2. Team Projects Form teams of 5 (± 1?) students
Project Ideas: Real life idea
No more than two (2) groups working on the same topic
your project idea ASAP, before proposal is due, for feedback

3. 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

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

5. 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

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

7. 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?

8. 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?

9. 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

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

11. 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, [ 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 ]

12. More Complexity Suppose today is Tuesday, Feb. 29
What day will be on April 3?
SOURCE: Hutchins, Cognition in the Wild, The MIT Press, [ 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 ]

13. 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.

14. 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

15. 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.

16. 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)

17. 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

18. 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

19. The Role of Software Engg. (2)

20. Example: ATM Machine
Understanding the money-machine problem:

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

22. 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

23. 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

24. 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

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

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

27. 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

28. 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

29. 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

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

31. Waterfall Process Model

32. UML – Language of Symbols
UML = Unified Modeling Language
Online information:

33. Use Case: Withdraw Cash

34. Actual Design

35. 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.

36. Component Diagram

37. Deployment Diagram

38. Collaboration Diagram

39. Statechart Diagram

40. Activity Diagram

41. Evolutionary Process Model

42. Spiral Process Model

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

44. Formal hedge pruning

45. 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

46. 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

47. Agile Project Effort Estimation

48. Measuring Quality of Work

49. 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

50. 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.

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

52. 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.

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

54. 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.

55. 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.

56. 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;)

57. 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.

58. 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.

59. 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

60. 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.

61. 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.

62. 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.

63. 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.

64. 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.

65. 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

66. 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.

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

68. 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

69. 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

70. 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?