TechJunkies series: Importance of “Quality” in application software, myth or reality
September 17, 2008
I have been working in the IT industry for quite sometime and one word that i really fail to understand is “QUALITY“. When i say i fail to understand i do not really mean the meaning of the word “QUALITY”, this is probably the first most or second most spelled out word in the IT industry today so understanding the meaning is no big problem.
What i really don’t understand is the “QUALITY” practice (followed in many companies). Many companies speak a lot about the importance of quality, if you are one of those blessed souls who get a lot of opportunities to visit many events in this tough economic situation then you must have heard executives boasting about the sophisticated quality processes, quality by design etc etc etc.
What keeps me wondering is whether these companies really mean what they claim? Do they really give enough importance to quality? is it just a marketing gimic to capture the imaginations of a prospective customer or is it really taken seriously? Honestly, i am struggling to find answers for all these questions.
In my opinion, quality is just another step in the software development life cycle for many companies. Quality is never taken seriously by product managers while defining the product, never taken seriously by architects during design, never taken seriously by developers while programming (and unit testing), surprisingly not taken seriously even by so called quality testers (they just do a monotonous job of testing the product based on the test specification, what happens if the test specifications are biased towards the happiest flow of a produdct – in many cases it is).
How is the situation if you start thinking on parameters like ratio of number of quality testers per developer? Is it dismal or healthy (many cases it must be pretty dismal). Due to the crowded development organization, the amount of code generated in a software development lifecycle is humungous, many many times more than the capacity of the quality management team.
How is the situation if you start thinking on other important parameters like product planning? How much time an executive allocates for quality management to test a product? In many cases it is minimal leaving the quality testers to do fire fighting.
I am not being pessimistic about the current situation, i am sure there are many companies in the IT industry that are exactly not doing what i have outlined above but how many such companies exists? how many companies are hungry to launch a quality product and not just another product?
Closing remark: Companies must start looking at quality right from minute someone starts talking about an idea that has the potential to become a product. Hitting the market early might help a lot in early sales, but hitting the market early with bad quality product shall keep the product in the shelf (and not an inch beyond that). Quality may be a myth now but companies must make quality a reality to be successful in the prevailing competitive environment.
Man ,
It took you ages to publish this second blog
By experience i can tell that there are organizations where Q:D ratio is 2:1 . Even then the quality team feels streched out. So i agree that the ratio has to be increased however there are organizations where the ratio is probably reverse and its really hard for Q teams to help measusring the quality
~Abhishek
Hi,
I think you mis understand, Quality parametrs at each stage are quite different, for the Quality of an architecture to be measured what is the KPI that you would set? TCO – right and at that point in time if you commit this is what we will meet the QA Correspondent would see and agree.
Always in Core Technology the person agreeing to the Design/Architecure needs to be such an expert who is revred and really knowledgable, in the same technology.
What you talk about is testing, even which is considerably a monotonous job, but the core should be testing the functionality.
You are right when you say no single team can make sure that the quality should be met but we should all have the Quality aspect imbibed in us and also have a simliar definition.
Bigger organizations do not buy expensive software products until they do their own TEsting on the propected software.
It is one thing similar to going to a 5 star hotel and not liking the service and saying the quality is not good, but it is a 5 star hotel !
Quality in the end is just a feeling, so we should just develop this feeling, a sense to a product/service like seeing/listening is to us. irrespective of all the process that we put in place.
This is my take on the subject.
The traditional view on software development projects is that there is always a tension between time, money and quality. “You can’t have all three”, is the widespread software engineering truism, also known as the famous ‘devil’s triangle’. The common conviction is that a need to cut costs will inevitably result in a lower quality, or that strict ensurance of quality will probably jeopardize the project planning. It rarely happens that quality is deployed explicitly as a means to bring a project back on track. Existing methods of project scheduling focus on time/cost tradeoffs, but do not model quality explicitly.
I like to make a stand against this subsidiary role of software product quality. Based on my own experience as an architect and consultant in a large variety of software development projects, I’m convinced that it is the lack of the quality that is expensive, not the quality itself. Software product quality is an excellent vehicle for the alignment of the software development process with the business goals.
In recent years, software products have increased in size and complexity, becoming a critical and strategic asset in the organizations’ business. In this scenario, to obtain software products with the appropriate level of quality, under the time and resources constraints established in projects, is a challenge. In spite of the fact that standards and methodologies to promote software quality assurance have been continually proposed, lacking software product quality is still responsible for a considerable increase in the total cost of many software-intensive systems. Although many successful software products exist today, the overall lack of attention to software quality has also led to many problematic systems as well as to many software projects that are late, over budget or cancelled. Latent defects and difficulty in maintaining or extending complex code have a dramatic impact on business competitiveness.
Although the majority of the software development cost is spent on quality-related issues such as quality control and maintenance, quality is rarely regarded as a predominant driver for a software development project. The traditional focus during software development is on functionality, only too often at the cost of quality. Of course it is vital that a system has the functionality as agreed-upon by stakeholders and expected by end-users; however in a recent report from Standish Group it is reported that an average of 64% of functions of software systems is never or rarely used. Hence the dominant focus on functionality cannot be justified from a pure business point of view. Other factors must be taken into account to explain the underrated position of quality in most software development projects.
First of all, functionality is often more tangible then quality: most features can be simply demonstrated by execution of the software system in front of stakeholders, while it is more difficult to substantiate the surplus value of software product quality. This is further emphasized by most development methods, which hold software developers responsible for delivery of the specified functionality in the first place. Unfortunately, even the modern Agile approach has the tendency to underestimate the value of quality-driven development by its focus on ‘working software’.
The pressure on development teams to make it to the next release will also put the focus on functionality. When the deadline for a software release looms ahead, quality is among the first ‘victims’ in the endeavour to meet the milestone on time. Especially in a multi-disciplinary environment, the need to synchronize the involved disciplines can overrule the software quality requirements in order to maintain the pace. But it is not common practice, however, to reserve time and resources in the next iteration to repair the lost quality. Due to repeatedly rushed work, quality-related issues will pile up each increment. Not surprisingly, this way of working will in most cases yield a system with serious quality flaws at the first release, resulting in expensive maintenance activities or even costly recalls.
Hence, the desired software quality must have a crystal-clear relationship with business goals and end-user expectations. Not only the overall level of quality must be appropriate to the product, also the prioritization of quality requirements is a prerequisite for a successful quality-driven development project.
Experience shows that it is of overriding importance to make an upfront selection of the most relevant quality requirements. Only a shortlist of at most five explicit quality attributes, agreed upon by all stakeholders, is perceived to be practical as driver for software development projects. This list must include items that will give the final product distinguishing characteristics, as well as quality aspects that will be very costly (or even impossible) to build-in or enhance afterwards. In most cases, the preservation of critical (existing) quality attributes is equally important to the enhancement of quality attributes that are crucial for competitive position of the product.
It will be clear by now, that the software quality issue has its roots in the requirements phase. Software product quality is often expressed by stakeholders in rather vague terms. It is generally taken to mean that a software product provides value to its users, generates few serious complaints, and of course makes a profit. However, presenting hard facts that underline the return on investment in quality is a different story. To prove its worth, software quality must be defined in an explicit and tangible way. When a quality aspect of a software product is not concrete and measurable, it is meaningless as a driver for the software architecture, useless as criterion for the completion of tasks, and powerless as part of formal acceptance tests.
In order to become a mature discipline, software engineering must be able to define its quality lexicon in the most concrete and comprehensive terminology, applicable in a wide variety of domains. Only when explicit quality criteria are part of the overall specification, design and implementation process, it will be possible to predict and guarantee the project result. A solid basis for the measurement of software quality is the ISO/IEC 9126 quality standard. This pragmatic model comprises a collection of quality attributes, metrics and examples of measurement protocols.
An important aspect of this ISO 9126 quality model is the distinction between the perspective of the developers and the stakeholders (especially the end-users of the software product). The internal and external quality is described according to six ´basic´ quality features, namely functionality, reliability, usability, efficiency, maintainability and portability. Furthermore, the perspective of the end user is addressed with quality attributes such as effectiveness, productivity, safety and satisfaction.
Specifying software quality for a product that has still to be developed is difficult for the purchaser or supplier. The purchaser needs to communicate requirements for the product to be developed in an unambiguous way. The supplier needs to be certain that the requirements are clearly understood. Both must be able to assess with confidence whether it is feasible to create a product with the appropriate level of software quality.
Consequently, the ISO 9126 model will serve to eliminate any misunderstanding between purchaser and supplier. This improvement in communication will do away with any rework required as a result of the software product not meeting the purchaser’s requirements. Both the time taken to deliver the specified software product and the cost of development will diminish as a result of adherence to the ISO 9126 standard.
Also with existing products or running projects, the ISO 9126 model will help to take advantage of quality-driven engineering. For a quality improvement program to be effective and profitable it is absolutely necessary to establish a named relationship between the problems encountered in real-life cases and explicit quality attributes of the software system under scrutiny. The ISO 9126 model provides the key definitions and measurement protocols that can be shared between stakeholders in order to obtain the buy-in and support to work on quality issues which are directly related to problems in the field.
With today’s complexity and proportions of software systems, it is virtually impossible to perform meaningful quality measurements without professional tooling. Sophisticated software metrics will be needed to underline the relationship between certain characteristics of the source code and properties of the final software product. This is useful in predicting whether the ultimate system will possess the required level of quality, as well in analyzing the flaws of existing systems in order to solve legacy problems and/or rectify error-prone practices in the development team.
A common challenge for advanced source code analysis tools is that they must be effectively geared to the problems at hand. Churning out of an overwhelming stream of information, cumbersome interpretation of data, production of a long list of false positives, etc. – if these items are on your list, you have the ingredients to spoil a fruitful deployment of any quality tool. Furthermore, it is impossible that a tool will give you all relevant information directly out of the box on a silver plate. Hence, the learning-curve to really understand what is being measured and to fine tune and adapt the tool’s features is equally important for a lasting utilization of the tool. And finally, since resources are scarce in most projects, the availability of an expert in both the tool and the domain is a decisive factor for a successful introduction of structural measurement of source code quality.
Quality-driven software development will help you to prevent or solve many common problems in software development projects, such as late delivery, increasing number of problem reports, legacy issues, instability caused by software faults, persistent and expensive problems with performance or connectivity, etc. However, as underlined by the above examples, a correct selection of the applied metrics is essential to have the full business-related benefits of source code analysis. In addition, successful deployment of a sophisticated tool requires a combination of domain knowledge, programming experience and familiarity with the tool.
The selection of the most relevant ISO 9126 quality attributes is often a stumbling block. Stakeholders must reach agreement about their views, expectations and demands regarding the quality of the software product. However, utilizing the ISO 9126 model, it is feasible to arrive at a shortlist with the five most significant product quality features, including domain-specific definitions and indicators. This agreement is the fundament to introduce or to intensify any quality program.
Experience learns that quality attributes related to maintenance issues are always high on this short list of most relevant quality requirements. This will not come as a surprise, since the overhwelming part of the total production cost of most software systemens can be traced back to software maintenance activities. It’s a blessing in disguise that source code analysis will yield tangible information with respect to maintenance-related quality aspects such as analysability, changeability, testability and reusability. Structural monitoring of these quality attributes during the software development life cycle right from the beginning will significangtly drive back the overall software development and maintenance cost. To make a long story short: software quality management has a high return on investment.
18 september 2008
Erik Philippus
ImprovemenT
Erik.Philippus@improvement-services.nl