LECTURE#3 PROCESS MODELS

SOCIAL LEARNING PROCESS

 Software is embodied knowledge that is initially dispersed, tacit and

incomplete.
 In order to convert knowledge into software, dialogues are needed
between users and designers, between designers and tools to bring
knowledge into software.
 Software development is essentially an iterative social learning process, and
the outcome is “software capital”.

2
WHAT / WHO / WHY IS PROCESS MODELS?
 What: Go through a series of predictable steps--- a road map that helps you create a timely, high-
quality results.
 Who: Software engineers and their managers, clients also. People adapt the process to their needs
and follow it.
 Why: Provides stability, control, and organization to an activity that can if left uncontrolled, become
quite chaotic. However, modern software engineering approaches must be agile and demand ONLY
those activities, controls and work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that you are building. One
process might be good for aircraft avionic system, while an entirely different process would be used
for website creation.
 How to ensure right: A number of software process assessment mechanisms that enable us to
determine the maturity of the software process. However, the quality, timeliness and long-term
viability of the software are the best indicators of the efficacy of the process you use. 3
 DEFINITION OF SOFTWARE PROCESS

 A framework for the activities, actions, and tasks that are required to build high-
quality software.

 SP defines the approach that is taken as software is engineered.

 Is not equal to software engineering, which also encompasses technologies that

populate the process– technical methods and automated tools.

4
A GENERIC PROCESS MODEL

5
 As we discussed before, a generic process framework for software engineering defines five framework
activities-communication, planning, modeling, construction, and deployment.
 In addition, a set of umbrella activities- project tracking and control, risk management, quality assurance,
configuration management, technical reviews, and others are applied throughout the process.
 Next question is: how the framework activities and the actions and tasks that occur within each activity are
organized with respect to sequence and time? See the process flow for answer.

A GENERIC PROCESS MODEL 6

 PROCESS FLOW
 Linear process flow executes each of the five
activities in sequence.
 An iterative process flow repeats one or more of
the activities before proceeding to the next.
 An evolutionary process flow executes the
activities in a circular manner. Each circuit leads
to a more complete version of the software.
 A parallel process flow executes one or more
activities in parallel with other activities (
modeling for one aspect of the software in parallel
with construction of another aspect of the
software.
7
For a small software project requested by one person (at a remote
location) with simple, straightforward requirements, the
communication activity might encompass little more than a phone
call with the appropriate stakeholder. Therefore, the only necessary
action is phone conversation, and the work tasks (the task set) that
this action encompasses are:

1. Make contact with stakeholder via telephone.

2. Discuss requirements and take notes.
3. Organize notes into a brief written statement of requirements.
4. E-mail to stakeholder for review and approval.
PRESCRIPTIVE PROCESS MODELS

 Prescriptive process models define a prescribed set of process

elements and a predictable process work flow.
 Prescriptive process models were originally proposed to bring
order to the chaos of software development.
 History has indicated that these traditional models have brought a
certain amount of useful structure to software engineering work
and have provided a reasonably effective road map for software
teams.
 Each process model also prescribes a process flow (also called a work
flow)—that is, the manner in which the process elements are
interrelated to one another.
 All software process models can accommodate the generic framework
activities described in Chapter 1, but each applies a different emphasis to
these activities and defines a process flow that invokes each framework
activity (as well as software engineering actions and tasks) in a different
manner.
PROCESS MODELS-THE WATERFALL MODEL

 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.
 PROCESS MODELS-THE V-MODEL
 A variation in the representation of the waterfall model is called the V-model.
Represented in Figure 2.4, the V-model depicts the relationship of quality assurance
actions to the actions associated with communication, modeling, and early
construction activities.
 PROCESS MODELS-THE V-MODEL
 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.
 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.
 The waterfall model is the oldest paradigm for software engineering. However, over the past three
decades, criticism of this process model has caused even ardent supporters to question its efficacy.
 Among the problems that are sometimes encountered when the waterfall model is applied are:
 1. Real projects rarely follow the sequential flow that the model proposes. Although the linear model
can accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the
project team proceeds.
 2. It is often difficult for the customer to state all requirements explicitly. The waterfall model requires
this and has difficulty accommodating the natural uncertainty that exists at the beginning of many
projects.
 3. The customer must have patience. A working version of the program(s) will not be available until
late in the project time span. A major blunder, if undetected until the working program is reviewed, can
be disastrous.
PROCESS MODELS- INCREMENTAL PROCESS MODELS

 The incremental model delivers a series of releases, called increments,

that provide progressively more functionality for the customer as each
increment is delivered.
 The incremental model combines elements of linear and parallel process
flows.
PROCESS MODELS- INCREMENTAL PROCESS MODELS
PROCESS MODELS- INCREMENTAL PROCESS MODELS

 Each linear sequence produces deliverable “increments” of the software.

 For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document
production functions in the first increment; more sophisticated editing
and document production capabilities in the second increment; spelling
and grammar checking in the third increment; and advanced page layout
capability in the fourth increment.
PROCESS MODELS- INCREMENTAL PROCESS MODELS

 When an incremental model is used, the first increment is often a core

product.
 That is, basic requirements are addressed but many supplementary features
(some known, others unknown) remain undelivered.
 The core product is used by the customer (or undergoes detailed evaluation).
 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.
PROCESS MODELS- INCREMENTAL PROCESS MODELS

 Incremental development is particularly useful when staffing is unavailable

for a complete implementation by the business deadline that has been
established for the project.
PROCESS MODELS- EVOLUTIONARY PROCESS MODELS
 Software, like all complex systems, evolves over a period of time.
 Business and product requirements often change as development proceeds, making a
straight line path to an end product unrealistic; tight market deadlines make
completion of a comprehensive software product impossible, but a limited version
must be introduced to meet competitive or business pressure; a set of core product
or system requirements is well understood, but the details of product or system
extensions have yet to be defined.
 In these and similar situations, you need a process model that has been explicitly
designed to accommodate a product that evolves over time.
PROCESS MODELS- EVOLUTIONARY PROCESS MODELS

 Evolutionary models are iterative. They are characterized in a manner

that enables you to develop increasingly more complete versions of the
software.
EVOLUTIONARY PROCESS MODELS- PROTOTYPING

 Often, a customer defines a set of general objectives for software, but does not
identify detailed requirements for functions and features.
 In other cases, the developer may be unsure of the efficiency of an algorithm, the
adaptability of an operating system, or the form that human-machine interaction
should take.
 In these, and many other situations, a prototyping paradigm may offer the best
approach.
EVOLUTIONARY PROCESS MODELS- PROTOTYPING
EVOLUTIONARY PROCESS MODELS- PROTOTYPING
The prototyping paradigm (Figure 2.6) begins with communication. You meet with
other stakeholders to define the overall objectives for the software, identify whatever
requirements are known, and outline areas where further definition is mandatory. A
prototyping iteration is planned quickly, and modeling (in the form of a “quick de-
sign”) occurs. A quick design focuses on a representation of those aspects of the soft-
ware that will be visible to end users (e.g., human interface layout or output display
formats). The quick design leads to the construction of a prototype. The prototype is
deployed and evaluated by stakeholders, who provide feedback that is used to fur-
ther refine requirements. Iteration occurs as the prototype is tuned to satisfy the
needs of various stakeholders, while at the same time enabling you to better under-
stand what needs to be done.
 EVOLUTIONARY PROCESS MODELS-THE SPIRAL MODEL

 Originally proposed by Barry Boehm [Boe88], the spiral model is an evolutionary

software process model that couples the iterative nature of prototyping with the
controlled and systematic aspects of the waterfall model.
 Using the spiral model, software is developed in a series of evolutionary releases.
 During early iterations, the release might be a model or prototype.
 During later iterations, increasingly more complete versions of the engineered
system are produced.
EVOLUTIONARY PROCESS MODELS-THE SPIRAL MODEL
EVOLUTIONARY PROCESS MODELS-THE SPIRAL MODEL
 A spiral model is divided into a set of framework activities defined by the software
engineering team.
 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.
 Risk is considered as each revolution is made.
 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.
EVOLUTIONARY PROCESS MODELS-THE CONCURRENT
DEVELOPMENT MODEL

 The concurrent development model, sometimes called concurrent engineering, can be

represented schematically as a series of framework activities, Software engineering
actions of tasks, and their associated states.
 The concurrent model is often more appropriate for system engineering projects
where different engineering teams are involved.
EVOLUTIONARY PROCESS MODELS-THE CONCURRENT
DEVELOPMENT MODEL
EVOLUTIONARY PROCESS MODELS-THE CONCURRENT
DEVELOPMENT MODEL