Size Estimation Metrics

Planning
Project management activities can be viewed as having three major phases:

1. project planning

2. project monitoring and control

3. Project termination

 Because estimation lays a foundation for all other project planning activities
and project planning provides the road map for successful software
engineering.

 Estimation of resources, cost, and schedule for a software engineering

effort requires experience, access to good historical information,
 Factors Affecting the Estimation Process
 Project Complexity: The complexity of the software is more when first version
of the software is developed. Complexity, however, is a relative measure that
is affected by familiarity with past effort.

 Project size: As size increases, the interdependency among various

elements of the software grows rapidly.

 The availability of historical information has a strong influence on

estimation risk.

 Risk is measured by the degree of uncertainty in the quantitative estimates

established for resources, cost, and schedule
 Project Planning Objectives: The objective of software project planning
is to provide a framework that enables the manager to make reasonable
estimates of resources, cost, and schedule. The planning objective is
achieved through a process of information discovery that leads to
reasonable estimates.

 SOFTWARE SCOPE: describes the data and control to be processed,

function, performance, constraints, interfaces, and reliability.
 Functions described in the statement of scope are evaluated and in some cases refined

to provide more detail prior to the beginning of estimation. Because both cost and
schedule estimates are functionally oriented, some degree of decomposition is often
useful.

 Performance considerations encompass processing and response time requirements.

 Constraints identify limits placed on the software by external hardware, available

memory, or other existing systems.

 1. Getting Necessary Information for Scope
The very basic way to get the inforamtion is the interaction between the customer
and the Developer. E.g. some basic questions may be:
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution?
The next set of questions may be;
 How would you (the customer) characterize "good" output that would be
generated by a successful solution?
 What problem will this solution address?
 Can you show me the environment in which the solution will be used?
 Will any special performance issues or constraints affect the way the
solution is approached?
 1. Getting Necessary Information for Scope contd..
The next level of the questions may be:

•Are you the right person to answer these questions? Are answers "official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
This kind of Q&A activity is to be done only to break the ice, then be replaced
by a meeting format that combines elements of problem solving, negotiation,
and specification.
Normally there is problem of cooperation between the customer and the
developer. To overcome these kind of problems, team oriented approach can be
used called, facilitated application specification techniques (FAST).
 2. Feasibility
The next important question is:

Can we build software to meet this scope? Is the project feasible?

Once scope is understood, the software team and others must work to

determine if it can be done within the dimensions just noted. This is a

crucial, although often overlooked, part of the estimation process.

 RESOURCES
The second software planning task

is estimation of the resources required

to accomplish the software

development effort.

 The development environment—hardware

and software tools—sits at the foundation of the resources pyramid and

provides the infrastructure to support the development effort.

 Next, we encounter reusable software components— software building

blocks that can dramatically reduce development costs and accelerate
delivery.

 At the top of the pyramid is the primary resource—people.

 RESOURCES
Each Resource is specified with four characteristics:

 Description of the resource.

 A statement of availability.

 Time when the resource will be required.

 Duration of time that resource will be applied.

 RESOURCES
1. Human Resources: The planner will start planning by selecting the
people with different skills, But for relatively small projects a single
individual may performall software engineering tasks, consulting with
specialists as required.

2. Reusable Software Resources: Component-based software engineering

emphasizes reusability—that is, the creation and reuse of software
building blocks.
 Off-the-shelf components: Existing software that can be acquired from a third
party or that has been developed internally for a past project

 Full-experience components: developed for past projects that are similar to the

software to be built for the current project.

 Partial-experience components: developed for past projects that are related to the software to
be built for the current project but will require substantial modification.

 New components; Software components that must be built by the software team specifically for
the needs of the current project
 RESOURCES

3. Environmental Resources: The environment that supports the software

project, often called the software engineering environment (SEE),
incorporates hardware and software. a project planner must prescribe
the time window required for hardware and software and verify that
these resources will be available.
Software Metrics

“Software metrics are quantifiable

measures that could be used to measure
different characteristics of a software or
the software development process.”
Why?
Software size is critical factor for determining
—
¡

Cost
¡ Schedule
¡ Effort
Software Estimation
—It is a part of Software project planning process.
—Used to determine how much software to build.
—Generally we estimate size too low.
¡ Results:
÷ Insufficient
funding.
÷ Less time for development
Key to software sizing..

•To use a variety of software sizing techniques

• Not to rely on a single source or method for the estimate.

•Because it affects program cost and may lead to risks.

Common types of size inaccuracies
 The earlier the estimate is made — the less is known about the software
to be developed —and the greater the estimating errors.

 —
Base your estimates on the smallest possible unit of each component

 Given our shortcomings in size estimation, it is absolutely critical that

you measure, track, and control software size throughout development.

 —
Analysis is necessary to determine trends in software size and
functionality progress
Software Measurement
 Measurements can be categorized in two ways
 Direct measures of the product include lines of code (LOC)
produced, execution speed, memory size, and defects
reported over some set period of time.
 Indirect measures of the product include functionality,
quality, complexity, efficiency, reliability, maintainability,
and many other "–abilities"
Software Measurement(Con.)
 Easy (Direct)
 The cost and effort required to build software,
 The number of LOC(lines of code) produced etc. etc .
 Difficult (Indirect)
 The quality and functionality of software
 Efficiency or maintainability
Size Oriented Metrics
 In order to develop metrics that can be assimilated
with similar metrics from other projects, we choose
lines of code as our normalization value.
 a set of simple size-oriented metrics can be developed
by considering
 Errors per KLOC (thousand lines of code).
 Defects per KLOC.
4

 $ per LOC.
 Page of documentation per KLOC.
 Other metrics
 Errors per person-month.
 LOC per person-month.
 $ per page of documentation.