Module T02
Software Engineering
Software Processes
Compiled from multiple sources by
Mun’im Zabidi (munim@utm.my)
1
Software process
 A software process is the process by which user needs are
translated into a software product.
 A software process model is a simplified, abstracted
description of the software development process.
 Fundamental activities
› Software specification (Requirements)
› Software analysis & design
› Software implementation (Coding)
› Software validation (Testing)
› Software evolution (Maintenance)
2
Three major models
 Sequential
› Fundamental activities are represented as sequential activities
 Evolutionary
› Fundamental activities are interleaved.
› An initial system is rapidly developed from abstract specifications.
Then the initial system is refined by customer inputs to produce a
system that satisfies the customer’s needs.
 Agile
› Break product development work into small increments that minimize
the amount of up-front planning and design.
› Iterations are short time frames (timeboxes) that typically last from one
to four weeks
3
Sequential Models
“The best performance improvement is the
transition from the nonworking state to the
working state.”
— J. Osterhout
Code-and-Fix Model
 Some code is written and
fixed when it does not work
correctly
 No design, no
specifications
 Usually chosen by new
programming students
 Maintenance nightmare
 Unsatisfactory for software
of any reasonable size
Code
Fix
5
Code-and-Fix
Pros
Cons
When to Use
• Suitable for
experimentation and
learning
• Unsatisfactory for
software of any
reasonable size
• Learning programming
• For very small projects
6
Waterfall Model
7
Waterfall Model
• Sequential design
process
• Progress is seen as
flowing steadily
downwards (like a
waterfall)
Requirement
Analysis
Design
Implementation
Testing
8
Waterfall Model:
Requirements Engineering
A formal process that seeks to understand
the problem and document in detail what
the software system needs to do. This
phase involves close interaction between
users and designers.
Requirement
Analysis
Design
Coding
Most of the examples in this course are simple,
and their requirements are clearly stated. In
the real world, however, problems are not well
defined. You need to study a problem carefully
to identify its requirements.
Testing
9
Waterfall Model:
Analysis
The requirements are studied & clarified,
and overall solution determined.
Requirement
Analysis
Design
Coding
Each major subsystem is analyzed, and
components & interaction between
components are determined.
Testing
10
Waterfall Model:
Design
The process of designing the
system’s components.
Requirement
Analysis
Design
Coding
Design involves the use of many levels
of abstraction to decompose the
problem into manageable components,
identify classes and interfaces, and
establish relationships among the
classes and interfaces.
testing
11
Waterfall Model:
Coding
The process of translating the system
design into programs. Separate programs
are written for each component and put to
work together.
Requirement
Analysis
Design
Coding
This phase requires the use of a programming
language. The implementation involves coding,
testing, and debugging.
Testing
a.k.a. Implementation or Development phase.
12
Waterfall Model:
Testing
Ensures that the code meets the
requirements specification and weeds out
bugs.
Requirement
Analysis
Design
Coding
An independent team of software engineers
not involved in the design and implementation
of the project usually conducts such testing.
Testing
13
Waterfall Model:
Maintenance
Maintenance is concerned with
changing and improving the product.
Requirement
Design
Coding
After the software is deployed, it must
continue to perform and improve in a
changing environment. This requires
periodic upgrades of the product to fix newly
discovered bugs and incorporate changes.
Testing
Testing
Maintenance
14
Waterfall Model
Pros
•
•
•
•
Result is predictable
Easy to understand
Easy to manage
High quality
Cons
When to Use
• When staff is lacking
• Large number of
experience.
documents
• For projects where
• Product appears at
systems are wellthe end of the project
understood but still
• Difficult to respond to
complex.
changing
• When quality is more
requirements
important than cost and
schedule.
15
V Model
• Extension of the waterfall
model.
• Emphasis on testing
• Every phase in the
software development
cycle has a corresponding
phase in the testing cycle
• Tests are developed early
16
V-Model
Pros
Cons
When to Use
• Easy to understand and • Does not handle
• It suits projects with high
to use.
requirement changes.
reliability needs.
• The model involves
• Requirements are tested • Works well when the
testing early in the life
too late so the cost of
requirements are clear
cycle.
fixing issues related to
and well known.
• Stabilizes requirements
requirements is high.
because it is developed
up front like the waterfall
model.
17
Evolutionary
Development
“When to use iterative development? You
should use iterative development only on
projects that you want to succeed..”
— Martin Fowler
Evolutionary development
 The basic idea this approach is based on is:
› developing an initial implementation,
› exposing this to the user comments and
› refining it through many version until an adequate system has been
developed.
 Specification, development and validation are interleaved
rather than separate, with rapid feedback across activities.
 Approaches:
› Prototyping
› Incremental
› Spiral
19
Prototyping
Get user
feedback
Build
prototype
Requirement
Design



A prototype is built during the
requirements phase
The prototype allows the client to
interact and experiment with a
working representation of the
product.
The process only continues once
the client is satisfied with the
functioning of the prototype.
Coding
Testing
Maintenance
20
Prototyping Model
Pros
Cons
When to Use
•
•
•
•
•
•
•
Requirements are better
understood because of
interaction with the
customer.
Requirements change and
creep are easily handled.
Documentation focuses on
the end product not the
evolution of the product.
Risk control is provided.
Costs are limited by
understanding the
requirements before
committing resources.
•
•
•
It has a reputation of being
quick-and-dirty method
leading to product of poor
quality.
May suffer from poor
documentation.
The customer may expect
the end product to be of the
exact look and feel of the
prototype.
Without proper
management, the iterations
can go forever.
•
•
•
Very good for developing
user interfaces
Requirements are not well
known up front or unstable.
For proof of concepts
and demonstrations.
When developing a new
product.
21
Incremental/Staged Delivery
 Requirements are prioritized and then implemented in
groups.
 A partial implementation of a total system is implemented
and delivered to the user. The user gets to use the system
early.
 Then slowly add increased functionality
 Each subsequent release of the system adds functions to the
previous release, until all designed functionality has been
implemented
22
Incremental/Staged Delivery
Requirement
Analyze
Analyze
Analyze
Design
Design
Design
Code
Code
Code
Test
Test
Test
Version 1
Version 2
Version 3
23
Incremental/Staged Delivery
Pros
Cons
• Customers get important • Complete definition of
functionality early
the fully functional
• Develop high-risk or
system must be
major functions first
available early in the
• Each release delivers an
cycle to allow planning
operational product
the increments.
• Customer can respond
• Requires good planning
to each build
and design
• Lowers initial delivery
• Well-defined module
cost
interfaces are required
• Total cost of the
complete system is not
lower
When to Use
• Most of the
requirements are known
up-front but are
expected to evolve over
time
• A need to get basic
functionality early
• On long projects
• When risks are not high.
24
Spiral Model
 Important software projects have failed because project risks
were neglected & nobody was prepared when something
unforeseen happened.
 The spiral model introduces the consideration of risk in the
process.
› If risks cannot be controlled or resolved, the process is terminated.
› Applicable only to large scale systems because of the cost of
evaluating risk
 Software process is represented as a spiral with many loops
› Over each loop, one or more features of the product are elaborated
and analysed and risks at that point of time are identified and resolved
through prototyping
› Based on this, the identified features are implemented
25
Spiral Model

1st Quadrant:
›
The objectives are investigated,
elaborated and analysed
› Alternative solutions are proposed

2nd Quadrant:
›
Risks are also identified
› Alternative solutions are evaluated to
select best.

3rd Quadrant:
›

Developing and verifying the next
level of the product
4th Quadrant:
›
Reviewing the results of the stages
traversed so far with the customer.
› Planning the next iteration around
the spiral.
26
Risk
 A risk is something that may occur in the course of a
project, and which, under the worst outcome, would affect
it negatively and significantly [Braude 2001, Section 2.4].
 Two types:
› Those that can be avoided or worked around
› Those cannot be avoided
 Problems are those risks that have not been identified.
Risks must be managed!
 Risk retirement is process whereby risks are reduced or
eliminated.
27
27
Example Risks








Underestimation of size
Time lag in learning new tools
Lack of top management commitment
Personnel resign
Changing scope and/or objectives
Technical breakthroughs—change in product
Unrealistic schedule
Personnel lack required knowledge or skills
28
28
Spiral Model
Pros
Cons
When to Use
• Developing high risk
elements first reduces
expenses if project had
to be terminated.
• Early and frequent
feedback from users
• It promotes reuse and
increases productivity.
• Can be costly
• Does not work well for
small or low-risk projects
• Complex to understand.
• Risk expertise requires
highly specific expertise
• Spiral may continue
indefinitely
• When creation of a
prototype is appropriate
• When costs and risk
evaluation is important
• For medium to high-risk
projects
• Users are unsure of
their needs
• Requirements are
complex
• New product line
• If the product is complex
and/or critical (real-time,
military, health care,
space, ...)
29
Agile Methods
“There are two ways to write error-free
programs; only the third one works.”
— Alan J. Perlis
Agile Manifesto
 All Agile frameworks share a common philosophy
Individuals and Interactions
Working Software/Product
Customer Collaboration
Responding to Change
www.agilemanifesto.org
31
12 Principles of Agile
1.
2.
3.
4.
5.
Our highest priority is to satisfy the
customer through early and continuous
delivery of valuable software
Welcome changing requirements, even late
in development. Agile processes harness
change for the customer’s competitive
advantage
Deliver working software frequently, from a
couple of weeks to a couple of months, with
a preference to the shorter time scale
Business people and developers must
work together daily throughout the project
Build project around motivated individuals.
Give them the environment and support
they need, and trust them to get the job
done
6.
7.
8.
9.
10.
11.
12.
The most efficient and effective method of
conveying information to and within a team
is face-to-face conversation
Working software is the primary measure of
progress
Agile processes promote sustainable
development. The sponsors, developers,
and users should be able to maintain a
constant pace indefinitely
Continuous attention to technical excellence
and good design enhances quality
Simplicity – the art of maximizing the
amount of work not done – is essential
The best architectures, requirements, and
designs emerge from self-organizing teams
At regular intervals, the team reflects on
how to become more effective, then tunes
and adjusts its behavior accordingly
32
Agile



Group of software development
methods
Based on iterative and
incremental development
The Agile Manifesto in 2001:
Most important phrases
 Timeboxing
› A defined period of time
›
› self-organizing, cross-functional
teams
› adaptive planning,
› evolutionary development and
delivery,

›
› a time-boxed iterative approach,
›
› rapid and flexible response to
change.
›
Scrum and XP are just two of
many agile methods.
during which a task must be
accomplished
Development teams are
repeatedly tasked with
producing a releasable
improvement to software
within each timebox
Motivates team members to
complete work within the
timeboxes.
The result is an increase in
productivity.
Product Scope is adjusted to
fit schedule
33
What is Scrum?
 Scrum is an iterative framework for developing any product or
managing any work.
 Iterative and incremental
› Project progresses in series of short iterations
› Product increment delivered at end of each iteration
 Self organizing & cross-functional team
› Direction provided primarily at beginning and end of each iteration
› Team works collectively to plan and organize their work
 Very collaborative
› Makes everything highly visible through constant communication and
collaboration.
34
The work done in a day is
the Daily Sprint. Each day
there is a short Stand-Up
Meeting to keep the Sprint
on track
Requirements are
organized and
prioritized in the
product backlog.
The highest priority
requirements
become the sprint
backlog. The
development work
to satisfy the
requirement
becomes one
sprint.
Each sprint lasts
between 2 and 4
weeks.
Each Sprint results in a
release or delivery of key
functionality.
Of all the possible Agile frameworks used by companies, 66 percent are Scrum or Scrum variants.
35
Scrum Components
 Major components of Scrum
• Release
– Completion of a major
component of work.
– Consists of multiple iterations
– Release Preparation occurs
at the beginning of a release
• Iteration
– Time box (10-20 days)
– Completion of a small
increment of work
– Multiple iterations in a
release
36
Product Backlog
 Product Backlog is simply a
list of all things that needs to
be done within the project. It
replaces the traditional
requirements specification
artifacts.
 These items can have a
technical nature or can be
user-centric e.g. in the form of
User Stories.
37
User Story
 A way to capture a
description of a
software feature from
an enduser perspective.
 Describes the type
of user, what they want
and why.
 Helps to create a
simplified description of
a requirement.
38
Sprint
 In Scrum, work is confined to a regular, repeatable work
cycle, known as a sprint or iteration (timebox).
 Scrum sprints used to be 30 days long, but today many
teams prefer shorter sprints, such as one-week or two-week
sprints
39
Sprint Backlog


The sprint backlog is a list
of tasks identified by the
Scrum team to be
completed during the
Scrum sprint.
During the sprint planning
meeting, the team selects
some number of
product backlog items,
usually in the form of user
stories, and identifies the
tasks necessary to
complete each user story.
40
Daily Standup Meetings




In addition to the normal meetings,
Scrum is characterized by Daily
Standup Meetings.
The daily Scrum meeting is a short
everyday meeting, ideally during start of
the working day.
Meeting is conducted standing up.
During this meeting, each team member
should answer these 3 questions:
1. What did I accomplish yesterday?
2. What will I do today?
3. What obstacles are impeding my
progress?
41
Commonly Used Terms
Commonly Used Terms
Product
owner
Scrum
master
Scrum team
User story
Product
backlog
Sprint
Sprint
backlog
Sprint
planning
meeting
Daily standup
meeting
Sprint review
meeting
Team
retrospective
meeting
Burndown
chart
Impediments
http://www.parorrey.com/blog/projectmanagement/scrum-overview-commonly-used-terms/
42
Scrum Team
 A Scrum Team is a collection of individuals working together
to deliver the requested and committed product increments.
43
Scrum Master
 A scrum master is the facilitator for a product development
team that uses scrum. The scrum master manages the
process for how information is exchanged.
44
Sprint Planning Meeting
 The Sprint Planning Meeting is the first meeting to kick off
the sprint. It is attended by the ScrumMaster, Development
Team and the Product Owner, along with interested and
invited stakeholders.
45
Daily Standup, Sprint Review & Team
Retrospective Meetings
46
Burndown Charts
 A burn down chart is a graphical representation of work left to
do versus time. The outstanding work (or backlog) is often on
the vertical axis, with time along the horizontal. That is, it is a
run chart of outstanding work.
47
Scrum Pros/Cons
Pros
Cons
When to Use
•
•
•
•
•
•
•
Features are delivered
incrementally, allowing user
to benefit early
Testing is integrated
throughout the lifecycle, a
working product is always
available
User involvement helps to
identify any issues early
and make it easier to
respond to changes
Predictable cost and
schedule
•
•
Can be chaotic
Dependent on a good
scrum master to reconcile
priorities
Requires dedication of
team members
Slicing by “user stories”
isn’t always feasible
•
•
Requirements change
frequently, even from
month to month
Success is defined by
responsiveness to
customer requests
Incremental results (e.g., at
20% of scope) have
significant value
48
Extreme Programming (XP)
 Another agile method
 Based on delivery of very
small increments of
functionality
 Heavy emphasis on testing
 Characterized by pairwise
programming
› 2 people working side-by-side
on the same problem on the
same computer
› Essentially, all code is
reviewed as it is written
49
Why It’s Called Extreme
Good practices are
pushed to the extreme
Code reviews
Testing
review code all the time (pair programming)
everybody will test all the time (unit testing) even the
customers (functional testing)
make it part of everybody's daily business (refactoring)
always leave the system with the simplest design that
supports current functionality (simplest thing that could
possibly work)
everybody will work defining and refining the architecture
all the time (metaphor)
integrate and test several times a day (continuous
integration)
make iterations really short -- seconds, minutes, hours
not weeks, months, years (the planning game)
Design
Simplicity
Architecture
Integration testing
Short iterations
50
XP
Pros
Cons
When to Use
• Lightweight
• Suits small to medium
sized projects
• Produces good team
cohesion
• Test based approach
• Difficult to apply to large
projects where
documentation is
essential
• Needs experience and
skill, else it will revert to
code-and-fix
• Programming pairs is
costly
• Requirements are not
fully understood
• Budget is limited
51
DSDM
 An agile project delivery
framework, primarily
 DSDM fixes cost, quality
and time at the outset and
uses the MoSCoW
prioritization of scope
 Pareto principle
 M - MUST: Describes a requirement
that must be satisfied in the final
solution for the solution to be
considered a success.
 S - SHOULD: Represents a highpriority item that should be included in
the solution if it is possible. This is
often a critical requirement but one
which can be satisfied in other ways if
strictly necessary.
 C - COULD: Describes a requirement
which is considered desirable but not
necessary. This will be included if time
and resources permit.
 W - WOULD: Represents a
requirement that stakeholders have
agreed will not be implemented in a
given release, but may be considered
for the future.
52
Test-driven development (TDD)
 Relies on the repetition of
a very short development
cycle: first the developer
writes an (initially failing)
automated test case that
defines a desired
improvement or new
function, then produces
the minimum amount of
code to pass that test, and
finally refactors the new
code to acceptable
standards.
 Test-first programming
concept of extreme
programming in the
beginning
 Today standalone
methodology
53
Feature-driven development (FDD)
 Iterative and incremental
development process.
 An Agile method
 Driven from a clientvalued functionality
(feature) perspective
 Mostly part of other
methodologies
54
The Reality
Selection of a Process Model
 Each model has its own strengths and weaknesses
 Selection of a model is based on:
› The nature of the product
› The skills of the development team
› The organization
› The Users
 Each team must pick or customize a model to fit its project
 If there is no suitable model for a particular project, pick a
model that comes close and modify it for your needs.
 Best suggestion
› “Mix-and-match” life-cycle models
56
Selection of a Process Model
 Deploying an ERP
application, such as SAP.
› The vendor has done this
many times, has a process
with all steps clearly defined
and understood, and can
proceed with a well-practiced
waterfall process.
 Creating custom reports for
the ERP application.
› This is likely to be an iterative
process, as reports evolve
towards greater usefulness
over time due to user
feedback, and is well-suited
to a Scrum process.
 How about?
› Open-source software such
as Firefox, GIMP?
› Applications based on
commercial off the shelf
(COTS) such as Visual Basic
for Applications (VBA)
running inside Microsoft
Excel?
› Microsoft?
57
Choosing a Methodology
Useful in developing
systems
Waterfall
V-Model
Iterative
Prototyping
Spiral
Agile
With unclear user
requirements
Poor
Poor
Good
Excellent
Excellent
Excellent
With unfamiliar
technology
Poor
Poor
Good
Excellent
Excellent
Poor
That are complex
Good
Good
Good
Excellent
Excellent
Poor
That are reliable
Good
Excellent
Good
Excellent
Excellent
Good
With short time
schedule
Poor
Poor
Excellent
Good
Poor
Excellent
With schedule
visibility
Poor
Poor
Excellent
Good
Excellent
Good
58
Reading List
 Raymond, E. S., The Cathedral and the Bazaar: Musings on
Linux and Open Source by an Accidental Revolutionary ,
O'Reilly Media, 2001.
 Beck K.,Extreme Programming Explained: Embracing
Change, Addison–Wesley, 1999.
 Beck K., Cockburn A., Jeffries R., Highsmith J., “Agile
manifesto”, http://www.agilemanifesto.org, 2001, 12-4-2002.
 Boehm B., “A spiral model of software development and
enhancement”, IEEE Computer 21 (5) (1988) 61–72.
 Cusumano MA, “How Microsoft Builds Software,”, Comm
ACM, 40(6) (1997) 53-61.
59