Tải bản đầy đủ (.pdf) (53 trang)

Assignment 1 1631 Software Development Life Cycles

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (940.52 KB, 53 trang )

ASSIGNMENT 01 FRONT SHEET
Qualification

BTEC Level 5 HND Diploma in Computing

Unit number and title

Unit 09: Software Development Life Cycle

Submission date

17/05/2023

Date Received 1st submission

17/05/2023

Re-submission Date

03/06/2023

Date Received 2nd submission

03/06/2023

Student Name

Tran Duc Long

Student ID


GCH210562

Class

GCH1106

Assessor name

Nguyen The Lam Tung

Student declaration
I certify that the assignment submission is entirely my own work and I fully understand the consequences of plagiarism. I understand that making a
false declaration is a form of malpractice.
Student’s signature
Grading grid
P1

P2

P3

P4

M1

Page 1 of 52

M2

D1


D2


❒ Summative Feedback:

❒ Resubmission Feedback:

2.1

Grade:

Assessor Signature:

Date:

Internal Verifier’s Comments:

Signature & Date:

Page 2 of 52


Table of Contents
A.

Introduction ......................................................................................................................................................................................................................................... 6

B.


Describe different software development lifecycles........................................................................................................................................................................... 6
I.

Describe two iterative and two sequential software lifecycle models. (P1) ................................................................................................................................... 6
1.

What is SDLC ? ............................................................................................................................................................................................................................. 6

2.

Waterfall model ........................................................................................................................................................................................................................... 8

2.1.

Waterfall model – design ........................................................................................................................................................................................................ 8

2.2.

Waterfall model – Application................................................................................................................................................................................................. 9

2.3.

Advantages and disadvantages of waterfall model............................................................................................................................................................... 10

3.

V-model ..................................................................................................................................................................................................................................... 11

3.1.


V-model – design ................................................................................................................................................................................................................... 11

3.2.

V-model - Verification Phases................................................................................................................................................................................................ 12

3.3.

V-model – Application ........................................................................................................................................................................................................... 14

3.4.

Advantages and disadvantages of the V-model .................................................................................................................................................................... 15

4.

Prototyping model ..................................................................................................................................................................................................................... 15

4.1.

Prototyping model phases ..................................................................................................................................................................................................... 16

4.2.

Types of prototyping models ................................................................................................................................................................................................. 17

4.3.

Best Practices of prototyping ................................................................................................................................................................................................ 17


4.4.

Advantages and disadvantages of the prototyping model.................................................................................................................................................... 18

5.

Spiral model ............................................................................................................................................................................................................................... 19

5.1.

Spiral model – design............................................................................................................................................................................................................. 19

5.2.

Spiral model phases ............................................................................................................................................................................................................... 20

Page 3 of 52


5.3.

Spiral model application ........................................................................................................................................................................................................ 21

5.4.

Advantages and disadvantages of Spiral model .................................................................................................................................................................... 21

6.

Scrum model .............................................................................................................................................................................................................................. 22


6.1.

Key roles in Scrum model ...................................................................................................................................................................................................... 23

6.2.

Advantages and disadvantages of the Scrum model ............................................................................................................................................................ 24

7.

Compare and Choose SDLC model to the project ..................................................................................................................................................................... 26

7.2.
II.

C.

Choose model for project ...................................................................................................................................................................................................... 27

Explain how risk is managed in the Spiral lifecycle model. (P2) .................................................................................................................................................... 31
2.

Why is risk assessment important? ........................................................................................................................................................................................... 31

3.

What is the goal of risk assessment? ........................................................................................................................................................................................ 32

4.


Five Steps of the Risk Management Process ............................................................................................................................................................................. 33

5.

Risk Management Matrix of Tune Source project ..................................................................................................................................................................... 34

6.

Risk management table ............................................................................................................................................................................................................. 35

Explain the importance of a feasibility study .................................................................................................................................................................................... 37
I.

Explain the purpose of a feasibility report. (P3) ............................................................................................................................................................................ 37
1.

What is a feasibility report? ...................................................................................................................................................................................................... 37

2.

Importance of feasibility report?............................................................................................................................................................................................... 38

3.

What is the objective of the feasibility report? ......................................................................................................................................................................... 39

4.

Type feasibility ........................................................................................................................................................................................................................... 39


4.1.

Technical feasibility ............................................................................................................................................................................................................... 39

4.2.

Economic feasibility ............................................................................................................................................................................................................... 39

4.3.

Legal feasibility ...................................................................................................................................................................................................................... 40

Page 4 of 52


4.4.

Operational feasibility ........................................................................................................................................................................................................... 40

4.5.

Schedule feasibility ................................................................................................................................................................................................................ 40

4.6.

Environmental feasibility ....................................................................................................................................................................................................... 40

II.


Describe how technical solutions can be compared. (P4) ............................................................................................................................................................. 41
1.

Feasible criteria ......................................................................................................................................................................................................................... 42

a.

Technical Feasibility ................................................................................................................................................................................................................... 42

b.

Economic Feasibility .................................................................................................................................................................................................................. 42

c.

Organizational Feasibility .......................................................................................................................................................................................................... 43

2.

Alternative matrix for the Tune Source project ........................................................................................................................................................................ 44

a.

C# technology ............................................................................................................................................................................................................................ 44

b.

Java technology ......................................................................................................................................................................................................................... 44

c.


PHP technology.......................................................................................................................................................................................................................... 45

3.

Choose an Alternative to Tune Source ...................................................................................................................................................................................... 45

D.

Conclusion ......................................................................................................................................................................................................................................... 49

E.

Reference........................................................................................................................................................................................................................................... 50

Table of Figures
Figure 1: SDLC (Servicenow, 2023) .............................................................................................................................................................................................................. 7
Figure 2: Waterfall model (Tutorialspoint, 2023). ....................................................................................................................................................................................... 8
Figure 3: V-model (Tutorialspoint, 2023) .................................................................................................................................................................................................. 12
Figure 4: Prototyping models (Martin, 2023). ........................................................................................................................................................................................... 16
Figure 5: Spiral model (Tutorialspoint, 2023). ........................................................................................................................................................................................... 19
Figure 6: Scrum model (Atlassian, 2023). .................................................................................................................................................................................................. 23
Figure 7: Diagram scrum for Tune Source ................................................................................................................................................................................................. 30

Page 5 of 52


A.

Introduction


The SDLC, which stands for Software Development Life Cycle, is an important method that helps businesses build high-quality software that
satisfies the needs of their consumers. This method provides a disciplined approach to software development, guaranteeing that the product
is delivered on time, of high quality, and meets the expectations of the users. In this article, we will look at the SDLC's various stages and offer
advice on how firms can effectively adopt it. This report will also demonstrate the application of SDLC to the provided project and identify the
many models involved in the project, as well as specific explanations of feasibility studies.

B. Describe different software development lifecycles
I. Describe two iterative and two sequential software lifecycle models. (P1)
1. What is SDLC ?
The process of developing and deploying software applications is iterative, with multiple distinct phases. The Software Development
Life Cycle (SDLC) technique improves process monitoring and improvement by providing analysis of each stage of software
development. SDLC may reduce waste and boost efficiency by detailing each action required to build and deliver a software
application. SDLC helps firms stay on track with timetables and budgets by monitoring, ensuring that software development remains a
profitable investment. Agile and Waterfall processes are frequently employed in SDLC, and some firms use a hybrid of both.
(Servicenow, 2023)

Page 6 of 52


Figure 1: SDLC (Servicenow, 2023)

Here are the six phases of the SDLC:


Requirements Gathering and Analysis: In this phase, the software requirements are gathered and analyzed in detail. This
involves working closely with the stakeholders to determine the specific features, functions, and goals of the software.




Design: Once the requirements are established, the system design is developed in this phase. This includes creating a detailed
plan for the software system, such as the architecture, data structures, algorithms, and user interface design.



Implementation: The actual coding of the software is done in this phase based on the design specifications. This involves
writing, compiling, and testing the code to ensure it meets the requirements and functions correctly.



Testing: Once the implementation phase is complete, testing is conducted to validate that the software works as intended and
meets the requirements. Different types of testing, such as unit testing, integration testing, and system testing, are performed.



Deployment: Once the software is tested and deemed to be stable and fully functional, it is deployed to the users for their use.

Page 7 of 52




Maintenance: After the software is deployed, it enters the maintenance phase. This phase involves ongoing support, bug fixes,
and updates to ensure that the software continues to meet the user's needs and functions correctly.

2. Waterfall model
The Waterfall model is a linear and sequential approach to software development in which each phase follows the preceding one in a
precise, predetermined order. The phases of this approach are as follows: requirements gathering, design, implementation, testing,
deployment, and maintenance. The Waterfall model requires the development team to move on to the next step only when the
previous one has been completed and authorized. This method is frequently employed in industries with stringent standards or when

the requirements are well understood and unlikely to change. It can, however, be stiff and inflexible when numerous iterations are
required or when there is a high amount of uncertainty or change in the project requirements.

Figure 2: Waterfall model (Tutorialspoint, 2023).

2.1.

Waterfall model – design

Page 8 of 52


The Waterfall approach was the initial SDLC Model to gain widespread usage in the field of Software Engineering as a means of
ensuring project success. This model involves dividing the entire software development process into distinct phases, with each
phase's outcomes serving as the next phase's input in a sequential manner. (Tutorialspoint, 2023).
The Waterfall model's consecutive phases are as follows:


Requirements Gathering and Analysis: The software requirements are gathered and thoroughly assessed during this
phase. This entails working closely with stakeholders to identify the software's unique features, functions, and goals.



Design: This phase develops the system design after the requirements have been identified. Creating a detailed plan for
the software system, such as the architecture, data structures, algorithms, and user interface design, is part of this.



Implementation: The actual coding of the software is done in this phase based on the design specifications. This
involves writing, compiling, and testing the code to ensure it meets the requirements and functions correctly.




Testing: Once the implementation phase is complete, testing is conducted to validate that the software works as
intended and meets the requirements. Different types of testing, such as unit testing, integration testing, and system
testing, are performed.



Deployment: Once the software is tested and deemed to be stable and fully functional, it is deployed to the users for
their use.



Maintenance: After the software is deployed, it enters the maintenance phase. This phase involves ongoing support,
bug fixes, and updates to ensure that the software continues to meet the user's needs and functions correctly.

2.2.

Waterfall model – Application


The Waterfall Model is a software development methodology that is often used in projects where the requirements are
well-defined and stable, and there is little likelihood of change during the development process. It is a sequential
approach where each phase of the project is completed before moving on to the next one, and changes to the project
scope, requirements or design are generally not allowed after a phase is completed. (Tutorialspoint, 2023).



The Waterfall Model is useful for large and complex projects that require a high degree of planning and organization,

and where it is important to have a clear understanding of the project requirements and timeline. It provides a

Page 9 of 52


structured and systematic approach to software development, with clearly defined phases and deliverables that allow
for better control and management of the project.


One common application of the Waterfall Model is in the development of large-scale enterprise software systems, such
as financial management systems, inventory management systems, or customer relationship management systems.
These types of projects typically require a high degree of planning and coordination across multiple departments, and
the Waterfall Model can help ensure that the project is completed on time, within budget, and to the satisfaction of the
stakeholders.



Another application of the Waterfall Model is in the development of mission-critical systems, such as those used in
aerospace or medical devices, where failure could have severe consequences. The Waterfall Model provides a rigorous
approach to software development that can help ensure the reliability, safety, and performance of these types of
systems. (Tutorialspoint, 2023).

2.3.

Advantages and disadvantages of waterfall model
Advantage

Disadvantage

1. Clear and well-structured approach: The Waterfall


1. Inflexible to changes: The Waterfall Model is inflexible to changes in

Model provides a clear and structured approach to

the project scope or requirements, and any changes that do occur can

software development, with each phase being completed

be difficult and costly to implement.

before moving on to the next one. This makes it easier to
plan, manage and monitor the project.
2. Well-defined requirements: The Waterfall Model

2. Late feedback: The Waterfall Model does not allow for feedback or

requires that all the requirements be gathered and

testing until the later phases of the project, which can result in issues

defined upfront, which can help ensure that the final

being identified only after significant development has already

product meets the client's needs.

occurred.

Page 10 of 52



3. Predictable timeline and budget: Because the Waterfall

3. Limited collaboration: The Waterfall Model does not prioritize

Model is so well-structured, it makes it easier to predict

collaboration between different teams or stakeholders, which can limit

the timeline and budget for the project, which can be

communication and result in a less satisfactory final product.

important for clients and stakeholders.
4. Less likelihood of errors: The Waterfall Model requires

4. Not suitable for complex or large projects: The Waterfall Model may

that each phase be completed before moving on to the

not be suitable for complex or large projects, as it can be difficult to

next one, which can help reduce the likelihood of errors

define all the requirements upfront and unforeseen issues may arise

and defects in the final product.

during the development process.


Overall, the Waterfall Model can be effective for smaller, well-defined projects where the requirements are unlikely to change, but it may
not be suitable for larger or more complex projects where flexibility and collaboration are necessary.

3. V-model
The V-Model is a variation of the waterfall model that involves incorporating a testing phase for every stage of the development
process. This indicates that each development phase has a corresponding testing phase associated with it. The V-Model is known for
its rigorous structure, and it requires each phase to be finished before progressing to the next one. (Tutorialspoint, 2023).

3.1.

V-model – design
In the V-Model, the testing phase for each development stage is scheduled concurrently. This results in Verification phases on
one arm of the 'V' and Validation phases on the other. The Coding Phase serves as the connection between the two arms of
the V-Model.

Page 11 of 52


Figure 3: V-model (Tutorialspoint, 2023)

3.2.

V-model - Verification Phases
Business Requirement Analysis
In the initial phase of the development cycle, the main focus is to comprehend the customer's perspective and their
precise requirements of the product. This phase entails extensive communication with the customer to gain an
understanding of their expectations. Effective management of this phase is crucial, as many customers are uncertain
about their exact needs. Furthermore, the planning of acceptance test design is carried out in this phase since business
requirements can be utilized as an input for acceptance testing. (Tutorialspoint, 2023).

System Design
After obtaining a comprehensive understanding of the product requirements, the next step is to create the entire
system design. This design will encompass the complete hardware and communication setup for the product that is
being developed. Based on the system design, a system test plan is created. This activity is performed at an early stage,
allowing ample time for actual test execution later on.
Architectural Design

Page 12 of 52


During this phase, the architectural specifications are comprehended and created. Generally, multiple technical
approaches are suggested, and the final decision is made based on technical and financial feasibility. The system design
is further divided into modules that perform various functions. This is also known as High Level Design (HLD).
The communication and data transfer between the internal modules and with other systems outside the product are
precisely comprehended and defined in this stage. This information enables the creation and documentation of
integration tests during this phase.
Module Design
During this stage, the detailed internal design of all system modules is defined, known as Low Level Design (LLD). It is
crucial that the design is compatible with the other modules in the system architecture and external systems. Unit tests
are a crucial aspect of any development process and aid in identifying maximum faults and errors at an early stage.
Based on the internal module designs, unit tests can be created during this stage.
Coding Phase
The Coding phase involves the implementation of the system modules designed in the previous phase. During this
phase, the most appropriate programming language is selected based on the system and architectural requirements.
The coding process follows established coding guidelines and standards. The code undergoes multiple reviews and
optimizations to ensure optimal performance before the final build is checked into the repository.
Validation Phases
The Verification Phases of the V-model are designed to ensure that each development phase meets the requirements and
specifications established in the previous phase. The four Verification Phases are:



Unit Testing: In this phase, individual units or components of the software are tested to ensure that they function
as intended. The objective is to detect and fix defects in each unit before moving on to the next phase. Unit testing
is usually done by developers, and automated testing tools may be used to accelerate the process. (Tutorialspoint,
2023).



Integration Testing: Integration testing involves testing the software components together to ensure that they
operate as a unit. The objective is to detect and resolve any defects caused by the interactions between

Page 13 of 52


components. Integration testing may include testing the software interface and interactions with other systems,
databases, or networks.


System Testing: In this phase, the entire system is tested as a whole to ensure that it meets the requirements and
specifications defined in the previous development phases. The objective is to detect and resolve any defects that
were not detected in earlier stages. System testing may include functional testing, performance testing, security
testing, and other types of testing.



Acceptance Testing: Acceptance testing is the final verification phase in the V-model. It involves testing the
software in a simulated production environment to ensure that it meets the user's requirements and performs as
expected. Acceptance testing may be done by end-users, customers, or other stakeholders who are not involved in
the development process. The objective is to gain confidence that the software is ready for deployment and use.


In summary, the Verification Phases in the V-model aim to identify and correct defects early in the development cycle
to prevent problems from escalating and becoming more challenging and costly to fix later on.

3.3.

V-model – Application


The V-model is a popular software development model used to develop high-quality software systems efficiently. It is
an extension of the traditional Waterfall model and emphasizes the importance of testing throughout the entire
development cycle. (Tutorialspoint, 2023).



The V-model is suitable for projects where the requirements are well-defined, and changes to the requirements are
limited. It is commonly used in safety-critical industries such as aerospace, defense, and healthcare where a defect in
the software could have catastrophic consequences.



The V-model is also useful for projects where the cost of fixing defects increases significantly as the project progresses.
By emphasizing testing at each stage of the development cycle, the V-model ensures that defects are detected and
fixed as early as possible, reducing the cost and time required to fix them.



The V-model can be applied to various software development processes, including agile development, where testing is
done throughout the development cycle in short iterations. In agile development, the testing phases may be less
formal, but the concept of continuous testing and verification is still present.


Page 14 of 52




Overall, the V-model is an effective approach for developing high-quality software systems in a structured and
disciplined manner, with a focus on testing and verification. It ensures that the software meets the requirements and
specifications defined in each development phase and is ready for deployment and use.

3.4.

Advantages and disadvantages of the V-model
Advantages

Disadvantages

Good documentation: V-Model requires documentation

Inflexible: V-Model is not flexible and requires all phases to be

at each stage of development, which ensures clear

completed in a sequence, which can be limiting in complex projects with

communication between the development team and

changing requirements.

stakeholders, making the process more transparent.
Early detection of defects: The V-Model's testing


Time-consuming: V-Model can be time-consuming because of its

approach emphasizes early testing, which allows defects

extensive documentation and testing requirements.

to be detected and corrected earlier in the development
process, reducing the cost of fixing them later.
Ensures high-quality products: By incorporating testing at

Expensive: The extensive testing and documentation requirements of V-

every stage, the V-Model ensures that products meet the

Model can result in higher project costs.

expected quality and requirements.
Reduces risks: V-Model's emphasis on planning and

Limited scope for creativity: V-Model's rigidity can limit the scope for

testing minimizes risks of project failure and ensures

creativity and innovation, leading to a focus on processes rather than

smooth project completion.

outcomes.


In conclusion, the V-Model is a highly-disciplined model that emphasizes early testing and documentation, which helps reduce risks
and ensure high-quality products. However, its inflexibility and extensive requirements can lead to higher project costs and limit
creativity. Ultimately, the choice of SDLC model depends on the project's specific needs and requirements.

4. Prototyping model

Page 15 of 52


The Prototyping Model is a software development model in which a prototype or working model of the software application is built to
help users and developers better understand the requirements and functionality of the system. It is an iterative process that involves
creating a working model of the software and refining it based on user feedback and requirements. The prototype is tested and
refined until it meets the user's requirements and can be used as the basis for the final product. This model is used when the
requirements are not well understood or are likely to change during the development process. The prototype can help to clarify
requirements and identify any issues early on in the development cycle. (Martin, 2023).

Figure 4: Prototyping models (Martin, 2023).

4.1.

Prototyping model phases
The Prototyping Model generally consists of the following six SDLC phases:


Requirements gathering: In this phase, the requirements for the software system are collected from the customer
or end-users. The goal is to gather as much information as possible about the features and functionalities that the
system should have. (Martin, 2023).




Quick design: Once the requirements are gathered, a quick design is created based on the information collected in
the previous phase. The design should be simple and capture the basic functionalities of the system.



Build prototype: In this phase, a working prototype of the software is built based on the quick design. The
prototype is usually not fully functional, but it should have enough features to give the customer an idea of what
the final product will look like.

Page 16 of 52




Prototype testing: The prototype is tested to make sure that it meets the requirements specified in the first phase.
This includes functional testing, performance testing, and usability testing.



Refinement: Based on the feedback received from the prototype testing, the prototype is refined and improved.
This process may involve several iterations of the previous phases until the customer is satisfied with the prototype.



Final implementation and maintain: Once the prototype is refined and approved, the final implementation of the
software system can begin. The final implementation phase includes coding, testing, and deployment of the system.

4.2.

Types of prototyping models

There are four main types of prototyping models:


Throwaway prototyping: In this type of prototyping, a basic prototype is created quickly to validate and refine the
requirements. Once the requirements are clarified, the prototype is discarded, and the actual development process
begins. (Martin, 2023).



Evolutionary prototyping: In this type of prototyping, a basic prototype is created first, and then it is refined based on
feedback and testing. The prototype is incrementally developed until it becomes the final product.



Incremental prototyping: In this type of prototyping, the prototype is developed in small, incremental steps. Each
iteration builds upon the previous one until the final product is complete.



Extreme prototyping: In this type of prototyping, the focus is on quickly building and testing small, functional
prototypes. The goal is to develop a working model as quickly as possible, even if it is not perfect.

4.3.

Best Practices of prototyping
Here are some best practices for prototyping:


Clearly define the objectives: Define the purpose of the prototype and what you want to achieve from it. This helps you
to focus on the important aspects of the prototype and avoid unnecessary features. (Martin, 2023).




Involve stakeholders: Involve all the stakeholders in the prototyping process, such as end-users, developers, and
designers. This helps you to get their feedback and ideas which can be used to improve the final product.

Page 17 of 52




Keep it simple: The prototype should be simple and easy to use. Avoid adding unnecessary features or complex
functionality that can confuse the users.



Test early and often: Test the prototype early and often with the target audience to get feedback and make necessary
improvements. This helps you to avoid costly changes later in the development process.



Be flexible: Be prepared to make changes and adapt the prototype as needed. It's important to be flexible and willing to
make changes based on feedback and new information.



Document everything: Document all the decisions, changes, and feedback throughout the prototyping process. This
helps you to keep track of everything and avoid confusion or misunderstandings.

4.4.


Advantages and disadvantages of the prototyping model
Advantages

Disadvantges

Improved User Feedback: Prototyping models provide a

Cost: Prototyping can be costly, as it requires additional resources and

platform for developers to get feedback from end-users at an

time to develop and refine the prototype.

early stage. This helps to ensure that the final product meets
the requirements and expectations of the users.
Reduced Development Time: Prototyping models can help

Increased Complexity: Prototyping can lead to increased complexity in

reduce the overall development time by identifying potential

the development process. It requires additional planning, design, and

issues and making necessary changes early in the

testing to ensure that the prototype accurately reflects the final

development process.


product.

Better Communication: Prototyping models can help improve

Scope Creep: Prototyping can sometimes lead to scope creep, as

communication between developers and users, as well as

additional features or functionality may be added to the prototype that

within the development team. The visual representation of

were not included in the initial requirements.

the product helps to facilitate discussions and ensure that
everyone is on the same page.

Page 18 of 52


Better Quality: Since the prototyping model allows for testing

Not Suitable for All Projects: Prototyping may not be suitable for all

and refinement, the final product is likely to be of better

projects, particularly those with well-defined requirements or those

quality than if it was developed without prototyping.


with limited budgets.

Overall, the prototyping model can be an effective development methodology for certain projects, particularly those that require a
high degree of user involvement or those with complex requirements. However, it is important to carefully consider the advantages
and disadvantages before deciding to use the prototyping model for a particular project.

5. Spiral model
The Spiral Model is a software development process model that combines elements of both the waterfall model and the iterative
model. It is a highly flexible process model that allows for continuous improvement and risk management throughout the software
development lifecycle. (Tutorialspoint, 2023).

Figure 5: Spiral model (Tutorialspoint, 2023).

5.1.

Spiral model – design
The Spiral model comprises of four distinct phases. These phases are traversed in a cyclical manner during the software
development process, which is referred to as Spirals.

Page 19 of 52


Identification
The phase commences with collecting the initial business requirements in the first spiral. As the product advances in
the following spirals, the identification of system, subsystem, and unit requirements also takes place in this stage.
Moreover, this phase involves comprehending the system requirements through ongoing communication between the
system analyst and the customer. Finally, when the spiral comes to an end, the product is launched in the designated
market.
Design
The Design phase begins with the initial conceptual design in the first spiral and encompasses the subsequent spirals

with activities such as creating the architectural design, developing the logical design of modules, designing the physical
product, and finalizing the design.
Construct or Build
The Construct phase involves the creation of the software product in each spiral. During the initial spiral, a Proof of
Concept (POC) is developed in this phase to obtain feedback from the customer while the design is still in progress.
As the project progresses through subsequent spirals, and there is greater clarity on the requirements and design
details, a working model of the software, called a build, is produced in this phase with a specific version number. These
builds are then shared with the customer to receive feedback.

5.2.

Spiral model phases
The Spiral Model consists of four phases, which are executed in a cyclical or spiral fashion. These phases are:


Planning: In this phase, the objectives, requirements, and constraints of the project are defined. A preliminary design is
created, and the project risks are identified and evaluated.



Risk analysis: In this phase, the risks identified in the planning phase are analyzed, and strategies are developed to
mitigate them. The project is also reviewed to determine whether it is feasible, and the design is refined based on the
results of the risk analysis.

Page 20 of 52



×