Software Engineering

Instructor: Syed Ali Raza

Department of Computer
Science
GC University Lahore
Chapter 2 – Process
Models
Major problems in software
development

How the How the project How the How the How the sales
customer leader understood engineer programmer executive
explained it it designed it wrote it described it

How the project What operations How the How the help What the
was documented installed customer was desk supported customer really
billed needed
Social Learning Process
Software is embodied knowledge that is
initially dispersed, implicit 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”.
Software Development
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.
Software process activities
Software specification
 where customers and engineers define the software
that is to be produced and the constraints on its
operation.
Software development
 where the software is designed and programmed.
Software validation
 where the software is checked to ensure that it is
what the customer requires.
Software evolution
 where the software is modified to reflect changing
customer and market requirements.
Process Flow
Identifying a Task Set
Key question is that what actions are
appropriate for a framework activity given the
nature of the problem, the characteristics of
the people and the stakeholders?

A task set defines the actual work to be done to

accomplish the objectives of a software
engineering action.
 A list of the task to be accomplished
 A list of the work products to be produced
 A list of the quality assurance filters to be
applied
Example of a Task Set
 The task sets for Requirements gathering
action for a simple project may include:
1. Make a list of stakeholders for the project.
2. Invite all stakeholders to an informal
meeting.
3. Ask each stakeholder to make a list of
features and functions required.
4. Discuss requirements and build a final list.
5. Prioritize requirements.
6. Note areas of uncertainty.
Example of a Task Set
 The task sets for Requirements gathering action for a big
project may include:
1. Make a list of stakeholders for the project.
2. Interview each stakeholders separately to determine overall wants
and needs.
3. Build a preliminary list of functions and features based on
stakeholder input.
4. Schedule a series of facilitated application specification meetings.
5. Conduct meetings.
6. Produce informal user scenarios as part of each meeting.
7. Refine user scenarios based on stakeholder feedback.
8. Build a revised list of stakeholder requirements.
9. Use quality function deployment techniques to prioritize
requirements.
10. Package requirements so that they can be delivered incrementally.
11. Note constraints and restrictions that will be placed on the
system.
12. Discuss methods for validating the system.
Process Patterns
 A process pattern
 describes a process-related problem that is
encountered during software engineering work,
 identifies the environment in which the problem has
been encountered, and
 suggests one or more proven solutions to the
problem.
 Stated in more general terms, a process pattern
provides you with a template [Amb98]
1. Problems and solutions associated with a complete
process model (e.g. prototyping).
2. Problems and solutions associated with a
framework activity (e.g. planning) or
3. an action with a framework activity (e.g. project
estimating).
Process Pattern Types
 Stage patterns
 defines a problem associated with a framework activity for the
process. It includes multiple task patterns as well.
 For example, EstablishingCommunication would incorporate the task
pattern RequirementsGathering and others.
 Task patterns
 defines a problem associated with a software engineering
action or work task and relevant to successful software
engineering practice.
 Example includes CustomerAssessment

 Phase patterns
 define the sequence of framework activities that occur with the
process, even when the overall flow of activities is iterative in
nature.
 Example includes SprialModel or Prototyping.
An Example of Process
Pattern
Describes an approach that may be applicable when stakeholders have
a general idea of what must be done but are unsure of specific
software requirements.
 Pattern name. RequiremetnsUnclear Type. Phase pattern
 Intent. This pattern describes an approach for building a model
that can be assessed iteratively by stakeholders in an effort to
identify or solidify software requirements.
 Initial context. Conditions must be met
1. stakeholders have been identified
2. a mode of communication between stakeholders and the software team has been
established
3. the overriding software problem to be solved has been identified by stakeholders
4. an initial understanding of project scope, business requirements and project
constraints has been developed
 Problem. Requirements are hazy or nonexistent. stakeholders are
unsure of what they want.
 Solution. A description of the prototyping process would be
presented here.
 Resulting context. A software prototype that identifies basic
requirements. is approved by stakeholders. Following this,
1. 1. This prototype may evolve through a series of increments to become
the production software
2. 2. the prototype may be discarded.
Process Assessment and
Improvement
SP cannot guarantee that
 software will be delivered on time
 meet the needs
 has the desired technical characteristics.

However, the process 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.
Generic Software Process
Models
Prescriptive Models
 Separate and distinct phases of specification
and development
Evolutionary development
 Specification and development are interleaved
Formal systems development (example -
ASML)
 A mathematical system model is formally
transformed to an implementation
Reuse-based development
 The system is assembled from existing
components
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?
The Waterfall Model
 It is the oldest paradigm for SE.
 It is used when requirements are well defined and
reasonably stable, it leads to a linear fashion.
 The classic life cycle suggests a systematic, sequential
approach to software development.
 Major Problems
 rarely linear, iteration needed.
 hard to state all requirements explicitly.
 code will not be released until very late.
 Hence it isonly appropriate when the requirements are well-
understood
The Waterfall Model
The V-Model
 A variation of waterfall model

 depicts the relationship of

quality assurance actions to
the actions associated with
communication modeling and
early code construction
activities.

 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.
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/or 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.
The Incremental Model
 Advantages of Incremental Model
 Initial product delivery is faster.
 Lower initial delivery cost.
 The core product is developed first i.e. main functionality is added in the first increment.
 With each release, a new feature is added to the product.
 Customers can respond to feature and review the product.
 Risk of changing requirement is reduced
 Disadvantages of Incremental Model
 Requires good analysis.
 Resulting cost may exceed the cost of the organization.
 As additional functionality is added to the product, problems may arise related to system
architecture which was not evident in earlier prototypes.
Prescriptive Models
 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?
 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.
 Two types are introduced, namely Prototyping and Spiral
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 are used to refine requirements.
Prototyping
 Both stakeholders and
software engineers like the
prototyping paradigm. Quick
plan
communication
 Users get a feel for the actual Modeling
Quick design
system, and developers get to
build something immediately.

 However, engineers may

make compromises in order Deployment
delivery &
to get a prototype working feedback Construction
of prototype
quickly. Construction
of prototype

 The less-than-ideal choice

may be adopted forever after
you get used to it.
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.
The Spiral
 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.
 Good to develop large-scale system as software evolves as the
process progresses and risk should be understood and properly
reacted to.
 Prototyping is used to reduce risk.
 However, it may be difficult to convince customers that it is
controllable as it demands considerable risk assessment
expertise.
The Spiral
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.
3. Formal systems
development
 An important variant of the waterfall model is formal system
development, where a mathematical model of a system specification is
created.

 This model is then refined, using mathematical transformations that

preserve its consistency, into executable code. Based on the assumption
that your mathematical transformations are correct, you can therefore
make a strong argument that a program generated in this way is
consistent with its specification.

 Transformations are ‘correctness-preserving’ so it is

straightforward to show that the program conforms to its specification

 Embodied in the ‘Cleanroom’ approach to software development

 The cleanroom software engineering process is a software development
process intended to produce software with a certifiable level of reliability.
Cleanroom Process
 Formal specification
 The software to be developed is formally specified. A state-transition model
which shows system responses to stimuli is used to express the specification.
 Incremental development
 The software is partitioned into increments which are developed and
validated separately using the Cleanroom process. These increments are
specified, with customer input, at an early stage in the process.
 Structured programming
 Only a limited number of control and data abstraction constructs are used.
The program development process is a process of stepwise refinement of the
specification. A limited number of constructs are used and the aim is to apply
correctness-preserving transformations to the specification to create the
program code.
 Static verification
 The developed software is statically verified using rigorous software
inspections. There is no unit or module testing process for code components.
 Statistical testing of the system
 The integrated software increment is tested statistically, to determine its
reliability. These statistical tests are based on an operational profile which is
developed in parallel with the system specification.
Cleanroom Process
Formal systems development
Problems
 Need for specialised skills and training to apply
the technique
 Difficult to formally specify some aspects of the
system such as the user interface
Applicability
 Critical systems especially those where a safety
or security case must be made before the
system is put into operation
4. Reuse-oriented
development
 Reuse-oriented approach relies on a large base of
reusable software components!

 Design system to capitalize on the existing components

 Process stages
 Component analysis
 Requirements modification
 System design with reuse
 Development and integration

This approach is becoming more important but

still limited experience with it
Reuse-oriented development

Requirements Component Requirements System design

specification analysis modification with reuse

Development System
and integration validation
Reuse-oriented development
Advantages:
 Reduced cost and risk
 Fast delivery
Challenges:
 Requires a large enough component base
 Some control over the system evolution is lost
as new versions of reusable components are
not under the control of organization using the
component
 Potential issues in backward/forward
compatibility
 Still Other Process
Models
Unified Process
Personal Software Process
Agile Process Model
The Unified Process (UP)
Iterative, incremental model to adapt to
specific project needs
Risk driven development
Combining spiral and Prototyping models
Iterative process
 development is divided into short fixed length
mini projects (called iterations).
 Each iteration has requirement analysis,
design, implementation and testing.
 Output of each iteration is tested integrated
executed system that grows with each iteration.
 Stages of the UP
development cycle

iteration phase

inc. elaboration construction transition

milestone release increment final production

release
An iteration end- A stable executable The difference
point when some subset of the final (delta) between the At this point, the
significant decision product. The end of releases of 2 system is released
or evaluation each iteration is a subsequent for production use.
occurs. minor release. iterations.
Stages of the UP
 Inception
 Customer communication, project vision and
planning activities (feasibility study)
 Elaboration
 multiple iterations that refines the requirements
and models of the system
 Construction
 develop software code
 Transition
 user testing and installation
 Production
 operation
UP Phases
UP Phases
Inception Elaboration Construction Transition Production

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n
Personal Software Process
(PSP)
The personal software process is a structured
set of process descriptions, measurements
and methods that can help engineers improve
their personal performance
The goal of PSP is to discipline software
process
The PSP introduces process concepts in a
series of steps. Each step includes all the
elements of the prior steps together with one
or two additions.
Personal Software Process
The Cyclic PSP 3
Cycle development
personal
process

PSP2.1
Personal Quality PSP2 Design template
Management Code reviews
Design Reviews

PSP1.1
Task planning
Personal PSP1
Size estimating Schedule planning
Planning Test report

PSP0.1
Coding standard
The Baseline PSP0 Size measurement
Current process
Personal Time recording
Process improvement
Proposal
Process Defect recording
Defect type standard
Credits
Pressman Slides

Sommerville Slides

Whitten-Bentley Slides