CHAPTER 4
Software Project Estimation
1
4.1 The management spectrum-4 P’ s
• People
• Product
• Process
• Project
2
.
People
• Recognizing roles such as project manager, team members, sponsors,
stakeholders, analysts, and developers is vital for project success.
• People are the main resource in any project, and effective management
enhances success chances.
• Different roles bring unique expertise and responsibilities, contributing to overall
project success.
Product
• Product refers to the project deliverable. Clear scope definition and control are
essential for success.
• Products aren't limited to software; they can include tangible goods or intangible
outcomes like organizational changes.
3
.
Process
• Process involves the methodology and plan guiding project activities, ensuring clarity
and coordination.
• The right process enhances project execution success by meeting goals and
objectives.
• Early comprehensive planning minimizes ambiguity, aligning processes with project
objectives.
• umbrella activities—such as software quality assurance, software configuration
management, and measurement occur throughout the process.
Project
• Project managers guide tasks, support team members, and ensure adherence to
project scope.
• Effective management involves guiding and supporting team members throughout
the project.
• The aim is to accomplish project scope requirements, leading to successful
outcomes.
4
4.2 Metrics for Size Estimation
• Lines of Code (LoC)
• Function Point
5
4.2 Metrics for Size Estimation
Lines of Code (LoC)
• A line of code (LOC) is any line of text in a code that is not a comment
or blank line, and also header lines, in any case of the number of
statements or fragments of statements on the line.
• LOC consists of all lines containing the declaration of any variable,
and executable and non-executable statements.
• It is one of the earliest and simplest Metric for calculating the size of a
computer program
• It is using calculating and comparing product activity of programmers
LOC is do not count the comment lines or blank lines spaces in the
code
6
Lines of Code (LoC)
• Advantages of Lines of Code (LOC)
• Effort Estimation: LOC is occasionally used to estimate development efforts
and project deadlines at a high level. Although caution is necessary, project
planning can begin with this.
• Comparative Analysis: High-level productivity comparisons between several
projects or development teams can be made using LOC. It might provide an
approximate figure of the volume of code generated over a specific time
frame.
• Benchmarking Tool: When comparing various iterations of the same program,
LOC can be used as a benchmarking tool. It may bring information on how
modifications affect the codebase’s total size.
7
Lines of Code (LoC)
• Disadvantages of Lines of Code (LOC)
• Challenges in Agile Work Environments: Focusing on initial LOC estimates may
not adequately reflect the iterative and dynamic nature of development in
agile development, as requirements may change.
• Not Considering Into Account External Libraries: Code from other libraries or
frameworks, which can greatly enhance a project’s overall usefulness, is not
taken into account by LOC.
• Challenges with Maintenance: Higher LOC codebases are larger codebases
that typically demand more maintenance work.
8
4.2 Metrics for Size Estimation
Function Point
• Function Point (FP) is a unit of measurement used in software engineering to
quantify the amount of business functionality delivered by a software application.
• It allows for the measurement of the size and complexity of a project, aiding in
better project management, optimization, and performance analysis over time.
• Function points are particularly useful for accurately determining the complexity
of an application, comparing projects of different sizes, and providing a consistent
method for assessing project scope without relying on estimating lines of code.
9
4.2 Metrics for Size Estimation
Function Point
• Function Point (FP) is a unit of measurement used in software engineering to
quantify the amount of business functionality delivered by a software application.
• It allows for the measurement of the size and complexity of a project, aiding in
better project management, optimization, and performance analysis over time.
• Function points are particularly useful for accurately determining the complexity
of an application, comparing projects of different sizes, and providing a consistent
method for assessing project scope without relying on estimating lines of code.
10
.
These are the five functional units to calculate FP
11
.
12
.
• To calculate FP falling formula is used
FP=UFP X CAF
• where UFP is Un adjusted functional point
CAF is complexity adjustment factor (CAF ranges from 0.65 to 1.35)
13
.
• ∑(fi) is the sum of all 14 questions and show the complexity
adjustment value/ factor-CAF (where i ranges from 1 to 14). Usually, a
student is provided with the value of ∑(fi)
These 14 questions can be
answered/rated as follows:
14
Project cost Estimation Approaches:
• Heuristic
• Analytical
• Empirical
15
Heuristics
• Heuristic techniques assume that the relationships among the
• different project parameters can be modeled using suitable
• mathematical expressions.
• Once the basic (independent) parameters are known, the other
(dependent) parameters can be easily determined by substituting the
value of the basic parameters in the mathematical expression.
Different heuristic estimation models can be divided into the
following
16
e
ur
is
ti
cs
17
e
ur
is
ti
cs
18
Analytical
• Analytical estimation is commonly used to estimate the time, effort, and
resources required for completing a software development project. Here's how it
typically works in this context:
• Clearly define the scope of the software project, including its features,
functionalities, and requirements.
• Break down the project into smaller tasks or components. This could involve
identifying major milestones, user stories, or specific features that need to be
implemented.
• Assess the complexity of each task or component. This could be based on factors
such as the level of technical difficulty, dependencies on other components, and
potential risks involved.
• Make assumptions about the resources available, team productivity, and any
constraints that may impact the project timeline. For example, you might assume
a certain number of developers working at a certain pace, or consider potential
delays due to unforeseen issues.
19
Analytical
• Use estimation techniques such as function point analysis, expert
judgment, or parametric estimation models to arrive at estimates for each
task or component. These techniques may involve using mathematical
formulas, benchmarks, or past experience to calculate estimates.
• Aggregate the estimates for individual tasks to determine the overall time,
effort, and resources required for the entire project. This may involve
summing up individual estimates or applying additional factors to account
for overhead, coordination efforts, and other project management
considerations.
• Review the estimates with stakeholders and team members to validate
assumptions, identify any discrepancies, and make adjustments as
necessary. This iterative process helps ensure that the estimates are
realistic and aligned with project goals.
• Document the estimates along with the assumptions, methodologies, and
any risks or uncertainties involved. Communicate the estimates to
stakeholders, clients, and team members to set expectations and facilitate
planning and decision-making.
20
Empirical
• Empirical estimation in software engineering relies on empirical data
and real-world observations to make estimates.
• It involves using past project data, historical performance metrics,
and other empirical evidence to inform estimations for current or
future projects.
• This approach contrasts with theoretical or purely subjective
estimation methods.
21
.
• Two key techniques commonly used in empirical estimation are expert judgment
and the Delphi technique:
• Expert Judgment: This technique involves seeking input and insights from
experienced professionals or subject matter experts in the relevant domain.
• These experts provide their informed opinions based on their expertise and past
experiences.
• It help refine estimates by considering factors that may not be readily apparent
from data alone, such as project-specific nuances or industry trends.
• Delphi Technique: The Delphi technique is a structured communication method
used to gather and refine opinions from a panel of experts. It typically involves
multiple rounds of anonymous feedback, where experts provide estimates or
assessments independently.
• The facilitator then aggregates and summarizes the responses before
redistributing them to the panel for further review.
• This iterative process continues until a convergence or consensus is reached
among the experts, resulting in a refined estimate.
22
Empirical
• By incorporating expert judgment and the Delphi technique, empirical
estimation aims to improve the accuracy and reliability of estimates
by leveraging the collective knowledge and experience of individuals
with diverse perspectives.
• These methods help account for uncertainties, risks, and variables
that may not be fully captured by data alone, thus enhancing the
overall quality of project planning and decision-making in software
engineering.
23
COCOMO (Constructive Cost Model)
• COCOMO stands for constructive cost model
• It is a popular software cost estimation model
• Developed by Barry Beohm in 1981
• It estimates effort required for a software project,
• The time required for the project, number of people required for the
project and hands the overall project cost
24
• COCOMO divides projects into 3 types
• Organic
• Semi detached
• Embedded
• KLOC- LOC means Lines of code and the K denotes 1000 (K 1000)
So, 200K LOC means there are 200,000 lines in a code
25
• Organic project
• It is a small project(2-250 KLOC)
• project team is small in size
• Project team has some prior experience
• Here problem is well analyzed and understood, has been solved in the past
• Eg. Library management system, inventory management system
26
• Semi detached project
• It is a medium size project(50-300K)
• The complexity of the project is medium
• Project team has experienced as well as in experienced members
• The project has some known and some unknown modules
• Eg. Database management system
27
• Embedded project
• The project size is large(more than 300KLOC)
• This type of project has high complexity
• The project team sizes large
• The project team has some experience
• Eg. Banking software
28
Basic COCOMO model
• It calculate effort scheduled time and number of people required to
complete a project
The values for the values for a b c and d for Organic projects projects semi detached projects and
embedded projects is shown in the following table:
Where a, b ,c ,d values are fixed.
29
Terminologies & Formulas Used in COCOMO :
• Effort (E)=Total effort required for the project in Man-Months
• Development Time required (D)= total time required for the development of
the project in months
• KLOC = of the project code in kilo in lines of code
• Staff size OR number of people required
• a,b,c,d= constants given for three types of projects
• Effort (E) = a * (KLOC) ^ b
• Development Time (D) = c * (Effort) ^ d
• People Required (P) = Effort / Development Time
30
.
31
.
32
Que. 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
33
Intermediate COCOMO model
• This model has more accurate than basic COCOMO model
• It consists of effort adjustment factor various cost drivers that is
product hardware resource and project parameter of the project
34
.
35
.
•.
36
. •.
37
.
38
Que. For a given semidetached type project ,size of project is
300KLOC Calculate effort and schedule time required consider that
developer has high experience developer has high application
experience and very low experience in programming
Soln:
39
40
Now, apply the same procedure as in
COCOMO,ietake values from Table and substitute
in Formulas
The only difference in the formula of
Effort (E) of COCOMO and COCOMO 2
is that we have to multiply by EAF in
COCOMO 2
41
Detailed COCOMO model
• It is a mixture of basic COCOMO and intermediate COCOMO model
• The entire software is divided into different modules
• Then COCOMO is applied on each module to estimate the effort
• And then Add(sum) all the efforts
42
Phases of detailed COCOMO model
1. Planning requirements
2. System design
3. Detail design
4. Module code and test
5. Integration and test
6. Cause constructive model
43
Advantages of COCOMO model
• It provides a systematic way to estimate cost and afford of a
software project
• Easy to implement
• provides idea about historical projects
• Helps in identifying factors that have greatest impact on the cost
and effort of a software project
Disadvantages of COCOMO model
• Limits the accuracy of the software cost
• It ignores requirements customer skills and Hardware issues
• It mostly depends on time factors assume that size of software is a
main factor that determine the cost and effort of a software
project which may not always be the case
44
COCOMO II
• COCOMO 2 is the revised version of the original COCOMO (Constructive
Cost Model)
• developed by Barry Boehm.
• offers methodologies, quantitative analytic structures, and tools for more
accurate estimation.
• consists of four estimation models that cater to different stages of the
software development lifecycle. These models are Application
Composition, Early Design, Post-Architecture, and Reuse.
• COCOMO 2 uses 5 scale factors and 17 cost drivers to refine the effort
equation exponent and account for various project attributes.
• Unlike COCOMO 1, COCOMO 2 is based on a non-linear reuse formula,
making it more suitable for estimating projects with significant code reuse.
• It gives more accurate estimates.
45
• Formulas Used in COCOMO 2:
• Basic Effort Formula: Effort = A x Size^B x M,
• where A is a constant, Size is the size of the software, B is the effort equation exponent,
and M is a multiplier.
• Effort for Joining Reusable Components: E = (ALOC x AT/100)/ATPROD, where
ALOC is the amount of lines of code, AT is the percentage of reused code, and
ATPROD is the percentage of new code added.
• Post-Architecture Model Effort: Effort = A x Size^B x M, similar to the basic
effort formula but used after designing the system architecture for more
detailed estimates.
46
4.5 Risk Management:
• Risk identification
• Risk Assessment
• Risk Containment
• RMMM
47
Risk identification
Risk identification is a crucial process that involves identifying potential risks
that could impact the success of a project.
By recognizing these risks early on, teams can develop strategies to mitigate
or manage them effectively.
Some common methods used for risk identification in software engineering
include:
• Common Methods for Risk Identification:
• Brainstorming: Team members come together to identify potential risks based on their
experience and expertise.
• Checklists: Using predefined checklists to systematically identify risks based on past
projects or industry standards.
• Interviews: Conducting interviews with stakeholders, clients, and team members to
gather insights on potential risks.
48
Risk identification
• SWOT Analysis: Analyzing the project's strengths, weaknesses, opportunities, and
threats to identify risks.
• Assumptions Analysis: Examining project assumptions to uncover potential risks
associated with incorrect assumptions.
• By employing these methods, software development teams can proactively
identify risks, prioritize them based on their impact and likelihood, and develop
risk management plans to ensure project success.
49
Risk Assessment
• Risk assessment simply means to describe the overall process or method to identify risk and
problem factors that might cause harm.
• It is a systematic examination of a task or project that you perform to simply identify significant
risks, problems, and hazards, and then to find out control measures that you will take to reduce
risk.
• The best approach is to prepare a set of questions that can be answered by project managers to
assess overall project risks:
• Will the project get proper support from the customer manager?
• Are end-users committed to software that has been produced?
• Is there a clear understanding of the requirements?
• Is there an active involvement of customers in the requirement definition?
• Are the expectations set for the product are realistic?
• Is the project scope stable?
• Are there team members with the required skills?
• Are project requirements stable?
• Is the technology used for software known to developers?
• Is the size of the team sufficient to develop the required product?
• Do all customers know the importance of the product/requirements of the system to be
built?
50
• Risk Identification: The first step is to identify potential risks that could
impact the project. It includes considering internal and external factors such
as technical complexities, resource constraints, changing requirements.
Various techniques such as brainstorming, and interviews can be used to
identify risks.
• Risk Analysis: Once risks are identified, they are analyzed to assess their
likelihood and potential impact on project objectives. Risks are categorized
based on their severity and probability of occurrence. Qualitative analysis
techniques such as risk matrices or quantitative techniques such as
probabilistic analysis may be used to analyze risks.
• Risk Evaluation: Risks are then evaluated to determine their significance and
prioritize them for further action. Risks that pose the greatest threat to
project success or have the highest likelihood of occurrence are given priority
for mitigation efforts.
51
• Risk Response Planning: Based on the results of the risk assessment, risk
response plans are developed to address identified risks. This involves
determining appropriate strategies for mitigating, transferring, avoiding, or
accepting risks. Mitigation plans outline specific actions to be taken to
reduce the likelihood or impact of risks.
• Monitoring and Review: Throughout the project lifecycle, risks are
monitored and reviewed to track their status and effectiveness of mitigation
efforts. Regular risk reviews are conducted to identify new risks, reassess
existing risks, and update risk response plans as needed. This ensures that
risk management remains an ongoing process throughout the project.
52
Risk Containment
• Risk containment in software engineering refers to the proactive measures taken to mitigate
and manage risks throughout the software development lifecycle.
• strategies commonly employed for risk containment :
• Risk Identification: The first step in risk containment is identifying potential risks that could impact
the project. This involves analyzing various factors such as technical complexities, resource
constraints, changing requirements, and external dependencies.
• Risk Analysis: Once risks are identified, they are analyzed to assess their potential impact on
project objectives and timelines. Risks are categorized based on their likelihood and severity,
allowing prioritization of mitigation efforts.
• Risk Mitigation Planning: Mitigation plans are developed to address identified risks. These plans
outline specific actions to reduce the likelihood or impact of risks, such as implementing
preventive measures, allocating additional resources, or developing contingency plans.
• Continuous Monitoring: Risks are continuously monitored throughout the project lifecycle to
identify new risks and track the effectiveness of mitigation efforts. Regular risk reviews and status
updates are conducted to ensure timely identification and response to emerging risks.
53
• Contingency Planning: Contingency plans are prepared to address risks that cannot be fully
mitigated. These plans outline alternative courses of action to be implemented if a risk
materializes, helping minimize the impact on project objectives.
• Communication and Collaboration: Effective communication and collaboration among
project stakeholders are essential for risk containment. This includes sharing risk information,
soliciting feedback, and fostering a culture of transparency and accountability.
• Risk Management Tools: Various tools and techniques are available to support risk
containment efforts, such as risk registers, risk matrices, and probabilistic analysis tools.
These tools help streamline the risk management process and ensure comprehensive
coverage of potential risks.
• Documentation: All risk management activities, including risk identification, analysis,
mitigation plans, and monitoring, should be well-documented. This ensures that risks are
effectively communicated, tracked, and addressed throughout the project.
By implementing these risk containment strategies, software engineering
teams can proactively identify, assess, and mitigate risks, thereby
reducing the likelihood of project delays, cost overruns, and quality
issues.
54
RMMM strategy
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 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 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.
55
