Software Engineering

1. Software Engineering EECE 351 Spring 2000 Lecture # 24 EECE 351 – Lecture 24

2. Overview • MMM • No Silver Bullets • Silver Bullet Re-fired • Items not in book • Quality Control • Personality traits • What we know • Where we are going EECE 351 – Lecture 24

3. MMMNo Silver Bullet “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.” EECE 351 – Lecture 24

4. MMM NSB –Accidental vs. Essence • Accidental is: • The difficulties that arise in the software’s production. (The simple errors) • What makes it hard to implement the program. • Unfamiliarity with MSDEV, C++, etc. • Essence is: • The difficulties inherent in the process of building software. (The hard stuff) • What makes Software creation difficult to begin with. • Understanding where to put a for/while loop EECE 351 – Lecture 24

5. MMM NSB – The Software Engineering Essential • The software engineering essential • Fashioning abstract conceptual structures of great complexity • To address this • Exploit shrink-wrapped applications • Use rapid prototyping and planned iteration in establishing requirements • Grow software organically • Identify and develop the great conceptual designers of the rising generation The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. EECE 351 – Lecture 24

6. MMM NSB – Essential Difficulties • Essential, inherent properties of software systems • Complexity (non-linear with size) • Conformity (yes or no conceptual integrity) • Changeability (infinite malleability) • Invisibility (no ready geometric representation) I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. There is inherently no silver bullet. EECE 351 – Lecture 24

7. MMM NSB –Solving the Accidental Difficulties • High level languages • Think in terms of ints, fors instead of byte cmp, branch. • More productive • Time-sharing • Enable many to utilize precious CPU power • Cheap PCs no longer make this as important • Unified Programming Environments • Attack problems of using programs together • Making them work together still takes 3x effort. EECE 351 – Lecture 24

8. MMM NSB – Duds on accidental • Revolutionary or incremental? • High-level language advances • Ada, Smalltalk, C++, java • Object-oriented programming • Artificial intelligence • IA > AI • Automatic programming • Graphical programming • Program verification • Environments and tools • Workstations/PC’s EECE 351 – Lecture 24

9. MMM NSB – Brass Bullets? Attacks on Essence • Therefore the most important function that software builders do for their clients is the iterative execution and refinement of the product requirements. For the truth is, the clients do not know what they want. • Buy versus build • Is $150,000 A lot of money? • Rapid prototyping and requirement refinement • Well-defined up-front requirements are a myth • Organic, incremental software development • Get the system running as fast as possible • Keep the system running • Great designers • The most important factor EECE 351 – Lecture 24

10. MMM“No Silver Bullet” Refired • There was no Silver Bullet • There never will be. • A lot of people have trouble believing • Accidental vs. Essence • Accurate and orderly representation of the conceptual construct • Effort of mentally crafting the constructs • Do not attack the Accident, go for the Essence • When people understand these differences, there might be a bullet. EECE 351 – Lecture 24

11. MMM – SBR • Can we attack the essence? • Yes! • But we still have to focus on the ENTIRE essence • Complexity Levels • Hierarchically (modules) & Incrementally • Pessimism vs. optimism vs. realism • NSB is “far too bleak” • Waaahhhh • We need to know what we are up against in order to beat it • “Know thy enemy, know thyself, your victory will not be endangered. Know the ground, know the weather, your victory will then be total.” Sun-Tzu The Art Of War EECE 351 – Lecture 24

12. MMM – SBR • Gloom • Separation • Needed to understand the differences • Isolation • Look at quote again “…by itself…” • “It is not the techniques I oppose, it is expecting them to work magic.” • Only allowing 10 yrs. • Humans can’taccurately predict beyond a decade • 40 yrs is a long time to wait • Moore’s Law EECE 351 – Lecture 24

13. MMM – SBR • Thought Experimentation • 1952 vs. 1986 • Might as well call this section 1984!!!! • Still have same problems now as then • What’s easier: • Figuring out MSDEV or • Figuring out C++? • Vanilla Framework • I haven’t heard of it outside this book • Have you? EECE 351 – Lecture 24

14. MMM – SBR • Invisibility • You cannot represent a program in the real world • Flow charts are EVIL • “Where is next November?” • Good programmers have strong spatial senses • Highly individualistic models • Productivity follows Quality • Goal of SE is to increase Quality, Testability, Stability, & Predictability NOT efficiency! • Who’s responsible when a BSOD occurs? EECE 351 – Lecture 24

15. MMM SBR – Do I Throw The First One Away? • Brooks admits now that this was erroneous (his term is “simplistic”) advice. • He blames the use of a waterfall model for this error. • He now counsels the use an organic growth (incremental build, rapid prototyping, etc.) model so that there is no “first one.” • He discusses the “build every night” approach used at Microsoft. • He’s still side-stepping the issue. • The fact is that you need to get your customers, through some incentive, to accept early versions of your product. EECE 351 – Lecture 24

16. MMM SBR – Object-Oriented Methodology: A Silver or Brass Bullet? [Why has object-oriented technique grown slowly?] The problem is that programmers in O-O have been experimenting in incestuous applications and aiming low in abstraction, instead of high. [James Coggins] It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. [David Parnas] EECE 351 – Lecture 24

17. MMM SBR – Object-Oriented Methodology Revisited • There is a frank admission that data abstraction and encapsulation are absolutely necessary • There is an admission that inheritance is critical in achieving intra- and inter-program reuse EECE 351 – Lecture 24

18. MMM SBR – Re-Use: Another Brass Bullet • Most experienced programmers have private libraries • Do you? • The larger the group, the tougher is re-use to practice • Why? • Motivational issues exist, but are largely accidental and not essential • NIH (not invented here) is real, but is not a minor reason (see above) • Vocabulary size is the inherent issue • Microsoft’s MFC, COM, and active-x efforts are examples massive vocabularies EECE 351 – Lecture 24

19. MMM SBR – Conceptual Integrity • Conceptual integrity is the most important concept • The architect is the realization vehicle for conceptual integrity • Separation of the architecture and implementation/realization is key • Note the similarity of the C++ class declaration and class implementation mechanisms - and the advice to separate into a separate header (*.H) and source file (*.Cpp) • Complexity is the business we are in! • And what limits us. EECE 351 – Lecture 24

20. Things not in MMMQuality Control • Dr. W. Edwards Demingwas the first to think of Quality Control • America laughed at him • Japanese thought it was good idea • How many TVs are made in the US now? • Dr. Deming’s ideas were employed in industrial settings. • Getting the machines to work correctly • How can they be applied to Software? EECE 351 – Lecture 24

21. Things not in MMMQuality Control • First, we have to know what quality software is (how to define): • Doesn’t crash • Accurate • Fulfills specifications • Etc. • Then, how do we make Quality Software • TEST, TEST, TEST • Look at those who do and ask: • What are they doing that I’m not? EECE 351 – Lecture 24

22. Things not in MMMPersonalities • You won’t be graded on it, but check out: • http://www.keirsey.com • Temperament or Character Sorter • Will help you figure out who you are • And more importantly how you learn • There are several types of outcomes • Each has a four letter code • Mine was ESTP • Now its ESTJ (or ENTJ) EECE 351 – Lecture 24

23. Things not in MMMPersonalities • E or I • Extroverted vs. Introverted • N or S • Intuition or Sensing • T or F • Thinking or Feeling • J or P • Judgment or Perception • The best engineers are usually ISTP EECE 351 – Lecture 24

24. What we know • No Silver Bullets • Quality Control • Personality Traits EECE 351 – Lecture 24

25. Where we are going • Quiz & Project questions • Final Review • The Exam • Summer!!! EECE 351 – Lecture 24