Musings on Tech

" Keep things simple stupid.. ." The best way to answer this question would be to ask whether the Quality with which the product is being shipped is sufficient for the Customer. It goes back to our old theme - "Customer interest is paramount". Having said this, making a decision of whether the quality is sufficient from the customer perspective is a tricky one. Many issues gets raised on what is sufficient for the cusatomer and let us face it is a difficult call to make given the pressures on time to deliver and impact/side effects due to a fix. Personally, I use the process listed below to evaluate the product quality. Base Rules - QA should have the same time (if not more) as the development to test the product. Most of the time QA lags the development and hence there is a learning curve for the QA. They need to know the features first, before they can start trying to break the features. - QA should have exercised all the features of the release in an in

I am sure that anyone who has gone through a complete software life cycle will understand what I am talking about. As the release date starts nearing, discussions starts on the number of defects that are still open and how we plan to address the same. This debates proceeds almost till the date of the release and many a times as the software is released, a plan for the "Service pack" that will address critical issues that have seeped through the product is put in place. Many of these discussions are painful and one of the primary reasons for the pain is due to the different perceptions on "Quality" of the software and whether one can say with a "clear conscience" that the product is ready to ship even though he knows that there are defects in the software. Obviously a good software practioner will not want to cause undue to pain to the end user of the software. If one scans through the litrature on Software quality, we will find two broad views. One v

Whenever the subject of Software quality is broached, immediately the arguments pertaining to the various constraints that binds the quality of software gets raised. So what are these constraints and how deeply they affect Quality. Before we take this discussion further, we need to root our discussions on one golden rule - "Customer/User is the King" and in case of any trade-off, the trade-off will be made in the best interest of the Customer/User. The second aspect we need to be clear on is, whether quality is an independent or dependent variable. I posit that, quality is a dependent variable and is always subject to constraints placed by other factors that the stakeholders of the software can control. Extending this argument further, let us look at what are the factors that control quality. By doing so we also get back to the idea behind the post i.e. the constraints on quality (more in context of software engineering). As I see it, the primary constraints that affect so

Over last few months, I have been privy to lot of talks on Software quality and how we need processes and tools in place to improve software quality. This discussion brings up an very interesting question. What is Software Quality? Basics first. Let us start with the definition of Quality: IEEE 610.12-1990) Standard Glossary of Software Engineering Terminology defines quality as: the degree to which a system. component, or process meets (1) specified requirements, and (2) customer or user needs or expectations (ISO 9003-3-1991) Guidelines for the application of ISO 9001 to the Development, Supply and Maintenance of Software defines quality as: the totality of features and characteristics of a product or service that bear on its ability to satisfy specified or implied needs . If we are to go by these definition, one thing becomes very clear. Quality is a function of user needs. As long as a product meets the specific requirements or needs of the customer/user, then it is con