CHAPTER - 4: QUALITY STANDARDS: THE MISSED OPPORTUNITIES

Transcription

1 CHAPTER - 4: QUALITY STANDARDS: THE MISSED OPPORTUNITIES 79

2 Chapter - 4: Quality Standards: The Missed Opportunities 4.1 Introduction Conventional Engineering streams like Mechanical, Electrical and Civil have evolved over centuries and hence their standardization also evolved over a long period of time. The integration of these standards adopted in different geographical locations/countries has started with the establishment of ISO in 1940s to improve the commercial activities across the nations by removing the barriers of different standards. Moreover in most of these conventional engineering fields, the tasks are repetitive whereby the improvements can be seen in terms of benefits accrued due to optimizing the activities and thereby reducing the efforts/costs in production. Comparable to these conventional engineering streams is the developments in electronic hardware that have relatively taken few decades to develop, but the standardization has maintained phase with the advances in the hardware technology in these fields as the production of electronic hardware has to be on large scale. Because of the mere size of the production requirements, it can be seen that it not possible for any single organization to meet the demands for these goods. Hence, many organizations have started producing the hardware. Often organizations producing the same hardware standardization is a must. Similarly as the products are becoming complex and the production numbers are increasing, it has led to assembly line of production mode where specialized units produce components rather than an organization producing everything it needs. This need has further enhanced the rapid development of standards to achieve standardization of the components which has lead to open system integration of these components. When compared with these domains of engineering, computer science and software engineering are relatively quite new and their growth has exploded in few decades. As the computer hardware technology is mostly electronics, the standardization of the components took relatively less time. 80

3 Like most of the Asian Languages failed to evolve with the technology and could not generate the equivalent technical terms, they are forced to use English by compulsion as a standard for technology. Even nations as big as India and China which have ancient cultures and given the world the initial lead in technologies failed to evolve their languages to cope up with the technology. This is another example of opportunities lost for standardization. The evolution of software quality standards and accompanying audit standards has missed many opportunities to cope up with the advancement of software technology. This has forced software professionals to look at the existing standards like TQM, ISO standards etc with an eye of adopting them. But many of such adoptions also could not address the needs of software industry. Even the standard like CMMI that is aimed at software development process could not meet the desired results due to its mere size of specifications and requirements. Even such huge standards could not be readily applied for small projects or in small organizations. Many highly complex applications that are developed with millions of man years of effort have moved over to maintenance phase. These standards failed to address directly the maintenance and testing projects which have gained equal commercial importance as that of software development. Further, these standardizations could not meet all the process requirements of an organization with its many support functions. Another scenario where standardization has failed is to address different business and working models of organizations. Even merger of many of the standards could not address the needs of an organization. SPICE is one such attempt to integrate relevant standards that has not yet seen success and acceptance. 81

4 4.2 Software Development Versus Other Hardware Development Coming to software the development history is totally different and it differs in many respects compared to either conventional engineering streams or electronics or even computer hardware in many respects. 1) Software is not production, but mostly one time development effort. Every software development project is unique and not done in the same way. Hence, the advantages of observing improvements over a repeated production line are not available in software development activities. 2) Software development is basically a mental process and hence it is individual based. The same tasks can be achieved in a number of ways and with differing complexities that depend on many factors like the skill and knowledge of the developer and the approach adopted etc. Hence standardization of the software product is not possible. 3) Software has entered into every stream of human activities and it is influencing every sphere of human life. Hence, the domains to which software development is relevant are limitless ranging from health care to technology to commercial activities to administration (e-governance). Hence, a common standard of processes for software covering all domains may not be possible 4) The software technology has improved many folds with in a very short time; to be precise less than four decades and the changes were so rapid that a person not keeping updated his/her knowledge on day to day basis is considered as illiterate in software technology parlance.the computer technology and especially software technology was very rapid and has exploded in a few decades. The technology and the areas into which software has invaded were changing quite rapidly. Hence, the standardization of software development processes could not catch up with the high rate of advancement of technology. 82

5 5) In an attempt to catch-up with fast changing software technology many standards have been developed. A quagmire of these standards has been effectively illustrated by Sarah (Sheard Sarah A, 2011) as shown in fig-1.1 This illustration clearly explains how many attempts have beenmade to bring standardization into software and how fast each one of them has faded into background by losing its relevance to the speed of advancement of software technologies. 6) In this rapidly varying process some of the technologies have become de-facto standards. Hence, standardization in software is a herculean task. 1.3 Criticality of Timing of Standardization: The theory of apocalypse of the two elephants The time at which a standard is developed is absolutely important and critical to the success of the standard. This is explained by David Clarke of MIT which is called apocalypse of the two elephants which is shown in fig-4.1. Fig-4.1: The apocalypse of the two elephants (This diagram is adopted from (Tanenbaum 1998) 83

6 The first peak in the picture shows the time of research activity surrounding a new subject. When a new subject is discovered first, there will be lot activity in the form research, discussions, papers and conferences etc. Once it has gained enough ground, the investors in the technology start developing products by investing money into making the products. This again is a rapid activity as shown by the second peak. The standardization of the subject/technology should take 63 place during the trough between these two peaks where the time is too short and standardization has to happen rapidly before the products are getting into production lines. Thus the standardization trough is to be squeezed between the two elephants (the two peaks). If the standardization has started too early, then it will prove to be bad technology as developments and changes happen rapidly making the standardization obsolete. If the standardization happens too late then the products already developed on the technology become defacto standards. One such standardization which missed the opportunity to become the leading industry standard is the Open Source Integration (OSI) reference model of network protocols that was brought out by ISO in early 1980 s. \ The Advanced Research Projects Agency (ARPA) of Department of Defense (DoD) of USA developed a project for communicating between two computers and called it ARPANET. Formally this has been brought out as Transmission Control Protocol/Internet Protocol (TCP/IP) reference model in ISO was too late in coming out with a standard which it brought out as OSI Reference Model. But by that time TCP/IP has gained wide popularity and many products were available in the market and shifting from TCP/IP reference model to OSI model was not economically and technically viable and not manageable. Thus even though OSI model is ideal reference model TCP/IP has been accepted as industry standard, even though formally it is declared as a standard. This is also true with software development standardization that has missed the opportunities more than once. 84

7 4.4 The Missed Opportunities of Standardization of Software Processes Management Missed Opportunity 1: The software development activities started in 1970s and started growing rapidly in mid 1980 s that continued into early 2000 s. But as can be seen the first CMM model has come into existence in 1993 much later than the technologies and software development processes have advanced into many domains. Similarly the first process oriented quality management system standard from ISO has appeared in 1987 and its interpretation to software industry took quite some time. Even though many more standards have come into existence (as shown in fig-1.1) regarding software development process standardization, the relevance of each one of them was lost in short time of its coming into existence. Missed Opportunity 2: Both CMMI and ISO 9000 standards have proven to be more oriented towards large software development projects requiring huge efforts in developing detailed Quality Management Systems (QMS) and were process heavy standards. Even though huge software projects were common in 1980s through early 2000 where implementation of these standards justified the efforts, small projects started getting developed and even small software development organizations started coming up that can give quick development lifecycles. Application of these standards proven to be infeasible in such situations and the standards failed to come-up with versions that can be directly applied to small projects/organizations. Missed Opportunity 3: Both CMM and ISO were more oriented towards development and production respectively. But most of the huge software that were developed have entered into their usage phase and needed 85

8 continuous updates either to accommodate new business requirements or to fix the bugs in the existing software that normally surface after much time of starting their usage. This software maintenance has itself become a huge revenue resource for many software providers. But again the frameworks like CMMI and ISO failed to address these areas until almost the year 2000 when ISO brought out its new version of 9000 series standards where the service issues are addressed. CMMI could bring in some kind of framework only in 2010 in terms of CMMI- Services. Missed Opportunity 4: Software testing has evolved into itself a huge revenue earner and many organizations that specialize in software testing have come into existence. But again these standards failed to bring in any specific standards for testing. Missed Opportunity 5: With advances in telecom sector many new technologies have come into existence like mobile applications that run on cell phones whose processor capability is limited and hence the compactness of the software has increased and lifecycle times for development has come down. Again these software standards missed the opportunity to address these new technologies. Important Observation: Many of the huge multinational like IBM, HP (or many of the earlier constituents of these companies like Compaq, Tandom Computers etc) etc have not adopted any of these standards but achieved their success which clearly shows the ineffectiveness of these standards. 4.5 Development of COPC standards versus Development of Software frameworks 1. COPC standards are developed based on a strong foundation of Maclolm Baldrige Quality Model while CMMI framework is based on DoD requirements of assessing the skills of software providers. ISO 9000 is based on production floor experience and involves Technical Committees and are voted by Government agencies. 86

9 2. COPC standards have involved all the stake holders (those who use these standards indifferent capacities) that included clients, service providers, end users, practitioners and standardization agencies. Hence, their suitability to address the needs is more intense. 3. COPC standards specifically developed the processes for each of the specific type of services and hence their adoption is much wider. ISO is very generic and CMMI is generic to software activities. Even within software activities, the standards are not specific to each line of services like software development, software maintenance and software testing. 4. COPC has brought out clearly defined set of metrics for each line of service and hence benchmarking is quite easy across organizations. Neither ISO nor CMMI-Development nor CMMI-Services have any specific set of metrics for each kind of services 5. The amount of documentation work is much less to meet COPC requirements while this task is huge for both ISO and CMMI frameworks. Hence, the popularity of COPC standards is very clear which is adopted by more than 1300 organizations across the world within a short span of time. 4.6 Auditing Techniques: There is a clear count of audit points that can be assigned for confirming to the requirements of COPC standards and the audit/assessment is quite objective. But the audits/appraisals in the case of ISO 9000 and CMMI are highly subjective and cannot be quantified. 4.7 Conclusions The study brings out the cost of loosing opportunities to evolve software quality standards and accompanying audit standards in terms of lack of a particular standard that can give the confidence to the customers and industry to judge the quality of the software development, maintenance and testing. A different approach is needed to address these needs.