CSEB233 Fundamentals of

Software Engineering
Module 2: Software Processes

Badariah Solemon 2010

Objectives
• To describe types of process flows.
• To explain software process patterns.
• To identify several process assessment
and improvements frameworks
• To analyze prescriptive and specialized
software process models.
• To select a process model for software
development project.
• To determine task set for software
process activities.

Badariah Solemon 2010

 A Generic Process Model
• A software process:
 a collection of work activities, actions,
tasks, which are performed when
software is to be created.
• A process model or framework
 is where these activities, actions, and
tasks reside, and that defines their
relationship with the process and with
one another.
 Also known as an abstract
representation of a software process.

Badariah Solemon 2010

 A Generic Process Model (cnt’d)
• The technical work
hierarchy – activities
encompassing actions,
populated by tasks.
• Each action is defined by
a set of task that defines:
1. the actual work to be
completed,
2. the work products to be
produced,
3. the quality assurance
filters to be applied,
and
4. The milestones that will
be used to indicate the
project and product
progress.

Badariah Solemon 2010

 Process Activities:
Framework and Umbrella
• Framework activities :
o generic activities that are applicable to all
software projects, regardless of their size or
complexity.
o Include communication; planning; modeling,
construction; and deployment.
• Umbrella activities:
o complementary activities applied throughout a
software project and help manage and control
progress, quality, change, and risk.
o Include project tracking and control; risk
management; software quality assurance
(SQA); technical reviews; configuration
management (CM); etc.
Badariah Solemon 2010
 Process Flow
• Describes how the framework activities
and the actions and tasks that occur within
each activity are organized with respect to
sequence and time.
• The flows:
1. Linear – execute the framework activities in
sequence.
2. Iterative – repeats one or more of the
activities before proceeding to the next.
3. Evolutionary – execute the activities in a
‘circular’ manner.
4. Parallel – executes one or more activities
simultaneously with other activities.
Badariah Solemon 2010
Process Flow

Badariah Solemon 2010

 Process Patterns
• It would be useful if proven solution to the problems,
encountered as project team moves through a
software process, were readily available , which can
be reused in another project.
• In more general terms, a process pattern provides
you with a template [Amb98]—a consistent method
for describing problem solutions within the context of
the software process.
• A process pattern
• describes a process-related problem that is
encountered during software engineering work,
• identifies the environment in which the problem has
been encountered, and
• suggests one or more proven solutions to the
problem.
Badariah Solemon 2010
 Process Assessment and
Improvement
• Approaches:
1. Standard CMMI Assessment Method for Process Improvement
(SCAMPI) :
• Is used to identify strengths, weaknesses, and ratings relative to SEI CMMI
appraisal reference model, which is applicable to internal process
improvement and external capability determination.
2. CMM-Based Appraisal for Internal Process Improvement (CBA
IPI):
• provides a diagnostic technique for assessing the relative maturity of a
software organization; uses the SEI CMM as the basis for the assessment
[Dun01]. However, CMM has been retired by SEI since the introduction of
CMMI group of standards.
3. SPICE (ISO/IEC15504):
• standard that defines a set of requirements for software process
assessment. The intent of the standard is to assist organizations in
developing an objective evaluation of the efficacy of any defined software
process. [ISO08]
4. ISO 9001:2000 for Software:
• a generic standard that applies to any organization that wants to improve the
overall quality of the products, systems, or services that it provides.
Therefore, the standard is directly applicable to software organizations and
companies. [Ant06]
Badariah Solemon 2010
Prescriptive Process Models
• Promote an orderly, structured approach
to SE
• That leads to a few questions …
• If prescriptive process models strive for
structure and order, are they inappropriate for
a software world that thrives on change?
• Yet, if we reject traditional process models
(and the order they imply) and replace them
with something less structured, do we make it
impossible to achieve coordination and
coherence in software work?

Badariah Solemon 2010

 Prescriptive Process Models
(cnt’d)
• Waterfall Model – represents elements of a linear
process flow
• V
• Incremental Model – combines elements of linear
and parallel process flows
• Evolutionary Model – follows the evolutionary
process flow that combines elements of linear and
iterative process flows
• Prototyping
• Spiral
• Concurrent Model – combines elements of
iterative and parallel process flows

Badariah Solemon 2010

 The Waterfall Model
• Represents a linear process flow from communication
through deployment.
Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

* Also known as the classic SDLC

* The original Waterfall model proposed by Winston Royce in 1970 made
provision for feedback loops, but many organizations apply this model as
if it were strictly linear.
Badariah Solemon 2010
The V-Model
 A variation in the
representation of the
Waterfall model.
 Illustartes how V&V
actions are
associated with
earlier SE action.
 In reality, there is no
fundamentals
difference between
the Waterfall model
and the V-model.

Badariah Solemon 2010

 The Waterfall Model: An
Analysis
Characteristics Strengths Weaknesses Applicability
 It suggests a systematic,  Simple and easy to  Real projects rarely follow the  When requirements are
sequential approach to use/explain to customers. linear flow that the model well understood and
SE, staring from  proposes. Although iteration is unlikely to change
The staged development cycle
requirements indirectly allowed, changes are radically during system
enforces discipline: every
specification going costly, involve significant development (e.g.: in a
phase has a defined start and
through planning, rework and can cause confusion well-defined enhancement
end point, and progress can be
modeling, construction, to project team and involve. to an existing system).
conclusively identified
testing, deployment and  
(through the use of The model requires the When software
support of the
milestones) customer to state all development technologies
completed system.
requirements explicitly, which is and tools are well known.
 Each major activity is often very difficult to achieve.  The work tasks in the
marked by milestones  The working software will not project are to proceed to
and deliverables
available until late in the completion in a linear
(artifacts i.e.
project, which can be disastrous manner.
documents).
for late discovery of major
defects.
 Leads to “blocking states” in
which some project team
members must wait for others
to complete dependent tasks.

Badariah Solemon 2010

 The Incremental Model

increment #n
Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

delivery of
increment # 2 nth increment

Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
delivery of
increment # 1 2nd increment

Communic at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign c ode
delivery of
De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

1st increment

project calendar time

Badariah Solemon 2010

 The Incremental
Model (cnt’d)
 Rather than deliver the software product as a single
delivery, the development and delivery is broken down
into increments with each increment delivering part of
the required functionality.
 User requirements are prioritised and the highest priority
requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.

Badariah Solemon 2010

 The Incremental Model:
An Analysis

Ask the students to analyze this process model and to

discuss their findings in class.

Badariah Solemon 2010

The Evolutionary Model:
Prototyping
Quick plan
Quick
Communication plan
communication
Modeling
Modeling
Quick design
Quick design

Deployment
Deployment
Delivery
delivery &
& Feedback Construction
feedback Construction
of
of prototype
prototype

Badariah Solemon 2010

 The Evolutionary Model:
Prototyping (cnt’d)
 Using this process model, a prototype (an early
approximation of a final software product) is built, tested,
and then reworked as necessary until an acceptable
prototype is finally achieved from which the complete
software product can now be developed.
 Although it can be implemented as a stand-alone process
model, it is more commonly used as part of other process
models.
 The main purpose of the model is to help better
understand what it is to built when requirements are fuzzy.

Badariah Solemon 2010

 The Prototyping Model:
An Analysis

Ask the students to analyze this process model and to

discuss their findings in class.

Badariah Solemon 2010

 The Evolutionary Model:
Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test

Badariah Solemon 2010

 The Evolutionary Model:
Spiral (cnt’d)
 A process model that combines the iterative nature of
prototyping with the systematic aspects of waterfall
model.
 The spiral model can be thought of as a repeating
waterfall model that emphasizes risk assessment and
that is executed in an incremental fashion.
 Each loop/pass through the spiral model consists of
risk assessment and other framework activities from
communication through deployment.

Badariah Solemon 2010

 The Spiral Model:
An Analysis

Ask the students to analyze this process model and to

discuss their findings in class.

Badariah Solemon 2010

The Concurrent Process Model
none

Modeling activity

represents the state

Under of a software engineering
activity or task
development

Awaiting
changes

Under review

Under
revision

Baselined

Done

Badariah Solemon 2010

 The Concurrent Process
Model (cnt’d)
 A process model that combines the iterative and
parallel elements of any of the prescriptive process
models.
 In this process model, all SE activities (framework or
umbrella activities) exist concurrently but reside in
different states.

Badariah Solemon 2010

 The Concurrent Model: An
Analysis

Ask the students to analyze this process model and to

discuss their findings in class.

Badariah Solemon 2010

Specialised Process Models
• Component based software development (CBSD)
• the process to apply when reuse is a development
objective
• Formal methods
• emphasizes the mathematical specification of
requirements, which can demonstrate software
correctness but are not widely used.
• Aspect-oriented software development (AOSD)
• provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects
• Unified Process
• a “use-case driven, architecture-centric, iterative
and incremental” software process closely aligned
with the Unified Modeling Language (UML)
Badariah Solemon 2010
Specialised Process Models (cnt’d)
• Agile Process
• An iterative approach to requirements specification,
construction and deployment, which support rapid
changes to requirements.
• Personal Process Model
• Emphasizes the need to record and analyze errors each
individual practitioner made, so that he/she can develop a
strategy to eliminate them.
• Team Process Model
• Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPT) of three to about 20 engineers.
• Show managers how to coach and motivate their teams
and how to help them sustain peak performance.

Badariah Solemon 2010

Agile Development
• Combines a philosophy and a set of
development guidelines.
• The philosophy encourages:
 customer satisfaction and early incremental delivery
of software;
 small, highly motivated project teams;
 informal methods;
 minimal SE work products; and
 overall development simplicity.
• The development guidelines:
 stress delivery over analysis and design, and
 active and continuous communication between
developers and customers
Badariah Solemon 2010
The Agile Manifesto
1. Value individuals and interactions over process and
tools
2. Prefer to invest time in producing working software
rather than in producing comprehensive
documentation
3. Focus on customer collaboration rather than
contract negotiation
4. Concentrate on responding to change rather than
on creating a plan and then following it
• Why?
• The modern business environment is fast-paced and
ever-changing. This process model has been
demonstrated to deliver successful systems quickly.

Badariah Solemon 2010

 The Agile Principles
1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive
advantage.
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily
throughout the project.
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done.
6. The most efficient and effective method of conveying information
to and within a development team is face–to–face conversation.

Badariah Solemon 2010

 The Agile Principles (cnt’d)

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity – the art of maximizing the amount of work not
done – is essential.
11. The best architectures, requirements, and designs emerge
from self–organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
Badariah Solemon 2010
Agile: Human Factors
• the process molds to the needs of the people
and team, not the other way around
• key traits must exist among the people on an
agile team and the team itself:
 Competence.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.

Badariah Solemon 2010

 What is Agility
• Agile software engineering combines the
philosophy and a set of development
guidelines.
• It is a modern software process
• Agility is dynamic,content specific,
aggressively change and growth oriented.
• It emphasizes rapid delivery of operational
software.
• The philosophy encourages customer
satisfaction and early incremental delivery
of software.
• Small, Highly motivated project teams.
• Overall development simplicity.
• Active and continuous communication
between customer and developers.
• Customer is part of development team.
Eliminate “us and them” attitude
• Adaptability due to unpredictability.
 Who does it
• Software engineers and other project
stakeholders(managers,customers,enduser)
work together on an agile team.
• An agile team is self organised and in control of
its own destiny.
• Good communication and collaboration among
all.
• Agile software engineering is only for
certain classes of software projects.
• It delivers successful systems quickly.
• Framework activities remain but at
minimal.
• The final work product is a software
increment delivered on committed date
that satisfies the customer.
 Human Factors
• Competence-skill and knowledge
• Common focus-Goal
• Collaboration
• Decision making ability-Autonomy
• Fuzzy problem solving ability-Ambiguity
• Mutual trust and respect
• Self organization
The Agile Process Models
• Also known as approaches to agile software
engineering, which include:
• Extreme Programming (XP)
• Industrial XP
• Scrum
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSM)
• Crystal
• Feature Driven Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
Badariah Solemon 2010
 The Extreme Programming
(XP)
• The most widely used approach to agile SE.
spike solutions
simple design
prototypes
CRC cards
user stories
values
acceptance test criteria
iteration plan

refactoring

pair
programming

Release
software increment unit test
project velocity computed continuous integration

acceptance testing

Badariah Solemon 2010

 The XP: Activities

XP Planning
• Begins with the creation of “user stories”
• Agile team assesses each story and assigns a cost
• Split stories if necessary
• Stories are grouped to for a deliverable increment
• A commitment is made on delivery date
• High valued and riskiest stories implemented first
• After the first increment “project velocity” is used to
help define subsequent delivery dates for other
increments

Badariah Solemon 2010

 The XP: Activities (cnt’d)
XP Design
• Follows the KIS principle
• Encourage the use of CRC cards to organize classes.
• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal
program design
XP Coding
• Recommends the construction of a unit test for a store before
coding commences
• Encourages “pair programming”(Two heads are better than one
head)
XP Testing
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and executed to
assess customer visible functionality
Badariah Solemon 2010
 Selecting a Process Model
• Analyze the sidebars in pages 45 and 47.
• What are the lesson-learned from these
sidebars?

Badariah Solemon 2010

 Selecting a Process Model
• Factors to consider:
1. The characteristics of the problems to be solved.
• Such as complexity of the problem, etc
• E.g.: simple with clear, stable requirements, complex with
changing, unstable requirements, etc.
2. The characteristics of the project
• Such as the customers who have requested the product and the
people who will do the work, etc.
• E.g.: Uncertain requirements, breakthrough technology
3. The characteristics of the product.
• Such as quality attributes or metric of the product, product
domain, etc
4. The project environment in which the software
team works
• Such as political, cultural, language ,etc .

Badariah Solemon 2010

 Key Questions in
Determining Task Set

• Different projects requires different task sets. The tasks

should be selected based on problems and project
characteristics.
• Q: What actions are appropriate for a framework activity,
given:
 the nature of the problem to be solved;
 the characteristics of the people doing the work; and
 the stakeholders of the project?
• Q: What work tasks (task set) that these actions should
encompasses of?
Badariah Solemon 2010
 Example

• Nature of the problems and project :

 A small software project requested by one person (at a remote
location) with simple, straightforward requirements.
• Actions:
 Communication action: develop requirements
• Task set:
 Make contact with stakeholder via telephone.
 Discuss requirements and take notes.
 Organize notes into a brief written statement of requirements.
 E-mail to stakeholder for review and approval.
Badariah Solemon 2010
 Process Management Tools
• Also known as process modeling tools or
process technology.
• Allows a team to define and manage the
elements of a process model (activities, actions,
task, work products, milestones, and QA
points/filters).
• Such tools also provide detailed guidance on the
content of each process element.
• The tools may also provide standard project
management tasks such as estimating,
scheduling, tracking and control.
• Example:
• Igrafx Process Tools (www.micrografx.com)
Badariah Solemon 2010
 Selecting a Process
Model: an Exercise
• The project:
Assume that you are in charge of a project to create a
portal for the Shah Alam district of Selangor state. This
portal would include a homepage with links to a wide range
of discounted travel packages to major destinations in
Selangor, links to certain featured places like golf courses,
shopping complexes and places to eat, links to the detailed
map of Selangor, and links to news and events listing. It
also includes a bulletin board and chat room feature where
tourists (international and local tourists) can exchange
information. The portal should also provide Automated
Teller Machine (ATM) locator, timezone converter, and
currency converter.
•Select a software process model that you would
recommend to be implemented in the above mentioned
Badariah Solemon 2010
 Summary
• There are four types of process flows – linear,
iterative, evolutionary, and parallel.
• Software process patterns may suggest one or more
proven solutions to the problem from other projects,
which can be reused in another project.
• There are several process assessment and
improvements frameworks that can be exercised by
practitioners.
• The analyses of prescriptive and specialized software
process models would help you select the most
appropriate process model for a software
development project, which can be proceeded with
the identification of task set for the project.

Badariah Solemon 2010

 References and credit
Contents in the slides are adapted from the
book and the slides that accompanied the book
by R.S. Pressman, Software Engineering: A
Practitioner’s Approach, 7th. Edition, McGraw
Hill, 2009.

Badariah Solemon 2010