What Is Effort Estimation?

Simply put, effort estimation is the process of estimating how much effort your project
will take to bring to life. It is expressed in terms of person-hours or money.

Effort estimation is a process in which project managers evaluate how much time and
money they need to complete a project. This technique is common in software
development, where technology professionals define the resources and schedule for
developing a new application or releasing an update. These forecasts help create
accurate estimates that often require approval before work on a project begins.

Effort estimation is a common tool as part of the agile methodology, which is a

framework that divides a project into smaller phases. In this framework, you can
estimate the effort for several components of development, including:

● Epics: Epics are large projects that several teams manage throughout
development. These usually contain several smaller releases and tasks.

● Features: A feature is a piece of functionality or design that addresses a user's

need. A feature often includes specific acceptance criteria that detail how that
part of the product should work.

● Sprints: A sprint is a short period containing a fraction of work. Often, a few

team members complete development tasks in sprints that build toward epics
and releases.

● Releases: Releases are software packages development teams can deploy.

These often contain several epics and features that teams deploy in iterations.

Development teams might estimate the effort for each of these components of the agile
framework or select components depending on the needs of the project.
A realistic effort estimate requires you to have a clear understanding of certain elements
of the project:
● The purpose and scope of the project (If working with a client, what are their
expectations?)
● What needs to be done to achieve it
● What resources should be allocated
● Timeline

Importance of Effort Estimation

● Understanding a project: When estimating the effort for development, it can

help team members to understand each task they need to complete, along with
any dependencies. Although you might have a clear scope, conversations you
have when estimating effort can help clarify project requirements and user
requests.

● Improving collaboration: Collaboration is a key concept in the agile framework,

and teams meet regularly to discuss priorities and status to accomplish this.
During estimation meetings, each team member can express their opinions on
efforts, priorities and resource needs.

● Creating an accurate budget: When you evaluate the effort to complete a

project, you can determine what team members, tools and time you need. This
can help you create an accurate project budget by estimating wages and the cost
of each resource.

● Making an accurate schedule: Organizations often rely on accurate delivery

schedules and provide this information to employees and customers. Using the
various estimation techniques can help ensure you build an accurate schedule
based on expert input and historical data.

● Managing resources and assignments: By evaluating the resources you need

for a project and the tasks to complete, you can estimate what resources you will
 need. This can help if development teams, such as QA, share resources or
assignments to ensure each can meet their schedules.

● Improving risk management: Estimating effort at the start of a project can help
you identify potential risks, like breaching a budget or schedule. With these
identified, you can create mitigation plans and prioritize monitoring high-risk
situations.

Some problems with estimating

● Nature of software.
○ Complexity and invisibility of software.

○ Subjective nature of much of estimating

○ Over-estimating small tasks and

○ Under-estimating large ones.

○ Political pressures

○ Different objectives of people in an organization

○ Managers may wish to reduce estimated costs in order to win support for
acceptance of a project proposal

● Changing technologies
○ Technology is rapidly changing, making the experience of previous project
estimates difficult to use in new ones.

○ Projects differ

○ Experience on one project may not be applicable to another

Challenges in Software Development Project Estimation:

There are many challenges in many aspects for project estimation. Below are some of
the significant challenges:
 ● The uncertain gray area ­–The biggest issue is the uncertainty involved at the
beginning of the project. Many times even the client is not clear about the
whole complete requirement. If there is no complete clear requirement then
how it’s possible to estimate it in term of effort and time?

● Not splitting bigger tasks- If somehow things are clear then many times the
estimation is taken keeping in mind the bigger tasks instead of splitting it into
smaller tasks for proper estimation. Such estimation will definitely will lead to
the overhead tasks at a later stage.

● Idealistic & optimistic estimation-Most of the time, the estimation is done

keeping in mind the ideal and optimistic conditions but things like version
maintenance, unavailability of some resource and change requests during the
project etc. are not considered in project estimation.

● Estimation person- Estimation must be done by the developer or in assistance

with the developer. Sometimes the estimation is not done by the developer
which may lead to huge mismatch in the estimation.

● Buffer & dependencies – It is always uncertain that how much buffer a PM

should take. Usually 15-20% buffer is taken keeping in mind project
elaboration as project progresses. But this decision should also consider the
things like skillsets, experience of the team and complexity of the project.
Dependency of project’s internal as well as external factors are not considered
most of the time. It can be in terms of some functionality like payment
integration or some license cost for some software etc.

Solution:

– Below are some of the steps which can help in better project estimation for a
successful software development project:

● Asking questions to clarify requirements ­– This is the most important part.

The PM should enquire as much as possible to go deeper to clarify all the
requirements. More clarity will always lead to better estimation. Clients will
 also appreciate this in some way as he will come to know about some aspects
which he didn’t even think about till now. He must clarify all functional,
non-functional and technical requirements separately for better understanding.
PM should clear up all uncertain gray area.

● Tasks Splitting ­– PM/Developer should split the task up to last mile small
sub-tasks which will definitely lead to much better estimation. A Bigger task
may have 10 sub-tasks inside it for which the cumulative effort may vary
significantly. A method is to create WBS, work breakdown structure, which
enlist all the sub-tasks and their efforts in detail for complete effort estimation.
Another way is also to split the tasks in MS projects with baseline details.
Smaller the tasks better it is.

● Estimation ­– Should always and always be done by the developer or in close

assistance with the developer by defining each milestone of the project. The
PM must use his experience also in estimation process. Estimation should be
come in range of time frame instead of a particular timeline. E.g. 4 to 5 months
is much better than a 4 months estimation. The reasons is- its estimation only
not a final deadline for the project. Estimation is always considered as a
deadline in most of the cases so the probability of going wrong in case of a
single number timeline is quite high.

● Proper buffer ­– Should be taken considering the things like skillsets,

experience of the team and complexity of the software project. All
dependencies must be understood well at estimation stage itself.

Over- and under- estimating

An over-estimate is likely to cause project to take longer than it would otherwise This
can be explained by the application of two laws: Parkinson’s Law: ‘Work expands to fill
the time available’ Thus, e.g. for an easy task over estimating the duration required to
complete it will cause some staff to work less hard to fill the time. Brook’s Law: putting
more people on a late job makes it later. So overestimating the effort required to
perform a task (activity) means more staff assigned to it than needed.
Underestimating a project: Can cause the project to not be delivered on time or cost but
still could be delivered faster than a more generous estimate On the other side the
danger of underestimating a project is the effect on the quality Zeroth law of reliability: if
a system doesn't have to be reliable it can meet any other objective .

Basis for successful estimating

A. The need for historical data.

● Most estimating methods need information about past projects
● Care has to be considered when applying past performance to new
projects because of possible differences in factors such as:
● Different programming languages
● Different experience of staff
● Different terminology

There are international Data Base containing data about thousands of projects
that can be used as reference

B. Measuring work.

The time and cost to implement software depends on:

● The developer’s capability and experience

● The technology that will be used
● The usual practice is to start by expressing work size independently of the
effort, using measures such as:
○ SLOC OR KLOC: Source lines of code or thousands of lines of code
○ Alternative size measure is Function Points (FP)

Major project estimation techniques

1. Top-down Estimate
Once more detail is learned on the project's scope, a top-down estimating technique
assigns an overall time for the project and divides the project into parts according to the
work breakdown structure.

For example, let’s imagine a project that must be finalized in one year. By fitting the
scope of the project on the timeline, you can estimate how much time is available for
each activity that needs to be performed. The top-down method is best applied to
projects similar to those you have completed previously. If details are sketchy or
unpredictable, the top-down approach is likely to be inefficient and cause backlogs.

Top-down, analogy-driven estimation methods use experience from the past to make
estimates for the future. Analogy-driven estimation methods require examples of
completed IT projects to base the new estimates upon. Note that one can do top down
estimations in multiple ways. The easiest way is finding three previous projects, and
take the average of these projects. A better, more advanced way is to use more
information for selecting the most similar projects. One should start with a database of
completed projects. For each completed project, the effort that was required to complete
it is listed together with information about the aspects that had an influence on the costs
of that project. These aspects are also known as effort drivers. An estimate for a new
project is derived by comparing the new project to all old projects and selecting the
(effort of the) project that is most similar. The advantage of using analogy-driven
estimation methods is that their basis is more objective and repeatable than expert
estimation.

Examples of top-down estimating

Here are some examples of when your company might use a top-down estimate:

New buildings

Many businesses use a top-down approach when they want to create a new office
building, satellite location or company branch. A company manager or other leader
typically decides to build a new office building or location. However, a manager may not
know the specific costs or procedures for the construction of an office building, such as
purchasing the land or outfitting the building with air conditioning. With a top-down
approach, this company leader can create a tentative plan and budget for the purchase
and construction of a new location. The company can then alter the top-down estimates
as the actual costs and details of the project become more certain.

Technology development

A top-down estimate can also be useful for companies looking to develop their
technology infrastructures, such as their cybersecurity system or network capabilities.
Company presidents or other leaders often determine the need for creating or altering a
company's technology infrastructure, so a top-down approach allows them to estimate
the project's costs and create a tentative plan. A company's IT or tech department can
then assess the specific costs of the project and create a more detailed plan based on
the president's top-down instructions.

Many technology companies also use a top-down approach to develop new devices or
systems that customers can then purchase. For example, a tech company might use a
top-down approach to plan the development of a new laptop.

Advantages of the top-down approach

Like other techniques, top-down estimating has its benefits and setbacks to project
managers and the team. Here are some of the advantages of using a top-down
estimate for your next project.

Useful for initial decision-making by the project manager

We mentioned before that the project management body provides the initial estimated
cost and duration in top-down decision-making. It forms a broad estimate of the time
and cost of the final deliverable. Having this information quickly available makes pivotal
decision-making easier during the early stages of the project, especially when the
details are still minimal.
Estimates are flexible

The top-down approach uses ballpark estimates of time and costs for the project. These
estimates are derived from various sources, such as the project accounts from similar
projects completed in the past or opinions from outside experts. However, as the project
progresses, the estimates are adjusted as more details become available. This makes
the planning more realistic and attainable.

Takes less time and effort

Because the top-down estimating technique focuses more on estimating the overall
costs and duration of the project rather than its components, this technique generally
takes less time and effort. This is useful when making initial decisions in the project
when all the project specifics are not yet defined.

Uses more holistic data

The top-down approach to estimating uses data from previous projects and/or products
to generate a time and cost estimate. This means that all risks, whether unforeseen or
not, are taken into consideration. Other than that, top-down estimating also considers
any scope creep that might happen during the project's duration.

The use of historical data in estimation relatively reduces any risk of overlooked tasks or
costs in the project, making the estimates larger than those derived from other methods.

Disadvantages

accuracy

A top-down estimate is less accurate than other estimating techniques. One way of
doing a top-down estimate is to break a project into a series of phases and only provide
an estimate one phase at a time, going by the most current phase. If managers make a
high-level estimate for an initial phase, while they gather business requirements, the
estimate could change later after they get the requirements.
overlooks lower levels of input

This approach provides less scope to get lower levels of input. Considering that the
estimate is from the top down and provides a global view of the project, this method
overlooks a lot of lower-level details. Another aspect of the omission is that businesses
often may not use the input of lower-level managers.

potential to mislead

One way of doing a top-down estimate is to use input from projects an organization
carried out in the past. While this is a convenient way of making an estimate, it has the
potential to mislead. If the project the business bases its estimation on is not similar to
the one for which it makes the estimate, the business may decide to go ahead with a
project it should have shelved. Alternately, the business may decide not to go ahead
with a potentially profitable project.

Top Down Estimates, most used methods.

At the strategic level top down estimates are used to evaluate the project proposal.
Sometimes much of the information needed to derive accurate time and cost estimates
is not available in the initial phase of the project—for example, design is not finalized. In
these situations top down estimates are used until the tasks in the WBS are clearly
defined.

Consensus Methods

This method simply uses the pooled experience of senior and/or middle managers to
estimate the total project duration and cost. This typically involves a meeting where
experts discuss, argue, and ultimately reach a decision as to their best guess estimate.
Firms seeking greater rigor will use the Delphi Method to make these macro estimates.

It is important to recognize that these first top down estimates are only a rough cut and
typically occur in the “conceptual” stage of the project. The top down estimates are
helpful in initial development of a complete plan. However such estimates are
sometimes significantly off the mark because little detailed information is gathered. At
this level individual work items are not identified. Or in a few cases, the top down
estimates are not realistic because top management “wants the project.”

Nevertheless, the initial top down estimates are helpful in determining whether the
project warrants more formal planning, which would include more detailed estimates. Be
careful that macro estimates made by senior managers are not dictated to lower level
managers who might feel compelled to accept the estimates even if they believe
resources are inadequate.

Although I prefer to avoid the top down approach if possible, I have witnessed surprising
accuracy in estimating project duration and cost in isolated cases.

Some examples are building a manufacturing plant, building a distribution warehouse,

developing air control for skyscraper buildings, and road construction.

However, I have also witnessed some horrendous miscalculations, usually in areas

where the technology is new and unproven.

Top Down estimates can be useful if experience and judgement have been accurate in
the past.

Ratio Methods

Top Down estimates (sometimes called parametric) usually use ratios, or surrogates, to
estimate project times or costs. Top Down estimates are often used in the concept or
“need” phase of a project to get an initial duration and cost estimate for the project.

For example, contractors frequently use number of square feet to estimate the cost and
time to build a house; that is, a house of 2,700 square feet might cost $160 per square
foot (2,700 feet X $160 per foot equals $432,000). Likewise, knowing the square feet
and dollars per square foot, experience suggests it should take approximately 10 days
to complete.

Two other common examples of top down estimates are the cost for a new plant
estimated by capacity size, or a software product estimated by features and complexity.
Apportion Methods

This method is an extension to the ratio method, apportionment is used when projects
closely follow past projects in features and costs. Given good historical data, estimates
can be made quickly with little effort and reasonable accuracy.

This method is very common in projects that are relatively standard but have some
small variation or customization. Anyone who has borrowed money from a bank to build
a house has been exposed to this process. Given an estimated total cost for the house,
banks and the Housing Authority authorize pay to the contractor by completion of
specific segments of the house.

For example, foundation might represent 3 percent of the total loan, framing 25 percent,
electric, plumbing and heating 15 percent, etc. Payments are made as these items are
completed.

An analogous process is used by some companies that apportion costs to deliverables

in the WBS (Work Breakdown Structure)—given average cost percentages from past
projects. The figure below presents an example similar to one found in practice.
Allocating project costs using a WBS

Assuming the total project cost is estimated, using a top down estimate, to be $500,000,
the costs are apportioned as a percentage of the total cost. For example, the costs
apportioned to the “Document” deliverable are 5 percent of the total, or The
sub-deliverables “Doc 1 and Doc-2” are allocated 2 and 3 percent of the total—S10,000
and $15,000, respectively.

2. Bottom-up Estimate

The bottom-up method is the opposite of top-down. It approaches the project as a

combination of small workpieces. By making a detailed estimate for each task and
combining them together, you can build an overall project estimate.

Creating a bottom-up estimate usually takes more time than the top-down method but
has a higher accuracy rate. However, for the bottom-up method to be truly efficient, the
project must be separated at the level of work packages.
Bottom-up estimation methods take a project definition and examine what activities or
deliverables need to be completed in order to achieve the project’s objective. One
keeps breaking up the project activities or deliverables into smaller sub activities or
partial deliverables until each sub activity of partial deliverable requires less than two
weeks of effort. After this project decomposition, in which the project is broken into
smaller bits, each individual part (be it activity or deliverable) is estimated. This
estimates are then combined into an overall estimate. The advantage of using
bottom-up estimation methods is that their estimates are more open to inspection (and
more understandable) than an expert’s holistic estimate. Also, since estimation errors
tend to cancel each other out, the bottom-up estimate is typically more reliable than an
expert’s single estimate of an entire project. Unfortunately the method has as a
disadvantage that it generally is less objective than a parametric estimation method,
since the decomposition contains subjective assessments of what needs to be done for
the project. Also it can take a lot of work to produce a good bottom-up estimate.

The term bottom-up estimating gives a hint about the underlying concept: costs,
durations or resource requirements are estimated at a very granular level. This means
that the estimation is done for work packages (some might suggest activities though)
which are the lowest and most detailed level of a work breakdown structure (WBS).
Bottom-estimating is done at the lowest level of the work breakdown structure.

While the estimation is performed at the level of activities or work packages, the
estimate for the whole project is the sum of all granular estimates.

The bottom-up estimation technique is also referred to as deterministic or detailed

estimating. It is often used as the so-called “definitive estimate” – a type of cost estimate
that comes with an accuracy between -5% and +10% according to the Project
Management Institute (PMI).

There are several steps involved, and we will discuss these in detail.

1. Define the Tasks

The first step in this technique involves listing all the different project elements
that you need to tackle. For instance, if a project consists of goods or getting
the bill of material, you should define that task.
You need to create a work breakdown structure to divide your entire project into
efficient and straightforward tasks.
This will help you look at the project from a granular level and determine the
most important aspects and people.
 2. Timelines and Resource Definitions
In the previous step, we mentioned that if you need to prepare a bill of
materials, you should mention that in the scope. At this point, you will need to
say the person in charge of creating the BoM and the total time it will take to
complete this.
Similarly, you will need to mention the same for all the tasks involved in a
project. It will help you identify how many resources you will need through the
project and timelines to consider. It will help you define the overall project
length and the total labor.

3. Determine the Allocations

Once you are done estimating the time and scope, it is now time to delegate
the tasks and empower your employees. Now is the time when people are
involved in creating the project estimation. You will need to get people to talk
about the infrastructure cost, the overheads involved, and the technology
defined for each project task or phase.
This will improve the granularity of the project definition and help the project
managers get a more in-depth insight into the estimate.
It will also ensure that nothing circles back to the project manager; everyone
determines the overall cost and resources for their particular area of expertise.

The pros of bottom-up estimating include:

● Highly accurate. Laying out the project's scope can be very challenging
since it involves estimating the exact details of the project and the people
involved in its execution. Bottom-up estimating allows team members to see
all the components of a project in one place, and it saves them time and
effort by estimating separately.

● Saves time. By estimating the work package in advance, a manager can

make better decisions and avoid costly mistakes. It also helps avoid
surprises down the road. Even though there is a large time investment up
 front, the idea behind the method is that it will prevent wasted time down the
road.

● Reduces risk. A bottom-up estimate allows the manager to address issues

related to the estimates without making significant changes. This allows the
team to avoid making significant errors.

● Improves success. A bottom-up analysis also allows managers to

implement strategies to help the team execute the project more effectively. A
comprehensive bottom-up analysis also allows the manager to identify
potential issues before they occur, which allows the team to react more
effectively to those that arise.

● Increases productivity. The team's autonomy and control are also

distributed through the various members of the team, which allows them to
work efficiently.

Bottom-up estimating cons:

● Not scalable. Bottom-up estimation requires project managers to start from
square one on each new project. There are opportunities to pull details from
related projects from the past. But the point of bottom-up estimation is to
create a forecast based on the individual components of this particular
assignment.

● Time-consuming. The project planning work is front-loaded. It can take

days, weeks, or even months to gather all the necessary information. For
teams with a high volume of incoming projects or staffing issues, this may
not be ideal.

● Slow-moving. Bottom-up estimation is typically not done in a hurry and is

therefore incompatible with last-minute projects or work that has a short
timeline.

Bottom-up estimating example

Example-1
Let’s imagine you’ve been tasked with determining how much money the project to build
a school will cost.

To determine how much the project will cost using the bottom-up estimation method,
you must first break the project down into its five distinct phases, as illustrated in the
graphic to the right.

The five phases of the project are site preparation, buying resources, constructing,
building, cleaning up the site, and handing over the building to the project sponsor.

You will further break these five phases into a work package level and an activity level.

Once you have progressed to the activity level, you will evaluate the available
resources, compute the cost, and determine how long each task will take. After that, you
will add all of these numbers together to get the final cost of the job and the length of
time it will take.

Many projects do not use bottom-up estimation as it is costly and time-consuming. In its
place, they utilize a somewhat similar method to perform a high-level estimation.
After completing the estimation process, you will employ progressive elaboration to
refine the cost as you obtain more specific information.

The project team can go forward, react swiftly and properly to market demands, and
move forward since they accepted the risk.

Bottom-up estimating involves the entire project team in the estimation process;
consequently, this technique develops better team commitment than other estimating
techniques.

Sometimes, team members may add padding, causing the estimate more than the
actual. You should look for these mistakes in your estimation.

Since you have all the estimation information, this technique also allows assessing the
change request against cost and time.

Example 2

In its simplest form, bottom-up estimation looks at the individual costs and time duration
required for each project task.

For example, let’s say you own a wedding cake bakery. The last time you gave a
wedding cake quote for a three-tier and several dozen cupcakes, you underestimated
the cost and lost profit on the project. Now, you’d like to better estimate a brand new
order to avoid making the same mistake twice.

In this scenario, you would lay out the individual components needed for each baked
good. Everything from frosting quantity to hairnets is factored in. You’ll also need to
account for the time it takes to do the shopping, coordinate customer service, and more.

Having all of this together on one list will make it possible for you to see the entire scope
of the project and provide an accurate estimation this time around.

Example 3
Here’s a hypothetical example of bottom-up estimating to show you what this process
looks like.

Imagine an IT department with 64 computer workstations that must be converted to a

cloud services contract. The manager is tempted to do a top-down approach and just
come up with an estimate based on similar projects in the past, but he knows some
workstations are obsolete and will require a special process. As a result, he conducts a
bottom-up analysis.

During this process, he finds 10 computers are obsolete and must be replaced. He
further finds another five computers are current but require extra permissions and aren't
a good fit for the project. In his analysis, he describes what must be done to each
computer, estimates the cost of each task and how long it will take, and then assigns it
to an IT employee with a deadline based on this analysis.

Had he conducted a top-down approach, the project would have been delayed and
there would have been cost overruns as IT employees discovered problems setting up
the new cloud system.

3. Expert judgement

The expert judgment technique requires consulting the expert who will perform the task
to ask how long it will take to complete. This method relies on your trust in the expert's
insights and experience.

While it may seem like the most accurate estimation method, there are two points to
consider:

● The expert's estimates need to be objective. Estimates that are carried out very
positively and overlook possible disruptions can create difficulties in meeting
deadlines.
 ● You can only get an accurate answer to specific questions. Detailing the task
description, framing it, and clarifying the requirements will allow the expert to
understand the task fully and provide an accurate estimate.

Expert estimation means that an expert estimates how much effort a project requires.
The advantages of asking somebody else than the project manager to estimate a
project, is that some experts have deep knowledge about the problem at hand. Many
experts will use intuition and/or previous experience to estimate the project, which is
usually more time-efficient than any of the other methods. The problem with expert
estimates is that their reliability is typically unknown (unless the organisation tracks the
performance of their estimators) and that their estimates are not objective. This last
aspect is important when discussions arise.

Note that there is big difference in asking an independent expert for an estimate, or
asking the person that has to perform the task for an estimate for that task. Asking the
person that has to do it probably yields more information, because the person has an
incentive to estimate accurately.

You can also use expert judgment:

● When the stakes are high. If you have a high-impact project coming up, it helps
to get validation from experts before you move forward.
● Before project planning. If you’re developing a project charter before you
create a project plan, you might want to bring in an expert to review it and
confirm that your project is viable.
● For cost management. When you’re determining cost estimates for product
pricing or even hiring, having an expert on hand will help you get as close as
possible to a realistic number.
● During decision-making. You can use expert judgment in a decision-making
framework, such as RACI, or during routine decisions. If you use RAPID, having
an expert as the decision-maker role helps you get full use of expert opinions.
 ● With forecasting. Experts can help you weigh factors such as the current macro
environment or market fit during forecasting, to help you get an accurate estimate
on potential sales.
● For risk management. An expert can review and analyze your risk assessment,
risk analysis, and risk responses to determine how high-risk different scenarios
are, so you can be prepared for any likely outcome.

Types of expert judgment:

Delphi technique: Running through the expert judgment process once will leave you
with one expert’s opinion, but these can be biased. The Delphi technique continues the
expert judgment process repeatedly in an effort to remove those cognitive biases.

Expert elicitation: When a group of experts in a specific knowledge area form one,
cohesive opinion. Usually used when there’s less data or resources available.

Who are the experts?

Your experts will vary depending on your needs—they could be anyone, from a team
member to a consultant you fly in for a unique situation. Your experts can be:

● Internal project team members. Your team is likely already made up of experts.
This is the easiest place (and often the first place) to look for experts.
● Subject matter experts. These are experts with a deep knowledge base of a
specific subject. For example, if you manage a manufacturing company, you’d
likely bring in a procurement expert when you’re looking for new potential
suppliers. Subject matter experts can be external consultants or in-house
experts. The benefits of using someone outside of your organization is that they
come without biases and can be more objective.
 ● Project managers. Project managers often have a deep understanding of their
subject matter. When using project managers as your experts, watch for biases
that come from working in the same field as you.
● Project stakeholders. Stakeholders can come from different backgrounds and
perform a variety of different roles. As a result, many of them are experts. Don’t
be afraid to lean on them for their valuable judgment.

The 7 steps to get expert judgment

It's not enough to just talk to an expert—you need to clarify what you want and expect
from them in order for the relationship to be successful. By clearly defining the inputs,
outputs, and expectations of the project, you and your expert can benefit from a
structured expert judgment process that satisfies everyone.
1. Research the problem

Before you can engage your expert, you must have a thorough understanding of
your problem. Make sure you know exactly what’s already been completed, where
the issue stands, and what you need from your expert.

2. Write out your questions

Be as specific as possible here. The more targeted your questions, the better your
expert’s answers will be. Using your research from the previous step, develop clear
questions. The questions you ask can be complex, but should be clear enough for
the expert to understand and answer.

3. Select your experts

Choose the experts that best fit the needs of this specific problem or project. For
example, if you’re working on product distributions, you’ll want to involve experts
who understand your industry’s supply chain and the target market. Then explain the
 problem to them, sharing all resources and project documents so they have the
knowledge they need to pass effective judgment.

4. Submit your questions

Send your questions off to your selected experts. If you’re using project
management software, you can attach relevant analyses and documents directly to
the questions. Then when your experts respond, you can see their answers in
real-time.

5. Review and analyze their judgements

Once you have answers from your experts, it’s up to you to review them and
determine how you’re going to use the information. To further mitigate bias, you
might want to use a peer review process made up of multiple experts to ensure
you’re getting the most accurate data.

6. Aggregate judgements in a report

Create a report of all the judgements you receive. Save it as one central source of
truth, so you can easily share the results with stakeholders.

7. Communicate results

Once you have your results neat and tidy, send them out to all stakeholders for
review. At this stage, you’ll also start to discuss if you need another round of expert
judgment. Mostly, you repeat the process if stakeholders spot errors or have
additional questions

4. Analogous Estimating

Analogous estimating is a technique for estimating based on similar projects completed

in the past. If the whole project has no analogs, it can be applied by blending it with the
bottom-up technique. In this case, you compare the tasks with their counterparts, then
combine them to estimate the overall project.
Analogous Estimation uses a similar past project information to estimate the duration or
cost of your current project, hence the word, "analogy". You can use analogous
estimation when there is limited information regarding your current project.

Quite often, there will be situations when project managers will be asked to give cost
and duration estimates for a new project as the executives need decision-making data
to decide whether the project is worth doing. Usually, neither the project manager nor
anyone else in the organization has ever done a project like the new one but the
executives still want accurate cost and duration estimates.

In such cases, analogous estimation is the best solution. It may not be perfect but is
accurate as it is based on past data. Analogous estimation is an easy-to-implement
technique. The project success rate can be up to 60% as compared to the initial
estimates.

Different Types of Analogous Estimation Techniques

Analogous estimating provides four types of estimates:

1. Single Point Estimate
2. Ratio Estimate
3. Estimate Range
4. Three-Point Estimate
1. Single Point Estimate

This estimate is also known as an absolute estimate. In this estimate, the estimation
result provides a single absolute value.

For example, you find a past similar project with a value of 250,000 USD, and your
project is similar to this one in size and technicalities, so the analogous estimate for
your project would be 250,000 USD.
2. Ratio Estimate

Using this method of estimating, you can apply data from previous projects to the one
you are working on now. The cost of a project is said to be linear to one or more of its
deliverables when using this methodology. For instance, the cost of the materials and
equipment used in a construction project accounts for only half of the total estimated
project cost.

As an illustration, you might say that the current project will cost approximately 200%
more than the project that came before it.

This approach considers a linear relationship between the various facets or between a
complete facet and the overall project.

3. Estimate Range

In place of a single estimate, the results of a range estimate are presented as a range of
possible values. The three-point estimate is a common method that indicates the range
of the estimate.

Analogous estimates are not accurate. To increase the likelihood of accurately

determining the project’s total cost, the estimator needs to provide the value that is most
likely to occur and the complete spectrum of all values that could occur.

Because there is limited visibility in the early stages of an adaptive or agile project, this
method is primarily used to manage those projects. For example, a project team offers
the following ranges for the costs of a new graphic interface: three to eight resource
months and 150,000 USD to 320,000 USD.

4. Three-Point Estimate

Here, you use three different estimates and then PERT or triangular estimate to arrive at
a single estimate.
These three estimates are
1. Optimistic Estimate
2. Most Likely Estimate
3. Pessimistic Estimate

Optimistic Estimate (O)

It is the estimate based on the best-case scenario for the activity.

Pessimistic Estimate (P) –

It is the estimate based on the worst-case scenario for the activity.

Most Likely Estimate (M) –

It is the most realistic estimate based on the resources likely to be assigned,

dependencies on other participants, possible problems that may arise, etc.

The final Three-Point estimate is calculated by calculating the average of the above 3
estimates. Now, the average can be a simple average or a Weighted average.

The Estimate that uses Simple average is called the Triangular Distribution, on the
other hand

The Estimate that uses Weighted is called the Beta Distribution.

The formula for Simple Average or Triangular Distribution is

E = ( P + O + M )/3

The formula for Weighted Average or Beta Distribution is

E = ( P + O +4 M )/6

The concept of the three-point estimating originated from the Program Evaluation and
Review Technique (PERT), which uses 3 estimates to define an approximate time
duration for an activity. PERT uses weighted average.

Analogous Estimation Requirements

For analogous estimation following is the requirement −

● Data from previous and on-going projects

○ Work hours per week of each team member
○ Costs involved to get the project completed
● Project close to the current project
● In case the current Project is new, and no past project is similar
 ○ Modules from past projects that are similar to those in current
project
○ Activities from past projects that are similar to those in current
project
○ Data from these selected ones
● Participation of the project manager and estimation team to ensure
experienced judgment on the estimates.

Analogous Estimation Steps

The project manager and team have to collectively do analogous estimation.

● Step 1 − Identify the domain of the current project.

● Step 2 − Identify the technology of the current project.
● Step 3 − Look in the organization database if a similar project data is
available. If available, go to Step (4). Otherwise go to Step (6).
● Step 4 − Compare the current project with the identified past project data.
● Step 5 − Arrive at the duration and cost estimates of the current project.
This ends analogous estimation of the project.
● Step 6 − Look in the organization database if any past projects have
similar modules as those in the current project.
● Step 7 − Look in the organization database if any past projects have
similar activities as those in the current project.
● Step 8 − Collect all those and use expert judgment to arrive at the duration
and cost estimates of the current project.

Advantages of Analogous Estimation

● Analogous estimation is a better way of estimation in the initial stages of

the project when very few details are known.
● The technique is simple and time taken for estimation is very less.
● Organization’s success rate can be expected to be high since the
technique is based on the organization’s past project data.
 ● Analogous estimation can be used to estimate the effort and duration of
individual tasks too. Hence, in WBS when you estimate the tasks, you can
use Analogy.

Disadvantages of analogous estimating

The few downsides of analogous estimating include:

● Because it functions at a basic level, analogous estimating is not as accurate as

other project estimation techniques.
● When using analogous estimation, project managers assume that various factors
of a similar past project will remain the same for the current project. Because
variables such as resources and inflation rates change constantly, the figures
managers use in their estimation might not be accurate.
● Analogous estimation is more appropriate for the initial planning stages of a
project than the executing stages.

Examples of analogous estimating

Here are a few examples of analogous estimating to understand how you might use it in
your project planning:

Example 1

Tina has recently been promoted as the project head of an advertising agency and must
present an upcoming project's cost and duration to a client. While she has not worked
on this type of account before, the agency has completed similar campaigns in the past.
She uses analogous estimation to assess the project's requirements according to past
data. She adjusts some variables to account for differences between projects and uses
the resulting data in her presentation.

Example 2
Tina's advertising agency is bidding on two different commercial campaigns. One is a
digital campaign for a new resort in town, and the other is for a dating website. The
agency has done a digital advert campaign for a new township in the past, so they
collect data from that campaign. The agency is better equipped to make an initial
estimation for this project based on analogous estimating than the dating website
campaign for which they do not have relevant past data available.

5. Parametric estimation methods

Parametric estimation methods use a model or algorithm that takes as input some
aspects of the project (such as the required functionality and the quality that is
expected). The model (a formula) or algorithm (computational steps) then produce an
estimate based on those inputs alone. The advantage of using parametric estimation
methods is that they tend to be more objective as their counterparts. When properly
used and with sufficient calibration these methods can produce highly reliable
estimates. Unfortunately their use is more complex and often more time-consuming
than the other estimation methods. Function Point Analysis is one of the most
commonly used methods. Cocomo is another.

The parametric estimating formula looks like this:

E_parametric = A_old / P old x P curr,

where,

E_parametric = parametric estimate

A_old = historical amount of cost or time

P_old = historical value of the parameter

P_curr = value of the parameter in the current project

the parametric estimation can be of two types:

 1. Deterministic
2. Probabilistic
Deterministic Estimates

Here, you get a single cost and duration estimate. Based on the experience, you can
adjust the estimate to include inflation and contingency reserve.
Probabilistic Estimates

Here, you get three estimates, as shown in the probability density curve in the below
chart.

(A sample chart showing the probability density function of a parametric estimation.)

This method provides more practical results. The three estimates are as follows:
● Most Likely Estimate: This is the most like estimate of the duration or costs an
activity will take to complete.
● Pessimistic Estimate: This is the worst-case scenario for an activity to complete
● Optimistic Estimate: This is the best-case scenario for an activity to complete.
Parametric Estimation Features

● Rigorous data is required for analogous estimation.

● Mathematical equations based on expertise, research, and industry-specific
historical data, e.g., cost per square meter in construction projects.
● Statistical relationships between historical data and other variables (e.g., square
meters in construction) are used to calculate the estimate.
● Estimations through parametric estimation techniques are better documented.

How to Improve Parametric Estimation

For better estimation, ensure the followings:

● Historical Data: When doing parametric estimation, historical data is an
extremely important factor. If the historical data are either inaccurate or out of
date, the estimation will not produce the result that is desired. To get a better
result, you should get the historical data, add the inflation factor, and make
adjustments according to the current market conditions.
● Parameter: Identify the correct parameter for your estimation. For example, the
cost of painting per square foot, labor rate, etc.
● Risk & Inflation: Every project is unique; a risk in a previous project cannot be
the risk for your project. Identify key risks for your project and factor them into the
cost. Consider the inflation if the historical data is older than two years.

Advantages of the Parametric Estimation Technique

● More accurate and reliable than analogous estimates and simple to perform.
● Very useful accurate data is available.
● Supported by senior management because of its accuracy.
● Estimates can be used for one project and replicated for other projects.
● Estimators trust this method and can calculate the capacity of labor or equipment
according to the organizational environment.
Disadvantages of the Parametric Estimation Technique
 ● It requires time, effort, and cost.
● There must be similarities among projects and tasks to benchmark and produce
estimates.
● It is difficult to account for environmental, political, and cultural differences.
● Estimating every cost or project event based on parametric benchmarks is
difficult.
Parametric Estimation Vs Analogous Estimation

Although different mechanisms are used, both approaches to estimation use historical
data.

To solve the parametric equation, the project manager will first break the overall project
down into its component parts, then look up the unit cost from the project that came
before it, and finally use this information to estimate the cost of the current project. This
is a time-consuming mathematical process that ultimately yields results that are
accurate enough.

In the analogous estimation, the project manager will find a similar project, and based
on an educated guess; he will find the project’s cost on hand. The estimates obtained
from this method are rough order of magnitude with an accuracy range -of 25% to 75%.

When you need a quick estimation, you will use the analogous method, and accuracy is
not the prime concern.

Cocomo (Constructive Cost Model)

Cocomo (Constructive Cost Model) is a regression model based on LOC, i.e number of
Lines of Code. It is a procedural cost estimate model for software projects and is often
used as a process of reliably predicting the various parameters associated with making
a project such as size, effort, cost, time, and quality. It was proposed by Barry Boehm in
1981 and is based on the study of 63 projects, which makes it one of the
best-documented models. The key parameters which define the quality of any software
products, which are also an outcome of the Cocomo are primarily Effort & Schedule:
 ● Effort: Amount of labor that will be required to complete a task. It is measured in
person-months units.

● Schedule: Simply means the amount of time required for the completion of the
job, which is, of course, proportional to the effort put in. It is measured in the units
of time such as weeks, months.

Different models of Cocomo have been proposed to predict the cost estimation at
different levels, based on the amount of accuracy and correctness required. All of these
models can be applied to a variety of projects, whose characteristics determine the
value of constant to be used in subsequent calculations. These characteristics
pertaining to different system types are mentioned below. Boehm’s definition of organic,
semidetached, and embedded systems:

● Organic – A software project is said to be an organic type if the team size

required is adequately small, the problem is well understood and has been
solved in the past and also the team members have a nominal experience
regarding the problem. Some of the projects that can be organic are- small data
processing systems, basic inventory management systems, business systems.

● Semi-detached – A software project is said to be a Semi-detached type if the

vital characteristics such as team size, experience, knowledge of the various
programming environment lie in between that of organic and Embedded. The
projects classified as Semi-Detached are comparatively less familiar and difficult
to develop compared to the organic ones and require more experience and better
guidance and creativity. The problems faced in this project are a few known and
a few unknown, which have never been faced before. Few such projects are-
Database Management System(DBMS), new unknown operating system, difficult
inventory management system. Eg: Compilers or different Embedded Systems
can be considered of Semi-Detached type.

● Embedded – A software project requiring the highest level of complexity,

creativity, and experience requirement fall under this category. Such software
requires a larger team size than the other two models and also the developers
 need to be sufficiently experienced and creative to develop such complex
models. Such projects include- air traffic models, ATMs, complex banking
systems, etc.

Types of COCOMO Model

The different types of COCOMO models define the depth of cost estimation is required
for the project. It depends on the software manager, what type of model do they choose.

According to Boehm, the estimation should be divided into 3 stages-

1. Basic COCOMO Model

2. Intermediate COCOMO Model

3. Detailed COCOMO Model

● Basic COCOMO Model

It is the one type of static model to estimates software development effort quickly
and roughly. It mainly deals with the number of lines of code and the level of
estimation accuracy is less as we don’t consider the all parameters belongs to
the project. The estimated effort and scheduled time for the project are given by
the relation:

Effort (E) = a*(KLOC)^b MM

Scheduled Time (D) = c*(E)^d Months(M)
Where,
● E = Total effort required for the project in Man-Months (MM).
● D = Total time required for project development in Months (M).
● KLOC = the size of the code for the project in Kilo lines of code.
● a, b, c, d = The constant parameters for a software project.

Estimation of development effort

For the three classes of software products, the formulas for estimating the effort based
on the code size are shown below:

Organic: Effort = 2.4(KLOC)^ 1.05 PM

Semi-detached: Effort = 3.0(KLOC) ^1.12 PM

Embedded: Effort = 3.6(KLOC) ^1.20 PM

Estimation of development time

For the three classes of software products, the formulas for estimating the development
time based on the effort are given below:

Organic: Tdev = 2.5(Effort)^ 0.38 Months

Semi-detached: Tdev = 2.5(Effort)^ 0.35 Months

Embedded: Tdev = 2.5(Effort)^ 0.32 Months

Some insight into the basic COCOMO model can be obtained by plotting the estimated
characteristics for different software sizes. Fig shows a plot of estimated effort versus
product size. From fig, we can observe that the effort is somewhat superliner in the size
of the software product. Thus, the effort required to develop a product increases very
rapidly with project size.
The development time versus the product size in KLOC is plotted in fig. From fig it can
be observed that the development time is a sub linear function of the size of the
product, i.e. when the size of the product increases by two times, the time to develop
the product does not double but rises moderately. This can be explained by the fact that
for larger products, a larger number of activities which can be carried out concurrently
can be identified. The parallel activities can be carried out simultaneously by the
engineers. This reduces the time to complete the project. Further, from fig, it can be
observed that the development time is roughly the same for all three categories of
products. For example, a 60 KLOC program can be developed in approximately 18
months, regardless of whether it is of organic, semidetached, or embedded type.
From the effort estimation, the project cost can be obtained by multiplying the required
effort by the manpower cost per month. But, implicit in this project cost computation is
the assumption that the entire project cost is incurred on account of the manpower cost
alone. In addition to manpower cost, a project would incur costs due to hardware and
software required for the project and the company overheads for administration, office
space, etc.

It is important to note that the effort and the duration estimations obtained using the
COCOMO model are called a nominal effort estimate and nominal duration estimate.
The term nominal implies that if anyone tries to complete the project in a time shorter
than the estimated duration, then the cost will increase drastically. But, if anyone
completes the project over a longer period of time than the estimated, then there is
almost no decrease in the estimated cost value.

Example: For a given project was estimated with a size of 300 KLOC. Calculate the
Effort, Scheduled time for development. Also, calculate the Average resource size and
Productivity of the software for Organic project type.
Ans: Given estimated size of project is: 300 KLOC
For Organic

Effort (E) = a*(KLOC)^b = 2.4*(300)^1.05 = 957.61 MM

Scheduled Time (D) = c*(E)^d = 2.5*(957.61)^0.38 = 33.95 Months(M)
Avg. Resource Size = E/D = 957.61/33.95 = 28.21 Mans
Productivity of Software = KLOC/E = 300/957.61 = 0.3132 KLOC/MM = 313 LOC/MM
For Semidetached

Effort (E) = a*(KLOC)^b = 3.0*(300)^1.12 = 1784.42 MM

Scheduled Time (D) = c*(E)^d = 2.5*(1784.42)^0.35 = 34.35 Months(M)

For Embedded

Effort (E) = a*(KLOC)^b = 3.6*(300)^1.2 = 3379.46 MM

Scheduled Time (D) = c*(E)^d = 2.5*(3379.46)^0.32 = 33.66 Months(M)

Example1: Suppose a project was estimated to be 400 KLOC. Calculate the effort and
development time for each of the three model i.e., organic, semi-detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC)^ a2 PM
 Tdev=b1*(efforts)^b2 Months

Estimated Size of project= 400 KLOC

(i)Organic Mode

E = 2.4 * (400)^1.05 = 1295.31 PM

D = 2.5 * (1295.31)^0.38=38.07 PM

(ii)Semidetached Mode

E = 3.0 * (400)^1.12=2462.79 PM

D = 2.5 * (2462.79)^0.35=38.45 PM

(iii) Embedded Mode

E = 3.6 * (400)^1.20 = 4772.81 PM

D = 2.5 * (4772.8)^0.32 = 38 PM

Example2: A project size of 200 KLOC is to be developed. Software development team

has average experience on similar type of projects. The project schedule is not very
tight. Calculate the Effort, development time, average staff size, and productivity of the
project.

Solution: The semidetached mode is the most appropriate mode, keeping in view the
size, schedule and experience of development time.

Hence E=3.0(200)^1.12=1133.12PM

D=2.5(1133.12)^0.35=29.3PM
 P = 176 LOC/PM

● Intermediate Model – The basic Cocomo model assumes that the effort is only a
function of the number of lines of code and some constants evaluated according to the
different software systems. However, in reality, no system’s effort and schedule can be
solely calculated on the basis of Lines of Code. For that, various other factors such as
reliability, experience, Capability. These factors are known as Cost Drivers and the
Intermediate Model utilizes 15 such drivers for cost estimation.

The intermediate model estimates software development effort in terms of size of the
program and other related cost drivers parameters (product parameter, hardware
parameter, resource parameter, and project parameter) of the project. The estimated
effort and scheduled time are given by the relationship:

Effort (E) = a*(KLOC)^b *EAF MM

Scheduled Time (D) = c*(E)^d Months(M)

Where,
● E = Total effort required for the project in Man-Months (MM).
● D = Total time required for project development in Months (M).
● KLOC = The size of the code for the project in Kilo lines of code.
● a, b, c, d = The constant parameters for the software project.

EAF = It is an Effort Adjustment Factor, which is calculated by multiplying the parameter

values of different cost driver parameters. For ideal, the value is 1.

Classification of Cost Drivers and their attributes:

 1. Product attributes
○ size of the application’s database
○ the complexity of the product
○ software’s reliability extent

2. Hardware attributes
○ Total turnabout time
○ Memory constraints
○ Run-time performance constraints

3. Project attributes
○ software tools used
○ required development schedule

4. Personnel attributes
○ Applications experience
○ Coding experience
○ Software developer’s capability
○ Analyst experience

The cost drivers are divided into four categories

Intermediate COCOMO equation:

E=ai (KLOC)^bi*EAF

D=ci (E)^di

The values of a and b in the case of the intermediate model are as follows:
 Example: For a given project was estimated with a size of 300 KLOC. Calculate the
Effort, Scheduled time for development by considering the developer having high
application experience and very low experience in programming.

Solution –

Given the estimated size of the project is: 300 KLOC

Developer having highly application experience: 0.82 (as per above table)

Developer having very low experience in programming: 1.14(as per above table)

EAF = 0.821.14 = 0.9348 Effort (E) = a(KLOC)b EAF = 3.0(300)1.12 0.9348 = 1668.07
MM

Scheduled Time (D) = c(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M)

● Detailed Model –

The model incorporates all qualities of both Basic COCOMO and Intermediate
COCOMO strategies on each software engineering process. The model accounts
for the influence of the individual development phase (analysis, design, etc.) of
the project.it uses multipliers for each phase of the project .it is a complex
mode.it includes more factors that influence the software projects and give more
accurate estimations. In this, the whole software is divided into different modules
and then we apply COCOMO in different modules to estimate effort and then
sum the effort. For instance, detailed COCOMO will perform cost estimation in
each development phase of the Waterfall Model-

Detailed COCOMO incorporates all characteristics of the intermediate version with an

assessment of the cost driver’s impact on each step of the software engineering
process. The detailed model uses different effort multipliers for each cost driver
attribute. In detailed cocomo, the whole software is divided into different modules and
then we apply COCOMO in different modules to estimate effort and then sum the effort.
The Six phases of detailed COCOMO are:

● Planning and requirements

 ● System design
● Detailed design
● Module code and test
● Integration and test
● Cost Constructive model

The detailed model introduces two more capabilities that are as follows:
Phase-sensitive effort multiplier:
Some phases (like design, programming, integration/test) are more affected than others
by factors defined by the cost drivers. The detailed model provides a set of
phase-sensitive effort multipliers for each cost driver. This helps in determining the
workforce allocation for each phase of the project.

Three-level product hierarchy:

In the three-level product hierarchy, there are a module, subsystem, and system levels.
The ratings of the cost driver are done at an appropriate level, i.e., the level at which it is
most affected by the variation.

Advantages and Disadvantages of COCOMO Model

Following are some advantages and disadvantages of the COCOMO model.

Advantages

● Easy to estimate the total cost of the project.

● Easy to implement with various factors.
● Provide ideas about historical projects.
● COCOMO is transparent, one 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.
● COCOMO Provides ideas about historical projects.
● The COCOMO model is easy to estimate the total cost of the project.
 ● The drivers are very helpful to understand the impact of the different factors that
affect project crises.

Disadvantages

● It ignores requirements, customer skills, and hardware issues.

● It limits the accuracy of the software costs.
● It mostly depends on time factors.
● It is hard to estimate KDSI ( Delivery source instructions in thousands) early on in
the project when most effort estimates are required.
● KDSI, actually, is not a size measure, it is a length measurement.
● 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.
● It limits the accuracy of software costs.
● It also ignores customer skills, cooperation, and knowledge.

Function Point Analysis

Function Point Analysis was initially developed by Allan J. Albercht in 1979 at IBM and it
has been further modified by the International Function Point Users Group (IFPUG).

The initial Definition is given by Allan J. Albrecht:

FPA gives a dimensionless number defined in function points which we have found to
be an effective relative measure of function value delivered to our customer.

FPA provides a standardized method to functionally size the software work product.
This work product is the output of software new development and improvement projects
for subsequent releases. It is the software that is relocated to the production application
at project implementation. It measures functionality from the user’s point of view i.e. on
the basis of what the user requests and receives in return.
 Function Point Analysis (FPA) is a method or set of rules of Functional Size
Measurement. It assesses the functionality delivered to its users, based on the user’s
external view of the functional requirements. It measures the logical view of an
application, not the physically implemented view or the internal technical view.

The Function Point Analysis technique is used to analyze the functionality delivered by
software and Unadjusted Function Point (UFP) is the unit of measurement.

Objectives of FPA:

● The objective of FPA is to measure the functionality that the user requests and
receives.

● The objective of FPA is to measure software development and maintenance

independently of the technology used for implementation.

● It should be simple enough to minimize the overhead of the measurement

process.

● It should be a consistent measure among various projects and organizations.

Types of FPA:

● Transactional Functional Type –

○ External Input (EI): EI processes data or control information that comes

from outside the application’s boundary. The EI is an elementary process.

○ External Output (EO): EO is an elementary process that generates data or

control information sent outside the application’s boundary.

○ External Inquiries (EQ): EQ is an elementary process made up of an

input-output combination that results in data retrieval.

● Data Functional Type –

 ○ Internal Logical File (ILF): A user identifiable group of logically related data
or control information maintained within the boundary of the application.

○ External Interface File (EIF): A group of users recognizable logically

related data allusion to the software but maintained within the boundary of
another software.

COCOMO II Model

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.

It consists of three sub-models:

1. End User Programming:

Application generators are used in this sub-model. End user write the code by using
these application generators.

Example – Spreadsheets, report generator, etc.

2. Intermediate Sector:
 ● (a). Application Generators and Composition Aids –
This category will create largely prepackaged capabilities for user programming.
Their product will have many reusable components. Typical firms operating in
this sector are Microsoft, Lotus,
Oracle, IBM, Borland, Novell.

● (b). Application Composition Sector –

This category is too diversified and to be handled by prepackaged solutions. It
includes GUI, Databases, domain specific components such as financial, medical
or industrial process control packages.

● (c). System Integration –

This category deals with large scale and highly embedded systems.

3. Infrastructure Sector:

This category provides infrastructure for the software development like Operating
System, Database Management System, User Interface Management System,
Networking System, etc.

Stages of COCOMO II:

1. Stage-I:
It supports estimation of prototyping. For this it uses Application Composition
Estimation Model. This model is used for the prototyping stage of application
generator and system integration.

2. Stage-II:
It supports estimation in the early design stage of the project, when we less know
about it. For this it uses Early Design Estimation Model. This model is used in
early design stage of application generators, infrastructure, system integration.

3. Stage-III:
It supports estimation in the post architecture stage of a project. For this it uses
Post Architecture Estimation Model. This model is used after the completion of
the detailed architecture of application generator, infrastructure, system
integration.
Difference between COCOMO 1 and COCOMO 2