O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

No silver bullet

Article: No Silver Bullets..
I make easy for students whose are difficulty to understand the article..

  • Entre para ver os comentários

No silver bullet

  1. 1. Essence and Accidents in Software Engineering By GHUFRAN JAMEEL HASAN
  2. 2. “I believe the hard part of building software is the specification, design, and testing of this conceptual construct, not the labor or representing it.”
  3. 3. NO SILVER BULLET • Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. • Why a silver bullet? • Silver is identified with the moon-A silver bullet offers the fastest, most powerful, and safest way to slay the fast, powerful, and incredibly dangerous werewolf • Same fashion of familiar software project , at least as seen by the non- technical manage.
  4. 4. NO SILVER BULLET (Cont..) • Usually innocent and straightforward but is capable of becoming a monster of • Missed schedules • Blown budge • Flawed products • We have no silver bullet that make software costs drop as rapidly as computer hardware costs do.
  5. 5. NO SILVER BULLET (Cont..) • Over decades, we see no silver bullet-no single development, that make improvement in • Productivity, • Reliability and • Simplicity
  6. 6. Essence and Accident in Software Engineering • All software construction involves Essential and accidental difficulties • Software, at its core, has these essential difficulties: • Complexity, • Conformity, • Changeability, • Invisibility
  7. 7. Complexity • Software is complex, even when done right. • Combinatorial many states, syntax must be just so or else. • Rich structure, interesting dependencies add to complexity. • Accidental (as practiced) issues add to complexity. • Efficient code is usually complicated code. • Complex code is harder to evolve, results in design drift and even more complexity.
  8. 8. Complexity(Cont..) • Many problems of developing software products derive from this essential complexity, due to complexity: • Difficulty of communication among team members-results into product flaws, cost overruns, and schedule delays • Difficulty of enumerating, much less understanding unreliability • Difficulty of invoking function- makes programs hard to use. • Complexity of structure brings the difficulty of extending programs to new functions without creating side effects
  9. 9. Conformity • Software has to be made to agree to common interfaces, protocols, standards, etc. • Mostly standards for mastering complexity is arbitrary. Human institutions and systems must conform these standards and interfaces and they differ from • Interface to interface, and from • Time to time because • They were designed by different people
  10. 10. Changeability • To be successful is to be changed! • Try to expect future unforeseen uses. • Buildings can get changed- but the high costs of change • Software product is found to be useful • People try it in new cases at the edge of or beyond the original domain. • The pressures for extended function come chiefly from users who like the basic function and invent new uses for it.
  11. 11. Changeability(Cont..) • In short, the software product is embedded in a cultural matrix of : • Applications, users, laws, and machine vehicles. • These all change continually, and their changes inexorably force change upon the software product. • In order to keep system flexible and marketable, Software is constantly subject to pressures for change un like buildings, cars or computers manufactured things are infrequently changed after manufacture. • Essential changes incorporate in models, serial-no. copies of the same basic design.
  12. 12. Changeability(Cont..) • We change software because ! • It is easy to update existing systems in the field (in theory) • We can undo changes if desired (in theory)
  13. 13. Invisibility • Software is invisible and unvisualizable • The floor plan of a building helps both architect and client evaluate spaces, traffic flows, views. contradictions and omissions become obvious. • No geometrical representation like map of land, diagram of chips • Although we can use various diagrams to help us visualize aspects of software (control flow, data dependencies, OMT/UML) • But that's NOT quite the same thing as, say, the blueprints of a building.
  14. 14. Invisibility(Cont..) • Still Unvisualizable ! Because.. • Even a progress in restricting and simplifying the structures of software, they remain inherently unvisualizable, and thus do not permit the mind to use some of its most powerful conceptual tools.
  15. 15. What about these Silver Bullets??? • HLLs • Frees us from byte-level thinking (accidental complexity). • IDE • AI -Certainly, AI techniques are useful in many application domains, but not as a silver bullet to solve the SE prob. • Graphical programming e.g UML, SDL, OOD
  16. 16. Promising attacks on conceptual essence • Buy, don't build • Requirements are the essence of a software system. • Focusing on getting the requirements right is a direct attack on essential problems. • Rapid Prototyping: • Take requirements, build mock up, show to user, analyze feedback, repeat. • Early feedback means less chance for requirements errors (which are the most expensive), fast turnaround in problem space to narrow misunderstandings and educate customer.
  17. 17. Promising attacks on conceptual essence(Cont..) • Staged Delivery incremental development…… • Get a skeleton system up and running, flesh it out as you go. • Helps to get developers feeling like system is real. • They add their updates as they finish them. • Microsoft (and many others) uses this approach; works well for them. • Skillful Designers • Find good people and keep them. • Pay them well, encourage them. • Above all, listen to them.
  18. 18. Promising attacks on conceptual essence(Cont..) • Skillful Designers • However, “great software design” is mostly “pure” design (not engineering); it’s an act of creativity and innovation balanced against experience and good engineering. • It’s impossible to teach.
  19. 19. There is no Royal Road, but there is a road
  20. 20. Good news! We have made great headway in solving the accidental problems! Orders of magnitude improvements! Bad news! Progress on essential problems will be much slower going.
  21. 21. Will Software Engineering prove to be the silver bullet that slays the software productivity monster ?
  22. 22. Thank You