The Rules (and I really mean it!)

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

Ranking Top 200 Jobs (2012) 28. Civil Engineer 38. Nurse 40. Physician 47. Accountant 60. Mechanical Engineer 73. Electrical Engineer 87. Attorney 1. Software Engineer 104. Airline Pilot 133. Fashion Designer 137. High School Teacher 163. Police Officer 173. Flight Attendant 185. Firefighter 196. Newspaper Reporter 200. Lumberjack Software Engineer ranks No. 1, followed by Actuary, Human Resources Manager, Dental Hygienist and Financial Planner. InformationWeek 5/15/12. Based on salary, stress levels, hiring outlook, physical demands, and work environment (www.careercast.com)

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

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

FAQs about software engineering What is software? What is software engineering? What is the difference between software engineering and system engineering? What is a software process? What is a software process model?

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

Computer programs and associated documentation What is software? Computer programs and associated documentation 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

Introduction: Software is Complex Complex  complicated Complex = composed of many simple parts related to one another Complicated = not well understood, or explained

Complexity Example: Scheduling Fence Construction Tasks Nailing [ 2 time units for unpainted; 3 time units otherwise ] Painting [ 5 time units for uncut wood; 4 time units otherwise ] Setting posts [ 3 time units ] Cutting wood [ 2 time units ] SOURCE: Goodaire & Parmenter, Discrete Mathematics with Graph Theory, Third Edition, Pearson Prentice Hall, 2006. [ Section 11.5, p. 361 ] Setting posts  Nailing, Painting Cutting  Nailing …shortest possible completion time = ? [  “simple” problem, but hard to solve without a pen and paper ]

More Complexity Suppose today is Oct. 29 What day will be on Dec. 3? SOURCE: Hutchins, Cognition in the Wild, The MIT Press, 1995. [ p. 315 ] [ To answer, we need to bring the day names and the day numbers into coordination, and for that we may need again a pen and paper ]

Software products Generic products Customized 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. 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.

Software 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

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.

The Role of Software Engg. (1) A bridge from customer needs to programming implementation Customer Software Engineering Programmer "You cannot solve it, unless you understand it." First law of software engineering Software engineer is willing to learn the problem domain (problem cannot be solved without understanding it first)

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

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

The Role of Software Engg. (2)

Example: ATM Machine Understanding the money-machine problem:

How ATM Machine Might Work Domain model created with help of domain expert

Why Study Software Engineering? 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

Law of Software Engineering Software should be written for people first ( Computers run software, but hardware quickly becomes outdated ) Useful + good software lives long To nurture software, people must be able to understand it

Understanding the Problem Domain System to be developed Actors Agents external to the system Concepts/ Objects Agents working inside the system Use Cases Scenarios for using the system

ATM: Gallery of Players Actors (Easy to identify because they are visible!)

Gallery of Workers + Things Concepts (Hard to identify because they are invisible/imaginary!)

What is the difference between software engineering and system engineering? 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 System engineers are involved in system specification, architectural design, integration and deployment

What is a software process? A set of activities whose goal is the development or evolution of software 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

Software Development Methods Method = work strategy The Feynman Problem-Solving Algorithm: (i) Write down the problem (ii) think very hard, and (iii) write down the answer. Waterfall Unidirectional, finish this step before moving to the next Iterative + Incremental Develop increment of functionality, repeat in a feedback loop Agile User feedback essential; feedback loops on several levels of granularity

Waterfall Method Unidirectional, no way back finish this step before moving to the next

Waterfall Process Model

UML – Language of Symbols UML = Unified Modeling Language Online information: http://www.uml.org

Use Case: Withdraw Cash

Actual Design

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

Component Diagram

Deployment Diagram

Collaboration Diagram

Statechart Diagram

Activity Diagram

Evolutionary Process Model

Spiral Process Model

Software Measurement What to measure? Project (developer’s work), for budgeting and scheduling Product, for quality assessment

Formal hedge pruning

Sizing the Problem (1) Step 1: Divide the problem into small & similar parts Step 2: Estimate relative sizes of all parts Size(  ) = 4 Size(  ) = 7 Size(  ) = 10 Size(  ) = 3 Size(  ) = 4 Size(  ) = 2 Size(  ) = 4 Size(  ) = 7

Total size =  points-for-section i (i = 1..N) Sizing the Problem (2) Step 3: Estimate the size of the total work Total size =  points-for-section i (i = 1..N) Step 4: Estimate speed of work (velocity) Step 5: Estimate the work duration Travel duration = Path size Travel velocity

Agile Project Effort Estimation

Measuring Quality of Work

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

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

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

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

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

Control Flow-Based Design (late 60s) 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.

Control Flow-Based Design (Late 60s) 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.

Control Flow-Based Design (Late 60s) 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;)

Data Structure-Oriented Design (Early 70s) 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.

Data Flow-Oriented Design (Late 70s) 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.

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

Simple design tools State diagram State machines represents how a system responds to internal and external stimuli, by showing how the internal state of the system changes in response to events. This representation should be familiar from P2/A2 Digital Logic and Computer Architecture courses. Unlike the data-flow model, the state machine representation does not show the flow of data within the system. State machines are often useful abstractions when dealing with real-time systems, because these are often driven by external events. In the example the diagram (taken from Sommerville p176) shows how the states of a simple microwave oven vary.

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

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

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

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... LAS: project to computerise ambulance despatch. To be completed in 6 months. A consortium of Apricot, Systems Options and Datatrak made the cheapest bid and was awarded the contract. Because of time pressures, and the lack of experience of the development team in dealing with safety-critical systems, fundamental flaws in system design, and inadequate consultation with users, the system went “live” even though there were 81 known errors. It ran for a day and a half before being shut down. A further 10-day trial was abandoned and the LAS reverted to manual operation. From the Independent, 30 Oct 1992, “Computer specialists yesterday said that the system blamed for this week's crisis at the London Ambulance Service appeared to ignore basic tenets for software where breakdown would put lives at risk. The failure of the computer system over 36 hours on Monday and Tuesday, which was said to have cost between 10 and 20 lives, raised serious questions about the way it was designed and tested, experts said. Yesterday, the software company involved, Systems Options, refused to comment.” Therac-25: See Leveson, especially Appendix A OSIRIS: Classic failures of trying to build a systemn to serve two different needs and neglecting one. Commissioned in 01/02. In Nov 2003 departmental administrators highlight 10 points critical to operation not adequately addressed, in partic the ability to generate reports central ro management of finances. System goes live in April 2004 with major omissions/flaws and University lucky to escape without serious financial meltdown.

Testing Methods Black-box testing White-box or glass-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". independent paths at least once logical decisions both true and false loops internal data structures

Design patterns Programs regularly employ similar design solutions Idea is to standardise the way these are implemented Code re-use Increased reliability Fewer errors, shorter development time 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 Templates in C++ offer a way of providing libraries to implement these standard containers Programmers regularly use similar, or even identical design solutions for problems.

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

Course schedule Week Lesson 1 Introduction — 2 The Software Lifecycle ESE — Introduction Course schedule Week Lesson 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 © Oscar Nierstrasz

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

Team Projects Project Ideas: Real life idea No more than two (2) groups working on the same topic Email your project idea ASAP, before proposal is due, for feedback Y.fouad@alexu.edu.eg

Project Deliverables Item Due week 1. Proposal 2 2.   First report   (Specification)       • Part 1 (Statement of Work & Requirements)       • Part 2 (Functional Requirements Spec & UI)       • Full Report #1   3 5 6 3.   Second report   (Design)       • Part 1 (Interaction Diagrams)       • Part 2 (Class Diagram and System Architecture)       • Full Report #2   7 8 9 4.   First demo 10 ► ... 5.   Third report   (All reports collated) 11 6.   Second demo 12► ... 7.   Electronic Project Archive 13

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?

END