GS SDLC Models (Watch it first)

• Basics: https://youtu.be/kSU2MPeptpM
• Classical Waterfall: https://youtu.be/noE3pnRzQGI
• Iterative Waterfall: https://youtu.be/vl-IWe0DkwU
• Prototyping Model: https://youtu.be/nNzH2rlEH6A
• Incremental Model: https://youtu.be/yd6uxnBIIQg
• Spiral Model: https://youtu.be/y2CnstDLhXM
• Agile Model: https://youtu.be/Xs6E-MAJbfE
• Comparison: https://youtu.be/ASrMUd0p9fE

Classical Waterfall Model

The classical waterfall model divides the life cycle into a set of phases. This model considers that one phase
can be started after the completion of the previous phase. That is the output of one phase will be the input
to the next phase. Thus, the development process can be considered as a sequential flow in the waterfall.
Here the phases do not overlap with each other. The different sequential phases of the classical waterfall
model are shown in the below figure:

Feasibility Study
The main goal of this phase is to determine whether it would be financially and technically feasible to
develop the software.
The feasibility study involves understanding the problem and then determining the various possible
strategies to solve the problem. These different identified solutions are analysed based on their benefits
and drawbacks, The best solution is chosen and all the other phases are carried out as per this solution
strategy.

Requirements analysis and specification

The aim of the requirement analysis and specification phase is to understand the exact requirements of the
customer and document them properly. This phase consists of two different activities.
Requirement gathering and analysis: Firstly, all the requirements regarding the software are gathered from
the customer and then the gathered requirements are analysed. The goal of the analysis part is to remove
incompleteness (an incomplete requirement is one in which some parts of the actual requirements have
been omitted) and inconsistencies (an inconsistent requirement is one in which some part of the
requirement contradicts some other part).

Requirement specification
These analysed requirements are documented in a software requirement specification (SRS) document.
SRS document serves as a contract between the development team and customers. Any future dispute
between the customers and the developers can be settled by examining the SRS document.

Design
The goal of this phase is to convert the requirements acquired in the SRS into a format that can be coded in
a programming language. It includes high-level and detailed design as well as the overall software
architecture. A Software Design Document is used to document all of this effort (SDD)

Coding and Unit testing

In the coding phase software design is translated into source code using any suitable programming
language. Thus, each designed module is coded. The aim of the unit testing phase is to check whether each
module is working properly or not.

Integration and System testing

Integration of different modules are undertaken soon after they have been coded and unit tested.
Integration of various modules is carried out incrementally over a number of steps. During each integration
step, previously planned modules are added to the partially integrated system and the resultant system is
tested. Finally, after all the modules have been successfully integrated and tested, the full working system
is obtained and system testing is carried out on this.
System testing consists of three different kinds of testing activities as described below:
Alpha testing: Alpha testing is the system testing performed by the development team.
Beta testing: Beta testing is the system testing performed by a friendly set of customers.
Acceptance testing: After the software has been delivered, the customer performed acceptance testing to
determine whether to accept the delivered software or reject it.

Maintenance
Maintenance is the most important phase of a software life cycle. The effort spent on maintenance is 60%
of the total effort spent to develop a full software. There are basically three types of maintenance:
Corrective Maintenance: This type of maintenance is carried out to correct errors that were not discovered
during the product development phase.
Perfective Maintenance: This type of maintenance is carried out to enhance the functionalities of the
system based on the customer’s request.
Adaptive Maintenance: Adaptive maintenance is usually required for porting the software to work in a new
environment such as working on a new computer platform or with a new operating system.

Advantages of Classical Waterfall Model

• This model is very simple and is easy to understand.

• Phases in this model are processed one at a time.
• Each stage in the model is clearly defined.
• This model has very clear and well-understood milestones.
• Process, actions and results are very well documented.
• Reinforces good habits: define-before- design, design-before-code.
• This model works well for smaller projects and projects where requirements are well understood.
Drawbacks of Classical Waterfall Model

• No feedback path: In the classical waterfall model evolution of software from one phase to another
phase is like a waterfall. It assumes that no error is ever committed by developers during any
phase. Therefore, it does not incorporate any mechanism for error correction.
• Difficult to accommodate change requests: This model assumes that all the customer requirements
can be completely and correctly defined at the beginning of the project, but actually customers’
requirements keep on changing with time. It is difficult to accommodate any change requests after
the requirements specification phase is complete.
• No overlapping of phases: This model recommends that a new phase can start only after the
completion of the previous phase. But in real projects, this can’t be maintained. To increase
efficiency and reduce cost, phases may overlap.

Iterative Waterfall Model

The iterative waterfall model provides feedback paths from every phase to its preceding phases, which is
the main difference from the classical waterfall model.
Feedback paths introduced by the iterative waterfall model are shown in the figure below.

When errors are detected at some later phase, these feedback paths allow correcting errors committed by
programmers during some phase. The feedback paths allow the phase to be reworked in which errors are
committed and these changes are reflected in the later phases. It is good to detect errors in the same
phase in which they are committed. It reduces the effort and time required to correct the errors.
Phase Containment of Errors
The principle of detecting errors as close to their points of commitment as possible is known as Phase
containment of errors.
Advantages of Iterative Waterfall Model

• Feedback Path – In the classical waterfall model, there are no feedback paths, so there is no
mechanism for error correction. But in the iterative waterfall model feedback path from one phase
to its preceding phase allows correcting the errors that are committed and these changes are
reflected in the later phases.
• Simple – Iterative waterfall model is very simple to understand and use. That’s why it is one of the
most widely used software development models.
• Cost-Effective – It is highly cost-effective to change the plan or requirements in the model.
Moreover, it is best suited for agile organizations.
• Well-organized – In this model, less time is consumed on documenting and the team can spend
more time on development and designing.

Drawbacks of Iterative Waterfall Model

• Difficult to incorporate change requests – The major drawback of the iterative waterfall model is
that all the requirements must be clearly stated before starting the development phase. Customers
may change requirements after some time but the iterative waterfall model does not leave any
scope to incorporate change requests that are made after the development phase starts.
• Incremental delivery not supported – In the iterative waterfall model, the full software is
completely developed and tested before delivery to the customer. There is no scope for any
intermediate delivery. So, customers have to wait a long for getting the software.
• Overlapping of phases not supported – Iterative waterfall model assumes that one phase can start
after completion of the previous phase, but in real projects, phases may overlap to reduce the
effort and time needed to complete the project.
• Risk handling not supported – Projects may suffer from various types of risks. But the Iterative
waterfall model has no mechanism for risk handling.
• Limited customer interactions – Customer interaction occurs at the start of the project at the time
of requirement gathering and at project completion at the time of software delivery. These fewer
interactions with the customers may lead to many problems as the finally developed software may
differ from the customers’ actual requirements.

V Model
The V-model is a type of SDLC model where process executes in a sequential manner in V-shape. It is also
known as Verification and Validation model. It is based on the association of a testing phase for each
corresponding development stage. Development of each step directly associated with the testing phase.
The next phase starts only after completion of the previous phase i.e. for each development activity, there
is a testing activity corresponding to it.
Verification: It involves static analysis technique (review) done without executing code. It is the process of
evaluation of the product development phase to find whether specified requirements meet.
Validation: It involves dynamic analysis technique (functional, non-functional), testing done by executing
code. Validation is the process to evaluate the software after the completion of the development phase to
determine whether software meets the customer expectations and requirements
When to use V Model

• Natural choice for systems requiring high reliability: Embedded control applications, safety-
critical software
• All requirements are known up-front
• Solution and technology are known
Advantages:

• This is a highly disciplined model and Phases are completed one at a time.
• V-Model is used for small projects where project requirements are clear.
• Simple and easy to understand and use.
• This model focuses on verification and validation activities early in the life cycle thereby enhancing
the probability of building an error-free and good quality product.
• It enables project management to track progress accurately.
Disadvantages:

• High risk and uncertainty.

• It is not a good for complex and object-oriented projects.
• It is not suitable for projects where requirements are not clear and contains high risk of changing.
• This model does not support iteration of phases.
• It does not easily handle concurrent events.

Prototyping Model
Advantages

• The resulting software is usually more usable

• User needs are better accommodated
• The design is of higher quality
• The resulting software is easier to maintain
• Overall, the development incurs less cost
Disadvantages

• For some projects, it is expensive

• Susceptible to over-engineering – Designers start to incorporate sophistications that they could not
incorporate in the prototype.
Use
The Prototyping Model should be used when the requirements of the product are not clearly understood
or are unstable. It can also be used if requirements are changing quickly. This model can be successfully
used for developing user interfaces, high technology software-intensive systems, and systems with
complex algorithms and interfaces. It is also a very good choice to demonstrate the technical feasibility of
the product.

Incremental Model
The basic idea… take advantage of what was being learned during the development of earlier, incremental,
deliverable versions of the system. Learning comes from both the development and use of the system…
Start with a simple implementation of a subset of the software requirements and iteratively enhance the
evolving sequence of versions. At each version design modifications are made along with adding new
functional capabilities.
Key characteristics

• Builds system incrementally

• Consists of a planned number of iterations
• Each iteration produces a working program
Benefits

• Facilitates and manages changes

Foundation of agile techniques and the basis for

• Rational Unified Process (RUP)

• Extreme Programming (XP)

Evolutionary Model with Iterations

• Outcome of each iteration: tested, integrated, executable system
• Iteration length is short and fixed Usually between 2 and 6 weeks
• Development takes many iterations (for example: 10-15)
• Does not “freeze” requirements and then conservatively design

Advantages

• Users get a chance to experiment with a partially developed system: Much before the full working
version is released
• Helps finding exact user requirements: Software more likely to meet exact user requirements.
• Core modules get tested thoroughly: Reduces chances of errors in final delivered software.
• Better management of complexity by developing one increment at a time.
 • Better management of changing requirements.
• Can get customer feedback and incorporate them much more efficiently: As compared when
customer feedbacks come only after the development work is complete.
• Training can start on an earlier release: customer feedback taken into account
• Frequent releases allow developers to fix unanticipated problems quicker.
Disadvantages

• The process is intangible: No regular, well-defined deliverables.

• The process is unpredictable: Hard to manage, e.g., scheduling, workforce allocation, etc.
• Systems are rather poorly structured: Continual, unpredictable changes tend to degrade the
software structure.
• Systems may not even converge to a final version.

Spiral Model

• Each loop of the spiral represents a phase of the software process:

o the innermost loop might be concerned with system feasibility,
o the next loop with system requirements definition,
o the next one with system design, and so on.
• There are no fixed phases in this model, the phases shown in the figure are just examples.
• The team must decide: how to structure the project into phases.
• Each loop in the spiral is split into four sectors (quadrants).

Quadrant 1 (Objective Setting)

• Identify objectives of the phase

• Examine the risks associated with these objectives.
• Risk: Any adverse circumstance that might hamper successful completion of a software project.
• Find alternate solutions possible.
Quadrant 2 (Risk Assessment and Reduction)

• For each identified project risk, a detailed analysis is carried out.

• Steps are taken to reduce the risk.
• For example, if there is a risk that requirements are inappropriate: A prototype system may be
developed.
Quadrant 3 (Development and Validation)

• develop and validate the next level of the product.

Quadrant 4 (Review and Planning)

• review the results achieved so far with the customer and plan the next iteration around the spiral.
• With each iteration around the spiral: progressively more complete version of the software gets
built.

RAD Model (Rapid Prototyping)

Major aims

• Decrease the time taken and the cost incurred to develop software systems.
• Facilitate accommodating change requests as early as possible: Before large investments have been
made in development and testing.
• A way to reduce development time and cost, and yet have flexibility to incorporate changes: Make
only short-term plans and make heavy reuse of existing code.
Methodology

• Plans are made for one increment at a time. The time planned for each iteration is called a time
box.
• Each iteration (increment): Enhances the implemented functionality of the application a little.
• During each iteration,
o A quick-and-dirty prototype-style software for some selected functionality is developed.
o The customer evaluates the prototype and gives his feedback.
o The prototype is refined based on the customer feedback.
When to use?

• Customized product developed for one or two customers only

• Performance and reliability are not critical.
• The system can be split into several independent modules.
When not to use?

• Few plug-in components are available

• High performance or reliability required
• No precedence for similar products exists
• The system cannot be modularized.
Unified Process

Inception

• Communication and planning are main.

• Identifies Scope of the project using use-case model allowing managers to estimate costs and time
required.
• Customers’ requirements are identified and then it becomes easy to make a plan of the project.
• Project plan, Project goal, risks, use-case model, Project description, are made.
• Project is checked against the milestone criteria and if it couldn’t pass these criteria then project
can be either cancelled or redesigned.
Elaboration

• Planning and modelling are main.

• Detailed evaluation, development plan is carried out and diminish the risks.
• Revise or redefine use-case model (approx. 80%), business case, risks.
• Again, checked against milestone criteria and if it couldn’t pass these criteria then again project can
be cancelled or redesigned.
• Executable architecture baseline.
Construction

• Project is developed and completed.

• System or source code is created and then testing is done.
• Coding takes place.
Transition

• Final project is released to public.

• Transit the project from development into production.
• Update project documentation.
• Beta testing is conducted.
• Defects are removed from project based on feedback from public.

Agile Model
• The requirements are decomposed into many small incremental parts that can be developed over
one to four weeks each.
• Face-to-face communication favoured over written documents.
• Frequent delivery of versions --- once every few weeks.
• Requirements change requests are easily accommodated.
• Close cooperation between customers and developers.
• Face-to-face communication among team members.
Agile Methodologies

• XP
• Scrum
• Unified process
• Crystal
• DSDM
• Lean
Short comings

• Can be misinterpreted…
• External review difficult to get…
• When project is complete, and team disperses, maintenance becomes difficult…

Extreme Programming (XP)

• Recommends taking the best practices to extreme levels.
• If something is good, why not do it all the time.
• Based on user story develop test cases
• Implement a quick and dirty feature every couple of days:
o Get customer feedback
o Alter if necessary
o Refactor
o Take up next feature
• If code review is good: Always review --- pair programming
• If testing is good: Continually write and execute test cases --- test-driven development
• If incremental development is good: Come up with new increments every few days
 • If simplicity is good: Create the simplest design that will support only the currently required
functionality.
• If design is good, everybody will design daily (refactoring)
• If architecture is important, everybody will work at defining and refining the architecture
(metaphor)
• If integration testing is important, build and integrate test several times a day (continuous
integration)

XP Practices

• Planning – determine scope of the next release by combining business priorities and technical
estimates
• Small releases – put a simple system into production, then release new versions in very short cycles
• Metaphor – all development is guided by a simple shared story of how the whole system works
• Simple design – system is to be designed as simple as possible
• Testing – programmers continuously write and execute unit tests
• Refactoring – programmers continuously restructure the system without changing its behaviour to
remove duplication and simplify
• Pair-programming -- all production code is written with two programmers at one machine
• Collective ownership – anyone can change any code anywhere in the system at any time.
• Continuous integration – integrate and build the system many times a day – every time a task is
completed.
• 40-hour week – work no more than 40 hours a week as a rule
• On-site customer – a user is a part of the team and available full- time to answer questions
• Coding standards – programmers write all code in accordance with rules emphasizing
communication through the code
When to use?

• Projects involving new technology or research projects. In this case, the requirements change
rapidly and unforeseen technical problems need to be resolved.
• Small projects: These are easily developed using extreme programming.

Scrum
• Self-organizing teams
• Product progresses in a series of month-long sprints
• Requirements are captured as items in a list of product backlog
• Scrum projects progress in a series of “sprints”, Target duration is one month
• Software increment is designed, coded, and tested during the sprint
• No changes entertained during a sprint
Roles
• Product Owner
o Acts on behalf of customers to represent their interests.
o Defines the features of the product
o Decide on release date and content
o Prioritize features according to market value
o Adjust features and priority every iteration, as needed
o Accept or reject work results.
• Development Team
o Team of five-nine peoples with cross-functional skill sets.
▪ QA, Programmers, UI Designers, etc.
o Teams are self-organizing
o Membership can change only between sprints
• Scrum Master (aka Project Manager)
o Facilitates scrum process and resolves impediments at the team and organization level by
acting as a buffer between the team and outside interference.
o Represents management to the project
o Removes impediments
o Ensure that the team is fully functional and productive
o Enable close cooperation across all roles and functions
o Shield the team from external interferences

Ceremonies
• Sprint Planning Meeting
o Goal is to produce Sprint Backlog
o Product owner works with the Team to negotiate what Backlog Items the Team will work on
in order to meet Release Goals
o Scrum Master ensures Team agrees to realistic goals
• Sprint
o A month-long iteration, during which an incremental product functionality completed
o NO outside influence can interfere with the Scrum team during the Sprint
o Each day begins with the Daily Scrum Meeting
• Daily Scrum
o Daily
o 15-minutes
o Stand-up meeting
o Not for problem solving
o Three questions:
▪ What did you do yesterday?
 ▪ What will you do today?
▪ What obstacles are in your way?
o Is NOT a way to collect information about WHO is behind the schedule
o Is a meeting in which team members make commitments to each other and to the Scrum
Master?
o Is a good way for a Scrum Master to track the progress of the Team
• Sprint Review Meeting
o Team presents what it accomplished during the sprint
o Typically takes the form of a demo of new features
o Informal, 2-hour prep time rule
o Participants
▪ Customers
▪ Management
▪ Product Owner
▪ Other engineers

Artifacts
• Product Backlog
o A list of all desired work on the project, usually a combination of
▪ story-based work (“let user search and replace”)
▪ task-based work (“improve exception handling”)
o List is prioritized by the Product Owner
o Usually is created during the Sprint Planning Meeting
• Sprint Backlog
o A subset of Product Backlog Items, which define the work for a Sprint
o Created by Team members
o Each Item has its own status
o Updated daily
• Burn down Charts
o Are used to represent “work done”.
o Are remarkably simple but effective Information disseminators
o 3 Types:
▪ Sprint Burn down Chart (progress of the Sprint)
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of the Sprint
• Actually, is not a straight line
▪ Release Burn down Chart (progress of release)
• Will the final release be done on right time?
• How many more sprints?
• X-axis: sprints
• Y-axis: amount of story points remaining
▪ Product Burn down chart (progress of the Product)
• Is a “big picture” view of project’s progress (all the releases)
Kanban
A Kanban board is one of the tools that can be used to implement Kanban to manage work at a personal or
organizational level. Kanban boards visually depict work at various stages of a process using cards to
represent work items and columns to represent each stage of the process.

Comparison Between All Process Models

Classical Waterfall Model: The Classical Waterfall model can be considered as the basic model and all
other life cycle models are based on this model. It is an ideal model. However, the Classical Waterfall
model cannot be used in practical project development, since this model does not support any mechanism
to correct the errors that are committed during any of the phases but detected at a later phase. This
problem is overcome by the Iterative Waterfall model through the inclusion of feedback paths.
Iterative Waterfall Model: The Iterative Waterfall model is probably the most used software development
model. This model is simple to use and understand. But this model is suitable only for well-understood
problems and is not suitable for the development of very large projects and projects that suffer from a
large number of risks.
Prototyping Model: The Prototyping model is suitable for projects, which either the customer
requirements or the technical solutions are not well understood. These risks must be identified before the
project starts. This model is especially popular for the development of the user interface part of the
project.
Evolutionary Model: The Evolutionary model is suitable for large projects which can be decomposed into a
set of modules for incremental development and delivery. This model is widely used in object-oriented
development projects. This model is only used if incremental delivery of the system is acceptable to the
customer.
Spiral Model: The Spiral model is considered as a meta-model as it includes all other life cycle models.
Flexibility and risk handling are the main characteristics of this model. The spiral model is suitable for the
development of technically challenging and large software that is prone to various risks that are difficult to
anticipate at the start of the project. But this model is more complex than the other models.
Agile Model: The Agile model was designed to incorporate change requests quickly. In this model,
requirements are decomposed into small parts that can be incrementally developed. But the main
principle of the Agile model is to deliver an increment to the customer after each Time-box. The end date
of an iteration is fixed, it can’t be extended. This agility is achieved by removing unnecessary activities that
waste time and effort.

Selection of appropriate life cycle model for a project: Selection of proper lifecycle model to complete a
project is the most important task. It can be selected by keeping the advantages and disadvantages of
various models in mind. The different issues that are analysed before selecting a suitable life cycle model
are given below:

• Characteristics of the software to be developed: The choice of the life cycle model largely depends
on the type of the software that is being developed. For small services projects, the agile model is
favoured. On the other hand, for product and embedded development, the Iterative Waterfall
model can be preferred. The evolutionary model is suitable to develop an object-oriented project.
User interface part of the project is mainly developed through prototyping model.
• Characteristics of the development team: Team member’s skill level is an important factor to
deciding the life cycle model to use. If the development team is experienced in developing similar
software, then even an embedded software can be developed using the Iterative Waterfall model.
If the development team is entirely novice, then even a simple data processing application may
require a prototyping model.
• Risk associated with the project: If the risks are few and can be anticipated at the start of the
project, then prototyping model is useful. If the risks are difficult to determine at the beginning of
the project but are likely to increase as the development proceeds, then the spiral model is the best
model to use.
• Characteristics of the customer: If the customer is not quite familiar with computers, then the
requirements are likely to change frequently as it would be difficult to form complete, consistent
and unambiguous requirements. Thus, a prototyping model may be necessary to reduce later
change requests from the customers. Initially, the customer’s confidence is high on the
development team. During the lengthy development process, customer confidence normally drops
off as no working software is yet visible. So, the evolutionary model is useful as the customer can
experience a partially working software much earlier than whole complete software. Another
advantage of the evolutionary model is that it reduces the customer’s trauma of getting used to an
entirely new system.