Yarmouk University

Faculty of Information Technology and Computer Sciences

Department of Computer Information Systems

Software Engineering

CIS 240

:
Mobile: 0796484613
E-mail: osa_alkhoun82@yahoo.com

Chapter Two

Software Processes

Software Processes (Chapter 4 from the textbook)

( )
Objectives

z
To introduce software process models
z
z
To describe Some generic process models and when they may be
used
z
z
To describe outline process models for requirements engineering,
software development, testing and evolution
z

z
To explain the Rational Unified Process model
z
z
To introduce CASE technology to support software process activities
z
Topics covered

z
Software process models
z
z
Process iteration
z
z
Process activities
z
z
The Rational Unified Process
z
z
Computer-aided software engineering
z
z
Agile development methods and processes.
z

The software process

z
A structured set of activities required to develop a software system.
Major activities or stages include: Requirements, Design,
Implementation, Testing, and Deployment.
. z
:
z
Each stage of those listed may have one or more sub stages. For
example, Requirement may include: communication, elicitation,
specification, and verification. Design may include architectural and
detail design.
. z
. :

z
In some projects, a stage maybe shortened, but it can never be ignored.
z
Framework Activities; different terminologies

z
In different books or references, some of those processes may be
mixed, combined, or have different names.
z

z
Communication
z
z
Planning
z
z
Modeling (Design and specs)
( ) z
Analysis of requirements

Design

z
Construction (Implementation and testing)
( ) z
Code generation

Testing

z
Deployment
z

Umbrella Activities
z

Those are considered as secondary processes. Some projects may or
may not include them.
. - z
Software project management
z
Formal technical reviews
z
Software quality assurance
z
Software configuration management
z
Work product preparation and production
z
Reusability management
z
Measurement
z
Risk management
z

Generic software process models

z

The waterfall model: Separate and distinct phases of specification and
development. Does not go to the next phase until completing the
current phase.
. : z
.
Evolutionary development (Prototyping).
.( ) z
Specification, development and validation are interleaved. Develop
prototypes for customers to see and verify.
" " .

Component-based software engineering
z
The system is assembled from existing components off-shelf
components.

There are many variants of these models e.g. formal development
where a waterfall-like process is used but the specification is a formal
specification that is refined through several stages to an implementable design.
- : z
.
.

The Waterfall Model

Communication
project init iat ion
requirement gat hering

Planning
estimating
scheduling
tracking

Modeling
analysis
design

Construction
code
test

Deployment
delivery
support
f eedback

We dont go back to a stage once it is completed, and usually we dont

start a stage until the previous stage is completed.
""

Waterfall model phases

z

Requirements analysis and definition

System and software design

z
z
Implementation and unit testing developers tasks.
z
z
Integration and system testing- testers tasks.
z
z
Operation and maintenance. Customer support and Customer service
tasks.
. z
z
We use the waterfall model when we have fixed, stable and known
requirements.
( ) z

z
The main drawback of the waterfall model is the difficulty of
accommodating changes after the process is underway. One phase has
to be completed before moving to the next phase.

z
( ).()

Waterfall model problems

z

Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements (not suitable
for unstable requirements).

z
.( )
Therefore, this model is only appropriate when the requirements are
well-understood and changes will be fairly limited during the design
process.
z

Few business systems have stable requirements.
( ) z
The waterfall model is mostly used for large systems engineering
projects where a system is developed at several sites. (Such as space
or govt projects).


z
.( ) .

Evolutionary development
( )
z
We want the software to evolve to its final form requirements are
not completely known, or we need to verify them with the customers.
"" " z

z
Exploratory development: The Objective is to work with customers
and to evolve a final system from an initial outline specification.
: z
( )
We should start with those requirements that are well-understood
and agreed upon and then add new features as proposed by the
customer.


z
Throw-away prototyping: The objective is to understand the system
requirements.
. : z
z
We may start with poorly understood requirements, and then build
prototypes to clarify what is really needed.
( ) z
.

Evolutionary Models: Prototyping

:

Quick plan

Communicat ion

Mode ling
Quick de sign

Deployment
Delivery
& Feedback

Const ruct ion

of
prot ot ype

Evolutionary development
( )
Problems

Lack of process visibility ( We dont have the complete

requirements and hence we are not sure how much resources we
may need, or of the project will be a successful one);
)
(
Systems are often poorly structured (because they evolve and
change continuously).
) ( )
.(
Special skills (e.g. in languages for rapid prototyping) may be
required.
- : )
.(

Evolutionary development

Applicability

For small or medium-size interactive systems;

For parts of large systems (e.g. the user interface);
( - : )
For short-lifetime systems.

Prototyping can be used in initial stages as a way of collecting
requirements. (Customers may find it easier to make comments on
actual product and not just papers or documents).
).

.(

Process iteration

z
System requirements ALWAYS evolve in the course of a project. As a
result, process iteration where earlier stages are reworked is always
part of large systems processes. (MS Windows & Office continuously
have updates, newer versions, batches and bug fixes).

. z
) .
.(
z
Iteration can be applied to any of the generic process models.
) ( z
z
Two (related) approaches
( ) z
Incremental delivery;

Spiral development.
( )
Incremental delivery
( )
z

Rather than delivering the system as a single delivery, the

development and delivery is broken down into increments with each
increment delivering part of the required functionality.
z

User requirements are prioritised and the highest priority requirements
are included in early increments.
z
Once the development of an increment is started, the requirements are
frozen though requirements for later increments can continue to
evolve.
z

The Incremental Model

) (

increment # n
Co m m u n i c a t i o n
Pl a n n i n g
Model ing
analysis
design

Co n s t ru c t i o n
code
t est

De p l o y m e n t
d e l i v e ry
fee dbac k

delivery of
nt h increment

increment # 2
Co m m u n i c a t i o n
Pl a n n i n g
Mode li ng
analysis
design

Co n s t r u c t i o n
code

De p l o y m e n t

t est

de l i v e ry
feedback

increment # 1

delivery of
2nd increment

Co m m u n i c a t i o n
Pl a n n i n g
Modeli ng
analysis
design

Co n s t r u c t i o n
code

De p l o y m e n t

t est

d e l i v e ry
fee dbac k

delivery of
1st increment

project calendar time

Incremental development advantages

z

Customer value can be delivered with each increment so system
functionality is available earlier.
z
Early increments act as a prototype to help elicit requirements for later
increments.
z
Lower risk of overall project failure.
z
The highest priority system services tend to receive the most testing.
z

Spiral development
z

( )
Process is represented as a spiral rather than as a sequence of activities
with backtracking.
( )z
Each loop in the spiral represents a phase in the process.
z
No fixed phases such as specification or design - loops in the spiral are
chosen depending on what is required.
- z

Risks are explicitly assessed and resolved throughout the process.
(This is the main difference from the Incremental model).
) . z
.(( )

Spiral model of the software process

) ( ) (

Evolutionary Models: The Spiral

( ) :
planning
estimation
scheduling
risk analysis

communication
modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test

Spiral model sectors

( )
z

Objective setting

Specific objectives for the phase are identified.

Risk assessment and reduction
z
Risks are assessed and activities put in place to reduce the key
risks.

Development and validation
z
A development model for the system is chosen which can be any of
the generic models.

Planning
z
The project is reviewed and the next phase of the spiral is planned.
.

General process activities

z

Software specification

Software design and implementation

Software validation
Software evolution

Software specification
z

The process of establishing what services are required and the
constraints on the systems operation and development.
z
Requirements engineering process
z
Feasibility study;

Requirements elicitation and analysis;

Requirements specification;

Requirements validation.

The requirements engineering process

Software design and implementation

z
Software design: To design a software structure or model that realises
the specification; The design is the link between the requirements and
the code (The blueprint such as the one used in buildings).
: z
) ( )
.(
z
Implementation: The process of converting the system specification
into an executable system (i.e. the code or the software).
. : ) : z
.( ) (
z
The activities of design and implementation are closely related and
may be inter-leaved.
. z
Design process activities

z

Architectural design

Abstract specification
Interface design
Component or detail design
Data structure design
Algorithm design

The software design process

Programming and debugging

z
Translating a design into a program and removing errors from that
program.
z
z
We use programming or developing to refer to the implementation
stage.
z
z
Programming is a personal activity - there is no generic programming
process, but there are coding standards (such as naming conventions).
z
( )( )
z
Programmers carry out some program testing to discover faults in the
program and remove these faults in the debugging process (i.e. unit
testing).
)( z
. )( ) ( )
.(
The debugging process
( ) ( )

Software validation

z
Verification and validation (V & V) are intended to show that a
system conforms to its specification and meets the requirements of the
system customer.
( V & V) z
.
z
Involves checking and review processes and system testing.
z
z
System testing involves executing the system with test cases that are
derived from the specification in order to be processed by the system.
z

z
Validation and verification occurs in the requirement stage while
testing occurs within or after the implementation stage.
z
.

Testing stages

z
Component or unit testing : Individual components are tested
independently;
) ( : z
Components may be functions or objects or coherent groupings of
these entities. Usually done by developers.
.

z
System testing: Testing of the system as a whole. Testing of emergent
properties is particularly important. Usually done by local company
testers.
. . : z
.
z
Acceptance testing: Testing with customer data to check that the
system meets the customers needs. Usually done by customers or
independent testers.
. :
z
.
The testing process

Testing phases

Other types of testing

z

Unit or white box testing (i.e. component testing).
.( . : ) z
Black box testing (can be part of system testing).
.( ) z
Integration testing (related to system testing).
( )( ) z
User Interface testing (can be part of system testing).
( ) ( ) z
Alpha and Beta testing (can be part of acceptance testing).
( ) z

Software evolution or maintenance

z

Software is inherently flexible and can change.

z
As requirements change, through changing business circumstances,
the software that supports the business must also evolve and change.
( ) z
)(
Although there has been a mixing between development and evolution
(maintenance) this is increasingly irrelevant as fewer and fewer
systems are completely new.
)( z
) (

System evolution
)(

The Rational Unified Process

z

A modern process model derived from the work on the UML and
associated process.
UML z
Normally described from 3 perspectives
z
A dynamic perspective that shows phases over time;

A static perspective that shows process activities;

A proactive perspective that suggests good practices.

RUP phase model

RUP phases

Inception

Establish the business case for the system.

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

z
Construction
z
System design, programming and testing.
)
z
Transition
( )z
Deploy the system in its operating environment.

RUP good practice

z
Develop software iteratively
( ) z
z
Manage requirements
z
z
Use component-based architectures
z
z
Visually model software
z
z
Verify software quality
z
z
Control changes to software
z

Static workflows

Workflow

Description

Business modeling

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.
.

. )(

Test
( )

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
change management

This supporting workflow managed changes to the system

(see Chapter 29).
( )

Project management

This supporting workflow manages the system

development (see Chapter 5).
( )

Environment

This workflow is concerned with making appropriate

software tools available to the software development team.
)(
.

Computer-aided software engineering CASE

z
Computer-aided software engineering (CASE) is a software to support
software development and evolution processes (Example, .NET IDE).
z
(.NET IDE ) ( )
z
Activity automation
z
Graphical editors for system model development (such as UML,
.NET, Eclipse, etc);
UML, .NET, )( )
(Eclipse
Data dictionary to manage design entities (OO design tools);
) (
Graphical UI builder for user interface construction (.NET, Eclipse,
etc.);
(.NET, Eclipse)
Debuggers to support program fault finding;
) (
Automated translators to generate new versions of a program (such
as Installers).
.( )
CASE technology

z
CASE technology has led to significant improvements in the software
process. However, these are not the order of magnitude improvements
that were once predicted
z
.
Software engineering requires creative thought - this is not readily
automated;
-
Software engineering is a team activity and, for large projects,
much time is spent in team interactions. CASE technology does not
really support these. (i.e. the personal activities, Some tools can be
used to work as a communication media between project team
members, project or defect tracking tools).

: ) . .

.(

CASE classification

z
Classification helps us understand the different types of CASE tools
and their support for process activities.
z

z
Functional perspective
z
Tools are classified according to their specific function.
( )
z
Process perspective
( )z
Tools are classified according to process activities that are
supported.

z
Integration perspective
z
Tools are classified according to their organisation into integrated
units.

Functional tool classification

Tool type

Planning tools

Editing tools

Examples

PERT tools, estimation tools,

spreadsheets
Text editors, diagram editors, word
processors

Change management tools

Requirements traceability tools, change

control systems

Configuration management
tools

Version management systems, system

building tools

Prototyping tools

Method-support tools
-
Language-processing tools
-
Program analysis tools

Testing tools
( )
Debugging tools

Very high-level languages, user

interface generators
Design editors, data dictionaries, code
generators
Compilers, interpreters
Cross reference generators, static
analysers, dynamic analysers
Test data generators, file comparators
Interactive debugging systems

Documentation tools

Page layout programs, image editors

Re-engineering tools

Cross-reference systems, program restructuring systems

Activity-based tool classification

CASE integration

z

Tools
z
Support individual process tasks such as design consistency
checking, text editing, etc.
.
Workbenches
z
Support a process phase such as specification or design, Normally
include a number of integrated tools.

Environments
z
Support all or a substantial part of an entire software process.
Normally include several integrated workbenches.
. ) (

Tools, workbenches, environments

.

The Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
."
:
Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items
on the left more.
".

What is Agility?
z

" "
Effective (rapid and adaptive) response to change
) ( z
Effective communication among all stakeholders
( )z
Drawing the customer onto the team
)( z
Organizing a team so that it is in control of the work performed
Yielding
z
Rapid, incremental delivery of software
z

An Agile Process
z

Is driven by customer descriptions of what is required (scenarios)
( )z
Recognizes that plans are short-lived
z
Develops software iteratively with a heavy emphasis on construction
activities
)( z
Delivers multiple software increments
" " z
Adapts as changes occur
. z

Extreme Programming (XP)

z
The most widely used agile process, originally proposed by Kent Beck
)( z
z
XP Planning
z
Begins with the creation of user stories
" "
Agile team assesses each story and assigns a cost

Stories are grouped to for a deliverable increment

A commitment is made on delivery date

After the first increment project velocity is used to help define
subsequent delivery dates for other increments
" "

z
XP Design
z
Follows the KIS principle
KIS
Encourage the use of CRC cards.
CRC )(
For difficult design problems, suggests the creation of spike
solutionsa design prototype
. " "
Encourages refactoringan iterative refinement of the internal
program design
)( " "
z
XP Coding
z
Recommends the construction of a unit test for a store before
coding commences (Test driven development).
.( )
Encourages pair programming
" )( "

XP Testing

All unit tests are executed daily

Acceptance tests are defined by the customer and executed to
assess customer visible functionality
" "

Extreme Programming (XP)

simple design
CRC cards

spike solut ions

prot ot ypes

user st ories
values
accept ance t est crit eria
it erat ion plan

ref act oring

pair
programming

Release
sof t w are increm ent
project v elocit y com put ed

unit t est
cont inuous int egrat ion
accept ance t est ing

Scrum
( )
z

Originally proposed by Schwaber and Beedle

z
Scrumdistinguishing features
z
Development work is partitioned into packets
" "
Testing and documentation are on-going as the product is
constructed

Work occurs in sprints and is derived from a backlog of
existing requirements
"" ""
Meetings are very short and sometimes conducted without chairs

demos are delivered to the customer with the time-box allocated
""

Scrum

Crystal

Proposed by Cockburn and Highsmith

z
Crystaldistinguishing features

Actually a family of process models that allow maneuverability
based on problem characteristics
" "

Face-to-face communication is emphasized

Suggests the use of reflection workshops to review the work
habits of the team
" "
z

Key points

z
Software processes are the activities involved in producing and
evolving a software system.
. )( z
z
Software process models are abstract representations of these
processes.
( ) z
z
General activities are specification, design and implementation,
validation and evolution.
)( z
z
Generic process models describe the organisation of software
processes. Examples include the waterfall model, evolutionary
development and agile development.
. z
. ) (
z
Iterative process models describe the software process as a cycle of
activities.
z
z
Requirements engineering is the process of developing a software
specification.
)( z
z
Design and implementation processes transform the specification to an
executable program.
( )( )z
z
Validation involves checking that the system meets to its specification
and user needs.
z
z
Evolution is concerned with modifying the system after it is in use.
)( z
z
The Rational Unified Process is a generic process model that separates
activities from phases.
z
z
CASE technology supports software process activities.
z
z
Agile development methodologies are suggested to deal with the
continuously evolving requirements and the need of company to
deliver software in a reasonable time.
z
.

Agile development accept changes on requirements and deal with

them continuously. They focus on the product rather than the
documents. They focus on customer satisfaction rather than contracts.
. z
. .
The 2 factors that affect the software process is the stability of the
requirements and the flexibility to change requirements. We need to
keep a balance between those 2 factors because instable requirements
causes a lot of troubles for the project management, while inflexible
project may have problems with customers and come up to a complete
failure.
z
.