System

Development
Life Cycle
COSC70 – Software Engineering I
System Development Life Cycle
● SDLC is a process that consists of a series
of planned activities to develop or alter any
Software Products
● It is a conceptual model which includes
policies and procedures for developing
or altering systems throughout their life
cycles.
● It consists of a detailed plan describing
how to develop, maintain, replace and alter
or enhance specific software.
System Development Life Cycle
● The life cycle defines a methodology
for improving the quality of software
and the overall development process.
● This is used by systems analysts to
develop an information system.
SDLC Activities
 SDLC Activities
● SDLC is a systematic approach which explicitly breaks
down the work into phases that are required to implement
either new or modified Information System.
● This provides a series of steps to be followed to design
and develop a software product efficiently. The SDLC
framework includes the following steps:

○ Planning / Feasibility Study

○ Analysis and Specification

○ System Design

○ Implementation

○ Maintenance/Support
 Planning / Feasibility Study
● Define the problem and scope of existing system.
● Overview the new system and determine its
objectives.
● Confirm project feasibility and produce the project
Schedule.
● During this phase, we must consider threats,
constraints, integration and security of system
● A feasibility report for the entire project is created
at the end of this phase.
 Analysis and Specification
● Gather, analyze, and validate the information.
● Define the requirements and prototypes for new
system.
● Evaluate the alternatives and prioritize the
requirements.
● Examine the information needs of end-user and
enhances the system goal.
● A Software Requirement Specification (SRS)
document, which specifies the software, hardware,
functional, and network requirements of the system is
prepared at the end of this phase.
 System Design
● Includes the design of application, network,
databases, user interfaces, and system
interfaces.
● Transform the SRS document into logical
structure, which contains detailed and complete set
of specifications that can be implemented in a
programming language.
● Create a contingency, training, maintenance,
and operation plan.
● Review the proposed design. Ensure that the final
design must meet the requirements stated in SRS
document.
● Finally, prepare a design document which will be
used during next phases.
 Implementation
● Implement the design into source code through
coding.
● Combine all the modules together into training
environment that detects errors and defects.
● A test report which contains errors is prepared
through test plan that includes test related tasks
such as test case generation, testing criteria,
and resource allocation for testing.
● Integrate the information system into its
environment and install the new system.
 Maintenance/Support
● Include all the activities such as phone support or
physical on-site support for users that is required
once the system is installing.
● Implement the changes that software might undergo
over a period of time, or implement any new
requirements after the software is deployed at the
customer location.
● It also includes handling the residual errors and
resolve any issues that may exist in the system
even after the testing phase.
● Maintenance and support may be needed for a
longer time for large systems and for a short
time for smaller systems.
Software Development
Paradigm
 Software Development Paradigm
● The software development paradigm helps
developer to select a strategy to develop the
software.
● A software development paradigm has its own set of
tools, methods and procedures, which are expressed
clearly and defines software development life cycle.
● There are various software development life cycle
models defined and designed which are followed
during the software development process.
● Each process model follows a Series of steps unique
to its type to ensure success in the process of
software development.
 Waterfall Model
● The Waterfall model is the simplest model
of software development paradigm. Requirement
Analysis

● It says the all the phases of SDLC will

System Design
function one after another in a linear
manner. That is, when the first phase is Implementation

finished, then only the second phase will

Testing
start and so on.
● This model assumes that everything is Deployment

carried out and taken place perfectly Maintenance

as planned in the previous stage and

there is no need to think about the past
issues that may arise in the next phase.
 Waterfall Model
● This model does not work smoothly if
there are some issues left at the previous Requirement
Analysis

step. The sequential nature of model does

System Design
not allow us go back and undo or redo
our actions. Implementation

● This model is best suited when developers

Testing
already have designed and developed
similar software in the past and are aware Deployment

of all its domains. Maintenance

 Waterfall Model
● Some developers/researchers use a version of the waterfall model that allows them to return to a
previous step when they encounter an issue with their current action. This is what we call a
Modified Waterfall Model. They vary depending on the needs of the developer.

Requirement
Analysis Requirement
Analysis

System Design
System Design

Implementation
Implementation

Testing
Testing

Deployment
Deployment

Maintenance
Maintenance
 Iterative Model
● This model leads the software development
process in iterations. It projects the process of Initial
Planning

development in cyclic manner, repeating every

step after every cycle of SDLC process.
● The software is first developed on very small
scale and all the steps are followed which are
taken into consideration. Then, on every next
iteration, more features and modules are
designed, coded, tested and added to the Deployment

software.
● Every cycle produces a software, which is
Maintenance

complete in itself and has more features and

capabilities than that of the previous one.
 Iterative Model
● After each iteration, the management team can do
work on risk management and prepare for the Initial
Planning

next iteration.
● If there are issues, challenges or risks identified
during risk management, it can be patched out in
the next iteration of the project
● If all of the features of the desired software
product has been included in the next iteration, the
software will be prepared for deployment Deployment

after the implementation stage of the last

Maintenance
iteration.
 Iterative Model
● Because a cycle includes small portion of whole
software process, it is easier to manage the Initial
Planning

development process but it consumes more

resources, as defining iterations may require
redefinition of the complete system.
● Because the nature of development is in iterations,
the end of the project is unknown, which can be
an additional risk
● This model is better suited for large and mission- Deployment

critical projects
Maintenance
 Spiral Model Determine Identify and
Objectives Resolve Risks

● This Spiral model is a combination of iterative

Risk
development process model and sequential Test Plan
Analysis
Risk
linear development model (i.e. waterfall model) Review
Analysis
Development
Risk
with a very high emphasis on risk analysis, Plan
Analysis
nth
Requirements 2nd Prototype
which is often goes unnoticed by most SDLC Plan
Concept
1st
Prototype
Prototype

models. Concept of
of
Require-
Require- Detailed

● Operation ments
It allows incremental releases of the product or
ments Design
Draft

incremental refinement through each iteration

Development
Plan Verification and Integration
Validation

around the spiral. Test Plan

Verification and Test

● The spiral model has four phases. A software

Validation

project repeatedly passes through these phases in Deployment

Implementation

iterations called Spirals. Plan the Next

Iteration
Development
and Testing
 Spiral Model Determine Identify and
Objectives Resolve Risks

● The four phases of the spiral model are as follows:

Risk

○
Analysis

Determine Objectives Test Plan Risk

Analysis
Review
This phase starts with gathering the Development
Plan
Risk
Analysis
business requirements in the baseline Requirements
Plan
2nd
nth
Prototype
1st Prototype

spiral. In the subsequent spirals as the Concept

of
Prototype

product matures, identification of system Concept of Require-

Require- Detailed
Operation ments
ments Design
Draft

requirements, subsystem requirements and Development

Plan Verification and Integration

unit requirements are all done in this phase. Test Plan

Validation

Verification and Test

Validation

This phase also includes understanding the Implementation

Deployment
system requirements by continuous Plan the Next Development
communication between the customer Iteration and Testing

and the system analyst.

Spiral Model Determine Identify and
Objectives Resolve Risks

○ Identify and Resolve Risks Risk

Analysis

Risk Analysis includes identifying, Test Plan Risk

Analysis
Review
estimating and monitoring the technical Development
Plan
Risk
Analysis
feasibility and management risks, such Requirements
Plan
2nd
nth
Prototype
1st Prototype

as schedule slippage and cost overrun. Concept

of
Prototype

Concept of Require-
Require- Detailed
Operation ments
ments Design
Draft

After testing the build, at the end of first Development

Plan Verification and Integration

iteration, the customer evaluates the Test Plan

Validation

prototype software and provides feedback. Verification and

Validation
Test

Implementation
Deployment

Plan the Next Development

Iteration and Testing
Spiral Model Determine Identify and
Objectives Resolve Risks

○ Development and Testing Risk

Analysis

During this phase, the identified features are Test Plan Risk
Analysis
Review
developed and verified through testing. The Development
Plan
Risk
Analysis
actual software is produced based on the Requirements
Plan
2nd
nth
Prototype
1st Prototype

feedback from the customer Concept

of
Prototype

Concept of Require-
Require- Detailed
Operation ments
ments Design
Draft

In the subsequent spirals, the requirements Development

Plan Verification and Integration

and features of the software are modified to Test Plan

Validation

add more features Verification and

Validation
Test

Implementation
Deployment
At the end of this phase, the next version of Plan the Next Development
the software is available. Iteration and Testing
Spiral Model Determine Identify and
Objectives Resolve Risks

○ Plan the Next Iteration Risk

Analysis

In this phase, the Customers evaluate the Test Plan Risk

Analysis
Review
developed version of the software so far. Development
Plan
Risk
Analysis
nth
Requirements 2nd Prototype
Plan 1st Prototype

In the end, the planning for the next phase is Concept

of
Prototype

started. Concept of Require-

Require- Detailed
Operation ments
ments Design
Draft

Development
Plan Verification and Integration
Validation
Test Plan
Verification and Test
Validation

Implementation
Deployment

Plan the Next Development

Iteration and Testing
 Spiral Model Determine Identify and
Objectives Resolve Risks

● The spiral model can easily accommodate

Risk
changing requirements since each iteration must Test Plan
Analysis
Risk
have improvements over the other. This also allows Review
Analysis
Development
Risk
users to see the system early and have Plan
Analysis
nth
Requirements 2nd Prototype
expectations of what the outcome could do. Plan
Concept
1st
Prototype
Prototype

● Due to the nature of the spiral model, managing Concept of

of
Require-
ments
Require- Detailed
Operation
the project can be more complex since the
ments Design
Draft

requirement and the system itself is ever changing.

Development
Plan Verification and Integration
Validation

● This could also mean that the spiral may go on Test Plan
Verification and Test

indefinitely, since different feedback is taken into

Validation

consideration. This model is not suitable for small Deployment

Implementation

or low-risk projects. Plan the Next

Iteration
Development
and Testing
 V-Model
● The V-Model is an extension of the Requirement
Analysis
Acceptance
Testing
waterfall model and is based on the
association of a testing phase for each
System System

corresponding development stage. Analysis Testing

● This means that for every single phase in

the development cycle, there is a Architecture
Design
Integration
Testing

directly associated testing phase.

● This is a highly-disciplined model and the Module
Design
Unit Testing

next phase starts only after completion of

the previous phase. Coding

● It is also known as Verification and

Validation model.
 V-Model
● V- Model application is almost the same as Requirement
Analysis
Acceptance
Testing
the waterfall model, as both the models are
of sequential type.
System System

● There are no ambiguous or undefined Analysis Testing

requirements, and the project is expected

to be shorter, making it suitable for small Architecture
Design
Integration
Testing

projects.
● Requirements have to be very clear before Module
Design
Unit Testing

the project starts, because it is usually

expensive to go back and make changes. Coding

● This makes the model not flexible to

changes.
 V-Model
● Due to it’s sequential nature, this model is Requirement
Analysis
Acceptance
Testing
not good for complex and object-
oriented projects, especially for projects
System System

where requirements are at a moderate to Analysis Testing

high risk of changing.

● This model is used in the medical Architecture
Design
Integration
Testing

development field, as it is strictly a

disciplined domain. Module
Design
Unit Testing

Coding
 V-Model
● Due to it’s sequential nature, this model is Requirement
Analysis
Acceptance
Testing
not good for complex and object-
oriented projects, especially for projects
System System

where requirements are at a moderate to Analysis Testing

high risk of changing.

● Since the Verification and Validation phase Architecture
Design
Integration
Testing

intersects with the Coding phase, it is

difficult to go back and change a feature Module
Design
Unit Testing

once an application is in the testing stage

● This model is used in the medical Coding

development field, as it is strictly a

disciplined domain.
 Big Bang Model
● This is an SDLC model where we do not Time

follow any specific process.

● The development just starts with the
required money and efforts as the input, BIG
Efforts Software
and the output is the software developed BANG
which may or may not be as per
customer requirement.
● The Big Bang Model requires very little Resources
planning. Even the customer is not sure
about what exactly he/she wants and
the requirements are implemented on the
fly without much analysis.
 Big Bang Model
● The Big Bang model of software Time

development is designed around the notion

that, beginning with nothing, a rapid
growth and expansion of code will BIG
Efforts Software
quickly emerge, thus producing a BANG
finished product in a mere instant
● This also means that this model will
produce a very high risk and Resources
uncertainty due to the fact that almost
nothing are concrete.
● This model is used as a learning aid for new
comers or students, but not on complex or
object-oriented projects.