A Summary and Methodological Principles
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.
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
- Structured programming
- Flow charts
- Structured methods
- 4GLs
- Prototyping
- Development processes to support the entire lifecycle
Humbug and snake oil
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
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?
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.
Complexity Real problems are complex Postpone composition until you have mastered the components, or That’s what’s wrong with top-down - Reverse composition of something we don’t understand to create components that are probably wrong
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
Principles of Methodology Beneficent difficulty* Close-fitting frames* Commensurate care Deferred invention* Dispassionate methodology* Domain relevance Frame exploitation* Problem sensitivity Uniform mood
Commensurate care The care taken in each aspect of a development should be proportional to PD where P is the probability that it will go wrong, and D is the size of the disaster if it does.
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.
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
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.
To summarise We have: - Tools for project planning, project management, risk assessment, team management
- Change management strategies
- Development methods
- Life cycle models
- Formal proofs
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!
Dostları ilə paylaş: |