Measuring Quality

You might remember that Chapter 1, "Envisioning the Solution," mentioned a fourth dimension for measuring a successful project: quality. Although of paramount importance in your project, I anticipate minimal coverage on the exam, so to honor your time, I'll move through these last few topics quickly.

Project Control Metrics

To me, project control encompasses the use of a scheduling tool. Pick one at randomsay, Microsoft Project.

Project control verifies that you are conforming to two of the three variables in the "success" equation (see Chapter 1): deadline and cost. You are dealing with actuals against forecast (or budget). Good project control doesn't guarantee that you will meet either goal (although it helps). Rather, it serves as an early warning system when you are in danger of missing your target. This warning gives you time to react and adjust your plan.

Organizational Performance Metrics

At some point, I have to discuss the standard quality measurements. Why not now?

It used to be that "defects per lines of code" was a standard quality measure, but this measure seems to have fallen out of favor, partly because of the subjectivity in the term "lines of code." Clearly, one line of Visual Basic .NET code is not equal to one line of VB6 code. So if you have the same number of defects in applications of the same size (lines), what can you draw from that? The .NET application does so much more in the same amount of space.

At one time, the following was considered a good measurement:

NASA standards were geared to deliver an MIS application with approximately 5 defects per 10,000 lines of code. MIS averages are closer to 85 defects per 10,000 lines of code (17 times greater).[1]

[1] From "Cut Your Bugs by an Order of Magnitude," by Steve McConnell. Enterprise Development, Fawcette Technical Publications (Fall 1998, p. 66).

As you can see, this information is a bit dated. I suspect that .NET, with its higher level of abstraction, will at least change the definition of "good enough," if not totally invalidate the measurement.

I prefer the quality measurement "severity 1 defects after release." "Severity 1" means the application crashed or became unusable. Basically, it measures how many defects got all the way through the multilayered testing process, including QA testing. Of course, the goal is zero.

There is an entire science for measuring software quality with various metrics and formulas. However, I don't anticipate any of them being on the exam.

Return on Investment Metrics

It's unlikely you'll be asked to do any complicated return on investment (ROI) calculations on the exam, but at a high level, ROI boils down to benefits divided by costs. Therefore, a solution that brings an additional $12 million annually to the bottom line, over an expected life span of five years, has a benefit value of $60 million. If that same solution costs $10 million to build and $2 million annually for maintenance costs, its costs would be $20 million. This would result in an ROI of 3, not taking into account the net present value of money spent today to received benefit in future dollars (when the cost of a dollar could be different). My apologies to the international readers, but I am most familiar with the currency of dollars.

The key term in the preceding paragraph is additional. The benefit is the amount of additional revenue that would be realized if you implement the solution versus making no changes to the present situation. This benefit could be an indication of additional revenue or could be based on expense savings. It would look like this as an equation:

graphics/11equ01.gif

Don't forget about items such as additional hardware expenses (new machines) or new software licenses (third-party software) that should be figured into your costs, both annual and original.

There is no magic ROI number that is good in all cases. Most companies hope for a positive number, but a shrink-wrap software company might have hopes of a higher number than a corporation that has no choice but to create software applications in support of its business plan.

ROI does come in handy when determining whether to "port" or refactor an existing application or rebuild it from scratch. In this case, the numerator might be a very small number, so the costs of rebuilding from scratch become prohibitive. This information is useful in making "go, no-go" decisions.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net