Web site layout - Chapter 26: Measurement 26.2 CLASSIC MISTAKE Data accuracy.
Chapter 26: Measurement 26.2 CLASSIC MISTAKE Data accuracy. The fact that you measure something doesn’t mean the measurement is accurate. Measurements of the software process can contain a lot of error. Sources of errors include unpaid and unrecorded overtime, charging time to the wrong project, unrecorded user effort, unrecorded management effort, unrecorded specialist effort on projects, unreported defects, unrecorded effort spent prior to activating the project-tracking system, and inclusion of non-project tasks. Capers Jones reports that most corporate tracking systems tend to omit 30 to 70 percent of the real effort on a software project (Jones 1991). Keep these sources of error in mind as you design your measurement program. Managing the Risks of Measurement In general, Measurement is an effective risk-reduction practice. The more you measure, the fewer places there are for risks to hide. Measurement, however, has risks of its own. Here are a few specific problems to watch for. Over-optimization of single-factor measurements. What you measure gets optimized, and that means you need to be careful when you define what to measure. If you measure only lines of code produced, some developers will alter their coding style to be more verbose. Some will completely forget about code quality and focus only on quantity. If you measure only defects, you might find that development speed drops through the floor. It’s risky to try to use too many measurements when you’re setting up a new measurement program, but it’s also risky not to measure enough of the project’s key characteristics. Be sure to set up enough different measurements that the team doesn’t overoptimize for just one. Measurements misused for employee evaluations. Measurement can be a loaded subject. Many people have had bad experiences with measurement in SAT scores, school grades, work performance evaluations, and so on. A tempting mistake to make with a software-measurement program is to use it to evaluate specific people. A successful measurement program depends on the buy-in of the people whose work is being measured, and it’s important that a measurement program track projects, not specific people. Perry, Staudenmayer, and Votta set up a software research project that illustrated exemplary use of measurement data. They entered all data under an ID code known only to them. They gave each person being measured a “bill of rights,” including the right to temporarily discontinue being measured at any time, to withdraw from the measurement program entirely, to examine the measurement data, and to ask the measurement group not to record something. They reported that not one of their research subjects exercised these rights, but it made their subjects more comfortable knowing they were there (Perry, Staudenmayer; and Votta 1994).
You want to have a cheap webhost for your apache application, then check apache web hosting services.