Presentation is loading. Please wait.

Presentation is loading. Please wait.

No Silver Bullet – Essence and Accident in Software Engineering.

Similar presentations


Presentation on theme: "No Silver Bullet – Essence and Accident in Software Engineering."— Presentation transcript:

1 No Silver Bullet – Essence and Accident in Software Engineering

2 The Werewolf and the software project Both seem straightforward and familiar at first Then they [can] become a monster. For software, the monster is missed schedule, blown budgets and flawed products, etc. We then cry for a silver bullet, an easy fix to the problem. But it is never there.

3 -First we need to see that problem is not that software progress is too slow, but that hardware progress is too fast. -Second, we need to understand what rate of progress in software by looking at two different forms of difficulty: 1. Essence – the difficulties inherent in the nature of the software 2. Accidents – the difficulties that, today, attend its production but are not inherent.

4 The Properties of Essence 1.Complexity of the software -Leads to problems such as product flaws, cost overruns, difficulty of enumerating, and unreliability. -complexity of functions makes it difficult to invoke said functions. -complexity of structure makes it hard to add on new functions -There also arises difficulty in management; complexity makes it project hard to find and control loose ends, learning burdens, and so on.

5 2. Conformity -the difficulty in this comes from conformation of software to other interfaces. -This cannot be simplified out by any redesign alone. 3. Changeability -Change in software constantly occurs to extend its functionality. -The pressure for extended function come from users who like the basic function and invent new uses for it.

6 4. Invisibility -The reality of software is not inherently embedded in space. -We find that it to constitute not one, but several, general directed graphs, superimposed one upon another.

7 Breakthroughs Solving Accidental difficulties 1.High – level languages -It frees a program from much of its accidental complexity. -The most a high-level language can do is to furnish all the construct the programmer imagines in the abstract program.

8 2. Time-Sharing - It preserves immediacy, and hence enables us to maintain an overview of complexity. -The principle effect is to shorten system response time. 3. Unified programming environments -They attack the accidental difficulties of using programs together, by providing integrated libraries, unified file formats, and pipes and filters.

9 Technical Developments – Potential Silver Bullets 1.Ada / Other high languages -Not only reflects evolutionary improvements in languages concepts, but embodies features to encourage modern design and modularization concepts However - Biggest payoff came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step by step solutions

10 2. Object - oriented programming - Two data types: abstract and hierarchical; aka classes - Each removes one more accidental difficulty from the process. -gives designers freedom to express essence of his design without so much syntactical material - Unfortunately, it cannot remove the complexity of design; that in itself is essential, not accidental.

11 3. Artificial intelligence -There would seem to be hope in a breakthrough. -But, what AI provides, as of this point is the ability to make the program solve a problem the way humans seem to; how to recognize. -Hard thing about building software is deciding what to say, not sayng it.

12 4. Expert systems -A program containing a geveralized inference engine and a rule base – takes input data assumptions and explore the logical consequences, yielding conclusions and advice. -For software building: suggesting interface rules, advising on testing strategies remembering bug-type frequencies, offering hints, etc. -Difficulties: 1) making easy ways to get from structure specifics to auto generation of diagnostic rules. 2) knowledge acquisition

13 5. “Automatic” programming -Idea of programs that solves problems based on a statement of problem specifications. -Nothing to the exact extant has been made at this point. -But there are similar examples: Systems for integrating differential equations have also permitted direct specification of the problem; assessing parameters, chose from library of functions and generates solution.

14 6. Graphical programming -Application of computer graphics to software design. -Not a very promising possibility, considering that visualizing some programs is close to impossible. 7. Program verification -Proving the design is correct before effort is put into implementing ad testing. -A major amount of work is required to be able to fully verify a design, and even then, bugs can still potentially occur.

15 8. Environment & Tools -hierarchal file systems, generalized tools, etc. -Useful in programming, but the return at this point is marginal. 9. Workstations -It’s helpful to have faster running machines. -Don’t, however, expect a magical programming enhancement.

16 Promising attacks on the Conceptual Essence 1.Buy Versus Build -Any product is cheaper to buy than to build afresh. -Cost of software has been development cost. -Many users operate own computers without writing a program, yet can solve new problems with the programs they have.

17 2. Requirements refinement & rapid prototyping - Hardest part of building software is deciding what to build. -Most important function that software builders do for their clients is get from them, the requirements of the product. -A prototype software system is one that simulates the important interfaces and performs the main functions of the intended systems. -Much of present-day software acquisition procedures rests upon the assumptions that one can specify a satisfactory system.

18 3. Incremental development – grow not build - The system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. -It is then fleshed out, with subprograms in turn being developed into actions. 4. Great designers -Software construction is a creative process. -Best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort - Like Mozart and Salieri

19 Any Questions?


Download ppt "No Silver Bullet – Essence and Accident in Software Engineering."

Similar presentations


Ads by Google