Software Processes

Lecture 3
 Topics covered
• Software process models
• Process activities, advantage and disadvantage
• Coping with change
• The Rational Unified Process
– An example of a modern software process.

2
 Software Process Models

• A structured set of activities required to develop a software system.

• Many different software processes but all involve:

– Specification – defining what the system should do;

– Design and implementation – defining the organization of the system and
implementing the system;
– Validation – checking that it does what the customer wants;
– Evolution – changing the system in response to changing customer needs.

3
A Generic Process
Model

4
Process Flow

5
 Identifying a Task Set
• A task set defines the actual work to be done to accomplish
the objectives of a software engineering action.
– A list of the task to be accomplished
– A list of the work products to be produced
– A list of the quality assurance filters to be applied

6
 Process Patterns
• 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.
• Stated 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.

7
 Process Pattern Types
• Stage patterns—defines a problem associated with a
framework activity for the process.
• Task patterns—defines a problem associated with a
software engineering action or work task and
relevant to successful software engineering practice
• Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature.

8
 Process Assessment and
Improvement
• Standard CMMI Assessment Method for Process Improvement
(SCAMPI) — provides a five step process assessment model
that incorporates five phases: initiating, diagnosing,
establishing, acting and learning.
• 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]
• SPICE—The SPICE (ISO/IEC15504) standard 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]
• 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 to9
Prescriptive Models
• Prescriptive process models advocate an orderly approach to
software engineering
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?

10
The Waterfall
Model
Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback

11
The Waterfall Model

• Sometimes called classic life cycle

• Suggests a systematic sequential approach to
software development
• Begins with customer specification of
requirements and progresses through planning,
modelling, construction and deployment
• Serves as a useful process model where
requirements are fixed and work is to proceed in
a linear manner

12
The V-Model

13
 The V-Model Cont.

• A variation of in the representation of the waterfall model is called

the V-model
• Depicts the relationship of quality assurance actions associated
with communication, modeling, and early construction activities
• Moves down the left side of the V
– Basic problem requirements are refined into progressively in
detail and technical representations of the problem
• Once code has been generated, moves up the right side of the V

14
 The V-Model Cont.

• Performing a series of tests

– Quality assurance actions
• Provides a way of visualizing how verification and validation actions are
applied to earlier engineering work

15
The Incremental
Model

16
The Incremental Model
Cont.
• Combines elements of linear and parallel
process flows
• Applies linear sequences in a staggered fashion
as calendar time progresses
• Each linear sequence produces deliverable
“increments” of the software that similar to
evolutionary process model
– Word processing software
• Focuses on the delivery of an operational
product with each increment
17
Evolutionary Models:
Prototyping

Quick plan
Quick
Communication plan
communication
Modeling
Modeling
Quick design
Quick design

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

18
 Evolutionary Models:
Prototyping
• Evolutionary model are iterative
• Enables to develop increasingly more complete
versions of the software
• A set of objectives but does not identified
detailed requirements for function and features
• Developer may be unsure of the efficiency of an
algorithm
• The adaptability of an operating system
• Begins with communications

19
Evolutionary Models: The
Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test

20
Evolutionary Models: The
Spiral
• Couples the iterative nature of prototyping with
the controlled and systematic aspects of the
waterfall model
• Provides the potential for rapid development of
increasingly more complete versions of the
software
• software is developed in a series of evolutionary
releases
– Model or prototype
– More complete versions of the engineered system
21
Evolutionary Models: The
Spiral
• Divides into a set of framework activities
defined by the software engineering team
• Each of the framework activities represent one
segment of the spiral path
• A realistic approach to the development of
large-scale systems and software

22
Evolutionary Models:
Concurrent
none

Modeling activity

represents the state

Under of a software engineering
activity or task
development

Awaiting
changes

Under review

Under
revision

Baselined

Done

23
 Evolutionary Models:
Concurrent
• Allows a software team to represent iterative
and concurrent elements of any of the process
models
• The modeling activity defined for the spiral
model is accomplished by invoking one or more
software engineering actions:
– prototyping, analysis, and design
• Defines a series of events that will trigger
transitions from state to state for each of the
software engineering activities, actions, or tasks
24
The Rational Unified
Process

25
 The Rational Unified Process

• Inception
– Establish the business case for the system.

• Elaboration
– Develop an understanding of the problem domain and the system
architecture.

• Construction
– System design, programming and testing.

• Transition
– Deploy the system in its operating environment.

26
 The Rational Unified Process

Workflow Description

Business modelling The business processes are modelled using business use cases.

Requirements Actors who interact with the system are identified and use cases
are developed to model the system requirements.

Analysis and design A design model is created and documented using architectural
models, component models, object models and sequence models.

Implementation The components in the system are implemented and structured

into implementation sub-systems. Automatic code generation from
design models helps accelerate this process.

27
 The Rational Unified Process

Workflow Description
Testing Testing is an iterative process that is carried out in conjunction with
implementation. System testing follows the completion of the
implementation.

Deployment A product release is created, distributed to users and installed in their

workplace.
Configuration and This supporting workflow managed changes to the system
change management
Project management This supporting workflow manages the system development

Environment This workflow is concerned with making appropriate software tools

available to the software development team.

28
 The Rational Unified Process

• Develop software iteratively

– Plan increments based on customer priorities and deliver highest priority
increments first.

• Manage requirements
– Explicitly document customer requirements and keep track of changes to
these requirements.

• Use component-based architectures

– Organize the system architecture as a set of reusable components.

29
 The Rational Unified Process

• Visually model software

– Use graphical UML models to present static and dynamic views of the
software.

• Verify software quality

– Ensure that the software meet’s organizational quality standards.

• Control changes to software

– Manage software changes using a change management system and
configuration management tools.

30
 Still Other Process
•
Models
Component based development—the process to apply when reuse is a
development objective
• Formal methods—emphasizes the mathematical specification of requirements
• AOSD(https://en.wikipedia.org/wiki/Aspect oriented_software_development)—
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)

31
The Unified Process (UP)

32
The Unified Process (UP)
• Attempts to draw on the best features and
characteristics of traditional software process
models
• Recognizes the importance of customer
communication and streamlined methods for
describing the customer’s view of a system
• Helps the architect focus on the right goals,
such as understandability, reliance to future
changes, and reuse

33
 UP
Phases
UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

34
UP Work Products

Inception phase

Elaboration phase
Vision document
Initial use-case model
Initial project glossary
Construction phase
Use-case model
Initial business case Supplementary requirements
Initial risk assessment. including non-functional Design model
Transition phase
Project plan, Analysis model Software components
phases and iterations. Software architecture Delivered software increment
Integrated software
Business model, Description. increment Beta test reports
if necessary. Executable architectural General user feedback
Test plan and procedure
One or more prototypes prototype.
I nc ept i o Test cases
n Preliminary design model Support documentation
Revised risk list user manuals
Project plan including installation manuals
iteration plan description of current
adapted workflows increment
milestones
technical work products
Preliminary user manual

35
 Personal Software Process (PSP)

• Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
• High-level design. External specifications for each component to be constructed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied to
uncover errors in the design. Metrics are maintained for all important tasks and
work results.
• Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all important
tasks and work results.
• Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the process
is determined. Measures and metrics should provide guidance for modifying the
process to improve its effectiveness.

36
 Team Software Process
(TSP)
• 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.
• Accelerate software process improvement by making CMM
Level 5 behavior normal and expected.
– The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.
• Provide improvement guidance to high-maturity
organizations.
• Facilitate university teaching of industrial-grade team
skills.
37