1. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 1 T-76.5650 Sotfware Engineering Seminar Introduction

2. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 2 Outline  The topic of this course  Why are quality attributes important?  Why are quality attributes difficult?  Quality attributes vs. functionality  Definition of the concept  Quality attribute classifications

3. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 3 The topic of this course

4. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 4 The topic of this course Reliability Interoperability Performance Usability Scalability Security Availability Maintainability Modifiability Testability Safety Survivability Confidentiality Portability Dependability Timeliness Integrity Fault-tolerance

5. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 5 The topic of this course Testing, QA Detailed design, implementation Requirements Software architecture Quality attributes Functionality Lecture 2 Lecture 3 Lecture 4

6. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 6 Group discussion  Identify example real-life systems and quality attributes that are important in them. These examples could be systems you have used, or systems you have developed. How does the system implementation reflect these QA requirements?  Can you find an example of a system that has no QA requirements, or the QA requirements are so insignificant that they pose no constraints on the system implementation?

7. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 7 Why are quality attributes important?  Are often more critical than functional requirements (Sommerville, 2004)  E.g., if an aircraft system does not meet its reliability requirements, it will not be taken into use  Affect how user perceives the quality of the product  E.g., ackward usability is a sure way to annoy user  Often cross-cutting throughout many functions, difficult to avoid or find countermeasures  Despite this, the software development in many companies is feature-driven  Perhaps functionality is easier to be marketed…?

8. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 8 Why are quality attributes difficult?  Firstly, it is often surprisingly difficult to pinpoint them in a measurable and observable requirement  “The system shall be robust.”  Secondly, quality attributes often depend on the system as a whole, not on a single service or subsystem  How to pinpoint the location in the system where reliability is realised?  Thirdly, quality attributes are often in conflict with each other and with functionality  See next slides

9. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 9 QAs can be in tradeoff with each other (Barbacci et al., 1995)

10. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 10... And with business qualities Low cost Short time-to-market High quality Inexpensive; lower quality; longer time-to-market More expensive; moderate quality; moderate time-to-market Expensive; high quality; longer time-to-market (Rozanski and Woods, 2005)

11. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 11 Why are quality attributes difficult?  Despite the interaction between different quality attributes, the research is, for historical reasons, divided into several communities  Performance community  Reliability community  Security community  Usability community  Etc.  Difficult to get an overview of approaches, difficult to find good cross-cutting articles

12. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 12 Quality attributes vs. functionality  What is the relationship between functionality and quality attributes?  Functionality and quality attributes are orthogonal (Bass et al., 2003)  The choice of functions does not dictate the level of quality attributes  However, functionality affects the achievement of quality attributes  Quality attributes act as constraints on functionality (Sommerville, 2004)

13. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 13 Quality attributes vs. functionality  Do quality attributes exist per se?  Many quality attributes cannot be separated from raw behaviour  Often impossible to say: ”quality of system is X” without reference to system functions  Functionality tells what the system does, quality attributes specify how the system does it  Often, in order to achieve quality attributes, certain functionality is added to the system  Quality is transformed into functionality in the development lifecycle  In the end, there is a piece of executing software that behaves in a certain prescribed way

14. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 14 Definition of the concept

15. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 15 The topic of this course Reliability Interoperability Performance Usability Scalability Security Availability Maintainability Modifiability Testability Safety Survivability Confidentiality Portability Dependability Timeliness Integrity ? Fault-tolerance

16. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 16 The mess around the concept  The concept in the center of this seminar course is called differently in different contexts  Although these terms are often used to refer to same things, there are subtle differences between selected words Non-functional Requirement Property Quality Attribute

17. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 17 Quality attribute, quality property  Often used as synonyms  IEEE Standard Glossary of Software Engineering Terminology (IEEE Std 610.12-1990)  Quality attribute: A feature or characteristic that affects an item’s quality  Quality: (1) The degree to which a system, component, or process meets specified requirements (2) The degree to which a system, component, or process meets customer or user needs and expectations  A quality property is an externally visible, non-functional property of a system such a performance, security, or scalability (Rozanski & Woods, 2005).

18. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 18 Quality attributes  Previous definitions are perhaps not self- explanatory  Quality attributes are often defined by enumerating and classifying them, and then giving more concrete definitions to subattributes  Different classifications exist (e.g. ISO/IEC 9126; Avizienis et al., 2004; Barbacci et al., 1995)

19. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 19 Non-functional requirement (NFR)  Is often used a synonym for quality attribute or quality attribute requirement  Functional requirement: A requirement that specifies a function that a system or system component must be able to perform (IEEE Std 610.12-1990)  Functional requirement: statements of services the system should provide (Sommerville, 2004)  Non-functional requirement: constraints on the services or functions offered by the system (Sommerville, 2004)  Note: we are talking about a requirement, not a characteristic of the software itself (property, attribute)

20. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 20 Non-functional requirement vs. quality attribute requirement  Non-functional requirement == quality attribute requirement?  Example non-functional requirement: The software development process should conform to standard XYZ.  A constraint (Sommerville, 2004)  Example quality attribute requirement: Software should authenticate all users.  Security requirement, yet functional in nature Quality attribute requirements Non-functional requirements

21. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 21 Which term to prefer?  I personally like to refer to “quality attributes”  No confusion about what is functional and what is not  Refers to a characteristic of the software  Taxonomies exist, even a standard  Often used when discussing software architectures  However, you can pick the one you like and stick to that  Take into account the connotations of your term  Remember to use different terms when searching for articles!

22. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 22 Quality attribute classifications

23. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 23 Classification of QAs  Why classify quality attributes?  A way to define quality attributes by dividing them into subattributes and giving more concrete definitions to them  Quality attributes in the same class often behave in a similar fashion  Specification, realisation, verification  Classification into observable and not observable via execution (Bass et al., 2003)  Observable via execution  Performance, security, reliability, etc.  Not observable via execution  Maintainability, testability, portability, etc.

24. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 24 ISO/IEC 9216 Quality model framework process quality internal quality attributes external quality attributes quality in use attributes process measures internal measures external measures quality in use measures ProcessSoftware product Effect of software product influences depends on contexts of use

25. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 25 ISO/IEC 9126 Quality model for internal and external attributes

26. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 26 Classification of ependability  Dependability = ability to deliver service that can be justifiably trusted  Is divided into the following five attributes (Avizienis et al., 2004) Dependability Reliability Availability Safety Integrity Maintainability See also security Especially from fault removal and repair point of view

27. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 27 Classification of security  Security = the capability of the software to protect information so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them (ISO/IEC 15408-1, 2001)  Security is divided into the following attributes (Avizienis et al., 2004) Security Confidentiality Integrity Availability Confidentiality Integrity Availability

28. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 28 Classification of maintainability  Maintainability = the ease with which a software system can be maintained  However, some treat maintainability as a synonym for modifiability, some treat them separately (Matinlassi and Niemelä, 2003) Maintainability Flexibility Reusability Modifiability Testability Integrability Extensibility Portability

29. SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY © Varvana Myllärniemi, 2006 29 References Avizienis, Algirdas; Laprie, Jean-Claude; Randell, Brian and Landwehr, Carl. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004. Barbacci, Mario; Longstaff, Thomas; Klein, Mark and Weinstock, Charles. Quality Attributes. SEI Technical Report CMU/SEI-95-TR-021. 1995. Bass, Len; Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2nd edition. Addison- Wesley, 2003. Clements, Paul; Kazman, Rick and Klein, Mark. Evaluating Software Architectures. Addison-Wesley, 2002. IEEE Std 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. 1990. ISO/IEC 15408-1. Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model. ISO/IEC Standard 15408-1, 1999. ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model. ISO/IEC Standard 9126-1:2001, 2001. Matinlassi, Mari and Niemelä, Eila. The Impact of Maintainability on Component-based Software Systems. Proc. of EUROMICRO Conference (EUROMICRO’03). 2003. Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005. Sommerville, Ian. Software Engineering. 7th edition. Addison-Wesley, 2004.