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

2. Lecture BA18 Good Enough Software
Session schedule
Business Analysis Schedule
Academic Year
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

3. 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

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

5. 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

6. 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

7. 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

8. 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

9. Lecture BA18 Good Enough Software
References
Bach, J. (1995). "Enough About Process: What We Need are Heroes," IEEE Software, vol. 12, no. 2, pp
Känsälä, K. (2004). "Good-Enough Software Process in Nokia," Lecture Notes in Computer Science, vol. 3009, pp
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
Lecture BA18 Good Enough Software