1. © Martyn Thomas Associates 2005 1 Extreme Hubris Martyn Thomas martyn@thomas-associates.co.uk email me if you want evidence or references for any of the points made.

2. © Martyn Thomas Associates 2005 2 A typical development …. Initial requirements Invitation to tender Use Cases (consultants) Internal review Contractual requirements Changes Final System late, over budget, reduced benefits Changes Ideas from bidders

3. © Martyn Thomas Associates 2005 3 A truth universally acknowledged... ….. requirements always change. Some people argue that this means it isn’t worth spending effort getting precise requirements at the start of a project The latest manifestation of this absurdity comes as part of eXtreme Programming. –“We value responding to change over following a plan” The Agile Manifesto

4. © Martyn Thomas Associates 2005 4 Requirements and XP

5. © Martyn Thomas Associates 2005 5 Requirements always change Some changes are extrinsic: the external needs really change. –For example, the hardware can’t be built as specified. Or certification rules are changed. Many changes are intrinsic: the client discovers new or different requirements. – often in response to a question from the developers about an omission or ambiguity.

6. © Martyn Thomas Associates 2005 6 What to do? “ Embrace Change: be agile”  Break the development into small releases  Involve a user representative throughout the project Xdefine each release through user stories, test cases, and metaphors Xkeep all the documentation in the code  rebuild the system often and run regression tests Xprogram in pairs. Group ownership: change anything Xdon’t write any code that is not needed to pass the current test set. Refactor when needed. –Y2K as “re-factoring?”

7. © Martyn Thomas Associates 2005 7 No! Complex systems need system-level analysis and design In XP, systems evolve. Evolution is slow, and succeeds only through widespread failure. Darwin. Prototyping is a valuable way of exploring and developing user requirements, but prototypes are not deliverable products! Successful, deterministic development of complex artefacts can only be achieved through –abstract specification –analysis to identify and remove the causes of intrinsic change –strong management of extrinsic change

8. © Martyn Thomas Associates 2005 8 Abstraction requires precision! The two most important characteristics of a specification notation are (1) that it should permit problem-oriented abstractions to be expressed … not test cases! … and (2) that it should have rigorous semantics so that specifications can be analysed for anomalies and to explore system properties. Not stories or metaphors!! “In this connection it might be worthwhile to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise”. Dijkstra 1972

9. © Martyn Thomas Associates 2005 9 Strong Change Management

10. © Martyn Thomas Associates 2005 10 Dependability requires Evidence A dependable system is one which we can justifiably trust to have the properties we require. Build a system that you know will have the required properties Provide evidence that you have succeeded –it is rarely cost-effective to rely on testing for evidence of dependability

11. © Martyn Thomas Associates 2005 11 MANIFESTO * for Dependable Software Development We hold these truths to be self-evident: 1The major barrier to dependable software development is irreducible complexity 2Our predominant tool for mastering complexity is abstraction 3 The purpose of abstraction is “ not to be vague, but to create a new semantic level in which one can be absolutely precise” * from manifest = obvious; hence: a statement of the obvious

12. © Martyn Thomas Associates 2005 12 MANIFESTO f or Dependable Software Development 4We need to be precise to support accurate communication and precise reasoning. 5 Formal specification is therefore fundamental to Dependable Software Development (DSD). 6Without a formal specification, we cannot know what we are trying to develop, nor can we assess the implications of proposed changes.

13. © Martyn Thomas Associates 2005 13 MANIFESTO for Dependable Software Developmen t 7Errors are inevitable in any human activity; DSD therefore requires notations, methods and tools that reduce the probability of making errors, detect any errors as soon as possible after they are made, and support rigorous arguments that major classes of errors have been eliminated. In this way, DSD reduces costs, reduces risks, and enhances quality.

14. © Martyn Thomas Associates 2005 14 MANIFESTO for Dependable Software Development 8 Implementation languages should be strongly typed, unambiguous, analysable, and supported by deep static analysis tools. Lowry 1969. 9DFD requires mature engineering processes, competent and experienced staff, and rigorous quality management. 10 The evidence for dependability that can be provided by testing is generally weak and almost never cost-effective.

15. © Martyn Thomas Associates 2005 15 MANIFESTO for Dependable Software Development 11 At 99% confidence it is almost always absurd to claim a lower pfh than 10 -4 for any system containing software. With one exception: zero. 12 The Safety Integrity Levels in IEC 61508 and elsewhere are therefore absurd. We need new DSD standards based on formal reasoning about specified properties, and incorporating the principles of this Manifesto.

16. © Martyn Thomas Associates 2005 16 The Path to DSD Establish mature, auditable processes (ISO 9001, CMM Level 3 etc). Introduce formal specification of all important system properties. Introduce rigorous design leading to implementation in a language that supports strong static analysis. Write reasoned dependability arguments (eg safety cases) based on the evidence from analysis. Do not tolerate defects: investigate root causes and improve the process.

17. © Martyn Thomas Associates 2005 17 Questions and Discussion