Software Process

Lecture 2

Remya Raghav. N
S6 IT
Govt. Engg. College
Idukki
• Process: a series of actions or steps taken in
order to achieve a particular end product

• Software Process:
a) An ordered set of steps to produce a high
quality software system
b) A process that deals with the technical and
management issues of software development
Processes, Projects, and Products
 Software Process

Managers will work on the project management process

Designers, developers, writers and testers will work on the development

process, the change process, and the inspection process

Build managers (configuration controllers) will work on configuration

management

Software Engineering Process Group (SEPG) will do process management

Characteristics of a Software Process

• Predictability
• Support Testability and Maintainability
• Support Change
• Support Early Defect Removal and Defect
Prevention
• Process Improvement
 Predictability

• Predictable processes are important since they aid in the task of

making estimates for new projects
“The last 5 projects of this size and scope, using this process, cost
approximately $1.5 M. Thus we predict that this current project will
cost the same.”

• Predictable processes are also important to help us gauge the

acceptability of various quality attributes

• Predictable processes are said to be under statistical control. A

process is under statistical control if following the same process
produces similar results— results will have some variation due to
random causes not process issues
Process under statistical control

Expected value of the

property
 Support Testability and Maintainability

• development projects spend a significant amount of time in

the testing phase

• most of the costs associated with a software system occur

after a system is deployed and is in active use
Effort distribution with phases

Requirements 10%
Design 20%
Coding 20%
Testing 50%

Time distribution of programmers

Writing programs 13%

Reading programs and manuals 16%
Job communication 32%
Others (including personal) 39%
 Support Change

• A software process needs to be able to respond

to a change in a system's requirements
 Early Defect Removal and Defect
Prevention
• The greater the delay in detecting an error after it occurs in a software development process, the more expensive it is to correct it

Cost of correcting errors

 Process Improvement

• No process is going to be perfect. And it should not be expected

that a process used by one organization can be transferred to
another organization without modification

• Improving the quality and reducing the cost of products is

fundamental to any engineering discipline
Software Development Process

• core of software process

• Process models specify the steps that need to be

performed and the order in which need to be
performed
 Process Step Specification
• A process is a set of steps
• Each step takes a set of inputs and produces a
set of outputs (generically called work products)
– Each output should be a formal and tangible artifact
that can be verified in some fashion

• One approach to process specification is known

as ETVX (Entry Criteria, Task, Verification and
eXit criteria)
A step in a development process
– Entry Criteria: what conditions must
be satisfied before initiating this step

– Task: what work is to be performed

during this step

– Verification: what checks must be

performed on the outputs of this step

– Exit Criteria: what conditions must be

satisfied before this step is over

– In addition, each step must specify

what information is generated for
management during this step.
Software Development Process Models

• Waterfall Model — the oldest model

and the one most widely used

• Prototyping

• Iterative — also widely used

• Spiral Model
1.Waterfall Model - Linear sequence of stages/phases
Project Outputs in Waterfall Model
• Requirements document

• Project plan

• System design document

• Detailed design document

• Test plan and test reports

• Final code

• Software manuals (e.g. user, installation, etc)

• Review reports
 Waterfall Advantages

• Conceptually simple, cleanly divides the problem into

distinct phases that can be performed independently

• Natural approach to problem solving

• Easy to administer in a contractual setting — each phase is

a milestone
 Waterfall disadvantages
• Assumes that requirements can be specified and frozen
early

• May force hardware and other technology choices too

early in the development phase

• Follows the “big bang” approach – all or nothing delivery;

too risky (partial development not possible)

• Very document oriented, requiring documents at the end

of each phase
2. Prototyping
 Features
• Prototyping addresses the requirement specification
limitation of the waterfall model

• Instead of freezing requirements only by discussions, a

prototype is built to understand the requirements

• Helps to alleviate the risk of not understanding the

requirements early in a development project

• A small waterfall model replaces the requirements stage

 Development of Prototype
• Starts with initial requirements

• Only key features which need better understanding are included in

prototype

• No point in including those features that are well understood

• Feedback from users taken to improve the understanding of the

requirements

• Critical Need: users must be educated that what they are seeing is ONLY
a prototype
– Users must understand that the prototype is going to be thrown away
– Otherwise, they will wonder why the development process is taking so
long!
 Managing Costs
• Costs can be kept low by only building features needing clarification

• Team can make use of rapid application development tools,

scripting, etc.

• Quality of prototype is not important, understanding user

requirements is more important

• Knowledge gained building prototype will be useful in design and

implementation

• Reducing risks associated with the project

 3. Iterative Enhancement
• Counters the “all or nothing” drawback of the waterfall
model

• Combines benefit of prototyping and waterfall

• Develop and deliver software in increments

• Each increment is complete in itself

• Can be viewed as a sequence of waterfalls

• Feedback from one iteration is used in future iterations

Iterative Enhancement Model
 Features
• After an initial requirements phase, a project control
list is created that lists the features of the desired
system.

• A set of features is selected for the first iteration

and the developers design, code, and test an
implementation of those features.

• The result is then analyzed and the project control

list is updated.

• Repeat until project control list is empty

Spiral Model
Spiral Model – A Detailed View
 Steps…
• Each cycle in the spiral begins with the identification of
objectives for that cycle
• The different alternatives for achieving those objectives
are considered and constraints are identified
• Next, the risks facing the project at this stage are
evaluated
• Next, activities are performed to resolve uncertainties
and reduce risk (including changing the objectives)
• Next, software is developed and tested, keeping in mind
the identified risks and avoiding them, if possible
• Finally, the last step consists of planning for the next
loop of the spiral
 Model Strengths Weaknesses Applicability
Waterfall Simple All or nothing — too risky Well understood problems
Easy to execute Requirements frozen early short duration projects
Intuitive and logical May chose outdated hardware/tech automation of existing manual
Easy contractually Disallows changes systems
No feedback from users
Encourages requirements bloating

Prototypin Helps reqs. elicitation Possibly higher cost and schedule Systems with novice users; or
g Reduces risk Encourages reqs. bloating areas with reqs. uncertainity
Better and more stable Disallows later change Heavy reporting based systems
final system can benefit from UI prototypes

Iterative Regular deliveries, Overhead of planning each For businesses where time is
leading to business iteration important, risk of long projects
benefit Total costs may increase cannot be taken
Can accommodate System architecture and design reqs not known and evolve with
changes naturally may suffer Time
Allows user feedback Rework may increase
Avoids reqs. bloating
Naturally prioritizes
reqs.
Allows reasonable exit
points
Reduces risks
Spiral Resolve risks Cost may increase Both works for development as
Represents cumulative well as enhancement projects
cost and progress
 Summary
• Software Process is a means for producing high quality
software systems with high productivity
• A software process has many sub-processes performed
by multiple people playing different roles
• Many different types of development processes have
been proposed
o with different strengths and weaknesses
o one model will not necessarily be suitable for every
organization
 Project Management Process

• Planning

• Monitoring and control

• Termination analysis
Relationship between development and
management process
 Planning
– Key activity that is performed before a project
development begins
– A critical ingredient for a successful project
– Provides fundamental basis for project management
– Tasks include
• Cost and schedule estimation
• Milestone determination
• Staffing
• Monitoring and Risk Management Plans
• Quality Assurance Plans
 Monitoring and Control

1. Lasts for the duration of the project and covers the

development process

2. Monitors all key parameters like cost, schedule,

risks

3. Takes corrective actions when needed

4. Needs information on the dev process – provided by

metrics
 Termination Analysis
– Termination analysis or postmortem analysis, is performed when
a development process ends

– Its key task is to analyze the development process looking for

data about its performance

– This data is used to improve the process on subsequent projects

– In an iterative development process, you could apply

postmortem analysis, at the end of each iteration

– Used to make predictions and estimations about future projects

 Metrics, measurements, and models
• Need objective and quantitative data

• Software metrics : quantifiable measures that could

be used to measure different characteristics (size,
complexity, reliability…) of a software system (SDP)

• Metrics provides the scale for quantifying qualities.

(c.m)

• Measurement must be performed on a given

software system in order to use metrics for
quantifying characteristics of the given software.
(measuring tape)
• Direct Metric: if metric is measured directly

• Indirect Metric : quality and reliability parameters

(Need Models for estimation)

• Model is a relationship of the predicted variable

(property of interest) that other variables that can
be measured
• Metrics provide a quantification of some
property

• Measurement provide the actual value for

the metrics

• Models are needed to get the value for the

metrics that cannot be measured directly.

• Metrics needed for objective and data-

based project development
 SCM: discipline for systematically controlling the
changes that take place during development

• Acco. to IEEE Definition,

“ SCM is the process of
-identifying and defining the items in
the system
-controlling the change of these items
throughout the life cycle
- recording and reporting the status of
items and change request
-verifying the completeness and
correctness of items”
 Issues handled by SCM

• Approving the change

• Evaluating the impact of the change
• Decide what needs to be done to
accommodate change request
• Control the changes - minimal effect on
cost, schedule and quality
 Components-SCM

• Software configuration identification

• Change control (CCB)

• Status accounting and auditing

 Process Management Process

• Building Estimation model

• Process improvement
-Capability Maturity model
-Quality improvement Paradigm
 QIP
• General method for improving a process
• Steps are

-Characterize (understand the process)

-Set Goals
-choose process
- Execute
-Analyze
-package (based on experience , define and
formalize the changes)

• Goal/Question/Metrics (GQM)