S/W Project Estimation & COCOMO and Risk Management

UNIT – III

SOFTWARE PROJECT ESTIMATION

COCOMO AND RISK MANAGEMENT

Yazhini 1
 S/W Project Estimation & COCOMO and Risk Management

Software Project Estimation

• Expert judgment estimating is easy to do – provided you have an expert on the project.
• Size-oriented metrics are derived by normalizing quality and/or productivity measures by considering the size of the
software that has been produced.
• Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization
value.
Effort and Cost Estimation-Expert Judgment
Estimating Software Size
• An accurate estimate of software size is an essential element in the calculation of estimated project costs and
schedules. The fact that these estimates are required very early on in the project (often while a contract bid is being
prepared) makes size estimation a formidable task.
• Initial size estimates are typically based on the known system requirements. You must hunt for every known detail of
the proposed system, and use these details to develop and validate the software size estimates.
• In general, you present size estimates as lines of code (KLSOC or SLOC) or as function points. There are constants that
you can apply to convert function points to lines of code for specific languages, but not vice versa. If possible, choose
and adhere to one unit of measurement, since conversion simply introduces a new margin of error into the final
estimate.
Developer Opinion
Developer opinion is otherwise known as guessing. If you are an experienced developer, you can likely make good
estimates due to familiarity with the type of software being developed.
Previous Project Experience
Yazhini
• Looking at previous project experience serves as a more educated guess. By using the data stored in the 2metrics
 S/W Project Estimation & COCOMO and Risk Management

Estimating Software Cost

• The cost of medium and large software projects is determined by the cost of developing the software, plus the cost of
equipment and supplies. The latter is generally a constant for most projects.
• The cost of developing the software is simply the estimated effort, multiplied by presumably fixed labour costs. For this
reason, we will concentrate on estimating the development effort, and leave the task of converting the effort to dollars to
each company.
Estimating Effort
• There are two basic models for estimating software development effort (or cost): holistic and activity-based. The single
biggest cost driver in either model is the estimated project size.
• Estimates produced with activity-based models are more likely to be accurate, as they are based on the software
development rates common to each organization.
Holistic Models for Cost Estimating
Holistic models relate size, effort and (sometimes) schedule by applying equations to determine the overall cost, and then
applying a percent of the overall cost to each development activity. They do not consider the actual labour rates and costs of
each activity.
Popular holistic models include the following:
• SDM (Software Development Model – Putnam – 1978)
• SLIM (Software Lifecycle Management – Putnam – 1979)
• COCOMO (Constructive Cost Model – Boehm – 1981)
• COPMO (Cooperative Programming Model – Conte, Dunsmuir, Shen – 1986)
Expert Judgment Estimating
• Expert Judgment estimating is easy to do – provided you have an expert on the project. This technique looks to the create an
estimate based upon their understanding of the project requirements.
Yazhini Many, if not most, project estimates are created
3 in this
fashion.
 S/W Project Estimation & COCOMO and Risk Management

• The advantage of this is that it is quick and if the expert is knowledgeable, it is often the most accurate estimate for
uncertain activities. The disadvantages are that you may not have an expert available and even if you do, the expert
often can provide no solid rationale for their estimate beyond, “That’s what I think it will take to do this”.
Decomposition Techniques
• Size-oriented software metrics are derived by normalizing quality and/or productivity measures by considering the size
of the software that has been produced.
• The decomposition technique is most frequently used when estimating projects. Decomposition techniques use the
divide and conquer approach. Estimating size, effort, and cost is performed in a stepwise manner by breaking down a
project into the main functions or related software engineering activities.
• These techniques are broadly classified as recursive decomposition, data-decomposition, exploratory decomposition,
and speculative decomposition. The recursive- and data-decomposition techniques are relatively general purpose as
they can be used to decompose a wide variety of problems.
• The organization builds a simple record of size measure for the software projects. It is built on past experiences of
organizations. It is a direct measure of software. This metric measure is one of the simplest and earliest metrics that is
used for computer programs to measure size. Size Oriented Metrics are also used for measuring and comparing the
productivity of programmers. It is a direct measure of a Software. The size measurement is based on lines of code
computation. The lines of code are defined as one line of text in a source file. While counting lines of code, the
simplest standard is:
Don’t count blank lines
Don’t count comments
Size = Kilo Lines of Code
Quality = Number of faults / KLOC
Count everything else
(KLOC)
Effort = Person / month Cost = $ / KLOC
The size-oriented
Productivity = KLOC /measure
person- is not aDocumentation
universally accepted
= Pages ofmethod.
documentation / KLOC
month
A simple set of size measures that can be developed is given below:
Yazhini 4
 S/W Project Estimation & COCOMO and Risk Management

Function Point
• Function-oriented software metrics use a measure of the functionality delivered by the application as a normalization
value. Since ‘functionality’ cannot be measured directly, it must be derived indirectly using other direct measures.
• Function-oriented metrics were first proposed by Albrecht, who suggested a measure called the function point.
• Function points are derived using an empirical relationship based on countable (direct) measures of software’s information
domain and assessments of software complexity.
• FPs of an application is found out by counting the number and types of functions used in the applications. Various functions
used in an application can be put under five types, as shown in Table:
Types of FP Attributes

Measurements Parameters Examples

1.Number of External Inputs(EI) Input screen and tables

2. Number of External Output Output screens and reports

(EO)

3. Number of external inquiries Prompts and interrupts.

(EQ)

4. Number of internal files (ILF) Databases and directories

5. Number of external Shared databases and shared

interfaces (EIF) routines.
Here that weighing factor will be simple, average, or complex for a measurement parameter type.
The Function Point (FP) is thus calculated with the following formula.
FP = Count-total * [0.65 + 0.01 * ∑(f i)]
= Count-total * CAF
Yazhini 5
where Count-total is obtained from the above Table.
 S/W Project Estimation & COCOMO and Risk Management
CAF = [0.65 + 0.01 *∑(fi)]

and ∑(fi) is the sum of all 14 questionnaires 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)
Also note that ∑(fi) ranges from 0 to 70, i.e.,
0 <= ∑(fi) <=70
and CAF ranges from 0.65 to 1.35 because
When ∑(fi) = 0 then CAF = 0.65
When ∑(fi) = 70 then CAF = 0.65 + (0.01 * 70) = 0.65 + 0.7 = 1.35
Based on the FP measure of software many other metrics can be computed:
• Errors/FP
• $/FP.
• Defects/FP
• Pages of documentation/FP
• Errors/PM.
• Productivity = FP/PM (effort is measured in person-months).
• $/Page of Documentation.
LOCs of an application can be estimated from FPs. That is, they are interconvertible. This process is known as backfiring. For
example, 1 FP is equal to about 100 lines of COBOL code.
FP metrics is used mostly for measuring the size of Management Information System (MIS) software.
But the function points obtained above are unadjusted function points (UFPs). These (UFPs) of a subsystem are further
Yazhini
adjusted by considering some more General System Characteristics 6
(GSCs). It is a set of 14 GSCs that need to be considered.
The procedure for adjusting UFPs is as follows:
 S/W Project Estimation & COCOMO and Risk Management

• Degree of Influence (DI) for each of these 14 GSCs is assessed on a scale of 0 to 5. (b) If a particular GSC has no
influence, then its weight is taken as 0 and if it has a strong influence then its weight is 5.
• The score of all 14 GSCs is totaled to determine Total Degree of Influence (TDI).
• Then Value Adjustment Factor (VAF) is computed from TDI by using the formula: VAF = (TDI * 0.01) + 0.65
Remember that the value of VAF lies within 0.65 to 1.35 because
When TDI = 0, VAF = 0.65
When TDI = 70, VAF = 1.35
VAF is then multiplied with the UFP to get the final FP count: FP = VAF * UFP
Differentiate between FP and LOC

FP LOC
1. FP is specification based. 1. LOC is an analogy based.
2. FP is language 2. LOC is language
independent. dependent.
3. FP is user-oriented. 3. LOC is design-oriented.
4. It is extendible to LOC. 4. It is convertible to FP
(backfiring)

Yazhini 7
 S/W Project Estimation & COCOMO and Risk Management

Decomposition Techniques for Estimation

Yazhini 8
 S/W Project Estimation & COCOMO and Risk Management

Yazhini 9
 S/W Project Estimation & COCOMO and Risk Management

Extended Function Point

Extended Function Point Metrics
• The function point measure was originally designed to be applied to business information systems application. To accommodate these
applications, the data dimension was emphasized to the exclusion of the functional and behavioural (control) dimensions.
• For this reason, the function point measure was inadequate for many engineering and embedded systems (which emphasize function and
control)
• A function point extension called feature points is a superset of the function point measure that can be applied to systems and engineering
software applications.
Feature Point
• Feature point is a comprehensive measure that encompasses the function point measure and can be applied to systems and engineering
software applications.
• Feature points are specifically useful in applications that have a high algorithmic complexity such as real-time systems with time
constraints, embedded systems, etc.
• Feature points are calculated by counting the information domain values and are weighed by a single weight only.
• Feature point measurement includes an additional parameter, ALGORITHM, to consider the complexity of the algorithms used in the
application.
• A table is used to compute the feature point, which consists of different weight values for information domain values and ALGORITHM
parameters.
3D Function Points
The 3D function point metric uses three dimensions – data, functional, and control – to represent software complexity.
• The data dimension is evaluated similarly to the traditional FPs calculation, where inputs, outputs, inquiries, external interfaces, and files
are counted.
• The functional dimension includes a feature transformation, which captures the sequence of steps that transform input into output.
• The control dimension includes a feature transition, which is defined as the total number of transitions between states. Each state
represents an externally observable mode. Yazhini 10
• The 3D function point method was introduced by Boeing to address two limitations of the Albrecht approach.
 S/W Project Estimation & COCOMO and Risk Management

Object Point
• Object points are a way of estimating effort size, similar to Source Lines Of Code (SLOC) or Function Points.
• They are not necessarily related to objects in Object-oriented programming, the objects referred to include screens,
reports, and modules of the language. The number of raw objects and complexity of each are estimated and a weighted
total Object-Point count is then computed and used to base estimates of the effort needed.
• Object points are an approach used in software development effort estimation under some models such as COCOMO II.

Low Lowest High Highest

Following are the steps for calculating object point: PROD 4 7 25 50

Assess object count: number of screens, reports and 3GL components. Productivity
Classify object: simple, medium and difficult depending on the values of characteristic dimensions.
Weight the number in each cell using the following scheme. The weights reflect the relative effort required to implement
an instance of that complexity level as given in the table.
Determine object points: add all the weighted object instances to get one number, the object point count.
Estimate percentage of reuse you expect to be achieved in this project.
Compute new object points to be developed as,
NOP=(Object Point) * (100 - %reuse) / 100
Where %reuse is the percentage of screens, reports and 3GL modules reused from previous applications.
Determine a productivity rate depending on developers’ experience and ICASE maturity as given in the above table.

Yazhini 11
 S/W Project Estimation & COCOMO and Risk Management

COCOMO-81
COCOMO: The COCOMO (Constructive Cost Estimation Model) is proposed by DR. Berry Boehm in 1981 and that's why it is also known as
COCOMO'81. It is a method for evaluating the cost of a software package. According to him software cost estimation should be done through
three stages:
• Basic COCOMO Model
• Intermediate COCOMO Model
• Complete/Detailed COCOMO Model
COCOMO'81 models depend upon the two main equations:
Development Effort : MM = a * KDSI b

Which is based on MM - man-month / person month / staff-month is one month of effort by one person.

Note: In COCOMO'81, there are 152 hours per Person month. According to organization this values may differ from the standard by 10% to
20%.
Efforts and Development Time (TDEV) : TDEV = 2.5 * MM c
Note: The coefficients a, b and c depend on the mode of the development.

DEVELOPMENT MODES:

There are three modes of development:

Organic: A software project is said to be an organic type if-
• Project is small and simple.
• Project team is small with prior experience.
• The problem is well understood and has been solved in the past.
• Requirements of projects are not rigid, such a mode example is payroll processing system.

Yazhini 12
 S/W Project Estimation & COCOMO and Risk Management

Semi-Detached Mode: A software project is said to be a Semi-Detached type if-

• Project has complexity.
• Project team requires more experience, better guidance and creativity.
• The project has an intermediate size and has mixed rigid requirements such a mode example is a transaction
processing system which has fixed requirements.
• It also includes the elements of organic mode and embedded mode.
• Few such projects are- Database Management System(DBMS), new unknown operating system, difficult inventory
management system.

Embedded Mode: A software project is said to be an Embedded mode type if-

• A software project has fixed requirements of resources .
• Product is developed within very tight constraints.
• A software project requiring the highest level of complexity, creativity, and experience requirement fall under this
category.
• Such mode software requires a larger team size than the other two models.

Development Mode with Project Characteristics:

Size Innovatio Deadline Dev.
n Environment

ORGANIC Small Little Not Tight Stable

SEMI- Medium Medium Medium Medium
DITACHED
EMBEDDED Large Greater Tight
Yazhini Complex Hardware 13
 S/W Project Estimation & COCOMO and Risk Management

Advantages of COCOMO’81
• COCOMO is transparent; you can see how it works unlike other models such as SLIM.
• Drivers are particularly helpful to the estimator to understand the impact of different factors that affect project costs.
Drawbacks of COCOMO’81
• It is hard to accurately estimate KDSI (thousand delivered source instruction) early on in the project, when most effort
estimates are required.
• KDSI, actually is not a size measure it is a length measure.
• It is extremely vulnerable to misclassification of the development mode.
• Success depends largely on tuning the model to the needs of the organization, using historical data which is not always
available.

COCOMO-II
COCOMO-II is the revised version of the original Cocomo (Constructive Cost Model) and is developed at University of
Southern California. It is the model that allows one to estimate the cost, effort and schedule when planning a new
software development activity.
COCOMO 1 and COCOMO 2 are two cost estimation models, developed by Barry Boehm. These two cost estimation
models are used for computing the cost of software development. The most basic difference between these two models is
that the COCOMO 1 model helps to provide the estimates required for the efforts and schedule, whereas the COCOMO 2
model provides the estimates that represent a standard deviation near the most likely estimate.
COCOMO II has three different models:
The Application Composition Model: Suitable for projects built with modern GUI-builder tools. Based on new Object
Yazhini 14
Points.
 S/W Project Estimation & COCOMO and Risk Management

The Post-Architecture Model: This is the most detailed COCOMO II model. You'll use it after you've developed your
project's overall architecture. It has new cost drivers, new line counting rules, and new equations.
COCOMO II can be used for the following major decision situations
• Making investment or other financial decisions involving a software development effort
• Setting project budgets and schedules as a basis for planning and control
S.No
• Deciding on or negotiating tradeoffs among software cost, schedule,
.
functionality,
COCOMO 1 COCOMO 2

performance or quality factors 1.

It is used in waterfall model of It is used in non-sequential, rapid
software development cycle. development of models.
• Making software cost and schedule risk management decisions
It helps reuse the models of
• Deciding which parts of a software system to develop, reuse, lease, or purchase software. It also helps provide
It helps give estimates required for
2. estimates which represent a
the efforts and schedule.
• Making legacy software inventory decisions: what parts to modify, phase out, standard deviation near the most
likely estimate.
outsource, etc It is based on the linear reuse It is based on the non-linear
3.
formula. formula of reuse.
• Setting mixed investment strategies to improve organization's software capability,
It is based on the reuse model
It is based on the assumption of
via reuse, tools, process maturity, outsourcing, etc. 4.
reasonable stable requirements.
that focuses on effort required to
understand and estimate.
The effort equation has an exponent The effort equation has an
Difference between COCOMO 1 and COCOMO 2 5. that is figured out using 3 exponent that is determined by 5
development modes. scale factors.
The following table highlights all the major differences between COCOMO 1
The development begins after the
It uses spiral development
6. requirements are assigned to
and COCOMO 2 software.
method.

Note: Please Refer book for Example of COCOMO-II 7. The number of sub-models are 3.
The number of sub-models
required are 4.

Yazhini8. It is assigned with 1715

cost
It has 15 cost drivers assigned to it.
drivers.
 S/W Project Estimation & COCOMO and Risk Management

Risk Management
• Risk management is the identification, evaluation, and prioritization of risks followed by coordinated and economical application of
resources to minimize, monitor, and control the probability or impact of unfortunate events or to maximize the realization of
opportunities.
• The risk management practice, which involves risk identification, analysis, prioritization, planning, mitigation, monitoring and
communication.
• To reduce risk, an organization needs to apply resources to minimize, monitor and control the impact of negative events while
maximizing positive events. A consistent, systemic and integrated approach to risk management can help determine how best to
identify, manage and mitigate significant risks.
Risk and Risk Event
• Event risk refers to any unforeseen or unexpected occurrence that can cause losses for investors or other stakeholders in a
company or investment.
• A risk is the possibility that an undesirable even (called the risk event) could happen. Risks involve both uncertainty and loss.
Proactive risk management is the process of trying to minimize the possible bad effects of risk events happening.
Risk Management and Software Project Management
• Risk management in software engineering is related to the various future harms that could be possible on the software due to
some minor or non-noticeable mistakes in software development project or process.
• Risk management is the most important issue involved in the software project development. This issue is generally managed by
Software Project Management (SPM). During the life cycle of software projects, various risks are associated with them. These
risks in the software project is identified and managed by software risk management which is a part of SPM.
• Some of the important aspects of risk management in software engineering are software risk management, risk classification and
strategies for risk management.
Purpose of Risk Management
• Anticipate and Identify risk
Yazhini 16
• Minimize the impact/damage/loss
 S/W Project Estimation & COCOMO and Risk Management

• Reduce the probability

• Monitor risk areas for early detection
• Ensure management awareness of risks
Categories of Risk
Risk categories can be defined as the classification of risks as per the business activities of the organization and provides a structured
overview of the underlying and potential risks faced by them. Most commonly used risk classifications include strategic, financial,
operational, people, regulatory and finance.
Schedule Risk: When the release or completion of the project is not assessed and addressed correctly, the schedule risk takes place.
Such a risk can impact a project
and might even be the reason behind the failure of the same and, thus, can result in losses for the company.
Budget Risk: Budget risk can be defined as a risk that arises from an improper estimation of a budget allocated
to a particular project or process. Budget risk is also regarded as cost risk, and the implications of such a risk
are delay in the completion of a specific project, premature handover of the project, failure to deliver the
quality project or compromise in the quality of the project in comparison to what was committed to the client, etc.
Operational Risk: Operational risks can be defined as the risks of loss arising from improper implementation of
processes, external issues (weather problems, government regulations, political and environmental pressures, and so on),
etc. Operational risks can be better understood as a type of risk due to inefficiencies in business operations carried
out by an organization. Examples of operational risks are insufficient resources, failure in resolving conflicts, etc.
Technical Environment Risk: Technical environment risk can be regarded as the risk concerning the environment in which both the
customers and the clients operate. This risk can take place due to the testing environment, regular fluctuations in production, etc.
Programmatic Risk: These are the risks that are not within the control of a program or outside the purview of the operational limits.
Yazhiniof programmatic risks.
Changes in product strategy or government regulations are examples 17
 S/W Project Estimation & COCOMO and Risk Management

Risk Management Plan

A risk management plan documents the whole process, including identifying, evaluating, and mitigating risk. It also
includes risk control monitoring, cost-benefit analysis, and financial impacts. A risk assessment is only one specific part of
that larger risk management process.
Top 10 Risks in software Project Management
• Personnel shortfalls
• Unrealistic schedules & budgets
• Developing the wrong functions & properties
• Developing the wrong user interface
• Gold-plating
• Continuing stream of requirements changes
• Shortfalls in externally furnished components
• Shortfalls in externally performed tasks
• Real-time performance shortfalls
• Straining computer-science capabilities
Risk Identification
• This is the process of identifying possible risks. Risks can be classified as affecting the project
plan (project risks), affecting the quality (technical risks), or affecting the viability of the product (business risks).
• Some experts exclude events that are common to all projects from consideration for risk management. These experts
Yazhini
consider those common events as part of standard project planning. 18
 S/W Project Estimation & COCOMO and Risk Management

Factors to consider when Examining Project

There are some specific factors to consider when examining project, product, and business risks. Some examples of
these factors are listed here,
People risks are associated with availability, skill level and retention of the people on the development team.
Size risks are associated with the magnitude of the product and the product team. Larger products are generally more
complex with more interactions. Larger teams are harder to coordinate.
Process risks are related to whether the team uses a defined, appropriate software development process and to
whether the team members actually follow the process.
Technology risks are derived from the software or hardware technologies that are being used as part of the system
being developed. Using new or emerging or complex technology increases the overall risk.
Tools risks, similar to technology risks, relate to the use, availability and reliability of support software used by the
development team, such as development environment and other Computer-Aided Software Engineering (CASE) tools.
Organizational and managerial risks are derived from the environment where the software is being developed.
Customer risks are derived from changes to the customer requirements, customers’ lack of understanding of the
impact of these changes, the process of managing these requirements changes, and the ability o the customer to
communicate effectively with the team and to accurately convey the attributes of the desired product.
Estimation risks are derived from inaccuracies in estimating the resources and the time required to build the product
properly.
Risk Analysis
After risks have been identified and enumerated, the next step is risk analysis. Risk analysis is the process of identifying
and analyzing potential future events that may adversely impact a company. A company performs risk analysis to better
understand what may occur, the financial implications of that event occurring, and what steps it can take to mitigate or
Yazhini 19
eliminate that risk.
 S/W Project Estimation & COCOMO and Risk Management

THANK YOU
Yazhini 20