Grown-up Software Development a summary and Methodological Principles



Yüklə 467 b.
tarix23.09.2017
ölçüsü467 b.
#1277


Grown-up Software Development

  • 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



Panaceas & silver bullets

    • 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

  • 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


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



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!



Yüklə 467 b.

Dostları ilə paylaş:




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət

    Ana səhifə