PROJECT
MANAGEMENT
AND CONTROL
UNIT IV
CONFIGURATION MANAGEMENT PROCESS
Configuration management is carried out through the following two
principal activities:
● Configuration Identification: This activity involves deciding which
parts of the system should be kept under configuration management.
● Configuration Control: This activity is used to ensure that changes
to a system occur smoothly.
CONFIGURATION IDENTIFICATION
Project managers normally classify the work products associated
with a software development process into three main categories, viz.,
controlled, pre-controlled, and uncontrolled.
Controlled work products are those that are put under configuration
control.
The team members must follow some formal procedures to change
these.
CONT..
Pre-controlled work products are not yet under configuration
control, but will eventually be under configuration control.
Uncontrolled work products will not be subject to configuration
control.
Controllable work products include both controlled and pre-controlled
work products.
CONT..
Typical controllable work products include the following:
● Requirements specification document
● Design documents
● Tools used to build the system such as compilers, linkers,
lexical analyzers, parsers, etc.
● Source code for each module
● Test cases
● Problem reports
CONFIGURATION CONTROL
Configuration control is part of a configuration management system
that most directly affects the day-to-day operations of developers.
Configuration control allows only authorized changes to the
controlled objects and prevents unauthorized changes.
The project manager can give permission to some members to be able
to change or access specific work products.
In order to change a controlled work product such as a code module, a
developer can get a private copy of the module through a reserve
operation.
CONT..
Configuration management tools allow only one team member to
reserve a module at any time.
Once a work product is reserved, it does not allow anyone else to
reserve this module until the reserved module is restored.
Thus, by preventing more than one developer to simultaneously
reserve a module, the problems associated with concurrent access
are taken care of.
MODIFICATIONS TO A WORK PRODUCT UNDER
CONFIGURATION CONTROL
When developers need to change a work product they first make a
reserve request.
A reserve request by a team member is honoured only if
appropriate authorization has been given by the project
manager to that member for the specific work product.
After the reserve command successfully executes, a private copy
of the work product is created in their local directory.
Then, they can carry out all necessary changes to the work
product on their private copy.
CONT..
Once they have satisfactorily completed all necessary changes,
the changes need to be restored in configuration management
repository.
However, restoring the changed work product to the system
configuration requires the permission of a change control
board (CCB).
CONT..
For every change that needs to be carried out, the CCB reviews the
changes made to the controlled work product and certifies certain
aspects about the change such as
● Change is well-motivated
● Developer has considered and documented the effects of the
change
● Changes interact well with the changes made by other developers
● Appropriate people (CCB) have validated the change and has
verified that the change is consistent with the need.
OPEN SOURCE CONFIGURATION MANAGEMENT TOOLS
SCCS and RCS are two popular configuration management tools
available on most UNIX systems.
SCCS or RCS can be used for controlling and managing different
versions of text files.
SCCS and RCS do not handle binary files.
SCCS and RCS provide an efficient way of storing versions that
minimize the amount of occupied disk space.
OPEN SOURCE CONFIGURATION MANAGEMENT TOOLS
Suppose, a module MOD is present in three versions MOD1.1, MOD1.2 and
MOD1.3, then SCCS and RCS stores the original module MOD1.1 together with
changes needed to transform MOD1.1 into MOD1.2, and MOD1.2 to MOD1.3.
The changes needed to transform each baseline file to the next version are stored
and are called deltas.
The main reason behind storing the deltas rather than storing the full revision
files is to save disk space.
The change control facilities provided by SCCS and RCS include the ability to
incorporate restrictions on the set of individuals who can create new versions, and
facilities for checking components in and out
MANAGING CONTRACTS
Types of Contract
The external resources required could be in the form of services, for
example staff on short-term contracts carrying out some project tasks.
On the other hand, a contract for a completed software package could be
placed. This could be:
● a bespoke system created specifically for one customer;
● an off-the-shelf package bought ‘as is’ – this is sometimes referred to
as shrink wrapped software;
● customized off-the-shelf (COTS) software – where a core system is
modified to meet the needs of the client.
CONT..
Another way of classifying contracts is by the way that the
payment to suppliers is calculated
● Fixed price contracts;
● Time and Materials contracts;
● Fixed price per delivered unit contracts
FIXED PRICE CONTRACTS
In this situation a price is fixed when the contract is signed.
The customer knows that, if there are no changes in the contract
terms, this is the price they pay on completion.
For this to be effective, the customer’s requirement has to be
fixed at the outset.
Once the development is under way the customer cannot change
their requirements without renegotiating the price of the contract.
CONT..
The advantages of this method are:
• Known customer expenditure As long as the requirements
are precise and not changed, the customer has a known cost.
• Supplier motivation The supplier has a motivation to work
in a cost-effective manner.
CONT..
The disadvantages include:
● Higher prices to allow for contingency The supplier absorbs the risk for
any errors in the estimates. To reduce the impact of this risk, the supplier will
add a margin to the price quoted.
● Difficulties in modifying requirements The need to change the
scope of the requirements may become apparent during development
● Upward pressure on the cost of changes When competing against
other potential suppliers, the supplier will try to quote as low a price as
possible.
● Threat to system quality The need to meet a fixed price could mean that the
quality of the software suffers.
TIME AND MATERIALS CONTRACTS
With this type of contract, the customer is charged at a fixed rate
per unit of effort, for example per staff-hour.
The supplier may provide an initial estimate of the cost based on
their current understanding of the customer’s requirements, but
this is not the basis for the final payment.
The supplier usually invoices the customer for work done at
regular intervals, say each month.
CONT..
The advantages of this approach are:
● Ease of changing requirements Where a project has a research orientation
and the direction of the project may change as options are explored, then this
may be an appropriate method of payment.
● Lack of price pressure The lack of price pressure may promote better
quality deliverables.
The disadvantages of this approach are:
● Customer liability The customer absorbs the risks associated with poorly
defined or changing requirements.
● Lack of incentives for supplier The supplier has no incentive to work in a
cost-effective manner or to control the scope of the deliverables.
FIXED PRICE PER UNIT DELIVERED CONTRACTS
This is often associated with function point (FP) counting.
The size of the system to be delivered is calculated or estimated
at the outset of the project.
The size could be estimated in lines of code, but FPs can be more
easily derived from requirements documents.
A price per unit is also quoted.
The final price is then the unit price multiplied by the number of
units.
CONT..
The advantages of this approach are:
● Customer understanding The customer can see how the price is calculated and
how it will vary with changed requirements.
● Comparability Pricing schedules can be compared.
● Emerging functionality The supplier does not bear the risk of increasing
functionality.
● Supplier efficiency The supplier still has an incentive to deliver the required
functionality in a cost effective manner
● Life-cycle range The requirements do not have to be definitively specified at the
outset. Thus the development contract can cover both the analysis and design stages
of the project.
CONT..
The disadvantages of this approach are:
● Difficulties with software size measurement Lines of code can easily be
inflated by adopting a verbose coding style.
● Changing requirements Some requested changes may affect existing code
drastically but not increase the overall FP count.
CONT..
Another way of categorizing contracts, at least initially, is according to the
approach that is used in contractor selection, namely
● open
● restricted
● negotiated.
CONTRACT MANAGEMENT
We have already noted that forms of communication between the supplier
and customer during the project could be specified in the contract.
It would probably suit all concerned if the contractor is left to get on with
the work.
However, at certain decision points (or milestones) the customer might
wish to examine work already done and make decisions about the future
direction of the project.
The project could require representatives of the supplier and customer to
interact at key points in the development cycle – for example, users may
need to provide information to assist interface design.
CONT..
One way of identifying the decision points is to divide a large project into
increments.
For each increment there could be an interface design phase, and the
customer might need to approve the designs before the increment is built.
There could also be decision points between increments.
For each decision point, the deliverables from the suppliers, the decisions to be made
by the customer and the
possible outcomes need to be defi ned. These decision points have added signifi cance
if they are the basis for
payment to the contractor. The customer also has responsibilities at these decision
points – for example, the
contractor should not be delayed unnecessarily awaiting customer approval of interim
deliverables.
There will be concerns about the quality of contracted work. The ISO 12207 standard
envisages the possibility
of there being agents, independent of both the supplier and customer, who will carry
out verifi cation,
validation and quality assurance. It also allows for joint reviews of project processes
and products to be
agreed when the contract is negotiated.
We saw earlier that changes to requirements will vary the contract terms. Oral evidence
is not normally
admissible to contradict, add to, or vary the terms of a written contract, so that agreed
changes need to be
documented. A change control procedure must record requests for changes, the
supplier’s agreement to them
and the cost for additional work.
The supplier might not meet a legal obligation. This might not be their fault, if, for
example, the customer
causes the delay by lateness in giving the necessary approvals for intermediate
products.
If no action is taken
when the default occurs, this might imply that the customer in fact condones the failure
and could lead to
the loss of legal rights. The customer should protect their legal rights by offi cially
notifying the supplier that
the failure has been recognized. It will be recalled that under English law any claim for
liquidated damages
should be based on actual losses, so the customer needs to keep an accurate record of
the actual losses
incurred as a result of the default.
ACCEPTANCE
When the work has been completed, the customer needs to arrange
acceptance testing. The contract may limit
how long acceptance testing can take, so the customer must be organized
to carry out this testing before the
time limit for requesting corrections expires.
We have already noted that some software suppliers are rather cursory with
their pre-acceptance testing. It
seems that they would rather the users spent their time on testing than
them. This imposition can be reduced
by asking to approve the supplier’s internal test plans.
THANK YOU
