Gaining on data quality

The automatic data collection, based on a well designed unit-test (see this post ) needs the following steps:

1. A sound architectural design where services are neatly conceived for managing values and entities.
2. Collection requirements including boundary values (see Boundary values ). Thereby, the tests will be focused on the “critical” scenarios.
3. Developers able to work in a TDD (Test Driven Development).
4. Scripts (e.g. Based on Ant/Crusader) to send the data results to a repository. This information (developer, task and result) is linked to the WBS/PBS (detailed at work-package level).
5. SQL based procedures for storing the results (see previous point) into a DB, which will be pooled for updating the performances (see post) based on the following values (as described in the following paper[1]):

• Time (Plan)
• Quality of production (As stated in the Acceptance Criteria)[2]
• Cost and reserves
• EVM
• Risks (e.g. listed both for proximity and impact)
• Issues (pending)

Pros and cons

In the following table are listed gains and costs:

Pros	Cons
Reducing the reworking costs (up to 5 times the production costs)[3] (	Increasing in developing time (up to 150%)
Reducing tests (time/costs)	Some training for less skilled developers
More focused approach from customers	More time (in the requirements collection) spent by the customer’s people (final users)
Actual results much more reliable	Finding an agreement about the metrics to be applied to the produced/maintained code.
More PM’s energy available for leading instead of crunching “personal” figures	Trusting the system that shall not be used as (Taylor’s spook)
Verifying WBS and planning	More shared planning on short terms as taught by Agile methods
Shorter and more clear reports (diagrams)	Less control on actual figures by PM
More data available for creating a reliable history. It is especially good for improving the estimations.
	This system is difficult to apply, but to the development activities.

Conclusion

The choice of avoiding the automation can be solved with the manual input of “personalized” data. This does not change the necessity of collecting and analyzing data both for evaluating the producers’ performances (Burn down charts) and the team output.

To use technology as ancillary requires that masters would be able to take their own responsibilities (i.e. accepting the existing reality).

---

[1] http://www.stsc.hill.af.mil/CrossTalk/2009/07/0907Ebert.html

[2] The quality of the processes will be monitored through the “Learned Lessons” applied to the Governance.

[3] http://www.stsc.hill.af.mil/consulting/sw_estimation/EstimatingHandbook.html