Software Engineering

Chapter 04
Process Models
Prescriptive Process Models
A prescriptive process model strives for structure and order in software
development

“prescriptive” because they prescribe a set of process elements—

framework activities, software engineering actions, tasks, work products,
quality assurance, and change control mechanisms for each project

prescribes a process flow

The Waterfall
Model
• requirements for a problem
are well understood
• work flows in a reasonably
linear fashion
• waterfall model, sometimes
called the classic life cycle
• a systematic, sequential
approach
 The Waterfall
Model
• Problems
• Real projects rarely follow the sequential flow
that the model proposes
• often difficult for the customer to state all
requirements explicitly
• The customer must have patience
• linear nature of the classic life cycle leads to
“blocking states”
• Inappropriete for never ending change
requirements.
• Variation “The V Model”
Incremental
Process Models
• compelling need to provide a limited set of
software functionality to users quickly and
then refi ne and expand on that functionality
in later software releases.
• combines the elements’ linear and parallel
process flows
• Each linear sequence produces deliverable
“increments” of the software
• first increment is often a core product.
• As a result of use and/or evaluation, a plan is
developed for the next increment
Evolutionary Process
Models (Prototyping)
• customer defines a set of general
objectives for software
• to better understand what is to be
built when requirements are fuzzy
• prototype serves as a mechanism for
identifying software requirements.
• Prototypes are built as “throwaways,”
• implementation compromises
• Prototype delivered as “Product”
Evolutionary Process Model (Spiral Model)
• couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model.
• risk -driven process model generator
• cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk
• anchor point milestones for ensuring stakeholder commitment to
feasible and mutually satisfactory system solutions
• software is developed in a series of evolutionary releases
 Spiral Model
• first circuit around the spiral might result in
the development of a product specification
• subsequent passes around the spiral might
be used to develop a prototype and then
progressively more sophisticated versions of
the software
• remains operative until the software is
retired
• realistic approach to the development of
large-scale systems and software
• demands considerable risk assessment
expertise
 Specialized Process Models

• Component Based Development

• Commercial off-the-shelf (COTS) software components
• targeted functionality with well-defined interfaces
• incorporates the following steps
1. Available component-based products are researched and evaluated for the
application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.
• leads to software reuse, reduction in development cycle time and a reduction in project cost
 Formal Methods Model

• leads to formal mathematical specification of computer software

• by applying a rigorous, mathematical notation
• Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily
• Offers the promise of defect-free software
• Problems
• The development of formal models is currently quite time consuming and expensive.
• Because few software developers have the necessary background to apply formal
methods, extensive training is required.
• It is difficult to use the models as a communication mechanism for technically
unsophisticated customers.
 “use case driven, architecture centric, iterative
and incremental”

implements many of the best principles of agile

software development
The Unified
Process importance of customer communication and
streamlined methods for describing the
customer’s view of a system
process flow that is iterative and incremental
Unified Process Model
 Personal Software Process

• The Personal Software Process (PSP) emphasizes personal measurement of

both the work product that is produced and the resultant quality of the work
product.
• The PSP model defines five framework activities:
• Planning – develops both size and resource estimates
• High Level Design – component design is created
• High-level design review – Verification to uncover errors in design
• Development – Code is generated, reviewed, compiled, and tested
• Postmortem – effectiveness of the process is determined
• PSP represents a disciplined, metrics-based approach to software
engineering
• PSP is intellectually challenging and demands a level of commitment
Team Software Process
• to build a “self-directed” project team that organizes itself to produce high-quality
software
• Accelerate software process improvement
• Phases: project launch, high-level design, implementation, integration and test, and
postmortem
• makes use of a wide variety of scripts, forms, and standards
• Scripts” define specific process activities
• Team members set project objectives, adapt the process to meet their needs, control the
project schedule