4 SDLC - Spiral Model
4 SDLC - Spiral Model
Identification
This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements,
subsystem requirements and unit requirements are all done in this phase.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final
design in the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In
the baseline spiral, when the product is just thought of and the design is being developed
a POC (Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a
working model of the software called build is produced with a version number. These
builds are sent to the customer for feedback.
The following illustration is a representation of the Spiral Model, listing the activities in
each phase.
Based on the customer evaluation, the software development process enters the next
iteration and subsequently follows the linear approach to implement the feedback
suggested by the customer. The process of iterations along the spiral continues throughout
the life of the software.
New product line which should be released in phases to get enough customer
feedback.
Significant changes are expected in the product during the development cycle.
Explore our latest online courses and learn new skills at your own pace. Enroll and
become a certified expert to boost your career.
This method is consistent with approaches that have multiple software builds and releases
which allows making an orderly transition to a maintenance activity. Another positive
aspect of this method is that the spiral model forces an early user involvement in the
system development effort.
On the other side, it takes a very strict management to complete such products and there
is a risk of running the spiral in an indefinite loop. So, the discipline of change and the
extent of taking change requests is very important to develop and deploy the product
successfully.
Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
Not suitable for small or low risk projects and could be expensive for small
projects.
Process is complex