1. An Introduction to Software Engineering

2. Software engineering is concerned with theories, methods and tools for professional software development Software engineering

3. Course Themes 1. Leadership of large software projects  Software as a product Clients and their needs Quality  Requirements and specification Usability Evolution  Project management Personnel management Economic, legal, and social factors

4. Course Themes 2. Large and very large systems  Software design Software architecture Object-oriented design  Dependable systems Reliability Verification

5. FAQs about software engineering l What is software? l What is software engineering? l What is the difference between software engineering and computer science? l What is the difference between software engineering and system engineering? l What is a software process? l What is a software process model?

6. FAQs about software engineering l What are the costs of software engineering? l What are software engineering methods? l What is CASE (Computer-Aided Software Engineering) l What are the attributes of good software? l What are the key challenges facing software engineering?

7. What is software? l Computer programs and associated documentation l Software products may be Generic - developed to be sold to a range of different customers Bespoke (custom) - developed for a single customer according to their specification Embedded Built into hardware Hard to change

8. Software products l Generic products Stand-alone systems that are marketed and sold to any customer who wishes to buy them. Examples – PC software such as editing, graphics programs, project management tools; CAD software; software for specific markets such as appointments systems for dentists. l Customized products Software that is commissioned by a specific customer to meet their own needs. Examples – embedded control systems, air traffic control software, traffic monitoring systems. 8

9. Software Applications 1. System software: such as compilers, editors, file management 2. Application software: stand-alone programs for specific needs. 3. Engineering/scientific software: such as automotive stress analysis, molecular biology, orbital dynamics etc 4. Embedded software resides within a product or system. (key pad control of a microwave oven, digital function of dashboard display in a car) 5. Product-line software focus on a limited marketplace to address mass consumer market. (word processing, graphics, database management) 6. WebApps (Web applications) network centric software :remote database and business applications. 7. AI software Robotics, expert system, pattern recognition game playing

10. Software Engineering Software Engineering is the science and art of building significant software systems that are: 1) on time 2) on budget 3) with acceptable performance 4) with correct operation.

11. What is Software Engineering? Some Definitions and Issues “state of the art of developing quality software on time and within budget” l Trade-off between perfection and physical constraints SE has to deal with real-world issues l State of the art! Community decides on “best practice” + life-long education

12. What is Software Engineering? “multi-person construction of multi-version software” l Team-work Scale issue (“program well” is not enough) + Communication Issue l Successful software systems must evolve Change is the norm, not the exception

13. 13 Why Study Software Engineering? l To acquire skills to develop large programs. Exponential growth in complexity and difficulty level with size. The ad hoc approach breaks down when size of software increases

14. What is the difference between software engineering and system engineering? l System engineering is concerned with all aspects of computer-based systems development including hardware, software and process engineering. Software engineering is part of this process l System engineers are involved in system specification, architectural design, integration and deployment

15. What is a software process? l A set of activities whose goal is the development or evolution of software l Generic activities in all software processes are: Specification - what the system should do and its development constraints Development - production of the software system Validation - checking that the software is what the customer wants Evolution - changing the software in response to changing demands

16. Engineering Process Model l Specification: Set out the requirements and constraints on the system. l Design: Produce a model of the system. l Manufacture: Build the system. l Test: Check the system meets the required specifications. l Install: Deliver the system to the customer and ensure it is operational. l Maintain: Repair faults in the system as they are discovered.

17. Component Diagram

18. Deployment Diagram

19. Collaboration Diagram

20. Statechart Diagram

21. Activity Diagram

22. What is a software process model? l A simplified representation of a software process, presented from a specific perspective l Examples of process perspectives are Workflow perspective - sequence of activities Data-flow perspective - information flow Role/action perspective - who does what Waterfall Evolutionary development Formal transformation Integration from reusable components

23. Generic Software Process Models l Waterfall Separate and distinct phases of specification and development l Evolutionary Specification and development are interleaved l Formal Transformation A mathematical system model is formally transformed to an implementation l Reuse-based The system is assembled from existing components

24. Waterfall Process Model

25. Evolutionary Process Model

26. Spiral Process Model

27. Software Quality... l Usability Users can learn it and fast and get their job done easily l Efficiency It doesn’t waste resources such as CPU time and memory l Reliability It does what it is required to do without failing l Maintainability It can be easily changed l Reusability Its parts can be used in other projects, so reprogramming is not needed

28. 28 Emergence of Software Engineering l Early Computer Programming (1950s): Programs were being written in assembly language. Programs were limited to about a few hundreds of lines of assembly code.

29. Early Computer Programming (50s) l Every programmer developed his own style of writing programs: according to his intuition (exploratory programming).

30.  Software development style was still exploratory.  Typical program sizes were limited to a few thousands of lines of source code. High-Level Language Programming (Early 60s)

31. 31 Control Flow-Based Design (late 60s) l Size and complexity of programs increased further: exploratory programming style proved to be insufficient. l Programmers found: very difficult to write cost-effective and correct programs.

32. Control Flow-Based Design (late 60s) l Programmers found: programs written by others very difficult to understand and maintain.

33. Control Flow-Based Design (late 60s) l Using flow charting technique: one can represent and design a program's control structure. Usually one understands a program: by mentally simulating the program's execution sequence.

34. Control Flow-Based Design (Late 60s) l It was found: GO TO ) JUMP ( statements makes control structure of a program messy GO TO statements alter the flow of control arbitrarily. The need to restrict use of GO TO statements was recognized.

35. Control Flow-Based Design (Late 60s) l But, soon it was conclusively proved: A program is called structured only three programming constructs are sufficient to express any programming logic: sequence (e.g. a=0;b=5;) selection ( e.g. if(c=true) k=5 else m=5;) iteration (e.g. while(k>0) k=j-k;)

36. Data Structure-Oriented Design (Early 70s) l Soon it was discovered: it is important to pay more attention to the design of data structures of a program than to the design of its control structure.

37. 37 Data Flow-Oriented Design (Late 70s) l Data flow-oriented techniques advocate : the data items input to a system must first be identified, processing required on the data items to produce the required outputs should be determined.

38. Data Flow Model of a Car Assembly Unit Fit Engine Paint and Test Fit Wheels Fit Doors Chassis Store Door Store Wheel Store Engine Store Car Partly Assembled Car Assembled Car Chassis with Engine

39. Simple design tools State diagram

40. 40 Object-Oriented Design (80s) l Object-oriented technique: an intuitively appealing design approach: natural objects (such as employees, pay-roll-register, etc.) occurring in a problem are first identified.

41. 41 Object-Oriented Design (80s) l Relationships among objects: such as composition, reference, and inheritance are determined. l Each object essentially acts as a data hiding (or data abstraction) entity.

42. When software projects go wrong London Ambulance Service –1992, computerised ambulance despatch system fails Therac-25 –2 people died and several others exposed to dangerous levels of radiation because of software flaws in radiotherapy device OSIRIS –£5M University financial package –Expenditure to date more like £20-25M NPfIT? –NHS £12 billion IT project comp.risks is a great source of others...

43. Testing Testing cannot show the absence of defects, it can only show that software defects are present. 1. Testing is a process of executing a program with the intent of finding an error. 2. A good test case is one that has a high probability of finding an as yet undiscovered error. 3. A successful test is one that uncovers an as yet undiscovered error.

44. Testing Methods Black-box testing Knowing the specified function that a product has been designed to perform, tests can be conducted that demonstrate each function is fully operational. White-box or glass-box testing Knowing the internal workings of a product, tests can be conducted to ensure that "all the gears mesh". 1. independent paths at least once 2. logical decisions both true and false 3. loops 4. internal data structures

45. Design patterns l Programs regularly employ similar design solutions l Idea is to standardise the way these are implemented Code re-use Increased reliability Fewer errors, shorter development time l An array is special case of a container type Way of storing a collection of possibly ordered elements. List, stack, queue, double-ended list, etc l Templates in C++ offer a way of providing libraries to implement these standard containers

46. Future Experience What will you be doing one year from now? Ten years from now?

47. © Oscar Nierstrasz ESE — Introduction ESE 1.47 Course schedule WeekLesson 1 Introduction — 2 The Software Lifecycle 3 Project Management 4 Requirements Collection 5 Waterfall lifecycle model 6 Iterative model 7 Agile model 8 Modeling Objects and Classes 9 UML 10 Software Architecture 11 User Interface Design 12 Software Metrics 13 Software Quality Software Validation

48. Projects  Project teams, about 3 to 5 people.  Select your own project, any branch of software engineering  Real project for real client who intends to use the software in production.  Presentations: requirements design final

49. Client (a.k.a Customer)  The client provides resources and expects some product in return.  Client satisfaction is the primary measurement of success. Question: Who is the client for Microsoft Excel?