Software in Practice a series of four lectures on why software projects fail, and what you can do about it - PowerPoint PPT Presentation


PPT – Software in Practice a series of four lectures on why software projects fail, and what you can do about it PowerPoint presentation | free to download - id: 3e739f-ZjNkZ


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Software in Practice a series of four lectures on why software projects fail, and what you can do about it


Software in Practice a series of four lectures on why software projects fail, and what you can do about it Martyn Thomas Founder: Praxis High Integrity Systems Ltd – PowerPoint PPT presentation

Number of Views:64
Avg rating:3.0/5.0
Slides: 35
Provided by: Martyn97
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software in Practice a series of four lectures on why software projects fail, and what you can do about it

Software in Practicea series of four lectures on
why software projects fail, and what you can do
about it
  • Martyn Thomas
  • Founder Praxis High Integrity Systems Ltd
  • Visiting Professor of Software Engineering,
    Oxford University Computing Laboratory

Lecture 4 Principles of Software Engineering
  • Dependability
  • Theory and Practice the 30-year gap
  • What we Know
  • Strong Software Engineering

Software Dependabilityour highest priority
  • Dependability umbrella term for safety,
    reliability, security, trustworthiness,
  • A dependable system is one known to have all its
    required properties.
  • We need dependable processes as well as
    dependable systems
  • to build systems on time and budget, and to be
    able to rely on what we deliver.

World dependability initiatives-evidence that
dependability is now high priority
  • Microsoft
  • trustworthiness initiative (11000 engineers)
  • Palladium/Longhorn/Next Generation Secure
    Computing Base.
  • Trusted Computing Platform Alliance
  • Intels LaGrande technology
  • IBMs Autonomic Computing initiative
  • Critical Infrastructure Protection initiatives
  • Dependable Systems Evolution identified as a
    computer science Grand Challenge
  • DIRC

In a 50 year old discipline, there is a 30-year
gap between theory and practice!
  • A study of program structure has revealed that
    programseven alternative programs for the same
    taskcan differ tremendously in their
    intellectual manageability. A number of rules
    have been discovered, violation of which will
    either seriously impair or totally destroy the
    intellectual manageability of the program.
    Dijkstra, 1972

Theory and Practice
  • Theory
  • The inherent difficulty of software design has
    been well understood for more than 30 years, and
    the problems and solutions have been taught to a
    generation of graduates.
  • Practice
  • The insight has been largely ignored by industry
    not because it has been tried and failed, but
    because it has been considered hard, and not
    tried. after G. K. Chesterton

Practice in Industry
  • Despite much progress in software development
  • most software development staff have
  • little formal education in software engineering
  • no good grounding in either the processes or the
    theories that underpin their professional work.
  • A fascination with the latest fad or fashion
  • managers who have even less understanding than
    their junior staff of the great complexity of the
    engineering tasks they are undertaking, and of
    the risks inherent in departing from what is
    known to work.
  • most software staff are recruited for their
    knowledge of a programming language or a software
    package, not for any engineering knowledge.

Software 2005, Santa Clara
  • "The quality I get from you people is abysmal.
    David Watson, CTO, Kaiser Permanente
  • "We're at too much risk to have the level of
    problems with bugs we have today." Ed Meehan,
  • "You're not all doomed. But many of you are.
    Neal Cameron, CIO, Unilever

Managers and engineering knowledge ...
Software Engineering
  • Computer based applications are increasingly
  • We choose to put that complexity into the
  • More and more software is business critical
  • Quite often, software is safety critical
  • Constructing complex and important systems is

Engineering is ...
  • Developing complex systems or objects ...
  • using scientific principles ...
  • and experience of successful systems and
    subsystems ..
  • embedded in a mature process ...
  • with effective quality and risk management
  • Many of our current concerns would be familiar to
    the builders of the Great Pyramids

7 Lessons from the Past
  • Complexity kills
  • The cost of correcting an error rises steeply
    with time
  • Change is inevitable
  • Most development is documentation, not invention
  • Reuse is better than originality
  • Engineering is a process of risk management
  • Optimisation is the last thing you should do

Complexity kills
  • Writing simple programs for simple problems is
  • Rigorous abstraction masters complexity
  • Mathematical rigour has always been essential
    from LL1 grammars strong typing concurrency
    primitives and E/R models to formal
    specifications and proof
  • Structural simplicity is key modularity,
    information hiding (Simula 67!), low coupling /
    high cohesion, problem-oriented structures (eg
    JSP/JSD), Object Orientation

The cost of correcting an error rises steeply
with time
  • Possibly 10-fold with each lifecycle phase
  • Specification errors are 100 times more costly
    than coding errors if both are found in unit
  • A good development method provides strong VV at
    each phase - this is why formal methods are so
  • Costs increase with time, even when the product
    is in service

Change is inevitable
  • Every business system encapsulates a business
    process - which has to change to stay competitive
  • Every successful product needs new versions with
    new features
  • The lifetime cost of most software is 5-10 times
    the development cost
  • So maintenance and upgrade are the most costly
    steps in the lifecycle
  • We therefore need to focus on methods, tools and
    system architectures that
  • preserve structural integrity
  • limit the growth in complexity

Most development is documentation, not invention
  • In all engineering, the main output is
  • aeronautical engineers say that an aircraft is
    not ready to fly until the documentation weighs
    more than the aircraft
  • For software, the documentation must support the
    maintenance/update phase
  • and vice-versa!
  • Updating code before updating specification or
    design documents is vandalism - it reduces (and
    ultimately destroys) the value of the product
  • Writing good code from good documentation is easy
    - the reverse can be impossible

Reuse is better than originality
  • Engineers build systems from reliable subsystems
  • They use successful designs from the past
  • A new design is almost always wrong
  • even if it isnt, building justified confidence
    is very expensive
  • Studying successful systems of the past is the
    basis for building successful systems in the
  • Design for reuse
  • components that provide a single function or
    closely related group of functions
  • clear, precise specification
  • secure version management

Engineering requires the management of risk
  • We cannot know everything we need to, when we
  • Unacceptable risks must be identified and
    eliminated early
  • The residual risks have to be managed.
  • plan to do work to avoid or accommodate them
  • the cost multiplied by the probability must be
    planned in the budget for the project
  • revised costs and probabilities are needed for
    every project review
  • The forecast cost to complete is a three-valued
  • if all risks materialise
  • engineering judgement
  • if no risks materialise

Optimisation is the last thing you should do
  • Jacksons law
  • Jacksons second law (for experts only)
  • This doesnt mean being wasteful of resources
  • a good engineer should know how to work
  • an engineer is someone who can do for twopence
    what any fool can do for a shilling

The Professional software engineer.
  • ... is someone who
  • has a good grounding in computer science,
    mathematics, and human factors
  • understands and can work with mature engineering
    processes involving teamwork, risk management,
    and quality assurance
  • understands measurement as a basis for quality
  • has studied successful systems of the past, and
    understands their design principles
  • understands a the limits of their own competence
  • keeps up to date by reading the journals and CPD

What we know Specifications
  • Form must mirror the structure of the real world
    requirement. Principles of Program Design,
    Jackson, AP 1975
  • Notation must support unambiguous statement of
    requirements and reasoning about properties. Only
    then can you understand the system, or the impact
    of changes.
  • Mathematical foundations are essential - Alan
    Turing knew this in the 1940s.

  • The two most important characteristics of a
    specification notation are (1) that it should
    permit problem-oriented abstractions to be
  • and (2) that it should have rigorous semantics
    so that specifications can be analysed for
    anomalies and to explore system properties.
  • 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

What we know Engineering
  • Engineering is the application of science, within
    mature processes, to build practical systems,
  • For software engineers, this means applying
    computer science, within mature processes for
    planning, risk and quality management, formal
    reviews, configuration management, and the rest
    of ISO 9001/CMM level 3
  • All engineers use mathematics to model and
    analyse their systems.

What we know Testing
  • Testing shows the presence, not the absence, of
    bugs. Dijkstra 1972
  • One can construct convincing proofs quite
    readily of the ultimate futility of exhaustive
    testing of a program and even of testing by
    sampling. So how can one proceed? The role of
    testing, in theory, is to establish the base
    propositions of an inductive proof. You should
    convince yourself, or other people, as firmly as
    possible, that if the program works a certain
    number of times on specified data, then it will
    always work on any data. This can be done by an
    inductive approach to the proof. Hoare 1969

What we know Change can destroy dependability
  • If you cannot reason about the impact of a
    change, the change must invalidate all
    pre-existing evidence of dependability.

Software Death
  • Software dies when a typical fix introduces more
    errors than it corrects
  • If your average error rate is 1 error/50 LoC,
    your software dies when the size of your average
    bug fix exceeds 50 LoC.
  • Debugging maximises the number of bugs remaining,
    for a given reliability.
  • IBM data showed that typical bugs only recurred
    every 100 user-years! Chapman

The State of the Art in Software
  • Annual cost to US economy of poor quality
    software 60B source US NIST Report
    7007.011, May 2002.
  • Typical industrial / commercial software
  • 6-30 faults delivered / 1000 lines of software
  • 1M lines 6000-30,000 faults on delivery
  • source Pfleeger Hatton, IEEE Computer, pp33-42,
    February 1997.

What we know Languages
  • I will start with a strong statement of opinion.
    I think that any significant advance in the
    programming art is sure to involve very extensive
    automated analyses of programs. Doing
    thorough analyses of programs is a big job. It
    requires a programming language which is
    susceptible to analysis. I think other
    programming languages will head either to the
    junk pile or to the repair shop for overhaul, or
    they will not be effective tools for the
    production of large programs. E S Lowry (IBM)
    Nato Conference, Rome, October 1969.
  • Such languages and tools exist

Experience with Strong Software Engineering
  • Software development based on formal
    specification, strong static analysis, ISO 9001
    mature processes
  • 0.1 - 1 faults / 1000 lines of software
  • 1M lines 100 - 1000 faults on delivery instead
    of 6000 - 30000
  • 100-fold improvement at no extra development
  • sources
  • Pfleeger Hatton, IEEE Computer, pp33-42,
    February 1997
  • Amey, http//

Formal methods can reduce risk, save money, and
deliver successful projects
  • Z is more efficient at finding faults than the
    most efficient test phase
  • http//
  • compelling evidence that development methods
    that focus on bug prevention rather than bug
    detection can both raise quality and save time
    and money.
  • http//

But get the basics right first
  • First ISO 9001 and/or CMM Level 3
  • now you are under control
  • ThenFormal methods for requirements
  • now you really understand what you are trying to
  • Then ...Implementation using well-defined
    languages with formal annotations
  • for example, SPARK

Two reasons for using Formal Methods
  • Formal methods reduce development risks and save
    development budget
  • FMs are cheaper
  • Formal methods lead to far fewer delivered bugs
  • delivered software is much higher quality
  • the extra quality is free
  • support costs are much reduced
  • you can even guarantee the software

  • We can build complex, dependable systems - but
    only if we always use strong software
  • System and software engineering must be rigorous,
    disciplined, conservative and evolutionary,
    learning from what has worked dependably in the
    past. Formal methods are fundamental to strong
    software engineering.
  • It will take numerate, motivated graduates to
    change things for the better you.