Transcript Transparency Masters for Software Engineering: A

Chapter 2
Software Process Models
1
Process Models
• Often referred to as “conventional” process models
• Prescribe a set of process elements
–
–
–
–
–
–
Framework activities
Software engineering actions
Tasks
Work products
Quality assurance and
Change control mechanisms for each project
• There are a number of process models in operation
• They are not perfect but they provide a useful roadmap for
SW engineering work
• Each process model also prescribes a workflow
2
A Generic Process Model
3
Process Flow
4
Build & Fix Model
• Product is constructed without specifications
or any attempt at design
• Adhoc approach and not well
defined
• Simple two phase model
5
Build & Fix Model
•
Suitable for small programming exercises of 100 or 200 lines
•
Unsatisfactory for software for any reasonable size
• Code soon becomes unfixable & unenhanceable
•
No room for structured design
•
Maintenance is practically not possible
6
The Waterfall Model
• Sometimes called classic life cycle
• Suggests a systematic, sequential approach to software
development
– It reinforces the notion of “define before design” and “design before
code”.
• Works best when
– Requirements of a problem are reasonably well understood
– Well-defined adaptations or enhancements to an existing system must
be made
– Requirements are well-defined and reasonably stable
7
The Waterfall Model
This model is named “waterfall
model” because its diagrammatic
representation resembles a
cascade of waterfalls.
8
The Waterfall Model - Problems
• It is difficult to define all requirements at the beginning of a
project
• This model is not suitable for accommodating any change
• A working version of the system is not seen until late in the
project’s life
• It does not scale up well to large projects.
• Real projects are rarely sequential.
9
The Incremental Model
• It combines elements of the waterfall model applied in
an iterative fashion
• It delivers a series of releases, called increments, that
provide progressively more functionality for customer as
each increment is delivered
• When it is used, the first increment is often a core
product. That is, basic requirements are addressed, but
many supplementary features remain undelivered
• The core product is used by customer. As a result, a plan
is developed for next increment
10
The Incremental Model
11
The Incremental Model
• This model focuses on the delivery of an operational
product with each increment
• Incremental development is particularly useful when
staffing is unavailable for a complete implementation
by the business deadline. Early increments can be
implemented with fewer people, and additional staff
can be added to later increments
• Increments can be planned to manage technical risks
12
The RAD Model
• RAD (Rapid Application Development) is an incremental SW
process model that emphasizes a short development cycle
• RAD model is a “high-speed” adaptation of the waterfall
model, in which rapid development is achieved by using a
component-based construction approach
• If a business application can be modularized in a way that
enables each major function to be completed in less than 3
months, it is a candidate for RAD
– Each major function can be addressed by a separate RAD team and
then integrated to form a whole
13
The RAD Model
14
The RAD Model
• Developed by IBM in 1980
• User participation is essential
15
The RAD Model
• Build a rapid prototype
• Give it to user for evaluation & obtain feedback
• Prototype is refined
With active participation of users
16
The RAD Model - Drawbacks
• Not an appropriate model in the absence of user participation.
• For large, but scalable projects, RAD requires sufficient human
resources to create right number of RAD teams
– Highly specialized & skilled developers are are not easily available.
• If a system cannot be properly modularized, building the
components necessary or RAD will be problematic
– Reusable components are required to reduce development time.
• RAD may not be appropriate when technical risks are high
17
Evolutionary Process Models
• Evolutionary models are iterative
• They are characterized in a manner that enables SW
engineers to develop increasingly more complete versions of
the software
• Example models
– Prototyping model
– The Spiral model
– Concurrent model
18
Evolutionary Models: Prototyping
• The prototype may be a usable program but is
not suitable as the final software product.
• The code for the prototype is thrown away.
However, experience gathered helps in
developing the actual system.
• The development of a prototype might involve
extra cost, but overall cost might turnout to be
lower than that of an equivalent system
developed using the waterfall model.
19
Evolutionary Models: Prototyping
20
Evolutionary Models: Prototyping
• The customer sees what appears to be a working
version of SW, unaware that in the rush to get it
working we haven’t considered overall quality or
long-term maintainability
• The developer often makes implementation
compromises in order to get prototype working
quickly
21
Evolutionary Models: Spiral
• Couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model
• It provides the potential for rapid development of increasingly
more complete versions of the software
• It is a risk-driven process model generator
• It has two main distinguishing features
– Cyclic approach
• Incrementally growing a system’s degree of definition and implementation
while decreasing its degree of risk
– A set of anchor point milestones
• A combination of work products and conditions that are attained along
the path of the spiral
22
Evolutionary Models: Spiral
23
Evolutionary Models: Spiral
• Unlike other process models that end when software is
delivered, the spiral model can be adapted to apply
throughout the life of the computer s/w
• The circuits around the spiral might represent
– Concept development project
– New Product development project
– Product enhancement project
• The spiral model demands a direct consideration of technical
risks at all stages of the project
24
Evolutionary Models: Spiral
• Difficult to convince customers that evolutionary approach is
controllable
• Demands considerable risk assessment expertise and relies on
this expertise for success
• If major risks are uncovered and managed, problems will
occur
25
Evolutionary Models: Concurrent
• Sometimes called concurrent engineering
• Can be represented schematically as a series of framework
activities, s/w engineering actions and tasks, and their associated
states
• Defines a series of events that will trigger transitions from state to
state for each of the s/w engineering activities, actions, or tasks
• Defines a network of activities
• E. g. The modeling activity which existed in none state while initial
communication was completed, now makes a transition into under
development state. If customer indicates that changes in
requirements must be made, modeling activity moves from under
development state into awaiting changes state
26
Evolutionary Models: Concurrent
27
Evolutionary Models: Concurrent
• Is applicable to all types of software development and
provides an accurate picture of the current state of project
• All activities exist concurrently but reside in different states
• Events generated at one point in the process network trigger
transitions among the states
28
Other Process Models
• Component-based development—the process to apply
when reuse is a development objective
• Formal methods—emphasizes the mathematical
specification of requirements
• AOSD—provides a process and methodological approach
for defining, specifying, designing, and constructing
aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely
aligned with the Unified Modeling Language (UML)
29
The Unified Process (UP)
• Developed by I.Jacobson, G.Booch and J.Rumbaugh
• It is a use-case driven, architecture-centric, iterative and
incremental software process
• UP is an attempt to draw on the best features and
characteristics of conventional s/w process models
• Also implements many of the best principles of agile software
development
• UP is a framework for object-oriented software engineering
using UML (Unified Modeling Language)
30
Phases of The Unified Process
31
Phases of UP - Inception
• Defines scope of the project
• Encompasses both customer communication and
planning activities
• Fundamental business requirements are described
through a set of preliminary use-cases
– A use-case describes a sequence of actions that are
performed by an actor (e.g., a person, a machine, another
system) as the actor interacts with the software
• A rough architecture for the system is also proposed
32
Phases of UP - Elaboration
• Encompasses customer communication and modeling activities
• Refines and expands the preliminary use-cases
• Expands the architectural representation to include five different
views of the software
–
–
–
–
–
The use-case model
The analysis model
The design model
The implementation model
The deployment model
• In some cases, elaboration creates an “executable architectural
baseline” that represents a “first cut” executable system
33
Phases of UP - Construction
• Makes each use-case operational for end-users
• As components are being implemented, unit tests
are designed and executed for each
• Integration activities (component assembly and
integration testing) are conducted
• Use-cases are used to derive a suite of acceptance
tests
34
Phases of UP - Transition
• Involves many activities like delivering, training,
supporting, and maintaining the product.
• Software is given to end-users for beta testing
• The software team creates the necessary support
information
– User manuals
– Trouble-shooting guides
– Installation procedures
• At the conclusion of the transition phase, the software
increment becomes a usable software release
35
Phases of UP - Production
• Coincides with the deployment activity of the generic
process
• The on-going use of the software is monitored
• Support for the operating environment
(infrastructure) is provided
• Defect reports and requests for changes are
submitted and evaluated
36
Unified Process Work Products
• Inception
– Vision document
– Initial use-case model
• Elaboration
– Analysis model, design model
• Construction
– Implementation model, deployment model, test model
• Transition
– Delivered software, beta test reports, general user
feedback
37
Initial Development & Evolution Cycles
38
Iterations & Workflow of Unified Process
39
Selection of a Life Cycle Model
Selection of a model is based on:
a) Requirements
b) Development team
c) Users
d) Project type and associated risk
40
Based On Characteristics Of Requirements
41
Based On Status Of Development Team
42
Based On User’s Participation
43
Based On Type Of Project With Associated Risk
44