ECE 355 Software Engineering Instructor Kostas Kontogiannis

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

How to reach me Kostas Kontogiannis Web: www.swen.uwaterloo.ca/~kostas E-mail: kostas@swen.uwaterloo.ca Tel. (xt. 2840) Office hours: Monday 16:00 – 17:00 DC 2539

ECE 355: Software Engineering CHAPTER 1 Unit 1

Outline for today Introduction Course description Software engineering basics

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

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

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

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”

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

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)

Outline for today Introduction Course description Software engineering basics

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?

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

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.

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

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 610.12]

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

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

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

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

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

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

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

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