Model Advantages Disadvantages

Waterfall 1. This model is simple and easy to understand and use. 1. Once an application is in the testing stage, it is very
2. It is easy to manage due to the rigidity of the model – difficult to go back and change something that was not
each phase has specific deliverables and a review well-thought out in the concept stage.
process. 2. No working software is produced until late during the life
3. In this model phases are processed and completed one cycle.
at a time. Phases do not overlap. 3. High amounts of risk and uncertainty.
4. Waterfall model works well for smaller projects where 4. Not a good model for complex and object-oriented
requirements are very well understood. projects.
5. Poor model for long and ongoing projects.
6. Not suitable for the projects where requirements are at a
moderate to high risk of changing.

V-Model 1. Simple and easy to use. 1. Very rigid and least flexible.
2. Testing activities like planning, test designing happens 2. Software is developed during the implementation phase,
well before coding. This saves a lot of time. Hence higher so no early prototypes of the software are produced.
chance of success over the waterfall model. 3. If any changes happen in midway, then the test
3. Proactive defect tracking – that is defects are found at documents along with requirement documents has to be
early stage. updated.
4. Avoids the downward flow of the defects.
5. Works well for small projects where requirements are
easily understood.
Prototype 1. Users are actively involved in the development 1. Leads to implementing and then repairing way of building
2. Since in this methodology a working model of the systems.
system is provided, the users get a better understanding 2. Practically, this methodology may increase the
of the system being developed. complexity of the system as scope of the system may
3. Errors can be detected much earlier. expand beyond original plans.
4. Quicker user feedback is available leading to better 3. Incomplete application may cause application not to be
solutions. used as the full system was designed Incomplete or
5. Missing functionality can be identified easily inadequate problem analysis.
6. Confusing or difficult functions can be identified
7. Requirements validation, Quick implementation of,
incomplete, but functional, application.
Operational
Specification
Transformation Reduces error by taking away major development steps, uses Must have a formal specification expressed precisely so that the
automation support designed to change specifications into transformation is able to operate on it.
deliverables, Transformations include: changing the data
representations, selecting algorithms, optimizing, and compiling.
Increments 1. Generates working software quickly and early during the 1. Needs good planning and design.
software life cycle. 2. Needs a clear and complete definition of the whole
2. This model is more flexible – less costly to change scope system before it can be broken down and built
and requirements. incrementally.
3. It is easier to test and debug during a smaller iteration. 3. Total cost is higher than waterfall.
4. In this model customer can respond to each built.
5. Lowers initial delivery cost.
6. Easier to manage risk because risky pieces are identified
and handled during it’d iteration.
Iteration 1. Each phase of an iteration is rigid with no overlaps 1. Requirements of the complete system are clearly defined
2. Costly system architecture or design issues may arise and understood.
because not all requirements are gathered up front for 2. When the project is big.
the entire lifecycle 3. Major requirements must be defined; however, some
details can evolve with time.
Spiral model 1. Provides early indication of insurmountable risk, without 1. Time spent for evaluating risk to large for small or low-
much cost risk projects
2. Users see the system early because of rapid prototyping 2. Time spent planning, resetting objectives, doing risk
tools analysis and prototyping may be excessive
3. Critical high-risk functions are developed first 3. The model is complex
4. The design does not have to be perfect 4. Risk assessment expertise is required
5. Users can be closely tied to all lifecycle steps 5. Spiral may continue indefinitely
6. Early and frequent feedback from users 6. Developers must be reassigned during non-development
7. Cumulative costs assessed frequently phase activities
7. May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next
iteration
Agile methods 1. Customer satisfaction by rapid, continuous delivery of 1. In case of some software deliverables, especially the large
useful software. ones, it is difficult to assess the effort required at the
2. People and interactions are emphasized rather than beginning of the software development life cycle.
process and tools. Customers, developers and testers 2. There is lack of emphasis on necessary designing and
constantly interact with each other. documentation.
3. Working software is delivered frequently (weeks rather 3. The project can easily get taken off track if the customer
than months). representative is not clear what final outcome that they
4. Face-to-face conversation is the best form of want.
communication. 4. Only senior programmers are capable of taking the kind
5. Close, daily cooperation between business people and of decisions required during the development process.
developers. Hence it has no place for newbie programmers, unless
6. Continuous attention to technical excellence and good combined with experienced resources.
design.
7. Regular adaptation to changing circumstances.
8. Even late changes in requirements are welcomed