Planning a Software Project

1 10/20/23
Project Failures

• Major reasons for project runaways

− unclear objectives
− bad planning
− no project management methodology
− new technology
− insufficient staff
• All of these relate to project management
• Effective project management is key to successfully executing
a project

2
Why improve PM?

• Better predictability leading to commitments that can be met

• Lower cost through reduced rework, better resource mgmt,
better planning,..
• Improved quality through proper quality planning and control
• Better control through change control, monitoring etc.

3
Why improve PM ….

• Better visibility into project health and state leading to timely

intervention
• Better handling of risks reducing the chances of failure
• All this leads to higher customer satisfaction
• And self and organization improvement

4
Two Dimensions in project execution

5
Process-based Project Execution

• Small project both engg and PM can be done informally

• Large projects require formality
• Formality: well defined processes used for each task;
measurements used to control
• Here we focus on processes for PM only

6
The Project Mgmt Process

• Has three phases - planning, monitoring and control, and

closure
• Planning is done before the main engineering life cycle (LC)
and closure after the LC
• Monitoring phase is in parallel with LC

7
Project Planning

• Basic objective:
− To create a plan to meet the commitments of the project
− create a path that, if followed, will lead to a successful project
• Planning involves
− defining the LC process to be followed, estimates, detailed schedule,
plan for quality, etc.
• Main output
− a project management plan, and
− project schedule

8
Key Planning Tasks

• Define suitable processes for executing the project

• Estimate effort
• Define project milestones and create a schedule
• Define quality objectives and a quality plan
• Identify risks and make plans to mitigate them
• Define measurement plan, project-tracking procedures,
training plan, team organization, etc.

9
Process Planning

• Plan how the project will be executed, (ie. the process to be

followed)
• Process will decide the tasks, their ordering, milestones
• Hence process planning is an important project planning task
• Should plan for LC and PM processes as well as supporting
processes

10
Life Cycle Process

• Various LC models - waterfall, iterative, prototyping;

diff models suit different projects
• During planning can select the model that is best for
the project
• This gives the overall process which has to be fine-
tuned to suit the project needs
• Usually done by process tailoring - changing the
process to suit the project
• Tailoring finally results in adding, deleting, modifying
some process steps

11
Planning Principles

• Understand scope
• Involve customer in planning.
• Recognize planning is iterative.
• Estimate based on what you know.
• Consider risk as you define plan.
• Be realistic- 100 %..omissions in communication.
• Adjust granularity ( detail) as you define plan.
• Define how you ensure quality.
• Accommodation of changes.
• Track plan frequently

12 10/20/23
Project Planning

• Objective is to make reasonable estimates of resources, cost,

schedule. ( Manager).
• Suggest best case & worst case scenario.

13 10/20/23
 Main objectives with a project plan

• Guide project execution

• Document project planning assumption

• Document project planning decisions regarding alternatives

chosen

• Facilitate communication among stakeholders

14 10/20/23
• Define key management reviews as to content, extent, and
timing

• Provide a baseline for progress measurement and project

control

15 10/20/23
The form of a project plan

• 1. Scope and Objectives –

• 2. Work Breakdown Structure (WBS) –
• 3. Budget and Schedule –
• 4. Risks –
• 5. Monitoring and Reporting Mechanisms –
• 6. Resources –
• 7. Knowledge & Skills –
• 8. Stakeholder Involvement -

16 10/20/23
Steps/ Task Set

• 1. Establish Project scope.

• 2.Determine Feasibility.
• 3.Analyze Risks.
• 4.Define required sources.
• a) Determine human resources required.
• b) Define reusable software resources.
• c) Identify environmental resources.
• 5 . Identify cost & effort.
• a) Decompose the problem.
• b) Develop two or more estimates using size, function points,
process tasks or usecases.

17 10/20/23
• c) Reconcile Estimates.

• 6. Develop a project schedule.

• Establish meaningful task set.
• Define a task network
• Use scheduling tools to develop a timeline chart.
• Define schedule tracking mechanisms.

18 10/20/23
Different types of project plans

• Quality plan - Includes the quality procedures and standards that concern the
project.
• Validation plan - Covers approaches, resources and schedule involved in the system
validation.

• Configuration management plan – Consists of the configuration management

procedures and structures to support the project.

• Maintenance plan - Predicts the maintenance requirements, maintenance costs and

the effort required.

• Staff development plan - Includes how available skills and experience will be
developed

19 10/20/23
• Project Planning
• Scope Management
• Project Estimation

20 10/20/23
Project Planning

• Performed before the production of software actually starts.

• set of multiple processes
• Scope Management
• creates boundaries of the project by clearly defining what would
be done in the project and what would not be done.
•
• During Project Scope management, it is necessary to -
• Define the scope
• Decide its verification and control
• Divide the project into various smaller parts for ease of management.
• Verify the scope
• Control the scope by incorporating changes to the scope

21 10/20/23
Software Scope

• Functions that are delivered to the end user.

• Includes

• Data as input & output.

• Scope is defined using..

• 1. A narrative description of software scope is developed after

communication with stake holders.

• 2. A set of use cases ( actions, events) is developed by end users.

22 10/20/23
Need for cost estimation

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.

23
Cost of a project

 The factors that affect cost of a project is due to:

 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)
 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.

24
Software Cost Estimation

25
COCOMO models

• The COstructive COst Model (COCOMO) is the

most widely used software estimation model in
the world. It
• 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.

26
Emperical Estimation Model- COCOMO

• Boehm
• Software development project can be classified into one of the
following three categories based on the development complexity:
• 1. organic-"small" teams with "good" experience working with "less than
rigid" requirements, the project deals with developing a well understood
application program

• 2. semidetached- "medium" teams with mixed experience working with a mix

of rigid and less than rigid requirements,
• The development consists of a mixture of experienced and inexperienced
staff.

• 3.Embedded- developed within a set of "tight" constraints. It is also

combination of organic and semi-detached projects.

27 10/20/23
• 1981

• software cost estimation should be done through three stages

• Basic COCOMO,

• Intermediate COCOMO

• Complete COCOMO.

28 10/20/23
Basic COCOMO Model
• Effort =a1 х(KLOC)a 2 PM

• KLOC is the estimated size of the software product expressed in Kilo Lines of Code,
• •a1, a2, b1, b2
• are constants for each category of software products.

• Tdev = b1 x (Effort)b2 Months

• Tdev is the estimated time to develop the software, expressed in months,

•
• • Effort is the total effort required to develop the software product, expressed in
person months (PMs).

29 10/20/23
Effort
• Effort Equation
− Effort = a * (KLOC)b (person-months)
• where Effort = number of person-month
(=152 working hours),
• a = a constant,
• KLOC = thousands of “lines of code"
(LOC) and
• b = a constant.

30
Effort
• Effort Equation
− Effort = a * (KLOC)b (person-months)
• where Effort = number of person-month
(=152 working hours),
• a = a constant,
• KLOC = thousands of “lines of code"
(LOC) and
• b = a constant.

31
 Productivity
• Productivity equation
− (KLOC) / (Effort)
• where Effort = number of person-month
(=152 working hours),

32
Schedule
• Schedule equation
− Duration, D = C * (E)d (months)
• where D = number of months estimated for
software development.

33
Average Staffing
• Average Staffing Equation
− (Effort) / (D) (FSP)
• where FSP means Full-time-equivalent
Software Personnel.

34
Estimation of development effort

•
• For the three classes of software products, the formulas for
estimating the effort based on the code size.

• Organic : Effort = 2.4(KLOC)1.05 PM

• Semi-detached : Effort = 3.0(KLOC)1.12 PM

• Embedded : Effort = 3.6(KLOC)1.20 PM

35 10/20/23
Estimation of development time

•
• For the three classes of software products, the formulas for estimating the
development time based on the effort are given below:

• Organic : Tdev = 2.5(Effort)0.38 Months

• Semi-detached : Tdev = 2.5(Effort)0.35 Months

• Embedded : Tdev = 2.5(Effort)0.32 Months

36 10/20/23
Example:
Assume that the size of an organic type software product has been estimated to be 32,000
lines of source code. Assume that the average salary of software engineers be Rs. 15,000/-
per month. Determine the effort required to develop the software product and the nominal
development time.

• From the basic COCOMO estimation formula for organic software:

• Effort = 2.4 х (32)1.05 = 91 PM

• Nominal development time = 2.5 х (91)0.38 = 14 months

•
• Cost required to develop the product = 14 х 15,000 = Rs. 210,000/-

37 10/20/23
Intermediate COCOMO model
• The basic COCOMO model assumes that effort and development time are
functions of the product size alone.

• Other project parameters besides the product size affect the effort required
to develop the product as well as the development time.

• The effect of all relevant parameters must be taken into account.

• Refines the initial estimate obtained using the basic COCOMO expressions
by using a set of 15 cost drivers (multipliers)

38 10/20/23
• The cost drivers can be classified as being attributes of the following items:
•
• Product: The characteristics of the product that are considered include the
inherent complexity of the product, reliability requirements of the product,
etc.
•
• Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required etc.
•
• Personnel: The attributes of development personnel that are considered
include the experience level of personnel, programming capability, analysis
capability, etc.
•

39 10/20/23
Complete COCOMO model
• Shortcoming of both the basic and intermediate COCOMO
models is that they consider a software product as a single
homogeneous entity.

• Most large systems are made up several smaller sub-systems.

• The cost of each subsystem is estimated separately.

• 1. Database part
• 2. Graphical User Interface (GUI) part
• 3. Communication part

40 10/20/23
single variable model

• When a model uses single basic variable to calculate all others

it is said to be a single variable model.
• IF several variables are used to describe software development
process .
• Selected equations combine these variables to give estimate of
cost & time.

41 10/20/23
Single Variable Model

• Eqn is used to calculate cost, time, effort.

• All depend on the size.
• C= aL b
• Two types of model

• Static
• A unique variable (say, size) is taken as a key element for calculating all
others(say cost time etc)
• Calculating (say, cost, time etc.)
• The form of equation used is the same for all calculations.

• Dynamic
• All variables are interdependent and there is no basic variable as in the static
model
42 10/20/23
Single variable model

• Use an equation to estimate the desired values such as cost,

time, effort etc
• Depend on the same variable used as predictor(say,size) C=aL
b
• C :cost L :size
• a&b : constants derived from the historical data of the
organization
• a & b depend on the local development environment, these
models are not transportable to different organizations

43 10/20/23
• • The software Engineering Laboratory of the university of Maryland has
established a model, the SEL model, for estimating its own software production

• E=1.4L 0.93
• Effort(person-month)

• DOC=30.4L 0.90

• Documentation(number of pages)

• D=4.6L 0.26

• Duration(month)
• L:number oflinesofcode(thousands of lines)used as predictor

44 10/20/23
Static Multi varible Model.
• Depend on several variables.
• Methods used, user participation…..
• Waltson & Felix at IBM.
• Relation between lines of code(L)
• & Effort (E) in person months.

• E= 5.2 L 0.91

45 10/20/23
• Duration of development in month.
• D= 4.1 L 0.36

• Productivity Index = I

46 10/20/23
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.

47
 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.
• Embedded Mode: The project is characterized by tight,
inflexible constraints and interface requirements. An embedded
mode project will require a great deal of innovation.

48
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
49
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

50
 Cost Estimation Process
Cost=SizeOfTheProject x Productivity

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

Function Point Errors

51
 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
52
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)
− External inquiries – interactive inputs requiring a response
− External files – machine-readable interfaces to other systems
− Internal files – logical master files in the system

53
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:

54
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:

55
 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

56
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

57
Example

58
Example (.)

59
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)

60
 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

61
 Relation between LOC and FP
• Relationship:

− LOC = Language
Factor * FP

− where
• LOC (Lines of Code)
• FP (Function Points)

62
 Relation between LOC and FP(.)
Assuming LOC’s per FP for:
Java = 53,
C++ = 64

aKLOC = FP * LOC_per_FP / 1000

It means for the SpellChekcer Example: (Java)

LOC=52.25*53=2769.25 LOC or 2.76 KLOC

63
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
64
Example

65
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.

Mode a b

Organic 3.2 1.05

Semi- 3.0 1.12
detached
Embedded 2.8 1.20

66
 • Effort Adjustment Factor
Effort computation(.)
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

67
 Effort Computation (..)
Total EAF = Product of the selected factors

Adjusted value of Effort: Adjusted Person

Months:
APM = (Total EAF) * PM
• PM – Person Months

68
Example

69
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

70
Distribution of Effort (.)
The following table gives the recommended percentage
distribution of Effort (APM) and TDEV for these
stages:

Percentage Distribution of Effort and Time Table:

Req Design, Implementation Testing

Analysis HLD + DD

Effort 23% 29% 22% 21% 100%

TDEV 39% 25% 15% 21% 100%

71
Advantages and Disadvantages
• Advantage
− COCOMO is transparent, one can see how it works
unlike other models.
− Drivers are particularly helpful to the estimator to
understand the impact of different factors that affect
project costs
• Disadvantages
− It is hard to accurately estimate KLOC early on in the
project, when most effort estimates are required
− Extremely vulnerable to mis-classification of the
development mode
− Success depends largely on tuning the model to the
needs of the organization, using historical data which is
not always available
72
 Staffing

• 4 factors in people management.

• 1. Consistency-
• people in project should be treated in a comparable way.
• Rewards should be same,
• Undervalued…

• 2. Respect-
• diff people diff skills.
• Respect it.
• All members should be given same chance.
• Fit in team..?

73 10/20/23
• 3. Inclusion –
• feel of listening..
• Good working environment for all.
• Junior, senior.

• 4. Honesty-
• technical knowledge..
• Will respect…

74 10/20/23
Selecting Staff- how to appoint to a project

• 1. Information provided by candidates about their background.

• Resume..

• 2. Info from interviews, communicator, social skills.

• But interviews are not capable to judge technical capabilities.

• 3.Recommendations from people who worked with…

• Only recommend those you know.

75 10/20/23
• Specific skills…
• Company location..
• Recent graduates will not have specific skills.

76 10/20/23
Motivating people- Mashlow

77 10/20/23
• People are motivated by satisfying your needs

• Hierarchy..

• Lower level- fundamental needs,

• Social needs- Social grouping.

• Esteem needs- need to feel respect by others.

78 10/20/23
• To satisfy social needs give time to people to meet co workers.
• Same place.. Easy
• But different place…

• Electronic medium does not satisfy social needs

• Face to face is necessary..

79 10/20/23
• To satisfy esteem needs you should show people you are
valued by the organization.
• Public recognition..
• Paid at level..@ skills, experience.

80 10/20/23
• Self realisation needs
• You need to give people responsibility for their work.
• Assign them demanding works & not impossible works.
• Tarining..

81 10/20/23
Classification of professionals- BASS/ DUNTEMAN
• 1. Task oriented people- are motivated by work they do.
• In SE its intellectual challenge.

• 2. Self oriented people- motivated by personal success,

recognition.

• 3. Interaction oriented people- presence & actions of

coworkers.

82 10/20/23
Managing Groups- factors infulencing.

• 1. Group Composition- skills, experience, personalities.

• 2. Group Cohesiveness- collection of individuals opinions.

• 3.Group Communications-

• 4. Group Organization- everyone feels organized

83 10/20/23
Software Configuration Management

• Configuration management: the art of coordinating software

development to minimize confusion
• Configuration management is the art of identifying, organizing,
and controlling modifications to the software being built
• The goal is to maximize productivity by minimizing mistakes
Introduction

• SCM is an umbrella activity that is applied throughout the

software process
• All information produced as part of the software process are
collectively called a software configuration
Introduction

• First Law of System Engineering states: No matter where you

are in the system life cycle, the system will change, and the
desire to change it will persist throughout the life cycle
Introduction

• Fundamental sources of change:

− New business or market conditions
− New customer needs
− Reorganization and/or business downsizing
− Budgetary or scheduling
Software Configuration Management Basics

• Identification – identifying software

configuration items in a baseline
• Control – controlling the release of a product and
changes to it throughout its lifecycle
• Status Accounting – recording and reporting of
the status of components and changes
• Auditing and Reviewing – Validating the
completeness of a product and that SCM
procedures are being followed
SCM Definitions

• Baseline – One or more software configuration

items that have been formally reviewed and
agreed upon and serve as a basis for further
development
• Software Configuration Item – A collection of
software elements treated as a unit for the
purposes of SCM
• Configuration – A collection of all the elements
of a baseline and a description of how they fit
together
SCM Definitions (cont’d)

• Configuration Control Board – Group with the

responsibility for reviewing and approving changes to
baselines
• Software – All of the code, specifications, plans,
descriptions, processes, and documents associated with a
software development effort
• Version – A specific instance of a baseline or configuration
item
Concepts

• Baseline, IEEE 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
Common Baselines

System engineering
System specification
Requirement analysis Software requirement specification
Design specification
Software design
Source code

Coding Test plans/Procedures/Data

Testing Operational system

Release
Software Configuration Item (SCI)

• Information created as part of SE process

• SCIs used as target in SCM:
− System specification
− Software project plan
− Software requirements specification
− Preliminary user manual
− Design specification
− Source code listing
Software Configuration Item (SCI)

− Test specification
− Operation and installation manuals
− Executable program
− Database description
− As-built user manual
− Maintenance documents
− Standards and procedures for SE
Need for CM

• CM needed to deliver product to the client

− What files should comprise the product?
− What versions of these files?
− How to combine these to make the product?

• Just for this, versioning is needed, and state of different items

has to be tracked

• There are other functions of CM also

Other Processes 95
SCI Modification Process

[Pressman, 1997]
Object identification in SW
configuration

• SCI can be named and organized using OO approach

• Two types of objects:
− basic object: ‘unit of text’ created during analysis, design, coding, or
testing.
− Aggregated objects: a collect of basic objects
Object identification in SW
configuration

• Features of objects:
− name: a character string
− description: a list of data items to identify the SCI type and a project
id, version information, etc.
− resources: entity that are provided, processed, referenced by the object
− Realization: a pointer to ‘unit of text’ for a basic object or null for an
aggregate object
Object identification in SW
configuration

• Relationships between objects

− part-of: a hierarchical relationship
− interrelated: a cross-structural relationship
• Object identification methods
− evolution graph
− automated SCM tools
− module interconnection language
Configuration Objects

[Pressman, 1997]
SCM Process
• Identification
• Version control
• Change control
• Configuration auditing
• Status reporting
Configuration Control

• Enforces a rigorous change control mechanism

• Requires formal procedures to

− request changes
− carry out impact analysis
− approve changes
− carry out changes
Evolution Graph

obj obj
1.3 1.4
obj obj obj
1.0 1.1 1.2
obj obj
2.0 2.1

obj obj
1.1.1 1.1.2

[Pressman, 1997]
Merging

• Two diverging versions may be merged to create a single new

version combining both set of change requests.

• Merge operations are typically done interactively with tool

assistance
Version Control

• Some of the issues

− When an executable is built, the versions of its constituents must be
consistent.
− If A depends upon B and B is recompiled, A may also need to be
recompiled.
− What if multiple people need to modify same SCI?
− Need to know what version different customers have
− How do you keep track of 100’s or 1000’s of modules?
Version Control

• Evolution graph to represent different versions

• Uses an object pool representing components, variants and
versions, and their relationship
• RCS (Revision Control System) is common tool.
− Use for documentation as well as code development

[Conradi, 1998]
Techniques for storing Versions
• Full files
• Forward Delta files
• Reverse Delta files
• The set of differences between two versions is called a delta.

[Conradi, 1998]
Version Control Support

• At the language level (in Ada):

With B;

Spec A Spec B
Body A Body B

• If only body of B changes, no change to A

• If spec of B changes, A must be recompiled
Change Control

Change request from user

Developer evaluates

Change report is generated

Change control authority makes decision

Request is queued, persons Change request is denied
are assigned
User is informed
“Check out” SCI(s)
Change Control

Make the change/review change

‘Check in’ changed SCIs

Establish a baseline for testing

Do SQA and ‘promote’ changes for inclusion in next release

Rebuild appropriate version

Audit the SCI changes/ include changes in new version

Release the new version

Access and Synchronization Control

[Pressman, 1997]
Configuration Audit

• Two approaches can be used to ensure proper

implementation of change:
− formal technical review (FTR)
− software configuration audit
• CA assesses a configuration object for characteristics that
are not generally not considered during review
• CA generally checks:

•Changes incorporated •SCM procedures followed

•FTR conducted •all related SCIs properly updated
•SE standards •change date and author
followed specified
Status Reporting
• Event occurred -- An SCI received updated ID
• people involved
• Time happened
• Effects on others
• Generated on a regular basis
• To improve communication among all parties
Organising for SCM

Roles:
• Configuration manager

• Change Control Board

includes representatives of
- user
- customer
- developer
SCM Planning

The SCM Plan is prepared in Project Initiation phase. It

documents
- what SCM activities are to be done
- how they are to be done
- who is responsible for doing specific
activities
- when they are to happen
- what resources are required
SCM Planning

• The outcome of the SCM planning phase is the Software

Configuration Management Plan (SCMP), which might be
extended or revised during the rest of the project.

• The SCMP can either follow a public standard like the IEEE
828, or an internal (e.g. company specific) standard.
SCM Tools

Common features of popular PC-based tools (PVCS,

MS Visual SourceSafe):
• Support for controlling all types of files (source
code as well as binary)
• Managing changes as deltas
• Supporting branching and merging
• Identifying and re-creating releases
• Providing a project view
SCM Tools

[Conradi, 1998]
Research Tools

[Volzer, 2002]
Research Tools

[Volzer, 2002]
 Outline of a Software Configuration
Management Plan (SCMP, IEEE
828-1990)
1. Introduction
− Describes purpose, scope of application, key terms and references
2. Management (Who?)
− Identifies the responsibilities and authorities for accomplishing the
planned configuration management activities
3. Activities (What?)
− Identifies the activities to be performed in applying to the project.
 Outline of a Software Configuration
Management Plan (SCMP, IEEE
828-1990)
4. Schedule (When?)
− Establishes the sequence and coordination of the SCM activities with
project mile stones.
5. Resources (How?)
− Identifies tools and techniques required for the implementation of the
SCMP
6. Maintenance
− Identifies activities and responsibilities on how the SCMP will be kept
current during the life-cycle of the project.