1. Chapter 5 Software Project Planning
Slides by Omar garcia

2. Agenda Motivation Introduction Software Project Estimation
Decomposition techniques
Empirical Estimation
Make/Buy Decision
About Project Manager
The project plan
Quiz
CSCI 425/925 Version 3

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

4. The Steps
Scoping—understand the problem and the work that must be done
Estimation—how much effort? how much time?
Risk—what can go wrong? how can we avoid it? what can we do about it?
Schedule—how do we allocate resources along the timeline? what are the milestones?
Control strategy—how do we control quality? how do we control change?
CSCI 425/925 Version 3

5. Write it Down! Project Scope Software Estimates Project Risks Plan
Schedule
Control strategy
Software
Project
Plan
CSCI 425/925 Version 3

6. Scoping the Problem Identify the customer Customer discussions:
Who is the end user [often not the customer]?
Who has the authority to accept the finished product?
What problem are we addressing?
What documentation will be required?
When does he believe he needs the product?
Where is the work to be done?
Why does he need the product?
How will the product be developed / acquired?
Identify the systems environment
Identify necessary tools
Identify potential re-use
CSCI 425/925 Version 3

7. Software Scope Software scope describes among others: function,
performance,
constraints,
interfaces,
and reliability.

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

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

10. Resources

11. 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 variables—human, technical, environmental, political—can affect the ultimate cost of software and effort applied to develop it.

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

13. Software Project Estimation
Critics:
First option is not practical. Cost estimates must be provided "up front."
Second 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.

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

15. 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).

16. Automated Estimation Tools
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.

17. Estimation Guidelines
estimate using at least two techniques
get estimates from independent sources
avoid over-optimism, assume difficulties
you've arrived at an estimate, sleep on it
adjust for the people who'll be doing the job, they have the highest impact
CSCI 425/925 Version 3

18. 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.
CSCI 425/925 Version 3

19. 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.
CSCI 425/925 Version 3

20. Nature of a Project Manager
CSCI 425/925
Nature of a Project Manager
More than a person who wants to deliver a project on time and within budget
More than a person who can best apply the tools for time and resource management
A true project manager must have ‘a fire in the belly’, to do everything required to make the project a success
This presentation will not cover the technical components of project management.
There are many training courses on project scheduling tools that may take weeks to complete.
An Internet search on “project management’ using google.com produced 2,730,000 hits.
Successful project managers command as much respect as high ranking defense managers.
On large projects, a project manager will have a specialist running the project schedule and in some cases have another specialist running the finance /budget package.
A ‘true’ project manager enjoys working to deadlines and communicating with people at all levels to orchestrate a successful outcome.
In its most basic form a project can be you and a customer working on a new Web site.
Even at that level there is a requirement on you as the service provider to manage the project scope and customer expectations to ensure that the project is completed on time and within budget.
Ask for participation in expanding on and better defining ‘a fire in the belly’. This is an important step in generating an understanding that a good project manager is like the conductor of an orchestra.
Some people have skills in particular instruments and only a few musicians have the skill to become the conductor.
CSCI 425/925 Version 3
Autumn 2003

21. Nature of a Project Manager
CSCI 425/925
Nature of a Project Manager
How do you become a Project Manager?
Specialist training is required as well as gaining experience by working on bids or projects and then manage progressively larger projects
Project Management, in many ways, is like parenting. You learn from what you see as your parent’s mistakes
A project manager should have training in project scheduling, project budgeting and estimating.
Other training requirements are:
Detailed knowledge of at least one IS discipline e.g. programming, N/W management, H/W maintenance;
Negotiation skills;
Commercial awareness (understand contract Terms and Conditions, Trade Practices, Occupational Health and Safety)
Presentation Skills
Project Managers must win the trust and respect of the customer and the project team. There should be no need to check on particular deliverables ‘every ten minutes’. By working as part of a bid or project team you learn about team dynamics and the importance of estimating the work effort for your deliverable and achieving to agreed deadlines.
CSCI 425/925 Version 3
Autumn 2003

22. Project Plan 1 Introduction
CSCI 425/925
Project Plan
1 Introduction
<copy and paste directly from requirements specification>
2 Project Estimates
<describe estimation technique>
<table of module name, estimated effort>
3 Risk Management
<identify all risks>
<table of risk, severity, consequences, detection, remediation>
4 Schedule
<identify each task (1 week granularity)>
<identify starting and ending triggers for each task>
<list of tasks on project time line>
<include opportunities to review work products>
5 Resources
5.1 Resources Available
<table of person name intended hours task assignment>
5.2 Resource Loading
<diagram mapping resource allocation onto the schedule>
CSCI 425/925 Version 3
Autumn 2003

23. Quiz What should you do with this plan?
A- Stick it on the shelf and ignore it
B- Make it hard to change
C- Change it every week to reflect how things are going
D- Express it electronically where it is
accessible to change
under configuration control
know who changed it
know why they changed it
CSCI 425/925 Version 3

24. Group Assignment for the lab
The problem
Describe the arrangements made by phone to identify your partner and yourself for the first time at the airport after a long e-romance.
Restrictions
No mobile phones are allowed.
After setting the arrangements on the phone, both leave to the airport ( no more talking).
The maximum length for this assignment is 350 words (no more than a page)
The whole group may get an extra point.
Hand this in before Wednesday 17 March 5 p.m.
CSCI 425/925 Version 3