Unit- 2

Prescriptive Process
Models
• Prescriptive Process Models Process Framework
• Capability Maturity Model Integration
• Waterfall Model
• Incremental & RAD Models
• Prototyping
• Spiral Model
• Concurrent Development Model.
• Agile Process Models Agility
• Agile Process
• Extreme Programming
• Adaptive Software Development
• SCRUM
 Prescriptive Process Models

 Prescriptive process models advocate an

orderly approach to software engineering
“ A Process Model is a descriptive and
diagrammatic representation of the software
life cycle.”
A software life cycle is the series of identifiable
stages that a software product undergoes
during its lifetime.
A Process Framework

Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
Framework Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design

 Construction
 Code generation
 Testing

 Deployment
 Umbrella Activities
 Software project management
 Formal technical reviews

 Software quality assurance

 Software configuration management

 Work product preparation and production

 Reusability management

 Measurement

 Risk management
 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

 1. Waterfall Model

 Here, steps (phases) are arranged in linear

order
 A step take inputs from previous step, give output
to next step (if any)
 Exit criteria of a step must match with entry
criteria of the succeeding step
 It follows ‘specify, design, build’ sequence
 Continue..
 Waterfall Model…
 Produce many intermediate deliverables, usually documents
 Have standard format defined

 Act as a ‘baseline’ for future reference (part of

contractual obligations)
 Important for quality assurance, project management, etc.

 Facilitates change of people from step to step

When requirements are clearly defined, waterfall model

is an ideal model for development software.
 The Waterfall Model

Co m m u n ic a t io n
p ro je c t in it ia t io n Planning
re q u ire m e n t g a t h e rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De p lo y m e nt
c ode
t es t d e liv e ry
s u p p o rt
f e e d ba c k
 Deliverables in Waterfall model
 Each step of waterfall model has certain deliverable
 Project plan and feasibility report
 Requirements document (SRS: Software Requirement
Specifications)
 System design document
 Detailed design document
 Test plans and Test reports
 Software Manuals (user manual, installation manual)
 Source code (in executable form)
 V & V review report of each step
Shortcomings of Waterfall model
 Requirements may not be clearly known,
especially for applications not having existing
(manual) counterpart
 Railway reservation: manual system existed, so
SRS can be defined
 On-line container management for railways – new

 Knowledge management for central bank - new

 Continue…
 Shortcomings…
 Waterfall model assumes that the requirements
are quite stable
 Requirements change with time during project
life cycle itself
 Users may find solution of little use
 Better to develop in parts in smaller increments

So other different approaches are suggested to take

care of these shortcomings
• Human Resource Management Systems
(HRMS)
• Supply Chain Management Systems,
Customer Relationship Management
(CRM) systems
• Inventory Management Systems, Point
of Sales (POS)
 Exercise

 Find two applications where

 Waterfall model is ideal for development
 Waterfall model can’t be used
 2. Prototyping Model
 When customer or developer is not sure
 of requirements (inputs, outputs)
 of algorithms, efficiency, human-machine interaction
 A throwaway prototype built from currently known user
needs
 Quick design focuses on what is unknown, or not
properly understood
 Many iterations of prototype may be required for
changed or new requirements
 Final product follows the standard waterfall type of
methodology
Prototyping Model

Qu ic k p la n

Co m m u n ic a t io n

Mo d e lin g
Qu ic k d e s ig n

De p loym e nt
De liv e ry
& Fe e d b ac k Co n s t ru c t io n
of
p ro t o t y p e
 Limitations of Prototyping
 Customer may want prototype itself !
 Developer may continue with implementation
choices made during prototyping
 may not give required quality, performance,….
 Good tools need to be acquired for quick
development of prototype
 May lead to a higher project cost

So when we have such difficulties based on the

requirements or based on the situation we might
choose some other development methodologies
 3. Incremental model
 Useful for product development where developers
define scope, features to serve many customers
 Example : database products, payroll or accounting
packages
 Early version with limited feature important to
establish market and get customer feedback
 Initial version may follow any method (waterfall)
 A list of features for future versions maintained
 The Incremental Model

incre m e nt # n
Co m m u n i c a t i o n
Pla n n in g

M o d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n
code De p l o y m e n t
t est d e l i v e ry
fe e d b a c k

d e liv e ry o f
incre m e nt # 2 n t h in cre me n t

Co m m u n i c a t i o n
Pla n n in g

Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t

Co m m u n i c a t i o n
Pla n n in g
Mo d e lin g
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode
d e liv e ry o f
De p l o y m e n t
t est d e l i v e ry
fe e d b a c k

1 s t in cre me n t

project calendar t ime

 4. Spiral Model
 Each loop represents a phase of the software process
 Number of loops not fixed
 Provides direct support for coping with the project risks
 During each iteration, risk analysis is done through
prototype construction
 After several iterations along the spiral, all risks are
resolved
 Then waterfall model can be used for software
development
 Spiral model is a meta model, since it subsumes all the
discussed models
 The Spiral Model

planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test
5. Rapid Application Development
(RAD) Model
 Incremental software process model that
emphasizes a short development cycle.
 Quick development is achieved by using
component-based construction approach
 Prerequisite:
 Well understood requirements
 Constrained project scope
 Short development time (< 3 months)
 Business application can be easily modularized
 The RAD Model
Te am # n
Mo d e lin g
bu s in e s s m o d e lin g
da t a m od e lin g
pro c e s s m o d e lin g

C o n s t ru c t io n
c om p o n e n t re u s e
Te am # 2 a ut o m a t ic c o d e
Co m m u n ic at io n g e n e ra t io n
t e s t in g
Mo d e l ing
b u s in e s s m o d e lin g
d a t a m o d e lin g
p ro ce ss m o d e lin g

Plan n in g
Co ns t ruc t io n De p lo ym e n t
Te am # 1 co m p o n e n t re u s e
in t e g rat io n
a u t o m a t ic co d e
g e n e ra t io n d e liv e ry
Mo d e lin g t e s t in g fe e d b ack
b u s in e s s m o d e lin g
d at a m o d e lin g
p ro ce s s mo d e lin g

Co n s t ru c t io n
co m p o n e n t re u s e
au t o m at ic co d e
g e n e rat io n
t e s t in g

6 0 - 9 0 d ays
 Limitations of RAD model

1. For large and scalable projects, it requires

sufficient human resources
2. Commitment from developer and customer is
must for rapid-fire activities
3. If system can’t be properly modularized,
creates problem
4. RAD may not be appropriate when technical
risks are high
 Comparison
 Waterfall model
 Supports no mechanism to handle the errors in
phases
 Iterative model
 Most widely used
 Simple to understand and use

 Suitable only for well-understood problems

 Not suitable for projects with risks

 Comparison
 Prototyping model
 Suitable for projects for which either user requirements or the
underlying technical aspects are not well understood
 Popular for development of the user-interface part of the
projects
 RAD model
 Suitable for large problems which can be decomposed into a set
of modules
 Spiral model
 Suitable for technically challenging software products that are
prone to risks
 Model is itself much more complex as compared to others
 Comparison

 From the viewpoint of the customer…..

 Initially customer confidence is high irrespective of the

development model followed
 During lengthy processes, it drops off as no working
product is immediately visible
 Incremental model lets the customer experiment with the
working product much earlier
 Gradual introduction of product via incremental phases
provides time to customer to adjust
 From financial viewpoint, customer can order the
increments as and when he can afford them
 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.”
Kent Beck et al

30
 What is “Agility”?
 Effective (rapid and adaptive) response to change
 Effective communication among all stakeholders

 Drawing the customer onto the team

 Organizing a team so that it is in control of the

work performed
Yielding …
 Rapid, incremental delivery of software

31
 Agile
Change is what software development is very much
about.
 Changes in the software being built

 Changes to the team members

 Changes because of new technology

An agile team recognizes that software is developed

by individuals working in teams and skills of these
people, their ability to collaborate is at the core for
the success of the project
32
 An Agile Process
 Is driven by customer descriptions of
what is required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a
heavy emphasis on construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur

33
Principles for those who want to
achieve agility

34
 Extreme Programming (XP)
 The most widely used agile process, originally
proposed by Kent Beck
 XP Planning
 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”(no of customer

stories implemented during the first release) is used to help
define subsequent delivery dates for other increments

35

Extreme
XP Design
Programming (XP)
 Follows the KIS(Keep it Simple) principle
 Encourage the use of CRC (class responsibility collaborator)cards
 For difficult design problems, suggests the creation of “ spike solutions”—a design
prototype
 Encourages “refactoring”—an iterative refinement of the internal program design

 XP Coding
 Recommends the construction of a unit test for a store before coding commences
 Encourages “pair programming”. XP recommends that two people work together….why?
 Refactoring is the process of changing the software system in such a way that it does not
alter the external behavior of the code yet improves the internal structure

 XP Testing
 All unit tests are executed daily
 “Acceptance tests” are defined by the customer and executed to assess customer visible
functionality

36
Extreme Programming (XP) sp ike so lut io ns
simp le d esig n
p ro t o t yp es
CRC card s
user st o ries
values
accep t ance t est crit eria
it erat io n p lan

refact o ring

p air
p ro g ramming

Release
s o ft wa re in cre m e n t unit t est
p roje ct v e lo cit y com p ut e d co nt inuo us int eg rat io n

accep t ance t est ing

37
 Adaptive Software
Development
 Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning

 Component-based focus

 Uses “time-boxing”

 Explicit consideration of risks

 Emphasizes collaboration for requirements gathering

 Jelled team is essential for collaboration

 Criticize , assistance, work as harder, communication prob.

 Emphasizes “learning” throughout the process

 Focus groups , Formal Technical Review, Postmortems (addressing

its own performance , improve the approach)

38
 Adaptive Software
Development
ad ap t ive cycle p lanning Req uirement s g at hering
use s m issio n st at e m e nt JAD
pro je c t c o nst raint s m ini-sp e cs
b asic re quire m e nt s
t ime-b o xed release p lan

Release
s o ft wa re in cre m e n t
a d ju s t m e nt s f o r s u bs e q u e n t cy cle s
co mp o nent s imp lement ed / t est ed
f o cus g ro up s f o r f eed b ack
f o rm al t echnical revie ws
p o st mo rt ems

39
 Scrum
 Originally proposed by Schwaber and Beedle
 Scrum—distinguishing features
 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
40
Scrum

41
 Capability Maturity Model Integration
(CMM)
 The Software Engineering Institute (SEI) has developed
a model based on capabilities that should be present in
organizations
 It helps organizations to improve the quality of
developed software
 Used for capability evaluation and software process
assessment

 Level 1: Initial
 ad hoc activities, few or no processes defined, success
depends on individual effort, low quality
 Capability Maturity Model Integration
(CMM)
 Level 2: Repeatable
 basic activities like tracking cost and schedule
are established, necessary process discipline is in
place to repeat earlier success

 Level 3: Defined
 processes for management and development are
defined and documented, though the process and
product qualities are not measured
Capability Maturity Model Integration
(CMM)
 Level 4: Managed
 Focus on product metrics e.g. product size,
reliability, time complexity, understandability
 Process metrics e.g. productivity, average defect
correction time, average number of failures
detected during testing per LOC
 Level 5: Optimizing
 Focus on continuous process improvement, defect
prevention, process change management,
technology change management
 Summary
 Adherence to a software life cycle model encourages the
team members to perform activities in a systematic and
disciplined manner.
 We discussed different categories of life cycle models in
this unit.
 Iterative model is the most widely used life cycle model
so far.
 The classical waterfall model can be considered the basic
model and all other cycle model are embellishments of
this model
 Questions!
 Which life cycle model would you follow for
developing software for each of the following
applications? Justify your choice.
1. A well-understood data processing application
2. A new library automation software that would link
various libraries in the city
3. A new text editor
4. The graphical user interface part of a large software
product
5. An extremely large software that would provide,
monitor, and control cellular communication among its
subscribers using a set of revolving satellites