Step Four: Software Sizing
Size is generally the most significant (but certainly not the only) cost and schedule driver. Overall scope of a software project is defined by identifying not only the amount of new software that must be developed, but also must include the amount of preexisting, COTS, and other software that will be integrated into the new system. In addition to estimating product size, you will need to estimate any rework that will be required to develop the product, which will generally be expressed as source lines of code (SLOC) or function points, although there are other possible units of measure. To help establish the overall uncertainty, the size estimate should be expressed as a least-likely-most range.
Predicting Size
Whenever possible, start the process of size estimation using formal descriptions of the requirements such as the customer’s request for proposal or a software requirements specification. You should reestimate the project as soon as more scope information is determined. The most widely used methods of estimating product size are:
Step One: Establish Estimate Scope and Purpose
Establish Estimate Scope and Purpose
Define and document expectations. When all participants understand the scope and purpose of the estimate, you’ll not only have a baseline against which to gauge the effect of future changes; you’ll also head off misunderstandings among the project group and clear up contradictory assumptions about what is expected.
Documenting the application specifications, including technical details, external dependencies and business requirements, will provide valuable input for estimating the resources required to complete the project. The more detailed the specs, the better. Only when these requirements are known and understood can you establish realistic development costs.
An estimate should be considered a living document; as data changes or new information becomes available, it must be documented and factored into the estimate in order to maintain the project’s integrity.
Previous:
Ten-Step Project Estimation Process Introduction
Coming Next:
Step Two: Establish Technical Baseline, Ground Rules, and Assumptions
The Cost of Cloud in the Sky Computing Part 1
Looking at ways to increase IT infrastructure without worrying about power, heat, space and other constraints…. Cloud in the sky computing (or cloud computing) may be an upcoming solution. Cloud in the sky essentially is buying
Amazon Web Services is an example. Costs, as I understand them are about $0.10 per hour of usage plus storage costs at $.15 per gig per month for a clone of an HP Tower server. If an application is hosted and not used there is no cost. Not bad. I suppose we could add to the advantages that they back up the whole system without you worrying about it. On the other hand, your data is out of your control.
Galorath recently did a study of the costs / benefits of force.com, Salesforce’s environment with some similarities to Amazon. I need to find out if our results are publishable. But I can tell you we found force. com to be attractive in the appropriate environment.
We will use SEER for IT to do a general analysis of cloud versus local computers soon.
Metrics and Estimation ROI
I was speaking with Ton Dekker and others from Galorath this morning abut the ROI from viable estimation. Ton pointed to the empirical evidence of a 10 to 15% saving in overall IT spending based on the implementation of a metrics program and estimation going along with it. Ton also spoke of MOUSE…. the “list of activities and services that need to be carried out to get a metrics program up and running.” The activity and service groups within MOUSE include:
|
Market View |
Operation |
Utilisation |
Service |
Exploitation |
|
Communication |
Application |
Training |
Helpdesk |
Registration |
|
Evaluation |
Review |
Procedures |
Guidelines |
|
|
Improvement |
Analysis |
Organisation |
Information |
|
|
Investigation |
Advice |
|
Promotion |
|
Why is all this important…. Well a viable metrics is not just collecting data… it is not just about checking a box. It is about communication, evaluation, and improvement. Looking at the number of metrics programs that fail, (the average life of a metrics program is 3 years according to Howard Rubin in 2006) It is about achieving business value with metrics. Programs that generate 10 or 15% cost savings generally don’t get killed. Programs that make more work and don’t have a payback can and should be killed.
