A software development process, also known as a software development life cycle (SDLC), is

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.

Software development activities

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.

Implementation, testing and documenting

Implementation is the part of the process where software engineers actually program the code for
the project.
Software testing is an integral and important phase of the software development process. This
part of the process ensures that defects are recognized as soon as possible.
Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development. This may also include the writing of an API, be it

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.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or
otherwise distributed into a production environment.
Software Training and Support is important and a lot of developers fail to realize that. It would
not matter how much time and planning a development team puts into creating software if
nobody in an organization ends up using it. People are often resistant to change and avoid
venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to
have training classes for new clients of your software.
Maintaining and enhancing software to cope with newly discovered problems or new
requirements can take far more time than the initial development of the software. It may be
necessary to add code that does not fit the original design to correct an unforeseen problem or it
may be that a customer is requesting more functionality and code can be added to accommodate
their requests. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor
cost, then it is likely that the overall quality of at least one prior phase is poor.[citation needed] In that
case, management should consider the option of rebuilding the system (or portions) before
maintenance cost is out of control.

Software development models

Several models exist to streamline the development process. Each one has its pros and cons, and
it's up to the development team to adopt the most appropriate one for the project. Sometimes a
combination of the models may be more suitable.

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 and incremental development

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

Code and fix

"Code and fix" development is not so much a deliberate strategy as an artifact of naivet and
schedule pressure on software developers.[2] Without much of a design in the way, programmers
immediately begin producing code. At some point, testing begins (often late in the development
cycle), and the inevitable bugs must then be fixed before the product can be shipped. See also:
Continuous integration

Process improvement models

Capability Maturity Model Integration
The Capability Maturity Model Integration (CMMI) is one of the leading models and
based on best practice. Independent assessments grade organizations on how well they
follow their defined processes, not on the quality of those processes or the software
produced. CMMI has replaced CMM. ISO 9000 ISO 9000 describes standards for a
formally organized process to manufacture a product and the methods of managing and
monitoring progress. Although the standard was originally created for the manufacturing
sector, ISO 9000 standards have been applied to software development as well. Like

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.

The Government Accountability Office, in a 2003 report on one of the Federal

Aviation Administrations air traffic control modernization programs,[3] recommends
following the agencys guidance for managing major acquisition systems by

establishing, maintaining, and controlling an accurate, valid, and current

performance measurement baseline, which would include negotiating all
authorized, unpriced work within 3 months;
conducting an integrated baseline review of any major contract modifications
within 6 months; and
preparing a rigorous life-cycle cost estimate, including a risk assessment, in
accordance with the Acquisition System Toolsets guidance and identifying the
level of uncertainty inherent in the estimate.

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

Simple and easy to use.

Easy to manage due to the rigidity of the model each phase has specific deliverables and a
review process.

Phases are processed and completed one at a time.

Works well for smaller projects where requirements are very well understood.

Disadvantages
Adjusting scope during the life cycle can kill a project

No working software is produced until late during the life cycle.

High amounts of risk and uncertainty.

Poor model for complex and object-oriented projects.

Poor model for long and ongoing projects.

Poor model where requirements are at a moderate to high risk of changing.

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.

Little flexibility and adjusting scope is difficult and expensive.

Software is developed during the implementation phase, so no early prototypes of the software
are produced.
Model doesnt provide a clear path for problems found during testing phases.
Incremental ModelThe incremental model is an intuitive approach to the waterfall model. Multiple
development cycles take place here, making the life cycle a multi-waterfall cycle. Cycles are divided up
into smaller, more easily managed iterations. Each iteration passes through the requirements, design,
implementation and testing phases.A working version of software is produced during the first iteration,
so you have working software early on during the software life cycle. Subsequent iterations build on the
initial software produced during the first iteration.Incremental Life Cycle Model Advantages
Generates working software quickly and early during the software life cycle.

More flexible less costly to change scope and requirements.

Easier to test and debug during a smaller iteration.

Easier to manage risk because risky pieces are identified and handled during its iteration.

Each iteration is an easily managed milestone.

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

Good for large and mission-critical projects.

Software is produced early in the software life cycle.

Disadvantages
Can be a costly model to use.
Risk analysis requires highly specific expertise.

Projects success is highly dependent on the risk analysis phase.

Doesnt work well for smaller projects.

And thats it. If you have any input, especially your views on advantages and disadvantages of any
particular model, feel free to leave them in the comments and I can add them to my copy.

Prototype Model
Software prototyping

Software prototyping refers to the activity of creating prototypes of

software applications, i.e., incomplete versions of the software program being
developed. It is an activity that can occur in software development and is
comparable to prototyping as known from other fields, such as mechanical
engineering or manufacturing.

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.

Outline of the prototyping process

The process of prototyping involves the following steps
1. Identify basic requirements
Determine basic requirements including the input and output information
desired. Details, such as security, can typically be ignored.
2. Develop Initial Prototype
The initial prototype is developed that includes only user interfaces.
3. Review
The customers, including end-users, examine the prototype and provide
feedback on additions or changes.
4. Revise and Enhance the Prototype
Using the feedback both the specifications and the prototype can be
improved. Negotiation about what is within the scope of the contract/product
may be necessary. If changes are introduced then a repeat of steps #3 and
#4 may be needed.

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:

Confirmation of user interface requirements and system scope

Demonstration version of the system to obtain buy-in from the business

Develop preliminary estimates of development time, cost and effort.

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:

Refinement database design

Obtain information on data volumes and system interface needs, for network
sizing and performance engineering

Clarifies complex requirements by drilling down to actual system functionality

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.

Evolutionary Prototypes have an advantage over Throwaway Prototypes in that

they are functional systems. Although they may not have all the features the
users have planned, they may be used on an interim basis until the final system is
delivered.
"It is not unusual within a prototyping environment for the user to put an
initial prototype to practical use while waiting for a more developed version
The user may decide that a 'flawed' system is better than no system at all."

In Evolutionary Prototyping, developers can focus themselves to develop

parts of the system that they understand instead of working on developing a
whole system.
To minimize risk, the developer does not implement poorly understood
features. The partial system is sent to customer sites. As users work with the
system, they detect opportunities for new features and give requests for
these features to developers. Developers then take these enhancement
requests along with their own and use sound configuration-management
practices to change the software-requirements specification, update the
design, recode and retest[10]

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.

Best projects to use prototyping

It has been argued that prototyping, in some form or another, should be used all the time.
However, prototyping is most beneficial in systems that will have many interactions with the
users.
Systems with little user interaction, such as batch processing or systems that mostly do
calculations, benefit little from prototyping. Sometimes, the coding needed to perform the system
functions may be too intensive and the potential gains that prototyping could provide are too
smallPrototyping is especially good for designing good human-computer interfaces. "One of the
most productive uses of rapid prototyping to date has been as a tool for iterative user
requirements engineering and human-computer interface design."[8]

Methods
There are few formal prototyping methodologies even though most Agile Methods rely heavily
upon prototyping techniques.

Dynamic systems development method

Dynamic Systems Development Method (DSDM)[18] is a framework for delivering business
solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001
approved. It expands upon most understood definitions of a prototype. According to DSDM the
prototype may be a diagram, a business process, or even a system placed into production. DSDM
prototypes are intended to be incremental, evolving from simple forms into more comprehensive
ones.

DSDM prototypes may be throwaway or evolutionary. Evolutionary prototypes may be evolved

horizontally (breadth then depth) or vertically (each section is built in detail with additional
iterations detailing subsequent sections). Evolutionary prototypes can eventually evolve into
final systems.
The four categories of prototypes as recommended by DSDM are:
Business prototypes used to design and demonstrates the business processes
being automated.
Usability prototypes used to define, refine, and demonstrate user interface
design usability, accessibility, look and feel.
Performance and capacity prototypes - used to define, demonstrate, and
predict how systems will perform under peak loads as well as to demonstrate and
evaluate other non-functional aspects of the system (transaction rates, data storage
volume, response time, etc.)
Capability/technique prototypes used to develop, demonstrate, and evaluate a
design approach or concept.

The DSDM lifecycle of a prototype is to:

1. Identify prototype
2. Agree to a plan
3. Create the prototype
4. Review the prototype

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:

An evolutionary prototype is constructed and made

into a baseline using conventional development
strategies, specifying and implementing only the
requirements that are well understood.

Copies of the baseline are sent to multiple customer

sites along with a trained prototyper.

What is the Waterfall Model?

The waterfall model is a sequential software development model in which development is seen as flowing
steadily downwards (like a waterfall) through several phases.

History of the Waterfall Model

In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a
model which he argued was flawed (Royce 1970). His paper then explored how the initial model could be
developed into an iterative model, with feedback from each phase influencing previous phases, similar to
many methods used widely and highly regarded by many today.
Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the
"waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model"
has since come to refer to any approach to software creation which is seen as inflexible and non-iterative.

Usage of the waterfall model

In Royce's original waterfall model, the following phases are followed perfectly in sequential order:

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.

Criticism of the waterfall model

The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief
that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the
next phases and learning from them. A typical problem is when requirements change midway through,
resulting in a lot of time and effort being invalidated due to the "Big Design Up Front".
In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as
follows:

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]:

Determine the objectives, alternatives, and constraints on the new iteration.

Evaluate alternatives and identify and resolve risk issues.

Develop and verify the product for this iteration.

Plan the next iteration.

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.