Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
a structure imposed on the development of a software product. Similar terms include software
life cycle and software process. It is often considered a subset of systems development life cycle.
There are several models for such processes, each describing approaches to a variety of tasks or
activities that take place during the process. Some people consider a lifecycle model a more
general term and a software development process a more specific term. For example, there are
many specific software development processes that 'fit' the spiral lifecycle model. ISO/IEC
12207 is an international standard for software lifecycle processes. It aims to be the standard that
defines all the tasks required for developing and maintaining software.
Overview
The large and growing body of software development organizations implement process
methodologies. Many of them are in the defense industry, which in the U.S. requires a rating
based on 'process models' to obtain contracts.
The international standard for describing the method of selecting, implementing and monitoring
the life cycle for software is ISO/IEC 12207.
A decades-long goal has been to find repeatable, predictable processes that improve productivity
and quality. Some try to systematize or formalize the seemingly unruly task of writing software.
Others apply project management techniques to writing software. Without project management,
software projects can easily be delivered late or over budget. With large numbers of software
projects not meeting their expectations in terms of functionality, cost, or delivery schedule,
effective project management appears to be lacking.
Organizations may create a Software Engineering Process Group (SEPG), which is the focal
point for process improvement. Composed of line practitioners who have varied skills, the group
is at the center of the collaborative effort of everyone in the organization who is involved with
software engineering process improvement.
The activities of the software development process represented in the waterfall model. There are
several other models to represent this process.
Planning
An important task in creating a software program is extracting the requirements or requirements
analysis. Customers typically have an abstract idea of what they want as an end result, but not
what software should do. Incomplete, ambiguous, or even contradictory requirements are
recognized by skilled and experienced software engineers at this point. Frequently demonstrating
live code may help reduce the risk that the requirements are incorrect.
Once the general requirements are gathered from the client, an analysis of the scope of the
development should be determined and clearly stated. This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as a result of
unclear requirements at the start of development. If the development is done externally, this
document can be considered a legal document so that if there are ever disputes, any ambiguity of
what was promised to the client can be clarified.
external or internal. The software engineering process chosen by the developing team will
determine how much internal documentation (if any) is necessary. Plan-driven models (e.g.,
Waterfall) generally produce more documentation than Agile models.
Waterfall model
The waterfall model shows a process, where developers are to follow these phases in order:
1. Requirements specification (Requirements analysis)
2. Software design
3. Implementation and Integration
4. Testing (or Validation)
5. Deployment (or Installation)
6. Maintenance
In a strict Waterfall model, after each phase is finished, it proceeds to the next one. Reviews may
occur before moving to the next phase which allows for the possibility of changes (which may
involve a formal change control process). Reviews may also be employed to ensure that the
phase is indeed complete; the phase completion criteria are often referred to as a "gate" that the
project must pass through to move to the next phase. Waterfall discourages revisiting and
revising any prior phase once it's complete. This "inflexibility" in a pure Waterfall model has
been a source of criticism by supporters of other more "flexible" models.
Spiral model
The key characteristic of a Spiral model is risk management at regular stages in the development
cycle. In 1988, Barry Boehm published a formal software system development "spiral model,"
which combines some key aspect of the waterfall model and rapid prototyping methodologies,
but provided emphasis in a key area many felt had been neglected by other methodologies:
deliberate iterative risk analysis, particularly suited to large-scale complex systems.
The Spiral is visualized as a process passing through some number of iterations, with the four
quadrant diagram representative of the following activities:
1. formulate plans to: identify software targets, selected to implement the program, clarify
the project development restrictions;
2. Risk analysis: an analytical assessment of selected programs, to consider how to identify
and eliminate risk;
3. the implementation of the project: the implementation of software development and
verification;
Risk-driven spiral model, emphasizing the conditions of options and constraints in order to
support software reuse, software quality can help as a special goal of integration into the product
development. However, the spiral model has some restrictive conditions, as follows:
1. The spiral model emphasizes risk analysis, and thus requires customers to accept this
analysis and act on it. This requires both trust in the developer as well as the willingness
to spend more to fix the issues, which is the reason why this model is often used for
large-scale internal software development.
2. If the implementation of risk analysis will greatly affect the profits of the project, the
spiral model should not be used.
3. Software developers have to actively look for possible risks, and analyze it accurately for
the spiral model to work.
The first stage is to formulate a plan to achieve the objectives with these constraints, and then
strive to find and remove all potential risks through careful analysis and, if necessary, by
constructing a prototype. If some risks can not be ruled out, the customer has to decide whether
to terminate the project or to ignore the risks and continue anyway. Finally, the results are
evaluated and the design of the next phase begins.
Iterative development[1] prescribes the construction of initially small but ever-larger portions of a
software project to help all those involved to uncover important issues early before problems or
faulty assumptions can lead to disaster.
Agile development
Agile software development uses iterative development as a basis but advocates a lighter and
more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather
than planning, as their primary control mechanism. The feedback is driven by regular tests and
releases of the evolving software.
There are many variations of agile processes:
In Extreme Programming (XP), the phases are carried out in extremely small (or
"continuous") steps compared to the older, "batch" processes. The (intentionally incomplete)
first pass through the steps might take a day or a week, rather than the months or years of
each complete step in the Waterfall model. First, one writes automated tests, to provide
concrete goals for development. Next is coding (by a pair of programmers), which is
complete when all the tests pass, and the programmers can't think of any more tests that are
needed. Design and architecture emerge out of refactoring, and come after coding. Design is
done by the same people who do the coding. (Only the last feature merging design and
code is common to all the other agile processes.) The incomplete but functional system is
deployed or demonstrated for (some subset of) the users (at least one of which is on the
development team). At this point, the practitioners start again on writing tests for the next
most important part of the system.
Scrum
CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only
that formalized business processes have been followed.
ISO/IEC 15504
ISO/IEC 15504 Information technology Process assessment also known as Software
Process Improvement Capability Determination (SPICE), is a "framework for the
assessment of software processes". This standard is aimed at setting out a clear model for
process comparison. SPICE is used much like CMMI. It models processes to manage,
control, guide and monitor software development. This model is then used to measure
what a development organization or project team actually does during software
development. This information is analyzed to identify weaknesses and drive
improvement. It also identifies strengths that can be continued or integrated into common
practice for that organization or team.
Formal methods
Formal methods are mathematical approaches to solving software (and hardware)
problems at the requirements, specification and design levels. Examples of formal
methods include the B-Method, Petri nets, Automated theorem proving, RAISE and
VDM. Various formal specification notations are available, such as the Z notation.
More generally, automata theory can be used to build up and validate application
behavior by designing a system of finite state machines.
Finite state machine (FSM) based methodologies allow executable software
specification and by-passing of conventional coding (see virtual finite state machine
or event driven finite state machine).
Formal methods are most likely to be applied in avionics software, particularly
where the software is safety critical. Software safety assurance standards, such as
DO178B demand formal methods at the highest level of categorization (Level A).
Formalization of software development is creeping in, in other places, with the
application of Object Constraint Language (and specializations such as Java
Modeling Language) and especially with Model-driven architecture allowing
execution of designs, if not specifications.
Another emerging trend in software development is to write a specification in some
form of logic (usually a variation of FOL), and then to directly execute the logic as
though it were a program. The OWL language, based on Description Logic, is an
example. There is also work on mapping some version of English (or another natural
language) automatically to and from logic, and executing the logic directly.
Examples are Attempto Controlled English, and Internet Business Logic, which does
not seek to control the vocabulary or syntax. A feature of systems that support
bidirectional English-logic mapping and direct execution of the logic is that they can
be made to explain their results, in English, at the business or scientific level.
Software Development Life Cycle Models The General Model Software life cycle models
describe phases of the software cycle and the order in which those phases are executed. There are tons of
models, and many companies adopt their own, but all have very similar patterns. The general, basic
model is shown below: General Life Cycle Model Each phase produces deliverables required by the next
phase in the life cycle. Requirements are translated into design. Code is produced during
implementation that is driven by the design. Testing verifies the deliverable of the implementation phase
against requirements. Requirements Business requirements are gathered in this phase. This phase is the
main focus of the project managers and stake holders. Meetings with managers, stake holders and users
are held in order to determine the requirements. Who is going to use the system? How will they use the
system? What data should be input into the system? What data should be output by the system? These
are general questions that get answered during a requirements gathering phase. This produces a nice big
list of functionality that the system should provide, which describes functions the system should perform,
business logic that processes data, what data is stored and used by the system, and how the user interface
should work. The overall result is the system as a whole and how it performs, not how it is actually going
to do it. Design The software system design is produced from the results of the requirements phase.
Architects have the ball in their court during this phase and this is the phase in which their focus lies.
This is where the details on how the system will work is produced. Architecture, including hardware and
software, communication, software design (UML is produced here) are all part of the deliverables of a
design phase. Implementation Code is produced from the deliverables of the design phase during
implementation, and this is the longest phase of the software development life cycle. For a developer, this
is the main focus of the life cycle because this is where the code is produced. Implementation my overlap
with both the design and testing phases. Many tools exists (CASE tools) to actually automate the
production of code using information gathered and produced during the design phase. Testing During
testing, the implementation is tested against the requirements to make sure that the product is actually
solving the needs addressed and gathered during the requirements phase. Unit tests and
system/acceptance tests are done during this phase. Unit tests act on a specific component of the system,
while system tests act on the system as a whole. So in a nutshell, that is a very basic overview of the
general software development life cycle model. Now lets delve into some of the traditional and widely
used variations. Waterfall Model This is the most common and classic of life cycle models, also referred
to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a
review takes place to determine if the project is on the right path and whether or not to continue or
discard the project. Unlike what I mentioned in the general model, phases do not overlap in a waterfall
model. Waterfall Life Cycle Model Advantages
Works well for smaller projects where requirements are very well understood.
Disadvantages
Adjusting scope during the life cycle can kill a project
V-Shaped ModelJust like the waterfall model, the V-Shaped life cycle is a sequential path of execution of
processes. Each phase must be completed before the next phase begins. Testing is emphasized in this
model more so than the waterfall model though. The testing procedures are developed early in the life
cycle before any coding is done, during each of the phases preceding implementation. Requirements
begin the life cycle model just like the waterfall model. Before development is started, a system test plan
is created. The test plan focuses on meeting the functionality specified in the requirements gathering. The
high-level design phase focuses on system architecture and design. An integration test plan is created in
this phase as well in order to test the pieces of the software systems ability to work together. The low-level
design phase is where the actual software components are designed, and unit tests are created in this
phase as well. The implementation phase is, again, where all coding takes place. Once coding is
complete, the path of execution continues up the right side of the V where the test plans developed earlier
are now put to use.V-Shaped Life Cycle Model Advantages
Simple and easy to use.
Each phase has specific deliverables.
Higher chance of success over the waterfall model due to the development of test plans early on
during the life cycle.
Works well for small projects where requirements are easily understood.
Disadvantages
Very rigid, like the waterfall model.
Easier to manage risk because risky pieces are identified and handled during its iteration.
Disadvantages
Each phase of an iteration is rigid and do not overlap each other.
Problems may arise pertaining to system architecture because not all requirements are gathered
up front for the entire software life cycle.
Spiral ModelThe spiral model is similar to the incremental model, with more emphases placed on risk
analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A
software project repeatedly passes through these phases in iterations (called Spirals in this model). The
baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each
subsequent spirals builds on the baseline spiral .Requirements are gathered during the planning phase.
In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is
produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with
testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the
project to date before the project continues to the next spiral .In the spiral model, the angular component
represents progress, and the radius of the spiral represents cost.
Spiral Life Cycle Model Advantages
High amount of risk analysis
Disadvantages
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Prototype Model
Software prototyping
A prototype typically simulates only a few aspects of the final solution, and may be completely
different from the final product.
Prototyping has several benefits: The software designer and implementer can get valuable
feedback from the users early in the project. The client and the contractor can compare if the
software made matches the software specification, according to which the software program is
built. It also allows the software engineer some insight into the accuracy of initial project
estimates and whether the deadlines and milestones proposed can be successfully met. The
degree of completeness and the techniques used in the prototyping have been in development and
debate since its proposal in the early 1970s
Overview
The original purpose of a prototype is to allow users of the software to evaluate developers'
proposals for the design of the eventual product by actually trying them out, rather than having to
interpret and evaluate the design based on descriptions. Prototyping can also be used by end
users to describe and prove requirements that developers have not considered, and that can be a
key factor in the commercial relationship between developers and their clients. Interaction design
in particular makes heavy use of prototyping with that goal.
This process is in contrast with the 1960s and 1970s monolithic development cycle of building
the entire program first and then working out any inconsistencies between design and
implementation, which led to higher software costs and poor estimates of time and cost. The
monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it
assumes that the software designer and developer is a single hero who has to slay the entire
dragon alone. Prototyping can also avoid the great expense and difficulty of changing a finished
software product.
Dimensions of prototypes
Nielsen summarizes the various dimensions of prototypes in his book Usability Engineering
Horizontal Prototype
A common term for a user interface prototype is the horizontal prototype. It provides a broad
view of an entire system or subsystem, focusing on user interaction more than low-level system
functionality, such as database access. Horizontal prototypes are useful for:
Vertical Prototype
A vertical prototype is a more complete elaboration of a single subsystem or function. It is
useful for obtaining detailed requirements for a given function, with the following benefits:
Types of prototyping
Software prototyping has many variants. However, all the methods are in some way based on
two major types of prototyping: Throwaway Prototyping and Evolutionary Prototyping.
Throwaway prototyping
Also called close-ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a
model that will eventually be discarded rather than becoming part of the final delivered software.
After preliminary requirements gathering is accomplished, a simple working model of the system
is constructed to visually show the users what their requirements may look like when they are
implemented into a finished system.
Rapid Prototyping involved creating a working model of various parts of the
system at a very early stage, after a relatively short investigation. The
method used in building it is usually quite informal, the most important factor
being the speed with which the model is provided. The model then becomes
the starting point from which users can re-examine their expectations and
clarify their requirements. When this has been achieved, the prototype model
is 'thrown away', and the system is formally developed based on the
identified requirements.[7]
The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If
the users can get quick feedback on their requirements, they may be able to refine them early
in the development of the software. Making changes early in the development lifecycle is
extremely cost effective since there is nothing at that point to redo. If a project is changed
after a considerable work has been done then small changes could require large efforts to
implement since software systems have many dependencies. Speed is crucial in
implementing a throwaway prototype, since with a limited budget of time and money little
can be expended on a prototype that will be discarded.
Strength of Throwaway Prototyping is its ability to construct interfaces that the users can
test. The user interface is what the user sees as the system, and by seeing it in front of them,
it is much easier to grasp how the system will work.
it is asserted that revolutionary rapid prototyping is a more effective
manner in which to deal with user requirements-related issues, and therefore
a greater enhancement to software productivity overall. Requirements can be
identified, simulated, and tested far more quickly and cheaply when issues of
resolvability, maintainability, and software structure are ignored. This, in turn,
leads to the accurate specification of requirements and the subsequent
construction of a valid and usable system from the user's perspective via
conventional software development models. ]
Prototypes can be classified according to the fidelity with which they resemble the actual
product in terms of appearance, interaction and timing. One method of creating a low
fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using
paper and pencil, and thus mimics the function of the actual product, but does not look at
all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a
GUI Builder and create a click dummy, a prototype that looks like the goal system, but
does not provide any functionality.
Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the
usage of storyboards, animators or drawings. These are non-functional implementations
but show how the system will look.
SUMMARY:-In this approach the prototype is constructed with the idea that it will be
discarded and the final system will be built from scratch. The steps in this approach are:
1. Write preliminary requirements
2. Design the prototype
3. User experiences/uses the prototype, specifies new requirements
4. Repeat if necessary
5. Write the final requirements
6. Develop the real products
Evolutionary prototyping
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from
Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build
a very robust prototype in a structured manner and constantly refine it. "The reason for
this is that the Evolutionary prototype, when built, forms the heart of the new system,
and the improvements and further requirements will be built.
When developing a system using Evolutionary Prototyping, the system is continually
refined and rebuilt.
"evolutionary prototyping acknowledges that we do not understand all the
requirements and builds only those that are well understood."
This technique allows the development team to add features, or make changes that
couldn't be conceived during the requirements and design phase.
For a system to be useful, it must evolve through use in its intended
operational environment. A product is never "done;" it is always maturing as
the usage environment changeswe often try to define a system using our
most familiar frame of reference---where we are now. We make assumptions
about the way business will be conducted and the technology base on which
the business will be implemented. A plan is enacted to develop the capability,
and, sooner or later, something resembling the envisioned system is
delivered.
Incremental prototyping
The final product is built as separate prototypes. At the end the separate prototypes are merged in
an overall design.
Extreme prototyping
Extreme Prototyping as a development process is used especially for developing web
applications. Basically, it breaks down web development into three phases, each one based on the
preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the
second phase, the screens are programmed and fully functional using a simulated services layer.
In the third phase the services are implemented. The process is called Extreme Prototyping to
draw attention to the second phase of the process, where a fully functional UI is developed with
very little regard to the services other than their contract.
Advantages of prototyping
There are many advantages to using prototyping in software development some tangible, some
abstract.
Reduced time and costs: Prototyping can improve the quality of requirements and specifications
provided to developers. Because changes cost exponentially more to implement as they are
detected later in development, the early determination of what the user really wants can result in
faster and less expensive software
Improved and increased user involvement: Prototyping requires user involvement and allows
them to see and interact with a prototype allowing them to provide better and more complete
feedback and specifications. The presence of the prototype being examined by the user prevents
many misunderstandings and miscommunications that occur when each side believe the other
understands what they said. Since users know the problem domain better than anyone on the
development team does, increased interaction can result in final product that has greater tangible
and intangible quality. The final product is more likely to satisfy the users desire for look, feel
and performance.
Disadvantages of prototyping
Using, or perhaps misusing, prototyping can also have disadvantages.
Insufficient analysis: The focus on a limited prototype can distract developers from properly
analyzing the complete project. This can lead to overlooking better solutions, preparation of
incomplete specifications or the conversion of limited prototypes into poorly engineered final
projects that are hard to maintain. Further, since a prototype is limited in functionality it may not
scale well if the prototype is used as the basis of a final deliverable, which may not be noticed if
developers are too focused on building a prototype as a model.
User confusion of prototype and finished system: Users can begin to think that a prototype,
intended to be thrown away, is actually a final system that merely needs to be finished or
polished. (They are, for example, often unaware of the effort needed to add error-checking and
security features which a prototype may not have.) This can lead them to expect the prototype to
accurately model the performance of the final system when this is not the intent of the
developers. Users can also become attached to features that were included in a prototype for
consideration and then removed from the specification for a final system. If users are able to
require all proposed features be included in the final system this can lead to conflict.
Developer misunderstanding of user objectives: Developers may assume that users share their
objectives (e.g. to deliver core functionality on time and within budget), without understanding
wider commercial issues. For example, user representatives attending Enterprise software (e.g.
PeopleSoft) events may have seen demonstrations of "transaction auditing" (where changes are
logged and displayed in a difference grid view) without being told that this feature demands
additional coding and often requires more hardware to handle extra database accesses. Users
might believe they can demand auditing on every field, whereas developers might think this is
feature creep because they have made assumptions about the extent of user requirements. If the
developer has committed delivery before the user requirements were reviewed, developers are
between a rock and a hard place, particularly if user management derives some advantage from
their failure to implement requirements.
Developer attachment to prototype: Developers can also become attached to prototypes they
have spent a great deal of effort producing; this can lead to problems like attempting to convert a
limited prototype into a final system when it does not have an appropriate underlying
architecture. (This may suggest that throwaway prototyping, rather than evolutionary
prototyping, should be used.)
Excessive development time of the prototype: A key property to prototyping is the fact that it is
supposed to be done quickly. If the developers lose sight of this fact, they very well may try to
develop a prototype that is too complex. When the prototype is thrown away the precisely
developed requirements that it provides may not yield a sufficient increase in productivity to
make up for the time spent developing the prototype. Users can become stuck in debates over
details of the prototype, holding up the development team and delaying the final product.
Expense of implementing prototyping: the start up costs for building a development team
focused on prototyping may be high. Many companies have development methodologies in
place, and changing them can mean retraining, retooling, or both. Many companies tend to just
jump into the prototyping without bothering to retrain their workers as much as they should.
Methods
There are few formal prototyping methodologies even though most Agile Methods rely heavily
upon prototyping techniques.
Operational prototyping
Operational Prototyping was proposed by Alan Davis as a way to integrate throwaway and
evolutionary prototyping with conventional system development. "It offers the best of both the
quick-and-dirty and conventional-development worlds in a sensible manner. Designers develop
only well-understood features in building the evolutionary baseline, while using throwaway
prototyping to experiment with the poorly understood features.
Davis' belief is that to try to "retrofit quality onto a rapid prototype" is not the correct approach
when trying to combine the two approaches. His idea is to engage in an evolutionary prototyping
methodology and rapidly prototype the features of the system after each evolution.
The specific methodology follows these steps:
Requirements specification
Requirements are captured and set in stone.
Design
A "blueprint" is drawn up for the developers to implement.
Implementation
Integration
Testing
Installation
Maintenance
The waterfall model maintains that one should move to a phase only when its preceding phase is completed
and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back
and forth or overlap between them.
As many find this approach particularly rigid, modifications have been made over the years and new variants
of the model have emerged.
Poor flexibility; the majority of software is written as part of a contract with a client, and clients
are notorious for changing their stated requirements. Thus the software project must be adaptable, and
spending considerable effort in design and implementation based on the idea that requirements will
never change is neither adaptable nor realistic in these cases. Unless those who specify requirements
and those who design the software system in question are highly competent, it is difficult to know
exactly what is needed in each phase of the software process before some time is spent in the phase
"following" it. Constant testing from the design, implementation and verification phases is required to
validate the phases preceding them. Users of the waterfall model may argue that if designers follow a
disciplined process and do not make mistakes that there is no need to constantly validate the
preceding phases.
Frequent incremental builds (following the "release early, release often" philosophy) are often
needed to build confidence for a software production team and their client.
It is difficult to estimate time and cost for each phase of the development process.
The waterfall model brings no formal means of exercising management control over a project
and planning control and risk management are not covered within the model itself.
Only a certain number of team members will be qualified for each phase, which can lead at
times to some team members being inactive.
Spiral model
The spiral model is a software development process combining elements of both design and
prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts.
Also known as the spiral lifecycle model (or spiral development), it is a systems development
method (SDM) used in information technology (IT). This model of development combines the
features of the prototyping model and the waterfall model. The spiral model is intended for large,
expensive and complicated projects.
This should not be confused with the Helical model of modern systems architecture that uses a
dynamic programming approach in order to optimise the system's architecture before design
decisions are made by coders that would cause problems.
The spiral model was defined by Barry Boehm in his 1986 article "A Spiral Model of Software
Development and Enhancement".[1] This model was not the first model to discuss iterative
development. As originally envisioned, the iterations were typically 6 months to 2 years long.
Each phase starts with a design goal and ends with the client (who may be internal) reviewing
the progress thus far. Analysis and engineering efforts are applied at each phase of the project,
with an eye toward the end goal of the project.
The model
The spiral model combines the idea of iterative development (prototyping) with the systematic,
controlled aspects of the waterfall model. It allows for incremental releases of the product, or
incremental refinement through each time around the spiral. The spiral model also explicitly
includes risk management within software development. Identifying major risks, both technical
and managerial, and determining how to lessen the risk helps keep the software development
process under control.[2]
The spiral model is based on continuous refinement of key products for requirements definition
and analysis, system and software design, and implementation (the code). At each iteration
around the cycle, the products are extensions of an earlier product. This model uses many of the
same phases as the waterfall model, in essentially the same order, separated by planning, risk
assessment, and the building of prototypes and simulations.[2]
Documents are produced when they are required, and the content reflects the information
necessary at that point in the process. All documents will not be created at the beginning of the
process, nor all at the end (hopefully). Like the product they define, the documents are works in
progress. The idea is to have a continuous stream of products produced and available for user
review.[2]
The spiral lifecycle model allows for elements of the product to be added in when they become
available or known. This assures that there is no conflict with previous requirements and design.
This method is consistent with approaches that have multiple software builds and releases and
allows for making an orderly transition to a maintenance activity. Another positive aspect is that
the spiral model forces early user involvement in the system development effort. For projects
with heavy user interfacing, such as user application programs or instrument interface
applications, such involvement is helpful.[2]
Starting at the center, each turn around the spiral goes through several task regions [2]:
Note that the requirements activity takes place in multiple sections and in multiple iterations, just
as planning and risk analysis occur in multiple places. Final design, implementation, integration,
and test occur in iteration 4. The spiral can be repeated multiple times for multiple builds. Using
this method of development, some functionality can be delivered to the user faster than the
waterfall method. The spiral method also helps manage risk and uncertainty by allowing multiple
decision points and by explicitly admitting that all of anything cannot be known before the
subsequent activity starts.[2]
Applications
This article may contain original research. Please improve it by verifying the claims made
and adding references. Statements consisting only of original research may be removed. More
details may be available on the talk page. (November 2011)
The spiral model is mostly used in large projects. For smaller projects, the concept of agile
software development is becoming a viable alternative. The US military had adopted the spiral
model for its Future Combat Systems program. The FCS project was canceled after six years
(20032009), it had a two year iteration (spiral). The FCS should have resulted in three
consecutive prototypes (one prototype per spiralevery two years). It was canceled in May
2009. The spiral model thus may suit small (up to $3 million) software applications and not a
complicated ($3 billion) distributed, interoperable, system of systems.
Also it is reasonable to use the spiral model in projects where business goals are unstable but the
architecture must be realized well enough to provide high loading and stress ability. For example,
the Spiral Architecture Driven Development is the spiral based Software Development Life
Cycle (SDLC) which shows one possible way how to reduce the risk of non-effective
architecture with the help of a spiral model in conjunction with the best practices from other
models.