4.

Software Project
Management and
Estimation
Introduction to Software Project
Management
• Software Project Management (SPM) is a
proper way of planning and leading software
projects.
• It is a part of project management in which
software projects are planned, implemented,
monitored, and controlled.
• it is essential to manage software projects
efficiently for an organization to deliver
quality products, keep the cost within the
client’s budget constraint, and deliver the
project as per schedule.
THE MANAGEMENT SPECTRUM-4P’s
Effective software project management focuses on the
four P’s:
• people,
• product,
• process,
• project.
The People
The “people factor” is so important that the Software Engineering Institute
has developed a People Capability Maturity Model (People-CMM), in
recognition of the fact that “every organization needs to continually
improve its ability to attract, develop, motivate, organize, and retain the
workforce needed to accomplish its strategic business objectives”
• People CMM defines the following key practice areas for software people:
staffing, communication and coordination, work environment,
performance management, training, compensation, competency analysis
and development, career development, workgroup development,
team/culture development, and others.
• Organizations that achieve high levels of People-CMM maturity have a
higher likelihood of implementing effective software project management
practices.
• The Stakeholders, Team Leaders, The Software Team, Agile Teams,
Coordination and Communication Issues
The Product
• Before a project can be planned, product objectives and scope should be established, alternative
solutions should be considered, and technical and management constraints should be identified.
• Without this information, it is impossible to define reasonable (and accurate) estimates of the
cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable
project schedule that provides a meaningful indication of progress.
• As a software developer, you and other stakeholders must meet to define product objectives and
scope.
• Objectives identify the overall goals for the product (from the stakeholders’ points of view)
without considering how these goals will be achieved.
• Scope identifies the primary data, functions, and behaviors that characterize the product, and
more important, attempts to bound these characteristics in a quantitative manner.
• Once the product objectives and scope are understood, alternative solutions are considered.

• Software Scope, Problem Decomposition

The Process
• A software process provides the framework from which a
comprehensive plan for software development can be established.
• A small number of framework activities are applicable to all software
projects, regardless of their size or complexity. A number of different
task sets—tasks, milestones, work products, and quality assurance
points—enable the framework activities to be adapted to the
characteristics of the software project and the requirements of the
project team.
• Finally, umbrella activities—such as software quality assurance,
software configuration management, and measurement—cover the
process model. Umbrella activities are independent of any one
framework activity and occur throughout the process.
• Melding the Product and the Process, Process Decomposition
The Project
• We conduct planned and controlled software projects for
one primary reason—it is the only known way to manage
complexity.
• The success rate for present-day software projects may have
improved somewhat, our project failure rate remains much
higher than it should be.
• To avoid project failure, a software project manager and the
software engineers who build the product must avoid a set
of common warning signs, understand the critical success
factors that lead to good project management, and develop
a commonsense approach for planning, monitoring, and
controlling the project.
Five-part commonsense approach to software projects:
• Start on the right foot.-This is accomplished by working hard (very hard) to understand the
problem that is to be solved and then setting realistic objectives and expectations for everyone who
will be involved in the project.

• Maintain momentum.-the project manager must provide incentives to keep turnover of

personnel to an absolute minimum, the team should emphasize quality in every task it performs

• Track progress.-progress is tracked as work products (e.g., models, source code, sets of test
cases) are produced and approved (using technical reviews) as part of a quality assurance activity.
• Make smart decisions.-the decisions of the project manager and the software team should
be to “keep it simple.”
• Conduct a postmortem analysis.-Establish a consistent mechanism for extracting lessons
learned for each project. Evaluate the planned and actual schedules, collect and analyze software
project metrics, get feedback from team members and customers, and record findings in written
form.
Determinants for software quality and organizational effectiveness.
Software Measurement
• Measurements in the physical world can be categorized in two ways: direct
measures (e.g., the length of a bolt) and indirect measures (e.g., the
“quality” of bolts produced, measured by counting rejects).
• Direct measures of the software process include cost and effort applied.
Direct measures of the product include lines of code (LOC) produced,
execution speed, memory size, and defects reported over some set period
of time.
• Indirect measures of the product include functionality, quality, complexity,
efficiency, reliability, maintainability.
• The cost and effort required to build software, the number of lines of code
produced, and other direct measures are relatively easy to collect.
However, the quality and functionality of software or its efficiency or
maintainability are more difficult to assess and can be measured only
indirectly.
• The software metrics domain into process, project, and product metrics.
Size-Oriented Metrics (LOC)
• Size-oriented software metrics are derived by normalizing quality
and/or productivity measures by considering the size of the software
that has been produced. If a software organization maintains simple
records, a table of size-oriented measures.
• In order to develop metrics that can be assimilated with similar
metrics from other projects, you can choose lines of code (analysis,
design, code, and test),as a normalization value.
• A set of simple size-oriented metrics can be developed for each
project:
• Errors per KLOC (thousand lines of code)
• Defects per KLOC
• $ per KLOC
• Pages of documentation per KLOC
Size-Oriented Metrics
In addition, other interesting metrics can be computed:
• Errors per person-month
• KLOC per person-month
• $ per page of documentation
Size-oriented metrics are not universally accepted as the best
way to measure the software process.
Function-Oriented Metrics (FP)
• Function-oriented software metrics use a measure of the
functionality delivered by the application as a normalization value.
• The most widely used function-oriented metric is the function point
(FP).
• Computation of the function point is based on characteristics of the
software’s information domain and complexity.
• The function point, like the LOC measure, is controversial. Followers
claim that FP is programming language independent, making it ideal
for applications using conventional and nonprocedural languages, and
that it is based on data that are more likely to be known early in the
evolution of a project, making FP more attractive as an estimation
approach.
SOFTWARE PROJECTS ESTIMATION
• Software project management begins with a set of activities that are collectively
called project planning.
• Before the project can begin, the software team should estimate the work to be
done, the resources that will be required, and the time that will elapse from start
to finish.
• Once these activities are accomplished, the software team should establish a
project schedule that defines software engineering tasks and milestones,
identifies who is responsible for conducting each task, and specifies the intertask
dependencies that may have a strong bearing on progress.
• Whenever estimates are made, you look into the future and accept some degree
of uncertainty as a matter of course.
• Useful techniques for time and effort estimation do exist. Process and project
metrics can provide historical perspective and powerful input for the generation
of quantitative estimates. Past experience (of all people involved) can support
massively as estimates are developed and reviewed.
• Estimation of resources, cost, and schedule for a software engineering
effort requires experience, access to good historical information , and the
courage to commit to quantitative predictions when qualitative
information is all that exists.
• Estimation carries inherent risk, and this risk leads to uncertainty.
• Project complexity has a strong effect on the uncertainty inherent in
planning. Complexity, however, is a relative measure that is affected by
familiarity with past effort.
• Project size is another important factor that can affect the accuracy and
efficiency of estimates. As size increases, the interdependency among
various elements of the software grows rapidly.
• The degree of structural uncertainty also has an effect on estimation risk. In
this context, structure refers to the degree to which requirements have
been set.
• The availability of historical information has a strong influence on
estimation risk. Estimation risk is measured by the degree of uncertainty in
the quantitative estimates established for resources, cost, and schedule.
• Software cost and effort estimation will never be an exact science.
Too many variables—human, technical, environmental, political—
can affect the ultimate cost of software and effort applied to
develop it.
• To achieve reliable cost and effort estimates, a number of options
arise:
1. Delay estimation until late in the project.
2. Base estimates on similar projects that have already been
completed.
3. Use relatively simple decomposition techniques to generate
project cost and effort estimates.
4. Use one or more empirical models for software cost and effort
estimation.
EMPIRICAL ESTIMATION MODELS
• An estimation model for computer software uses empirically derived
formulas to predict effort as a function of LOC or FP.
• The empirical data that support most estimation models are derived
from a limited sample of projects. For this reason, no estimation
model is appropriate for all classes of software and in all development
environments. Therefore, you should use the results obtained from
such models carefully.
• An estimation model should be standardized to reflect local
conditions. The model should be tested by applying data collected
from completed projects, plugging the data into the model, and then
comparing actual to predicted results. If agreement is poor, the model
must be tuned and retested before it can be used.
The Structure of Estimation Models
• A typical estimation model is derived using regression
analysis on data collected from past software projects.
• The overall structure of such models takes the form

• where A, B, and C are empirically derived constants, E

is effort in person-months, and ev is the estimation
variable (either LOC or FP).
The COCOMO II Model
Software estimation models bearing the name COCOMO, for COnstructive
COst MOdel.
The original COCOMO model became one of the most widely used and
discussed software cost estimation models in the industry.
Like its predecessor, COCOMO II is actually a hierarchy of estimation models
that address the following areas:
• Application composition model. Used during the early stages of
software engineering, when prototyping of user interfaces,
consideration of software and system interaction, assessment of
performance, and evaluation of technology maturity are principal.
• Early design stage model. Used once requirements have been
stabilized and basic software architecture has been established.
• Post-architecture-stage model. Used during the construction of
the software.
• The COCOMO II models require sizing information. Three different sizing options are
available as part of the model hierarchy: object points, function points, and lines of source
code.
• The object point is an indirect software measure that is computed using counts of the
number of (1) screens (at the user interface), (2) reports, and (3) components likely to be
required to build the application.
• Each object instance (e.g., a screen or report) is classified into one of three complexity levels
(i.e., simple, medium, or difficult). In essence, complexity is a function of the number and
source of the client and server data tables that are required to generate the screen or report
and the number of views or sections presented as part of the screen or report.
• Once complexity is determined, the number of screens, reports, and components are
weighted.
• NOP= (object points)* [(100 - %reuse)/100]
where NOP is defined as new object points.
• To derive an estimate of effort based on the computed NOP value, a
“productivity rate” must be derived.
• the productivity rate

• for different levels of developer experience and development

environment maturity.
• Once the productivity rate has been determined, an estimate of
project effort is computed using Estimated effort .

• In more advanced COCOMO II models, a variety of scale factors, cost

drivers, and adjustment procedures are required.
The Software Equation
• The software equation is a dynamic multivariable model that assumes
a specific distribution of effort over the life of a software
development project.

Where,
• E - effort in person-months or person-years
• t - project duration in months or years
• B - “special skills factor”
• P - “productivity parameter” that reflects
The software equation has two independent parameters: (1) an
estimate of size (in LOC) and (2) an indication of project duration in
calendar months or years.
• To simplify the estimation process and use a more common
form for them estimation model, a set of equations derived
from the software equation. Minimum development time is
defined as