Home arrow Practices arrow Page 4 - The Art Of Software Development (part 5): Adding Value

Playing The Numbers - Practices

So you think releasing a software product is the end of theroad? Not by a long shot! In this final article, find out what goes intothe post-release phase of the software development cycle...and how youcan use it to make both your customer and your accountants happy.

  1. The Art Of Software Development (part 5): Adding Value
  2. The Real World
  3. Changing Things Around
  4. Playing The Numbers
  5. Going The Whole Nine Yards
  6. Parting Shots
By: Vikram Vaswani, (c) Melonfire
Rating: starstarstarstarstar / 2
October 15, 2002

print this article


It doesn't matter how long you've been developing software - you learnsomething new with every project you execute. And so, after a projecthas been formally concluded, it's important to spend some time auditingthe effort and expense that went into it, both to see if it matched yourinitial estimates and to locate areas for improvement.

Some of the possible audits are:
  1. Requirements definition: This report measures the number ofiterations a requirements specification goes through before it isformally approved, and provides an indication of how rapidly andefficiently the organization can understand and document customer needs.
  2. Estimation accuracy: This report compares the effort and expenseestimated by the organization at the beginning of the project with theactual effort and expense at the conclusion, and thereby measures theorganization's skill at providing customers with accurate projectestimates and the validity of the estimation methods and formulae used.
  3. Test planning and execution: This report compares the tests plannedwith the tests actually executed in each of the testing phases, in orderto measure the integrity of the test process. The time and costestimates of each test may also be compared against actual time andcost, to verify the accuracy of the organization's estimation formulae.
  4. Error resolution: This report graphs the number of errors reportedagainst the number of errors actually resolved, and thus provides ameasure of how well the organization's defect management processactually works. A variant of this report involves graphing the number oferrors against the time taken to close them, in order to measureresponse time.
  5. Error frequency: This report graphs the number of errors against eachcomponent of the software architecture, and can be used to identifyorganizational deficiencies in skill or programming knowledge (bymapping each component to specific developer skill sets orresponsibilities). It also provides a measure of the accuracy andeffectiveness of the organization's test plan and test cases.
  6. Change request resolution: This report compares the number of changerequests against the time taken to execute them, and provides a measureof how well the organization is set up to respond to evolving customerneeds.
This is by no means an exhaustive list - every organization hasdifferent needs, and must develop different metrics to analyze its ownperformance over time.

The data that is used to compile these reports must be collectedthroughout the software development process, and reports based on thatdata should be generated and provided to the project manager on aregular basis throughout the project lifecycle. This ongoing trendanalysis allows managers to identify specific problems in differentphases of the project, and take corrective action to resolve them.

In addition to ongoing analysis, once the project has concluded, acomprehensive set of audit reports should be built and analyzed to get abig-picture view of the problems encountered over the project timeline.These reports can be used to identify specific action items fordifferent departments of the organization, and to prevent are-occurrence of the same mistakes in subsequent projects.

It is also useful to perform a re-estimation of the entire project onceit is formally concluded. At this point, project managers have a veryclear idea of what exactly the software requirements are (after all,they just built it!) and they can use this understanding to estimate howlong the project would take. This estimation should again be comparedwith the original estimate delivered to the customer, discrepanciesshould be analyzed to understand their source, and corrections should bemade so that future estimates are more accurate.

The ultimate goal of all this analysis: better estimation, betterimplementation, better quality control. All of which leads to lowercosts for the organization and greater value for the customer.

>>> More Practices Articles          >>> More By Vikram Vaswani, (c) Melonfire

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates


Dev Shed Tutorial Topics: