1 / 16

Grown-up Software Development

Grown-up Software Development. A Summary and Methodological Principles. Immature discipline.

aria
Download Presentation

Grown-up Software Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Grown-up Software Development A Summary and Methodological Principles

  2. Immature discipline In spite of its 50 year history, software development is a curious immature affair. To do better we must recognise the great variety in our problems and products, we must think consciously about development risks, we must focus our attention where it matters, we must learn from experience, and we must be masters, not pedants, of development methods. • Michael Jackson, “Problem Frames”, p333.

  3. State of the art • 50 years on we have • Programming languages • Compilers • IDEs • GUI builders • Common applications • The Web • But software quality suggests the discipline is still in its infancy

  4. Panaceas & silver bullets • Structured programming • Flow charts • Structured methods • 4GLs • Prototyping • Development processes to support the entire lifecycle • Humbug and snake oil

  5. Become a master • A master • Recognises the need for different notations and techniques • Knows when to use which technique • Is not a pedant – can tailor methods • Must understand the rules very well

  6. Understand failure • Engineers ask “how/when will this fail, what happens when it does?” • Software only fails because it is wrong; this is a development failure • reason about the consequences: • How hard is this to get right? • How/when will I know if it’s wrong? • How bad will it be if it’s wrong? • How easily can it be fixed if it’s wrong?

  7. Amatuerism • Failing to consult or use existing specialised knowledge of a problem domain • What algorithm do you use for a cruise control? – ask a control engineer. • Don’t invent financial auditing rules yourself for a finance system • Etc.

  8. Complexity • Real problems are complex • Postpone composition until you have mastered the components, or • Postpone the solution until you have analysed and understood the problem • That’s what’s wrong with top-down • Reverse composition of something we don’t understand to create components that are probably wrong

  9. Frames in Perspective • PFs let you classify development problems • Guide decomposition by showing a repertoire of subproblems you know how to handle • They DON’T WORK for every kind of problem in every situation • Pure maths: no domains or interfaces • GUI – use a standard GUI builder • Compiler – use established texts on compiler design

  10. Principles of Methodology • Beneficent difficulty* • Close-fitting frames* • Commensurate care • Deferred invention* • Dispassionate methodology* • Domain relevance • Frame exploitation* • Problem sensitivity • Uniform mood

  11. Commensurate care The care taken in each aspect of a development should be proportional to PD where P is the probability that it will go wrong, and D is the size of the disaster if it does. • If you need to fudge something, do it where it will do no serious harm

  12. Domain relevance Everything that’s relevant to the requirements must appear in some part of the application domain • If it doesn’t appear in domain descriptions, the system cannot report on it, control it, etc.

  13. Problem sensitivity A method for solving problems must be closely expressed in terms of the problems it can help you solve • If a method doesn’t talk about the problem, how can it help you solve it? • The method used in designing the program is to break the specified problem down into a number of sub-problems expressed in English. The same idea is then used to break down each sub-problem into further sub-problems. The method is applied successively until each of the sub-problems can be readily and easily expressed in the programming language. This is called programming by stepwise refinement. • Gak!!! Antithesis of sensitivity

  14. Uniform mood Never mix indicative and optative moods in the same description • Indicative mood describes the natural properties that the domains possess regardless of the system • Optative mood describes what the system is required to do.

  15. To summarise • We have: • Tools for project planning, project management, risk assessment, team management • Change management strategies • Development methods • Life cycle models • Formal proofs

  16. Continued • We also have an immature discipline that repeatedly delivers bad systems • We must • employ principles of methodology • Become masters and not pedants • Avoid method enthusiasts • Analyse and structure problems • So, go forth and do some good!

More Related