1 / 36

Software Engineering 3156

Software Engineering 3156. Fall 2001 Section 1 10-Sep-01 Class #2: Overview Phil Gross. Administrivia. HW0 = questionnaire Fabulous new web site Policy about people who don’t meet the requirements. Case Study: Ariane 501. Next-generation launch vehicle Successor to the Ariane 4

carney
Download Presentation

Software Engineering 3156

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  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 4

  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 5

  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… 6

  7. Ariane 501 Go Boom 7

  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 8

  9. At Least It Was Pretty 9

  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) 10

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

  12. Waterfall Model • Requirements • Specification • Design • Implementation • Integration • Maintentance 12

  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 13

  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 14

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

  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 16

  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 17

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

  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 19

  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 20

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

  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 22

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

  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 24

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

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

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

  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 28

  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 29

  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 30

  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 31

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

  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 33

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

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

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

More Related