SPM and COCOMO Models

Objectives

• To introduce the fundamentals of software costing

and pricing
• To describe three metrics for software productivity
assessment
• To explain why different techniques should be
used for software estimation
• To describe the principles of the COCOMO 2
algorithmic cost estimation model
Topics covered

• Software productivity
• Estimation techniques
• Algorithmic cost modelling
• Project duration and staffing
 Fundamental estimation questions

• How much effort is required to complete an

activity?
• How much calendar time is needed to complete
an activity?
• What is the total cost of an activity?
• Project estimation and scheduling are interleaved
management activities.
Software cost components

• Hardware and software costs.

• Travel and training costs.
• Effort costs (the dominant factor in most
projects)
– The salaries of engineers involved in the project;
– Social and insurance costs.
• Effort costs must take overheads into account
– Costs of building, heating, lighting.
– Costs of networking and communications.
– Costs of shared facilities (e.g library, staff restaurant, etc.).
Costing and pricing

• Estimates are made to discover the cost, to the

developer, of producing a software system.
• There is not a simple relationship between the
development cost and the price charged to the
customer.
• Broader organisational, economic, political and
business considerations influence the price
charged.
Software pricing factors

Market A development organisation may quote a low price because it

opportunity wishes to move into a new segment of the software market.
Accepting a low profit on one projec t may give the opportunity
of more profit later. The experience gained may allow new
products to be developed.
Cost estimate If an o rganisation is unsure of its cost estimate, it may increase
uncertainty its price by some contingency over and above its normal profit.
Contractual terms A c ustomer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects. The
price charged may then be less than if the software source code
is handed over to the customer.
Requirements If the requirements are likely to change, an organisation may
volatility lower its price to win a c ontract. After the contract is awarded,
high prices can be charged for changes to the requirements.
Financial healt h Developers in financial difficulty may lower their price to gain
a c ontract. It is better to make a smaller than normal profit or
break even than to go out of business.
Software productivity

• A measure of the rate at which individual

engineers involved in software development
produce software and associated
documentation.
• Not quality-oriented although quality assurance is
a factor in productivity assessment.
• Essentially, we want to measure useful
functionality produced per time unit.
Productivity measures

• Size related measures based on some output

from the software process. This may be lines of
delivered source code, object code instructions,
etc.
• Function-related measures based on an
estimate of the functionality of the delivered
software. Function-points are the best known of
this type of measure.
Measurement problems

• Estimating the size of the measure (e.g. how many

function points).
• Estimating the total number of programmer
months that have elapsed.
• Estimating contractor productivity (e.g.
documentation team) and incorporating this
estimate in overall estimate.
Lines of code

• What's a line of code?

– The measure was first proposed when programs were
typed on cards with one line per card;
– How does this correspond to statements as in Java which
can span several lines or where there can be several
statements on one line.
• What programs should be counted as part of the
system?
• This model assumes that there is a linear
relationship between system size and volume of
documentation.
Productivity comparisons

• The lower level the language, the more

productive the programmer
– The same functionality takes more code to implement in a
lower-level language than in a high-level language.
• The more verbose the programmer, the higher
the productivity
– Measures of productivity based on lines of code suggest
that programmers who write verbose code are more
productive than programmers who write compact code.
System development times

Analysis Design Coding Testing Documentation

Assembly code 3 weeks 5 weeks 8 weeks 10 2 weeks
High-level language 3 weeks 5 weeks 4 weeks weeks 2 weeks
6 weeks

Size Effort Productivity

Assembly code 5000 lines 28 weeks 714 lines/month
High-level language 1500 lines 20 weeks 300 lines/month
Factors affecting productivity

Application Knowledge of the application domain is essential for effective

domain software development. Engineers who already understand a
experience domain are likely to be the most productive.
Process quali ty The development process used can have a s ignificant effect on
productivity. This is covered in Chapter 28.
Project size The larger a project, the more time required for team
communications. Less time is available for development so
individual productivity is reduced.
Technology Good support technology such as C AS E tools, configuration
support management systems, etc. can improve productivity.
Working As I discussed in Chapter 25, a q uiet working environment with
environment private work areas contributes to improved productivity.
Quality and productivity

• All metrics based on volume/unit time are

flawed because they do not take quality into
account.
• Productivity may generally be increased at the
cost of quality.
• It is not clear how productivity/quality metrics
are related.
• If requirements are constantly changing then an approach
based on counting lines of code is not meaningful as the
program itself is not static;
Estimation techniques

• There is no simple way to make an accurate estimate of the

effort required to develop a software system
– Initial estimates are based on inadequate information in a user
requirements definition;
– The software may run on unfamiliar computers or use new
technology;
– The people in the project may be unknown.
• Project cost estimates may be self-fulfilling
– The estimate defines the budget and the product is adjusted to meet
the budget.
Changing technologies

• Changing technologies may mean that previous estimating

experience does not carry over to new systems
– Distributed object systems rather than mainframe systems;
– Use of web services;
– Use of ERP or database-centred systems;
– Use of off-the-shelf software;
– Development for and with reuse;
– Development using scripting languages;
– The use of CASE tools and program generators.
Estimation techniques

• Algorithmic cost modelling.

• Expert judgement.
• Estimation by analogy.
• Parkinson's Law.
• Pricing to win.
Estimation techniques

Algorithmic A m odel based on historical cost information that relates some software
cost modelling metric (usually its size) to the project cost is used. An estimate is made
of that metric and the model predicts the effort required.
Expert Several experts on the proposed software development techniques and
judgement the application domain are consulted. They each estimate the projec t
cost. These estimates are compared and discussed. The estimation
process iterates until an agreed estimate is reac hed.
Estimation by This technique is applicable when other projects in the same application
analogy domain have been completed. The cost of a new project is estimated by
analogy with these completed projects. Myers (Myers 1989) gives a
very clear description of this approach.
ParkinsonÕs ParkinsonÕsLaw states that work expands to fill the time avail able. The
Law cost is determined by avail able resources rather than by objective
assessment. If the software has to be delivered in 12 months and 5
people are available, the effort required is estimated to be 60 person-
months.
Pricing to win The software cost is estimated to be whatever the customer has
available to spend on the projec t. The estimated effort depends on the
customerÕs b udget and not on the software functionality.
Pricing to win

• The project costs whatever the customer has to

spend on it.
• Advantages:
– You get the contract.
• Disadvantages:
– The probability that the customer gets the system he or
she wants is small. Costs do not accurately reflect the
work required.
Top-down and bottom-up
estimation

• Any of these approaches may be used top-down

or bottom-up.
• Top-down
– Start at the system level and assess the overall system
functionality and how this is delivered through sub-
systems.
• Bottom-up
– Start at the component level and estimate the effort
required for each component. Add these efforts to
reach a final estimate.
Top-down estimation

• Usable without knowledge of the system

architecture and the components that might be
part of the system.
• Takes into account costs such as integration,
configuration management and documentation.
• Can underestimate the cost of solving difficult low-
level technical problems.
Bottom-up estimation

• Usable when the architecture of the system is

known and components identified.
• This can be an accurate method if the system has
been designed in detail.
• It may underestimate the costs of system level
activities such as integration and documentation.
Estimation methods

• Each method has strengths and weaknesses.

• Estimation should be based on several methods.
• If these do not return approximately the same result, then
you have insufficient information available to make an
estimate.
• Some action should be taken to find out more in order to
make more accurate estimates.
• Pricing to win is sometimes the only applicable method.
Pricing to win

• This approach may seem unethical and un-businesslike.

• However, when detailed information is lacking it may be the
only appropriate strategy.
• The project cost is agreed on the basis of an outline proposal
and the development is constrained by that cost.
• A detailed specification may be negotiated or an evolutionary
approach used for system development.
Algorithmic cost modelling

• Cost is estimated as a mathematical function of

product, project and process attributes whose
values are estimated by project managers:
– Effort = A  SizeB  M
– A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier reflecting
product, process and people attributes.
• The most commonly used product attribute for cost
estimation is code size.
• Most models are similar but they use different values for A, B
and M.
COCOMO Models
Software Estimations

• Cost
• Effort
• Time
Motivation

The software cost estimation provides:

• the vital link between the general concepts and
techniques of economic analysis and the
particular world of software engineering.
• Software cost estimation techniques also provides
an essential part of the foundation for good
software management.
Cost of a project

• The cost in a project is due to:

– due the requirements for software, hardware and
human resources
– the cost of software development is due to the human
resources needed
– most cost estimates are measured in person-months
(PM)
Cost of a project (.)

• the cost of the project depends on the nature and

characteristics of the project, at any point, the
accuracy of the estimate will depend on the
amount of reliable information we have about the
final product.
Software Cost Estimation
Introduction to COCOMO
models

• The COstructive COst Model (COCOMO) is the

most widely used software estimation model in the
world.
• The COCOMO model predicts the effort and
duration of a project based on inputs relating to
the size of the resulting systems and a number of
"cost drives" that affect productivity.
Effort

• Effort Equation
– PM = C * (KDSI)n (person-months)
• where PM = number of person-month
• C = a constant,
• KDSI = thousands of "delivered source
instructions" (DSI) and
• n = a constant.
Productivity

• Productivity equation
– (DSI) / (PM)
• where PM = number of person-month

• DSI = "delivered source instructions"

Schedule

• Schedule equation
– TDEV = C * (PM)n (months)
• where TDEV = number of months estimated for
software development.
• Total Development Time Equation values
(TDEV)
Average Staffing

• Average Staffing Equation

– (PM) / (TDEV) (FSP)
• where FSP means Full-time-equivalent
Software Personnel.
COCOMO Models

• COCOMO is defined in terms of three different

models:
– the Basic model,
– the Intermediate model, and
– the Detailed model.
• The more complex models account for more
factors that influence software projects, and make
more accurate estimates.
The Development mode

• the most important factors contributing to a

project's duration and cost is the Development
Mode
– Organic Mode: The project is developed in a
familiar, stable environment, and the product is
similar to previously developed products. The
product is relatively small, and requires little
innovation.
– Semidetached Mode: The project's characteristics
are intermediate between Organic and Embedded.
The Development mode

• the most important factors contributing to a

project's duration and cost is the Development
Mode:
– Embedded Mode: The project is characterized
by tight, inflexible constraints and interface
requirements. An embedded mode project will
require a great deal of innovation.
Modes
Feature Organic Semidetached Embedded

Organizational Thorough Considerable General

understanding of
product and
objectives
Experience in Extensive Considerable Moderate
working with related
software systems

Need for software Basic Considerable Full

conformance with
pre-established
requirements

Need for software Basic Considerable Full

conformance with
external interface
specifications
Modes (.)

Feature Organic Semidetached Embedded

Concurrent Some Moderate Extensive

development of
associated new
hardware and
operational
procedures

Need for innovative Minimal Some Considerable

data processing
architectures,
algorithms
Premium on early Low Medium High
completion
Product size range <50 KDSI <300KDSI All
Cost Estimation Process

Cost= Size Of The Project x Productivity

Cost Estimation Process

Effort
Size Table
Development Time
Lines of Code
Estimation Process
Number of Use Case Number of Personnel

Function Point Errors

Project Size - Metrics
1. Number of functional requirements
2. Cumulative number of functional and non-functional requirements
3. Number of Customer Test Cases
4. Number of ‘typical sized’ use cases
5. Number of inquiries
6. Number of files accessed (external, internal, master)
7. Total number of components (subsystems, modules, procedures,
routines, classes, methods)
8. Total number of interfaces
9. Number of System Integration Test Cases
10. Number of input and output parameters (summed over each
interface)
11. Number of Designer Unit Test Cases
12. Number of decisions (if, case statements) summed over each
routine or method
13. Lines of Code, summed over each routine or method
Project Size – Metrics(.)

Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13
Project Size – Metrics(.)
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

1. Number of functional requirements

2. Cumulative number of functional and non-functional
requirements
3. Number of Customer Test Cases
Project Size – Metrics(.)
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

4 . Number of ‘typical sized’ use cases

5. Number of inquiries
Project Size – Metrics(.)
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

6. Number of files accessed (external, internal, master)

7. Total number of components (subsystems, modules,
procedures, routines, classes, methods)
8. Total number of interfaces
9. Number of System Integration Test Cases
Project Size – Metrics(.)
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

10. Number of input and output parameters (summed over

each interface)
11. Number of Designer Unit Test Cases
Project Size – Metrics(.)
Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13

12. Number of decisions (if, case statements) summed over each routine
or method
13. Lines of Code, summed over each routine or method
Project Size – Metrics(.)

Availability of Size Estimation Metrics:

Development Phase Available

Metrics
a Requirements Gathering 1, 2, 3
b Requirements Analysis 4, 5
d High Level Design 6, 7, 8, 9
e Detailed Design 10, 11, 12
f Implementation 12, 13
Function Points

• STEP 1: measure size in terms of the amount of functionality

in a system. Function points are computed by first calculating
an unadjusted function point count (UFC). Counts are
made for the following categories
 •External inputs – those items provided by the user that
describe distinct application-oriented data (such as file
names and menu selections)
 •External outputs – those items provided to the user
that generate distinct application-oriented data (such as
reports and messages, rather than the individual
components of these)
Function Points(.)

 •External inquiries – interactive inputs requiring a

response
 •External files – machine-readable interfaces to other
systems
 •Internal files – logical master files in the system
Function Points(..)

• STEP 2: Multiply each number by a weight factor, according

to complexity (simple, average or complex) of the
parameter, associated with that number. The value is given
by a table:
Function Points(...)

• STEP 3: Calculate the total UFP (Unadjusted Function

Points)
• STEP 4: Calculate the total TCF (Technical Complexity
Factor) by giving a value between 0 and 5 according to the
importance of the following points:
Function Points(....)
• Technical Complexity Factors:
– 1. Data Communication
– 2. Distributed Data Processing
– 3. Performance Criteria
– 4. Heavily Utilized Hardware
– 5. High Transaction Rates
– 6. Online Data Entry
– 7. Online Updating
– 8. End-user Efficiency
– 9. Complex Computations
– 10. Reusability
– 11. Ease of Installation
– 12. Ease of Operation
– 13. Portability
– 14. Maintainability
Function Points(.....)

• STEP 5: Sum the resulting numbers too obtain DI (degree of

influence)
• STEP 6: TCF (Technical Complexity Factor) by given by the
formula
– TCF=0.65+0.01*DI
• STEP 6: Function Points are by given by the formula
– FP=UFP*TCF
Example
Example (.)
Example (..)
• Technical Complexity Factors:
– 1. Data Communication 3
– 2. Distributed Data Processing 0
– 3. Performance Criteria 4
– 4. Heavily Utilized Hardware 0
– 5. High Transaction Rates 3
– 6. Online Data Entry 3
– 7. Online Updating 3
– 8. End-user Efficiency 3
– 9. Complex Computations 0
– 10. Reusability 3
– 11. Ease of Installation 3
– 12. Ease of Operation 5
– 13. Portability 3
– 14. Maintainability 3
» DI =30 (Degree of Influence)
Example (…)

• Function Points
– FP=UFP*(0.65+0.01*DI)= 55*(0.65+0.01*30)=52.25

– That means the is FP=52.25

Effort Computation

• The Basic COCOMO model computes effort as a function of

program size. The Basic COCOMO equation is:
– E = aKLOC^b
• Effort for three modes of Basic COCOMO.

Mode a b

Organic 2.4 1.05

Semi- 3.0 1.12
detached
Embedded 3.6 1.20
Example
Effort Computation

• The intermediate COCOMO model computes effort as a

function of program size and a set of cost drivers. The
Intermediate COCOMO equation is:
– E = aKLOC^b*EAF
• Effort for three modes of intermediate COCOMO.
• EAF is Effort Adjustment Factor
Mode a b

Organic 3.2 1.05

Semi- 3.0 1.12
detached
Embedded 2.8 1.20
Effort computation(.)

• Effort Adjustment Factor

Cost Driver Very Low Nominal High Very Extra
Low High High
Required Reliability .75 .88 1.00 1.15 1.40 1.40
Database Size .94 .94 1.00 1.08 1.16 1.16
Product Complexity .70 .85 1.00 1.15 1.30 1.65
Execution Time Constraint 1.00 1.00 1.00 1.11 1.30 1.66
Main Storage Constraint 1.00 1.00 1.00 1.06 1.21 1.56
Virtual Machine Volatility .87 .87 1.00 1.15 1.30 1.30
Comp Turn Around Time .87 .87 1.00 1.07 1.15 1.15
Analyst Capability 1.46 1.19 1.00 .86 .71 .71
Application Experience 1.29 1.13 1.00 .91 .82 .82
Programmers Capability 1.42 1.17 1.00 .86 .70 .70
Virtual machine Experience 1.21 1.10 1.00 .90 .90 .90
Language Experience 1.14 1.07 1.00 .95 .95 .95
Modern Prog Practices 1.24 1.10 1.00 .91 .82 .82
SW Tools 1.24 1.10 1.00 .91 .83 .83
Required Dev Schedule 1.23 1.08 1.00 1.04 1.10 1,10
Effort Computation (..)

Total EAF = Product of the selected factors

Adjusted value of Effort: Adjusted Person Months:

APM = (Total EAF) * PM
Example
Software Development Time

• Development Time Equation Parameter Table:

Parameter Organic Semi- Embedded

detached
C 2.5 2.5 2.5
D 0.38 0.35 0.32

Development Time, TDEV = C * (APM **D)

Number of Personnel, NP = APM / TDEV

DETAILED/ADVANCED COCOMO
MODEL

• A major shortcoming of both the basic and

intermediate COCOMO models is that they
consider a software product as a single
homogeneous entity.
• However, most large systems are made up
several smaller sub-systems.
• These sub-systems may have widely different
characteristics.
DETAILED/ADVANCED
COCOMO MODEL

• In Advanced COCOMO Model the cost of each

subsystem is estimated separately. This approach
reduces
• Example: A distributed Management Information System
(MIS) product for an organization having offices at several
places across the country can have the following sub-
components:
• Database part
• Graphical User Interface (GUI) part
• Communication part
DETAILED/ADVANCED
COCOMO MODEL

• Of these, the communication part can be

considered as Embedded software. The
database part could be Semi-detached
software, and the GUI part Organic
software. The costs for these three
components can be estimated separately,
and summed up to give the overall cost of the
system.
Software Maintenance
Software Maintenance

“Caveat Emptor: The cost of software maintenance increases

with the square of the programmer’s creativity.”
First Law of Programmer Creativity,
Robert D. Bliss, 1992

“It doesn't take a lot of skill to get a program to work. The

skill comes in when you have to keep it working.”
--Robert Martin
What is software maintenance?

• Changes made to software after delivery.

Software may include source code,
documentation, and operating procedures.
Software Evolution
• It is impossible to produce system of any size which do
not need to be changed. Once software is put into use,
new requirements emerge and existing requirements
changes as the business running that software
changes.
• Parts of the software may have to be modified to correct
errors that are found in operation, improve its
performance or other non-functional characteristics.
• All of this means that, after delivery, software systems
always evolve in response to demand for change.
 Program Evolution Dynamic
Program evolution dynamic is the study of system change.
The majority of work in this area has been carried out by
Lehman and Belady. From these studies , they proposed a sets
of laws concerning system change.
Law Description
Continuing change A program that is used in real-world environment
necessarily must change or become progressively
less useful in that environment.
Increasing complexity As an evolving program changes, its structure
tends to become more complex. Extra resources
must be devoted to preserving and simplify the
structure.
Program Evolution Dynamic
(cont’d)
Law
Large program evolution
Organizational stability
Conservation of familiarity
Description
Program evolution is self-regulation process.
System attributes such as size, time between
release and the number of report errors are
approximately invariant for each system
release
Over a program’s lifetime, its rate of
development is approximately constant and
independent of the resources devoted to the
system development
Over the lifetime of system, the incremental
change in each release is approximately
constant.
Software Evolution Approaches

• There are a number of different strategies for

software change.
– Software maintenance
– Architectural transformation
– Software re-engineering.
• Software maintenance
– Changes to the software are made in response to
changed requirements but the fundamental
structure of the software remains stable. This is
most common approach used to system change.
Software Evolution Approaches
(cont’d)

• Architectural transformation
– This is a more radical approach to software
change then maintenance as it involves making
significant change to the architecture of the
system.
• Software re-engineering
– This is different from other strategies in that no
new functionality is added to the system.
– System re-engineering may involve some
structural modifications but dose not usually
involves major architectural change.
Types of Software Maintenance
Software Maintenance

• Software maintenance is the general process

of changing a system after it has been
diverted.
• The change may be simple changes to correct
coding errors, more extensive changes to
correct design errors or significant
enhancement to correct specification error or
accommodate new requirements.
Maintenance Characteristics

• We need to look at maintenance from three

different viewpoints: [PRE2004]
– the activities required to accomplish the
maintenance phase and the impact of a software
engineering approach (or lack thereof) on the
usefulness of such activities
– the costs associated with the maintenance phase
– the problems that are frequently encountered
when software maintenance is undertaken
Types of Maintenance

• Maintenance to repair software faults

– Changing a system to correct deficiencies in the way meets
its requirements
• Maintenance to adapt software to a different operating
environment
– Changing a system so that it operates in a different environment
(computer, OS, etc.) from its initial implementation
• Maintenance to add to or modify the system’s functionality
– Modifying the system to satisfy new requirements
 Fault repair
(17%)

functionality
software
addition or
adaption
modification
(18%)
(65%)

Maintenance effort distribution .

Development vs. Maintenance

not directly linked to the directly driven by the real

real world world
freedom constrained by existing
system
defects have no immediate defects disrupt production
effect
methods available system not using current
methods
standards may be enforced shifting standards, if any
Software Maintenance
Objectives

• Corrective,
• Adaptive,
• Perfective,
• Inspection.
Types of Maintenance

• Corrective:

– Taking existing code and correcting a fault that causes

the code to behave in some way that deviates from its
documented requirements.
Types of Maintenance

• Adaptive:

– Taking existing code and adapting it to provide new

features and functionality. These are typically part of a
new release of the code and part of a larger
development effort.
Types of Maintenance

• Perfective:

– These are typically made to improve the

maintainability of the code such as restructuring it to
make it more easily understood or to remove
ambiguities.
Types of Maintenance

• Inspection:

– These are usually made as a result of code

inspections and focus more of adhering to coding
standards or to reduce the likelihood of a failure.
Various other issues under
Software Project Management

• Risk Management
• Change Management
• Version Control
• Configuration Management
What is risk?

A risk is a possibility of loss.

Undesirable outcome.

Missed opportunity.
Anatomy of a risk

Probability of occurrence

Risk

Consequence: size of loss

Classification of software risks

• Software Project Risks

- Affecting the project plan

• Software Process/Technical Risks

- Affecting the quality

• Software Product Risks

- Affecting the viability of the product
 Example

Risk Project Technical Business Common special

HW not available X X
Requirement X X
incomplete
Use of special X X
methodologies
Problems achieving X X
required reliability
Retention of key X X
people
Understanding X X
required effort
The single potential X X
customer goes
The Risk Management Process

Identify risks

Learn about risks Risk Analyze risks

Knowledge
Base

Plan for risks

Resolve risks

Track risks
Identification: Quantification

Risk Exposure = Probability x Consequence

Calculating Risk Exposure
Factor P C RE
Late delivery 0.25 28 7 days
days
API integration delay 0.60 15 9 days
days
Additional unit testing needed; 0.90 20 18 days
3% more classes than first days
estimated
Test group reports that they may 0.50 30 15 days
not be able to fit if extra one days
month will not be given
TOTAL RISK EXPOSURE 49 days
Identification: Documentation

Project Name of project

Date Date of entry
Header Risk name Name of risk

Assessment Risk category Type of risk

Likelihood of
Action Plan Probability
occurrence
Consequence Severity of impact
Tracking
Originator Who reported this risk
Resolution Where in software
Phase/activity
process
WBS Element WBS relationship

Adapted from Managing Risk: Methods for Software Systems Development by Elaine M. Hall, Addison-Wesley 1998
Analysis: Documentation

Header
Assessment
Statement Brief description of risk
Action Plan Context When, where, how, why
Analysis Impact on project
Tracking
Resolution
Planning/Tracking: Documentation

Header
Assessment Scenario What would happen?

Action Plan Indicator Metric to be monitored

Tracking Trigger condition

Value indicating risk
scenario
Resolution
When/where to check
Checkpoint
metric

How we will handle the

Resolution strategy
risk

Action plan Concrete action plan

Resolution: Documentation

Header
Assessment
Action Plan Software Engineer Signature

Tracking Quality Engineer Signature

Project Manager Signature
Resolution Marketing Manager Signature
Risk Management Capability

5: Risk statistics used to make organizational/process improvements

4: Quantified analysis used to determine resolution cost/benefit for project

3: Risks systematically quantified, analyzed and resolved

2: Risks are usually recorded, tracked and handled as they are discovered

1: Risks ignored or only tracked in an ad-hoc fashion

Risk Management Infrastructure

Common
Risks
Checklists
Standard
Risk
Risk Template
Ranking Risk
Database
RiskTemplate With
Mgt. Statistics
Plan
Template
 Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the projec t will not be
deli vered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestimated.
product
CAS E tool under- Product CAS E tools which support the project do not perform as
performance anticipated
Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.
The risk management process
 Risks and risk types
Risk type Possible risks
Technology The database used in the system canno t process as many transactions per second
as expected.
Software components that should b e reused contain defects that limit their
func tionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unava ilable at critical times.
Requi red training for staff is not av ailable.
Organ isational The organ isation is restructured so that different manag ement are responsible for
the project.
Organ isational financial problems force reductions in the project budge t.
Tools The code generated by CASE tools is inefficient.
CASE tools canno t be integrated.
Requi rements Changes to requirements that require major design rewo rk are proposed.
Customers fail to unde rstand the impact of requirements change s.
Estimation The time required to deve lop the software is unde restimated.
The rate of defect repair is underestimated.
The size of the software is unde restimated.
Risk analysis (i)

Risk Probability Effects

Organ isational financial problems force reductions in Low Catastrophic
the project budge t.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects wh ich limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organ isation is restructured so that different High Serious
manage ment are responsible for the project.
Risk analysis (ii)

Risk Probability Effects

The database used in the system canno t process as Moderate Serious
many transactions per second as expec ted.
The time required to deve lop the software is High Serious
unde restimated.
CASE tools canno t be integrated. High Tolerable
Customers fail to unde rstand the impact of Moderate Tolerable
requirements change s.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is unde restimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant
Risk management strategies (i)

Risk Strategy
Organ isational Prepar e a b riefing document for senior manage ment
financ ial problems showing how th e project is making a v ery important
contribution to the goals of the bus iness.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, inves tigate buying- in
components.
Staff illness Reorganise team so that there is more ove rlap o f work
and people therefore understand e ach other’s jobs.
Defective Replace potentially defective components with bough t-
components in components of known reliability.
Risk management strategies (ii)

Risk Strategy
Requi rements Derive traceability information to assess requirements
chang es chang e impac t, maximise information hiding in the
design.
Organ isational Prepar e a b riefing document for senior manage ment
restructuring showing how th e project is making a v ery important
contribution to the goals of the bus iness.
Database Inves tigate the possibility of buy ing a higher-
performanc e performanc e database.
Unde restimated Inves tigate buying in components, inve stigate use of a
deve lopment time program generator
Risk indicators

Risk type Potential indicators

Technology Late delivery of hardwa re or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organ isational Organ isational gossip, lack of action by senior manage ment
Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powe red workstations
Requi rements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects
Version Control
Version control systems

• A version control system (often called a source

code control system) does these things:
– Keeps multiple (older and newer) versions of everything
(not just source code)
– Requests comments regarding every change
– Allows “check in” and “check out” of files so you know
which files someone else is working on
– Displays differences between versions

116
What is Version Control?

• Terms
– VCS, CVS, SVN, RCS
• A versioned backup system
– Restore project to a previous, working state
• A synchronized control system
– You can’t edit the same files I am editing
– Well, not without making sure it works
What is Version Control?

• Manages file sharing for

Concurrent Development

• Keeps track of changes with

Version Control

• SubVersion (SVN)
is a version control system
Why version control?

• Scenario 1:
– Your program is working
– You change “just one thing”
– Your program breaks
– You change it back
– Your program is still broken--why?

• Has this ever happened to you?

119
Why version control? (part 2)

• Your program worked well enough yesterday

• You made a lot of improvements last night...
– ...but you haven't gotten them to work yet
• You need to turn in your program now

• Has this ever happened to you?

120
Version control for teams

• Scenario:
– You change one part of a program--it works
– Your co-worker changes another part--it works
– You put them together--it doesn’t work
– Some change in one part must have broken something
in the other part
– What were all the changes?

121
Teams (part 2)

• Scenario:
– You make a number of improvements to a class
– Your co-worker makes a number of different
improvements to the same class
• How can you merge these changes?

122
What does it look like?

The All Versions of all

“Repository the files
”

Alice’s Local Joe’s Local Jane’s Local

Version Version Version
What does it look like?

The “Repository” All Versions of all the files

Add a new file

(or directory)
that everyone
can see
“OK” or “File already exists”

Alice’s Local Version Joe’s Local Version Jane’s Local Version

What does it look like?

The “Repository” All Versions of all the files

Commit my
changes so “OK” or “Your files are out of date”
everyone can
see them

Alice’s Local Version Joe’s Local Version Jane’s Local Version

What does it look like?

The “Repository” All Versions of all the files

Update my local files

to reflect all changes
“OK” or
“Your files
conflict”

Alice’s Local Version Joe’s Local Version Jane’s Local Version

What does it look like?

The “Repository” All Versions of all the files

Call what I have

“Release 1.0”

“OK”

Alice’s Local Version Joe’s Local Version Jane’s Local Version

What does it look like?

The “Repository” All Versions of all the files

Create a
separate
version: “Release
1.0.joe” for local “OK”
testing

Alice’s Local Version Joe’s Local Version Jane’s Local Version

What does it look like?

The All Versions of all

“Repository the files
Six Months
”
Later
Merge my
special “OK”
version
back into
the
main
product

Alice’s Local Joe’s Local Jane’s Local

Version Version Version
What does it look like?

The All Versions of all

“Repository the files
”
One Year
Later Give me “Release 1.

Release “OK”
1.5-Joe
causes
injuries!

Alice’s Local Joe’s Local Jane’s Local

Version Version Version
Version and Variant

◼ Version: a CI at one point in its development,

includes revision and variant

◼ Variant: functionally equivalent versions, but

designed for different settings, e.g. hardware
and software
Forty year history

• A steady movement toward more concurrency.

• In first generation tools, concurrent development
was handled solely with locks. Only one person
could be working on a file at a time.
• The second generation tools are a fair bit more
permissive about simultaneous modifications, with
one notable restriction. Users must merge the
current revisions into their work before they are
allowed to commit.
• The third generation tools allow merge and 132
commit to be separated.
History

133
Create :Create a new, empty
repository.

• A repository is the official place where you store

all your work.
• A repository is three dimensional:
• Directories, files, and time.
• A version control repository contains every version
of your source code that has ever existed.

134
Checkout : Create a working
copy.

• The checkout operation is used when you need to

make a new working
• It is a copy of a repository that already exists.
• A working copy is a copy used for working.

135
Commit

• Apply the modifications in the working copy to the

repository as a new changeset.
• The commit operation takes the pending
changeset and uses it to create a new version of
the tree in the repository.

136
Log message

• It is typical to provide a log message (or comment)

when you commit, explaining the changes you
have made.
• This log message becomes part of the history of
the repository.

137
Update

• Update the working copy with respect to the

repository.

138
Update

• Update brings your working copy up-to-date by

applying changes from the repository, merging
them with any changes you have made to your
working copy if necessary.
• The VCS remembers that revision so that it can
keep careful track of where you started making
your changes.
• This revision is often referred to as the parent of
the working copy.
139
Add : Add a file or directory.

• Use the add operation when you have a file or

directory in your working copy that is not yet under
version control and you want to add it to the
repository.
• The item is not actually added immediately.

140
Edit : Modify a file.

• This is the most common operation when using a

version control system.
• When you checkout, your working copy contains a
bunch of files from the repository.
• You modify those files, expecting to make your
changes a part of the repository.

141
Delete :Delete a file or directory.

• Use the delete operation when you want to

remove a file or directory from the repository.
• If you try to delete a file which has been modified
in your working copy, your VCS might complain.
• Typically, the delete operation will immediately
delete the working copy of the file, but the actual
deletion of the file in the repository is simply added
to the pending changeset.

142
Rename: Rename a file or
directory.

• Use the rename operation when you want to

change the name of a file or directory.

143
Move :Move a file or directory.

• Use the move operation when you want to move a

file or directory from one place in the tree to
another.

144
Status

• List the modifications that have been made to the

working copy.
• As you make changes in your working copy, each
change is added to the pending changeset.
• The status operation is used to see the pending
changeset.
• Or to put it another way, status shows you what
changes would be applied to the repository if you
were to commit.
145
Diff

• Show the details of the modifications that have

been made to the working copy.
• Status provides a list of changes but no details
about them.
• To see exactly what changes have been made to
the files, you need to use the diff operation.

146
Revert

• Undo modifications that have been made to the

working copy.
• A complete revert of the working copy will throw
away all your pending changes and return the
working copy to the way it was just after you did
the checkout.

147
Log: Show the history of
changes to the repository.

• Your repository keeps track of every version that

has ever existed. The log operation is the way to
see those records. It displays each changeset
along with additional data such as:
• • Who made the change?
• • When was the change made?
• • What was the log message?
• Most version control tools present ways of slicing
and dicing this information.
• For example, you can ask log to list all the 148
Tag :Associate a meaningful name with a
specific version in the repository.

• Version control tools provide a way to mark a

specific instant in the history of the repository with
a meaningful name.
• This is not altogether different from the descriptive
and memorable names we use for variables and
constants in our code.

149
Branch : Create another line of
development.

• The branch operation is what you use when you

want your development process to fork off into two
different directions.

150
Merge : Apply changes from one
branch to another.

• Typically when you have used branch to enable

your development to diverge, you later want it to
converge again, at least partially.

151
Resolve :Handle conflicts
resulting from a merge.

• In some cases, the merge operation requires

human intervention.
• Merge automatically deals with everything that can
be done safely.
• Everything else is considered a conflict.

152
Lock : Prevent other people
from modifying a file.

• The lock operation is used to get exclusive rights

to modify a file.
• Not all version control tools include this feature. In
some cases, it is provided but is intended to be
rarely used.

153
How Versions are Stored

◼ Full copy of each version

◼ Delta (differences between two versions)
◼ Forward delta

1.1 1.2 1.3 1.4

◼ Reverse delta

1.1 1.2 1.3 1.4

◼ Mixed delta
Version Control Models (1/3)

◼ Basic problem of collaborative work

Figure from svn-book

Version Control Models (2/3)

◼ Model 1-Pessimistic: lock-modify-unlock

Problems:

◼ Forget to unlock

◼ Parallel work not

possible

◼ Deadlock
Figure from svn-
book
Version Control Models (3/3)

Model 2-Optimistic: copy-modify-merge

Figure from svn-book

diff tools

• There are a number of tools that help you spot

changes (differences) between two files
• Tools include diff, rcsdiff, jDiff, etc.
• Of course, they won't help unless you kept a copy
of the older version
• Differencing tools are useful for finding a small
number of differences in a few files

158
jDiff

• jDiff is a plugin for the jEdit editor

• Advantages:
– Everything is color coded
– Uses synchronized scrolling
– It's inside an editor--you can make changes directly
• Disadvantages:
– Not stand-alone, but must be used within jDiff
– Just a diff tool, not a complete solution

159
jDiff

160
sccs

• sccs is Source Code Control System (UNIX)

• sccs keeps multiple versions of a complete
directory
• Storage requirements are small, because sccs:
– keeps the original documents
– keeps the changes needed to go from one version to
the next
– generates any version when you ask for it

161
CVS

• CVS (Concurrent Versions System) is the most

popular version control system on Windows
• CVS is built on top of rcs
• CVS is built into JBuilder and Eclipse
• http://www.cvshome.org/dev/codewindow.html

162
Create a Repository

• Determine Structure
• Determine Permissions
Import or Checkout

• Import - I have the files and I want to put them into

the initial repository
• Checkout - I want to start working on an existing
repository
Update and Check-in

• Update - Updates the local files to match the

central repository
• Check-in - Update the central repository to match
your local files
• Always update before checking in (svn enforces
this)
• Always test with the latest update before checking
in (not enforced)
Merge

• We both update the same file at the same time.

What happens?
• Update tells me there is a conflict
– You checked yours in first
• I have to merge the two updates together.
– Before checking in
How to use SVN (in a nutshell)

• Checkout:
• receives a copy of an entire project from the SVN server
• (source files, project & make files, resource files, etc.)
• Update:
• receives copies of individual files or folders on the server
and merges them with your current copy (locally)
• Commit:
• sends an updated file (your local copy) to the SVN server where it is
incorporated into the original project database; a new version number is
assigned not the entire project
• Add:
• notifies SVN of a new file or folder that needs to be added to the existing
project (only if SVN is aware of a file, can you commit the file)
Further Considerations

• before doing a commit

you MUST do an UPDATE (and resolve any
possible conflicts) BEFORE you COMMIT your
copy

• to add a new file or folder

you need to use ADD and then COMMIT

• if you want to get rid of a file,

you need to delete it in your local folder
and then COMMIT the folder
Further Considerations (cont.)

• Make sure to UPDATE REGULARLY

otherwise you will have lots of conflicts

• SVN will not help you

if you do not COMMIT REGULARLY

• If you add lots of new stuff,

make sure to COMMIT EVERYTING
Benefits of Version Control

• Ability to return to an earlier version

– In case of error or failure in working copy
– To view snapshot in time
• Track who made changes
• Maintain current pages while developing their
replacements
• Record of development process
Drawbacks of Version Control

• Time investment to train personnel to use system

• Temptation to change system to take advantage
of latest technology (Dennis, 1998)
• No access if central server is unavailable
• Possibility of commit wars
Version Control for Your Project

• Decide how often to commit files

• Pick your method:
– Version control software
– Zip archives
– Folders
Client-Server VCS

• In Client-Server VCS there is one centralized

server and a number of clients
– The centralized server holds all the files under revision
control
– The clients access the files from the centralized server
• Subversion is the most popular Client-Server VCS
designed to replace CVS
Client-Server VCS

Client

Client Server

Client
Subversion Client-Server VCS

• Many Open Source Projects are converting from

Subversion to DVCS (git, mercurial, bzr)
– Making a commit requires a network connection
– Merging is harder than in mercurial
– Second tier contributers are left with no versioning
system
• Free hosting for open source projects:
– http://code.google.com/
Distributed VCS

• In Distributed VCS there is a peer to peer model

– When you want to get the code, you download the
entire repository contents
– You can then simply host a repository by allowing
incoming connections
– DVCS is used in Open Source Software Development
• The maintainer of a project could stop answering his or her
emails
• The other developers already have the full repository.
Distributed VCS

Peer

Peer

Peer
 SOFTWARE
CONFIGURATION MANAGEMENT (SCM)
What is Configuration
Management?

• The control of changes made throughout the

system lifecycle.

– Allows changes to be evaluated before they are

approved.
– Considers interrelationships among system
components.
 Software Configuration
Management

• A software engineering discipline

– Comprised of tools and techniques
– used to manage change to software assets.

• A set of activities to control change by:

– identifying the products & establishing relationships
– defining mechanisms for management, control, auditing
and reporting on changes made.

In short: “A methodology to control and manage a

software development project.”
Why do we need SCM?

• To manage:
– Many people working on the same code.
– Projects delivered in several releases
(builds).
– Rapid evolution of software and hardware.
– Project surveillance:
• i.e. project’s status, bugs, features, etc.
– Concurrent support and development.
– Stress time requirements of projects.
 What Are The Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements other
documents

software models
Project
Plan
data
Test
code

184
The Software Configuration

programs documents

The pieces
data

185
SCM Elements

• Component elements—a set of tools coupled within a file

management system (e.g., a database) that enables access
to and management of each software configuration item.
• Process elements—a collection of procedures and tasks that
define an effective approach to change management (and
related activities) for all constituencies involved in the
management, engineering and use of computer software.
• Construction elements— a set of tools that automate the
construction of software by ensuring that the proper set of
validated components (i.e., the correct version) have been
assembled.
• Human elements— to implement effective SCM, the software
team uses a set of tools and process features
186 (encompassing other CM elements)
 The SCM Process
• How does a software team identify the discrete elements of
a software configuration?
• How does an organization manage the many existing
versions of a program (and its documentation) in a manner
that will enable change to be accommodated efficiently?

• How does an organization control changes before and after

software is released to a customer?

• Who has responsibility for approving and ranking changes?

• How can we ensure that changes have been made

187
properly?
 The SCM Process
Software
Vm.n

reporting

configuration auditing

version control

change control

identification

SCIs

188
 Software Process Improvement
(SPI)
Review

SPI IS
– PROCESS TO IMPROVE SOFTWARE
– DEVELOPED BY SE
– IDENTIFIES STEPS PRODUCT MUST GO THROUGH
– APPLICABLE THROUGHOUT SOFTWARE LIFE
CYCLE
Capability Maturity Model (CMM)

Review

The CMM - FRAMEWORK FOR SOFTWARE

IMPROVEMENT PROCEDURES

Identifies
• Maturity Levels
• Key Process Areas
• Key Elements
 KEY PROCESS AREAS (KPAs)
As Defined by
SOFTWARE ENGINEERING INSTITUTE (SEI)
“SOFTWARE ENGINEERING AND MANAGEMENT PRACTICES”
LEVEL 1 - INITIAL
LEVEL 2 -REPEATABLE
REQUIREMENTS PROJECT SUBCONTRACT SOFTWARE SOFTWARE
PROJECT QUALITY
MANAGEMENT TRACKING & MANAGEMENT CONFIGURATION
PLANNING ASSURANCE
OVERSIGHT MANAGEMENT

LEVEL 3 - DEFINED

ORGANIZATION ORGANIZATION INTEGRATED SOFTWARE INTERGROUP PEER

TRAINING PRODUCT
PROCESS PROCESS PROGRAM SOFTWARE COORDINATION REVIEWS
FOCUS DEFINITION MANAGEMENT ENGINEERING

LEVEL 4 - MANAGED
PROCESS
MEASUREMENT QUALITY
& MANAGEMENT
ANALYSIS

LEVEL 5 - OPTIMIZING

DEFECT PROCESS
TECHNOLOGY CHANGE
PREVENTION INNOVATION MANAGEMENT
System Modification Scenario (SMS)

Review

The SMS is:

A part of the Software Process Architecture, that
provides process definition, description and
documentation of how work is accomplished during
routine system modification and/or enhancement.
 SOFTWARE PROCESS ARCHITECTURE
SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES
CHANGE INITIATION CHANGE DEFINITION CHANGE ANALYSIS

PROBLEM CHANGE
CHANGE/ (PTR) (SCR) FUNCTIONAL REQUIREMENTS
PROBLEM DOCUMENTATION INITIATION, REQ’MENTS ANALYSIS SPECIFICATION
DEFINITION & REVIEW, DEFINITION PREPARATION & IMPACT
DISPOSITION APPROVAL, ANALYSIS
& RANKING

CHANGE ANALYSIS (Contd.) CHANGE APPROVAL & PLANNING

SYSTEM/ PROPOSED RELEASE CCB DEVELOPMENT

DESIGN SUBSYSTEM RESOURCE RELEASE PLANNING RELEASE REVIEW & ITSA
PREPARATION DESIGN ESTIMATION PACKAGE ITSA PREP & PLANNING APPROVAL PREP. &
DEVELOPMENT ACCEPTANCE ACCEPTANCE

CHANGE DEVELOPMENT
System/Subsystem
DETAILED Design UNIT CODE
Release SYSTEM DETAILED & COMPUTER DETAILED DETAILED &
DOCUMENTATION SAT SQT SIT UT
Planning DEFINITION SOFTWARE UNIT UNIT
MODIFICATION DEFINITION SPECIFICATIONS DEFINITION DEFINITION TEST(UT)
DEVELOPMENT

CHANGE DEVELOPMENT (Contd.) CHANGE IMPLEMENTATION

SIT SQT SAT RELEASE POST

EXECUTION EXECUTION EXECUTION IMPLEMEN- RELEASE
& & & TATION IMPLEMEN-
CERTIFICATION CERTIFICATION CERTIFICATION TATION
Purpose of Software
Configuration Management

• To establish and maintain the integrity or software

products through the project’s life cycle.
 What are the major functions of
Configuration Management (CM)?

IDENTIFICATION CONTROL

STATUS
ACCOUNTING AUDIT
 Configuration Identification

IDENTIFICATION
IDENTIFICATION
The first function of
CM:

• Identify Configuration Items (CIs)

• Document Functional and Physical
Characteristics
Configuration Items (CI)

REQUIREMENTS OPERATIONAL ACCOUNTING

DOCUMENT PROCEDURE SYSTEM

A/P A/R
CHAPTER 1 SECTION 1

CHAPTER n SECTION n
ADD

UPDATE

DELETE
 Configuration Control

Second Function of
Configuration Management CONTROL

• Configuration Control consists of:

– Change Evaluation
– Change Coordination
– Change Approval or disapproval
– Change Implementation
Configuration Status Accounting
Third Function of Configuration Management

• Tracks SCR Status to include:

– Proposed changes (Formal SCRs)
– Waivers and deviations to configuration
(Emergency SCRs)
– Implementation of approved changes

STATUS
ACCOUNTING
Configuration Audit
Fourth Function of Configuration
Management
• Verifies SCR
• Verifies each CI conforms to required
specifications
• Types of Audit
– Configuration
–Functional Configuration
–Physical Configuration
– Internal AUDIT
Software configuration
management activities are
planned.
CMM SCM
Activities to support Goal 1

»Prepare a SCM Plan.

»Use the SCM Plan.
Selected work products are
identified, controlled, available.
CMM SCM
Activities to support Goal 2

• Use the SCM plan.

• Establish the CM library system.
• Identify the work products to be placed under
CM.
• Create and release products from the CM
library.
CMM Goal 3

Changes to identified work

products are controlled.
CMM SCM
Activities to support Goal 3

• Initiate, record, review, approve and track

SCRs.
• Control changes to baselines.
Affected groups and individuals
are informed of baseline status
and content.
CMM SCM
Activities to support Goal 4

• Record status of CIs.

• Create standard reports and provide to
affected groups and individuals.
• Conduct baseline audits.
 SOFTWARE PROCESS ARCHITECTURE
SYSTEM MODIFICATION SCENARIO - PHASES & SUBPHASES
CHANGE INITIATION CHANGE DEFINITION CHANGE ANALYSIS

PROBLEM CHANGE
CHANGE/ (PTR) (SCR) FUNCTIONAL REQUIREMENTS
PROBLEM DOCUMENTATION INITIATION, REQ’MENTS ANALYSIS SPECIFICATION
DEFINITION & REVIEW, DEFINITION PREPARATION & IMPACT
DISPOSITION APPROVAL, ANALYSIS
& RANKING

CHANGE ANALYSIS (Contd.) CHANGE APPROVAL & PLANNING

SYSTEM/ PROPOSED RELEASE CCB DEVELOPMENT

DESIGN SUBSYSTEM RESOURCE RELEASE PLANNING RELEASE REVIEW & ITSA
PREPARATION DESIGN ESTIMATION PACKAGE ITSA PREP & PLANNING APPROVAL PREP. &
DEVELOPMENT ACCEPTANCE ACCEPTANCE

CHANGE DEVELOPMENT
System/Subsystem
DETAILED Design UNIT CODE
Release SYSTEM DETAILED & COMPUTER DETAILED DETAILED &
DOCUMENTATION SAT SQT SIT UT
Planning DEFINITION SOFTWARE UNIT UNIT
MODIFICATION DEFINITION SPECIFICATIONS DEFINITION DEFINITION TEST(UT)
DEVELOPMENT

CHANGE DEVELOPMENT (Contd.) CHANGE IMPLEMENTATION

RELEASE POST
EXECUTION EXECUTION EXECUTION IMPLEMEN- RELEASE
& & & TATION IMPLEMEN-
CERTIFICATION CERTIFICATION CERTIFICATION TATION
SCM Plan
• Defines:
– What SCM activities are to be accomplished
– How SCM activities are to be accomplished
– Who is responsible for performing SCM activities
– When SCM activities are to be accomplished
– What resources are required to accomplish SCM
activities
– When the SCM Plan shall be reviewed, updated and
approved

S C M P
 CM Terminology

P S C
C RELEASE
T C C
I
R R O

T • PROBLEM TROUBLE REPORT (PTR)

D • SYSTEM CHANGE REQUEST (SCR)
R • CONFIGURATION CHANGE ORDER (CCO)
• CONFIGURATION ITEM (CI)
• TEST DISCREPANCY REPORT (TDR)
• RELEASE
Problem Trouble Report

P • Description of a Detected Problem with:

T
R • Design
• Software
• Documentation
• Management Process (i.e., the SMS)
• Becomes SCR if PTR impacts CI(s)
• Closed if no impact on CI(s)
System Change Request

S
C • Formalizes change request
R
• Identifies affected components
• Defines the change requirements
• Provides the associated Software Change
Specification (SCS).
• Impacts Configuration Items (CI)
– One CI or Many CIs
– Requires a CCO
PTR / SCR Process Overview

problem Employee change

C C
C identifies
I
O
P S
T change
C resolution

R R
C C
C identifies
close/ I
no change O
TEST DISCREPANCY REPORT (TDR)

T • SIGNIFIES SOME PORTION OF TEST

D FAILED
R

• ABLE TO CREATE CCOs TO IDENTIFY

IMPACTED CIs
Configuration Change Order

• Identifies:
C
C • Configuration Item (CI) impacted
O
– a CCO addresses only one CI

• Estimated size of change

• Estimated effort to implement change
• Actual effort expended
• Synopsis of change
Configuration Item

C
I
• Is a separate single item of the Software
• Is controlled
• Examples:
– Functional Descriptions, Software Code, Test
Entities, Standard Operating Procedures,
Training Manuals, Etc..
Release

RELEASE

• A collection of selected SCRs

– Approved
– Funded for implementation
– Containing associated CI changes
• Once release occurs, it becomes the official
version of an system.
SCR - CCO - CI Relationship

S C
C C C
R O I
Typical SCR - CCO - CI Relationship
S C
C C C
R O I
C
C
O
C
C C
O I
C
S C
C O
R C
C C
O I

Each SCR may affect multiple CIs which must be controlled by

separate CCOs.
Baselines

• The IEEE (IEEE Std. No. 610.12-1990) defines a

baseline as:
• A specification or product that has been formally
reviewed and agreed upon, that thereafter serves as
the basis for further development, and that can be
changed only through formal change control
procedures.
• A baseline is a milestone in the development of
software that is marked by the delivery of one or
more software configuration items and the approval
of these SCIs that is obtained through a formal
technical review.
221
 Baselines
modified
SCIs
Project database
approved
Software Formal
engineering SCIs technical SCIs
tasks reviews

stored

SCIs

extracted
SCM SCIs
controls

BASELINES :
System Specification
Software Requirements
Design Specification
Source Code
Test Plans/Procedures/Data
Operational System

222
Software Baseline Library

• The Software Baseline Library is a controlled

environment where the CIs and SCM records
pertaining to the CI are stored and must have:
– established controls to prevent unauthorized
changes,
– flexible service provided to programmers/testers,
– development/testing applied to trial versions of CIs
Software Configuration Objects

Data model

Design specification

data design
architectural design
module design
interface design

Component N

interface description
algorithm description
Test specification PDL

test plan
test procedure
test cases

Source code

224
Effective SCM Benefits
• Changes to Configuration Items are:
– properly documented and approved
– based on agreed upon requirements
– traced through design and development
– fully integrated and tested
– implemented into a quality release
– well arranged throughout system’s life cycle
• Status is easily determined at any time
• Facilitates correction action, if required
Configuration Management’s First Role
in the SMS
CHANGE INITIATION PHASE

Purpose: Define, record and track the initial actions to begin the
cycle of change to an AIS by defining the problem or change and
creating a Problem Trouble Report (PTR) or a System Change
Request (SCR).

Subphases:
• Problem (PTR) Documentation & Disposition
• Change (SCR) Initiation, Review, Approval, & Ranking
Configuration Management’s Second
Role in the SMS
CHANGE APPROVAL AND PLANNING PHASE

Purpose: Establish a release package plan.

Subphases:
• Release Planning
Configuration Management’s Third
Role in the SMS
CHANGE DEVELOPMENT PHASE

Purpose: Modify the system design, software, documentation, test

scripts and test data to fulfill System Change Request (SCR)
requirements.

Subphases:
• Release Planning
• System/Subsystem Design & CSU Specifications Development
• Unit Coding & Unit Testing Tracking and Oversight
• Software Integration Test (SIT) Execution and Certification
• Software Qualification Test (SQT) Execution and Certification
• Software Acceptance Test (SAT) Execution and Certification
Configuration Management’s Final Role
in the SMS
CHANGE IMPLEMENTATION PHASE

Purpose: Immediately before release provide all users with the

necessary documentation and training required to use the new
release.
Perform a review after implementation to verify accuracy and
completeness of the release.

Subphases:
• Release Implementation
SCM Repository

• The SCM repository is the set of mechanisms and

data structures that allow a software team to
manage change in an effective manner
• The repository performs or precipitates the
following functions :
– Data integrity
– Information sharing
– Tool integration
– Data integration
– Methodology enforcement
– Document standardization
230
Repository Content
u se -case s
b u sin e ss ru le s an aly sis m o d e l so u rce co d e
b u sin e ss fu n ct io n s sce n ario -b ase d d iag ram s o b j e ct co d e
o rg an izat io n st ru ct u re flo w -o rie n t e d d iag ram s sy st e m b u ild in st ru ct io n s
in fo rm at io n arch it e ct u re class-b ase d d iag ram s
b e h av io ral d iag ram s Const ruct ion
d e sig n m o d e l Cont ent
arch it e ct u ral d iag ram s
Business in t e rface d iag ram s
Cont ent co m p o n e n t -le v e l d iag ram s
t e ch n ical m e t rics t e st case s
t e st scrip t s
t e st re su lt s
q u alit y m e t rics
Model
Cont ent
V&V
Cont ent

Project
Management
p ro j e ct e st im at e s Cont ent
p ro j e ct sch e d u le
SCM re q u ire m e n t s
Pro j e ct Plan
ch an g e re q u e st s Document s SCM/ SQA Plan
ch an g e re p o rt s
Sy st e m Sp e c
SQA re q u ire m e n t s
Re q u ire m e n t s Sp e c
p ro j e ct re p o rt s/ au d it re p o rt s
De sig n Do cu m e n t
p ro j e ct m e t rics
Te st Plan an d Pro ce d u re
231 Su p p o rt d o cu m e n t s
Use r m an u al
Repository Features
• Versioning.
– saves all of these versions to enable effective management of
product releases and to permit developers to go back to previous
versions
• Dependency tracking and change management.
– The repository manages a wide variety of relationships among the
data elements stored in it.
• Requirements tracing.
– Provides the ability to track all the design and construction
components and deliverables that result from a specific
requirement specification
• Configuration management.
– Keeps track of a series of configurations representing specific
project milestones or production releases. Version management
provides the needed versions, and link management keeps track
of interdependencies.
• Audit trails.
232
– establishes additional information about when, why, and by whom
changes are made.
SCM – How it is accomplished?

All these goals are accomplished through

Version control

Management of multiple revisions of the same unit

of information.
 Version Control

• Version control combines procedures and tools to manage

different versions of configuration objects that are created
during the software process
• A version control system implements or is directly
integrated with four major capabilities:
– a project database (repository) that stores all relevant configuration
objects
– a version management capability that stores all versions of a
configuration object (or enables any version to be constructed using
differences from past versions);
– a make facility that enables the software engineer to collect all
relevant configuration objects and construct a specific version of the
software.
– an issues tracking (also called bug tracking) capability that enables
the team to record and track the status of all outstanding issues
234 associated with each configuration object.
 Change Control Process—I
need for change is recognized

change request from user

developer evaluates

change report is generated

change control authority decides

request is queued for action

change request is denied
user is informed
change control process—II

235
 Change Control Process-II
assign people to SCIs

check-out SCIs

make the change

review/audit the change

establish a “baseline” for testing

change control process—III

236
 Change Control Process-III
perform SQA and testing activities

check-in the changed SCIs

promote SCI for inclusion in next release

rebuild appropriate version

review/audit the change

include all changes in release

237
 Auditing

Change
Requests SQA
Plan
SCIs

SCM Audit

238
 Status Accounting
Change
Change Reports
Requests ECOs

SCIs

Status Accounting

Reporting

239
SCM for Web Engineering-I

• Content.
– A typical WebApp contains a vast array of content—text, graphics, applets,
scripts, audio/video files, forms, active page elements, tables, streaming data,
and many others.
– The challenge is to organize this sea of content into a rational set of
configuration objects and then establish appropriate configuration control
mechanisms for these objects.
• People.
– Because a significant percentage of WebApp development continues to be
conducted in an ad hoc manner, any person involved in the WebApp can
(and often does) create content.

240
SCM for Web Engineering-II

• Scalability.
– As size and complexity grow, small changes can have far-reaching and
unintended affects that can be problematic. Therefore, the rigor of
configuration control mechanisms should be directly proportional to
application scale.
• Politics.
– Who assures that quality control processes have been followed before
information is published to the site?
– Who is responsible for making changes?
– Who assumes the cost of change?

241
Change Management for WebApps-I

classify t he
request ed change

class 1 change class 4 change

class 2 change class 3 change

dev elop brief writ t en dev elop brief writ t en

acquire relat ed object s
assess impact of change descript ion of change descript ion of change

t ransmit t o all t eam t ransmit t o all st ake-

members for rev iew holders for rev iew
changes
required
in relat ed
object s

furt her furt her

ev aluat ion ev aluat ion
is required OK t o make is required OK t o make
242
 Change Management for
WebApps-II

check out object (s)

t o be changed

make changes
design, const ruct , t est

check in object (s)

t hat were changed

publish t o WebApp

243