Software Project Management

Introduction

■ Software process and project metrics

⚪ are quantitative measures
⚪ enable software engineers to gain insight into efficacy of
the software process and projects
■ Basic quality & productivity data (called measures)
are
⚪ Collected (and normalized using size- or function-oriented
metrics),
⚪ analyzed,
⚪ compared against past averages,
⚪ and assessed to determine whether productivity & quality
improvements have occurred
■ Metrics also indicate problem areas in processes
and projects
 3Ps" - "People, Product, and Process"

● In software engineering, the "3Ps" - "People, Product, and

Process" - represent a holistic approach to project management,
focusing on the team members involved (people), the
software application being developed (product), and the
structured methods used to build it (process), all working
together to achieve a successful outcome.
●
 3Ps" - "People, Product, and Process"

1) People:
● This refers to the individuals on the development team, including
developers, testers, designers, project managers, and stakeholders,
highlighting the importance of having the right skills and expertise for the
project.
1) Product:
● This represents the actual software application being developed,
encompassing its features, functionality, user interface, and quality
standards.
1) Process:
● This encompasses the structured methodologies and workflows used to
build the software, including requirements gathering, design, development,
testing, deployment, and ongoing maintenance.
3Ps" - "People, Product, and Process"
What is Measurement?
■ It is the act of obtaining a measure
■ It is a mechanism of objective evaluation
⚪ enables managers and practitioners to improve
software process
⚪ assists in planning, tracking and controlling a software
project and assessing product quality
What is a Measure?
■ It provides a quantitative indication of the size of
some product or process attribute
OR
■ quantitative indication of the extent, amount,
dimension, capacity, or size of some attribute of
product or process
Metric?
■ A metric is quantitative measure of the degree
to which a system, component or process
possesses a given attribute (IEEE definition)
■ Metrics enable people to gain insight into the
effectiveness of the software process and the
projects
 Difference between Measure,
Metric, Indicator
■ Measure
⚪ It is a value that represents the size, quantity, or
dimension of a software product or process.
■ Metric
⚪ A comparison of two or more measures, e.g.,
temperature values over time, errors per KLOC
■ Indicator
⚪ Compares a metric against a baseline or
expected result and helps in making decisions
■ Reference:
http://www.stsc.hill.af.mil/crosstalk/1995/03/Measure.asp
Determinants for software quality and
organizational effectiveness
Process connects 3 important factors that influence software quality and
organizational performance

Product

Customer
Characteristics Business
conditions
Project

People Process
Development environment Technology
Process Metrics
& Software Process Improvement

■ To improve a process
⚪ Measure specific attributes of process
⚪ Develop meaningful metrics based on these attributes
⚪ These metrics provide indicators that lead to strategy for
improvement
■ Example
⚪ Metrics can be derived from the following process
outcomes/attributes
■ Errors uncovered before software release,
■ defects delivered to & reported by end-user,
■ work products delivered
■ Human efforts expended
■ Calendar time expended
■ Schedule conformance
Project Metrics
■ Used by project managers and software team to
adapt project workflow and technical activities
■ Objective is
⚪ To minimize the development schedule by making
adjustments that can avoid delays and mitigate
potential problems
⚪ To assess product quality on an ongoing basis and
when necessary, modify technical approach to
improve quality
⚪ Most important use of metrics is estimation of time,
effort.
Project Metrics
■ Example
⚪ Metrics collected from past projects help to establish
time and effort estimates for current software projects
⚪ Production rates (in terms of models created, review
hours, function points, delivered source lines)
⚪ Errors uncovered during each software engg. Task
■ Software projects are assessed against the
project metrics for improvement
 Software Measurement Categories
■ Direct Measures
⚪ Of software process are
■ Cost and effort
⚪ Of product are
■ Line of Code (LOC)
■ Execution Speed
■ Defects over specified period of time
■ Indirect Measures
⚪ Of product are
■ Functionality
■ Quality
■ Complexity
■ Efficiency
■ Reliability
■ Maintainability
■ .. Other Abilities
Size Oriented Metrics
■ Derived by normalizing quality and/or productivity
measures by considering the size of software that
has been produced.
■ LOC used as a normalizing factor for other
measures
■ Widely used in software industry but their validity
and applicability is debated
 Example Set of Size-oriented
metrics
■ Errors per KLOC (thousand lines of code)
■ Defects per KLOC
■ $ per LOC
■ Pages of Documentation per KLOC
■ Errors per person-month
■ LOC per person-month
■ $ per Page of documentation
Pros and cons
■ Though widely used but not universally accepted as best way to
measure a software process
■ Controversy lies in using LOC as a key measure
■ proponents claim
⚪ LOC easy to count
⚪ Many existing estimation models use LOC
⚪ Large literature & data based on LOC exists
■ But opponents argue that
⚪ LOC measures are prog. language dependent
⚪ When considering productivity, LOC criteria penalizes well designed short
programs
⚪ Can not accommodate non procedural languages
⚪ Planner must estimate LOC long before analysis and design
Function-oriented Metrics
■ These use a measure of the functionality delivered by
application as a normalization value.
■ Most widely used function-oriented metric is function
point (FP)
■ FP’s computation – based on characteristics of
software information domain and complexity.
 Reference URL:
http://ourworld.compuserve.com/homepages/softcomp/
fpfaq.htm
■ Function points are a measure of the size of
computer applications and the projects that build
them. The size is measured from a functional or
user, point of view.
■ It is independent of the computer language,
development methodology, technology or
capability of the project team used to develop the
application
Function Point
■ First proposed by Albrecht; can be used to measure
functionality delivered by a system
■ Like LOC, FP is also controversial
⚪ Proponents claim
■ It is prog. Language independent, hence ideal for conventional and
non-procedural languages
■ Based on data that can be known early phases of projects
⚪ Opponents claim
■ Computation is based on subjective rather than objective data
■ counts of information domain may be difficult to collect
■ FP is just a number and has no physical meaning
Computing function points (cont..)
■ Following empirical relationship is used to
compute Function Point (FP)

FP=total count x [0.65+ 0.01 x Σ(Fi)]

Fi (i=1 to 14 ) are VAF (Value adjustment factors)

or simply ‘adjustment values’ based on answers
to some questions (See list of Qs on PAGE 473 from book 6th
edition )
 Object-oriented Metrics
■ Used for object-oriented projects
■ Set of metrics for projects:
⚪ Number of scenario scripts
■ Scenario scripts are detailed sequence of steps about user and
application interaction
■ Scenario scripts are directly correlated to application size and no. of test
cases
⚪ Number of key classes
■ Key classes are independent components
■ They Indicate amount of development effort and potential reuse
⚪ Number of support classes
■ These indicate amount of development effort and potential reuse
⚪ Average number of support classes per key class
⚪ Number of sub systems (aggregation of classes)
■ If identified, it is easier to lay out the schedule
Use-case oriented Metrics
■ Use-cases describe user visible functions and features
■ They are defined early in software process and can be
used as normalization measure before significant activities
are initiated
■ They are independent of programming language
■ No. of use cases directly proportional to
⚪ size of application in LOC &
⚪ no. of test cases that will be designed
■ There is no standard size of a use case as they are
created at different levels of abstraction
⚪ For this reason, it is a suspect as a normalization measure
Web Engineering Project Metrics
■ Reading assignment
Software Quality Metrics
■ Measuring quality through
⚪ Correctness
■ It is degree to which software performs its required function
■ Common measure= defects per KLOC
■ For quality assessment defects are counted typically for 1 year
⚪ Maintainability
■ It is the ease with which a program can be
⚪ corrected if an error is found
⚪ Adapted if environment changes or
⚪ Enhanced if customer desires
■ Measured indirectly, e.g., Mean-time-to change (MTTC)
■ Maintainable programs -> lower MTTC
Software Quality Metrics
⚪ Integrity
■ System’s ability to withstand (accidental & intentional) attacks
■ Two more attributes that help determine integrity
⚪ threat = probability of attack within a given time (that causes
failure)
⚪ security = probability that an attack will be repelled
■ Integrity = Σ [1 – (threat * (1 – security))]
⚪ Usability
■ It quantifies ease of use and learning (time)
Defect Removal Efficiency
■ It is a measure of the filtering ability of the quality
assurance and control activities as they are applied
through out the process framework.

■ DRE = E / (E + D)
⚪ E = # of errors found before delivery
⚪ D = # of defects found after delivery

■ Ideal value of DRE is 1

■ Realistically D will be greater than 0
■ As E increases, DRE begins to approach 1
Redefining DRE
■ DRE can also be applied on each process
framework activity and hence find the team’s
ability to assess errors before they are passed to
next activity or software engineering task.
■ DRE = Ei / (Ei + Ei+1)
⚪ Ei = errors in activity i
⚪ Ei+1 = errors in activity i+1 that were not discovered in
activity i
Project Size Estimation

● In the fast-paced world of Software Engineering, accurately

estimating the size of a project is key to its success.
● Understanding how big a project will be helps predict the
resources, time, and cost needed, ensuring the project starts off
on the right foot.
● This is a critical step in software engineering that ensures
projects are feasible and managed efficiently from the start.
What is Project Size Estimation?
● Project size estimation is determining the scope and
resources required for the project.
● It involves assessing the various aspects of the
project to estimate the effort, time, cost, and
resources needed to complete the project.
● Accurate project size estimation is important for
effective and efficient project planning, management,
and execution.
Importance of Project Size Estimation
● Financial Planning: Project size estimation helps in planning the
financial aspects of the project, thus helping to avoid financial
shortfalls.
● Resource Planning: It ensures the necessary resources are
identified and allocated accordingly.
● Timeline Creation: It facilitates the development of realistic
timelines and milestones for the project.
● Identifying Risks: It helps to identify potential risks associated with
overall project execution.
● Detailed Planning: It helps to create a detailed plan for the project
execution, ensuring all the aspects of the project are considered.
● Planning Quality Assurance: It helps in planning quality assurance
activities and ensuring that the project outcomes meet the required
standards.
Who Estimates Projects Size?
● Project Manager: Project manager is responsible for
overseeing the estimation process.
● Subject Matter Experts (SMEs): SMEs provide detailed
knowledge related to the specific areas of the project.
● Business Analysts: Business Analysts help in
understanding and documenting the project requirements.
● Technical Leads: They estimate the technical aspects of
the project such as system design, development,
integration, and testing.
Who Estimates Projects Size?

● Developers: They will provide detailed estimates for the

tasks they will handle.
● Financial Analysts: They provide estimates related to the
financial aspects of the project including labor costs,
material costs, and other expenses.
● Risk Managers: They assess the potential risks that could
impact the projects’ size and effort.
● Clients: They provide input on project requirements,
constraints, and expectations.
Lines of Code (LOC)

1. KLOC: Thousand lines of code

2. NLOC: Non-comment lines of code
3. KDSI: Thousands of delivered source instruction
Lines of Code (LOC)
1. It’s tough to estimate LOC by analyzing the problem definition. Only
after the whole code has been developed can accurate LOC be
estimated. This statistic is of little utility to project managers because
project planning must be completed before development activity can
begin.
2. Two separate source files having a similar number of lines may not
require the same effort. A file with complicated logic would take longer
to create than one with simple logic. Proper estimation may not be
attainable based on LOC.
3. The length of time it takes to solve an issue is measured in LOC. This
statistic will differ greatly from one programmer to the next. A seasoned
programmer can write the same logic in fewer lines than a newbie
coder.
Advantages
● Universally accepted and is used in many models like
COCOMO.
● Estimation is closer to the developer’s perspective.
● Both people throughout the world utilize and accept it.
● At project completion, LOC is easily quantified.
● It has a specific connection to the result.
● Simple to use.
Disadvantages:
● Different programming languages contain a different
number of lines.
● No proper industry standard exists for this technique.
● It is difficult to estimate the size using this technique in the
early stages of the project.
● When platforms and languages are different, LOC cannot
be used to normalize.
Function Point Analysis
● In this method, the number and type of functions supported
by the software are utilized to find FPC(function point
count).
● The steps in function point analysis are:
1) Count the number of functions of each proposed type.
2) Compute the Unadjusted Function Points(UFP).
3) Find the Total Degree of Influence(TDI).
4) Compute Value Adjustment Factor(VAF).
5) Find the Function Point Count(FPC).
Count the number of functions of each
proposed type:
● Find the number of functions belonging to the following types:
1) External Inputs: Functions related to data entering the system.
2) External outputs: Functions related to data exiting the system.
3) External Inquiries: They lead to data retrieval from the system
but don’t change the system.
4) Internal Files: Logical files maintained within the system. Log
files are not included here.
5) External interface Files: These are logical files for other
applications which are used by our system.
Measurement Parameters Examples

Number of External Inputs (EI) Input screen and tables

Number of External Output (EO) Output screens and reports

Number of external inquiries (EQ) Prompts and interrupts

Number of internal files (ILF) Databases and directories

Number of external interfaces Shared databases and shared

(EIF) routines
COCOMO II Model

● 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.
 COCOMO II Model

● The key parameters that define the quality of any

software product, which are also an outcome of
COCOMO, are primarily effort and schedule:
1) Effort: Amount of labor that will be required to complete
a task. It is measured in person-months units.
2) Schedule: This 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.
Types of Projects in the COCOMO Model
Categorized into three types based on their complexity, size, and the
development environment.

1) Organic: Team size required is adequately small, the problem is well

understood and has been solved in the past and also the team members
have a nominal experience regarding the problem.
2) Semi-detached: A software project is said to be a Semi-detached type if
the vital characteristics such as team size, experience, and knowledge of
the various programming environments lie in between organic and
embedded. The projects classified as Semi-Detached are comparatively
less familiar and difficult to develop compared to the organic ones and
require more experience better guidance and creativity. Eg: Compilers or
different Embedded Systems can be considered Semi-Detached types.
Types of Projects in the COCOMO Model
3) Embedded: A software project requiring the highest level
of complexity, creativity, and experience requirement
falls under this category. Such software requires a larger
team size than the other two models and also the developers
need to be sufficiently experienced and creative to develop
such complex models.
 Aspects Organic Semidetached Embedded

300 and above

Project Size 2 to 50 KLOC 50-300 KLOC
KLOC

Complexity Low Medium High

Team Highly Some experienced as well Mixed experience,

Experience experienced as inexperienced staff includes experts

Environme Flexible, fewer Somewhat flexible, Highly rigorous,

nt constraints moderate constraints strict requirements

Effort E=
E = 3.0(400)1.12 E = 3.6(400)1.20
Equation 2.4(400)1.05

Simple payroll New system interfacing with Flight control

Example
system existing systems software

TEAM SIZE : less no of profeesionlas moderate, higher

1) Planning and requirements: This initial phase involves
defining the scope, objectives, and constraints of the project. It
includes developing a project plan that outlines the schedule,
resources, and milestones
2) System design: In this phase, the high-level architecture of
the software system is created. This includes defining the
system’s overall structure, including major components, their
interactions, and the data flow between them.
3) Detailed design: This phase involves creating detailed
specifications for each component of the system. It breaks
down the system design into detailed descriptions of each
module, including data structures, algorithms, and interfaces.
1) Module code and test: This involves writing the actual
source code for each module or component as defined in
the detailed design. It includes coding the functionalities,
implementing algorithms, and developing interfaces.
2) Integration and test: This phase involves combining
individual modules into a complete system and ensuring
that they work together as intended.
3) Cost Constructive model: The Constructive Cost Model
(COCOMO) is a widely used method for estimating the
cost and effort required for software development projects.
Importance of the COCOMO Model

● Cost Estimation: To help with resource planning and project

budgeting, COCOMO offers a methodical approach to software
development cost estimation.
● Resource Management: By taking team experience, project size,
and complexity into account, the model helps with efficient
resource allocation.
● Project Planning: COCOMO assists in developing practical project
plans that include attainable objectives, due dates, and
benchmarks.
● Risk management: Early in the development process, COCOMO
assists in identifying and mitigating potential hazards by including
risk elements.
Importance of the COCOMO Model

● Support for Decisions: During project planning, the model

provides a quantitative foundation for choices about scope,
priorities, and resource allocation.
● Benchmarking: To compare and assess various software
development projects to industry standards, COCOMO offers
a benchmark.
● Resource Optimization: The model helps to maximize the
use of resources, which raises productivity and lowers costs.
 cost estimation of the basic COCOMO model

E = a*(KLOC)b PM
Tdev = c*(E)d
Person required = Effort/ Time
Where,
E is effort applied in Person-Months
KLOC is the estimated size of the software product indicate
in Thousand lines of code

Tdev is the development time in months

a, b, c are constants determined by the category of software
project given in below table.
 The constant values a, b, c, and d

Software
a b c d
Projects
Organic 2.4 1.05 2.5 0.38

Semi-Detac
3.0 1.12 2.5 0.35
hed

Embedded 3.6 1.20 2.5 0.32

Basic project was estimated to be 400 KLOC (kilo lines of code). Calculate
effort and time for each of the three modes of development.
E = a*(KLOC)b PM
1. For organic mode,
Tdev = c*(E)d
1.05
● effort = 2.4 × (400) ≈ 2.4 × 449.92 ≈ 1295 person-month.

0.38
● dev. time = 2.5 × (1295) ≈ 38 months.

2. For semi-detach mode,

1.12
● effort = 3 × (400) ≈ 2462 person-month.

0.35
● dev. time = 2.5 × (2462) ≈ 38 months.

3. For Embedded mode,

1.20
● effort = 3.6 × (400) ≈ 4772 person-month.

0.32
● dev. time = 2.5 × (4772) ≈ 38 months.
Example2: A project size of 200 KLOC is to be developed. Software
development team has average experience on similar type of projects.
The project schedule is not very tight. Calculate the Effort, development
time, average staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate mode, keeping

in view the size, schedule and experience of development time.

Hence E=3.0(200)1.12=1133.12PM

D=2.5(1133.12)0.35=29.3PM

COCOMO Model

P = 176 LOC/PM
Example
Example
To solve this problem using the Basic COCOMO Model, we need to apply the following
equations:

1. Effort Estimation (E):

b
E=a×(KLOC)

where:

○ a=2.4 b=1.05
○ KLOC=20000/1000=20
1. Development Time Estimation (T):
d
T=c×(E)

where:

○ c=2.5c d=0.38

Step 1: Calculate Effort (E)

1.05
E=2.4×(20) =55.756
Step 2: Calculate Time (T)
0.38 0.38
T=2.5×(E) =2.5x(55.756) =11.52 Months