Chapter 3 Prescriptive Process Models

1
Chapter 3Prescriptive Process Models
2
Overview

• Prescriptive process models prescribe a distinct
  set of activities, actions, tasks, milestones,
  and work products required to engineer high
  quality software.
• Prescriptive software process models are adapted
  to meet the needs of software engineers and
  managers for a specific project.
• Prescriptive software models provide stability,
  control, and organization to a process that if
  not managed can easily get out of control.
• Framework activities for a particular process
  model may be organized into a process flow that
  may be linear, incremental, or evolutionary.

3
Overview (cont)

• The software engineer's work products (programs,
  documentation, data) are produced as a
  consequence of the activities defined by the
  software process.
• The best indicators of how well a software
  process has worked are the quality, timeliness,
  and long-term viability of the resulting software
  product.

4
Objectives

• Introduce process models and the roles they play
  in a software engineering environment
• Give examples of some of the most common process
  models
• Provide means of comparing process model

5
Software Process

• Aimed to control the activities of software
  development and as such improve quality...
• A structured set of activities for
• Specifying,
• Designing,
• Implementing and
• Testing software systems
• A software process model is an abstract
  representation of a process
• a description of a process from a particular
  perspective

6
Software Process Models

• Software process models are general approaches
  for organizing a project into activities
• Help the project manager and his team to decide
• What work should be done
• In what sequence to perform the work
• The models should be seen as aids to thinking,
  not rigid prescriptions of the way to do things
• Each project ends up with its own unique plan
  because
• Projects differs in the nature of the project,
  people doing the work, and the work environment

7
Prescriptive Models

• Prescriptive process models advocate an orderly
  approach to software engineering
• Organize framework activities in a certain order
• Originally proposed to bring order to the chaos
  of software development
• They brought order to software engineering work
  and provide reasonable guidance to software teams
  
• Adopt following activities
• Communication
• Planning
• Modeling
• Construction
• Deployment
• Differ in
• Emphasis of these activities
• Manners in which the framework is invoked and its
  relationship with other activities

8
Prescriptive Models

• 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?

9
Software Processes

• Every software engineering organization needs to
  describe a set of framework activities for the
  processes it adopts
• Each framework activity needs to be populated
  with software engineering actions
• Each engineering action needs to be defined in
  terms of a task set that defines the work and
  work products needed to meet the development
  goals
• The resulting process model should be adapted to
  accommodate the nature of the specific project,
  people doing the work, and the work environment

10
Software Processes (cont)

• Regardless of the process model selected,
  software engineers will chose a generic process
  framework that includes these activities
  communication, planning, modeling, construction,
  and deployment
• Each process model will prescribe a set of
  process elements (framework activities, software
  engineering actions, tasks, work products,
  quality assurance, and change control mechanisms)
  and a workflow (the manner in which the process
  elements are interrelated)
• All software process models discussed in this
  chapter can accommodate the generic framework
  activities described previously

11
The Waterfall Model
Old fashioned but reasonable approach when
requirements are well understood
12
Limitations of the waterfall model

• The model implies that you should attempt to
  complete a given stage before moving on to the
  next stage
• Does not account for the fact that requirements
  constantly change.
• It also means that customers can not use anything
  until the entire system is complete.
• The model makes no allowances for prototyping.
• Assumes understanding of problem and full
  requirements early on
• It implies that you can get the requirements
  right by simply writing them down and reviewing
  them.
• Inflexible partitioning of the project into
  distinct stages makes it difficult to respond to
  changing customer requirements.

13
Critique of Waterfall Model continued

• Followed systematic approach to development
• The model implies that once the product is
  finished, everything else is maintenance.
• Assumes patience from customer
• Surprises at the end are very expensive
• Some teams sit ideal for other teams to finish
• Therefore, this model is only appropriate when
  the requirements are well-understood and changes
  will be fairly limited during the design process.

14
The Incremental Model
Delivers software in small but usable pieces,
each piece builds on pieces already delivered
15
The Incremental Model

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality.
• First Increment is often core product
• Includes basic requirement
• Many supplementary features (known unknown)
  remain undelivered
• First Increment is used or evaluated
• A plan of next increment is prepared
• Modifications of the first increment
• Additional features of the first increment
• It is particularly useful when enough staffing is
  not available for the whole project
• Increment can be planned to manage technical risks

16
The Incremental Model

• User requirements are prioritised and the highest
  priority requirements are included in early
  increments.
• Once the development of an increment is started,
  the requirements are frozen though requirements
  for later increments can continue to evolve.
• Customer value can be delivered with each
  increment so system functionality is available
  earlier.
• Early increments act as a prototype to help
  elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
  receive the most testing.

17
The RAD Model
Makes heavy use of reusable software components
with an extremely short development cycle
18
Critique of RAD

• If requirements are well understood and project
  scope is constrained
• Very short development time
• Construction emphasizes the reuse and the
  automatic code generation
• For large but scalable projects
• RAD requires sufficient human resources
• Projects fail if developers and customers are not
  committed in a much abbreviated time-frame
• Problematic if system can not be modularized
• Not appropriate when technical risks are high

19
Evolutionary Models Prototyping
Good first step when customer has a legitimate
need, but is clueless about the details,
developer needs to resist pressure to extend a
rough prototype into a production product
Quick plan
Modeling Quick design
Construction of prototype
20
Evolutionary Models The Spiral
Couples iterative nature of prototyping with the
controlled and systematic aspects of the linear
sequential model
21
(No Transcript)
22
Evolutionary Models Concurrent
Similar to spiral model often used in development
of client/server applications
23
Specialized Process Models

• Component based development spiral model
  variation in which applications are built from
  prepackaged software components called classes
• Formal methodsemphasizes the mathematical
  specification of requirements. Rigorous
  mathematical notation used to specify, design,
  and verify computer-based systems
• Aspect-Oriented Software Development
  (AOSD)provides a process and methodological
  approach for defining, specifying, designing, and
  constructing aspects like user interfaces,
  security, and memory management that impact many
  parts of the system being developed

24
Unified Process

• Use-case driven, architecture centric, iterative,
  and incremental software process closely aligned
  with the Unified Modeling Language (UML)
• Attempts to draw on best features of traditional
  software process models and implements many
  features of agile software development
• Phases
• Inception phase (customer communication and
  planning)
• Elaboration phase (communication and modeling)
• Construction phase
• Transition phase (customer delivery and feedback)
  
• Production phase (software monitoring and support)

25
The Unified Process (UP)
inception
elaboration
inception
26
UP Phases
27
UP Work Products
28
Attributes for Comparing Process Models

• Overall flow and level of interdependencies among
  tasks
• Degree to which work tasks are defined within
  each framework activity
• Degree to which work products are identified and
  required
• Manner in which quality assurance activities are
  applied

29
Attributes for Comparing Process Models (cont)

• Manner in which project tracking and control
  activities are applied
• Overall degree of detail and rigor of process
  description
• Degree to which stakeholders are involved in the
  project
• Level of autonomy given to project team
• Degree to which team organization and roles are
  prescribed