|
||||||||||||||||||||||||
How do we quantitatively measure a "good" piece of
Obviously, The performance, easy of use, and Functionality!
Well... think about it, Windows 95 was hailed a revolutionary change in Operating Systems, the Leap from CMD line to the WIMP environment, what really makes a good piece of software?
"How ambiguous can you be!"
Yes indeed, there's so many different subsets of software and within that further levels and sets of quality attributes. And the fact every software a unique product in every percievable way, but lets focus away from functionality and purpose and step back to the native code and design.
What really makes a good piece of software from Planning all the way to Maintenance? (ref. Waterfall model)
I am embarking on this small quest and I would definitely like to hear your views.
cheers, Allan.
Well... think about it, Windows 95 was hailed a revolutionary change in Operating Systems, the Leap from CMD line to the WIMP environment, what really makes a good piece of software?
"How ambiguous can you be!"
Yes indeed, there's so many different subsets of software and within that further levels and sets of quality attributes. And the fact every software a unique product in every percievable way, but lets focus away from functionality and purpose and step back to the native code and design.
What really makes a good piece of software from Planning all the way to Maintenance? (ref. Waterfall model)
I am embarking on this small quest and I would definitely like to hear your views.
cheers, Allan.
Since whether or not software is "good" is a question of quality, but a "quantitative" measurement is a question of quantity, the only way to establish a qualitative measure of a good piece of software is to define quality in arbitrary, quantitative terms. In addition, it would require defining something that is subjective in terms of something that is objective, and would, by necessity, omit many of the most useful, subjective evaluations.
That said, the best one could do is to count (i.e. quantity) the number of times the software failed. By "failed," one would have to consider actual error conditions as well as the times users were not able to complete the desired tasks without going to sources outside of what the software presented them on the screen (or were not able to complete the desired tasks at all). Anything else, and the results would not be entirely quantitative, but also qualitative.
Counting the number of times the software succeeded would be more difficult, since users don't usually call tech support several times a day saying, "the program worked well again."
That said, the best one could do is to count (i.e. quantity) the number of times the software failed. By "failed," one would have to consider actual error conditions as well as the times users were not able to complete the desired tasks without going to sources outside of what the software presented them on the screen (or were not able to complete the desired tasks at all). Anything else, and the results would not be entirely quantitative, but also qualitative.
Counting the number of times the software succeeded would be more difficult, since users don't usually call tech support several times a day saying, "the program worked well again."
 |