UNIT -5

Project Management
Software project management is a sub-discipline of project management that involves planning,
organizing, and overseeing the development of software applications or systems. It encompasses a
set of activities that are designed to ensure that software projects are completed on time, within
budget, and according to specified requirements. The primary goal of software project management
is to deliver high-quality software that meets or exceeds customer expectations.

Key components of software project management include:

1. Project Planning: This involves defining the project scope, objectives, timelines, and resource
requirements. Project managers work with stakeholders to gather requirements and create a
detailed project plan that outlines tasks, milestones, and dependencies.
2. Resource Management: Effective allocation and utilization of resources, including personnel,
time, and budget, are critical for project success. Resource management involves identifying
the skills and expertise needed for the project and assigning tasks accordingly.
3. Risk Management: Identifying and managing risks is crucial to avoiding potential issues that
could impact the project. This includes assessing potential risks, developing mitigation
strategies, and implementing contingency plans.
4. Communication Management: Ensuring clear and effective communication among team
members, stakeholders, and other relevant parties is essential. Project managers facilitate
communication to keep everyone informed about project progress, changes, and challenges.
5. Quality Management: Maintaining software quality is a key objective. This involves defining
and implementing quality standards, conducting reviews and testing, and ensuring that the
final product meets the specified requirements.
6. Change Management: As project requirements or circumstances change, it's important to
manage these changes effectively. This includes assessing the impact of changes, obtaining
approvals, and adjusting project plans as needed.
7. Monitoring and Control: Monitoring progress against the project plan and making necessary
adjustments is a continuous process in software project management. This involves tracking
key performance indicators, ensuring adherence to timelines, and making data-driven
decisions.
8. Documentation: Comprehensive documentation is crucial for understanding project
requirements, design decisions, and code. This includes technical documentation, user
manuals, and other relevant documentation.
9. Stakeholder Management: Identifying and engaging with stakeholders, such as customers,
end-users, and project sponsors, is vital. Understanding their expectations and keeping them
informed contributes to project success.
10. Closure and Evaluation: After the software is delivered, the project is formally closed. This
phase includes a post-implementation review to evaluate what went well, what could be
improved, and to document lessons learned for future projects.

Effective software project management helps ensure that software development projects are
completed successfully, meeting the needs of the stakeholders and delivering value to the
organization. It requires a combination of technical knowledge, leadership skills, and effective
communication.

2. Estimating software projects is a challenging task, and various methods can be used, including ines
of Code (LOC) and Function Points (FP). Both methods have their strengths and weaknesses, and the
choice between them often depends on the nature of the project and the available information.
Here's a brief overview of each method:
 1. Lines of Code (LOC):
● Definition: LOC is a measure of the number of lines in the source code. It is a widely
used metric for estimating software size and, consequently, project effort and
duration.
● Advantages:
● Simplicity: LOC is relatively easy to measure and understand.
● Widely used: Many industry standards and historical data are based on LOC.
● Disadvantages:
● Variability: The number of lines of code can vary significantly based on
programming language, coding style, and other factors.
● Quality differences: LOC doesn't account for differences in code complexity
or quality.
2. Function Points (FP):
● Definition: Function Points are a measure of the functionality provided by a software
application, independent of the technology used. They consider the inputs, outputs,
user interactions, and data storage.
● Advantages:
● Technology-independent: FP is not tied to a specific programming language
or technology, making it useful for comparing projects across different
platforms.
● Focus on functionality: FP considers the software's functionality rather than
its implementation details.
● Disadvantages:
● Complexity: Estimating function points can be more complex and may
require a thorough understanding of the system's requirements.
● Learning curve: FP may require training and experience to apply effectively.

Choosing between LOC and FP:

● Project Nature: For projects with a well-defined scope and clear requirements, LOC may be
sufficient. For more complex projects or those where the requirements are not well-defined,
FP might be more suitable.
● Historical Data: If your organization has historical data based on LOC or FP, it may be
beneficial to use the same metric for consistency and better accuracy.
● Expertise: Consider the expertise of the team. If your team has experience and expertise in
one method over the other, it might be more practical to stick with what they are familiar
with.

In practice, some organizations use a combination of methods or use different methods at different
stages of the project to improve accuracy. Whichever method you choose, it's crucial to regularly
review and update your estimates as the project progresses and more information becomes
available.
Certainly! Let's consider a simple example to illustrate Lines of Code (LOC). In this example, we'll

Now, let's break down the LOC in this example:

 1. Comments: Comments are not considered executable code, but they are part of the source
file. In this example, there are three lines of comments.
2. Blank lines: Blank lines are also part of the source file. In this example, there is one blank
line.
3. Executable code: These are the actual lines that perform actions. In this example, there are
several lines of executable code within the factorial function, the input capture, and the
result display.

Lines of Code : Disadvantages

– The value of LOC measurement varies with the programmer, programming language,
and the project complexity.

– Every programmer has different technical skills, programming styles, and logical
ability. Therefore, the LOC value may differ during estimation.

– Different programming languages have their different programming techniques. The

actual number of the source lines may vary in programs.

– LOC only considers the source code. But some projects are highly complex and they
need much effort at the design and analysis phases.

– LOC is not suitable for component or reuse- based programming technologies where
the components are considered as the unit of measurement.

– Also, it is very difficult to accurately estimate the project size from the requirement
specification or project nature.

– There is a lack of standard tools for counting the source lines.

– The quality of code is the main focus for quality software, which is poorly considered
during size measurement.
Function Point Analysis

– To overcome the limitations of the LOC-based measurement, Alan Albrecht proposed

another size estimation technique called the function point (FP) analysis.

– The size of the project is estimated on the basis of functions or services requested by
the customer in the requirement specification.

– It is a structured technique that decomposes systems down into smaller components

so that they can be better understood and analysed.

– It relies on the product features delivered to the customer.

– The actual number of function points can be verified at the end of each stage of a
project.

Function Point Analysis : Advantages

– FP measurement is programming language independent and programmer

independent.

– It does not have any constraint specific to the hardware, procedural or

non-procedural languages.

– It is very easy to predict the function points in the final product from the
requirement specification.

– More accurate estimates are possible in the early stages of software development.

– An important aspect of FP is the consideration of user’s view through requirement

specification or problem description along with developers view during requirement
decomposition for the FP analysis.

– FP-based estimations are based on the following five information domain values and
their complexities in a particular project.

– Number of inputs

– Number of outputs

– Number of inquiries

– Number of internal logical files

– Number of external interfaces

– The value of each of these five information domains is collected and a subjective
evaluation is performed to categorize them as simple, average, and complex.
Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of Lines of Code.
It is a procedural cost estimate model for software projects and is often used as a process of reliably
predicting the various parameters associated with making a project such as size, effort, cost, time,
and quality. It was proposed by Barry Boehm in 1981 and is based on the study of 63 projects, which
makes it one of the best-documented models.
The key parameters which define the quality of any software products, which are also an outcome of
the Cocomo are primarily Effort & Schedule:
● Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.
● Schedule: Simply means the amount of time required for the completion of the job,
which is, of course, proportional to the effort put in. It is measured in the units of time
such as weeks, and months.
● COCOMO 1 Model:
The Constructive Cost Model was first developed by Barry W. Boehm. The model is for
estimating effort, cost, and schedule for software projects. It is also called as Basic COCOMO.
This model is used to give an approximate estimate of the various parameters of the project.
Example of projects based on this model is business system, payroll management system and
inventory management systems.
● COCOMO 2 Model:
The COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and
is developed at the University of Southern California. This model calculates the development
time and effort taken as the total of the estimates of all the individual subsystems. In this
model, whole software is divided into different modules. Example of projects based on this
model is Spreadsheets and report generator.

● Difference between COCOMO 1 and COCOMO 2:

COCOMO I COCOMO II

COCOMO I is useful in the waterfall models COCOMO II is useful in non-sequential, rapid

of the software development cycle. development and reuse models of software.

It provides estimates of effort and It provides estimates that represent one standard
schedule. deviation around the most likely estimate.

This model is based upon the linear reuse This model is based upon the non linear reuse
formula. formula

This model is also based upon the

This model is also based upon reuse model which
assumption of reasonably stable
looks at effort needed to understand and estimate.
requirements.

Effort equation’s exponent is determined Effort equation’s exponent is determined by 5 scale

by 3 development modes. factors.
COCOMO I COCOMO II

Development begins with the

It follows a spiral type of development.
requirements assigned to the software.

Number of submodels in COCOMO I is 3 In COCOMO II, Number of submodel are 4 and 17

and 15 cost drivers are assigned cost drivers are assigned

Size of software stated in terms of Lines of Size of software stated in terms of Object points,
code function points and lines of code

Project Scheduling

A schedule in your project’s time table actually consists of sequenced activities and milestones that
are needed to be delivered under a given period of time.
Project schedule simply means a mechanism that is used to communicate and know about that tasks
are needed and has to be done or performed and which organizational resources will be given or
allocated to these tasks and in what time duration or time frame work is needed to be performed.
Effective project scheduling leads to success of project, reduced cost, and increased customer
satisfaction. Scheduling in project management means to list out activities, deliverables, and
milestones within a project that are delivered. It contains more notes than your average weekly
planner notes. The most common and important form of project schedule is Gantt chart.

Process :
The manager needs to estimate time and resources of project while scheduling project. All activities
in project must be arranged in a coherent sequence that means activities should be arranged in a
logical and well-organized manner for easy to understand. Initial estimates of project can be made
optimistically which means estimates can be made when all favorable things will happen and no
threats or problems take place.
The total work is separated or divided into various small activities or tasks during project schedule.
Then, Project manager will decide time required for each activity or task to get completed. Even
some activities are conducted and performed in parallel for efficient performance. The project
manager should be aware of fact that each stage of project is not problem-free.
Problems arise during Project Development Stage :
● People may leave or remain absent during particular stage of development.
● Hardware may get failed while performing.
● Software resource that is required may not be available at present, etc.
The project schedule is represented as set of chart in which work-breakdown structure and
dependencies within various activities are represented. To accomplish and complete project within a
given schedule, required resources must be available when they are needed. Therefore, resource
estimation should be done before starting development.
Resources required for Development of Project :
● Human effort
● Sufficient disk space on server
● Specialized hardware
● Software technology
● Travel allowance required by project staff, etc.
Advantages of Project Scheduling :
There are several advantages provided by project schedule in our project management:
● It simply ensures that everyone remains on same page as far as tasks get completed,
dependencies, and deadlines.
● It helps in identifying issues early and concerns such as lack or unavailability of
resources.
● It also helps to identify relationships and to monitor process.
● It provides effective budget management and risk mitigation.

Earned Value Analysis (EVA) is also called “Budget cost of work performed”. It is considered a
refinement of the cost-monitoring technique. This analysis was first carried out USA’s Department of
Defence (DOD). In this analysis, a “value” is assigned to each track or work package based on the
expenditure forecast. The value assigned is known as the “planned value (PV)”. The work that has
not yet begun is given a value known as the “earned value of zero”. The total value credited to a
project is called “earned value(EV)”, which is also represented as “money value”.
Methods For Earned Value Analysis
● 0/100 Technique: The technique where a task is assigned a value of zero until such time
that is completed when it is given a value of 100% of the budgeted value.
● 50/50 Technique: The technique in which a task is assigned a 50% value as soon as it is
started and then given a value.
● 75/25 Technique: The technique where a task is assigned 75% on starting and 25% on
completion.
● Milestone Technique: The technique where a task is given a value based on the
achievement of milestones that have been assigned values as part of the original budget
plan.
● Percentage Complete: In some cases, there may be a way of objectively measuring the
amount of work completed.
Stages in Earned Value Analysis
● Creating the baseline budget: This is the first stage in setting up EVA. This budget is
based on the project plan. It predicts the earned value through time. Normally, it is
measured in person hours or workdays, for example: in a software development project.
● Monitoring Earned Value: The second stage is monitoring the earned value as the
project progresses. This is achieved by monitoring the completion of each task. Actual
cost(AC) is the actual cost of each task and it can be analyzed and collected.
● Schedule Variance(SV): This is the third stage which is measured in cost as EV-PV which
is the deviation between planned work and completed work.
Example: Consider these values,
PV =40000
 EV=35000
SV=35000-40000 = -5000
Here the calculated SV value is negative and hence we conclude that the project is
behind the original schedule.
● Time variance(TV): The difference between the current time and the time when the
achievement of the earned value was planned to occur.
● Cost Variance(CV): This value is the difference between the actual cost and the earned
value. Using this value we can estimate the accuracy of the original cost scheduled for
the project. If the CV values are found to be negative, we conclude the project is over
cost.
Advantages of Earned Value Analysis (EVA)
● Project Performance Measurement: EVA provides a comprehensive method for
measuring and assessing the performance of a project. It helps project managers gain a
clear understanding of how well a project is progressing in terms of cost and schedule.
● Objective Performance Metrics: EVA relies on objective metrics, making it less
susceptible to subjective interpretations. This can lead to more accurate assessments of
project performance.
● Integration of Cost and Schedule: EVA combines cost and schedule performance,
allowing project managers to see the relationship between these two critical aspects of
project management. This integration can help in identifying issues early and making
informed decisions.
● Early Issue Identification: EVA can highlight problems in project execution early, enabling
project managers to take corrective actions promptly. This can prevent cost overruns and
schedule delays.
● Benchmarking: EVA allows for benchmarking project performance against planned
targets and historical data. It helps project managers assess whether their project is on
track compared to similar projects.
● Effective Communication: EVA provides a standardized way to communicate project
performance to stakeholders. Charts and reports generated from EVA data can make it
easier for stakeholders to understand the project’s status.
Disadvantages of Earned Value Analysis (EVA)
● Complexity: EVA involves complex calculations and terminology, which can be
challenging for project teams to understand, especially for smaller projects or teams with
limited expertise.
● Resource-Intensive: Implementing EVA requires tracking detailed data and maintaining
comprehensive records. This can be resource-intensive, and some organizations may lack
the necessary tools or resources for effective EVA implementation.
● Subjectivity in Earned Value Calculation: The “earned value” itself can be subject to
interpretation, especially in situations where there are gray areas regarding the
completion of work packages or milestones.
● Assumption of Linear Progression: EVA assumes linear progression, which means that it
may not work well for projects with irregular or non-linear progress patterns, such as
research and development projects.
● Time-Consuming: Calculating and updating EVA metrics can be time-consuming, which
may not be suitable for projects that require quick decision-making and frequent
changes.
● Focus on Metrics vs. Problem Solving: Overemphasis on EVA metrics can sometimes
lead to a focus on numbers rather than addressing the underlying issues causing
performance problems.
RMMM Plan :
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.
Risk Mitigation :
It is an activity used to avoid problems (Risk Avoidance).
Steps for mitigating the risks as follows.
1. Finding out the risk.
2. Removing causes that are the reason for risk creation.
3. Controlling the corresponding documents from time to time.
4. Conducting timely reviews to speed up the work.
Risk Monitoring :
It is an activity used for project tracking.
It has the following primary objectives as follows.
1. To check if predicted risks occur or not.
2. To ensure proper application of risk aversion steps defined for risk.
3. To collect data for future risk analysis.
4. To allocate what problems are caused by which risks throughout the project.
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.

Example:
Let us understand RMMM with the help of an example of high staff turnover.
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.
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.