My Estimating Process

Preamble

The following is an outline of the estimating and initial design software engineering process model I use as a consultant. My track record when this process is followed, in terms of meeting cost and performance objectives, is good enough that I will usually tender the estimate in stage X. as a firm bid.

It should be recognized as a model practice, for instance it may make sense to follow a risk-driven project management strategy where smaller pilot projects are undertaken first as opposed to the traditional complete waterfall breakdown. It may also make sense to "plan for failure" in such pilot projects and if the exploration of risks manifestly demonstrates the case (either that the risk is too large or too slight to be of importance) such projects may be terminated early.

This document was a textfile until some time in 2005.

Copyright

(c) Copyright 1995,1996,2005 Fred Morris, Seattle WA. U.S.A.

e-mail: m3047@nwa.net
telephone: 206.297.6344

Change History

22-Sep-1996 A nod to Scott McKenzie for pointing out that I had omitted sizing of the dataset.

26-Feb-2005 Updated contact information.

14-May-2005 HTMLized it.

Process Outline

I. Client Capabilities Evaluation
	A. Awareness of the Capability Maturity Model?
	B. What documentation justifies use of current toolset and
	   methodology?
	C. How are other projects developed, and what is the track
	   record?
II. Requirements Identification
	A. Who needs to buy off?
		1. Users.
		2. Management.
		3. I.S. Department?
		4. Networking & Hardware guys?
		5. Casual users?
	B. Institutional/political considerations.
		1. Management visibility?
		2. Preexisting turf wars & control issues?
		3. Possible new control issues?
		4. User & management satisfaction:
			a. with existing system?
			b. with existing methodologies?
			c. with existing management & users?
	C. Process management considerations.
		1. Audits of system performance?
		2. Security?
		3. Training?
	D. How many users:
		1. Simultaneous?
		2. Serial?
		3. Unusual peak loads?
	E. How many sites:
		1. Using the process?
		2. Using the data?
	F. Data interchange issues/requirements.
		1. Externally-visible data formats?
		2. Exchange of data with other systems?
	G. Dataset issues:
		1. "Legacy" data to be imported or converted?
		2. How much new data is generated in a given
		   time period?
		3. Is generation of new data seasonal?
		4. Record retention issues/schedules.
	H. Process issues/requirements.
		1. Are existing processes documented?
		2. Are new processes needed?
	I. Uptime.
		1. Availability of the system?
		2. Impacts of its unavailability for various periods
		   of time?
	J. Timeliness.
		1. Interactive response time?
		2. Currency of data?
		3. Latency of data?
	K. Disaster recovery.
		1. Considerations identified in II.I.
		2. Are existing mechanisms for backup & recovery
		   sufficient?
	L. Vital system requirements are documented.
III. Preliminary Size Estimation
	A. Simultaneous users; adequate hardware and network
	   infrastructure?
	B. Number of ways of getting data into & out of the system.
	C. Complexity of process.
		1. Ballpark estimate based on complexity of DFDs.
		   (see VII.)
		2. Design of a new process may be a whole project all by
		   itself!
	D. How much data; adequate storage and backup policy?
	E. Difficulty of coordinating change control with existing
	   systems.
	F. Any especially pressing requirements identified in II?
IV. Process Audit
	A. Comparison with issues identified in II.
	B. Does actual process match the documented process?
	C. Opportunity to document undocumented processes.
	D. Verification that all users are identified.
	E. Opportunity to do some pre-selling of the new system.
V. Resources Identification
	A. Which resources identified in I.B., II.A., II.C.1., II.F.,
	   II.G.1., II.G.4, II.H.1, II.K.2., IV. are suitable and available?
	B. New resources to be developed.
	C. How will new resources be developed?
VI. Project Size Reevaluation
	A. Discrepancies between II. & IV.?
	B. Discrepancies identified in IV.B.
	C. How much effort to document items in IV.C.?
	D. Adjustments based on V.C.
	E. Adjustments based on complexity change of DFDs. (see VII.)
	F. Additional drift until X. projected.
VII. Data Flow/Process Modeling
	A. Training for users & management on interpreting Data
	   Flow Diagrams (DFDs) if needed.
	B. DFDs span the interface.
	C. Any undocumented process which turns out not to be incidental
	   needs to go through formal design. (See III.C.2.)
	D. A complicated process with a lot of sources and sinks is
	   invariably a very expensive process! (see X.A.)
	E. Work on DFDs starts with II. and continues in IV. and V.
	F. DFD's & process output from this stage should be usable as
	   reference for the as-built system.
VIII. User Interface Mockup
	A. Screens.
	B. Edit Checks.
	C. Critical reports.
	D. Items output from this stage should be usable as reference
	   for the as-built system.
IX. Walkthroughs & Buy-In
	A. VII. and VIII. are reviewed with all classes of users and
	   impacted parties.
	B. Changes reviewed with all impacted parties.
	C. Major changes could conceivably push the project back as far
	   as stage II.
	D. Items produced in stages VII. and VIII. are updated to
	   reflect all minor changes and reviewed again.
	E. Milestones identified.
X. Project Estimation
	A. Black-Box Complexity Squared Rule:
		1. DFD atoms assigned complexity points as
		   (<number of flows> - 1)^2.
		2. DFD sources & sinks assigned one complexity point
		   per connection.
		2. Complexity points are summed.
		3. Grief of average process is average estimated hours
		   for:
			a. most complicated process.
			b. average grief of "uncomplicated" processes.
			c. an "average" process.
		4. Hours = grief * complexity.
	B. Documentation.
	C. Training.
	D. Maintenance.
	E. Changes before delivery.
	F. Demonstration of milestones from IX.E.
	G. Costs for new resources.
	H. Costs for resources & client personnel needed to support
	   XI.C., XI.E., XI.G.
	I. Adjusted for measured drift in size estimates. (See III. and
	   VI.)
XI. Implementation
	A. Coding.
	B. Testing of resources.
	C. Testing of data exchange with existing systems.
	D. More coding.
	E. Testing of user interface.
	F. More coding.
	G. Tests of process.
	H. Delivery planning.
		1. Logistics.
		2. Pre-delivery training.
	I. Debugging and tweaking.
	J. Version 0beta creation.
XII. Delivery
	A. Installation.
	B. Installation verification.
	C. Documentation of installation issues.
XIII. Training
	A. Delivery of documentation identified in X.B.
	B. Basic training on use of the system.
XIV. Testing
	A. Does the system meet the vital requirements from II.L.?
	B. If the as-built system doesn't match the documents produced
	   in VII. and VIII. then those are revised.
	C. What additional documentation is needed?
XV. The Blessing
	A. Version 1 creation & installation.
	B. Additional documentation delivered.
XVI. Maintenance
	A. Evaluation of impacts of changes.
	B. Implementation of changes.
	C. Audits.
	D. Ongoing training.
	E. Caretaking.
	F. New technologies identification.
	G. Migration planning.