David Notkin UWash
While I know of more scholarly sources to go to for an academic treatment of software quality I enjoy trolling the web since I am more inclined to find the unexpected there. Today I happened to have found the site http://www.robelle.com/library/papers/quality/. It is not a remarkable page but it does repeat some of my prior observations:
- quality is measured by a human's perceptions
- correctness as measured against the specification is not the same as quality
- different people or the same person at different times will evaluate the quality differently
- quality can only be judged in context
The prior post does a good job of summarizing some key views of quality and helped me make the point that each stakeholder will evaluate quality differently. This page helps me make the point that there are nested systems and the quality is evaluated at each system boundary by the stakeholder(s) at that point. Since this last point is a bit obtuse, let me give an example of what I mean.
In a large organization, the person usually called the "user" is the one who directly interacts with the routine transactions of the business system in which this software product is embedded. For a customer relationship management tool, it is the sales and marketing people who frequently enter pipeline and contact information. Since their job uses the mechanized system as a tool for performance, their roll up of quality attributes will concern the use of this tool in the context of their jobs. The goal is to close as many deals as possible as quickly as possible. Their key performance indicator will be something like booked revenue per quarter. Most likely the majority of the metrics that would eventually support that rollup will be related to how the product enhances or hurts this productivity.
But in the modern organization, there are other users as well. The entire sales and marketing organizational hierarchy will also use this product as they review the collective pipeline for the organization and use the results of this consolidation for financial planning. Their task is not the direct booking of the contracts but the management information reporting and assimilation of the information into the broader context of the business. Whether this is viewed as one additional layer of user or several makes no difference once you can see that the way these two important stakeholders view the product with different expectations and interests.
One of the temporal considerations in quality evaluation occurs during the sales cycle. While the end user's evaluation of the product would logically be considered, the logistics, economics and politics often prevent it. Product purchase decisions are usually made by a different set of stakeholders, often the most senior managers the product sales staff can engage and the company's sourcing and purchasing professionals. Their evaluation of the the product quality stems from many sources that have no guaranteed basis on what the end users will assess once the product is in production. I think this topic can easily become an entire paper but not a software engineering paper.
In this discussion I could have substituted value for quality and value is certainly one of the key filters someone will use in determining quality. This is quite evident in cars. Clearly a Toyota Civic will measure very differently than a Porsche Boxster. Yet many Toyota Civic customers feel the Civic is a good quality product for the price. In a reverse fashion, Jaguar once had a dependability problem with their cars. Everyone agree that it was a high quality product when it ran. But the frequent trips for repair caused their reputation to diminish forcing them to address the dependability issue. No doubt all auto makers needed to face that issue as the marketplace improved raising the bar for everyone.
But quality can transcend mere value. While the dictionary definitions of quality focus more on the philosophical or aesthetic sense of the word, even the prosaic world of business cannot completely avoid this sense of the word as well. I think Apple provides a good example of what I intend here. Before Apple became dominant I heard many product managers moan that computer hardware had become a race to the bottom to see who could make it the cheapest and could not see any value in user interface research investment. But Apple stubbornly stuck to their visions and eventually proved that the marketplace will reward superior design.
My friends in college were design students and I listened to endless pompous discussions of aesthetics and beauty. They frequently chose products that were beautiful and represented a refined sense of taste. However they often chose aesthetics over function despite the Bauhaus tradition of the school. These people were partly frustrated artists who wanted to make beautiful things but had not completely absorbed some of the Bauhaus teaching.
Meanwhile I was taking classes in the engineering school with students who were only mildly put off when they realized their socks did not match. Pocket protectors were the norm since pens still leaked back then and engineers can be very cheap when it comes to replacing their short sleeved white shirts. It was their aesthetic that brought us inscrutable black boxes that would blink 12:00 for eternity since figuring out how to set the time was almost impossible even with a manual. Of course other engineers could in a heartbeat but in the marketplace, the majority of the buyers were not engineers and people only tolerated these machines since they provided value despite their flaws.
These two very different aesthetics existed side-by-side and never realized any synergy. Sadly, I don't feel we have gotten too much past that and we are leaving it to the marketplace to slowly sort out how people quantify the various qualities of a complex product like an iPhone. While there is a great deal of elegance in the market-driven approach, it gives the product designers little to base their decisions on absent some form of model that predicts market success from some set of attributes, most commonly function and features. Yet how would you go about quantifying design aesthetics so it could be included in a quality calculation?
In the end I don't find anything on this page which is more hopeful for defining quality than what I have already found in Bass et al from Software Architecture in Practice. Their approach starts with some feature or function expressed as a use case. It then provides some additional information about this use case which supports a defined metric for the behavior of interest. I'll continue my web crawl but I suspect I may not find anything to extend their concepts of quality decomposition until I peruse the academic vein.
No comments:
Post a Comment