It8075 SPM Unit IV

Mrs.C.B.Selvalakshmi, AP/CSE and Mr. S.

Murali, AP/CSE
Final Year CSE IT8075 UNIT-IV Notes

UNIT IV - PROJECT MANAGEMENT AND CONTROL

Framework for Management and control – Collection of data – Visualizing progress – Cost
monitoring – Earned Value Analysis – Prioritizing Monitoring – Project tracking – Change
control – Software Configuration Management – Managing contracts – Contract
Management.
4.1 Framework of Management and Control
4.1.1 Creating Framework

 After the project starts its execution, the project must be carefully monitored to
ensure the project’s progress.
 Monitoring process focuses on comparing the actual output with the expected one
and reviews the schedule to fit on target.
 Regular monitoring of the project is needed to have more control over the project.
Always the expected outcomes are compared with the actual ones and analyzed
whether there is any slack in the planned process.
 Project control is a continuous process of monitoring the progress of the project plan
and it also includes re-planning of activities if necessary.
 The experience gained from the current project can be taken as an input over future
project establishment of activities.
 Generally, revising the planning strategy is due to:
Delay in completion of the project within the target
time Quality factors
Inadequate functionality in adopting newer
techniques Actual estimation is above the
estimated one.
 A typical project control cycle is depicted below:
1|Page www.nitropdf.com
Mrs.C.B.Selvalakshmi, AP/CSE and Mr. S. Murali, AP/CSE
4.1.2 Project Reporting Structures

 Project steering committee or the Project Board has the overall responsibility of the
project’s progress in achieving the target.
 Project manager has the day-to-day responsibility of governing the development of
the project. These managers assign individual responsibilities to different teams
under a team leader.
Project Reporting Structures

 The diagram represents a structure for a medium-sized project where team leaders
can directly report to the project managers.
 Every team consists of a group of team members assigned with specific tasks. These
members represent the respective team according to the work allocated.
 Team leaders organize and collect team related information and report to the project
manager.
 The project manager in-turn generates a project-level report of the progress of the
project and report to the steering committee
4.1.3 Categories of Reporting
 Reporting is broadly classified as formal and informal reporting. The basic types of
reports associated with formal and informal reporting includes regular and ad hoc
types.
 Formal regular types can be oral or written. The standard oral communication of
minutes are kept whereas written type gets the reporting issues in a separate written
format.
 Formal ad hoc are mostly received information of different levels towards the end of
the project and generate written reports.
 Informal, oral and ad hoc provides early warning to the system and must be backed
up by formal reporting procedures.
4.1.4 Progress Assessment

 Based on the information collected from various levels at regular intervals during the
development of the project measures the progress assessment.
 The information can however, measure the project’s objectives in determining
whether the project can produce deliverables or not.
 Every single activity will not yield a deliverable work product but a group of
activities can achieve the specified tangible product.
 Usually, the assessment process is carried out by the team members who are
associated with the project activities.
 Checkpoints can be used to check the initial activity plan which may govern specific
events in generating report or a deliverable.
 Team leaders will have to assess the project daily while the project leaders can do it
on a weekly basis. Higher level members generate less reporting than their
subordinates.
 Review points or control points can be set at different points in the project life
cycle to review the progress of the project.
4.2 Collection of data project termination
 Collecting information of the project progress at regular instances provides much

control over the project.
 However, gathering of partial completion of activities can be used to calculate the
remaining work needed to complete.
 Intermediate products that are achieved can specify a milestone in the
development of the project.
4.2.1 Partial Completion Reporting

 The staff time related to a specific project indicates the work that has to be
carried out by the particular staff.
 Every organization uses an accounting method to calculate the charges of their
employees. However, the information related to project schedule is not shown in
this report.
 Timesheets can be maintained on a weekly basis to measure the staff
involvement in the development process.
Weekly timesheets contain the breakdown activities and holds information about the
scheduled and estimated completion time of individuals and do not contain the
project completion dates.
4.2.2 Reporting Risk
 Risk reporting uses a traffic light method concept and consists of the
following steps:
1. Identify the first level elements for assessment
2. Break the first level elements into second
level elements
3. Assess the second level elements and mark
the color as
Green – on target
Amber – not on target but recoverable
Red – not on target and difficult to recover
 Review all the second level elements to reach the first level assessments
 Review both first and the second level assessments to produce an overall
assessment
 This method only focuses on non-achievement factors and do not mention about
any delay in the development process.
 Assessment forms can be used to evaluate the overall status of the project.
 Critical activities denoted by red color must be reconsidered during the revision
of project schedule.
4.3 Visualizing Progress
 Collected data cannot be represented as arrived. It has to be shown visually so

that everybody involved in the project work is pleased about its progress.
Presenting effectively plays a vital role in the future of the project
4.3.1 Categories of Visualizing Progress

 The techniques that are used in visualizing project progress are:
 Gantt chart
 Slip Chart
 Ball Chart
These are explained in detail in the following sections.
4.3.2 Gantt Chart Technique

 Gantt chart is the most simple and the oldest form of representing the progress of the
project.
 It consists of an activity bar that indicate the scheduled activity dates and the
duration along with the activity floats.
 The progress reports of the activity are normally represented as a shaded activity bar
Sample Gantt Chart

For example in the figure, the code and test module activity of X is ahead of
the completion process whereas the third activity Z is lacking behind in its
schedule
4.3.3 Slip Chart Technique
 A Slip chart provides an alternative view of Gantt chart by providing

a visual indication of those activities which are not on schedule.
 The chart indicates that, the more there is a bend in the line the greater
the variation in the project plan.
 If the slip line deviates more towards the non-achievement of project
objectives, then it has to be reconsidered.
 The same figure used to represent Gantt chart is modified to Slip chart and depicted below
 Additional slip lines can be included at regular intervals as they are build
p which provides the project manager a clear idea about the projects
progress.
4.3.4 Ball Chart Technique
 Ball charts are represented in the form of circles that indicate the start and the end
point completion of activities.
 Initially, the circles contain the original scheduled dates and when revisions are done,
the second dates are introduced inside the circle until the activity is started or
completed.
 Circles of bar chart will at most contain only two dates the original and the revised
one or the original and the actual dates.
 Ball charts are pictorially shown as below:
 An activity is denoted by a red circle (colored darker in the figure) when the start and
the end dates are later than the target dates whereas green circle (colored lighter in
the figure) denotes that the activity is ahead of its schedule.
 The color to the circles reminds the project team about the status of each activity.
 In general, all the three types of chart techniques do not show clearly the slippage in
the project completion date for the project life cycle. This is overcome by timeline charts.
4.3.5 Timeline Charts
 Timeline usually records and displays the target changes during the project life cycle.
 The chart represents the planned time along the horizontal axis and the actual time
along the vertical axis.
 A line down the horizontal axis represents the scheduled activity completion dates
and the slip in the line indicates a delay in the respective activities.
 This timeline chart is used to calculate the duration of execution of the project as a
part of post-implementation review.
4.4 Cost Monitoring

 An important component of project control is cost monitoring.
 Cost monitoring provides an indication of the effort that has been given to the project.
 Sometimes, more cost is incurred to complete the activities to keep the project on
schedule.
 A cumulative cost chart is depicted below:
Planned cost
Cumulative cost
10 | P a g e www.nitropdf.com
 The chart does a comparison between the actual and the planned expenditure.
 These charts become more useful for estimating future costs.
 When revision of estimated cost and completion date are done, the same can
also be expressed in the revised cumulative chart.
4.5 Earned Value Analysis
 An assigned value to each task or work package based on original cost forecasts
yields earned value for the project.
 The assigned value is the original budgeted cost value and termed as a planned value
(PV) or budgeted cost of work schedule (BCWS).
 Earned value(EV)denotes the total value credited to a project at any point. It is also
termed as budgeted cost of work performed (BCWP).
 Common methods used in assigning an earned value are:

 0/100 technique: Task value is assigned zero till completion and the
budgeted value is 100%.
 50/50 technique:Task value is assigned 50% and then increased to
100% once it completes.
 Milestone technique:Task is assigned a value based on the

achievement of milestones as part of original plan.
 Out of all these method, the 0/100 technique is used because the other techniques are
not suitable for longer duration cost estimation.
4.5.1 Baseline Budgets

 To setup an earned value analysis, the first step is to create a baseline budget. The
baseline budget shows the forecast growth of the project plan in earned value with
respect to time.
 Common ways of measuring earned value in software development process is
persons-hours or work-days.
 An 0/100 technique can be used to get the creditability of earned value.
 A typical baseline budget chart is given below and it depicts the scheduled
completion of all activities involved in the development of the project
200
150
100
50
0
5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100
Elapsed Days
Baseline Budget Chart
4.5.2 Monitoring Earned Value
 The next step in earned value analysis is to monitor the project progress.
 Monitoring process indicates the completion of tasks and includes the activity start
and milestone achievement of the project.
 The actual cost (AC)is calculated by the actual cost of each task and is also called as
actual cost of work performed (ACWP).
 Certain inferences can be obtained from the earned chart such as:
 Schedule variance (SV) : the difference between the earned value
and the planned value indicates the degree of the completed work with
the planned.
 Cost variance (CV):the difference between the earned value and the
actual cost of a completed work results in cost variance. A positive
CV value indicated that the project is under control and a negative CV
denotes that the actual cost incurred is much more than the planned
one.
o The diagram depicts the earned value analysis along with the schedule and cost
4.5.3 Performance Ratios

 Performance ratios defines two index values namely Cost Performance Index (CPI) and
o Schedule Performance Index (SPI).
 Cost performance index and Schedule performance index values are calculated by the
formulas,
 CPI = Earned value /
Actual Costs SPI =
Earned value / Planned
value
 When these indices refers to a greater value it means that the work is completed
better than planned and if the value is less, it means that the work is more costlier
than planned.
4.6 Project Tracking
4.6.1 Prioritizing Monitoring

The list of priorities defined in the level of monitoring are:
o Critical path activities: These denote those activities in the critical path that
are delayed in project completion date.
o Activities with no free float: These delayed activities will have a delay in
subsequent ones but still stick on target. These activities can have a serious
effect on the resource schedule because the subsequent activities have to wait
for its completion.
o Activities with less than a specified float: If there is a very little float in the
activity say less than one week, these activities must be monitored very
closely.
o High risk activities: These high risks are identified in the risk management
plan itself and these results in over spending.
o Activities using critical resources: Critical activities are very expensive and are
available only for a limited period and require high level of monitoring.
4.6.2 Getting back Project on Target

 Projects are subjected to delays and unexpected events.
 The project manager must ensure that the project scheduled end dates are unaffected
at any circumstances.
 To maintain the project within the completed time, duration of some activity of the
project can be delayed or shorten to fit into the time limit.
 The strategies involved in getting back the project to target
are; Critical path shortening
Reconsidering precedence requirements
Critical Path Shortening
 Delayed projects can often be brought back on track by shortening activity times on
the critical path.
 Critical path is determined by the overall duration of the project.
 By increasing the resources for the critical path activities results in completion of the
activity before time and the resources can be prolonged for a longer duration.
 At the same time, the resources used must be effectively allocated to all the activities
so that no resources are idle at any point of time.
 Swapping of critical and non- critical activities can also be used to shorten the time
limit and bring the project back to target.
 One disadvantage of shortening critical path is that, it produces many more paths
while shortening which can become critical.
 Reconsidering Precedence Requirements

 The project can be brought back to target by defining constraints to certain activities
that affect the other activities for its completion.
 A precedence constraint activity can be sub-divided into a component that can start
immediately.
 Altering these constraints would have a major impact on the quality factors, the risk
involved, which can cause a delay in carrying out the activities.
 4.7 Change Control
 Change control implies the authority to approve and rank the changes. It combines
the automated tool with human to provide a mechanism for control of change.
 Any changes or alteration done to a single document often implies changes to other
documents as well.
 Change request is evaluated to assess the technical aspect of configuration items and
the budget.
4.7.1 Role of Chang Control Manager
The responsibilities of change control manager or the configuration librarian are:

 Identification of configuration items that are subjected to change control.
 All project documentation and software products must be maintained in the central repository.
 A formal set of procedures have to be setup to have control over changes. Maintenance of library
items in the repository
4.7.2 Change control Procedures

Change control authority (CCA) makes the final decision on the status and the
priority of the change based on the change report.
Guidelines of a change control procedures includes:
Need for change is identified
Change requested by the development staff
Management considers the change request
Change control authority
Change needed, staff member is elected to handle Change control denies
Prepares report based on cost and other factors User is informed
Development staff reports user about change
User decides to accept the change or not
If user accepts, copies of master are chosen
User do not accept the change

Copies are modified, recompiled and tested
Management is informed
New version of the product is notified
Software released for user acceptance testing
If user is satisfied, master copies are replaced with change
New products are released after change
Change Control Procedure
4.7.3 System Scope Changes
 Any changes done leads to changes in the size of the system which gradually increases.
 The changes can be either from the management of from the user.
 For every change that is implemented, the scope of the developing project must be
very carefully monitored and controlled.
 The changes made should not make the system to be inconsistent by affecting the
estimating factors.
4.8 Software Configuration Management
Throughout development, software consists of a collection of items (such as

programs, data and documents) that can easily be changed. During software development,
the design, code, and even requirements are often changed, and the changes occur at any
time during the development. This easily changeable nature of software and the fact that
changes often take place require that changes be done in a controlled manner.
Software configuration management (SCM) is the discipline for systematically
controlling the changes that take place during development. Software configuration
management is a process independent of the development process largely because most
development models cannot accommodate change at any time during development. SCM
can be considered as having three major components:
 Software configuration identification
 Configuration control
 Status accounting and auditing
Configuration identification
The first requirement for any change management is to have clearly agreed-on basis
for change. That is, when a change is done, it should be clear to what changes has been
applied. This requires baselines to be established. A baseline change is the changing of the
established baseline, which is controlled by SCM.
After baseline changes the state of the software is defined by the most recent
baseline and the changes that were made. Some of the common baselines are functional or
requirements baseline, design baseline, and product or system baseline. Functional or
requirement baseline is generally the requirements document that specifies the functional
requirements for the software. Design baseline consists of the different components in the
software and their designs. Product or system baseline represents the developed system.
It should be clear that a baseline is established only after the product is relatively
stable. Though the goal of SCM is to control the establishment and changes to these
baselines, treating each baseline as a single unit for the purpose of change is undesirable, as
the change may be limited to a very small portion of the baseline.
Configuration control
Most of the decisions regarding the change are generally taken by the configuration
control board (CCB), which is a group of people responsible for configuration
management, headed by the configuration manager. For smaller projects, the CCB might
consist of just one person. A change is initiated by a change request.
The reason for change can be anything. However, the most common reasons are
requirement changes, changes due to bugs, platform changes, and enhancement changes.
The CR for change generally consists of three parts. The first part describes the change,
reason for change, the SCIs that are affected, the priority of the change, etc.
The second part, filled by the CM, describes the decision taken by the CCB on this
CR, the action the CM feels need to be done to implement this change and any other
comments the CM may have. The third part is filled by the implementer, which later
implements the change.
Status accounting and auditing

For status accounting, the main source of information is the CRs and FRs themselves.
Generally, a field in the CR/FR is added that specifies its current status. The status could be
active, complete, or not scheduled. Information about dates and efforts can also be added to
the CR, the information from the CRs/FRs can be used to prepare a summary, which can be
used by the project manager and the CCB to track all the changes.
4.9 Managing Contracts
4.9.1 Introduction
 The acquisition and supply process are depicted for pre-contract and post-contract as
follows:
 The success of a contract requires considerable amount of time management.
 An ISO 12207 standard defined for acquisition and supply of software defines five
major processes namely,
 Acquisition
 Supply
 Operation
 Maintenance
 Development
 The initiation activity starts with the acquirer describing the preparation for the invitation
to tender.
 System requirements are broader and are not related to software alone but depends on the
changes in the organizational environment.
 Software requirements specifically relate to the software components within the
delivered system and can be extracted from broader system requirements.
 Request for proposal of the project contains the system requirements, scope of the
system, instruction for the bidders, list of software products, subcontractors detail and
other technical constraints.
 The criteria for selecting the supplier will have to done very carefully by the acquirer
done by joint reviews, verification and validation.
 As the supplier delivers, the acquirer conducts the review tests and is satisfied accepts
the software and sign-off as completed.
 4.9.2 Supply Process

 The supplier process activities will need to undertake in response to the request of
supplier.
 Initiation: The process is started when a request for a proposal from an
acquirer and the supplier initiates the work.
 Response Preparation: The response is prepared with expert knowledge
drawn from various people.
 Contract: Every activity is handled well, then the acquirer accepts the
supplier and the details of the contract are negotiated and signed.
 Planning: A detailed plan is developed of how the work has to be carried out.
 Execution and Control: The detailed plan can be executed and the
development process is invoked. The supplier must monitor and have control
over the product quality in identifying, analyzing and providing resolutions.
 Review and Evaluation: The acquirer reviews the progress of product
information which are needed to be accessed.
 Delivery and Completion: Post-delivery process has to be defined in view of
the management plans.
 4.9.3 Types of Contract
 Services are the external resources that are required for setting up a new system.
 Based on the supply of a completed software package the contracts can be classified as
 Bespoke system: This kind of system is developed for an individual that
is created from scratch.
 Off-the-shelf: This package denotes what the user buys as it is and called
as shrink-wrapped software.
 Customized off-the-shelf: This system represents a basic core system
that is modified based on the requirements of the client.
 Based on how the payment is made to the supplier, the contracts can be
classified as,
 Fixed price contracts: Here, the price is fixed when the contract is
signed. There will be no changes in the contract terms and the payment
must be made towards the end of the work.
 Advantages of Fixed price contracts
 Customer expenditure is well-known.
 Motivation of the supplier towards delivering the product with cost-
effective.
 Disadvantages of Fixed price contracts
 Supplier absorbs the risk in original estimate and allows higher
prices to allow contingency which is added as a margin quoted in
the tender.
 Requirements once defined are difficult to modify which can cause
friction between supplier and customer.
 Initially, the supplier will quote low price but as requirements are
put forward, the supplier demands a higher price.
 Threat to the quality of the system can occur if the price is fixed.
 Time and Materials contracts: Here, the customer is charged with a
fixed rate per unit of effort. This also estimates the overall cost based on
the customer’s requirements and it is not based on the final payment.
 Advantages of Time and Materials contracts
o Changing requirements can be done very easily.
o The customer is not worried about the price pressure.
 Disadvantages of Time and Materials contracts
o Customer cannot include all the requirements needed by them.

o The supplier will not like to work in a system where the scope
defined is out of control.
 Fixed price per unit delivered contracts:This type of contract is based
on function point counting. Along with the size of the system which
includes LOC, a price per unit is also quoted. In this system, the scope
grows during the development process.
 Advantages of Fixed price per unit delivered contracts

 Unlike the time contract, the customer can understand the
changing requirements
 Pricing schedules can be compared.
 Supplier does not get affected by risk increasing functionality.
 Supplier has efficiency to deliver the cost-effective manner.
 Development contract includes both the analysis and design stages
of the project.
 Disadvantages of Fixed price per unit delivered contracts
 It is very difficult to measure the software size.
 The requirement changes sometimes affect the transactions that are
not included in the function point count.
 Based on the approach used in contractor selection the contracts can be classified as
 Open tendering process: The request for proposal must be considered
and evaluated with the original conditions. Every supplier can bid to
supply the goods and services. The evaluation process can be time-
consuming and also expensive in open tendering process.
 Restricted tendering process: Here, bids can be made only by suppliers
who have been invited by the customer. This is an better approach than
the open tendering but has some risk factors.
 Negotiated procedure: In particular instances, the restricted tendering
process fails because of the defects which lead to additional payment
towards the completion of the project.
4.9.4 Stages in Contract Placement
The main stages in contract placement are given below:

 Requirement analysis
 Evaluation plan
 Invitation to tender
 Evaluation of proposals
Requirement analysis
Preparation of an requirement document containing the following:

 Introduction,
 Description of the existing system
 Current environment of the system
 Customer’s future plans
 System requirements based on either mandatory or desirable
 Deadlines have to be defined
 Additional information requires from the potential suppliers
Evaluation plan
The evaluation plan contains:
Preparing a plan to evaluate the submitted proposals.
Checking for the mandatory requirements that have been defined to meet the objectives.
Evaluating the desirable requirements
Validating the quality of the software system
Cost incurred for the lifetime of the proposed system
Invitation to tender
 This is also termed as request for proposal and contains:
 System requirements
 Defining the scope of the system
 Instruction to the bidders
 List of the software products
 Control of the subcontractors resulting in MoA
 Technical constraints
Evaluation of proposals
This evaluation has to be done in a planned manner. The process of evaluation
includes: Scrutiny of the proposal documents
Questioning supplier
representatives Giving
demonstrations
Visiting the site of the development
process Conducting practical tests.
4.9.5 Typical Terms of Contract

The contents of a typical terms of contract are listed below:
Definitions: The exact meaning of who is a supplier and who is a customer.
Forms of agreement: Categorizing whether the contract is sale, a lease, or a
license.
Goods and services to be supplied: This contains the actual list of individual
pieces of equipment that has to be delivered with specific model numbers. The
services includes proper training, documentation, installation, conversion of
existing files, maintenance of agreements and insurance related issues.
Ownership of the software: There are two possible ownership that can exists;
one with the customer and the other with the supplier. Supplier provides a
license to the user to use but that does not mean the ownership changes. Any
assignment of copyright must be in writing.
Environment: The basic working environment facilities have to be provided
by the supplier and the customer such as electricity supply.
Customer commitments:Customers have to provide with the basic
accommodation facilities even though the work is carried out by external
contractors.
Acceptance procedures: Various tests are conducted and the system is
accepted after the procedure for signing off the testing process is completed.
Standards: Every product that is supplied must abide by the standards relating
to its development and its documentation
Project and quality management: The quality that is expected by the

management for the project can be influenced by conducting review meetings
and obtaining the progress information of the project.
Timetable: A schedule is drawn to describe the different tasks and activities
that has to be carried out during the development process.
Price and payment method:Payment must be made based on the price that has
been defined in the agreement ensuring that the goods and services are
satisfactory.
Miscellaneous legal requirements: A contract must be defined within the legal

jurisdiction stating the liabilities that are applied to sub contractors involved in
the process. Liquidated damages can cause financial losses where the customer
suffers if the supplier is not able to oblige.
4.10 Contract Management
 Contract management studies and monitors the conversation between the supplier and
the customer while the contracted work is being carried out.
 Customer can make changes to the future direction of the project and make decisions.
 The entire project will require representative of the supplier and the customer to interact
with each other at different points in the development process.
 Activities involved in contract management include: Identifying customer approval;
 Negotiating successfully; Project deliverables; Managing change; Decision making; Legal
obligations; Business laws.
Accepting the Contract

 Customer has to undergo acceptance testing towards the end of the process.
 Every contract would have defined a time limit for the acceptance testing and the result
has to be produced before the time expires.
 Certain software suppliers are concerned with pre-acceptance testing where the user tests
the system than the developer.
 The supplier will not like to retain their staff to a specific project after its completion.
 Customer finds that the modifications needed by them are handled only by the junior
level staffs that are not aware of the delivered product.
 All the payment to the supplier solely depends on the acceptance testing.
 Every bug that is raised must be fixed within the period of warranty.

It8075 SPM Unit IV

Uploaded by

Copyright:

Available Formats

It8075 SPM Unit IV

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

It8075 SPM Unit IV

Uploaded by

Copyright:

Available Formats

Mrs.C.B.Selvalakshmi, AP/CSE and Mr. S.

UNIT IV - PROJECT MANAGEMENT AND CONTROL

4.1 Framework of Management and Control

4.1.1 Creating Framework

4.1.2 Project Reporting Structures

Project Reporting Structures

4.1.3 Categories of Reporting

4.1.4 Progress Assessment

4.2 Collection of data project termination

 Collecting information of the project progress at regular instances provides much

4.2.1 Partial Completion Reporting

4.3 Visualizing Progress

 Collected data cannot be represented as arrived. It has to be shown visually so

4.3.1 Categories of Visualizing Progress

These are explained in detail in the following sections.

4.3.2 Gantt Chart Technique

Sample Gantt Chart

4.3.3 Slip Chart Technique

 A Slip chart provides an alternative view of Gantt chart by providing

4.3.4 Ball Chart Technique

4.4 Cost Monitoring

4.5 Earned Value Analysis

 Common methods used in assigning an earned value are:

 Milestone technique:Task is assigned a value based on the

4.5.1 Baseline Budgets

4.5.3 Performance Ratios

4.6 Project Tracking

4.6.1 Prioritizing Monitoring

4.6.2 Getting back Project on Target

 Reconsidering Precedence Requirements

 4.7 Change Control

The responsibilities of change control manager or the configuration librarian are:

4.7.2 Change control Procedures

Need for change is identified

Change requested by the development staff

Management considers the change request

Change control authority

Change needed, staff member is elected to handle Change control denies

Prepares report based on cost and other factors User is informed

Development staff reports user about change

User decides to accept the change or not

If user accepts, copies of master are chosen

User do not accept the change

New version of the product is notified

Software released for user acceptance testing

If user is satisfied, master copies are replaced with change

New products are released after change

Change Control Procedure

4.7.3 System Scope Changes

4.8 Software Configuration Management

Throughout development, software consists of a collection of items (such as

Status accounting and auditing

4.9 Managing Contracts

 4.9.2 Supply Process

 4.9.3 Types of Contract

o Customer cannot include all the requirements needed by them.

 Advantages of Fixed price per unit delivered contracts

4.9.4 Stages in Contract Placement

The main stages in contract placement are given below: