Chapter -2

Prescriptive Process Models

Software Engineering
The IEEE definition

The application of
 systematic, disciplined, quantifiable approach
 to the development, operation, and maintenance of
software;
 that is, the application of engineering to software.
A Layered Technology

Software Engineering

tools

methods

process model

a “quality” focus
A Layered Technology (contd.)
 Process
 Defines who is doing what, when, and how to reach a certain
goal.
 Forms the basis for management control of software projects.
 Methods
 technical “how to”s for building software
 Broad array of tasks: communication, requirements analysis,
design modeling, program construction, testing, and support
 Tools
 Automated support for process and methods
 A Process Framework
Software Process

Process framework

Process framework
Framework activity 1
Framework
Framework activities
activities
work
work tasks
tasks
work
work products
products
milestones
milestones &
& deliverables
Framework activity n
deliverables
QA checkpoints
QA checkpoints
Umbrella Activities
Umbrella Activities
Framework Activities
 Communication
 Get to know your Customer and their processes
 Identify stakeholders
 Requirement elicitation

 Planning
 Plan the work
 Identify resources
 Identify tasks
 Set the schedule
Framework Activities (contd.)
 Modeling
 Analysis of requirements
 Design

 Construction
 Code generation
 Testing

 Deployment
 Delivery
 Feedback
 Activity: Communication
 Task set for a relatively simple project
 Make a list of stakeholders for project
 Invite all stakeholders for an informal meeting
 Ask each stakeholder to make a list of required features and
functions
 Discuss requirements and build a final list
 Prioritize requirements
 Note areas of uncertainty
 Task set for a larger project
 …
Activity: Communication , Action: requirement gathering
 Task set for a relatively simple project …
 Task set for a larger project
 Make a list of stakeholders for project
 Interview each stakeholder separately
 Build a preliminary list of required features and functions
 Schedule a series of facilitated requirement gathering meetings
 Conduct meetings
 Produce informal user scenarios as part of each meeting
 Refine user scenarios based on stakeholder feedback
 Build a revised list of stakeholder requirements
 Use quality function deployment techniques to prioritize
requirements
 Package requirements so that they can be delivered incrementally
 Note constraints and restrictions that will be placed on the system
 Discuss methods for validating the system
Umbrella Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration management
 Work product preparation and production
 Reusability management
 Measurement
 Risk management
 Software project tracking and control
 To maintain schedule …
 Risk management
 Software quality assurance
 Formal technical reviews
 Uncover and remove errors before they propagate to the
next action
 Measurement
 Process, project and product measures
 Software configuration management
 Manages the effects of change
 Reusability management
 Work product preparation and production
 Create models, documents, logs, forms, lists …
The Process Model: Adaptability
 the framework activities will always be applied on every
project ... BUT
 the tasks (and degree of rigor) for each activity will vary
based on:
 the type of project
 characteristics of the project
 common sense judgment; concurrence of the project team
CMMI
 The CMMI defines each process area in terms of “specific
goals” and the “specific practices” required to achieve
these goals.
 Specific goals establish the characteristics that must exist
if the activities implied by a process area are to be
effective.
 Specific practices refine a goal into a set of process-related
activities.
 CMMI represents a process model in two different ways
 A Continuous Model
 A Staged Model
Continuous vs. Staged
 The continuous representation uses capability levels to
measure process improvement, while the staged
representation uses maturity levels.
 Capability levels, which belong to the continuous
representation, apply to an organization’s process-
improvement achievement for each process area.
 Maturity levels, which belong to the staged
representation, apply to an organization’s overall maturity.
 Each capability level corresponds to a generic goal and a
set of generic and specific practices.
 Each maturity level comprises a predefined set of process
areas.
Capability Levels
 Level 0: Incomplete - Process goals not satisfied
 Level 1: Performed - Process goals satisfied
 Level 2: Managed - Process areas conforms to
organizationally defined policy, resources are available, work
tasks are monitored
 Level 3: Defined - Tailored according to the organization’s
standard processes
 Level 4: Quantitatively managed - Quantitative assessment
 Level 5: Optimized - Processes are optimized
CMMI Maturity Levels
 Level 1: Initial.
 The software process is characterized as ad hoc and
occasionally even chaotic. Few processes are defined, and
success depends on individual effort.
 Level 2: Repeatable.
 Basic project management processes are established to
track cost, schedule, and functionality. The necessary
process discipline is in place to repeat earlier successes
on projects with similar applications.
CMMI Maturity Levels
 Level 3: Defined.
 The software process for both management and
engineering activities is documented, standardized, and
integrated into an organizationwide software process. All
projects use a documented and approved version of the
organization's process for developing and supporting
software.This level includes all characteristics defined for
level 2.
CMMI Maturity Levels
 Level 4: Managed.
 Detailed measures of the software process and product
quality are collected. Both the software process and
products are quantitatively understood and controlled
using detailed measures. This level includes all
characteristics defined for level 3.
 Level 5: Optimizing.
 Continuous process improvement is enabled by
quantitative feedback from the process and from testing
innovative ideas and technologies. This level includes all
characteristics defined for level 4.
SW Process Models
 Prescriptive process models advocate an orderly approach
to software engineering.

 It is a set of activities required to:

 Define, design, implement, test and maintain a software
product.

 A SW process model is chosen based on the nature of

the project
SW Process Model Phases
 All models have phases and each phase has 3
components:
 Set of activities, this is what you do.
 Set of deliverables, this is what you produce.
 Quality control measures, this is what you use to
evaluate the deliverables.
 The activities defines the process Framework, the generic
set encompasses:
 Communication, planning, modeling, construction, and
deployment
The Waterfall Model
This Model suggests a systematic, sequential approach to SW
development that begins at the system level and progresses
through analysis, design, code and testing.

Communica t ion
project init iat ion Planning
requirement gat hering estimating Modeling
scheduling
analysis Const ruct ion
tracking
design Deploy ment
code
t est delivery
support
f eedback
The Waterfall Model
Advantages Disadvantages
 Easy  Sequential, does not reflect
 Structured reality
 Provide a template into which  Does not allow for feedback
methods for analysis, design,  Does not produce a
code, testing and maintenance prototype
can be placed.  User must wait until the end
to see the final program.
 Requires to state all
requirements initially.
When to use Waterfall Model
 Simple Projects
 Limited amount of time
 Requirements are well understood

 We can use it for our Class Project

Incremental Models
 Goal to provide quick basic functionality to the users
 Process is not linear
 Requirements are well defined
 Software is completed in an increments fashion
 Will Study 2 models:
1. Incremental Model
2. RAD
1. Incremental Model
 It combines characteristics of the waterfall model and
the iterative nature of the prototyping model.
 1st build is usually the CORE product
 Each increment “deliverable” may add a new
functionality.
 This is repeated until the product is complete
The Incremental Model

increment # n
Com m un ic a t i on
Pla n ni ng
M o de li ng
a nal y s is Co n s t r u c t i o n
d es i gn
c od e De p l o y m e n t
t es t de liv e ry
fe e db a c k

deliv ery of
nt h increment
increment # 2

Com mu ni c a t i on
Pla n ni ng
M o de li ng
a naly s is Co n s t ru c t i o n
d es ig n c ode De p l o y m e n t
t es t d e l i v e ry
fe e db a c k
delivery of
increment # 1 2nd increment

Com mu ni c a t i on
Pla n ni ng
M o de li ng
a naly s is Co n s t ru c t i o n
d es ig n c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e db a c k
1st increment

project calendar t ime

When to use Incremental Model
 When staffing is not available by deadline.
 When the software can be broken into increments and
each increment represent a solution
2. Rapid Application Development
Model
 Builds on the Incremental model with emphases on short
development cycle.
 In other words high speed waterfall model
 Components are build using this model as a fully
functional units in a relatively short time
 It assumes that the system can be modularized
 RAD will fail if you don’t have strong and skillful teams
 High performance might be an issue
 May not be appropriate when technical risk are high (i.e
when make heavy use of new technologies).
The RAD Model

Team # n
M o d e lin g
busines s m odeling
dat a m odeling
proc es s m odeling

Co n s t r u ct io n
com ponent reuse
Team # 2 aut om at ic c ode
Com mu nicat ion generat ion
t es t ing
Mo d el ing
b usin e ss m o de li ng
d at a m o de li ng
p ro ce ss m o d el in g

Plann ing
Co nst ruct io n De p loym e nt
Team # 1 co m p on e nt reu se
int egrat ion
a ut om a t ic co d e
g e ne ra t i on
deliv ery
Mode lin g t e st in g feedback
business modeling
dat a modeling
process modeling

Co nst ru ct ion
component reuse
aut omat ic code
generat ion
t est ing

6 0 - 9 0 days
Evolutionary Process Model
 Core requirements are well understood but additional
requirements are evolving and changing fast
 Time-to-Market
 Iterative – software gets more complex with each
iteration
1. Prototype
2. Spiral
3. Concurrent
Evolutionary Process Model (contd.)
 Advantages
 Do not require full knowledge of the requirements
 Iterative
 Divide project into builds
 Allows feedback, show user something sooner
 Develop more complex systems
1. Prototyping Model
 Start with what is known about requirements.
 Do a quick design.
 Build the prototype by focusing on what will be seen by
the user.
 Use the prototype to show the user and help refining
requirements.
The Prototyping Model

Q u ick p l an

Com mu nicat ion

Mo d e l in g
Qu i ck d e si g n

Deployment
De live r y
& Fe e dback Con st r uct ion
of
pr ot ot ype
When to use Prototype Model
 When the customer define general objectives for the SW
but does NOT identify details about INPUT, OUTPUT, or
processing requirements.

 The developer is unsure of the efficiency of an algorithm,

human machine interaction, etc.
Prototype Model
Advantages Disadvantages
 Prototype is served as the  Customer might think that
machinery for identifying the prototype is the final
requirements. product and forget lack of
 Is developed very quick. quality i.e PERFORMANCE,
RELIABILITY.
2. Spiral Model
 Iterative (like Prototype) and controlled (like waterfall)
model.
 Software is developed using evolutionary releases
 Software complexity increase with each release
The Spiral Model
 Consist of 6 task regions.
 Customer communication - the goal is to establish good
communication between customer and developer.
 Planning - produce/adjust project plan.
 Risk analysis - assess management and technical risks.
 Engineering - build one or more representations of the
application.
 Construction and release - - to construct, test, install and
support the application.
 Customer evaluation – get customer feedback
The Spiral Model

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery
code
feedback test
Spiral Development
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the process.
 Risks are explicitly assessed and resolved throughout the
process.
When to use Spiral Model
 Very large projects.
 When technical skills must be evaluated at each step.
3. The Concurrent Development Model

none

Modeling act ivit y

represents the state

Under of a software engineering
activity or task
development

A wait ing
changes

Under review

Under
revision

Baselined

Done