Software

Engineering

By Miss Nida E Rub

Chapter # 2

PROCESS MODELS
Chapter # 2
2.1 A GENERIC PROCESS MODEL
• Defining a Framework Activity
• A generic process framework for software engineering
defines five framework activities—communication,
planning, modeling, construction, and deployment.
• Defining a Framework Activity
• Identifying a task set
• Process Patterns
• Process patterns are patterns used to describe problems
and their solutions in the context of software process.
• Problems associated with a complete process model
• Within a framework activity
• Within an action in an activity
2.2 PROCESS ASSESSMENT AND
IMPROVEMENT
2.2 PROCESS ASSESSMENT AND
IMPROVEMENT
• A software process assessment is a disciplined examination of
the software processes used by an organization, based on a
process model.
• The assessment includes
• The identification and characterization of current practices,
• Identifying areas of strengths and weaknesses
• The ability of current practices to control or avoid significant
causes of poor (software) quality
• Cost
• schedule
• The process itself can be assessed to ensure that it meets a
set of basic process criteria that have been shown to be
essential for a successful software engineering.
2.2 PROCESS ASSESSMENT
AND IMPROVEMENT
A software assessment (or audit) can be of three types.
1. A self-assessment (first-party assessment) is
performed internally by an organization's own
personnel.
2. A second-party assessment is performed by an
external assessment team or the organization is
assessed by a customer.
3. A third-party assessment is performed by an external
party or (e.g., a supplier being assessed by a third party
to verify its ability to enter contracts with a customer).
2.2 PROCESS ASSESSMENT
AND IMPROVEMENT
• Software process assessments are
performed in an open and collaborative
environment.
• They are for the use of the organization to
improve its software processes, and the
results are confidential to the
organization.
• The organization being assessed must
have members on the assessment team.
 PROCESS ASSESSMENT AND
IMPROVEMENT
• A number of different approaches to software process assessment and
improvement have been proposed over the past few decades:

(1) Standard CMMI Assessment Method for Process Improvement

(SCAMPI)— provides a five-step process assessment model that
incorporates five phases: initiating, diagnosing, establishing, acting,
and learning.
• CMMI  Capability Maturity Model Integration
(2) CMM-Based Appraisal for Internal Process Improvement (CBA IPI)—
provides a diagnostic technique for assessing the relative maturity of a
software organization
(3) SPICE (ISO/IEC15504)— A standard that defines a set of requirements
for software process assessment. The intent of the standard is to assist
organizations in developing an objective evaluation of the efficiency of
any defined software process
(4) ISO 9001:2000 for Software — A generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies
2.3 PRESCRIPTIVE PROCESS MODELS
Prescriptive Process Models
• 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.
• Prescriptive software models are those which prescribe
the components which make up a software model,
including the activities, the inputs and outputs of the
activities, how quality assurance is performed, how
change is managed, and so on.
Prescriptive Process Models
• The following framework activities are carried out irrespective
of the process model chosen by the organization.

1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

• The name 'prescriptive' is given because the model prescribes

a set of activities, actions, tasks, quality assurance and change
the mechanism for every project.
2.3.1 The Waterfall Model
• There are times when the requirements for a problem are well
understood
• In such cases Software Engineers use Waterfall Model
• The waterfall model is also called as 'Linear sequential
model' or 'Classic life cycle model'.
• It begins with customer specification of requirements and
progresses through planning, modeling, construction, and
deployment, culminating in ongoing support of the completed
software
• In this model, each phase is fully completed before the beginning of
the next phase.
• This model is usually used for the small projects.
• In this model, feedback is taken after each phase to ensure that the
project is on the right path.
• Testing part starts only after the development is complete.
2.3.1 The Waterfall Model

The waterfall model is the oldest paradigm for

software engineering.
2.3.1 The Waterfall Model
• A variation in the representation of the waterfall model is
called the V-model.
2.3.1 The Waterfall Model
• The V-model 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
• 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.
2.3.1 The Waterfall Model
• Among the problems that are sometimes
encountered when the waterfall model is applied
are:
• Real projects rarely follow the sequential flow
that the model proposes.
• It is often difficult for the customer to state all
requirements explicitly.
• The customer must have patience. A working
version of the program(s) will not be available
until late in the project time span.
2.3.2 Incremental Process Models
• The incremental model combines
elements of linear and parallel process
flows discussed in Section 2.1.
• The incremental model applies linear
sequences in a staggered fashion as time
progresses.
• Each linear sequence produces deliverable
“increments” of the software
2.3.2 Incremental Process Models
2.3.2 Incremental Process Models
Example Word-processing software
• Lets assume the 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
• Advanced page layout capability in the fourth increment
2.3.2 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 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.
• This process is repeated following the delivery of each
increment, until the complete product is produced.
2.3.3 Evolutionary Process Models
• Complex systems evolve over a period of time
• -Business and product requirements often change as
development proceeds.
• 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.
• Evolutionary models are iterative.
• Evolutionary Process Model produce an increasingly more
complete version of the software with each iteration.
2.3.3 Evolutionary Process Models
Evolutionary Process Model
• Prototyping
• Spiral Model
2.3.3 Evolutionary Process Models
Prototyping
• The prototyping paradigm assists you and other stakeholders
to better understand what is to be built when requirements
are fuzzy.
• Prototyping paradigm
• Begins with communication.
• Planned quickly and modeling occurs
• Quick design focuses on a representation of those aspects of the
software that will be visible to end users.
• It serves as a mechanism for identifying software
requirements
2.3.3 Evolutionary Process Models
Prototyping
2.3.3 Evolutionary Process Models
The Spiral Model
2.3.3 Evolutionary Process Models
The Spiral Model
• Originally proposed by Barry Boehm.
• It couples the iterative nature of prototyping with the
controlled and systematic aspects of water fall model.
• Process is represented as a spiral rather than as a sequence of
activities with backtracking.
• Each loop in the spiral represents a phase in the process.
• No fixed phases such as specification or design - loops in the
spiral are chosen depending on what is required.
• Risks are explicitly assessed and resolved throughout the
process.
2.3.3 Evolutionary Process Models
The Spiral Model
• The Spiral Model is a risk-driven model, meaning
that the focus is on managing risk through
multiple iterations of the software development
process.
• Risk Analysis: In the risk analysis phase, the risks
associated with the project are identified and
evaluated.
2.3.4 Concurrent Models
Reading Assignment

2.3.4 Concurrent Models

2.3.5 A Final Word on
Evolutionary Processes
Page 48-50