CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 3
Prescriptive Process Models
Discussion of the Software Process models:
Prescriptive Process Models
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Software Process Models (1)
Prescriptive process models evolved over the years to bring
some order to the software development (structure, order,
consistency)… But, the software industry is fast changing!
A prescriptive process model is a strategy/paradigm that
prescribes a set of process elements (activities, actions,
work tasks, product, QA, CM) and a workflow.
Different software projects require different process models!
Why?
- nature of the application
- complexity
- methods and tools
- required control
- expected quality
- outcomes/products
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Software Process Models (2)
Key phases of a software process model:
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Waterfall Model (1)
Known as classic life cycle or sequential model.
Communication
Planning
Development
Modeling
Deployment
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Waterfall Model (2)
Life cycle phases:
1. Communication (Requirements Analysis): Good understanding
of the system (databases, performance, interface/user,
functions).
Document: SRS - What the system will do.
2. Planning: Developing project development plan (estimation,
scheduling, tracking, and risk management).
Document: SDP – The project development plan.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Waterfall Model (3)
3. Modeling (Design): Translating requirement specifications of a
software systems that can be assessed for against
requirements.
Design elements: data structures, software architecture,
interfaces, implementation (algorithmic) details.
Document: SDD - How the system will work.
4. Coding: Translation design into code (programming task).
Document: generated code (modules, procedures, packages,
classes, etc..)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Waterfall Model (4)
5. Testing: Process of finding unknown errors and defects using
a test plan that consist of test cases.
Testing begins before coding starts!
Test cases are traceable to requirements
Testing begins in the small
Unit testing
Integration testing
System testing
Acceptance testing
Document: Test Plan and Test Cases
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Waterfall Model (5)
5. Deployment (Support): Delivery, support, and feedback.
Application of previous phases when making a change to
deployed system (new requirements, environment changes,
interface/user changes, etc…).
Potential Problems:
- Incomplete requirements
- Long waiting for a working version (client perspective)
- Critical path - blocking states and waiting time
- Projects do not follow sequential flow! Too many changes
BUT, the model defines essential activities for software
development...
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Incremental Model (1)
It is an iterative linear process that produces functional
increments (usable modules) of the system.
increment 1
analysis
design
increment 2
code
analysis
test
design
increment 3
analysis
delivery of
Core
1st increment Product
code
desig n
Additional
delivery of
2nd increment Features
t est
co de
test
calendar time
delivery of
3rd increment
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Incremental Model (2)
- It is an evolutionary model.
- First increment is the core product (focus on the essential
requirements of the system)
- Plans for future increments (additional requirements) must be
developed.
Advantages:
- Increments are functional products (unlike prototyping)
- Staffing is not an issue, adjusted as needed
- Facilitates managing technical and other risks
Any disadvantages?
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The RAD Model (1)
- Incremental process that uses component-based development
for business applications, and emphasizes short life cycle.
- Ideally, each business function is completed in 2 to 3 months.
team #3
team #2
b u s i n e s s
m o d e l i n g
team #1
b u s i n e s s
m o d e li n g
Business
Modeling
d a t a
m o d e l i n g
p r o c e s s
m o d e l i n g
d a t a
m o d e li n g
Data
Modeling
a p p l i c a ti o n
g e n e r a t i o n
t e s ti n g
&
t u r n o v e r
p r o c e s s
m o d e li n g
Process
modeling
a p p li c a ti o n
g e n e r a ti o n
t e s ti n g
&
t u r n o v e r
Application
generation
Testing and
turnover
60 - 90 days
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The RAD Model (2)
RAD phases: (Applied to modeling and development phases)
1. Business modeling - identify business functions, processes,
and what/how/who generates information.
2. Data modeling - redefine business information to data objects,
and define object attributes and relationships among objects.
3. Process modeling - describe how processes manipulate (add,
delete, retrieve, update) data objects to implement business
functions.
4. Application generation - automated tools (4th generation
techniques) are used to create the application by using
component reuse.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The RAD Model (3)
5. Testing - mainly component integration and system testing
since components are already tested.
Challenges:
-
Requires sufficient human resources
Require careful planning for multiple teams
Requires commitment (developer and customer)
Limited to specific systems (with modularity nature) (business
applications)
- Inappropriate when technical risks are high (technology and
interoperability)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Prototyping Model (1)
- Evolutionary model - iterative
- Incomplete requirements? Go prototyping!
- The prototype shows software aspects visible to the user.
Listen
to customer
Quick Plan
Design/Build
/Revise
mock-up
Customer
test-drives
mock-up
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Prototyping Model (2)
The purpose:
- to satisfy customer needs
- to understand system requirements
What to do with the prototype?
- throw it away or reuse it? Must decide before you build it.
Potential problems:
- Pressure to extend the prototype to a working system!
- The “less-than-ideal choice” becomes part of the system!
Prototyping keeps everyone happy! Only if the customer
agrees to its purpose and what you will do with it...
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Spiral Model (1)
An evolutionary iterative process (with controlled step-wise
waterfall) that produces incremental releases of the system
(not necessarily functional increments!)
Planning
Risk Analysis
Customer
Communication
SRS
Engineering
Prototype
Customer
Evaluation
Construction &
Release
Complete System
Working Version
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Spiral Model (2)
- Each release goes through task regions, each task region
defines a set of work tasks relevant to the project type and size.
- It is appropriate for large-scale evolving software projects.
- It facilitates prototyping (in early passes) to reduce risks!
- Allows constant risk assessment in all region
- Each pass thought the planning region, the project plan,
schedule, and cost are adjusted accordingly.
Drawback:
- Less popular than sequential and prototype models
- Does not appeal to the customer!
- Require considerable risk assessment expertise
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Concurrent Process Model
An evolutionary iterative concurrent process where all process
activities are concurrent, but at different states.
- Appropriate for system engineering (different engineering
teams)
- Similar to RAD model, but at the system level!
- Uses events and states to represent process activities.
- Defines a “network” of activities with changing states (via
events)
See figure 3.6, page 57 - States of modeling activity.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
The Unified Process (1)
- A “use-case driven, architecture-centric, iterative and
incremental” software process.
- It integrates different component-based development models
into one scenario-based unified model.
- It emphasizes customer communications through use-cases.
- It is a framework for OO development with UML modeling.
- Developed by James Rumbaugh, Grady Booch, and Ivar
Jacobson in early 1990s, by combing the best of their individual
OOA and OOD methods.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Unified Process (2)
Phase:
Elab or at io n
Inc ept ion
Planning
Communication
inception
Modeling
Construction
Deployment
const r uct ion
Release
soft ware increment
pr o d uct ion
t r ansit io n
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Unified Process (3)
UP Phases
Incept ion
Elaborat ion
Const ruct ion
Transit ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations
#1
#2
#n-1
#n
Product ion
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Unified Process (4)
Incept ion phase
Vision document
Init ial use-case model
Init ial project glossary
Init ial business case
Init ial risk assessment .
Project plan,
phases and it erat ions.
Business model,
if necessary .
One or more prot ot y pes
I nc e pt i o
n
Elaborat ion phase
Use-case model
Supplement ary requirement s
including non-funct ional
Analy sis model
Soft ware archit ect ure
Descript ion.
Execut able archit ect ural
prot ot y pe.
Preliminary design model
Rev ised risk list
Project plan including
it erat ion plan
adapt ed workflows
milest ones
t echnical work product s
Preliminary user manual
See Figure 3.8, page 67: UP Work Products.
Const ruct ion phase
Design model
Soft ware component s
Int egrat ed soft ware
increment
Test plan and procedure
Test cases
Support document at ion
user manuals
inst allat ion manuals
descript ion of current
increment
Transit ion phase
Deliv ered soft ware increment
Bet a t est report s
General user feedback
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Other Process Models (1)
Component-Based Development model: A specialized model that
Integrates OO technology to the engineering and construction
activities of the spiral model.
Used when reuse of COTS components is the main objective.
This model aims to improve software development. (70%
saving in time, 84% saving in cost, 26.2 productive index (the
norm is 16.9) (see page 60)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Other Process Models (2)
Formal Methods (Cleanroom SE): The application of formal
mathematical specifications to develop safety-critical software
applications. The emphasis is on defect-free software using
formal methods during analysis and design.
Issues: cost is high, training is extensive, communication with
customer is difficult.
Aspect-Oriented Model: New “immature” process model that
focus on modeling aspects as customer concerns that cut
cross multiple system functions, features, and information.
(self-reading)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Try to work problems 2, 3, 4, 5, 6, 7, 8, 10, 11, 14, and
15 from Chapter 3, page 69.
No submission is required for practice assignments.
Work it for yourself!
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Last Slide
End of chapter 3