1

SE311-Software Construction and development

Week 2 Lecture 3-4

Instructor: Ali Haider

 Prescriptive Models
• Originally proposed to bring order to chaos.
• Prescriptive process models advocate an orderly approach to software engineering.
However, will some extent of chaos (less rigid) be beneficial to bring some creativity?

That leads to a few questions …

• If prescriptive process models strive for structure and order (prescribe a set of process
elements and process flow), 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?
17
 The Waterfall Model
Communication
project initiation Planning
requirement estimatin
gathering Modeling
g
analys Construction
schedulin
is
g cod Deployment
design delivery
tracking e
test support
feedbac
k

It is the oldest paradigm for SE. When requirements are well

defined and reasonably stable, it leads to a linear fashion.

(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements

explicitly. Blocking state. 3. code will not be released until very late.)

18
The classic development.
to software life cycle suggests a systematic, sequential approach
 A variation of waterfall model
The V-Model depicts the relationship of
quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.

Team first moves down the

left side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.

19
The Incremental Model

increment
#n
Co m m u n i c a t i o
n Planning
Modelin
g Co n s t ru c t i o n
analysis
code De p l o y m e n
design
test t
d e l i v e ry
fe e d b a c k

delivery of
increment # nth
increment
2
Co m m u n i c a t i o
n Planning
Modelin
g analysis Co n s t ru c t i o n
design code De p l o y m e n

test
t d e l i v e ry
fe e d b a c k
delivery of
increment # 2nd
1 increment
Co m m u n i c a t i o
n Planning
Modeling
analysi Co n s t ru c t i o n
s
design
code
test
De p l o y m e n
t d e l i v e ry delivery of
fe e d b a c k
1st
increment

20

project calendar
time
 The Incremental Model

• When initial requirements are reasonably well defined, but the overall
scope of the development effort precludes a purely linear process. A
compelling need to expand a limited set of new functions to a later
system release.
• It combines elements of linear and parallel process flows. Each linear
sequence produces deliverable increments of the software.
• The first increment is often a core product with many supplementary
features. Users use it and evaluate it with more modifications to better
meet the needs.
21
 Evolutionary Models
• Software system evolves over time as requirements often change as
development proceeds. Thus, a straight line to a complete end product is not
possible. However, a limited version must be delivered to meet competitive
pressure.
• Usually a set of core product or system requirements is well understood, but
the details and extension have yet to be defined.
• You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
• It is iterative that enables you to develop increasingly more complete
version of the software. 22

• Two types are introduced, namely Prototyping and Spiralmodels.

Evolutionary Models: Prototyping
• When to use: Customer defines a set of general objectives but does not identify detailed
requirements for functions and features. Or Developer may be unsure of the efficiency of
an algorithm, the form that human computer interaction should take.
• What step: Begins with communication by meeting with stakeholders to define the
objective, identify whatever requirements are known, outline areas where further
definition is mandatory. A quick plan for prototyping and modeling (quick design)
occur. Quick design focuses on a representation of those aspects the software that will
be visible to end users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s comments will be used
to refine requirements.
• Both stakeholders and software engineers like the prototyping paradigm. Users get a feel
for the actual system, and developers get to build something immediately. However,
engineers may make compromises in order to get a prototype working quickly. The less-23
than-ideal choice may be adopted forever after you get used to it.
Evolutionary Models: Prototyping

Q u ick p lan
Quick
Com m u n ication plan
communication
Mo d e lin g
Modeling n
Q u ick d e sig
Quick design

Deployment
Deployment
De live ry
Construction
delivery &
& Fe e dback of Con
prototype
stru ction
feedback Construction
of
prototype
of prototype

24
 Evolutionary Models: The Spiral
• It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model
and is a risk-driven process model generator that is used to guide multi-stakeholder concurrent engineering of
software intensive systems.
• Two main distinguishing features: one is cyclic approach for incrementally growing a system’s degree of
definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones
for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• A series of evolutionary releases are delivered. During the early iterations, the release might be a model or
prototype. During later iterations, increasingly more complete version of the engineered system are produced.
• The first circuit in the clockwise direction might result in the product specification; subsequent passes around the
spiral might be used to develop a prototype and then progressively more sophisticated versions of the software.
Each pass results in adjustments to the project plan. Cost and schedule are adjusted based on feedback. Also, the
number of iterations will be adjusted by project manager.
• 25
Evolutionary Models: The
Spiral planning
estimatio
n
schedulin
g risk
communicati analysis
on
modeli
ng
analysi
star s
t design

deployme
nt constructio
delivery n
feedback code
26
test
 Three Concerns on
Evolutionary Processes
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that
the process will fall into chaos. On the other hand if the speed is too
slow then productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the
development over zero defects. Extending the development in order to reach
high quality could result in a late delivery of the product when the
opportunity niche has disappeared.
27
 Concurrent Model
• Allow a software team to represent iterative and concurrent elements of any of
the process models. For example, the modeling activity defined for the spiral model
is accomplished by invoking one or more of the following actions: prototyping,
analysis and design.
• The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition into
the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
• Concurrent modeling is applicable to all types of software development and provides an
accurate picture of the current state of a project. Rather than limiting software
engineering activities, actions and tasks to a sequence of events, it defines a process
network. Each activity, action or task on the network exists simultaneously with other
activities, actions or tasks. Events generated at one point trigger transitions among 28the
states.
Concurrent Model
non
e
Modeling
activity

represents the state

Under
of a software
developme engineering activity or
task
nt

Awaitin
g
chang
es

Under
review
Under
revisio
n

Baselined

Don
e

29
 Still Other Process Models

• Component based development—the process to apply

when reuse is a development objective ( like spiral model)
• Formal methods—emphasizes the mathematical specification of
requirements ( easy to discover and eliminate ambiguity,
incompleteness and inconsistency)
• Aspect Oriented software development (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) to
model and develop object-oriented system iteratively and 30incrementally.
The Unified Process (UP)
Elabor
elaboration
ation

Incep
inception
tion

constr
Release uction
software
increment tr ansition
31
pr od
uction
UP Work Products
Inception phase

Elaboration phase Construction

Vision document phase
Design model
Initial use-case Transition
Software
model Initial Use-case model phase
Delivered software
components
project glossary Supplementary increment Beta test
Integrated
Initial business requirements including reports
software
case Initial risk non-functional Analysis General user feedback
increment
assessment. model Test plan and
Project plan, Software architecture procedure Test
phases and iterations. Description. cases
Business Executable
Support
model, if architectural documentation
necessary. prototype. user manuals
One or more prototypes Preliminary design installation
model Revised risk manuals
list description of
Project plan including current increment
iteration plan
adapted
workflows
milestones
technical work
products Preliminary
user manual
33
References

►These slides are designed and adapted from slides provided by Software Engineering: A
Practitioner’s Approach, 7/e
►(McGraw-Hill2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011
by Ian Sommerville