1. Software Engineering 3156 Fall 2001 Section 1 10-Sep-01 Class #2: Overview Phil Gross

2. 2 Administrivia HW0 = questionnaire Fabulous new web site Policy about people who don’t meet the requirements

3. 3 Case Study: Ariane 501 Next-generation launch vehicle Successor to the Ariane 4 Prestige project for ESA Maiden flight: June 4 th 1996

4. 4 The System Inertial Reference System – What’s my position, velocity, and acceleration? Critical, obviously – Dual redundant Calibrated on launch pad Largely carried over from Ariane 4 – recalibration routine allowed to continue running for 40 sec after launch

5. 5 The Problems Recal routine never used after launch, but still active One step in recal converted floating point value of horizontal velocity to integer Ada automatically throws an exception if data conversion is out of bounds If exception not handled, IRS returned diagnostic data instead of position/velocity info

6. 6 The Situation Perfect launch Starts flying much faster than Ariane 4 Horizontal component goes out of bounds for integer conversion Both IRSs switch to diagnostic mode Control system interprets diagnostic data as very weird orientation And attempts to correct it…

7. 7 Ariane 501 Go Boom

8. 8 Postmortem Recal routine had no business being active after launch Horizontal velocity parameter conversion was deliberately allowed to be unchecked Software had never been tested with actual flight parameters – Problem easily reproduced in test environment after the fact

9. 9 At Least It Was Pretty

10. 10 Extra Case Study Bug Report This is an actual e-mail I received over the weekend (name removed to protect the guilty) Hello, I filled out the questionnaire, but I could not submit it. Just wanted to let you know. - (John Doe)

11. 11 Overview The Waterfall model More on maintenance Terminology Team models More on the project

12. 12 Waterfall Model Requirements Specification Design Implementation Integration Maintentance

13. 13 Requirements What are we doing and why? Interviews – Getting a problem specification out of busy, threatened, very-much-not-programmer types – Difficult to simulate in a course, so we’re skipping Prototypes and negotiation Metric: requirements volatility

14. 14 Specification Creating the contract What it will do, not how Detailed, so duration and cost can be estimated Classical: DFD, FSM, Petri Nets OO: Use cases, class modeling, state diagrams

15. 15 Design Fill in the “How” Interaction diagrams – Sequence – Collaboration Interactions determine actions Determine object clients Create detailed design

16. 16 Implementation Pick a language: C, C++, Java, Ada, COBOL, LISP, FORTRAN, Standard ML, Forth, PL/SQL, Assembly, etc. Programming standards: comments, meaningful variable names, named constants, etc. Black-box and Glass-box testing

17. 17 Integration Top-down finds design faults early Bottom-up finds operational faults early and isolates them So, “Sandwich Integration” does both at once Product and acceptance testing

18. 18 Maintentance Corrective (fix problems) Perfective (improvements) Adaptive (environment changes) Difficult, important, programmers hate it Carefully designed processes are critical

19. 19 Better Definition of Maintenance Changing something that’s already been written or specified Regardless of whether it’s before or after delivery Delivery date is artificial boundary Note that Schach is a Maintenance specialist

20. 20 Maintenance Costs Money Lots and lots of money Far and away most expensive component When doing cost-benefit analysis, anything that cheapens maintenance generally wins

21. 21 Maintenance Is A Good Thing It’s what happens to a used, living program Dead programs, like dead languages, need no maintenance

22. 22 Maintenance Is Hard Every problem is a puzzle This is what happened – Find out why – Fix it Often end up knowing code better than original authors Horrible job – fixing stupidities all day, every day

23. 23 Terminology Faults and errors (also bug, defect, anomaly, failure, exception) – Fault is in the program – Error is observed effect Products, programs, and systems

24. 24 OO Terminology Attribute = field, state variable, instance variable, property Method = member function (not quite the same as plain old function, though) Static vs. dynamic

25. 25 Teams - Brooks’s Law Adding personnel to a late software project makes it later Training time Number of communication pairs grows as O(N 2 ) while work accomplished grows at O(N) If project naturally breaks into four pieces, what is a fifth person supposed to do?

26. 26 Democratic Teams Egoless programming Social engineering “Please find bugs in my code” Problem: “I order you all to be egoless”

27. 27 Chief Programmer Teams Brooks’s approach Chief Programmer Back-up Programmer Secretary Just Plain Programmers

28. 28 Chief Programmer Problems Chief supposed to be manager and programmer Back-up Programmer just waiting for Chief Programmer to be hit by a truck – Cf. Vice President of the USA Secretary does paperwork all day Doesn’t scale to 100 programmers

29. 29 Typical Modern Team Programmers have a Technical Leader and a separate Team Manager Manager is administrative only Tech Lead is Technical only Can increase the hierarchy

30. 30 Microsoft Model Synchronize and stabilize Programmers can do whatever they want, but have to check in their code on time every day for integration Lets hackers run (relatively) free Good model for firms that can attract the very best programmers

31. 31 Extreme Teams Code in pairs No specialization A writes test cases, then B writes code while A watches Designed to be turnover-resistant Not for those who don’t like to be watched

32. 32 More On Project Three main parts – Client – Server – AI Each group will work on one of the three

33. 33 Client Graphical tile-based UI Network communication with server Running animations Sending commands from user to server Displaying what the server tells it to Editor mode Untrusted

34. 34 Server Network communication with client Modeling of entire game world – Combat – movement Management of game clock Storage to LDAP server

35. 35 AI Determine NPC/Monster actions Determine shortest path between points Scripting Conversation

36. 36 XML Structured form of communication How components will communicate Freeform HTML Grammar and validation DOM and SAX