SE Unit-2 SDLC and Process Models

SDLC(Software Development Life-cycle Model)

A software life cycle model (also termed process model) is a pictorial and diagrammatic
representation of the software life cycle. A life cycle model represents all the methods
required to make a software product transit through its life cycle stages. It also captures
the structure in which these methods are to be undertaken.A software life cycle model (also
termed process model) is a pictorial and diagrammatic representation of the software life
cycle. A life cycle model represents all the methods required to make a software product
transit through its life cycle stages. It also captures the structure in which these methods
are to be undertaken.

The stages of SDLC are as follows:

Stage1: Planning and requirement analysis

Business analyst and Project organizer set up a meeting with the client to gather all
the data like what the customer wants to build, who will be the end user, what is the
objective of the product. Before creating a product, a core understanding or
knowledge of the product is very necessary.

For Example, A client wants to have an application which concerns money

transactions. In this method, the requirement has to be precise like what kind of
operations will be done, how it will be done, in which currency it will be done, etc
Stage2: Defining Requirements

Once the requirement analysis is done, the next stage is to certainly represent and
document the software requirements and get them accepted from the project
stakeholders.

This is accomplished through "SRS"- Software Requirement Specification

document which contains all the product requirements to be constructed and
developed during the project life cycle.

Stage3: Designing the Software

The next phase is about to bring down all the knowledge of requirements, analysis,
and design of the software project. This phase is the product of the last two, like
inputs from the customer and requirement gathering.

Stage4: Developing the project

In this phase of SDLC, the actual development begins, and the programming is
built. The implementation of design begins concerning writing code. Developers
have to follow the coding guidelines described by their management and
programming tools like compilers, interpreters, debuggers, etc. are used to develop
and implement the code.

Stage5: Testing

After the code is generated, it is tested against the requirements to make sure that
the products are solving the needs addressed and gathered during the
requirements stage.

During this stage, unit testing, integration testing, system testing, acceptance
testing are done.

Stage6: Deployment

Once the software is certified, and no bugs or errors are stated, then it is deployed.

Then based on the assessment, the software may be released as it is or with

suggested enhancement in the object segment.

Stage7: Maintenance

Once when the client starts using the developed systems, then the real issues
come up and requirements to be solved from time to time.This procedure where the
care is taken for the developed product is known as maintenance.

SDLC Models
Software Development life cycle (SDLC) is a spiritual model used in project
management that defines the stages include in an information system development
project, from an initial feasibility study to the maintenance of the completed
application.

Waterfall Model

The waterfall is a universally accepted SDLC model. In this method, the whole
process of software development is divided into various phases.

The waterfall model is a continuous software development model in which

development is seen as flowing steadily downwards (like a waterfall) through the
steps of requirements analysis, design, implementation, testing (validation),
integration, and maintenance.

Linear ordering of activities has some significant consequences. First, to identify

the end of a phase and the beginning of the next, some certification techniques
have to be employed at the end of each step. Some verification and validation
usually do this mean that will ensure that the output of the stage is consistent with
its input (which is the output of the previous step), and that the output of the stage
is consistent with the overall requirements of the system.

RAD Model

RAD or Rapid Application Development process is an adoption of the waterfall

model; it targets developing software in a short period. The RAD model is based on
the concept that a better system can be developed in lesser time by using focus
groups to gather system requirements.

○ Business Modeling
○ Data Modeling
○ Process Modeling
○ Application Generation
○ Testing and Turnover

Incremental Model

The incremental model is not a separate model. It is necessarily a series of

waterfall cycles. The requirements are divided into groups at the start of the
project. For each group, the SDLC model is followed to develop software. The SDLC
process is repeated, with each release adding more functionality until all
requirements are met. In this method, each cycle act as the maintenance phase for
the previous software release. Modification to the incremental model allows
development cycles to overlap. After that subsequent cycle may begin before the
previous cycle is complete.
Agile Model

Agile methodology is a practice which promotes continues interaction of

development and testing during the SDLC process of any project. In the Agile
method, the entire project is divided into small incremental builds. All of these
builds are provided in iterations, and each iteration lasts from one to three weeks.

Any agile software phase is characterized in a manner that addresses several key
assumptions about the bulk of software projects:

1. It is difficult to think in advance which software requirements will persist and

which will change. It is equally difficult to predict how user priorities will
change as the project proceeds.
2. For many types of software, design and development are interleaved. That is,
both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to think about how much design is
necessary before construction is used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a
planning point of view) as we might like.

Prototype Model

The prototyping model starts with the requirements gathering. The developer and
the user meet and define the purpose of the software, identify the needs, etc.

A 'quick design' is then created. This design focuses on those aspects of the
software that will be visible to the user. It then leads to the development of a
prototype. The customer then checks the prototype, and any modifications or
changes that are needed are made to the prototype.

Looping takes place in this step, and better versions of the prototype are created.
These are continuously shown to the user so that any new changes can be updated
in the prototype. This process continue until the customer is satisfied with the
system. Once a user is satisfied, the prototype is converted to the actual system
with all considerations for quality and security.

How to Choose a Process Model?

Selection Process parameters plays an important role in software
development as it helps to choose the best suitable software life cycle
model. Following are the parameters which should be used to select a SDLC.
1. Requirements characteristics :
● Reliability of Requirements
● How often the requirements can change
● Types of requirements
● Number of requirements
● Can the requirements be defined at an early stage
● Requirements indicate the complexity of the system

2. Development team :
● Team size
● Experience of developers on similar type of projects
● Level of understanding of user requirements by the developers
● Environment
● Domain knowledge of developers
● Experience on technologies to be used
● Availability of training

3. User involvement in the project :

● Expertise of user in project
● Involvement of user in all phases of the project
● Experience of user in similar project in the past

4. Project type and associated risk :

● Stability of funds
● Tightness of project schedule
● Availability of resources
● Type of project
● Size of the project
● Expected duration for the completion of project
● Complexity of the project
● Level and the type of associated risk

What is a Defined Process?

A Defined process consists of a well-defined set of steps that need to be followed

for the goal to be achieved. A defined process produces the same outcome every
time and has low volatility which could be predicted. This makes the process of
planning easier as there are no changes that get along the way of
development.There is a command and control type of leadership seen in a defined
process where the project manager manages all the developers and orders them the
type of work they have to complete.

What is an Empirical Process?

The empirical process uses facts, previous experience, and evidence for
implementing any feature for the product. All of the features that go into the
product are discussed, analysed, inspected, and then adapted to the product.In an
empirical approach, the customer gets small updates for the product such as bug
fixes or new features which were once user stories in a regular period.

Defined Process Empirical Process

The process is planned in detail before The planning takes place as the team
the project begins. progresses with the project.

The project manager knows most of the Everyone involved in the project has an
information of the project. equal right to know about the details of
the project.

The entire project is completed within a The entire project is completed in short
single cycle which may take months. cycles where it is reviewed after each
cycle.

The developers are told how and what The developers are given an idea such
they have to create and there is no as a user story where they could employ
scope of creativity or freedom any techniques or software and deliver
the result according to their judgement

There is a command and control type of The Scrum or Agile team is self-
leadership among the manager and the organising and have the liberty to ask
developers. questions and share their opinions.

TRADITIONAL PROCESS MODELS

There is a variety of traditional systems development methodologies that can be

adopted within the organisation. They include waterfall, Spiral, V-Model, Rational
Unified Process (RUP) and Rapid Application Development.

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:

1. 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 analyzed based on their benefits and drawbacks, The best solution
is chosen and all the other phases are carried out as per this solution strategy.

2. 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 analyzed. 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 analyzed 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.
3. 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)

4. 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.

5. 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.
6. 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.
Incremental process model
The incremental process model is also known as the Successive version
model.
First, a simple working system implementing only a few basic features is built
and then that is delivered to the customer. Then thereafter many successive
iterations/ versions are implemented and delivered to the customer until the
desired system is released.

A, B, and C are modules of Software Products that are incrementally

developed and delivered.
Life cycle activities:
Requirements of Software are first broken down into several modules that can
be incrementally constructed and delivered. At any time, the plan is made just
for the next increment and not for any kind of long-term plan. Therefore, it is
easier to modify the version as per the need of the customer. The
Development Team first undertakes to develop core features (these do not
need services from other features) of the system.
Once the core features are fully developed, then these are refined to increase
levels of capabilities by adding new functions in Successive versions. Each
incremental version is usually developed using an iterative waterfall model of
development.
As each successive version of the software is constructed and delivered, now
the feedback of the Customer is to be taken and these were then incorporated
into the next version. Each version of the software has more additional
features than the previous ones.
Agile Manifesto
In February 2001, at the Snowbird resort in Utah, a team of 17 software developers
met to discuss lightweight development methods. The result of their meeting was
the following Agile Manifesto for software development:-

We are uncovering the better ways of developing software by doing it and helping
others to do it. Through this meeting, we have come to value -

○ Individuals and interactions over Processes and tools.

○ Working software over comprehensive documentation.
○ Customers are collaborating over contact negotiation.
○ Responding to change over following a plan.

So that, while there is value in the items on the right, we value the items on the left
more.
The Twelve Principle of Agile Manifesto
1. Customer Satisfaction: Manifesto provides high priority to satisfy the
customer's requirements. This is done through early and continuous delivery
of valuable software.
2. Welcome Change: Making changes during software development is common
and inevitable. Every changing requirement should be welcome, even in the
late development phase. Agile process works to increase the customers'
competitive advantage.
3. Deliver the Working Software: Deliver the working software frequently,
ranging from a few weeks to a few months with considering the shortest time
period.
4. Collaboration: Business people (Scrum Master and Project Owner) and
developers must work together during the entire life of a project development
phase.
5. Motivation: Projects should be build around motivated team members.
Provide such environment that supports individual team members and trust
them. It makes them feel responsible for getting the job done thoroughly.
6. Face-to-face Conversation: Face-to-face conversation betweenScrum Master
and development team and between the Scrum Master and customers for the
most efficient and effective method of conveying information to and within a
development team.
7. Measure the Progress as per the Working Software: The working software is
the key and primary measure of the progress.
8. Maintain Constant Pace: The aim of agile development is sustainable
development. All the businesses and users should be able to maintain a
constant pace with the project.
9. Monitoring: Pay regular attention to technical excellence and good design to
maximize agility.
10. Simplicity: Keep things simple and use simple terms to measure the work that
is not completed.
11. Self-organised Teams: The Agile team should be self-organized. They should
not be depending heavily on other teams because the best architectures,
requirements, and designs emerge from self-organized teams.
12. Review the Work Regularly: The work should be reviewed at regular intervals,
so that the team can reflect on how to become more productive and adjust its
behaviour accordingly.