1. COMP 7012: Foundations of Software Engineering
Spring 2012
Scott Fleming, Instructor

2. Great software can make the world a better place
What great software has made your life better?

3. Here’s some great software that I’ve used
Facebook: Helps me connect me with old friends
Photoshop: Helps me fix up my photos
Subversion: Helps me manage versions of my software projects
PowerPoint: Helped me produce these slides ;-)

4. Of course not all software is great
What bad software have you encountered?

5. Here’s some bad software that I’ve used
Facebook: Ever try to manage access control/groups?
Photoshop: What does half this stuff even do?
Subversion: Argh! Forgot to use svn to manage files in working copy… again
Word 2009: Mind bogglingly buggy
OK, so most software has pros and cons…
So how can we produce software with
more pros and fewer cons???

6. Making great software ain’t easy
In fact, the “Software Crisis” has been going on since the 1960s
(More like a depression)
Cutter Consortium 2002 survey on litigation (78% of organizations have had disputes ending in litigation)
Standish Group data on 28,000 software projects completed in 2000

7. In this course, you’ll learn how to reliably produce great software …
… and how to avoid the bad

8. What does software engineering mean to you?

9. Engineering is the creation of cost-effective solutions
to practical problems
by applying scientific knowledge
to building things
in the service of mankind
Software engineering aims to do the same where “built things” are software systems

10. Let’s focus on two important challenges in SE
(1) Giving the customers what they want
(2) Cost-effectiveness

11. Problem: Requirements

12. “The customer is always right!”
But …
Customers may change their minds
Customers may not agree with each other
Customers may not know exactly what they want

13. Problem: Cost estimation

14. Spectacular failure: Denver Int’l Airport baggage-handling system
Largest international airport in the US
Scheduled to open in Oct ‘93; actually opened in Feb ‘95
Had to buy back up system and scale back first system after deadline had passed
System never did work as intended and was retired in 2005
Problems both managerial and technical
Hard to get precise figures on how over-budget, but one estimate at $3.2 billion

15. Problem: Bugs

16. Spectacular failure: Therac-25 radiation therapy machine
6 overdoses between Jun ‘85 and Jan ‘87.
First overdose:
Breast cancer
“tremendous force of heat… this red-hot sensation”
Reddening, swelling in front; later matching back; tremendous pain
Lost breast and lost use of arm, shoulder
15,000-20,000 rad overdose; 200 rad normal dose; 1000 to whole body will kill
Manufacturer and operators refused to implicate Therac-25
Other cases were similar; one for skin cancer on face resulted in death in one month

17. Problem: Maintenance

18. All successful software will change over time
But such change can lead to design erosion

19. What ways have you heard of for coping with these problems?

20. Iterative development Test-driven development
In this course, you’ll use four approaches for coping with the challenges of software engineering
Agile development
Iterative development
Test-driven development
Object-oriented analysis and design

21. Values of Agile Development
From the Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

22. Iterative development process
Go around and around in this loop
Each time around is an iteration
Iterations are timeboxed

23. Test-driven development
Write the tests before the code!

24. Object-oriented analysis and design
OOA applies object modeling to understand the requirements for the system (i.e., what the system should do)
OOD elaborates analysis models specify how the system should work (i.e., how the system should do it)

25. OOA/D is best understood with an example
Consider a dice game in which software simulates a player rolling two dice.
If the total is seven, the player wins
Otherwise, he/she loses
Example from Larman (2005)

26. Define use cases UC Play a dice game: Analysis Use cases
Player requests to roll the dice. System presents results. If the dice face value totals seven, player wins; otherwise player loses
Design

27. Define a domain model
Analysis
Use cases
Domain model
Design

28. Assign object responsibilities and draw interaction diagrams
Analysis
Use cases
Domain model
Design
Interaction diagrams

29. Define design class diagrams
Analysis
Use cases
Domain model
Design
Interaction diagrams
Design class diagrams

30. Why is this OOA/D process useful?

31. Why is this OOA/D process useful?
Lowers representation gap between software components and our mental models of the problem domain

32. How does OOA/D fit into an iterative process?

33. Closing thought: To effectively apply these approaches requires a lot of experience
Let’s take a look at the syllabus to see how you’re going to get that experience