Prescriptive Process Models

1
• A stakeholder is anyone who has a stake in the
successful outcome of the project—business
managers, end users, software engineers,
support people, etc.

2
 Prescriptive Models
• Prescriptive process models advocate an
orderly approach to software engineering

3
• The waterfall model, sometimes called the classic life
cycle, suggests a systematic, sequential approach to
software development that begins with customer
specification of requirements and progresses
through planning, modeling, construction, and
deployment, culminating in ongoing support of the
completed software.

4
The Waterfall
Model

5
 The Waterfall
• Model
A variation in the representation of the waterfall model is called
the V-model.
• It depicts the relationship of quality assurance actions to the
actions associated with communication, modeling, and early
construction activities.
• As a software team moves down the left side of the V, basic
problem requirements are refined into progressively more
detailed and technical representations of the problem and its
solution.

6
 The Waterfall
Model
Once code has been generated, the team moves up the right side of
the V, essentially performing a series of tests (quality assurance
actions) that validate each of the models created as the team moved
down the left side.

The V-model provides a way of visualizing how verification and

validation actions are applied to earlier engineering work.

7
The Waterfall
Model

8
Use cases:
Projects where failures and downtimes are unacceptable (e.g.,
medical software, aviation fleet management software).

9
• Real projects rarely follow the sequential flow that the
model proposes .As a result ,changes can cause
confusion as the project team proceeds.
• It is often difficult for the customer to state all
requirements explicitly.
• Customer must have patience.
Bradac found that the linear nature of the waterfall model
leads to “Blocking states”
The waterfall model can serve as a useful process model
in situations where requirements are fixed and work is to
proceed to completion in a linear manner.
10
• Linear nature of the classic life cycle leads to
“blocking states” in which some project team
members must wait for other members of the
team to complete dependent tasks. In fact,
the time spent waiting can exceed the time
spent on productive work! The blocking states
tend to be more prevalent at the beginning
and end of a linear sequential process.

11
• Use cases:
i. Simple small or mid-sized projects with clearly defined and
unchanging requirements (small company website
development).
ii. Projects with the need for stricter control, predictable budget
and timelines (e.g., governmental projects).
iii.Projects that must adhere to multiple rules and regulations
(healthcare projects).
iv.Projects where a well-known technology stack and tools are
used.

12
 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
• 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.
• Incremental model focus more on delivery of operation product with each
increment.
 The Incremental
Model
increment #n
Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

delivery of
increment # 2 nt h increment

Communic at ion
Planning

Modeling
analys is C o n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
delivery of
increment # 1 2nd increment

Communic at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign c ode
t es t
De p l o y m e n t
d e l i v e ry delivery of
fe e dba c k

1st increment

project calendar time

14
Advantages of Incremental model:
•Generates working software quickly and early during the
software life cycle.
•This model is more flexible – less costly to change scope and
requirements.
•It is easier to test and debug during a smaller iteration.
•In this model customer can respond to each built.
•Lowers initial delivery cost.
•Easier to manage risk because risky pieces are identified and
handled during it’d iteration.

15
• The incremental model combines elements of the waterfall
model applied in an iterative fashion.
• The model applies linear sequences in a staggered fashion as
calendar time progresses.
• When an increment model is used, the 1st increment is often a core
product. The core product is used by the customer.
• As a result of use and / or evaluation, a plan is developed for the
next increment.
• The plan addresses the modification of the core product to better
meet the needs of the customer and the delivery of additional
features and functionality.

16
• The process is repeated following the delivery of each increment,
until the complete product is produced.
• If the customer demands delivery by a date that is impossible to
meet, suggest delivering one or more increments by that date and
the rest of the Software later.

17
Disadvantages of Incremental model:
•Needs good planning and design.
•Needs a clear and complete definition of the whole system
before it can be broken down and built incrementally.
•Total cost is higher than waterfall.

Use cases:
Large, mission-critical enterprise applications that preferably
consist of loosely coupled parts, such as micro services or web
services.

18
 Evolutionary Process Model
• Produce an increasingly more complete version of the
software with each iteration.
• Evolutionary Models are iterative.
• Evolutionary models are:
– Prototyping
– Spiral Model
– Concurrent Development Model
 Prototyping cohesive
• Best approach when:
– Objectives defines by customer are general but does not have details like input,
processing, or output requirement.
– Developer may be unsure of the efficiency of an algorithm, O.S., or the form that
human machine interaction should take.
• It can be used as standalone process model.
• Model assist software engineer and customer to better understand what is to be
built when requirement are fuzzy.
• Prototyping start with communication, between a customer and software engineer to
define overall objective, identify requirements and make a boundary.
• Going ahead, planned quickly and modeling (software layout visible to the
customers/end-user) occurs.
• Quick design leads to prototype construction.
• Prototype is deployed and evaluated by the customer/user.
• Feedback from customer/end user will refine requirement and that is how iteration
occurs during prototype to satisfy the needs of the customer.
 Prototyping (cont..)
 Prototype can be serve as “the first system”.
 Both customers and developers like the prototyping paradigm.
 Customer/End user gets a feel for the actual system
 Developer get to build something immediately.
Problem Areas:
 Customer cries foul and demand that “a few fixes” be applied to
make the prototype a working product, due to that software quality
suffers as a result.
 Developer often makes implementation in order to get a prototype
working quickly without considering other factors in mind like OS,
Programming language, etc.
Customer and developer both must be agree that the prototype is built
to serve as a mechanism for defining requirement.
Evolutionary Models:
Prototyping Quick plan
Quick
Communication plan
communication

Modeling
Modeling
Quick design
Quick design

Deployment
Deployment
Delivery
delivery & Construction
& Feedback Construction
feedback of
of prototype
prototype

22
 Spiral Model
 Couples iterative nature of prototyping with the controlled and systematic
aspects of the linear sequential model
• It provide potential for rapid development of increasingly more complete
version of the software.
• Using spiral, software developed in as series of evolutionary release.
– Early iteration, release might be on paper or prototype.
– Later iteration, more complete version of software.
• Divided into framework activities (C,P,M,C,D).
• Each activity represent one segment.
• Evolutionary process begins in a clockwise direction, beginning at the center
risk.
• First circuit around the spiral might result in development of a product
specification. Subsequently, develop a prototype and then progressively more
sophisticated version of software.
• Unlike other process models that end when software is delivered.
• It can be adapted to apply throughout the life of software.
Spiral Model
• A spiral model is divided into a set of framework activities
defined by the software engineering team.
• Each of the framework activities represent one segment of the
spiral.
• As this evolutionary process begins, the software team performs
activities that are implied by a circuit around the spiral in a
clockwise direction, beginning at the center.
• Anchor point milestones —a combination of work products and
conditions that are attained along the path of the spiral—are noted
for each evolutionary pass.

25
 Spiral Model (cont.)
i) Concept Development Project:
• Start at the core and continues for multiple iterations until until development
is complete.
• If concept is developed into an actual product, the process proceeds outward
on the spiral and a “new product development project” commences.
ii) New Product Development Project:
• New product will evolve through a number of iterations around the spiral.
• Later, a circuit around spiral might be used to represent a “Product
Enhancement Project”
iii) Product Enhancement Project:
• There are times when process is dormant or software team not developing new
things but change is initiated, process start at appropriate entry point.
Problem Area:
• It may be difficult to convince customers (particularly in contract
situations) that the evolutionary approach is controllable.
• If a major risk is not uncovered and managed, problems will
undoubtedly occur.

Use cases:
• Projects with unclear business needs or too ambitious/innovative
requirements.
• Projects that are large and complicated.
• Research and development (R&D) activity or the introduction of a
new service or a product.
Advantages of the Spiral Model
• Realistic approach to the development because
the software evolves as the process progresses.
In addition, the developer and the client better
understand and react to risks at each
evolutionary level.
• It maintains a systematic stepwise approach,
like the classic waterfall model, and also
incorporates into it an iterative framework that
more reflect the real world.
28
Disadvantages of the Spiral Model
• One should possess considerable risk-assessment
expertise
• It has not been employed as much proven models (e.g.
the Waterfall Model) and hence may prove difficult to
‘sell’ to the client.

29
Evolutionary Models: Concurrent

30
 Concurrent Development Model
• It represented schematically as series of major technical activities, tasks,
and their associated states.
• It is often more appropriate for system engineering projects where different
engineering teams are involved.
• The activity-modeling may be in any one of the states for a given time.
• All activities exist concurrently but reside in different states.
E.g.
• The analysis activity (existed in the none state while initial customer
communication was completed) now makes a transition into the under
development state.
• Analysis activity moves from the under development state into the awaiting
changes state only if customer indicates changes in requirements.
• Series of event will trigger transition from state to state.
E.g. During initial stage there was inconsistency in design which was uncovered.
This will triggers the analysis action from the Done state into Awaiting
Changes state.
 Still Other Process
• Component based Models
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

32
• Unified Process
1. A “use-case driven, architecture-centric, iterative and
incremental” software process closely aligned with the Unified
Modeling Language (UML).
2. UP recognizes the importance of customer communication
and streamlined methods for describing the customer’s view of
a system ( i.e. the use case)

33
• A use-case is a text narrative or template that describes a
system function/features from the user’s point of view. A use-
case is written by the user and serves as a basis for the creation of
a more comprehensive analysis model.

34
The Unified Process (UP)

35
1.Inception Phase:
i. It includes both customer communication and planning
activities.
ii. By collaborating with the customer and end users.
iii.Business requirements for the software are identified.
iv.A rough architecture for the system is proposed.
v. Plan for the iterative.
vi.Fundamental business requirements are described through a set of
Preliminary use-cases that describe what features and functions
are described by each major class of users.
vii.Use –case describes a sequence of actions that are performed by
an actor(Ex: Person, Machine, another system) as the actor
interacts with the software.
36
2. Elaboration Phase:
i. It includes the customer communication modelling activities of
the generic process model.
ii. Elaboration refines and expands the preliminary use-cases that
were developed as part of the inception phase and expands the
architectural representation to include 5 different views of the
software.
 Use-case Model
 Analysis Model
 Design Model
 Implementation Model
 Deployment Model

37
iii.Elaboration creates an “executable architectural baseline”
executable system.
iv. The architectural baseline demonstrates the viability (possibility)
of the architecture but does not provide the features and
functions required to use the system.
V. The plan is carefully reviewed at the culmination(end) of the
elaboration phase to ensure that – Scope
- Risks
- Delivery dates remain reasonable
vi. Modifications to the plan may be made at this time.

38
3.Construction Phase:
i. Refines and then translates the design model into implemented
software components.
ii. All necessary and required features and functions of the software
increment(i.e. the release) are then implemented in the source
code.
iii.As components are being implemented, unit tests are designed
and executed for each.

39
4.Transition Phase:
i. Transfers the software from the developer to the end-user for beta
testing and acceptance.
ii. Beta testing is a controlled testing action in which the software is
used by actual end-users with the intent of uncovering defects and
deficiencies.
iii.Software team creates the necessary support information (Ex:
User manuals, Installation procedures)
iv.At the conclusion of the translation phase, the software increment
becomes a usable software release.

40
5. Production Phase:
i. On –going monitoring and support are conducted.
ii. Defects reports and requests for changes are submitted and
evaluated.

Use cases:
Large and high-risk projects, especially, use-case based development
and fast development of high-quality software.

41