The Software Development Life Cycle (SDLC) is a structured process for developing software that consists of multiple stages. The Waterfall model was the first process model introduced and consists of sequential phases where each phase must be completed before moving to the next. Iterative models develop software through repeated cycles, implementing portions of requirements at a time and incorporating feedback between cycles.

1. Software Development Life Cycle,
SDLC for short, is a well-defined,
structured sequence of stages in
software engineering to develop
the intended software product.
SDLC Activities
SDLC provides a series of steps to be followed
to design and develop a software product
efficiently. SDLC framework includes the
following steps:

2. THE
WATERFALL
MODEL

3. •The Waterfall Model was first Process Model to be introduced.
•It is 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 fully before the next phase can
begin.
•basically used for the for the project which is small and there are no
uncertain requirements.
•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.
•In this model the testing starts only after the development is complete.
•In waterfall model phases do not overlap.

5. Advantages of waterfall model:
1. This model is simple and easy to understand and
use.
2. Due to the rigidity of the model – each phase has
specific deliverables and a review process.
3. In this model phases are processed and
completed one at a time. Phases do not overlap.
4. Waterfall model works well for smaller projects
where requirements are very well understood.

6. Disadvantages of waterfall model:
1. Once an application is in the testing stage, it is very difficult to go
back and change something that was not well-thought out in the
concept stage.
2. working software is produced until late during the life cycle.
3. High amounts of risk and uncertainty.
4. Not a good model for complex and object-oriented 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.

7. When to use the waterfall model:
1. This model is used only when the requirements are very well known, clear and
fixed.
2. Product definition is stable.
3. Technology is understood.
4. There are no ambiguous requirements
5. Ample resources with required expertise are available freely.
6. The project is short.
7. Very less customer interaction is involved during the development of the
product.
Once the product is ready then only it can be demoed to the end users. Once
the product is developed and if any failure occurs then the cost of fixing such
issues are very high, because we need to update everywhere from document
till the logic.

8. 8
Code-and-fix model
code first
version
retirement
operations mode
modify until
client is satisfied

9. In the build and fix model (also referred to as an ad hoc model), the software is
developed without any specification or design.
An initial product is built, which is then repeatedly modified until it (software) satisfies
the user.
That is, the software is developed and delivered to the user. The user checks whether the
desired functions 'are present. If not, then the software is changed according to the
needs by adding, modifying or deleting functions.
This process goes on until the user feels that the software can be used productively.
However, the lack of design requirements and repeated modifications result in loss of
acceptability of software. Thus, software engineers are strongly discouraged from using
this development approach.

10. Advantages Disadvantages
1.Requires less experience to execute or
manage other than the ability to
program.
2.Suitable for smaller software.
3.Requires less project planning.
1.No real means is available of
assessing the progress, quality, and
risks.
2.Cost of using this process model is
high as it requires rework until user's
requirements are accomplished.
3.Informal design of the software as it
involves unplanned procedure.
4.Maintenance of these models is
problematic.
This model includes the following two phases.
•Build: In this phase, the software code is developed
and passed on to the next phase.
•Fix: In this phase, the code developed in the build
phase is made error free. Also, in addition to the
corrections to the code, the code is modified
according to the user's requirements.

11. THE
PROTOTYPING
MODEL

12. In this model, it is assumed that all the requirements may not be known at the start of
the development of the system.
It is usually used when a system does not exist or in case of a large and complex system.
This model allows the users to interact and experiment with a working model of the
system known as prototype. The prototype gives the user an actual feel of the system.
At any stage, if the user is not satisfied with the prototype, it can be discarded and an
entirely new system can be developed. Generally, prototype can be prepared by the
approaches listed below.
•By creating main user interfaces without any substantial coding so that users can get a
feel of how the actual system will appear.
•By abbreviating a version of the system that will perform limited subsets of functions

13. This prototype is developed based on the currently known requirements. Development of
the prototype obviously undergoes design, coding, and testing, but each of these phases is
not done very formally or thoroughly.
By using this prototype, the client can get an actual feel of the system, because the
interactions with the prototype can enable the client to better understand the requirements
of the desired system.
Prototyping is an attractive idea for complicated and large systems for which there is no
manual process or existing system to help determine the requirements.
Risks associated with the projects are being reduced through the use of prototyping.
The development of the prototype typically starts when the preliminary version of the
requirements specification document has been developed.
At this stage, there is a reasonable understanding of the system and its needs are unclear
or likely to change. After the prototype has been developed, the end users and clients
are given an opportunity to use the prototype.
They provide feedback to the developers regarding the prototype: what is correct, what
needs to be modified, what is missing, what is not needed, etc. Based on the feedback,
the prototype is modified to incorporate some of the suggested changes that can be
done easily, and then the users and the clients are again allowed to use the system.

14. 1. Requirements gathering and analysis: The user is interviewed in order to know the
requirements of the system.
2. Quick design: When requirements are known, a preliminary design or quick design for
the system is created. It is not a detailed design and includes only the important aspects
of the system, which gives an idea of the system to the user.
3. Build prototype: Information gathered from quick design is modified to form the first
prototype, which represents the working model of the required system.
4. User evaluation: thorough evaluation of the prototype to recognize its strengths and
weaknesses such as what is to be added or removed. Comments and suggestions are
collected from the users and provided to the developer.
5. Refining prototype: Once the user evaluates the prototype and if he is not satisfied,
the current prototype is refined according to the requirements. That is, a new prototype
is developed with the additional information provided by the user. The new prototype is
evaluated just like the previous prototype. This process continues until all the
requirements specified by the user are met. Once the user is satisfied with the
developed prototype, a final system is developed on the basis of the final prototype.

15. Advantages Disadvantages
•1. Provides a working model to the user early in
the process, enabling early assessment and
increasing user's confidence.
•2. The developer gains experience and insight by
developing a prototype there by resulting in better
implementation of requirements.
•3. The prototyping model serves to clarify
requirements, which are not clear, hence reducing
ambiguity and improving communication between
the developers and users.
•4. There is a great involvement of users in
software development. Hence, the requirements of
the users are met to the greatest extent.
•1. If the user is not satisfied by the developed
prototype, then a new prototype is developed. This
process goes on until a perfect prototype is
developed. Thus, this model is time consuming and
expensive.
•2. The developer loses focus of the real purpose of
prototype and hence, may compromise with the
quality of the software. For example, developers
may use some inefficient algorithms or
inappropriate programming languages while
developing the prototype.
•3. Prototyping can lead to false expectations. For
example, a situation may be created where the user
believes that the development of the system is
finished when it is not.
•4. The primary goal of prototyping is speedy
development, thus, the system design can suffer as
it is developed in series without considering
integration of all other components.

17. In Iterative model, iterative process starts with a simple implementation of a
small set of the software requirements and iteratively enhances the evolving
versions until the complete system is implemented and ready to be deployed. An
iterative life cycle model does not attempt to start with a full specification of
requirements. Instead, development begins by specifying and implementing just
part of the software, which is then reviewed in order to identify further
requirements. This process is then repeated, producing a new version of the
software at the end of each iteration of the model.
Iterative Model design
Iterative process starts with a simple implementation of a subset of the software
requirements and iteratively enhances the evolving versions until the full system
is implemented. At each iteration, design modifications are made and new
functional capabilities are added. The basic idea behind this method is to develop
a system through repeated cycles and in smaller portions at a time .
.

18. For example, word-processing software developed using the iterative paradigm might
deliver basis file management, editing, and document production functions in the first
increment; more sophisticated editing and document production capabilities in the
second increment; spelling and grammar checking in the third increment; and
advanced page layout capability in the fourth increment.

19. When an iterative-enhancement model is used, the first increment is often a core
product. That is, basic requirements are addressed, but many supplementary features
(some known, other unknown) remain undelivered. The core product is used by the
customer (or undergoes detailed review). As a result of use and/or evaluation, a plan
is developed for the next increment. The plan addresses the modification of the core
product to better meet the needs of the customer and the delivery of additional
features and functionality. This process is repeated following the delivery of each
increment, until the complete product is produced.

20. Advantages of Iterative-Enhancement Model
• The feedback from early increments improve the later stages.
•Users get benefits earlier than with a conventional approach.
• Early delivery of some useful components improves cash flow, because you get some
return on investment early on.
• Smaller sub-projects are easier to control and manage.
• The project can be temporarily abandoned if more urgent work crops up.
Disadvantages of Iterative-Enhancement Model
• Software breakage, that is, later increments may require modifications to earlier
increments.
• Programmers may be more productive working on one large system than on a series of
smaller ones.

22. In incremental model the whole requirement is divided into various builds. Multiple
development cycles take place here, making the life cycle a “multi-waterfall”
cycle. Cycles are divided up into smaller, more easily managed modules. Each module
passes through the requirements, design, implementation and testing phases. A working
version of software is produced during the first module, so you have working software
early on during the software life cycle. Each subsequent release of the module adds
function to the previous release. The process continues till the complete system is
achieved.
In the diagram above when we work incrementally we are adding piece by piece but expect
that each piece is fully finished. Thus keep on adding the pieces until it’s complete. As in the
image above a person has thought of the application. Then he started building it and in the
first iteration the first module of the application or product is totally ready and can be
demoed to the customers. Likewise in the second iteration the other module is ready and
integrated with the first module. Similarly, in the third iteration the whole product is ready
and integrated. Hence, the product got ready step by step.

23. Advantages of Incremental model:
Generates working software quickly and early during the software life cycle.
This model is more flexible – less costly to change scope and requirements.
It is easier to test and debug during a smaller iteration.
In this model customer can respond to each built.
Lowers initial delivery cost.
Easier to manage risk because risky pieces are identified and handled during it’d
iteration.
Disadvantages of Incremental model:
Needs good planning and design.
Needs a clear and complete definition of the whole system before it can be broken
down and built incrementally.
Total cost is higher than waterfall.

24. When to use the Incremental model:
•Major requirements must be defined; however, some details can
evolve with time.
•There is a need to get a product to the market early.
•A new technology is being used
•Resources with needed skill set are not available
•There are some high risk features and goals.

28. The spiral model is similar to the incremental model, with more emphasis 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.
Planning Phase: Requirements are gathered during the planning phase. Requirements
like ‘BRS’ that is ‘Bussiness Requirement Specifications’ and ‘SRS’ that is ‘System
Requirement specifications’.
Risk Analysis: 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. If any
risk is found during the risk analysis then alternate solutions are suggested and
implemented.
Engineering Phase: In this phase software is developed, along with testing at the end
of the phase. Hence in this phase the development and testing is done.
Evaluation phase: This phase allows the customer to evaluate the output of the project
to date before the project continues to the next spiral.

29. Spiral Model is very widely used in the software industry as it is in synch with the
natural development process of any product i.e. learning with maturity and also
involves minimum risk for the customer as well as the development firms.
Following are the typical uses of Spiral model:
•When costs there is a budget constraint and risk evaluation is important.
•For medium to high-risk projects.
•Long-term project commitment because of potential changes to economic priorities
as the requirements change with time.
•Customer is not sure of their requirements which is usually the case.
•Requirements are complex and need evaluation to get clarity.
•Significant changes are expected in the product during the development cycle.

30. Advantages of Spiral model:
High amount of risk analysis hence, avoidance of Risk is enhanced.
Good for large and mission-critical projects.
Strong approval and documentation control.
Additional Functionality can be added at a later date.
Software is produced early in the software life cycle.
Disadvantages of Spiral model:
Can be a costly model to use.
Risk analysis requires highly specific expertise.
Project’s success is highly dependent on the risk analysis phase.
Doesn’t work well for smaller projects.

31. COTS - commercial off-the-shelf

32. Short for commercial off-the-shelf, an adjective that describes software or
hardware products that are ready-made and available for sale to the
general public. For example, Microsoft Office is a COTS product that is a
packaged software solution for businesses. COTS products are designed to
be implemented easily into existing systems without the need for
customization.

33. The Agile Movement

37. What Is Agile?
Not a methodology! The Agile movement
seeks alternatives to traditional project
management.

38. Where Did Agile Come From?
•In 1970, Dr. Winston Royce presented a paper entitled “Managing the
Development of Large Software Systems,” which criticized sequential
development.
•He asserted that software should not be developed like an automobile on an
assembly line, in which each piece is added in sequential phases.
•In such sequential phases, every phase of the project must be completed before
the next phase can begin.
• Dr. Royce recommended against the phase based approach in which developers
first gather all of a project’s requirements, then complete all of its architecture
and design, then write all of the code, and so on

39. Why Agile?
Agile development methodology provides opportunities to assess the
direction of a project throughout the development lifecycle. This is achieved
through regular cadences of work, known as sprints or iterations, at the end of
which teams must present a potentially shippable product increment.
By focusing on the repetition of abbreviated work cycles as well as the
functional product they yield, agile methodology is described as “iterative”
and “incremental.”
In waterfall, development teams only have one chance to get each aspect of a
project right. In an agile paradigm, every aspect of development —
requirements, design, etc. — is continually revisited throughout the lifecycle.
When a team stops and re-evaluates the direction of a project every two
weeks, there’s always time to steer it in another direction.

40. And because a team’s work cycle is limited to two weeks, it gives stakeholders
recurring opportunities to calibrate releases for success in the real world.
Agile development methodology helps companies build the right product.
Instead of committing to market a piece of software that hasn’t even been written
yet, agile empowers teams to continuously replan their release to optimize its value
throughout development, allowing them to be as competitive as possible in the
marketplace.
Development using an agile methodology preserves a product’s critical market
relevance and ensures a team’s work doesn’t wind up on a shelf, never released.