Chapter 3 Prescriptive Process Models - PowerPoint PPT Presentation

1 / 29
About This Presentation
Title:

Chapter 3 Prescriptive Process Models

Description:

Prescriptive process models prescribe a distinct set of activities, actions, ... Many supplementary features (known & unknown) remain undelivered ... – PowerPoint PPT presentation

Number of Views:45
Avg rating:3.0/5.0
Slides: 30
Provided by: roger286
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com