Chris Russell O2.41 02920 41 6431 crussell@cardiffmet.ac.uk Business Analysis Good Enough Software Chris Russell O2.41 02920 41 6431 crussell@cardiffmet.ac.uk Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Session schedule Business Analysis Schedule Academic Year 2014-5 Semester 2 Week Topic 1 Introduction 2 Investigate situation: rich picture, context diagrams 3 Consider perspectives: types of participation, CATWOE, Power-Interest, Thomas-Kilmann 4 Analyse needs 1: Use Cases 5 Analyse needs 2: structured techniques 6 Define requirements 1a: SSADM 7 Define requirements 1b: SSADM EASTER 8 Define requirements 2: UML 9 Generic assignment feed-forward and task review 10 Balance good enough software against quality costs; Prioritise requirements 11 Assignment submisison Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Quality Issues Trade-offs exist between our quality attributes Security <-> Performance Portability <-> Functionality Trade-offs also exist with our three other key variables Quality is a subjective measure Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Trade Off Triangle(s) Time and/or Cost Scope Quality Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Perceptions Perhaps the key to the right balance is to understand the perceptions of the user and sponsor Would they notice the difference between the best possible quality and pretty good quality? What would constitute adequate quality? The answer will depend upon the domain of the system and attitudes to risk among other factors Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Bugs may be tolerated ‘Apple shipped the first version of Hypercard with about 500 known bugs in it, yet the product was a smashing success. The Hypercard QA team chose the right bugs to ship with. They also chose the right qualities… it isn’t the number of bugs that matters, it’s the effect of each bug.’ (Bach 1995: 96) Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Utilitarian approach Based upon the ‘greatest happiness principle’ (Mill 2001[1871]: 12) Advocated first by Bach in the context of software (1995) – who also coined the term ‘good enough software’ – and supported by others such as Yourdon (1995) and Känsälä (2004) Entails (Bach 1995): Evolutionary development cp. RAD Heroic teams Dynamic infrastructure and processes Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software Limitations May not suit an emphasis on quality standards/strategies such as ISO 9000 and six sigma May contrast with the perception of the programmer May necessitate an increase in time and cost devoted to testing and releasing of subsequent patches Does not suit certain domains (Reed 2003) Lecture BA18 Good Enough Software

Lecture BA18 Good Enough Software References Bach, J. (1995). "Enough About Process: What We Need are Heroes," IEEE Software, vol. 12, no. 2, pp. 96-98. Känsälä, K. (2004). "Good-Enough Software Process in Nokia," Lecture Notes in Computer Science, vol. 3009, pp. 424-430. Mill, J.S. (2001[1871]). Utilitarianism, New York: Routledge. Reed, K. (2003). "Good Enough Is Not Good Enough," IEEE Software, vol. 20, no. 5, p. 109. Yourdon, E. (1995). "When good enough software is best," IEEE Software, vol. 12, no. 3, pp. 79-81. Lecture BA18 Good Enough Software