1. ECE 355 Software Engineering Instructor Kostas Kontogiannis

2. Welcome Welcome to the Software Engineering course
Demanding, challenging and, rewarding course
A glimpse of what software engineering in industry is all about

3. How to reach me Kostas Kontogiannis
Web:
Tel. (xt. 2840)
Office hours:
Monday 16:00 – 17:00
DC 2539

4. ECE 355: Software Engineering CHAPTER 1
Unit 1

5. Outline for today Introduction Course description
Software engineering basics

6. Course components 4 lectures 6 tutorials 1 project Section 2 RCH 302
9:30-11:20 Th
Section 1 RCH 101, RCH 103
15:30 – 16:20 T,
14:30-16:20 Th
6 tutorials
T, Th, F
1 project

7. Course website http://www.swen.uwaterloo.ca/~kostas/ECE355-05/
schedule
lecture notes & slides
recommended book
Object Oriented Software Engineering Using UML, Patterns and Java, 2nd edition B. Bruegge, A. Dutoit © 2004 Prentice Hall
assignments & solutions and a sample final exam
project description
grade allocation
course news system

8. Project component
Design and implement software for an IP Telephony application
Groups of 4 (after class request)
25% of total grade
Three parts:
Requirements
Design
Implementation

9. Goals of this course
Become familiar with software engineering concepts
Learn how to perform analysis, design and basic project management tasks using examples
Experience software engineering in a larger project that uses several components
Note:
“Scratching the surface of software engineering”
“Fitting you to become an amateur software engineer”

10. Course outline Unit 1: Software Engineering Basics - Chapter 1
Unit 2: Process Models and Software Life Cycle - Chapter 1
Unit 3: Software Requirements - Chapter 4
Unit 4: Unified Modeling Language (UML) - Chapter 2
Unit 5: Design Basics and Software Architecture - Chapter 6
Unit 6: OO Analysis and Design - Chapter 5 & 7 & 9
Unit 7: Design Patterns - Chapter 8 & 10
Unit 8: Testing and Reliability - Chapter 11
Unit 9: Software Engineering Management and Economics - Chapter 3 & 14

11. What to do by Friday Visit the Web site Go to the Project section
Complete Part I
Administration
Complete Part II
Preparation
Task 1 Use of SIP Clients
Task 2 Startup Eclipse (subtask 2.1)

12. Outline for today Introduction Course description
Software engineering basics

13. Software Engineering: A Problem Solving Activity
Analysis: Understand the nature of the problem and break the problem into pieces
Synthesis: Put the pieces together into a large structure
For problem solving we use
Techniques (methods):
Formal procedures for producing results using some well-defined notation
Methodologies:
Collection of techniques applied across software development and unified by a philosophical approach
Tools:
Instrument or automated systems to accomplish a technique
What is Software Engineering? The goal is to produce high quality software to satisfy a set of functional and nonfunctional requirements. How do we do that?
First, and foremost, by acknowledging that it is a problem solving activity. That is, it has to rely on well known techniques that are used all over the world for solving problems. There are two major parts of any problem solving process:
Analysis: Understand the nature of the problem. This is done by looking at the problem and trying to see if there are subaspects that can be solved independently from each other. This means, that we need to identify the pieces of the puzzle (In object-oriented development, we will call this object identification).
Synthesis: Once you have identified the pieces, you want to put them back together into a larger structure, usually by keeping some type of structure within the structure.
Techniques, Methodologies and Tools: To aid you in the analysis and synthesis you are using 3 types of weapons: Techniques are well known procedures that you know will produce a result (Algorithms, cook book recipes are examples of techniques). Some people use the word “method” instead of technique, but this word is already reserved in our object-oriented development language, so we won’t use it here. A collection of techniques is called a methodology. (A cookbook is a methodology). A Tool is an instrument that helps you to accomplish a method. Examples of tools are: Pans, pots and stove. Note that these weapons are not enough to make a really good sauce. That is only possible if you are a good cook. In our case, if you are a good software engineer. Techniques, methodologies and tools are the domain of discourse for computer scientists as well. What is the difference?

14. Software Engineering
Software Engineering is a collection of techniques,
methodologies and tools that help with the
production of:
a high quality software system
with a given budget
before a given deadline
while change occurs. 20

15. Scientist vs Engineer Computer Scientist Engineer Software Engineer
Proves theorems about algorithms, designs languages, defines knowledge representation schemes
Has infinite time…
Engineer
Develops a solution for an application-specific problem for a client
Uses computers & languages, tools, techniques and methods
Software Engineer
Works in multiple application domains
Has only 3 months...
…while changes occurs in requirements and available technology
A computer scientist assumes that techniques, methodologies and tools are to be developed. They investigate in designs for each of these weapons, and prove theorems that specify they do what they are intended to do. They also design languages that allow us to express techniques. To do all this, a computer scientist has available an infinite amount of time.
A software engineering views these issues as solved. The only question for the software engineer is how these tools, techniques and methodologies can be used to solve the problem at hand. What they have to worry about is how to do it under the time pressure of a deadline. In addition they have to worry about a budget that might constrain the solution, and often, the use of tools. Good software engineering tools can cost up to a couple of $10,000 Dollars (Galaxy, Oracle 7, StP/OMT)
Object modeling is difficult. As we will see, good object modeling involves mastering complex concepts, terminology and conventions. It also requires considerable and sometimes subjective expertise in a strongly experience-based process. Beware of the false belief that technology can substitute for skill, and that skill is a replacement for thinking. offers this advise [cit Tillmann].
Many organizations are frustrated with a lack of quality from their tool-based systems. However, the cause of this problem is often the false belief that a tool can be a substitute for knowledge and experience in understanding and using development techniques. Although CASE tools such as StP/OMT or Objectory and similar tools have the potential to change how people design applications, it is a mistake to think they can replace the skills needed to understand and apply underlying techniques such as object, functional or dynamic modeling. You cannot substitute hardware and software for grayware (brain power) [cit Tillmann]: Buying a tool does not make a poor object modeler a good object modeler. Designers need just as much skill in applying techniques with CASE tools as they did with pen and paper.
Another problem, that is often associated with tool-based analysis is that it is often insufficient or incomplete. Why is that? To a certain extent this problem has always existed. Systems developers are much better at collecting and documenting data than they are at interpreting what these data mean. This in unfortunate, because the major contribution an analysist can bring to system development is the thought process itself. But just as a tool is not a substitute for technique, knowledge and experience, technique skills cannot replace good analysis - people are still needed to think through the problem.
So our message is: Being able to use a tool does not mean you understand the underlying techniques, and understanding the techniques does not mean you understand the problem. In the final analysis, organizations and practitioners must recognize, that methodologies, tools and techniques do not represent the added values of the object modeling process. Rather, the real value that is added, is the thought and insight that only the analyst can provide.

16. Science, Engineering, Management, Human Factors
Science: empirical studies; theories characterizing aggregate system behavior (e.g. reliability)
Management: organizing teams, directing activities, correcting problems
Human factors: user task understanding and modeling; ergonomics in user interface design
Engineering: tradeoffs, canonical solutions to typical problems
Tradeoffs and representative qualities
Pick any two:
Good, fast, cheap
Scalability, functionality, performance
Source: Lecture Notes by Richard Taylor

17. Software Engineering: Definition
The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. [IEEE Standard ]

18. Differences from Programming
Software engineering includes, e.g.:
determining what to build
organizing teams to cooperatively build systems;
analysis and testing
lifecycle system engineering
software architecture
Source: Lecture Notes by Richard Taylor

19. Programming vs. Software Engineering
Small project
You
Build what you want
One product
Few sequential changes
Short-lived
Cheap
Small consequences
Huge project
Teams
Build what they want
Family of products
Many parallel changes
Long-lived
Costly
Large consequences
Programming
Engineering
Source: Lecture Notes by Richard Taylor

20. Prepare to be surprised...
Software engineers deal with a very broad range of projects, kinds of systems, organizational settings, scale, criticality, domain expertise, etc.
Think of the following examples
Embedded software controlling
nuclear power plant
airplane
automobile
telecom network
Information system of large corporations
Standard operating and systems software
Shrink-wrap office software

21. Software Lifecycle Requirements phase Analysis phase
Design phase (System and Object)
Implementation phase
Testing phase
Integration phase
Maintenance phase
Retirement

22. Software Lifecycle Activities
...and their models
Requirements
Elicitation
Analysis
System
Design
Object
Design
Implemen-
tation
Testing
Use Case
Model
Test
Cases ?
Verified By
class....
class...
Source
Code
Implemented By
Solution Domain
Objects
Realized By
Subsystems
Structured By
Application
Domain
Objects
Expressed in Terms Of

23. Product and Process
Which is the more important corporate asset: products or development processes?
Products: the only thing that brings in revenue
Process: the only thing you retain
The asset that distinguishes you from your competitor en route to a product
The asset that gets you to your next product
The asset that determines key properties of your products
Source: Lecture Notes by Richard Taylor

24. The order of things...
Better to think of the phases as activities that could occur
in parallel
in different orders
The order depends on
particular development process and method used and
the project context

25. Average cost distribution (1976–1981 data)
Object-Oriented and Classical Software Engineer 5th Edition, Schach (2002)