Software Project Planning

1
Software Project Planning
2
Observations on Estimation

• Estimate what?
• resources,
• cost, and
• schedule for a software engineering effort
• What does it require?
• experience,
• access to good historical information,
• and the courage to commit to quantitative
  predictions when qualitative information is all
  that exists.
• Estimation carries inherent risk and this risk
  leads to uncertainty.

3
Observations on Estimation

• Factors
• Project complexity has a strong effect on the
  uncertainty inherent in planning. Complexity is a
  relative measure beginner or experienced team.
• Project size can affect the accuracy and efficacy
  of estimates. As size increases, the
  interdependency among various elements of the
  software grows rapidly.
• Murphy's law "What can go wrong will go
  wrong"and if there are more things that can
  fail, more things will fail.
• Degree of structural uncertainty structure
  refers to the ease with which the task can be
  subdivided.

4
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.
• These estimates are made
• within a limited time frame at the beginning of a
  software project
• and should be updated regularly as the project
  progresses.
• In addition, estimates should attempt to define
  best case and worst case scenarios so that
  project outcomes can be bounded.

5
Software Scope

• The first activity in software project planning
  is the determination of software scope.
• A statement of software scope must be bounded.
• Software scope describes
• the data and control to be processed,
• function,
• performance,
• constraints,
• interfaces,
• and reliability.

6
Software Scope

• 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.

7
Software Scope Obtaining Information Necessary
for Scope

• How should we initiate communication between the
  developer and the customer?
• Gause and Weinberg suggest that the analyst start
  by asking context-free questions
• 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?

8
Software Scope Obtaining Information Necessary
for Scope

• The next set of questions enables the analyst to
  gain a better understanding of the problem
• How would you (the customer) characterize "good"
  output that would be generated by a successful
  solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the environment in
  which the solution will be used?
• Will any special performance issues or
  constraints affect the way the solution is
  approached?

9
Software Scope Obtaining Information Necessary
for Scope

• The final set ("meta-questions) of questions
  focuses on the effectiveness of the meeting
• 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?

10
Software Scope Feasibility

• Once scope has been identified, it is reasonable
  to ask "Can we build software to meet this
  scope? Is the project feasible?"
• Software feasibility has four solid dimensions
• TechnologyIs a project technically feasible? Is
  it within the state of the art? Can defects be
  reduced to a level matching the application's
  needs?
• FinanceIs it financially feasible? Can
  development be completed at a cost the software
  organization, its client, or the market can
  afford?
• TimeWill the project's time-to-market beat the
  competition?
• ResourcesDoes the organization have the
  resources needed to succeed?

11
Software Scope Example

• A conveyor line

12
Resources
13
Resources

• The development environmenthardware and software
  toolsprovides the infrastructure to support the
  development effort.
• At a higher level are the reusable software
  componentssoftware building blocks that can
  dramatically reduce development costs and
  accelerate delivery.
• The primary resource is people.
• 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.

14
Resources

• Human Resources The number of people required
  for a software project can be determined only
  after an estimate of development effort (e.g.,
  person-months) is made.

15
Resources

• Reusable software components
• 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. Existing
  specifications, designs, code, or test data
  developed for past projects that are similar to
  the software to be built for the current project.
  
• Partial-experience components. Existing
  specifications, designs, code, or test data
  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.

16
Software Project Estimation

• In the early days of computing, software costs
  constituted a small percentage of the overall
  computer-based system cost.
• Today, software is the most expensive element of
  virtually all computer-based systems.
• Software cost and effort estimation will never be
  an exact science.
• Too many variableshuman, technical,
  environmental, politicalcan affect the ultimate
  cost of software and effort applied to develop
  it.

17
Software Project Estimation

• To achieve reliable cost and effort estimates, a
  number of options arise
• Delay estimation until late in the project
  (obviously, we can achieve 100 accurate
  estimates after the project is complete!).
• Base estimates on similar projects that have
  already been completed.
• Use relatively simple decomposition techniques to
  generate project cost and effort estimates.
• Use one or more empirical models for software
  cost and effort estimation.

18
Software Project Estimation

• Critics
• First option is not practical. Cost estimates
  must be provided "up front."
• Secon option unfortunately, past experience has
  not always been a good indicator of future
  results.
• Ideally, the techniques noted for each option
  should be applied in tandem each used as a
  cross-check for the other.

19
Software Project Estimation

• Decomposition techniques take a "divide and
  conquer" approach to software project estimation
  cost and effort estimation can be performed in a
  stepwise fashion.
• Empirical estimation models can be used to
  complement decomposition techniques and offer a
  potentially valuable estimation approach in their
  own right.
• A model is based on experience is d f (vi)
• where d is one of a number of estimated values
  (e.g., effort, cost, project duration) and vi are
  selected independent parameters (e.g., estimated
  LOC or FP).
• Automated estimation tools implement one or more
  decomposition techniques or empirical models. In
  such systems, the characteristics of the
  development organization (e.g., experience,
  environment) and the software to be developed are
  described. Cost and effort estimates are derived
  from these data.

20
Decomposition Techniques

• Software sizing problem.
• 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.

21
Decomposition Techniques

• Software sizing problem.
• "Fuzzy logic" sizing. This approach uses 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.
• Function point sizing. The planner develops
  estimates of the information domain
  characteristics. (Chap. 4)

22
Decomposition Techniques

• Software sizing problem.
• Standard component sizing. Software is composed
  of a number of different "standard components"
  that are generic to a particular application
  area.
• 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 of modifications that must be accomplished.

23
Decomposition Techniques

• Problem-Based Estimation

24
Decomposition Techniques

• LOC-Based Estimation

25
Decomposition Techniques

• FP-based estimation
• Decomposition for FP-based estimation focuses on
  information domain values rather than software
  functions.
• The project planner estimates inputs, outputs,
  inquiries, files, and external interfaces.
• For the purposes of this estimate, the complexity
  weighting factor is assumed to be average.

26
Decomposition Techniques

• FP-based estimation

27
Decomposition Techniques

• FP-based estimation
• Each of the complexity weighting factors is
  estimated and the complexity adjustment factor is
  computed as described in Chapter 4
• Factor Value
• Backup and recovery 4
• Data communications 2
• Distributed processing 0
• Performance critical 4
• Existing operating environment 3
• On-line data entry 4
• Input transaction over multiple screens 5

Master files updated on-line 3 Information
domain values complex 5 Internal processing
complex 5 Code designed for reuse 4
Conversion/installation in design 3 Multiple
installations 5 Application designed for change
5 Complexity adjustment factor 1.17
28
Decomposition Techniques

• FP-based estimation
• Finally, the estimated number of FP is derived
• FPestimated count-total x 0.65 0.01 x S
  (Fi)
• FPestimated 375
• The organizational average productivity for
  systems of this type is 6.5 FP/pm. Based on a
  burdened labor rate of 8000 per month, the cost
  per FP is approximately 1230. Based on the LOC
  estimate and the historical productivity data,
  the total estimated project cost is 461,000 and
  the estimated effort is 58 person-months.

29
Empirical Estimation Models

• An estimation model for computer software uses
  empirically derived formulas to predict effort as
  a function of LOC or FP.
• Values for LOC or FP are estimated, but instead
  of using the tables described in those sections,
  the resultant values for LOC or FP are plugged
  into the estimation model.

30
Empirical Estimation Models

• A typical estimation model is derived using
  regression analysis on data collected from past
  software projects.
• The overall structure of such models takes the
  form
• E A B (ev)C
• where A, B, and C are empirically derived
  constants, E is effort in person-months, and ev
  is the estimation variable (either LOC or FP).
• The majority of estimation models have some form
  of project adjustment component that enables E to
  be adjusted by other project characteristics
  (e.g., problem complexity, staff experience,
  development environment).

31
Empirical Estimation Models

• LOC - oriented

32
Empirical Estimation Models

• FP- oriented

33
The Make/Buy Decision
Software engineering managers are faced with a
make/buy decision. It may be further complicated
by a number of acquisition options (1) software
may be purchased (or licensed) off-the-shelf,
(2) "full-experience" or "partial-experience"
software components may be acquired and then
modified and integrated to meet specific needs,
or (3) software may be custom built by an
outside contractor to meet the purchaser's
specifications.
34
The Make/Buy Decision
For more expensive software products, the
following guidelines can be applied 1. Develop
specifications for function and performance of
the desired software. Define measurable
characteristics whenever possible. 2. Estimate
the internal cost to develop and the delivery
date. 3a.Select three or four candidate
applications that best meet your specifications.
3b. Select reusable software components that
will assist in constructing the required
application. 4. Develop a comparison matrix
that presents a head-to-head comparison of key
functions. Alternatively, conduct benchmark tests
to compare candidate software. 5. Evaluate each
software package or component based on past
product quality, vendor support, product
direction, reputation, and the like. 6. Contact
other users of the software and ask for opinion.
35
The Make/Buy Decision Decision Tree

36
The Make/Buy Decision Decision Tree

If the system is to be built from scratch, there
is a 70 percent probability that the job will be
difficult. Using the estimation techniques
discussed earlier in this chapter, the project
planner projects that a difficult development
effort will cost 450,000. A "simple"
development effort is estimated to cost 380,000.
The expected value for cost, computed along any
branch of the decision tree, is expected cost
S (path probability)i x (estimated path cost)i
where i is the decision tree path. For the build
path, expected costbuild 0.30 (380K) 0.70
(450K) 429K
37
The Make/Buy Decision Decision Tree

Following other paths of the decision tree, the
projected costs for reuse, purchase and contract,
under a variety of circumstances, are also shown.
The expected costs for these paths are expected
costreuse 0.40 (275K) 0.60 0.20(310K)
0.80(490K) 382K expected costbuy
0.70(210K) 0.30(400K) 267K expected
costcontract 0.60(350K) 0.40(500K) 410K

38
Automated Estimation Tools

• Automated estimation tools allow the planner to
  estimate cost and effort and to perform "what-if"
  analyses for important project variables such as
  delivery date or staffing.
• All automated tools perform the following six
  generic functions
• Sizing of project deliverables. The "size" of one
  or more software work products is estimated.
• Output e.g., screen, reports,
• The software itself (e.g., KLOC),
• Functionality delivered (e.g., function points),
• Descriptive information (e.g. documents).

39
Automated Estimation Tools

• Selecting project activities. The appropriate
  process framework is selected and the software
  engineering task set is specified.
• Predicting staffing levels. The number of people
  who will be available to do the work is
  specified.
• Predicting software effort. Estimation tools use
  one or more models that relate the size of the
  project deliverables to the effort required to
  produce them.
• Predicting software cost. Given the results of
  step 4, costs can be computed by allocating labor
  rates to the project activities noted in step 2.
• Predicting software schedules. When effort,
  staffing level, and project activities are known,
  a draft schedule can be produced by allocating
  labor across software engineering activities
  based on recommended models for effort
  distribution.