The document discusses techniques for decomposing software projects to aid in cost estimation. It describes decomposing by problem or process. Process decomposition breaks down framework activities like communication. For complex projects, communication can be broken into smaller tasks. The document also discusses software sizing methods, empirical estimation models, and making buy versus build decisions. It outlines manual and automated cost estimation techniques from project-level to activity-level estimates.

1. SOFTWARE PROJECT
PLANNING AND COSTING
Software Cost Estimation
SE518
Lecture-3

2. Project Planning Components
• Software Scope
• Resources
• Project Estimation
• De-composition Techniques
• Empirical estimation models
• Make or Buy Decision
• Estimation Tools (Manual and Automated)

3. De-composition Techniques
Software project estimation is a form of problem solving.
If the problem is complex, it must be decomposed to
smaller problems.
Decomposition have two point of views
1. Decomposition of the problem
2. Decomposition of the process
In estimation we use one or both methods of partitioning

4. De-composition Techniques
Decomposition of the process
1. Framework selection (communication, planning etc)
2. How do we accomplish this framework activity?”
For example, a small, relatively simple project might require
the following work tasks for the communication activity:
• Develop list of clarification issues.
• Meet with stakeholders to address clarification issues.
• Jointly develop a statement of scope.
• Review the statement of scope with all concerned.
• Modify the statement of scope as required

5. De-composition Techniques
In case of complex project, the communication activities
can be broken down into
• Review the customer request.
• Plan and schedule a formal, facilitated meeting with all
stakeholders.
• Conduct research to specify the proposed solution and
existing approaches.
• Prepare a “working document” and an agenda for the
formal meeting.
• Conduct the meeting.

6. De-composition Techniques
• Jointly develop mini-specs that reflect data, functional,
and behavioral features of the software. Alternatively,
develop use cases that describe the software from the
user’s point of view.
• Review each mini-spec or use case for correctness,
consistency, and lack of ambiguity.
• Assemble the mini-specs into a scoping document.
• Review the scoping document or collection of use cases
with all concerned.
• Modify the scoping document or use cases as required.

7. De-composition Techniques
• Software project estimation prediction
Accuracy
of Project
Estimate
(Prediction)
Proper size
estimation
Ability to
translate
estimate into
effort, time &
money
Degree of
abilities of
software
team
Stability of
product
requirements

8. De-composition Techniques
• Software Sizing
• size refers to a quantifiable outcome of the software
project.
• size can be measured in lines of code (LOC).
• size can represented as function points (FP)

9. De-composition Techniques
• Software Sizing
• Analogy sizing (planner must identify type of
application & its magnitude on a qualitative scale)
• Divide the historical produce size data into size ranges.
• Compare the planned product with these prior products.
• Based on this comparison, select the size that seems most
appropriate for the new product.
• Function point sizing (information domain
characteristics), Function points are derived using an empirical
relationship based on countable (direct) measures of software’s
information domain (external inputs, external outputs, external
interface, internal logical files etc) and qualitative assessments
of software complexity.

10. De-composition Techniques
• Software Sizing
• Standard component sizing (generic components of a
particular application like every mis application have to input
data, reporting etc). Historical data may also be used.
• Change sizing (existing software modifications e.g addition,
modification, deletion etc.)
• User stories sizing
• It represent the relative sizing of the user story. It is a unit of
estimation used by Agile teams to estimate User Stories.
When the product owner wants some features to be
developed he/she desires to know how soon the team can
complete the features and how many resources it will take to
complete the work.

11. 11
Decomposition Techniques
• Process-based estimation
• decomposition based on tasks required to complete the software
process framework
• Problem-based estimation
• using lines of code (LOC) decomposition focuses on software
functions
• using function point (FP) decomposition focuses on information
domain characteristics

12. Empirical Estimation Models
• An estimation model for computer software uses
empirically derived formulas to predict effort as a function
of LOC.
• Structure of estimation model
E = A + B x (ev)C
Models
• Walston-Felix model
• Bailey-Basili model
• Boehm simple model
• Doty model for KLOC > 9

13. 13
Empirical Estimation Models
• Experiential Models
• Typically derived from regression analysis of
historical software project data with estimated
person-months as the dependent variable
• Static Estimation Model
• does not include time as an independent variable
• Constructive Cost Model (COCOMO)
• Dynamic Estimation Models
• usually takes time or development phase into
account
• Software Equation Model

14. 14
Make Buy Decision
• Based on Data
• It may be more cost effective to acquire a piece of
software rather than develop it.
• Decision tree analysis provides a systematic way
to sort through the make-buy decision.
• As a rule outsourcing software development
requires more skillful management than does in-
house development of the same product.

15. Make up or Buy Decision
• Software may be purchased (or licensed) off-the-shelf.
• “full experience” or “partial-experience” software
components may be acquired and then modified and
integrated to meet specific needs.
• Software may be custom built by an outside contractor to
meet the specifications.

16. Make up or Buy Decision
For expensive software products, the following guidelines
can be applied:
1. Develop specifications for function and performance of
the desired software.
2. Define measurable characteristics whenever possible.
3. Estimate the internal cost to develop and the delivery
date.
4. Select three or four candidate applications that best
meet your specifications. OR Select reusable software
components that will assist in constructing the required
application.

17. Make up or Buy Decision
4. Develop a comparison matrix that presents a head-to-
head comparison of key functions.
5. Alternatively, conduct benchmark tests to compare
candidate software.
6. Evaluate each software package or component based
on past product quality, vendor support, product
direction (identification and selection of implementation
strategy, execution) , reputation etc.
7. Contact other users of the software and ask for
opinions.

18. Make up or Buy Decision
Following points may also influence make/buy decision:
• Delivery time of both products.
• Will the cost of acquisition plus the cost of customization
be less than the cost of developing the software
internally?
• Will the cost of outside support (e.g., a maintenance
contract) be less than the cost of internal support?

19. 19
Decision Process
1. Develop specifications.
2. Estimate internal cost & delivery.
3. Select 3 or 4 candidate packages.
4. Select reasonable components.
5. Build a cost-benefit comparison matrix (key
function performance) or use conduct
benchmark tests of candidate software
6. Evaluate each software package or
component based on history with the
product or vendor.
7. Contact other users.

20. Cost Estimation Techniques
• Manual software Estimating Methods
• Manual Project Level Estimates using rules of thumb
• Manual Phase Level Estimates using ratios and percentages
• Manual Activity Level Estimates using work breakdown structure
• Automated Software Estimating Methods
• Automated Project Level Estimates using rules of thumb
• Automated Phase Level Estimates using ratios and percentages
• Automated Activity Level Estimates using work breakdown
structure

21. Cost Estimation Techniques
•The most accurate forms of software cost
estimation are the
•Manual activity-level estimates using
work-breakdown structures and
•Automated activity-level or task-level
estimates (micro-estimation) cost
estimating at either the activity or the task
level, and used for larger projects only.

22. Manual Project Level Estimates using
rules of thumb
• Oldest method
• Not accurate
• In use due to simplicity for smaller projects.
• Example
Examples of rules of thumb using the lines-of-code-metrics
might be “JAVA applications average 500 code statements
per staff month” or “JAVA applications cost an average of
Rs 1000 per line of code to develop.”

23. Manual Project Level Estimates using
rules of thumb
• Its simple method and easy to do.
• However, simplistic estimates using rules of thumb should
not serve as the basis of contracts or formal budgets for
software projects.
• Calendar months = (Function points) 0.4

24. Manual Phase Level Estimates using
ratios and percentages
• Its start with overall project level estimates
• Then ratios and percentages are assigned to various phases of
the project.
• Number of phases would run from five to eight
• Requirements gathering, analysis & design, coding, testing,
installation and training.
• Example
We are going to develop an application of 100 functional points
or having 10,000 LOC. Using rule of thumb from manual project
estimation, we assume that this project will average 500 code
statements per month. Then effort will take 20 months
10,000=500xmonths

25. Manual Phase Level Estimates using
ratios and percentages
• Typical effort percentages of five phases are
• Requirements 10%
• Analysis and design 20%
• Coding 30%
• Testing 30%
• Installation & training 5%

26. Manual Phase Level Estimates using
ratios and percentages
• Issues
• In real world, percentages vary widely for every activity on the basis
of type of projects
• Many kinds of software work span over multiple phases or run the
entire duration of the project like documentation
• Activities that are not phased, may accidently be omitted from the
estimates

27. Manual Phase Level Estimates using
ratios and percentages
• Issues
Example- 1: smaller projects coding is 60%, larger projects coding is
15-20%, however testing % may be increased.
Fix percentage can not be used
Example-2: week estimation of activities span over multiple phases
like documentation, starts during requirements phase and end after
testing
These must be considered
Example-3
Quality assurance, technical writing & integration are not identified as
phases. In complex projects it takes 25-30% effort.
That’s why most manual estimates tends towards excessive
optimism for both cost and schedule.

28. Manual Phase Level Estimates using
ratios and percentages
Slightly more useful than overall project estimates and
are just about as easy to prepare.
However, they are far from sufficient for contracts, budgets, or
serious business purposes

29. Manual Activity Level Estimates using
work breakdown structure
• Estimation of each activity or task using a formal work-
breakdown structure is the most accurate of the manual
methods.

30. Conditions of Manual Estimation
• Can be used for early estimates before requirements
• Small projects, which can be completed with one or two
programmers
• Low value projects with no critical business impacts
Not use full in situation like
• contract purposes for software development and
maintenance
• Larger projects
• Projects with significance business impact.

31. Automated Estimating Methods
• Its same as in manual method
• Just easier and simpler due to automated tool
• Its also called Macro-estimation
• Its starts with general equitation's of staffing, effort etc