1. EECE 310 Software Engineering
Lecture 0: Course Orientation

2. What is this course about?
Building program modules
Programming in the large
Other skills – design, documentation and testing

3. Building Program modules
Abstraction mechanisms
Procedures
Exceptions
Data abstractions
Iteration abstraction
Polymorphic abstractions

4. Programming in the large
How to design and implement large programs
Requirements analysis and specification
Design
Design patterns
Design evaluation
Implementation and testing

5. Other skills
Understand how individual activities are integrated into the software engineering life-cycle
Appreciate the value of good design and sound engineering principles in software construction
Apply sound techniques for writing specifications, building test-suites, developing design documents
Learn how software engineering works in the “real world” or at least the way it should 

6. What is this course NOT about?
Java/C#/C++ or its (or third party) libraries
Eclipse or any other integrated development environment (IDE) or build tool
Distributed systems, software security, databases, HCI, computer games, ...
Though you’ll use concepts learned in this class for these

7. Mastery of CPSC 260 topics assumed
How is EECE 310 different from earlier software courses (pre-requisite classes) ?
APSC 160: Intro. to Computation in Eng. Design
Introduction to programming languages
CPSC 260: Object-Oriented Program Design
Data structures
Introduction to OO
Emphasis on C/C++ language
Abstraction
Advanced OO
Emphasis on Java
Mastery of CPSC 260 topics assumed

8. Why should you take this course ?
Fundamental class in object-oriented design
You will learn not just how to do it, but why do it that way
Appreciation of design and aesthetics of software
Many of the things you’ll learn have immediate applications (e.g., testing, design patterns, specifications)
If nothing else, you’ll develop an appreciation for large- scale software development and its challenges

9. Course grading Practice (20 %) Exams (55 %) Term project (25 %)
In-class quizzes (5 %)
Assignments (15 %)
Exams (55 %)
Mid-term (20 %)
Final (35 %)
Term project (25 %)

10. Labs and Assignments Labs in MCLD 348 starting from next week
You must be present and demonstrate the solution to the assignment during the session when the assignment is due
You are responsible for ensuring that your code works on the computers in the lab (not on your personal laptops)
The TAs will be there to answer questions about assignments
Assignments: To be done in teams of two
Same partner for all assignments preferred
Same grade for both you and your partner
You must individually be able to explain your solution to us

11. To succeed in this course …
Attend the lectures and participate in activities
We will have active learning components in each class
Ask questions, come to office hours if needed
The concepts may seem easy or even obvious sometimes, but they are hard to apply or get right
Try to solve the recommended exercises in the book
Do the assignments yourself and don’t just hack them
Understand the solutions to the quizzes/mid-term
Think about your project and finish it early !

12. Why study Software Engineering ?
Motivation
Why study Software Engineering ?

13. What is Engineering ? Engineering (Webster)
The application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems.

14. Is Software Engineering ?
“Engineering is design under constraint… Engineering is synthetic - it strives to create what can be, but it is constrained by nature, by cost, by concerns of safety, reliability, environmental impact, manufacturability, maintainability and many other such 'ilities.' ...”
William Wulf and George Fisher

15. Moore’s Law – Compute Power

16. Constraints of Software Engineers
Not like those for “real” engineers:
Weight, physics, etc.
Complexity of what we can understand
Most important constraints:
Limits of human memory
Cost of human effort
This class is about managing complexity to efficiently produce reliable, complex software systems.

17. Why is software difficult to get right ?
... The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work. Human beings are not accustomed to being perfect, an few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program. -Frederick P. Brooks, "The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)”, 1965

18. Growth in size of Linux Kernel between 1991 and 2003
Software Complexity
Growth in size of Linux Kernel between 1991 and 2003

19. S/W Failure Example 1: Therac-25
Radiation machine produced by Atomic Energy of Canada
In 1986, delivered massive overdoses of radiation injuring 100 patients and killing 3
Caused by a Software error (race condition) that led to the wrong beam being engaged
Main reasons for the failure:
Inadequate testing – one person tested whole system
Program did not check its internal values for consistency – user-error in data entry went unnoticed by the machine

20. S/W Failure Example 2: Ariane 5
Ariane 5 rocket took off but within seconds veered dangerously from its flight path and self-destructed
Ariane 5 code was ported from Ariane 4 code which had a much smaller range of orbital values.
Ariane 5 needed a wider range of values, which led to the overflow of some of the internal variables.
This caused a software exception. Unfortunately, exception handling was disabled, and hence the entire system crashed.

21. Down-to-earth examples of S/W Failures
Windows BSOD
Amazon.com outage
Can you think of examples from your own experiences ?

22. Software Failures Vs. Bridge Failures
Failure to adhere to the laws of physics
Software failures
Failure to adhere to sound design principles
Tacoma narrows, 1940

23. Techniques to reduce the cognitive complexity of software development
Abstraction: Information hiding for divide & conquer
Specifications: Write it down precisely & test it

24. Summary
Software is everywhere – bugs in software can have serious consequences
Software development (on large scale) is hard
Too many details lead to errors – hard to reason about
Important to reduce the cognitive complexity of software
Abstraction: Art of hiding unimportant details and generalizing across multiple entities
Key technique to enable modular development
Write down precise specifications wherever possible

25. Antine De Saint Exupe’ry (“The little prince”)
Perfection is achieved not when there is nothing left to add but nothing left to remove
Antine De Saint Exupe’ry (“The little prince”)