3. Engineering  Turning ideas into reality  Creating something useful from other things using science and math

4. Software Engineering vs. Other Engineering Disciplines  Maturity Roman aqueducts 2000 years ago Software engineering 50 years ago  Startup costs Barriers to entry  Rate of change

5. Software Engineering Objective The right software delivered defect free, on time and on cost, every time. Carnegie Mellon Software Engineering Institute

6. Common Mistakes  Over committing (“big eyes”)  Unrealistic schedules Training Access to people or materials Hours in the day  Level of detail Vague descriptions Over specification  Not knowing your user  Assuming that you’ll get it right the first time

7. Different Types of Projects  Consider 4 different types of systems COMP 523 projects Productivity suites Commercial web sites Airplane systems Pacemakers  How do they differ in criticality?  What does that mean for the development process?

8. All software projects are different but … Requirements will change. Surprises will happen. Schedules will slip. Life will happen.

9. Transparency  Track what you do AND document it  …not as an afterthought  Living, heavily-used documentation

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

12. 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 (first published 1987) ISO 9000 Malcolm Baldrige National Quality Award (just celebrated 25 th anniversary) Malcolm Baldrige National Quality Award

13. Why not apply to software development?  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 1995 Standish Group Study Jerry Saltzer SOSP 1999

14. 1995 Standish Group Study  50% software projects challenged 2x budget 2x completion time 2/3 planned function  30% impaired Scrapped  20% success

15. Jerry Saltzer Presentation  Who is Jerry Saltzer? Early time sharing (CTSS) Multics Operating System (“inspired” Unix) Project Athena ○ Thin client computing ○ Kerberos ○ LDAP ○ Instant messaging

17. Software Engineering Processes  Differ by how often you do the steps Points on the spectrum Differences in overhead  Three fundamental models Waterfall Spiral Iterative  Widely used models Integrated Product Development Unified Software Development Process Extreme Programming

18. All models address the 4 P’s of Software Engineering  People: those doing it  Product: what is produced  Process: manner in which it is done  Project: the doing of it

19. Fundamental Steps  Requirements  Design  Implementation  Test  Deployment  Maintenance

20. Processes  Differ by how often you do the steps Focus and emphasis  Points on the spectrum  Differences in overhead  Three fundamental processes Waterfall Spiral Iterative

21. Waterfall  Do it once  Traditional model  Used for large next version releases,  especially when  well understood product  tightly coupled changes

22. Waterfall  1970s  Built on 1950’s stage- wise process  Recognized the need for feedback Limited Heavy process

23. Waterfall  Pros Simple documentation management Clean design phase  Cons Least flexibility No early feedback

24. Iterative (a.k.a. Agile)  Many iterations  Each iteration is on a fixed cycle Typically biweekly  Used for projects with  lots of small independent, but well understood, changes  small development team  strong client involvement

25. Iterative  Reaction to waterfall  Derived from “evolutionary” process Requirements and specs evolve over time  Two well-known models Extreme programming SCRUM

26. Iterative (a.k.a. Agile)  Pros Fast feedback on problems Very adaptable to any changes Lots of versions to work with Heavy user involvement  Cons Document maintenance Code maintenance Requires good automation

27. Spiral  Few iterations  Each iteration adds new requirements  Used often for projects with less well defined requirements

28. Spiral  Risk based  Barry Boehm 1988  “A Spiral Model of Software Development and Enhancement”

29. Spiral  Pros Adaptation to changes based on risks Good customer interaction Early version Limited iterations provide phase structure  Cons Document maintenance

30. Unified (Software Development) Process spiral variant  Iterations within phases  4 phases and core workflows for each  Identifies that iterations differ Requirements Analysis Design Implementation Test ElaborationInceptionConstructionTransition Also known as Rational Unified Process (Rational products)Rational Unified Process

31. Historical Recap  Waterfall: 1970, built on 1950’s stage- wise processes Recognized need for feedback  Iterative (agile): late 70s,modeled on evolutionary model Didn’t work well for large products  Spiral: 1988, risk-based