Software planning involves estimating how much time, effort, money, and resources will be required to build a specific software system. After the project scope is determined and the problem is decomposed into smaller problems, software managers use historical project data (as well as personal experience and intuition) to determine estimates for each. The final estimates are typically adjusted by taking project complexity and risk into account. The resulting work product is called a project management plan.
Project Planning Objectives
To provide a framework that enables a software manager to make a reasonable estimate of resources, cost, and schedule.
'Best case' and 'worst case' scenarios should be used to bound project outcomes.
Estimates should be updated as the project progresses.
Estimation Reliability Factors
Project complexity
Project size
Degree of structural uncertainty (degree to which requirements have solidified, the ease with which functions can be compartmentalized, and the hierarchical nature of the information processed)
Availability of historical information
Project Planning Process
Establish project scope
Determine feasibility
Analyze risks
Determine required resources
Determine required human resources
Define reusable software resources
Identify environmental resources
Estimate cost and effort
Decompose the problem
Develop two or more estimates
Reconcile the estimates
Develop project schedule
Establish a meaningful task set
Define task network
Use scheduling tools to develop timeline chart
Define schedule tracking mechanisms
Software Scope
Describes the data to be processed and produced, control parameters, function, performance, constraints, external interfaces, and reliability.
Often functions described in the software scope statement are refined to allow for better estimates of cost and schedule.
Customer Communication and Scope
Determine the customer's overall goals for the proposed system and any expected benefits.
Determine the customer's perceptions concerning the nature if a good solution to the problem.
Evaluate the effectiveness of the customer meeting.
Feasibility
Technical feasibility is not a good enough reason to build a product.
The product must meet the customer's needs and not be available as an off-the-shelf purchase.
Estimation of Resources
Human Resources (number of people required and skills needed to complete the development project)
Environment Resources (hardware and software required to be accessible by software team during the development process)
Software Project Estimation Options
Delay estimation until late in the project.
Base estimates on similar projects already completed.
Use simple decomposition techniques to estimate project cost and effort.
Use empirical models for software cost and effort estimation.
Automated tools may assist with project decomposition and estimation.
Decomposition Techniques
Software sizing (fuzzy logic, function point, standard component, change)
Problem-based estimation (using LOC decomposition focuses on software functions, using FP decomposition focuses on information domain characteristics)
Process-based estimation (decomposition based on tasks required to complete the software process framework)
Use-case estimation (promising, but controversial due to lack of standardization of use-cases)
Causes of Estimation Reconciliation Problems
Project scope is not adequately understood or misinterpreted by planner
Productivity data used for problem-based estimation techniques is inappropriate or obsolete for the application
Empirical Estimation Models
Typically derived from regression analysis of historical software project data with estimated person-months as the dependent variable and KLOC, FP, or object points as independent variables.
Constructive Cost Model (COCOMO) is an example of a static estimation model.
COCOMO II is a hierarchy of estimation models that take the process phase into account making it more of dynamic estimation model.
The Software Equation is an example of a dynamic estimation model.
Estimation for Agile Development
Each user scenario is considered separately
The scenario is decomposed into a set of engineering tasks
Each task is estimated separately
May use historical data, empirical model, or experience
Scenario volume can be estimated (LOC, FP, use-case count, etc.)
Total scenario estimate computed
Sum estimates for each task
Translate volume estimate to effort using historical data
The effort estimates for all scenarios in the increment are summed to get an increment estimate
Make-Buy Decision
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.
