Overview Last lecture Software engineering CS3157: Advanced - PDF document

Overview • Last lecture – Software engineering CS3157: Advanced • Will cover most in class, you are responsible for Programming understanding high level overview – PHP Lecture #13 • Will cover in class and next lab. Dec 5 Shlomo Hershkop shlomo@cs.columbia.edu What is Software Engineering? Why • Stephen Schach: “Software engineering is a discipline whose aim is • in school, you learn the mechanics of programming the production of fault-free software, delivered on time and within • you are given the specifications budget, that satisfies the user’s needs.” • you know that it is possible to write the specified • includes: program in the time allotted – requirements analysis – human factors • but not so in the real world... – functional specification – what if the specifications are not possible? – software architecture – what if the time frame is not realistic? – design methods – what if you had to write a program that would last for 10 years? – programming for reliability • in the real world: – programming for maintainability – team programming methods – software is usually late, over budget and broken – testing methods – software usually lasts longer than employees or hardware – configuration management • the real world is cruel and software is fundamentally brittle 1

Who Time • the average manager has no idea how software needs to • you never have enough time be implemented • software is often under budgeted • the marketing department always wants it • the average customer says: “build me a system to do X” tomorrow • even though they don’t know how long it will take • the average layperson thinks software can do anything to write it and test it (or nothing) • “Why can’t you add feature X? It seems so simple...” • most software ends up being used in very different ways • “I thought it would take a week...” than how it was designed to be used • “We’ve got to get it out next week. Hire 5 more programmers...” People Complexity • you can’t do everything yourself • software is complex! • e.g., your assignment: “write an operating • or it becomes that way system” – feature bloat • where do you start? – patching • what do you need to write? • do you know how to write a device driver? • e.g., the evolution of Windows NT – NT 3.1 had 6,000,000 lines of code • do you know what a device driver is? – NT 3.5 had 9,000,000 • should you integrate a browser into your – NT 4.0 had 16,000,000 operating system? – Windows 2000 has 30-60 million • how do you know if it’s working? – Windows XP has at least 45 million... 2

Necessity Therac-25 • http://sunnyday.mit.edu/papers/therac.pdf • you will need these skills! • therac-25 was a linear accelerator released in 1982 for cancer treatment by releasing limited doses of radiation • risks of faulty software include • it was software-controlled as opposed to hardware- – loss of money controlled (previous versions of the equipment were – loss of job hardward-controlled) – loss of equipment • it was controlled by a PDP-11; software controlled safety – loss of life • in case of error, software was designed to prevent harmful effects • main cause: • a race condition often happened when operators entered data quickly, then hit the up-arrow key to correct the data and the values were not reset properly • BUT • in case of software error, cryptic codes were displayed to • the manufacturing company never tested quick data the operator, such as: entry— their testers weren’t that fast since they didn’t do • “MALFUNCTION xx” data entry on a daily basis • Where 1 < xx < 64 • apparently the problem had existed on earlier models, • operators became insensitive to these cryptic codes but a hardware interlock mechanism prevented the software race condition from occurring • they thought it was impossible to overdose a patient • however, from 1985-1987, six patients received massive overdoses of radiation and several died • in this version, they took out the hardware interlock mechanism because they trusted the software 3

• perfect launch Example2: Ariane 501 • ariane 501 flies much faster than ariane 4 • next-generation launch vehicle, after ariane 4 • horizontal velocity component goes out of bounds • presigious project for ESA • IRS in both main and redundant systems go into diagnostic mode • maiden flight: june 4, 1996 • inertial reference system (IRS), written in ada – computed position, velocity, acceleration • control system receives diagnotic data but interprets it as wierd – dual redundancy position data – calibrated on launch pad – relibration routine runs after launch (active but not used) • attempts to correct it... • one step in recalibration converted floating point value of horizontal velocity to integer • ka-boom! • ada automatically throws out of bounds exception if data conversion is out of bounds • if exception isn’t handled... IRS returns diagnostic data instead of position, velocity, • failure at altitiude of 2.5 miles acceleration • 25 tons of hydrogen, 130 tons of liquid oxygen, 500 tons of solid propellant Mythical man-month • expensive failure: • Fred Brooks (1975) – ten years – $7 billion • book written after his experiences in the OS/360 design • horizontal velocity conversion was deliberately left unchecked • major themes: – Brooks’ Law: “Adding manpower to a late software project makes it later.” • who is to blame? – the “black hole” of large project design: getting stuck and getting out – organizing large team projects and communication • “mistakes were made” – documentation!!! – when to keep code; when to throw code away • software had never been tested with actual flight parameters – dealing with limited machine resources • problem was easily reproduced in simulation, after the fact • most are supplemented with practical experience 4

No silver bullet SE Mechanics • paper written in 1986 (Brooks) • well-established techniques and methodologies: • “There is no single development, in either technology or management technique, which by itself promises even one order-of magnitude improvement within a decade of productivity, in reliability, – team structures in simplicity.” – software lifecycle / waterfall model • why? software is inherently complex – cost and complexity planning / estimation • lots of people disagreed, but there is no proof of a counter-argument – reusability, portability, interoperability, scalability • Brooks’ point: there is no revolution, but there is evolution when it comes to software development – UML, design patterns Team Structures Lifecycles • why Brooks’ Law? • software is not a build-one-and-throw-away process – training time • that’s far too expensive – increased communications: pairs grow by • so software has a lifecycle • while people/work grows by – how to divide software? this is not task sharing • we need to implement a process so that software is maintained correctly • types of teams – democratic • examples: – “chief programmer” – build-and-fix – synchronize-and-stabilize teams – waterfall – eXtreme Programming teams 5

Software lifestyle cycle Requirements • 7 basic phases (Schach): • what are we doing, and why? – requirements (2%) – specification/analysis (5%) • need to determine what the client needs, not what the client wants – design (6%) or thinks they need – implementation (module coding and testing) (12%) – integration (8%) • worse— requirements are a moving target! – maintenance (67%) – retirement • common ways of building requirements include: – prototyping • percentages in ()’s are average cost of each task during 1976-1981 � – natural- language requirements document • testing and documention should occur throughout each phase • note which is the most expensive! • use interviews to get information (not easy!) • example: your online store Specifications Design Phase • the “contract”— frequently a legal document • the “how” of the project • fills in the underlying aspects of the specification • what the product will do, not how to do it • design decisions last a long time! • should NOT be: – ambiguous, e.g., “optimal” • even after the finished product – incomplete, e.g., omitting modules – maintenance documentation – contradictory – try to leave it open-ended • detailed, to allow cost and duration estimation • architectural design: decompose project into modules • detailed design: each module (data structures, algorithms) • classical vs object-oriented (OO) specification – classical: flow chart, data-flow diagram • UML can also be useful for design – object-oriented: UML • example: your online store • example: your online store 6