Software Development Processes
Software Development Life Cycle
SDLC aka. Software Development Process is a
process of understanding business needs by
designing an information system, building it, and
delivering it to users.
SDLC probably sounds pretty simple.
Unfortunately, it is not.
The SDLC gives organizations a framework to
develop successful software. From gathering the
initial requirements for a new product, through
maintaining a mature product.
Chea Daly SE 2
Software Development Life Cycle
The SDLC methodology is used by both large and
small software organizations.
SDLC specifies tasks to be performed at various
stages by a software engineer/developer. It ensures
that the end product is able to meet the customer’s
expectations and fits in the overall budget.
Chea Daly SE 3
Stages of SDLC
The SDLC’s stages cover the complete life cycle of a software.
Chea Daly SE 4
Software Development Life Cycle
Because the SDLC models require the development
team to complete each phase before moving on to the
next,
- It helps ensure problems do not become
compounded during the process.
- It helps teams identify and deal with problems
immediately.
- This minimizes their impact on both the cost of the
project and the quality of the final software
product.
Chea Daly SE 5
Software Process Models
There are different kinds of software process
models (or SDLC models):
• Waterfall
• Prototyping
• Incremental Development
• Time-boxing
• Spiral
• …
Chea Daly SE 6
Software Process Models
• There is no universal process model that is right
for all kinds of software development. The right
process depends on the customer and regulatory
requirements, the environment where the
software will be used, and the type of software
being developed.
Chea Daly SE 7
Waterfall Model
Chea Daly SE 8
Waterfall Model Phases
The waterfall system development process is a
sequential, multistage system development
process in which work on the next stage cannot
begin until the results of the current stage are
reviewed and approved or modified as
necessary.
Chea Daly SE 9
Waterfall Model Stages
Requirement Analysis: breaking a complex
topic into smaller parts.
Design: a process of problem-solving and
planning for a software solution.
Implementation/Coding: The process of
writing the source code
Testing: is conducted to get information about
the quality of the software under test.
Chea Daly SE 10
Waterfall Model Stages
Deployment: When the system meets approval
and is ready to “go live”, it is time to get it
deployed.
Maintenance: Systems evolve after
deployment, and they will be continuously
improved and changed as needed.
Chea Daly SE 11
Advantages
Simple and easy to understand
Easy to explain to the user
Phases are processed and completed one at a
time. Phases do not overlap. Which allows
maximum management control.
Chea Daly SE 12
Disadvantages
In practice, not all the requirements can be
received at once to properly design the system.
High amounts of risk and uncertainty.
Chea Daly SE 13
Waterfall Model Overall
The waterfall approach to system development
allows for a high degree of management control.
It is for this reason that this 50-year-old
approach is frequently followed when an
organization contracts with another to build its
information system, even though the other
models can be faster and can lead to higher
quality results.
Chea Daly SE 14
Waterfall Model Overall
However, a major problem with this approach is
that users do not interact with the solution until
the testing phase when the system is nearly
complete. This can lead to a mismatch between
system capabilities, users’ expectations, and
organizational needs.
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
Requirement stage.
Chea Daly SE 15
Waterfall Model Overall
Waterfall Model works well for smaller projects
where requirements are very well understood.
Poor model for long and ongoing projects.
Not a right process model in situations where
requirements change quickly or at a high risk of
changing.
Chea Daly SE 16
Prototyping Model
Requirements
Quick
Design
Refine Build
Requirements Prototype Design Code Test
Customer Product
Evaluation
Requirement Analysis
Chea Daly SE 17
Prototyping Model
Prototyping Model is a software development
model in which prototype is built, tested, and
reworked until an acceptable prototype is
achieved.
It also creates base to produce the final system
or software.
It works best in scenarios where the project’s
requirements are not known in detail.
Chea Daly SE 18
Advantages
Quicker user feedback is available leading to
better solutions
Errors can be detected much earlier.
Missing functionality can be identified easily
New requirements can be easily added.
Chea Daly SE 19
Disadvantages
Users may not use the prototype in the same
way as they use the final system.
Excessive development time of the prototype
Chea Daly SE 20
Incremental Development Model
... ...
A A A Feedback from iteration N
leads to refinement and
D D D adaptation of the
requirements and design
... ... in iteration N+1
C C C
T ... T ... T
The system grows
Product incrementally
Product
Product
4 weeks (for example)
Chea Daly SE 21
Advantages
It is easier to get customer feedback on the development work
that has been done. Customers can use the early increments as
prototypes and gain experience that informs their requirements
for later system increments. Customers find it difficult to judge
progress from software design documents or prototypes.
Customers do not have to wait until the entire system is
delivered before they can gain value from it. The first increment
satisfies their most critical requirements, so they can use the
software immediately.
It is easier to test and debug during a smaller iteration.
New functionality can be defined for later increments.
Chea Daly SE 22
Disadvantages
In the incremental approach, there is no complete system
specification until the final increment is specified. This
requires a new form of contract, which large customers
such as government agencies may find difficult to
accommodate.
System structure tends to degrade as new increments are
added. Regular change leads to messy code as new
functionality is added in whatever way is possible.
It becomes increasingly difficult and costly to add new
features to a system.
Total cost is higher than waterfall.
Chea Daly SE 23
Incremental Development Model
Overall
Incremental development is based on the idea of
developing an initial implementation, getting
feedback from users and others, and evolving the
software through several versions until the required
system has been developed.
Generally, the early increments of the system
include the most important or most urgently
required functionalities.
Chea Daly SE 24
Incremental Development Model
Overall
In an incremental delivery process, customers define
which of the services are most important and which
are least important to them.
This model can be used when major requirements of
the complete system are clearly defined and
understood; some details can evolve with time.
Once the system increments have been identified, the
requirements for the services to be delivered in the
first increment are defined in detail and that
increment is developed.
Chea Daly SE 25
Incremental Development Model
Overall
During development, further requirements analysis
for later increments can take place, but
requirements changes for the current increment are
not accepted.
Chea Daly SE 26
Time-boxing Model
Requirement Team
Requirement Requirement Requirement
TB 1 TB 2 TB 3
Design Team
Design Design Design
TB 1 TB 2 TB 3
Programming Team
Code Code Code
TB 1 TB 2 TB 3
Deployment Team
Deploy Deploy Deploy
TB 1 TB 2 TB 3
Time
Chea Daly SE 27
Advantages and Disadvantages
Advantages
Speeds up the development process and shortens the
delivery time.
Disadvantages
Project management becomes more complex.
Each iteration is done in a timebox of fixed duration
and run in parallel. However, to support parallel
execution, each iteration has to be structured
properly and teams have to be organized suitably.
Chea Daly SE 28
Time-boxing Model Overall
Time-boxing is well suited for projects that
requires a large number of features to be
developed in a short time.
Not suited to projects in which entire
development work cannot be divided into
multiple iterations of almost, equal duration.
Chea Daly SE 29
Spiral Model
Spiral Model starts with a small set of
requirement and goes through each development
phase.
The development team adds functionality for the
additional requirement in every-increasing
spirals until the application is ready for the
production.
Chea Daly SE 30
Spiral Model Process
Planning Risk Analysis
Evaluation Engineering
Chea Daly 31
Spiral Model Phases
A spiral model is divided into a four task regions:
Planning – to define resources, timelines, and
other project-related information. Output: Finalized
list of requirements.
Risk analysis – a process is undertaken to identify
risk and alternate solutions. Output: Document
which highlights all the risks and its mitigation
plans.
Chea Daly SE 32
Spiral Model Phases
Engineering – software is developed, along with
testing at the end of the phase. Output: Code, Test
cases and test results, Test summary report and
defect report.
Evaluation – This phase allows the customer to
evaluate the output of the project to date before the
project continues to the next spiral. Output:
Features implemented document.
Chea Daly SE 33
Advantages
High amount of risk analysis, so risk avoidance
is enhanced.
More able to cope with the changes.
Additional Functionality can be added at a later
date. lt.
Chea Daly SE 34
Disadvantages
Can be a costly model to use.
Risk analysis is important phase so requires
highly specific expertise.
Risk of not meeting budget or schedule
As the number of phases is unknown at the start
of the project, so time estimation and
management is very difficult.
Chea Daly SE 35
Spiral Model Overall
The model is recommended:
When risk evaluation is important
For medium to high-risk projects
When users are unsure of their needs
Requirements are complex and need evaluation to
get clarity.
Significant changes are expected in the product
during the development cycle.
Not suitable for small projects as it is expensive.
Chea Daly SE 36
References
1. Ian Sommerville ‘Software Engineering’, 10e – 2016
2. Roger S. Pressman ‘Software Engineering: a
practitioner’s approach’, 7e – 2010
3. ukessays.com
4. en.wikipedia.org
Chea Daly SE 37
