1. 27 February A Broader Perspective

2. Triangle Technology Executive Panel Friday, 2 March 3:30 p.m. Sitterson 014 For more info, see http://www.cs.unc.edu/~pozefsky/TTECPanel.html Capital Analytics Find out about local businesses Ask questions about the industry Learn what companies are looking for in employees Network

3. Midterm Presentations: Purpose You don’t understand something until you’ve taught it Clarification of your thought process and understanding Sharpen your understanding of the project Facilitate sharing Learn from each other Practice presenting

4. Midterm Presentations: Logistics March 6 and 8 Requests accepted Assignments will be made at team meetings 15 minute presentations (excluding set up) Copies of charts to be posted on website Full attendance is expected

5. Presentations: The Basics Speak loudly and clearly Stand up No chewing gum when speaking Speak, don’t read: you ARE the experts Practice, practice, practice Set up and test demos and laptops early

6. Presentations Hints Cover all topics, but they don’t need equal time! Focus on what’s special about your project Don’t try to cover too much Keep it light Give the audience something to look at

7. Presentations Grading Content and style count Single grade for group Everyone does NOT need to present

8. Presentation Content Motivation Introduction to the area and project Key domain problems to be addressed “Use Cases” Who are the users What do they need to do Design System design and further detail as needed Key technical problems to be addressed Technologies being used (and why) Demo: what you present to your customer this week Any interesting “why”s

9. Motivation Tell the class about the problem Information about the group Similar websites How things are done today What are the problems being faced Why is the project being done

10. Design The first picture that you would draw for a new team member Sharing with other teams Technologies Major problems (solved or open)

11. Examples of Architecture Pictures Game Engine Soun d File I/O Controller I/O Visual Interfac e Omega CONTROL MODEL Login VerifyUser Monster Breed VIEW Monster Combat Login

12. Two links sent to me … Humor: If Programmers Had to Build Planes http://www.flixxy.com/if-programmers-had-to-build-planes.htm Which would be funny except… F-22 Raptors http://it.slashdot.org/it/07/02/25/2038217.shtml

13. The Goal of Software Engineering The right software, delivered defect free, on time and on cost, every time.

14. Software Craftmanship Software craftsmanship (McBreen 2001)McBreen 2001 Craft of writing software Craft of using software Distinguish from software engineering Scope Rigor Relevant distinction?

15. Why Industry Practices? Software engineering is the application of theory and practice of computer science project management engineering domains Where better to look at application?

16. Software Engineering History First key conference in 1968 Became important because of perceived software crisis in productivity Cost and budget overruns (OS/360) Morphed to issues of quality Financial implications (BoNY) Safety (Therac)

17. BoNY (1985) BoNY (Bank of New York): Nation’s largest clearer of government securities Software to track Federal securities transactions wrote new information on top of old. Feds debited the bank for each transaction but bank did not know who owed it how much. 90 minutes => $32 Billion overdraft !

18. Cost of Bug Bank had to borrow $24 bill from federal reserves. Interest paid ~$5 mill for 1 day. (Annual earnings of bank ~120 mill) BoNY share prices dropped by 25c Federal funds rate dropped from 8.4% to 5.5% System down for 28 hours. Fear of financial crisis caused increase in price of platinum!

19. Cause of bug Message buffer counter at BoNY system was 16-bit long. Counters at Fed (and other banks) 32 bit. More than 32,000 transactions that morning! =>Counter overflow Securities database corrupted.

20. The Drama continues… Trying to correct it – they copied corrupted data over the backup. Lost a few hours because of this. Does code for error recovery get tested at all?

21. Therac-25 (1985-1987) Medical linear accelerator Used to zap tumors with high energy beams. Electron beams for shallow tissue or x-ray photons for deeper tissue. Eleven Therac-25s were installed: Six in Canada Five in the United States

22. Therac-25 Changes from Therac-20 Uses new “double pass” technique to accelerate electrons…more deadly Machine itself takes up less space Software now coupled to the rest of the system and responsible for safety checks. Hardware safety interlocks removed. “Easier to use”

23. Therac-25 Turntable Counterweight Field Light Mirror Beam Flattener (X-ray Mode) Scan Magnet (Electron Mode) Turntable

24. What Happened? Six patients were delivered severe overdoses of radiation between 1985 and 1987. Four of these patients died. Why? The turntable was in the wrong position. Patients were receiving x-rays without beam-scattering.

25. What would cause that to happen? Race conditions. Several different race condition bugs. Overflow error. The turntable position was not checked every 256th time the “Class3” variable is incremented. No hardware safety interlocks. Wrong information on the console. Non-descriptive error messages. “Malfunction 54” “H-tilt” User-override-able error modes.

26. Source of the Bug Incompetent engineering. Design Troubleshooting Virtually no testing of the software. The safety analysis excluded the software! No usability testing.

27. Back to History

28. 1960’s 60’s “Cowboys” wrote software anyway that they could Difference between best programmers and worst as high as 28:1 (many sources) 1968 Edsger Dijkstra, “GOTO Statement Considered Harmful” (CACM) Recognition that rules can improves the average programmer The start of software engineering?

29. Structuring Software Development Few rules helped immensely Good rules and practices developed over the 70’s and 80’s If a few rules are good, more are better… Late 80’s, major focus on process as a key to quality ISO 9000 Malcolm Baldridge National Quality Award Why not apply to software development?

30. ISO 9000 What is ISO? International body 150 national standards organization US: ANSI Primarily technical standards Recent years has broadened its scope Generic management system standards First published in 1987 Revision in 2000 Compendium of best practices Not the process but the management of the process http://www.iso.org/iso/en/ISOOnline.frontpage

31. Which brings us back to What is part of software engineering?

32. The 4 P’s of Software Engineering Product: what is produced Process: the manner in which it is done Project: the doing of it People: those doing it

33. Product Sales brochure Use cases and requirements Design document: from architecture to detailed design Fully documented code Test plan and tools Manuals Users Administrators

34. Process Software Engineering Steps Software Engineering Processes Reviews and Inspections

35. Software Engineering Elaborated Steps Concept Requirements Architecture Design Implementation Unit test Integration System test Maintenance

36. Software Engineering Processes Differ by how often you do the steps Points on the spectrum Differences in overhead Three fundamental models Waterfall Spiral Iterative Two widely used models Rational Unified Process (a.k.a. Unified Software Development Process) Extreme Programming

37. Integrated Product Development: The IBM Approach Originated at GE Key principles Cross-functional teams at all phases Phased approval Example checkpoints Concept Plan Ship Sunset

38. Rational Unified Process Iterations within phases 4 phases Inception (interaction with stakeholders) Elaboration (architecture and functions) Construction (initial operational) Transition (completed product) Core workflows for each iteration Requirements Analysis (part of Requirements) Design Implementation (includes Integration) Test

39. Unified Process Matrix ElaborationInceptionConstructionTransition Requirements Analysis Design Implemen- tation Test

40. Extreme Programming Complete development process First code drop is 2-3 weeks after start Customer a part of the development team Iterative development to the max Derive requirements with customer through hands-on experimentation Agile methodology

41. Why XP? Companies started codifying their practices Large documents and people to manage them Rise of the project manager “Honored in the breach” More large projects and more late or failed projects

42. 1995 Standish Group Study 50% software projects challenged 2x budget 2x completion time 2/3 planned function 30% impaired Scrapped 20% success http://web.mit.edu/Saltzer/www/publications/Saltzerthumbnails. pdf

43. Agile Methodologies Keep only those rules and processes that help Antidote to bureaucracy License to hack Key characteristics Adaptive People-oriented

44. Extreme Programming: History Kent Beck considered the inventor Ideas developed in the early 90’s First project at Daimler Chrysler in 1996

45. XP Bills of Rights Developer has a right to Clear requirements and priorities Determine how long a requirement will take to implement Revise estimates Always produce quality code Customer has a right to An overall plan See progress in a running system Change requirements and priorities Be informed of changes to schedule and have input as to how to adapt Cancel in the middle and still have something to show for the investment