360 likes | 470 Views
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
E N D
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 2
Case Study: Ariane 501 • Next-generation launch vehicle • Successor to the Ariane 4 • Prestige project for ESA • Maiden flight: June 4th 1996 3
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
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
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
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
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
Overview • The Waterfall model • More on maintenance • Terminology • Team models • More on the project 11
Waterfall Model • Requirements • Specification • Design • Implementation • Integration • Maintentance 12
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
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
Design • Fill in the “How” • Interaction diagrams • Sequence • Collaboration • Interactions determine actions • Determine object clients • Create detailed design 15
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
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
Maintentance • Corrective (fix problems) • Perfective (improvements) • Adaptive (environment changes) • Difficult, important, programmers hate it • Carefully designed processes are critical 18
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
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
Maintenance Is A Good Thing • It’s what happens to a used, living program • Dead programs, like dead languages, need no maintenance 21
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
Terminology • Faults and errors (also bug, defect, anomaly, failure, exception) • Fault is in the program • Error is observed effect • Products, programs, and systems 23
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
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
Democratic Teams • Egoless programming • Social engineering • “Please find bugs in my code” • Problem: “I order you all to be egoless” 26
Chief Programmer Teams • Brooks’s approach • Chief Programmer • Back-up Programmer • Secretary • Just Plain Programmers 27
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
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
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
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
More On Project • Three main parts • Client • Server • AI • Each group will work on one of the three 32
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
Server • Network communication with client • Modeling of entire game world • Combat • movement • Management of game clock • Storage to LDAP server 34
AI • Determine NPC/Monster actions • Determine shortest path between points • Scripting • Conversation 35
XML • Structured form of communication • How components will communicate • Freeform HTML • Grammar and validation • DOM and SAX 36