SOFTWARE PROJECT

MANAGEMENT
SOFTWARE CONFIGURATION
MANAGEMENT

1
 Terminology
• A configuration is a manner of arrangement of
parts.
• A configuration item (CI) is a work product that is
treated as a single entity for the purposes of
identification and change control
• A composite of configuration items is defined as
an aggregate CI
Eg.: Serial port device driver is a CI
Linux OS is an aggregate CI
2
 Terminology
• A version identifies the state of a configuration item
or a configuration at a well defined point in time
• Variants are versions that are intended to coexist.
- A system has multiple variants when it is supported
on different OSs and different hardware
platforms(eg. Machintosh, windows or Linux variant)
- A system has also multiple variants when it is
delivered with different levels of functionalities(eg.,
novice, expert or standard version)

3
 Version Syntax
• Following is a possible syntax:
• <version>::=<CIName>.<Major>.<Minor>. <revision>
• <CIN>::=<CI>│<Configuration Aggregate>
• <Major>::=<Non-negative Integer>
• <Minor>::=< Non-negative Integer>
• <revision>::=< Non-negative Integer>
Example: RAD.1.0.0 – 1st version
RAD.1.0.1 – 1st revision
RAD.1.1.2 – 1st minor,2nd revision
RAD.2.0.0 – 2nd version
4
 Terminology
• A promotion is a version that has been made available to other
developers in the project
- It denotes a configuration item that has reached a relatively stable
state and that can be used or reviewed by other developers
• A release is a version that has been made available to the client or
the users
- It denotes that a configuration item has met the quality set by the
quality control team and can be used or reviewed by the users
• A repository is a library of releases
• A workspace is a library of promotions

5
 Terminology
• A software library provides facilities to store, label, and identify versions of the CIs
• Three types of libraries:
o Developer’s workspace or dynamic library
- used for everyday development by developers
- change is not restricted and controlled by the individual developers
o Master directory or controlled library
- tracks promotions
- change needs to be approved
o Software repository or static library
- tracks releases
- promotions need to meet certain control criteria before they become releases

6
 Terminology
• A baseline is a version of a CI that has been
formally reviewed and agreed on and which
can be changed only through a change request
• A change request is a formal report issued by
a user or developer requesting a modification
in a configuration item

7
 Sources of Change
• Development
- Need for improving the process, functions and
features for effectiveness and efficiency
• Maintenance
- Bugs detected while in use
• Growth
- Need for moving to a new platform
- Expanding the scope
- Expanding the system to other domain
8
 Software Configuration Management
• The baseline product undergoes continuous
changes
• A process is required to handle these changes in a
systematic and controlled manner
• Such a process is called Software Configuration
Management
• SCM is very important during all phases starting
with Requirements
• Continues to be important during Maintenance
9
 SCM Activities
• Three main activities:
o Identification of CIs
o Change management control
o Configuration audit and status reporting

10
 Identification of Configuration Items
• Anything suitable for configuration control
• baseline product which is the basis for
subsequent changes
Ex.: - Planning documents
- RAD, SDD
- code
- Test data, test cases
- tools such as compilers
11
 Change Management Control (CMC)
• Change Control: process of evaluating, approving or
disapproving and managing changes.
– Depending on the size of the project, there might be
change control board (CCB) or CM Team
– Structure: representatives from each stakeholder party
• Dev., QA, Marketing, Mgmt., Customer support

12
 CMC Process
• Accept change request from
user/developer/customer via change request form
that describes:
- The configuration item in question
- The proposed change
- The impact of the change (cost, time, quality)
• Analyze the request by
- Identifying parties affected by the change
- Requesting and collecting their assessments
13
 CMC Process
• Based on cost, quality, time and utility, and received
assessment, evaluate the change needed
• If NO, defer for reconsideration, or reject
• If YES do the following:
- Rename affected components
- Execute the change
- Incorporate in the baseline
- Update to new status
- Update baseline and product database
14
Configuration Audit & Status Reporting
• How can we ensure that the change has been properly
implemented and reported?
• The answer is threefold:
- Formal technical review
- Configuration audit
- Status reporting
• The technical review
- Focuses on the technical correctness of the modified CI
- Addresses for its consistency with other CIs

15
Configuration Audit & Status Reporting

• Configuration audit answers questions:

- Has the change been made as specified?
- Have additional modifications been
incorporated?
- Has a formal review been conducted?
- Are the CMC procedures followed?
- Have all related CIs been properly updated?

16
Configuration Audit & Status Reporting
• Status reporting/status accounting answers the
following questions:
- What happened
- Who did it?
- When did it happen?
• In general, SR gives the complete profile:
- CR Decision Effected Affected
• SR is place in an online database
• SR helps improve communication among all involved
17
 Configuration Management Tools
• Many in existence but describe 4 here:
o RCS(Revision Control System)
- a free tool to control a repository storing all versions of the CIs
- to optimize storage, RCS only stores the latest version and the differences
between each version
- Doesn’t support branch
- to obtain a specific version
- developers check out a version into their workspace by specifying
version number or date
- to change a CI developers need to lock the item to prevent others from
changing the item
- When the change is completed, the developer checks the modified item
back into the repository releasing lock

18
 Configuration Management Tools
• CVS(Concurrent Version System)
- a free tool, extends RCS with the concept of branch
- Instead of a sequence of differences, CVS stores a tree of differences for
each CI
- Provides tools for merging two branches detecting overlaps
- Its Change control policy:
- Instead of locking a CI, CVS considers each developer to be a separate
branch
- If a single developer modified a CI between two check-ins, CVS merges
the branch onto the main trunk
- If CVS detects a concurrent change, it first attempts to merge the two
changes and then, in case of overlap, notifies the last developer to check-
in

19
 Configuration Management Tools
• Perforce
- Commercial replacement for CVS
• ClearCase
- commercial, supports CM aggregates and configurations
- A CM aggregate is realized as a directory which is managed as a CI
- Allows the specification of configuration with rules, selecting
versions of each CI
- a version can be specified by referring to a specific version
number or to the latest version number
- Provides access control mechanisms to define the ownership of
each CI and configurations

20
 SCM Plan Template
1. Introduction
1.1 Purpose
1.2 Scope
2. Roles and Responsibilities
3. Activities
3.1 Configuration Items
3.2 Change Control
3.3 Configuration audit and status accounting
21
 SCMP Template
• Introduction describes the scope and audience of
the document
• Management section describes the organization of
the project which can be referenced in the SPMP
• Activities section describes in detail the Cis
identification, CMC process, CM audit and status
reporting
• Schedule section describes when the activities
take place

22
 Assessment of a Software Project
• The following criteria, but not limited to, can be used to
assess a real project:
1. Planning
1.1 Does the project have a detailed SPMP?
1.2 How was the plan developed and approved?
1.3 How detail is the WBS?
1.4 Are the budget and schedule estimates inline with the
WBS?
1.5 Are there support planning documents: RMP, SCMP,
and SQAP? How detail are they?
23
 Assessment of a Software Project
2. Supporting Documents
2.1 Are there the following supporting docs?
• RAD
• SDD
2.2 Are the documents detailed enough?

24
 Assessment of a Software Project
3. Personnel
3.1 Does the project have a capable PM?
3.2 Are there enough teams?
3.3 Do the teams have the technical as well as
business environment expertise?
4. Product
4.1 Is the product delivered on time and budget?
4.2 How is the satisfaction of the customers?
25