Metrics to define what is "good" in your environment... In order to setup metrics, you need to decide on what objectives you want to achieve and their relative importance. Once you decide on what your objectives are, you can devise a measurement system for it. For example, you could have several objectives:
- minimal memory usage - minimal i/o usage - minimal response time - program readability - code reuse and modularity - least code - minimal programming time - whatever But in reality, whatever objective you focus on will be at the detriment of the others. If you focus on "minimal memory usage" it is usually at the expense of "least code" or something else. Of course, this is just a general rule, but it should be considered when prioritizing your objectives. I think most people just want "better" software. For most users, that means fewer bugs and more features. To that end, process is more important than metrics. Studies have shown that most quality assurance processes are approximately equal in effectiveness. Those same studies also find that when two or more processes are used together, quality goes up significantly. Those quality assurance processes include: - pair programming - informal design reviews - informal code inspections - modeling or prototyping - personal desk-checking of code (i.e. reviewing a printout) - unit testing - regression testing - low-volume beta test - etc. So just adding one more process to your current practices can make a big difference in your software quality. rex ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
