Dr. D. Y.

Patil School of MCA

MCA I, SEM II
A.Y. 2023-24

Subject:- Software Project Management.

By
Prof. Supriya Ghodekar.
Chapter No-2
Linear Software Project Estimation
Chp-2 Linear Software Project Estimation

2.1 Different methods of Cost estimation

2.1.1 COCOMO-I & II model (Problem Statement)
2.1.2 Delphi cost estimation
2.2 Function Point Analysis (Problem Statement)
2.3 The SEI Capability Maturity Model CMM
2.4 Software Configuration management
What is a Software Project Estimation?

A Software Project Estimation is a document that helps define the

resources (people and tools) you’ll need to build your project by
listing specific tasks, how many hours it’ll take, and how much it’ll
cost (roughly).
What are Project Estimation Techniques?

Project estimation techniques refer to the procedures and tools

used to develop rough calculations of various aspects of any
project. An excellent example of this is a project cost estimate that
provides an overview of the anticipated expenses associated with
the project. Whenever stakeholders or clients require information
on any project aspect, these techniques help project managers
evaluate realistic numbers essential to plan a project successfully.
Why is Project Estimates Important?

Accurate estimates are critical to plan and execute a project

successfully. Without precise estimates, it becomes tough to
determine how long a project will take or the number of resources
required. Project managers use these estimates to ensure the team
has the right people, materials, and tools available whenever
needed. These estimates also help managers set realistic goals and
expectations for the team members and the stakeholders.
Who Estimates Projects?

Estimating a project is typically done by the project team.

Although the project manager may be in charge of the database
or documents used to record estimates, the whole team and
subject matter experts need to participate in creating and
refining the estimates. Engaging more knowledgeable
individuals in the estimation process increases the chances of
generating realistic figures. The project manager ensures the
estimates are complete and updated whenever necessary
The 3 Major Parts to Project Estimation
 Effort estimation
 Cost estimation
 Resource estimate
While accurate estimates are the basis of sound project planning, there
are many techniques used as project management best practices in
estimation as - Analogous estimation, Parametric estimation, Delphi
method, 3 Point Estimate, Expert Judgment, Published Data Estimates,
Vendor Bid Analysis, Reserve Analysis, Bottom-Up Analysis, and
Simulation. Usually, during the early stages of a project life cycle, the
project requirements are feebly known and less information is available
to estimate the project. The initial estimate is drawn merely by
assumptions knowing the scope at a high level, this is known as ‘Ball-
park estimates’, a term very often used by project managers
1. Top-Down Estimate Once more detail is learned on the scope
of the project, this technique is usually followed where high-
level chunks at the feature or design level are estimated and
are decomposed progressively into smaller chunks or work-
packets as information is detailed.

2. Bottom-Up Estimate This technique is used when the

requirements are known at a discrete level where the smaller
workpieces are then aggregated to estimate the entire project. This
is usually used when the information is only known in smaller
pieces.
3. Analogous Estimating This project estimation technique is used when
there is a reference to a similar project executed and it is easy to correlate
with other projects. Expert judgment and historical information of similar
activities in a referenced project are gathered to arrive at an estimate of the
project.
4. Parametric Estimate This technique uses independent measurable
variables from the project work.
For example, the cost for construction of a building is calculated based on
the smallest variable as the cost to build a square feet area, the effort
required to build a work packet is calculated from the variable as lines of
codes in a software development project. This technique gives more
accuracy in project estimation.
5. Three-point Estimating This technique uses a
mathematical approach as the weighted average of an
optimistic, most likely and pessimistic estimate of the work
package. This is often known as the PERT (Program
Evaluation and Review Technique)
6. What-If Analysis This project estimation technique uses
assumptions based on varying factors like scope, time, cost,
resources, etc., to evaluate the possible outcomes of the project
by doing impact analysis. In a usual scenario, the project
estimate is done by conducting estimation workshops with the
stakeholders of the project, senior team members who could
give valuable inputs to the estimation exercise. The high-level
scope is broken down into smaller work packages,
components, and activities, each work package is estimated by
effort and resources needed to complete the work package. The
project may be detailed into the smallest chunk that can be
measured.
The following activities are done during the
workshop:
 Break down the scope into smallest work
package, components or activities (WBS)
 Sequence the activities in the order in which
they will be performed
 Identify the effort required to complete each
activity
 Identify the resource estimate to complete each
task or activity
 Identify the dependencies to complete each
activity
 Identify the possible risks and assumptions
 Define the resource and cost estimate to the
completion of each activity, component and work
package
When Should Estimates Take Place?
In a Waterfall project that follows a traditional approach, the
planning phase occurs after project initiation. During this
phase, estimates are made and recorded for different aspects
such as scope, cost, time, resources, quality, and risks. These
estimates may be subject to adjustments throughout the project
as and when new information arises. For example, if new risks
are identified, project risk estimates must be updated
accordingly. Agile projects, on the other hand, adopt a more
iterative planning approach. Such projects are usually divided
into sprints or iterations in most Agile frameworks. During the
initial stage, estimates are created when compiling the overall
project backlog - a list of features and requirements. During
each sprint, estimates are updated either in the sprint
retrospective or the sprint planning session for each new sprint
What Is Cost Estimation in Project
Management?
A project can only come together with all the necessary materials
and labor, and those materials and labors cost money. Putting
together a budget that keeps costs to a minimum, while
maximizing the project’s quality and scope can be challenging.
This is why proper cost estimation is important.

In this article, we will define what cost estimation is and also

cover the key elements for estimating costs.
Want to skip the theory and jump right into the work? Unlock a
free trial with Wrike right now to manage and track project costs
with ease.
Definition of Cost estimation:

“Cost estimation in project management is the process of forecasting the

financial and other resources needed to complete a project within a defined
scope.
“ Cost estimation accounts for each element required for the project —
from materials to labor — and calculates a total amount that determines a
project’s budget.”
Software Cost Estimation
For any new software project, it is necessary to know how much it will cost
to develop and how much development time will it take. These estimates are
needed before development is initiated, but how is this done? Several
estimation procedures have been developed and are having the following
attributes in common.
1. Project scope must be established in advanced.
2. Software metrics are used as a support from which evaluation is made.
3. The project is broken into small PCs which are estimated individually.
To achieve true cost & schedule estimate, several option arise.
4. Delay estimation
5. Used symbol decomposition techniques to generate project cost and
schedule estimates.
6. Acquire one or more automated estimation tools.
Uses of Cost Estimation
1. During the planning stage, one needs to choose how many engineers
are required for the project and to develop a schedule.

2.In monitoring the project's progress, one needs to access whether the
project is progressing according to the procedure and takes corrective
action, if necessary.
Elements of cost estimation in project management
There are two key types of costs addressed by the cost estimation
process:
1.Direct costs: Costs associated with a single area, such as a
department or the project itself. Examples of direct costs include fixed
labor, materials, and equipment.
2.Indirect costs: Costs incurred by the organization at large, such as
utilities and quality control.
Within these two categories, here are some typical elements that a cost
estimation will take into account:
•Labor: The cost of team members working on the project, both in
terms of wages and time
•Materials and equipment: The cost of resources required for the
project, from physical tools to software to legal permits
•Facilities: The cost of using any working spaces not owned by the
organization.
•Vendors: The cost of hiring third-party vendors or contractors.
•Risk: The cost of any contingency plans implemented to reduce risk.
Cost Estimation Models
A model may be static or dynamic. In a static model, a single variable is
taken as a key element for calculating cost and time.
In a dynamic model, all variable are interdependent, and there is no basic
variable.
1)Static, Single Variable Models: When a model makes use of single
variables to calculate desired values such as cost, time, efforts, etc. is
said to be a single variable model.
Where C = Costs
L= size
a and b are constants

The Software Engineering Laboratory established a model

called SEL model, for estimating its software production.
This model is an example of the static, single variable
model.

E=1.4L0.93
DOC=30.4L0.90
D=4.6L0.26

Where E= Efforts (Person Per Month)

DOC=Documentation (Number of Pages)
D = Duration (D, in months)
L = Number of Lines per code
2)Static, Multivariable Models:
These models are based on method (1), they depend on several
variables describing various aspects of the software development
environment.
In some model, several variables are needed to describe the software
development process, and selected equation combined these variables
to give the estimate of time & cost. These models are called
multivariable models.
2)Static, Multivariable Models:

E=5.2L0.91
In the same manner duration of development is given by
D=4.1L0.36

The productivity index uses 29 variables which are found to

be highly correlated productivity as follows:

Where Wi is the weight factor for the ithvariable and Xi={-1,0,+1} the
estimator gives Xione of the values -1, 0 or +1 depending on the
variable decreases, has no effect or increases the productivity.
Methods of Cost Estimation in Projects –
Tools and Techniques
Expert Judgement Method.
Analogous Estimating Method.
Parametric Estimating Method.
Bottom-up Estimating Method.
Three-Point Estimating Method.
Data Analysis Method.
Project Management Information System Method.
Decision-Making Method
Expert Judgement

While estimating the project cost, the first step is to take the
comments from the experts.
The experts are the people who have prior knowledge on similar
kind of projects.
So they can suggest valuable insight based on their experience.
You can also take their advice on various tools and techniques that
can be used to estimate similar kind of project.
Analogous Estimation
Normally, at the early stages of your project, you do not have much
detail, so taking into account of similar projects previously
completed by your organization, the cost of the project can be
estimated. Analogous estimation technique uses the parameters such
as scope, budget, duration, size, weight and complexity of previous
projects having similar nature of works. It measures the current
project on that basis and does the estimation.
The technique is less costly and less time-consuming. But the
accuracy of this estimation is lower than the other estimation
techniques as it is purely based on historical data. It can be applied to
the whole project or some part of the project in combination with
other techniques.
For example, if the budget of a particular activity in the previous
project has X amount, and by measuring the same activity in your
current project looks identical, then the same X amount can be
applied to that.
Parametric Estimation
This technique uses an algorithm to calculate the cost of the activity
considering the historical data and other project variables. A
statistical relationship needs to be evaluated between the historical
data and other variables. This technique can be used for the complete
project or for some
of the activities in conjunction with other estimation techniques. This
is one of the most accurate techniques to estimate the cost of the
project.
For example, in an industrial project, one of the activities is to make
10 valves in the first phase. So as part of historical data gathering,
you got the information that construction of each valve requires
$150.

Based on that information you can calculate as:

•Total cost of making 10 valves = cost per valves * no. of valves
•Total cost = 150∗10=150∗10=1500
Bottom-Up Estimation
Bottom-up estimation technique starts with the estimation
from the lower level i.e. the work package level created as
per WBS(work-breakdown structure) and then rolled up to
higher-level.+
The accuracy of this estimation technique is high as you are
doing the estimation from granular level
Three-Point Estimation
To deal with uncertainties and risk, you need to take the help of three-
point estimation which is also referred as PERT- Program Evaluation and
Review Technique.
The Program Evaluation and Review Technique use three types of
estimations:
•M – Most Likely: The realistic or ideal situation, all the required
resources will be assigned and can achieve the expected productivity
•O – Optimistic: Estimation based on best case scenario
•P – Pessimistic: Estimation based on worst case scenario
Based on the above assumptions, the expected duration can be calculated
using two basic formulas.
•Triangular Distribution – (O+M+P)/3
•Beta distribution – (O+4M+P)/6
Reserve Analysis
• To deal with uncertainty, you need to allocate some
funds called as the contingency reserve. That is the part
of the cost baseline to mitigate the identified and
accepted risks.
• Also for unknown risks, an amount needs to be
estimated which is called management reserve.
• This is not included in the cost baseline but part of the
overall project budget. It is important to keep the reserve
budget to deal with uncertain events.
• The contingency reserve is under the project manager
authority, while to use the management reserve the
project manager need to take approval from the sponsors.
Project Management Software
• There are some tools which can be used to
perform the project cost estimation, such as cost
estimating software application, spreadsheets,
simulation and statistical tools.
• This is another technique to estimate the cost by
comparing the various bids proposed by the
vendors. There may be differences in their bids
but you can get an idea considering the average
bid values.
Group Decision Making Techniques
• This technique emphasizes the involvement of a group of people who are going
to perform the technical work. By involving those you will gain more details on
the work and thus helpful to estimate more accurately.
• Also, it develops a commitment from the people who are involved in the
discussion to complete the work as estimated.
• Depending upon the nature of your project, either you can apply these
techniques together or in combinations of few techniques to estimate the project
cost.
• Also, keep in mind that the estimations are never drawn to an exact figure; it is
always in the probable ranges.
• In the initial phases, the preliminary estimate ranges between -15% to +50%,
while the rough order of magnitude estimates in between -25% to +75%. And
the budget estimate falls in -10% to +25% ranges.
COCOMO Model
Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.
COCOMO is one of the most generally used software estimation models in the
world.
COCOMO predicts the efforts and schedule of a software product based on the
size of the software.
The necessary steps in this model are:
1.Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KDLOC).
2.Determine a set of 15 multiplying factors from various attributes of
the project.
3.Calculate the effort estimate by multiplying the initial estimate with
all the multiplying factors i.e., multiply the values in step1 and step2.
The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using
KDLOC as the measure of the size. To determine the initial effort E i in
person-months the equation used is of the type is shown below
Ei=a*(KDLOC)b
COCOMO-I
The term COCOMO stands for "Constructive Cost Model".
This model is used to estimate effort, cost and schedule for
software projects. Barry W. Boehm proposed the model. The
fundamental input to COCOMO is the estimated number of
lines of source code.
Boehm proposed three levels of the model:
1. Basic,
2. Intermediate,
3. Detailed.
The basic COCOMO-I model is a single-valued, static model
that computes software development effort (and cost) as a
function of program size expressed in estimated thousand
delivered source instructions (KDSI). The basic method uses
simple formulae to derive the total number of man months of
effort, and the total elapsed time of the project, from the
estimated number of lines of code.
COCOMO-I models depends on the two main equations
for prelimi
Effort = Ax (Size) 8
Timedev = Cx (Effort)D
The value of the constant a and b are depends on the project type.
In COCOMO, projects are categorized into three types:
1.Organic
2.Semidetached
3.Embedded

1.Organic: A development project can be treated of the organic

type, if the project deals with developing a well-understood
application program, the size of the development team is
reasonably small, and the team members are experienced in
developing similar methods of projects.
Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing
systems.
2. Semidetached: A development project can be treated with semidetached type if
the development consists of a mixture of experienced and inexperienced staff.
Team members may have finite experience in related systems but may be
unfamiliar with some aspects of the order being developed.

Example of Semidetached system includes developing a new operating

system (OS), a Database Management System (DBMS), and complex
inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the

software being developed is strongly coupled to complex hardware, or if the
stringent regulations on the operational method exist.
For Example: ATM, Air Traffic control.
The coefficients A,B and C depend on the mode of the
development/classes of software projects. These classes or
types are as follow:

1. Organic: In this type, the software is developed by small

software teams in a highly familiar environment.

2. Semi-detached: This type is seen as a bridge-type

between the organic and embedded types. It can either be
seen as a mixture of characteristics of both types or an
intermediate level of project characteristic.

3. Embedded: In this type, the product is operated within a

highly coupled complex of hardware,
Software and operational constraints.
There are three modes of development
Advantages of COCOMO-I
1. COCOMO is transparent, one can see how it works
2. Drivers are particularly helpful to the estimator to understand the
impact of different factors that affect project costs.
Drawbacks Of COCOMO-I
Software Project Estimation
1. The number of lines of code is only accurately predictable at the end of the
architectural design phase of a project, and this is too late;
2. Line of code can vary amongst programming languages and conventions
3. The concept of a line of code does not apply to some modern programming
techniques, e.g. visual programming.
4. It is hard to accurately estimate KDSI (Thousand delivered source
instructions ) early on in the project, when most effort estimates are required
5. KDSI, actually, is not a size measure it is a length measure
6. Extremely vulnerable to misclassification of the development mode
7. Success depends largely on tuning the model to the needs of the
organisation, using historical data which is not always available
COCOMO II
The most fundamental calculation in the COCOMO model is the use of the
Effort Equation to estimate the number of Person-Months required developing
a project.
Most of the other COCOMO results, including the estimates for Requirements
and Maintenance, are derived from this quantity.
COCOMO II provides two main models as follow:
(A) Early Design Model
(B) Post-architecture Model
The rest of this section describes each of these two models in details.
(A) Early Design Model

In the requirements analysis phase of a software project's

lifecycle, the stakeholders must agree upon the requirements.
The Early Design Model gets into action when these
requirements get agreed upon. The estimated effort required for
the software project is calculated using the following formula:
EffortNS= Ax (Size) E x M
where;

A: Constant (based on the calibration of local conditions and past data of

the firm).

Size: Size of the software (expressed in KLOCS).

E: Constant (calculated using a formula, which is shown below).

M: Constant (based on the attributes/cost-drivers of the project and is

calculated using a formula, which is shown below).

EffortNS: Estimated effort (expressed in units of PMs).

Timedev=Cx (Effort) F
where;
C: Constant (based on the calibration of local conditions and past data of
the firm).

F: Constant (calculated using a formula, which is shown below).

Effort: Previously calculated estimated effort (expressed in units of

PMs).

Timedev : Estimated development time (expressed in months).

Constants E and F are determined by using Scaling Factors
(SFS), In COCOMO II, there are five different Scaling Factors
that are listed as follow:
1. Precedentedness (PREC): Represents the similarity between
the current software project and previously developed projects.
2. Process Flexibility (FLEX): Represents the degree of
flexibility in the development process of the software project.
3. Risk Resolution (RESL): Represents the extent of the risk
analysis process that is carried out during the software project
lifecycle.
4. Team Cohesion (TEAM): Represents the extent to which the
software project's team members know each other and worked
well together previously.
5. Process Maturity (PMAT): Represents the level of the
Capability Maturity Model of the organisation that is realizing the
software project.
(B) Post-architecture Model
The development of the software project is calculated with the same formula
that is used in the Early Design Model. However, the Post-architecture Model
uses 17 properties for the calculation instead of 7 properties used by the Early
Design Model.
Features COCOMO 1 COCOMO 2
Full Forms COCOMO 1 is an abbreviation for COCOMO 2 is an abbreviation for
Constructive Cost Model 1. Constructive Cost Model 2.
Utilization Models It is utilized in the waterfall model It is useful in quick development, non-
of SDLC. sequential, and reuses software
models.
Basic It is based on the linear reuse It is based on the non-linear formula.
formula.
Estimation It offers estimates of the effort and It offers estimates that are one standard
Precision timeline. deviation from the most common
estimate.
Size of program The program's size is indicated in It has extra factors for expressing
statements code lines. software size, including lines of code,
object points, and function points.

Model framework The requirements given to the It utilizes the spiral type of
software come first in the development.
development process.
Effort equation's The 3 development methods define The 5 scale methods define the
exponent the exponent of the effort equation. exponent of the effort equation.

Sub models It has 3 submodels. It has 4 submodels.

Cost Drivers It utilizes 15 cost drivers. It utilizes 17 cost drivers.
Delphi Cost Estimation
Delphi estimation is a widely used technique in software project management
for estimating the time, effort, and cost involved in completing a project. It is
a consensus-based method that relies on the expertise of a group of
individuals, typically experts or stakeholders, to arrive at an estimation.
Here's how Delphi estimation works in the context of cost
estimation:
1.Formation of Expert Group: A group of experts or
stakeholders relevant to the project is selected. These
individuals should have knowledge and experience in the
domain of the project.
2.Initial Estimates: Each expert independently provides their
estimate of the cost involved in completing the project. These
estimates can be based on historical data, similar projects, or
their professional judgment.
3.Anonymous Feedback: The estimates are collected and
compiled anonymously. This means that individual estimates
are not disclosed to the group.
1.Feedback and Discussion: The compiled estimates are shared with the
group, highlighting the range and average of the estimates. Experts are
encouraged to discuss the factors influencing their estimates.
2.Reiteration: Experts revise their estimates based on the discussion and
feedback received from other participants. This process can be repeated
for multiple rounds until a consensus is reached or until the estimates
converge within an acceptable range.
3.Consensus: Eventually, the group arrives at a final estimate, which
represents a collective agreement on the likely cost of the project. This
estimate is often more accurate and reliable than individual estimates due
to the pooling of expertise and the iterative nature of the process.
Advantages Of Delphi Cost Estimation
1.Utilization of Expertise: Delphi estimation leverages the knowledge and
experience of experts in the field. By involving individuals who are familiar with
the project domain, technology, and relevant processes, it ensures that estimates
are based on informed judgment rather than guesswork.
2.Anonymity: The anonymity of individual estimates encourages participants to
provide honest and unbiased input. This helps in mitigating the influence of
dominant personalities or hierarchical dynamics within the group, leading to
more objective estimates.
3.Iterative Refinement: The Delphi method allows for iterative refinement of
estimates through multiple rounds of feedback and discussion. Participants can
revise their estimates based on insights gained from group interactions, leading
to convergence towards a more accurate and reliable estimate over time.
4.Consensus Building: Delphi estimation facilitates consensus building among
participants. By encouraging open dialogue and collaboration, it helps in reconciling
differences in perspectives and arriving at a shared understanding of project costs.
This shared consensus enhances buy-in and commitment to the estimated values.
5.Flexibility: Delphi estimation can be adapted to suit the specific needs and context
of the project. It can accommodate variations in the number and composition of
participants, as well as the frequency and format of interactions. This flexibility
makes it suitable for a wide range of projects, from small-scale developments to large-
scale enterprise initiatives.
6.Risk Mitigation: By drawing on the collective wisdom of experts, Delphi
estimation helps in identifying and mitigating potential risks associated with cost
estimation. Participants can discuss various factors influencing project costs, such as
technological complexity, resource availability, and market conditions, enabling a
more comprehensive assessment of uncertainties.
7.Time and Cost Efficiency: While Delphi estimation may involve multiple rounds
of feedback and discussion, it can ultimately lead to time and cost savings compared
to traditional estimation methods. By harnessing the efficiency of group collaboration
and consensus-building, it streamlines the estimation process and reduces the need for
extensive rework or adjustments.
 DisAdvantages Of Delphi Cost Estimation
1.Time-Consuming Process: Delphi estimation typically involves multiple
rounds of feedback and iteration, which can prolong the estimation process.
Coordinating schedules, collecting and analyzing data, and facilitating group
interactions require significant time and effort, potentially delaying project
planning and execution.
2.Resource Intensive: The iterative nature of Delphi estimation necessitates the
allocation of resources, including personnel, technology, and administrative
support. Managing the logistics of participant involvement, communication,
and documentation adds to the overall resource burden, particularly for large-
scale or complex projects.
3.Difficulty in Handling Technical Uncertainty: In software development,
where technological advancements and complexities are common, Delphi
estimation may struggle to account for technical uncertainties and emerging
trends. Expert opinions may vary widely based on individual interpretations
and assumptions, leading to inconsistent or unreliable estimates.
4.Limited Quantitative Data: Delphi estimation primarily relies on
qualitative inputs from experts, which may lack the precision and
objectivity of quantitative data. In software project management, where
stakeholders often demand concrete numerical estimates, the subjective
nature of Delphi estimates may pose challenges in decision-making and
resource allocation.
5.Potential for Groupthink: Despite efforts to maintain anonymity and
encourage diverse perspectives, the Delphi method may still be susceptible
to groupthink. Participants may conform to dominant opinions or avoid
expressing dissenting views, leading to a consensus-driven bias that
overlooks critical factors or risks associated with cost estimation.
6.Expert Availability : Ensuring the availability of qualified experts for
participation in Delphi estimation can be challenging, particularly for
specialized projects. Moreover, selecting participants with diverse
backgrounds and expertise levels is crucial to obtaining well-rounded
estimates, but this may introduce biases or limitations in the estimation
process.
7.Difficulty in Handling Dynamic Environments: Delphi estimation may struggle
to adapt to dynamic or rapidly evolving project environments, where market
conditions, technology trends, or regulatory requirements can change unpredictably.
Static estimates derived from expert judgment may become quickly outdated or
irrelevant in such contexts, necessitating continuous monitoring and revision.
8.Lack of Transparency and Accountability: The anonymity of individual
estimates in Delphi estimation, while intended to promote candid feedback, may also
hinder transparency and accountability. Participants may lack visibility into the
reasoning behind others' estimates, making it difficult to evaluate the credibility of
the inputs or hold contributors accountable for their judgments.
9.Overemphasis on Consensus: While consensus-building is a key aspect of Delphi
estimation, it may inadvertently prioritize agreement over accuracy. Participants may
prioritize harmony and conformity over critical evaluation, leading to inflated or
overly optimistic estimates that do not reflect the true complexities or uncertainties
of the project.
Functional Point (FP) Analysis
Allan J. Albrecht initially developed function Point Analysis in 1979
at IBM and it has been further modified by the International Function
Point Users Group (IFPUG). FPA is used to make estimate of the
software project, including its testing in terms of functionality or
function size of the software product. However, functional point
analysis may be used for the test estimation of the product. The
functional size of the product is measured in terms of the function
point, which is a standard of measurement to measure the software
application.
Objectives of FPA

The basic and primary purpose of the functional point analysis is to

measure and provide the software application functional size to the client,
customer, and the stakeholder on their request. Further, it is used to
measure the software project development along with its maintenance,
consistently throughout the project irrespective of the tools and the
technologies.
 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 interfaces Shared databases and shared

(EIF) routines.
Example: Suppose the requirement specification for the
Website Development of the Children Welfare Project has been
carefully analyzed and the following estimates have been obtained.
There is a need for 11 inputs, 11 outputs, 7 inquiries, 22 files, and 6
external interfaces. Also, assume outputs, queries, Internal files
function point attributes are of low complexity and all other
function points attributes are of medium complexity. Sum of all FP
is 40. What is the FUNCTION POINTS (FP) for the Children
Welfare project?
Information domain Value Low Medium High Total

External Inputs 3 4*11 6 44

External Outputs 4*11 5 7 44
External Inquiries 3*7 4 6 21
Internal Logical Files 7*22 10 15 154

External Interface Files 5 7*6 10 42

Total Unadjusted Function 305

Points
The count total computed is 305 which must be adjusted using
Equation-1. As we have Sum of All FP is 40.
Formula of Fp
FP=Total Unadjusted Function Points/Count Total*[0.65+(0.01*40)]

Therefore FP = 305 [0.65+ (0.01* 40)] = 320.25

• Software Engineering Institute Capability
Maturity Model (SEICMM)

• The Capability Maturity Model (CMM) is a procedure used to

develop and refine an organization's software development
process.
• The model defines a five-level evolutionary stage of
increasingly organized and consistently more mature processes.
• CMM was developed and is promoted by the Software
Engineering Institute (SEI), a research and development center
promote by the U.S. Department of Defense (DOD).
• Capability Maturity Model is used as a benchmark to measure
the maturity of an organization's software process.
Methods of SEICMM
1)Capability Evaluation: Capability evaluation provides a way to assess
the software process capability of an organization. The results of capability
evaluation indicate the likely contractor performance if the contractor is
awarded a work. Therefore, the results of the software process capability
assessment can be used to select a contractor.

2)Software Process Assessment: Software process assessment is used by

an organization to improve its process capability. Thus, this type of
evaluation is for purely internal use.
Level 1: Initial
Ad hoc Activities characterize a software development organization at
this level. Very few or no processes are described and followed. Since
software production processes are not limited, different engineers follow
their process and as a result, development efforts become chaotic.
Therefore, it is also called a chaotic level.

Level 2: Repeatable
At this level, the fundamental project management practices like
tracking cost and schedule are established. Size and cost estimation
methods, like function point analysis, COCOMO, etc. are used.
Level 3: Defined
At this level, the methods for both management and development
activities are defined and documented. There is a common
organization-wide understanding of operations, roles, and
responsibilities. The ways through defined, the process and product
qualities are not measured. ISO 9000 goals at achieving this level.

Level 4: Managed
At this level, the focus is on software metrics. Two kinds of metrics
are composed.
Product metrics measure the features of the product being developed,
such as its size, reliability, time complexity, understandability, etc.
Product metrics measure the features of the product being developed,
such as its size, reliability, time complexity, understandability, etc.

Process metrics follow the effectiveness of the process being used,

such as average defect correction time, productivity, the average
number of defects found per hour inspection, the average number of
failures detected during testing per LOC, etc. The software process
and product quality are measured, and quantitative quality
requirements for the product are met. Various tools like Pareto charts,
fishbone diagrams, etc. are used to measure the product and process
quality. The process metrics are used to analyze if a project performed
satisfactorily. Thus, the outcome of process measurements is used to
calculate project performance rather than improve the process.
Level 5: Optimizing
At this phase, process and product metrics are collected.
Process and product measurement data are evaluated for
continuous process improvement.
Key Process Areas (KPA) of a software organization
Except for SEI CMM level 1, each maturity level is featured by several Key Process Areas (KPAs
Software Configuration Management
When we develop software, the product (software) undergoes many changes in
their maintenance phase; we need to handle these changes effectively.
Several individuals (programs) works together to achieve these common goals.
This individual produces several work product (SC Items) e.g., Intermediate
version of modules or test data used during debugging, parts of the final
product.
The elements that comprise all information produced as a part of the software
process are collectively called a software configuration.
As software development progresses, the number of Software Configuration
elements (SCI's) grow rapidly.
SCM Process
It uses the tools which keep that the necessary change has been
implemented adequately to the appropriate component.

The SCM process defines a number of tasks:

1.Identification of objects in the software configuration
2.Version Control
3.Change Control
4.Configuration Audit
5.Status Reporting
1. Planning and Identification
The first step in the process is planning and identification. In this step,
the goal is to plan for the development of the software project and
identify the items within the scope. This is accomplished by having
meetings and brainstorming sessions with your team to figure out the
basic criteria for the rest of the project.
pecific activities during this step include:
•Identifying items like test cases, specification requirements, and
code modules
•Identifying each computer software configuration item in the process
•Group basic details of why, when, and what changes will be made
and who will be in charge of making them
•Create a list of necessary resources, like tools, files, documents, etc.
2. Version Control and Baseline
The version control and baseline step ensures the continuous integrity
of the product by identifying an accepted version of the software. This
baseline is designated at a specific time in the SCM process and can
only be altered through a formal procedure.
•Identifying and classifying the components that are covered by the
project
•Developing a way to track the hierarchy of different versions of the
software
•Identifying the essential relationships between various components
•Establishing various baselines for the product, including
developmental, functional, and product baselines
•Developing a standardized label scheme for all products, revisions,
and files so that everyone is on the same page.
3. Change Control
Change control is the method used to ensure that any changes that are
made are consistent with the rest of the project. Having these controls
in place helps with quality assurance, and the approval and release of
new baseline(s). Change control is essential to the successful
completion of the project.
•Controlling ad-hoc changes requested by the client
•Checking the merit of the change request by examining the overall
impact they will have on the project
•Making approved changes or explaining why change requests were
denied.
4.Configuration Status Accounting
The next step is to ensure the project is developing according to
the plan by testing and verifying according to the predetermined
baselines. It involves looking at release notes and related
documents to ensure the software meets all functional
requirements.
•Recording and evaluating changes made from one baseline to
the next
•Monitoring the status and resolution of all change requests
•Maintaining documentation of each change made as a result of
change requests and to reach another baseline
•Checking previous versions for analysis and testing.
5. Audits and Reviews
The final step is a technical review of every stage in the software
development life cycle. Audits and reviews look at the process,
configurations, workflow, change requests, and everything that has
gone into developing each baseline throughout the project’s
development.
Activities in this step include:
•Making sure that the goals laid out in the planning and identification
step are met
•Ensuring that the software complies with identified configuration
control standards
•Making sure changes from baselines match the reports
•Validating that the project is consistent and complete according to
the goals of the project.