The Complete Alphabet of Quality Software Systems: Conflicts and Compromises

Transcription

1 Siakas Kerstin V., Berki Eleni, Georgiadou Elli, Sadler Chris (1997). The Complete Alphabet of Quality Software Systems: Conflicts & Compromises. Lt. Gen. J. S. Ahluwalia (Eds.) Total Quality Management - The Transforming Role of Quality in a Turbulent World, The 7th World Congress on Quality & Qualex, Feb, New Delhi, India, Institute of Directors-IOD., Tata McGraw-Hill Publishing Company Ltd, New Delhi, pp The Complete Alphabet of Quality Software Systems: Conflicts and Compromises Kerstin Siakas 1 Eleni Berki 2 Elli Georgiadou 3 Chris Sadler 3 1 Technological Educational Institute, Department of Informatics, PO Box 14561, Thessaloniki, Greece, Tel fax : siaka@it.teithe.gr 2 University of Sheffield, Department of Computer Science, 211 Portobello Street, Regent Court, Sheffield S1 4DP, UK Tel : fax : mscb7@teach.shef.ac.uk 3 University of North London, School of Computing, 2-16 Eden Grove, London N7 8EA, UK, Tel: , fax: , e.georgiadou@unl.ac.uk / c.sadler@unl.ac.uk Abstract Quality, like beauty, is in the eye of the stakeholder; but there is more to it than meets the eye! Information systems have a multiplicity of people involved throughout their lifecycle. They are developed and they have a life, they evolve, adapt and die, hence we use many attributes relevant to all stakeholders namely users, developers and sponsors. Acceptability to reliability, correctness to usability, expandability to zoticality span the range of people involved either as actors or sufferers, as users or as financiers. In order to explore the way each stakeholder views information systems quality we use an attribute alphabet as a vehicle and a prompter. In this paper we identify the main attributes of interest and concentrate on the overlaps and conflicts of interest which inevitably lead to compromises for practical, logistic and financial reasons. Additionally, we examine variations within the stakeholders e.g. different types of user and developer for example software testers may conflict with analysts one finding errors in the work of the other.

2 We conclude by proposing a holistic approach to development, taking into account the worldview, worries and ideas of all involved. We combine ideas from the Soft Systems Methodology and techniques from semi-formal and formal methods.

3 1. Quality Factors / Attributes Quality according to the IEEE Glossary of Software Engineering Terminology [ ] is the degree to which software meets customer or user needs or expectations. Schneidewind [ ]states that a Quality factor is an attribute of software that contributes to its quality. According to these two definitions it can be said that quality factors are attributes that customers or users expect to find in the software. Thus software quality factors can be said to be customer or user oriented. We argue that different stakeholders have different perceptions about quality attributes. According to Gillies [ ] there are different views of quality, which may conflict which each other [ ]. The transcendent view: The classical definition of quality meaning "elegance". The product-based view: The economist's view: higher quality equals higher cost. The user-based view: It is meeting the users requirements and fitness for purpose. The manufacturing view: Measures quality in terms of conformance to requirements. The value-based view: Provide what the customer requires at a price they can afford. It is generally recognised that consistent quality will ensure repeat orders and help build a good reputation. Quality plays a vital role to achieving a competitive advantage, based on the notion of continuous improvement throughout the entire organisation. Quality is intertwined with process management, human resources management, organisational characteristics, and strategic and technological approaches. The alphabet to be discussed will provide indications showing conflicts and compromises, synergy and opposition, which of the stakeholders is concerned the most and where possible how much.

4 The alphabet Availability SW functioning in a satisfactory manner at a given time Boundedness Correctness SW that conforms to requirements Durability How long the SW will be used before replacement Efficiency SW making efficient use of system's resources Flexibility SW capable of changing in response to new conditions Genericity Standard SW without brand name????? Holisticness Integration Justifiability Know-how Learnability The ease with which the SW can be learned Maintainability The ease with which the SW can be changed Novelty The degree of novelty in the SW Operability Portability Ability of Software to operate in different environments Quantifiability Reliability SW consistent in its operations Reusability SW using/contributing to procedures in other systems Simplicity Testability The ease with which the system can be tested Usability SW that can be used for its intended purpose Verifiability Weltanshauung Worldview-ability expandability Ease of expanding the SW Y? Zoticality Figure 1. The Alphabeth 2. Stakeholders ISO is about Software Life Cycle Processes. It quotes ISO-9126 Quality Characteristics and ISO-9001 Quality Systems as normative. ISO gives guidance on identifying the role adoption and offers the concept of views to help identification of processes attached to a role. Processes can be divided in primary, support and organisational processes. Primary processes are acquisition, supply, development, operation and maintenance.

5 Support Processes are documentation, configuration management, quality assurance, verification, validation, joint review, audit and problem resolution. Organisational processes are management, infrastructure, improvement and training. Each process is decomposed into tasks and tasks are further decomposed into activities. According to ISO there are five views, namely: 1. The contract view (Acquirer, Supplier) 2. The Management view (Manager) 3. Operating view (Operator, User), 4. Engineering view (Developer, Maintainer) 5. Supporting view (Support process employer) Sponsor In this paper we group Acquirers, Suppliers and Managers as sponsor. Managers on different levels are the software developing company representatives. The management objectives are to make decisions in commitment with the owners objectives on strategic, tactical and operational levels and to control that these decisions are followed. When using different Decision Support Systems or Expert Systems managers themselves are users of an information system User User are considered by the authors to be the persons who in different ways use the final software product. Users can be either internal in the company that develop the software or external customers who buy and use the software Developer By developer the authors consider every person that not is an user or a sponsor who commit in some way to the development of the software. Developers can be the person who is carrying out Requirement Analysis, Analysis, Design, Programming, Testing and Maintenance and also persons doing Maintenance and supporting the process.

6 3. Software Quality Metrics (SQM) Direct measurement of quality factors can often be done first very late in the life cycle. For example reliability, which is concerned with how well as software system functions meet a user s requirements [Musa] can be obtained first after that the software has been used for a stated period of time under stated conditions, while indirect measurement of quality, like number of discrepancy reports (deviations from requirements) can be done earlier in the life cycle. Other estimates of quality can be made by developers even earlier than the indirect measurements of quality. This is the reason why according to Schneidewind [ ] metrics are considered to be developer oriented. Figure 2 shows a Software Quality Metrics (SQM) model which has been developed to allow the customer to assess the product being developed by a contractor. The model consists of attributes which are classified into product operation and product revision. Several criteria, which can be measured using different metrics, visualise the attributes. ISO-9126 is the first international standard to attempt to define a framework for evaluating software Quality. ISO-9126, software product evaluation quality characteristics and guidelines for their use, are heavily influenced by the SQM approach. According to ISO-9126 software quality may be evaluated by six characteristics, namely: 1. Functionality 2. Reliability 3. Efficiency 4. Usability 5. Maintainability 6. Portability. Each of these characteristics is defined as a set of attributes that bear on the relevant aspect of software and can be refined through multiple levels of subcharacteristics[fenton]. Definitions of subcharacteristics are given in the Annex A, which is not a part of the International Standard. Attributes at the second level of refinement are left completely undefined [Fenton]. Nevertheless, ISO-9126 is an important milestone for evaluating software quality.

7 Attributes Criteria Metrics Communicativness Usability Accuracy Product operation Reliability Consistency Devise Efficiency M E Efficiency Accessibility T Reusability Completeness Structuredness R I Product revision Maintainability Portability Conciseness Device independence C S Legibility Testability Self-descriptiveness Traceability Figure 2: A model for Software Quality Metrics (SQM)

8 4. Agreements, conflicts and compromises The alphabet Sponsor Developer User.Availability Boundedness *Correctness Durability Efficiency Flexibility Genericity Holisticness Integration Justifiability Know-how.Learnability *Maintainability Novelty Operability.Portability Quantifiability Reliability Simplicity Testability Usability Verifiability Weltanshauung (Worldview-ability) expandability Y? Zoticality Direct interest (+) Indirect interest (0) Figure 3. The stakeholders view According to Darrel [ ]first category quality factors are those which should be described in the requirements specification. One first category factor is correctness. Every stakeholder probably agree that correctness should be totally present in any software system. For the user is availability probably also of as great important as the correctness and obviously a first category quality factor.

9 A second quality factor according to Darrel [ ]is maintainability or modifiability. There are different categories of modifications, namely corrective changes, adaptive changes and perfective changes. The corrective changes are changes due to error fixing. The adaptive changes occurs due to developer responding on changes in requirements and perfective changes are changes which improve a software system [Darrel]. Obviously it is in the greatest interest of the developer that a software system is easy to maintain. Many software systems have a very high level of maintenance due to changes in requirements. These can happen due to customer s external circumstances change or because customers become more demanding. Maintainability is normally only of indirect interest to customer. According to Darrel [ ] very few customers include directives about maintenance in their requirement specifications. Maintainability is important to the developer because there is a correlation between maintainability and the degree of rework. The same reason is relevant to the sponsor but in terms of costs. Portability is normally of interest to the sponsor because of competitive reasons and only of indirect interest to the customer. If portability is of interest to the user it should be stated in detail in the requirements analysis. 5. Product - Process The customer s concerns on quality factors are rather different from those of the developers and the managers. Some quality factors are important to all stakeholders. Customers are mainly requiring a correct software, easy to use, ready in time to a price that gives value for money. Quality attributes considering the product is for the user of greatest interest. Developers are mainly interested in a structured software easy to maintain and to reuse. Sponsors are mainly interested in quality attributes that give satisfied customers to a low cost. Thus, the developer and the sponsor are concerned of quality attributes regarding rather the process than the product. References [ ] Fenton Norman. Whitty Robin, Iizuka Yoshinori [ed],1995: Software Quality Assurance and Measurement, A Worldwide Perspective International Thomson Computer press, London [ ] Gillies Alan C.,1992: Software Quality, Theory and management London, Chapman & Hall [ ] IEEE,1990: IEEE Glossary of Software Engineering Terminology, [ ] Musa J.D., Iannino A., Okumoto K.,1987: Software Reliability Measurement, Prediction, Application, McGrawHill,NewYork [ ] Schneidewind Norman. F.,1995: Controlling pedicting the quality of space shuttle software using metrics, Software Quality Journal 4, 49-68