Dr. D. Y.

Patil School of MCA

MCA I, SEM I
A.Y. 2024-25

Subject:- Software Engineering and Project

Management.

By
Prof. Supriya Ghodekar.
Chapter No-3
Fundamentals Of Project Management
3.1 Overview Of Project Management
What is Project –
A project is a group of tasks that need to complete to reach a clear result. A
project also defines as a set of inputs and outputs which are required to achieve a
goal. Projects can vary from simple to difficult and can be operated by one
person or a hundred.

What is software project management?

Software project management is an art and discipline of planning and
supervising software projects. It is a sub-discipline of software project
management in which software projects planned, implemented, monitored and
controlled.
It is a procedure of managing, allocating and timing resources to develop
computer software that fulfills requirements
Software project management?
There are three needs for software project management. These are:

1.Time
2.Cost
3.Quality

It is an essential part of the software organization to deliver a quality

product, keeping the cost within the client?s budget and deliver the
project as per schedule. There are various factors, both external and
internal, which may impact this triple factor. Any of three-factor can
severely affect the other two.
3.2 Project Management Life Cycle IEEE
(Institute of Electrical and Electronics Engineers) life Cycle.
Phase-1:Project Initiation :
This is the phase of your project when you have to show that it has value and
is feasible.
This stage involves creating a business case to justify the need for the project,
as well as conducting a feasibility study to show that it can be completed
within a reasonable time and cost.
This is also an opportunity to create a task a contract, which is a document
that specifies exactly what the project will deliver.
1)Documentation –
2)Undertaking a feasibility study –
3)Recognizing extension –
4)Assemble of the team –
5)Recognizing expectations –
6)Recognizing project partners –
7)Building up a business case –
8)Building up an explanation of work –
Phase-2: Project planning :
After the venture(Proceed) has been approved, the second stage is project planning.
This stage's deliverable is the undertaking plan, which will serve as a guide for the
execution and control stages.
The task plan should include every aspect of the project's execution, such as
expenses, risks, assets, and timetables.

1)Make Task List –

2)Make a Budget –
3)Risk Management Plan –
4)Interchanges Plan –
5)Make a Project Schedule –
6)Appoint Tasks –
Phase-3: Project execution :
The third stage is project execution, which is where the majority of the work is
done.
This is the stage in which you complete the task exercises and achievements to
set expectations for the customer's or partner's fulfillment based on the
previous stage's arrangement.
To keep the group running, the project manager will allocate resources based
on the situation.
They will also attempt to identify and reduce risks, manage issues, and
integrate any changes.
1)Timetable Management –
2)Cost Management –
3)Quality Management –
4)Change Management –
5)Acquirement Management –
Phase-4: Task Monitoring and Control :
The fourth stage is project monitoring and control, which occurs concurrently with the
venture's execution period.
It entails monitoring the project's progress and execution to ensure that it is completed
on time and within budget.
To ensure quality assurance, quality control systems are used. The most significant issues
in a project are frequently identified with three things—time, cost, and degree, which are
commonly referred to as the triple constraint.
The primary goal of this stage is to implement strict controls on the company's
operations to ensure that the components are not straying from the planned course of
action.
Reporting –
Reporting in two ways has an impact on the project. Project directors can monitor
progress in two ways: first, it provides information to partners during introductions that
helps them stay on the right track. Reports on undertakings may differ in terms of task
advancement, cost, and variation.
Phase-5: Project Closure :
The customer or partner is notified of the ultimate expectations during
the fifth step, which is project completion. Once everything has been
verified, it is delivered, the paperwork is finished, and everything is
approved. The team and project manager can now take the lead in an
overview assessment of the project's activities and learn from it.
Depending on the project, transferring control to a different team—such
as the tasks supervisory team—may also occur at this point.In this
instance, it is the attempt supervisor's duty to make sure that the
transition goes well.
1)Move Deliverables –
2)Affirm Completion –
3)Audit Documentation –
4)Delivery Resources –
Activities
Software Project Management consists of many activities, that includes
planning of the project, deciding the scope of product, estimation of cost in
different terms, scheduling of tasks, etc.
The list of activities are as follows:
1. Project planning and Tracking
2. Project Resource Management
3. Scope Management
4. Estimation Management
5. Project Risk Management
6. Scheduling Management
7. Project Communication Management
8. Configuration Management
Now we will discuss all these activities -
1. Project Planning: It is a set of multiple processes, or we can say that it a task that
performed before the construction of the product starts.
2. Scope Management: It describes the scope of the project. Scope management is
important because it clearly defines what would do and what would not. Scope
Management create the project to contain restricted and quantitative tasks, which may
merely be documented and successively avoids price and time overrun.
3. Estimation management: This is not only about cost estimation because whenever
we start to develop software, but we also figure out their size(line of code), efforts, time
as well as cost.
Size of software
Quality
Hardware
Communication
Training
Additional Software and tools
Skilled manpower
4. Scheduling Management: Scheduling Management in software refers to all
the activities to complete in the specified order and within time slotted to each
activity. Project managers define multiple tasks and arrange them keeping
various factors in mind.
For scheduling, it is compulsory -
o Find out multiple tasks and correlate them.
o Divide time into units.
o Assign the respective number of work-units for every job.
o Calculate the total time from start to finish.
o Break down the project into modules.
5. Project Resource Management: In software Development, all the elements
are referred to as resources for the project. It can be a human resource,
productive tools, and libraries.
Resource management includes:
o Create a project team and assign responsibilities to every team member
o Developing a resource plan is derived from the project plan.
o Adjustment of resources.
6. Project Risk Management: Risk management consists of all the activities like
identification, analyzing and preparing the plan for predictable and unpredictable risk
in the project.
Several points show the risks in the project:
o The Experienced team leaves the project, and the new team joins it.
o Changes in requirement.
o Change in technologies and the environment.
o Market competition.
7.Project Communication Management: Communication is an essential factor in the
success of the project. It is a bridge between client, organization, team members and as
well as other stakeholders of the project such as hardware suppliers.
From the planning to closure, communication plays a vital role. In all the phases,
communication must be clear and understood.
Miscommunication can create a big blunder in the project.
8. Project Configuration Management: Configuration management is
about to control the changes in software like requirements, design, and
development of the product.

The Primary goal is to increase productivity with fewer errors.

3.3 Quality metrics

Quality metrics measure the value and performance of your business's products,
services, and processes.
Quality metrics can help assess customer satisfaction levels, identify areas for
improvement within your company, and track the overall quality of your
products or services
1. Code Quality – Code quality metrics measure the quality of code used for software
project development. Maintaining the software code quality by writing Bug-free and
semantically correct code is very important for good software project development. In
code quality, both Quantitative metrics like the number of lines, complexity, functions,
rate of bugs generation, etc, and Qualitative metrics like readability, code clarity,
efficiency, and maintainability, etc are measured.
2. Reliability – Reliability metrics express the reliability of software in different
conditions. The software is able to provide exact service at the right time or not checked.
Reliability can be checked using Mean Time Between Failure (MTBF) and Mean Time To
Repair (MTTR).
3. Performance – Performance metrics are used to measure the performance of the
software. Each software has been developed for some specific purposes. Performance
metrics measure the performance of the software by determining whether the software is
fulfilling the user requirements or not, by analyzing how much time and resource it is
utilizing for providing the service.
4. Usability – Usability metrics check whether the program is user-friendly or not. Each
software is used by the end-user. So it is important to measure that the end-user is happy
or not by using this software.
5. Correctness – Correctness is one of the important software quality metrics as this
checks whether the system or software is working correctly without any error by
satisfying the user. Correctness gives the degree of service each function provides as
per developed.
6. Maintainability – Each software product requires maintenance and up-gradation.
Maintenance is an expensive and time-consuming process. So if the software product
provides easy maintainability then we can say software quality is up to mark.
Maintainability metrics include the time required to adapt to new
features/functionality, Mean Time to Change (MTTC), performance in changing
environments, etc.
7. Integrity – Software integrity is important in terms of how much it is easy to
integrate with other required software which increases software functionality and
what is the control on integration from unauthorized software’s which increases the
chances of cyberattacks.
8. Security – Security metrics measure how secure the software is. In the age of cyber
terrorism, security is the most essential part of every software. Security assures that
there are no unauthorized changes, no fear of cyber attacks, etc when the software
product is in use by the end-user.
3.4 Risk Management Process
What is Risk?
"Tomorrow problems are today's risk." Hence, a clear definition of a "risk" is a problem
that could cause some loss or threaten the progress of the project, but which has not
happened yet.

These potential issues might harm cost, schedule or technical success of the project and
the quality of our software device, or project team morale.
“Risk Management is the system of identifying addressing and eliminating these
problems before they can damage the project.”
Risk Management
A software project can be concerned with a large variety of risks. In order to
be adept to systematically identify the significant risks which might affect a
software project, it is essential to classify risks into different classes. The
project manager can then check which risks from each class are relevant to
the project.

There are three main classifications of risks which can affect a software
project:
1.Project risks
2.Technical risks
3.Business risks
1.Project risks: Risks are threats affect the project schedule or resources. It is related
to loss of personnel or funds allocated to the project. An example of a project risk is the
loss of an experienced and talented staff. Finding an equivalent staff with appropriate
skills and experience may take a long time and, consequently, the software design will
take longer to complete.

2. Product risks: Risks that affect the quality or performance of the software. An
example of a product risk is the failure of a purchased component to perform as
expected. This may affect the overall performance of the system so that it is slower
than expected.

3. Business risks: Risks that threaten the viability of the software and affect the
organisation developing. For example, a competitor introducing a new product is a
business risk. The introduction of a competitive product will affect the sales of existing
software products..
Other risk categories

1.1. Known risks: Risks that become visible following a through evaluation
of the project schedule, the commercial and technological context in which
the plan is being created, and more reliable data sources (such as an
impossible delivery date)

2.2. Predictable risks: Risks that are assumed from previous project
experience (e.g., turnover in the past)

3.3. Unpredictable risks: Those risks that can and do occur, but are
extremely tough to identify in advance.
Principle of Risk Management

1.Global Perspective: In this, we review the bigger system description,

design, and implementation. We look at the chance and the impact the risk is
going to have.
2.Take a forward-looking view: Consider the threat which may appear in the
future and create future plans for directing the next events.
3.Open Communication: This is to allow the free flow of communications
between the client and the team members so that they have certainty about the
risks.
4.Integrated management: In this method risk management is made an
integral part of project management.
5.Continuous process: In this phase, the risks are tracked continuously
throughout the risk management paradigm.
Risk Management Process.
• Risk management is a series of steps whose objectives are to identify, address,
and eliminate software risk items before they become either threats to
successful software operation or a major source of expensive rework. (Boehm,
1989)
• Risk management is one of the most important jobs for a project manager. Risk
management involves expecting risks that might affect the project schedule or
the quality of the software being developed, and then taking action to avoid
these risks
• An outline of the process of risk management is illustrated as follows. It
involves several stages:
Risk Management Process.
1. Risk identification: You should identify possible project, product, and business risks.

2. Risk analysis: You should assess the likelihood and consequences of these risks.

3. Risk planning: You should make plans to address the risk, either by avoiding it or
minimizing its effects on the project.

4. Risk monitoring: You should regularly assess the risk and your plans for risk mitigation
and revise these when you learn more about the risk.

The risk management process is an iterative process that continues throughout the project.
Once you have drawn up an initial risk management plan, you monitor the situation to
detect emerging risks. As more information about the risks becomes available, you have to
reanalyze the risks and decide if the risk priority has changed. You may then have to change
your plans for risk avoidance and contingency management.
1)Identification of Risk :
Risk identification is the first stage of the risk management process.
Risk identification may be a team process where a team get together
to brainstorm possible risks.
Alternatively, the project manager may simply use his or her
experience to identify the most probable or critical risks.
• It is concerned with o Identifying the risks
• What Type of risk it is
• To which it is associated
• From where it is derived.
• Possible threats of risk
• There are several other tools and techniques also for identifying
risks Five common information gathering techniques for risk
identification include brainstorming, Delphi
technique,interviewing,root cause analysis, and SWOT analysis.
Sr. Risk Type Associated /Derived From Possible Threats database used in
No.
1. Technology Derive from the software or The the system cannot process as many
risks hardware technologies that are transactions per second as expected.
used to develop the system Reusable software components contain
defects that mean they cannot be reused
as planned.

2. People risks Associated with the people in the It is impossible to recruit staff with the
development team. skills required Key staff are ill and
unavailable at critical times. Required
training for staff is not available.

3. Organizational Derive from the organisational The organisation is restructured so that

risks environment where the software is different management are responsible
being developed. for the project. Organizational financial
problems force reductions in the project
budget.
4. Tools risks Derive from the software tools The code generated by software code
Risks and other support software used generation tools is inefficient.
to develop the system. Software tools cannot work together
in an integrated way.

5. Requirements Risks that derive from changes Changes to requirements that require
risks to the customer requirements major design rework are proposed.
and the process of managing the Customers fail to understand the
requirements change. impact of requirements changes.

6. Estimation Risks that derive from the The time required to develop the
risks management estimates of the software is under-estimated. The rate
resources required to build the of defect repair is underestimated.
system. The size of the software is
underestimated.
Risk Analysis
During the risk analysis process, you have to consider each identified risk and make a
judgment about the probability and seriousness of that risk. To do this you have to rely
on your own judgment and experience of previous projects and the problems that arose
in them. It is not possible to make precise, numeric assessment of the probability and
seriousness of each risk. Rather, you should assign the risk to one of a number of bands:
1. The probability of the risk might be assessed as:
• Very Low (<10%)
• Low (10-25%)
• Moderate (25-50%),
• High (50-75%),Or
• Very High(> 75%),
 Probability Effects
Sr. No. Type of Risk Risk Probability Effects

1. Technology risks The database used in the Moderate Serious

system cannot process as
many transactions per second
as expected

2. Technology risks Faults in reusable software Moderate Serious

components have to be
repaired before these
components are reused

3. People risks It is impossible to recruit staff High Catastrophic

with the skills required for the
project.
4. People risks Key staff are ill at critical Moderate Serious
times in the project.
5. People risks Required training for staff is Moderate Tolerable
not available.

6. Organizational risks The organisation is High Serious

restructured so that different
management are responsible
for the project.

7. Organizational risks Organizational financial Low Catastrophic

problems force reductions in
the project budget.

8. Tools risks Risks Code generated by code Moderate Insignificant

generation tools is inefficient.

9. Tools risks Risks Software tools cannot be High Tolerable

integrated.
10. Requirements risks Changes to requirements Moderate Serious
that require major design
rework are proposed.

11. Requirements risks Customers fail to Moderate Tolerabl

understand the impact of e
requirements changes.

12. Estimation risks The time required to High Serious

develop the software is
underestimated.

13. Estimation risks The rate of defect repair Moderate Tolerabl

is underestimated. e

14. Estimation risks The size of the software High Tolerabl

is underestimated. e
Risk planning:

The risk planning process considers each of the key risks that have been
identified, and develops strategies to manage these risks. For each of the
risks, you have to think about the actions which will minimize the
interference to the project if the problem identified in the risk occurs. You
should have strategies in place to cope with the risk if it arises. Strategy
should be so effective that reduce the overall impact of a risk on the project
or product.
Sr. Risk Strategy document for senior
No.
1. Organizational financial a briefing is management Prepare showing how the project
problems making of a important contribution to the goals to the the
business very and presenting reasons why cuts project
budget would not be cost-effective.

2. Recruitment problems Alert customer to potential difficulties and the possibility of

delays; investigate buying-in components.

3. Staff illness Reorganize team so that there is more overlap of work and
people therefore understand each other's jobs

4. Defective components Replace potentially defective components with bought-in

components of known reliability.

5. Requirements changes Derive traceability information to assess requirements

change impact; maximize information hiding in the design.
6. Organizational restructuring Prepare a briefing document for senior
management showing how the project is making
a very important contribution to the goals of the
business.

7. Database performance Investigate the possibility of buying a higher-

performance database.

8. Underestimated development time Investigate buying-in components; investigate

use of a program generator.
Risk Monitoring
•Risk monitoring control is the process of:
• Keeping track of the identified risks,
• Monitoring residual risks and identifying new risks,
• Ensuring the execution of risk plans, and
• Evaluating their effectiveness in reducing risk.

Risk monitoring and control is an ongoing process for the life of the project.
The risks change as the project matures, new risks develop, or anticipated risks
disappear.
Sr.no Risk Type Potential Indicators

1. Technology risks • Late Delivery of

hardware or support
software.
• Many reported
technology problems.
2. People risks • Poor staff morale.
• Poor relationships
amongst team members.
• High staff turnover.
3. Organizational risks • Organization gossip.
• Lack of action by senior
management.
4. Tools risks • Reluctance by team members to use tools;
complaints about
• CASE tools; demands for higher-powered
workstations.
5. Requirements risks • Any requirements change requests.
• Customer complaints.
6. Estimation risks • Failure to meet agreed schedule;
• Failure to clear reported defects.
Risk Mitigation :
Risk mitigation simply means to reduce adverse effects and
impact of risks that are harmful to project and Business
continuity.
It includes introducing measures and step taken into a project
plan to mitigate, reduce, eliminate, or control risk.Risk
mitigation means preventing risks to occur (risk avoidance).
Following are measures and steps to be taken for mitigating risks:

•Communicate with concerned staff to find probable risks.

•Identify and eliminate all those causes and issues that can create risk before the
beginning of project work.
•Develop policy in an organization that will help to continue the project even though
some staff leaves the organization.
•Everybody in the project team should be acquainted i.e. should be aware of and
familiar with current development activity.
•Maintain corresponding documents in a timely manner. This documentation should
be strictly followed as per standards set by the organization.
•Conduct timely reviews in order to speed up work.
•For conducting every critical activity during software development, provide
additional staff is required.
RMMM
A Risk management technique is usually seen in the software Project
plan.
This can be divided into Risk Mitigation, Monitoring, and
Management Plan (RMMM).
In this plan, all works are done as part of risk analysis. As part of the
overall project plan project manager generally uses this RMMM plan.
In some software teams, risk is documented with the help of a Risk
Information Sheet (RIS). This RIS is controlled by using a database
system for easier management of information i.e creation, priority
ordering, searching, and other analysis.
After documentation of RMMM and start of a project, risk mitigation
and monitoring steps will start.
1)Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
Finding out the risk.
Removing causes that are the reason for risk creation.
Controlling the corresponding documents from time to time.
Conducting timely reviews to speed up the work.
Risk Mitigation:
To mitigate this risk, project management must develop a strategy for reducing
turnover. The possible steps to be taken are:
 Meet the current staff to determine causes for turnover (e.g., poor working
conditions, low pay, competitive job market).
 Mitigate those causes that are under our control before the project starts.
 Once the project commences, assume turnover will occur and develop
techniques to ensure continuity when people leave.
 Organize project teams so that information about each development activity is
widely dispersed.
 Define documentation standards and establish mechanisms to ensure that
documents are developed in a timely manner.
 Assign a backup staff member for every critical technologist.
2)Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.

To check if predicted risks occur or not.

To ensure proper application of risk aversion steps defined for risk.
To collect data for future risk analysis.
To allocate what problems are caused by which risks throughout the project.
Risk Monitoring:
As the project proceeds, risk monitoring activities commence. The
project manager monitors factors that may provide an indication of
whether the risk is becoming more or less likely. In the case of high
staff turnover, the following factors can be monitored:
 General attitude of team members based on project pressures.
 Interpersonal relationships among team members.
 Potential problems with compensation and benefits.
 The availability of jobs within the company and outside it.
Risk Management:
Risk management and contingency planning assumes that mitigation efforts
have failed and that the risk has become a reality. Continuing the example, the
project is well underway, and a number of people announce that they will be
leaving. If the mitigation strategy has been followed, backup is available,
information is documented, and knowledge has been dispersed across the team.
In addition, the project manager may temporarily refocus resources (and
readjust the project schedule) to those functions that are fully staffed, enabling
newcomers who must be added to the team to “get up to the speed“.
Drawbacks of RMMM:
 It incurs additional project costs.
 It takes additional time.
 For larger projects, implementing an RMMM may itself
turn out to be another tedious project.
 RMMM does not guarantee a risk-free project, infact,
risks may also come up after the project is delivered.
3)Risk Management and planning :
It assumes that the mitigation activity failed and the risk is a reality. This
task is done by Project manager when risk becomes reality and causes severe
problems. If the project manager effectively uses project mitigation to
remove risks successfully then it is easier to manage the risks. This shows
that the response that will be taken for each risk by a manager. The main
objective of the risk management plan is the risk register. This risk register
describes and focuses on the predicted threats to a software project.
3.5 Linear Software Project Cost Estimation

3.5.1 COCOMO-I (Problem Statement)

3.5.2 Function Point Analysis (Problem Statement)
3.5.3 The SEI Capability Maturity Model CMM
3.5.4 Software Configuration management
3.5.3 Software Engineering Institute
Capability Maturity Model (SEICMM)
• The Capability Maturity Model (CMM) is a procedure used to
develop and refine an organization's software development process.
• The model defines a five-level evolutionary stage of increasingly
organized and consistently more mature processes.
• CMM was developed and is promoted by the Software Engineering
Institute (SEI), a research and development center promote by the
U.S. Department of Defense (DOD).
• Capability Maturity Model is used as a benchmark to measure the
maturity of an organization's software process.
Methods of SEICMM
1)Capability Evaluation: Capability evaluation provides a way to assess
the software process capability of an organization. The results of capability
evaluation indicate the likely contractor performance if the contractor is
awarded a work. Therefore, the results of the software process capability
assessment can be used to select a contractor.

2)Software Process Assessment: Software process assessment is used by

an organization to improve its process capability. Thus, this type of
evaluation is for purely internal use.
Level 1: Initial
Ad hoc Activities characterize a software development organization at this
level. Very few or no processes are described and followed. Since software
production processes are not limited, different engineers follow their
process and as a result, development efforts become chaotic. Therefore, it
is also called a chaotic level.

Level 2: Repeatable
At this level, the fundamental project management practices like tracking
cost and schedule are established. Size and cost estimation methods, like
function point analysis, COCOMO, etc. are used.
Level 3: Defined
At this level, the methods for both management and development
activities are defined and documented. There is a common organization-
wide understanding of operations, roles, and responsibilities. The ways
through defined, the process and product qualities are not measured. ISO
9000 goals at achieving this level.

Level 4: Managed
At this level, the focus is on software metrics. Two kinds of metrics are
composed.
Product metrics measure the features of the product being developed,
such as its size, reliability, time complexity, understandability, etc.
Process metrics follow the effectiveness of the process being used, such as
average defect correction time, productivity, the average number of defects
found per hour inspection, the average number of failures detected during
testing per LOC, etc. The software process and product quality are measured,
and quantitative quality requirements for the product are met. Various tools
like Pareto charts, fishbone diagrams, etc. are used to measure the product
and process quality. The process metrics are used to analyze if a project
performed satisfactorily. Thus, the outcome of process measurements is used
to calculate project performance rather than improve the process.
Level 5: Optimizing
At this phase, process and product metrics are collected.
Process and product measurement data are evaluated for
continuous process improvement.
Key Process Areas (KPA) of a software organization
Except for SEI CMM level 1, each maturity level is featured by several Key Process Areas (KPAs
 3.5.4 Software Configuration Management

Definition-
“The elements that comprise all information produced as a part of the software process
are collectively called a software configuration”.
When we develop software, the product (software) undergoes many changes in their
maintenance phase; we need to handle these changes effectively.
Several individuals (programs) works together to achieve these common goals. This
individual produces several work product (SC Items) e.g., Intermediate version of
modules or test data used during debugging, parts of the final product.
As software development progresses, the number of Software Configuration elements
(SCI's) grow rapidly.
SCM Process
It uses the tools which keep that the necessary change has been
implemented adequately to the appropriate component.

The SCM process defines a number of tasks:

1.Identification of objects in the software configuration
2.Version Control
3.Change Control
4.Configuration Audit
5.Status Reporting
1. Planning and Identification

The first step in the process is planning and identification. In

this step, the goal is to plan for the development of the software
project and identify the items within the scope. This is
accomplished by having meetings and brainstorming sessions
with your team to figure out the basic criteria for the rest of the
project.

specific activities during this step include:

•Identifying items like test cases, specification requirements,
and code modules
•Identifying each computer software configuration item in the
process
•Group basic details of why, when, and what changes will be
made and who will be in charge of making them
•Create a list of necessary resources, like tools, files,
documents, etc.
2. Version Control and Baseline

The version control and baseline step ensures the continuous integrity
of the product by identifying an accepted version of the software. This
baseline is designated at a specific time in the SCM process and can
only be altered through a formal procedure.
•Identifying and classifying the components that are covered by the
project
•Developing a way to track the hierarchy of different versions of the
software
•Identifying the essential relationships between various components
•Establishing various baselines for the product, including
developmental, functional, and product baselines
•Developing a standardized label scheme for all products, revisions,
and files so that everyone is on the same page.
3. Change Control

Change control is the method used to ensure that any changes that are made are
consistent with the rest of the project. Having these controls in place helps with
quality assurance, and the approval and release of new baseline(s). Change control
is essential to the successful completion of the project.

•Controlling ad-hoc changes requested by the client

•Checking the merit of the change request by examining the overall impact they
will have on the project
•Making approved changes or explaining why change requests were denied.
4.Configuration Status Accounting

The next step is to ensure the project is developing according to

the plan by testing and verifying according to the predetermined
baselines. It involves looking at release notes and related
documents to ensure the software meets all functional
requirements.

•Recording and evaluating changes made from one baseline to

the next
•Monitoring the status and resolution of all change requests
•Maintaining documentation of each change made as a result of
change requests and to reach another baseline
•Checking previous versions for analysis and testing.
5. Audits and Reviews

The final step is a technical review of every stage in the software

development life cycle. Audits and reviews look at the process,
configurations, workflow, change requests, and everything that has
gone into developing each baseline throughout the project’s
development.
Activities in this step include:
•Making sure that the goals laid out in the planning and identification
step are met
•Ensuring that the software complies with identified configuration
control standards
•Making sure changes from baselines match the reports
•Validating that the project is consistent and complete according to
the goals of the project.
Need Of Configuration management:

o Several people work on software that is continually update.

o Help to build coordination among suppliers.

o Changes in requirement, budget, schedule need to accommodate.

o Software should run on multiple systems.

People involved in Configuration Management: