SOFTWARE PROCESSES

AND
PROCESS MODELS
 CONTENTS

• SOFTWARE PROCESSES
• PROCESS MODEL
• A GENERIC PROCESS MODEL
• PROCESS FLOW
• SOFTWARE FRAMEWORK ACTIVITIES
• PROCESS IMPROVEMENT
• SOFTWARE PROCESS MODEL
• SELECTION OF SOFTWARE PROCESS MODEL
 SOFTWARE PROCESS
• A structured set of activities required to develop a software system.
• A framework for the activities, actions, and tasks that are required to build
high-quality software.
• It is not equal to software engineering, which also encompasses technologies
that populate the process– technical methods and automated tools
• 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.
 SOFTWARE PROCESS DESCRIPTIONS
• When we describe and discuss processes, we usually talk about the
activities in these processes such as specifying a data model, designing a
user interface, etc. and the ordering of these activities.
• Process descriptions may also include:
• Products, which are the outcomes of a process activity;
• Roles, which reflect the responsibilities of the people involved in the
process;
• Pre- and post-conditions, which are statements that are true before
and after a process activity has been enacted or a product produced.
 SOFTWARE PROCESS MODEL

• A software process model is an abstract representation of a process.

• It presents a description of a process from some particular
perspective.
• It describes the sequence of phases for the entire lifetime of a
product.
• Therefore, it is sometimes also called product life cycle.

• This covers everything from the initial commercial idea until the
final de-installation or disassembling of the product after its use.
 WHAT/WHO/WHY IS PROCESS MODELS?
• What: go through a series of predictable steps--- a road map that helps you create a
timely, high-quality results.
• Who: software engineers and their managers, clients also. people adapt the process
to their needs and follow it.
• Why: provides stability, control, and organization to an activity that can if left
uncontrolled, become quite chaotic. however, modern software engineering
approaches must be agile and demand only those activities, controls and work
products that are appropriate.
• What work products: programs, documents, and data
• What are the steps: the process you adopt depends on the software that you are
building. one process might be good for aircraft avionic system, while an entirely
different process would be used for website creation.
• How to ensure right: a number of software process assessment mechanisms that
 A GENERIC PROCESS MODEL

• As we discussed before, a generic process framework for

software engineering defines five framework activities:
communication, planning, modeling, construction, and
deployment.
• In addition, a set of umbrella activities- project tracking and
control, risk management, quality assurance, configuration
management, technical reviews, and others are applied
throughout the process.
 CONTD…
• Communication : this activity involves heavy communication with
customers and other stakeholders in order to gather requirements
and other related activities.
• Planning : here a plan to be followed will be created which will
describe the technical tasks to be conducted, risks, required
resources, work schedule etc.
• Modeling : a model will be created to better understand the
requirements and design to achieve these requirements.
• Construction : here the code will be generated and tested.
• Deployment : here, a complete or partially complete version of the
software is represented to the customers to evaluate and they give
feedbacks based on the evaluation.
 PROCESS FLOW

• A linear process flow

executes each of the five
activities in sequence.
• An iterative process flow
repeats one or more of the
activities before proceeding
to the next.
 CONTD…
• An evolutionary process flow
executes the activities in a circular
manner.
• Each circle leads to a more complete
version of the software.
• A parallel process flow executes one
or more activities in parallel with other
activities modeling for one aspect of the
software in parallel with construction of
another aspect of the software.
A GENERIC PROCESS
MODEL
 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
 CONTD…

For example, a small software project requested by one person with simple
requirements, the communication activity might encompass little more than a
phone call with the stakeholder. therefore, the only necessary action is phone
conversation, the work tasks of this action are:
1. Make contact with stakeholder via telephone.
2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval
 CONTD…

• The task sets for requirements gathering action for a simple project may
include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal meeting.
3. Ask each stakeholder to make a list of features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
 CONTD…
• The task sets for requirements gathering action for a big project may include:
1. make a list of stakeholders for the project.
2. interview each stakeholders separately to determine overall wants and needs.
3. build a preliminary list of functions and features based on stakeholder input.
4. schedule a series of facilitated application specification meetings.
5. conduct meetings.
6. produce informal user scenarios as part of each meeting.
7. refine user scenarios based on stakeholder feedback.
8. build a revised list of stakeholder requirements.
9. use quality function deployment techniques to prioritize requirements.
10. package requirements so that they can be delivered incrementally.
11. note constraints and restrictions that will be placed on the system.
12. discuss methods for validating the system.
 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.
CONTD…

• task patterns—defines a problem associated with a software engineering action or

work task and relevant to successful software engineering practice (e.g.,
requirementsgathering is a task pattern).
• stage patterns—defines a problem associated with a framework activity for the
process. an example of a stage pattern might be establishingcommunication. this
pattern would incorporate the task pattern requirementsgathering and others
• phase patterns—define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in nature. an example of
a phase pattern might be spiralmodel or prototyping.
 CONTD…
• template for describing a process pattern:
• pattern name:
• the pattern name is given a meaningful name that describe its function within software process.
• example: customer-communication

• intent:
• the objective of this pattern is describe briefly.
• example: intent of the communication customer to connection establish with customer.

• type:
• the pattern type is specified.
• three types:
• task pattern - action or work task;
• stage pattern – frame activity; and
• phase pattern – sequence of frame.
 CONTD…
• INITIAL CONTEXT:

• describe which pattern are applies prior to the initialization of the pattern.
1. what organizational or team-related activities have already occurred?
2. what is the entry state for the process?
3. what software engineering information or project information already exists?
for example, the planning pattern (a stage pattern) requires that
4. customers and software engineers have established a collaborative
communication;
5. successful completion of a number of task patterns [specified] for the
communication pattern has occurred; and
6. the project scope, basic business requirements, and project constraints are
known
 CONTD…

• problem.
• the specific problem to be solved by the pattern.
• solution.
• describes how to implement the pattern successfully. this section describes how
the initial state of the process (that exists before the pattern is implemented) is
modified as a consequence of the initiation of the pattern.
• it also describes how software engineering information or project information that
is available before the initiation of the pattern is transformed as a consequence of
the successful execution of the pattern.
 CONTD…

• resulting context:
• the condition that will result once the pattern has been successfully
implementers are describe.
• upon completion of the pattern:
1. what organizational or team-related activities must have occurred?
2. what is the exit state for the process?
3. what software engineering information or project information has
been developed?
 CONTD…
• related pattern:
• a list of process pattern that are directly related to this one are
provided as a hierarchy on in some other diagrammatic form.
• for example, the stage pattern communication encompasses the task patterns:
projectteam, collaborativeguidelines, scopeisolation, requirementsgathering,
constraintdescription, and scenariocreation.

• known uses and examples:

• indicate the specific instances in which the pattern is applicable.
• for example, communication is mandatory at the beginning of every software project,
is recommended throughout the software project, and is mandatory once the
deployment activity is under way.
 PROCESS IMPROVEMENT

• Many software companies have turned to software process

improvement as a way of enhancing the quality of their
software, reducing costs or accelerating their development
processes.
• Process improvement means understanding existing processes
and changing these processes to increase product quality and/or
reduce costs and development time.
Chapter 2 Software Processes 30/10/2014 24
 APPROACHES TO IMPROVEMENT
• The process maturity approach, which focuses on improving process and
project management and introducing good software engineering practice.
• The level of process maturity reflects the extent to which good technical
and management practice has been adopted in organizational software
development processes.
• The agile approach, which focuses on iterative development and the
reduction of overheads in the software process.
• The primary characteristics of agile methods are rapid delivery of
functionality and responsiveness to changing customer requirements.

Chapter 2 Software Processes 30/10/2014 25

 THE PROCESS IMPROVEMENT CYCLE

Chapter 2 Software Processes 30/10/2014 26

 PROCESS IMPROVEMENT ACTIVITIES
• process measurement
• you measure one or more attributes of the software process or product.
these measurements forms a baseline that helps you decide if process
improvements have been effective.
• process analysis
• the current process is assessed, and process weaknesses and bottlenecks
are identified. process models (sometimes called process maps) that
describe the process may be developed.
• process change
• process changes are proposed to address some of the identified process
weaknesses. these are introduced and the cycle resumes to collect data
about the effectiveness of the changes.
Chapter 2 Software Processes 30/10/2014 27
 PROCESS MEASUREMENT

• Wherever possible, quantitative process data should be collected

• however, where organisations do not have clearly defined process
standards this is very difficult as you don’t know what to measure.
• a process may have to be defined before any measurement is possible.

• Process measurements should be used to assess process

improvements
• but this does not mean that measurements should drive the
improvements.
• the improvement driver should be the organizational objectives.
Chapter 2 Software Processes 30/10/2014 28
 PROCESS METRICS

• Time taken for process activities to be completed

• e.g. calendar time or effort to complete an activity or process.
• Resources required for processes or activities
• e.g. total effort in person-days.
• Number of occurrences of a particular event
• e.g. number of defects discovered.

Chapter 2 Software Processes 30/10/2014 29

 CAPABILITY MATURITY LEVELS

Chapter 2 Software Processes 30/10/2014 30

 THE SEI CAPABILITY MATURITY MODEL
• initial
• essentially uncontrolled
• repeatable
• product management procedures defined and used
• defined
• process management procedures and strategies defined and used
• managed
• quality management strategies defined and used
• optimising
• process improvement strategies defined and used 30/10/2014 31
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 to software organizations and
companies. [ant06]
 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 33is
determined. measures and metrics should provide guidance for modifying the process to
improve its effectiveness.
 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.
• Provide improvement guidance to high-maturity organizations.

34
SOFTWARE DEVELOPMENT LIFE CYCLE
(SDLC)
 PRESCRIPTIVE PROCESS 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?
WATERFALL MODEL
 CONTD…

• The first published model of the software development process was

derived from more general system engineering processes (royce,
1970).
• This model is known as the ‘waterfall model’ or software life cycle
• The waterfall model this takes the fundamental process activities of
specification, development, validation, and evolution and represents
them as separate process phases such as requirements specification,
software design, implementation, testing, and so on.
 CONTD…
• PROBLEMS:
• Real projects rarely follow the sequential flow that the model proposes.
although the linear model can accommodate iteration, it does so
indirectly. as a result, changes can cause confusion as the project team
proceeds.
• It is often difficult for the customer to state all requirements explicitly.
the waterfall model requires this and has difficulty accommodating the
natural uncertainty that exists at the beginning of many projects.
• The customer must have patience. a working version of the program(s)
will not be available until late in the project time span. a major blunder,
if undetected until the working program is reviewed, can be disastrous
 CONTD…
• problems:
• rarely linear, iteration needed.
• hard to state all requirements explicitly. blocking state.
• code will not be released until very late.
• waterfall model application
• every software developed is different and requires a suitable sdlc
approach to be followed based on the internal and external factors.
some situations where the use of waterfall model is most appropriate
are:
• requirements are very well documented, clear and fixed.
• product definition is stable.
• technology is understood and is not dynamic.
• there are no ambiguous requirements.
• ample resources with required expertise are available to support
 CONTD…

• Some circumstances where the use of the waterfall model is

most suited are:
• When the requirements are constant and not changed
regularly.
• A project is short
• The situation is calm
• Where the tools and technology used is consistent and is not
changing
• When resources are well prepared and are available to use.
 THE V-MODEL

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
42
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 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
nth increment
increment # 2

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
t es t
De p l o y m e n t
d e l i v e ry delivery of
fe e dba c k

1st increment

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
43
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
project calendar time
 EVOLUTIONARY MODELS:
PROTOTYPING

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

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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
44
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 EVOLUTIONARY MODELS: THE
SPIRAL
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedbackA Practitioner’s Approach, 7/e
These slides are designed to accompany Software Engineering: test 45
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
46
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 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—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
These slides are designed ALIGNED
to accompany WITH
Software Engineering: THE UNIFIED
A Practitioner’s Approach, 7/e MODELING LANGUAGE (UML)
47
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 THE UNIFIED PROCESS

• WHY A PROCESS?
• SOFTWARE PROJECTS ARE LARGE, COMPLEX,
SOPHISTICATED
• TIME TO MARKET IS KEY
• MANY FACETS INVOLVED IN GETTING TO THE END
• COMMON PROCESS SHOULD
• INTEGRATE THE MANY FACETS
• PROVIDE GUIDANCE TO THE ORDER OF ACTIVITIES
• SPECIFY WHAT ARTIFACTS NEED TO BE
DEVELOPED
• OFFER CRITERIA FOR MONITORING AND 48

MEASURING A PROJECT
 THE UNIFIED PROCESS
• COMPONENT BASED - MEANING THE SOFTWARE SYSTEM IS
BUILT AS A SET OF SOFTWARE COMPONENTS
INTERCONNECTED VIA INTERFACES
• USES THE UNIFIED MODELING LANGUAGE (UML)
This is what makes
• USE CASE DRIVEN the Unified process
Unique
• ARCHITECTURE-CENTRIC
• ITERATIVE AND INCREMENTAL

Component: A physical and replaceable part of a system that conforms to

and provides realization of a set of interfaces.
Interface: A collection of operations that are used to specify a service of a
class or a component 49
 THE UNIFIED PROCESS

Software
User’s Software
Development
requirements System
Process

50
 THE UNIFIED PROCESS

• USE CASE DRIVEN

• A USE CASE IS A PIECE OF
FUNCTIONALITY IN THE SYSTEM THAT
GIVES A USER A RESULT OF VALUE
• USE CASES CAPTURE FUNCTIONAL
REQUIREMENTS
• USE CASE ANSWERS THE QUESTION:
WHAT IS THE SYSTEM SUPPOSED TO
DO FOR THE USER? 51
 THE UNIFIED PROCESS

• ARCHITECTURE CENTRIC
• SIMILAR TO ARCHITECTURE FOR
BUILDING A HOUSE

• EMBODIES THE MOST SIGNIFICANT

STATIC AND DYNAMIC ASPECTS OF
THE SYSTEM
• INFLUENCED BY PLATFORM, OS,
DBMS ETC.
• PRIMARILY SERVES THE REALIZATION 52

OF USE CASES
 THE UNIFIED PROCESS

• ITERATIVE AND INCREMENTAL

• COMMERCIAL PROJECTS CONTINUE MANY MONTHS AND
YEARS
• TO BE MOST EFFECTIVE - BREAK THE PROJECT INTO
ITERATIONS

• EVERY ITERATION - IDENTIFY USE CASES,CREATE A

DESIGN, IMPLEMENT THE DESIGN
• EVERY ITERATION IS A COMPLETE DEVELOPMENT
PROCESS
53
 THE LIFE OF THE UNIFIED PROCESS

• UNIFIED PROCESS REPEATS OVER A SERIES

OF CYCLES
• EACH CYCLE CONCLUDES WITH A PRODUCT
RELEASE
• EACH CYCLE CONSISTS OF FOUR PHASES:
• INCEPTION
• ELABORATION
• CONSTRUCTION
• TRANSITION

54
 THE UNIFIED PROCESS (UP)
Elaboration
elaboration

Inception
inception

construction
Release
transition
software increment

These slides are designed to accompany Software Engineering:

production A Practitioner’s Approach, 7/e
55
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 CONTD…

1.INCEPTION –
• COMMUNICATION AND PLANNING ARE MAIN.
• IDENTIFIES SCOPE OF THE PROJECT USING USE-CASE MODEL
ALLOWING MANAGERS TO ESTIMATE COSTS AND TIME REQUIRED.
• CUSTOMERS REQUIREMENTS ARE IDENTIFIED AND THEN IT
BECOMES EASY TO MAKE A PLAN OF THE PROJECT.
• PROJECT PLAN, PROJECT GOAL, RISKS, USE-CASE MODEL,
PROJECT DESCRIPTION, ARE MADE.
• PROJECT IS CHECKED AGAINST THE MILESTONE CRITERIA AND IF
IT COULDN’T PASS THESE CRITERIA THEN PROJECT CAN BE
EITHER CANCELLED OR REDESIGNED.
56
• ELABORATION –
1.PLANNING AND MODELING ARE MAIN.
2.DETAILED EVALUATION, DEVELOPMENT PLAN IS
CARRIED OUT AND DIMINISH THE RISKS.
3.REVISE OR REDEFINE USE-CASE MODEL (APPROX.
80%), BUSINESS CASE, RISKS.
4.AGAIN, CHECKED AGAINST MILESTONE CRITERIA AND IF
IT COULDN’T PASS THESE CRITERIA THEN AGAIN
PROJECT CAN BE CANCELLED OR REDESIGNED.
5.EXECUTABLE ARCHITECTURE BASELINE.
57
• CONSTRUCTION –
1.PROJECT IS DEVELOPED AND COMPLETED.
2.SYSTEM OR SOURCE CODE IS CREATED AND THEN TESTING
IS DONE.
3.CODING TAKES PLACE.

58
• TRANSITION –
1.FINAL PROJECT IS RELEASED TO PUBLIC.
2.TRANSIT THE PROJECT FROM DEVELOPMENT INTO
PRODUCTION.
3.UPDATE PROJECT DOCUMENTATION.
4.BETA TESTING IS CONDUCTED.
5.DEFECTS ARE REMOVED FROM PROJECT BASED ON
FEEDBACK FROM PUBLIC.

59
THE LIFE OF THE UNIFIED PROCESS
Time

Inception Elaboration Construction Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

1 1 1 1

Release 1
A cycle with its phases and its iterations 60
 UP PHASES
UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
61
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
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 Transition phase
Design model
Project plan, Analysis model Software components
phases and it erations. Soft ware archit ecture Int egrated software Delivered soft ware increment
Business model, Description. increment Beta test reports
if necessary. Executable architectural Test plan and procedure General user feedback
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

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e
62
(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman.
 SELECTION OF A PROCESS MODEL

• Selection of a model is based on:

• Requirements
• Development team
• Users
• Project type and associated risk
THANK YOU!!!

64