ZeePedia

Decomposition Techniques, Estimation – Tools

<< Estimation - Concepts
Estimation – Tools >>
img
Software Project Management (CS615)
LECTURE # 30
6. ESTIMATION
6.3
Decomposition Techniques
Software project estimation is a form of problem solving, and in most cases, the
problem to be solved (i.e., developing a cost and effort estimate for a software
project) is too complex to be considered in one piece. For this reason, we
decompose the problem, re-characterizing it as a set of smaller (and hopefully,
more manageable) problems.
Before an estimate can be made, the project planner must understand the scope of
the software to be built and generate an estimate of its "size."
6.3.1
Software Sizing
The accuracy of a software project estimate is predicated on a number of things:
(1) The degree to which the planner has properly estimated the size of the product
to be built
(2) The ability to translate the size estimate into human effort, calendar time, and
dollars (a function of the availability of reliable software metrics from past
projects)
(3) The degree to which the project plan reflects the abilities of the software team
(4) The stability of product requirements and the environment that supports the
software engineering effort.
As project estimate is only as good as the estimate of the size of the work to be
accomplished, sizing represents the project planner's first major challenge.
In the context of project planning, size refers to a quantifiable outcome of the
software project. If a direct approach is taken, size can be measured in LOC. If an
indirect approach is chosen, size is represented as FP.
There are four different approaches to the sizing problem:
1. "Fuzzy logic" sizing: This approach uses the approximate reasoning
techniques that are the cornerstone of fuzzy logic. To apply this approach, the
planner must identify the type of application, establish its magnitude on a
qualitative scale, and then refine the magnitude within the original range.
Although personal experience can be used, the planner should also have
226
img
Software Project Management (CS615)
access to a historical database of projects8 so that estimates can be com- pared
to actual experience.
2. Function point sizing: The planner develops estimates of the information
domain. Its characteristics will be discussed later in the session.
3. Standard component sizing: Software is composed of a number of different
"standard components" that are generic to a particular application area. For
example, the standard components for an information system are subsystems,
modules, screens, reports, interactive programs, batch programs, files, LOC,
and object-level instructions. The project planner estimates the number of
occurrences of each standard component and then uses historical project data
to determine the delivered size per standard component. To illustrate, consider
an information systems application. The planner estimates that 18 reports will
be generated. Historical data indicates that 967 lines of COBOL [PUT92) are
required per report. This enables the planner to estimate that 17,000 LOC will
be required for the reports component. Similar estimates and computation are
made for other standard components, and a combined size value (adjusted
statistically) results.
4. Change sizing: This approach is used when a project encompasses the use of
existing software that must be modified in some way as part of a project. The
planner estimates the number and type (e.g., reuse, adding code, changing
code, and deleting code) of modifications that must be accomplished. Using
an "effort ratio" [PUT92) for each type of change, the size of the change may
be estimated.
6.4
Estimation ­ Tools
i.
Work Breakdown Structure (WBS)
a) Dividing into Logical Units/Tasks
To correctly estimate the effort, size, or cost of completing a project, it is
important to be aware of the multiple tasks that comprise a project. You can
divide a project into logical units or tasks by using the WBS technique.
Creating a WBS is a prerequisite for any estimation activity. It enables you to
conceptualize an abstract entity, such as a project, into distinct, independent units.
After dividing a project into tasks, you can categorize them as logical, broad
tasks. For example, tasks, such as drawing up a marketing strategy, planning a
phase-wise product release, and interacting with media agencies and the
production department can be compiled under a common category, Marketing.
b) Benefits of Using a WBS
227
img
Software Project Management (CS615)
Using a WBS provides a number of benefits to the management and to the
development teams.
First, it gives the management an idea about the size and complexity of the
project.
Second, it helps in planning, scheduling, and monitoring a project realistically.
This is possible because all the tasks in the project can be preformed measurable
targets for each task.
To aid planning, scheduling, and monitoring a project, you can use tools such as:
­
Program Evaluation and Review Techniques (PERT)
­
Critical Path Method (CPM)
­
Timeline charts
­
Gantt charts
These tools use WBS as the fundamental basis for assessing resources to tasks,
computing the number of days needed, and the cost required to complete the
tasks.
ii.
Measuring Effort for a Project
Measuring the effort for a project is a specialized activity. It enables you to derive
cost estimates that are critical for project management. An incorrect measurement
of effort at the beginning of project can result in inaccurate project plans and
frequent slippages. It can also lead to inaccurate cost estimates, which can cause
steep cost deviations between estimated and actual cost values.
There are many techniques that you can use to accurately estimate effort, such as:
a) Source lines of Code (SLOC)
b) Function Point (FP)
c) Constructive Cost Model (COCOMO)
These are quantitative estimation techniques because they rely on the use of
formulae to calculate effort.
In addition to quantitative estimation techniques, there is a human-based
technique known as:
d) Delphi technique
This technique is based on soft skills and relies more on human factors, such as
collecting information during group discussions.
228
img
Software Project Management (CS615)
a) SLOC- Technique
At the beginning of a software project, it is important to determine the size of the
project. The project size helps determine the resources, effort, and duration of the
project.
There are many techniques to calculate the size of a software project. You can
calculate the size by using a directly measurable technique, the SLOC technique.
It is defined as the source lines of code that are delivered as part of the product.
The effort spent on creating the source lines of code is expressed in relation to
thousand lines of code (KLOC).
The SLOC technique is an objective method of estimating the size because there
are no multiple ways of calculating the lines of code. Therefore, the effort
estimate is close to being accurate.
This technique includes the calculation of lines of code, documentation of pages,
inputs, outputs, and components of a software program. Components are again of
multiple types, such as reports, screens, and files.
The SLOC technique is also used to directly calculate the effort to be spent on a
project.
Following figure is a simple example of counting source lines of code. The code
displayed here contains four lines of code.
If (emp_code<=1200)
Print ("Welcome to the Inventory database.");
Else
Print ("Access denied to the Inventory databases.");
­ Counting SLOC
You can use the SLOC technique to estimate the effort required for a project
when the programming language and the technology to be used are predefined. In
addition to the programming language and technology, the complexity and effort
required to write a program should be easily predictable.
The use of the SLOC technique requires that the technology or language remain
unchanged throughout the project. Generally, you can use the SLOC technique
when you are using third-generation languages, such as FORTRAN or COBOL.
While counting the source lines of code, there are some general considerations
that you need to keep in mind. However, these can vary in every organization.
229
img
Software Project Management (CS615)
The general considerations include the following:
·
Only the delivered lines of code are included in SLOC calculation. For
example, test drivers and other support software are not part of the number of
lines developed for a project.
·
Only the source lines of code written only by the development team as
counted. This excludes the code created by applications generators.
·
Only declaration statements are counted as source lines of code. This
excludes comments inserted to improve the readability of programs.
­ Disadvantages of Using SLOC
Despite being accurate in providing figures to calculate the effort required for a
project, the SLOC technique has a drawback.
The SLOC technique is language-dependent. The effort required to calculate
source lines of code may not be the same for all languages.
For example, to conceive and write 8 lines of code that accomplish a task in the
assembly language may require 15 minutes. However, you may need only five
minutes to complete the same lines of code if it is written in Visual Basic.
b) FP Technique
The FP technique is a direct indicator of the functionality of a software
application from the user's perspective. This is the most popular technique used to
estimate the size of a software project.
This fact is further supported by a quote of Capers Jones, chairman of Software
Productivity Research, Inc. in Burlington, Massachusetts, on page 1 of Computer
Finance brought out in November 1997. He quotes "80% of the Fortune 500, are
using function points, at least somewhere in their application development
organizations".
You use the FP technique to estimate the total size of a project. The total size of a
project is estimated as a single FP value. After calculating the total size of a
project in FP, you divide the total FP into the different phases of the SDLC. This
way, you can determine how much effort per FP is required in that particular
phase.
For example, the testing phase is planned for 20 FP of work. The project
managers, based on their past project experience, determine the amount of effort
in man/person months required in the testing phase.
230
img
Software Project Management (CS615)
Similarly, you can express the cost required to complete FP of work for a
particular phase. At the end of a project, you can also express the number of
defects reported in terms of per FP for a phase.
­ Features of Function Points
The total size of a software project is expressed in total function points. It is
independent of the computer language, development methodology, technology, or
capability of the project team developing the software project.
The specific user functionality of the application is evaluated in terms of relation
to what is delivered by the application and, not how it is delivered. Only user-
requested and user-defined components are counted. To calculate FP for a project,
some major components are required.
The major components and their relationships are represented in following figure.
Function Points
Unadjusted Data Function
Unadjusted Transaction
Points
Function Points
Internal Files
External Interfaces
User Inputs
User Outputs
User Inquiries
Figure: Function Points Components and their Relationship
You can calculate the function point estimates for a project or a particular phase
by following four steps:
1.
Identify the unadjusted function points.
2.
Calculate total GSC s.
3.
Calculate Value Adjustment Factor (VAF)
4.
Apply a formula to calculate Adjusted FP (AFP)
231
img
Software Project Management (CS615)
­ Advantages of Using Function Points
Function points are language-and technology-independent. Therefore, you can use
them to estimate any kind of project. They can also be used to estimate the effort,
cost, and schedules of projects that use the Prototyping and Spiral models because
such projects have uncertain user and project requirements.
In addition, you can use function points as a project estimation technique when
you anticipate changes in the middle of a project. These changes may disturb the
estimates if, you had used SLOC to estimate the effort, cost, or size of a project.
The FP estimation uses a subjective and holistic approach for project estimation.
Consequently, the estimates calculated by using the FP are unlikely to be
incorrect.
­ Disadvantages of Using Function Points
Estimation by using FP generally uses data from past projects for assigning
weights to GSC s and the information domain values. To be able to do this
realistically, it is important for the organization to have developed similar projects
in the past.
The organization should also be prepared with adequate data and tools for FP
estimation of the new project.
In addition, FP provides a vague estimation. This characteristic of FP does not
usually provide precise or approximate estimates of the effort, cost and size of a
project.
Consequently, at the end of a project, deviations from the estimated to the actual,
values of each of the factors maybe quite extreme.
232
Table of Contents:
  1. Introduction & Fundamentals
  2. Goals of Project management
  3. Project Dimensions, Software Development Lifecycle
  4. Cost Management, Project vs. Program Management, Project Success
  5. Project Management’s nine Knowledge Areas
  6. Team leader, Project Organization, Organizational structure
  7. Project Execution Fundamentals Tracking
  8. Organizational Issues and Project Management
  9. Managing Processes: Project Plan, Managing Quality, Project Execution, Project Initiation
  10. Project Execution: Product Implementation, Project Closedown
  11. Problems in Software Projects, Process- related Problems
  12. Product-related Problems, Technology-related problems
  13. Requirements Management, Requirements analysis
  14. Requirements Elicitation for Software
  15. The Software Requirements Specification
  16. Attributes of Software Design, Key Features of Design
  17. Software Configuration Management Vs Software Maintenance
  18. Quality Assurance Management, Quality Factors
  19. Software Quality Assurance Activities
  20. Software Process, PM Process Groups, Links, PM Phase interactions
  21. Initiating Process: Inputs, Outputs, Tools and Techniques
  22. Planning Process Tasks, Executing Process Tasks, Controlling Process Tasks
  23. Project Planning Objectives, Primary Planning Steps
  24. Tools and Techniques for SDP, Outputs from SDP, SDP Execution
  25. PLANNING: Elements of SDP
  26. Life cycle Models: Spiral Model, Statement of Requirement, Data Item Descriptions
  27. Organizational Systems
  28. ORGANIZATIONAL PLANNING, Organizational Management Tools
  29. Estimation - Concepts
  30. Decomposition Techniques, Estimation – Tools
  31. Estimation – Tools
  32. Work Breakdown Structure
  33. WBS- A Mandatory Management Tool
  34. Characteristics of a High-Quality WBS
  35. Work Breakdown Structure (WBS)
  36. WBS- Major Steps, WBS Implementation, high level WBS tasks
  37. Schedule: Scheduling Fundamentals
  38. Scheduling Tools: GANTT CHARTS, PERT, CPM
  39. Risk and Change Management: Risk Management Concepts
  40. Risk & Change Management Concepts
  41. Risk Management Process
  42. Quality Concept, Producing quality software, Quality Control
  43. Managing Tasks in Microsoft Project 2000
  44. Commissioning & Migration