Software Project Planning CFICSE PM01 1999

1
Software Project PlanningCFICSE PM01 1999

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 01-613-541-6000 ext. 6190

2
Planning

• A plan is merely a position from which to
  adjust. Thats not to say you you can get away
  without one without a plan you have nothing.
• Neil MacLaine, 1 PPCLI
• No plan survives contact with the enemy.
• Anonymous

3
Goals

• Define what is to be built
• Define the process to be used
• Define the resources required
• equipment
• software engineering environment
• personnel
• Define the schedule
• to meet contractual or other constraints
• to meet other goals, e.g., quality
• Identify and adapt to other constraints
• hardware resource utilization
• reuse
• creation of reusable products
• etc.

4
Principles

• developed iteratively and maintained
• starts by mapping the route from vague,
  incomplete requirements to precise ones
• a conceptual design is then developed
• each time requirements are refined, resource
  projections, size estimates and schedules are
  also refined
• when requirements are clear, a detailed design
  and implementation strategy is developed and
  incorporated into the plan
• as various parts become better understood, their
  implementation details are incorporated into the
  plan
• throughout, the plan provides the framework for
  negotiating the time and resources required

5
Considerations

• Initial resource estimates and schedules almost
  always unacceptable
• reduce scope or extend time and resources
• New features needed before they can be ready
• difficult to forecast need, therefore need it now
• Implication the plan is the result of a
  negotiation between the customers desires and
  their means
• This must be done rapidly, as every day delay in
  planning is a day-for-day slip to completion

6
Planning Cycle (Humphrey)
Initial Requirements
Negotiate Commitment
Negotiated Requirements
Decompose Requirements
Estimate Product Size
Estimate Project Resources
WBS
Develop Schedule
SLOC or FP
NO
Does Schedule Meet Need?
Programmer Machine Time
YES
Product
Develop Software
Projected Schedule
Actuals
Compare (Database)
Estimates
7
Plan Goals and Objectives

• implement the product in small incremental steps
• select each increment to support succeeding
  increments and/or improve requirements knowledge
• freeze the requirements for each incremental step
  before starting design
• when the requirements change during
  implementation, defer the change to a subsequent
  increment
• if the changes cannot be deferred, stop work,
  modify the requirements, revise the plan, and
  start again on the design

8
Builds and Releases

• A build is a portion of a system that satisfies,
  in part or completely, an identifiable subset of
  the specifications. Specifications met in one
  build also are met in all successor builds. The
  last build, therefore, is the complete system.
• NASA heuristic any system larger than 10 kSLOC
  is developed in builds.
• Microsoft heuristic build and smoke at least
  weekly, preferably daily
• A release is a build that is delivered for
  acceptance testing and subsequently released for
  operational use.
• NASA heuristic one release for each 300 kSLOC
  total system size.

9
Requirements Supremacy

• the plan should always be keyed around the
  project requirements, which include
• functional requirements
• what the product is supposed to do
• system needs
• target systems, standards, compatibility
• customer identification
• who is it for, how are they to be involved
• measures of success
• cost, schedule, performance, quality, size
• validation and acceptance
• acceptance testing, criteria, warranties
• support
• continuing support requirements

10
The Work Breakdown Structure

• framework for relating product structure and
  software process
• traditionally structured around modules
• but see Royce, section 10.1 for arguments against
• as many layers as necessary typically lt6

System
Sub-system
Sub-system
Sub-system
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
Mod.
11
Estimating

• Fundamental concerns
• establishing a size measure (SLOC, FP)
• deriving an accurate estimate (FP counting,
  Wideband Delphi, COCOMO, SLIM, other parametric
  methods)
• reducing estimating bias
• understanding estimating inaccuracies
• to reduce them
• to know where to contingency-plan
• estimating contingencies
• tend to inflate estimates, therefore resisted

12
Size Measures

• SLOC
• most commonly used
• surprisingly difficult to define
• language dependent two orders of magnitude
  variability between languages
• Function Points
• standardized by IFPUG, widely used
• portable across languages, including 4GL and
  visual
• also estimates of non-code documentation size by
  FP
• Mk II Function Points (UK SW Metrics Assn)
• Feature Points (SPR)
• Full Function Points (UQaM)
• for a given language and counting guide, there is
  a linear relationship between SLOC and FP

13
Estimating Techniques

• SWAG (WAG, PDOMA, RESWAG)
• Wideband Delphi
• Parametric estimating tools
• SLIM
• SEER
• COCOMO
• others
• All rely in some way on historical data
• if you dont have historical data, your estimates
  will be inaccurate
• Most are biased in some sense

14
Scheduling

• Schedule by activities, phases, etc.
• Tied to development process model
• Like the overall plan, developed iteratively as
  more detail about the project becomes known
• Larger projects tend to have a bell-curve or
  Raleigh curve staffing profile

personnel
time
15
Time and Effort Distribution (NASA)
16
Project Effort Distribution
17
Resources

• Watts S. Humphrey, Managing the Software Process,
  chapter 6
• NASA Recommended Approach to Software
  Development, and Mangers Handbook for Software
  Development, available from http//sel.gsfc.nasa.g
  ov/