SOFTWARE ENGINEERING PROCESSES Software Engineering Engineering Turning ideas

SOFTWARE ENGINEERING PROCESSES

Software Engineering

Engineering � Turning ideas into reality � Creating something useful from other things using science and math

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

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

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 �

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

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

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

Programming History

1960’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) � Recognition that rules can improve the average programmer

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) � Malcolm Baldrige National Quality Award 25 th anniversary) (just celebrated

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

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

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

Processes

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

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 �

Fundamental Steps � Requirements � Design � Implementation � Test � Deployment � Maintenance

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

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

Waterfall � 1970 s � Built on 1950’s stagewise process � Recognized the need for feedback �Limited �Heavy process

Waterfall � Pros �Simple documentation management �Clean design phase � Cons �Least flexibility �No early feedback

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

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

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

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

Spiral � Risk based � Barry Boehm 1988 � “A Spiral Model of Software Development and Enhancement”

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

Unified (Software Development) Process spiral variant Iterations within phases � 4 phases and core workflows for each � � Identifies that iterations differ Inception Elaboration Construction Transition Requirements Analysis Design Implementation Test Also known as Rational Unified Process (Rational products)

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