Software Engineering

1
Software Engineering

• Dr Zumao Weng
• School of Computing and Intelligent Systems, UUM
• 22-9-2009

2
Module Information

• Lecturer Dr Zumao Weng
• Room MG050
• Tel [phone]
• E-mail zm.weng_at_ulster.ac.uk
• Pre-requisite
• Algorithms and Data Structures
• Object-oriented Systems Development
• Object Oriented Programming
• Aims
• To develop students' knowledge and capability in
  the theories, methods and tools required to build
  manage and evolve efficient, economic and
  effective software systems. To build upon the
  second year prerequisites and provide students
  with a critical awareness of the relationship
  between software engineering and systems design,
  quality management, process improvement, project
  and risk management, reliability and the ethical
  and legal dimensions of the subject. To provide
  the student with knowledge, understanding and
  experience in designing and implementing software
  solutions. To foster an understanding of the
  software engineering process, and the tools and
  technologies required to support this process. To
  engender an ability to operate in a proper
  professional and ethical framework.
• Lecture 09.15-12.05, Tuesday, MF231
• Lab 12.15-14.05, Tuesday, MG122

3
Learning Outcomes

• A successful student will be able to show that
  he/she can
• Knowledge and Understanding
• Critically evaluate software engineering
  techniques and approaches.
• Show a critical appreciation for the importance
  of systems architecture design within the
  software engineering process.
• Develop a detailed understanding of key issues
  concerned with building dependable software
  systems.
• Develop a detailed understanding of the software
  management process.
• Intellectual Qualities
• Exercise professional judgement in the selection
  of appropriate software engineering approaches
  and techniques in order to increase the
  productivity and quality of the software
  development process.
• Choose appropriate tools and techniques to
  estimate and plan a small to medium project.
• Analyse the software requirements of a simple
  system.
• Plan the testing for a software module.
• Professional/Practical Skills
• Demonstrate the ability to apply project
  management techniques.
• Demonstrate competence in the design,
  specification and implementation of
  components-based solutions.
• Demonstrate competence in the use of industry
  standard software engineering tools and
  technologies.
• Demonstrate an ability to apply verification and
  validation techniques.
• Transferrable Skills
• Demonstrate the ability to work as part of a
  group.
• Independently explore advanced features of a
  complex software tool.

4
Teaching and Learning Methods

• Lectures will be used to represent the theory and
  concepts. All lecture and supplementary material
  will be accessible by students thought the
  facultys website. Tutorial tasks will be
  employed during lecture time to ensure
  understanding and to work through examples and
  implications of the theory and concepts
• Practical exercises will support the lecture
  contents using CASE tools and relevant industry
  standard technologies. Students will apply a
  software engineering approach to defined
  scenarios and implement a solution using object
  oriented language and industry standard
  technologies. The students will work in small
  groups during practical time and will present
  material in a group assignment to which each will
  contribute. They will best facilitate a blending
  of individuals understanding through discussion
  and peer tutoring. The students are also
  requested to review a list of literatures and
  give their point of views independently.
• The module is web-supplemented

5
Assessment

• Typically the coursework will comprise of two
  assignments, a group project and an independent
  one.
• Each assignment is normally 50 of the coursework
  mark.
• Coursework 1
• This is a group assignment, 4 students per group,
  in which the requirements
• specifications and design documentations for a
  given software development project
• are expected. The assessment of individuals
  contribution is based on the student
• statement in the documentations regarding their
  individuals contribution in the
• group.
• Coursework 2
• This is an independent assignment in which a set
  of questions covering a couple of
• specific software engineering topics are
  provided. Students are requested to answer
• all the questions in their point of views
  according to the lectures and literatures.
• Examination
• There will be a three-hour written examination
  where typically, a student is required
• to answer any four from six questions and each
  question is normally 25 marks.

6
Recommended Indicative Texts

• Leszek A. Maciaszek Bruc Lee Liong, Practical
  Software Engineering A Case Study Approach,
  Addison Wesley, 2005
• Bernd Bruegge and Allen H. Dutoit,
  Object-Oriented Software Engineering 2nd Ed.,
  Prentice Hall, 2004
• Ian Sommerville, Software Engineering, 8th Ed.,
  Addison Wesley, Pearson Education, 2004.
• Roger Pressman, Software Engineering a
  Practitioner's Approach, 5th ed., McGraw-Hill,
  2000
• Mark Priestley, Practical Object-oriented Design
  with UML, McGraw-Hill, 2000
• Steve C. McConnell, Code Complete A Practical
  Handbook of Software Construction, Microsoft
  Press International, 1993
• Simon Bennett, John Skelton, Ken Lunn, Schaums
  Outlines UML, Schaum, 2001
• P Stevens and R Pooley, Using UML - Software
  Engineering with objects and components, Addison
  Wesley, 2000
• Sinan Si Alhir, UML in a Nutshell, O'Reilly, 1998
• Fowler, M. and Scott, K, UML Distilled, Addison
  Wesley, 1997
• Meilir Page-Jones, Fundamentals of
  Object-oriented Design in UML, Addison Wesley,
  2000
• Ed Kit, Software Testing in the Real World,
  Addison Wesley, 1995
• Leszek Maciaszek, Requirements Analysis and
  System Design, Addison Wesley, 2001
• Suzanne Robertson, James Robertson, Mastering the
  Requirements Process, Addison Wesley, 1999
• Stephen H. Kan, Metrics and Models in Software
  Quality Engineering, John Wiley and Sons,1995
• Gerald Kotonya, Ian Somerville, Requirements
  Engineering, John Wiley and Sons, 1998
• William Perry, Effective Methods for Software
  Testing, John Wiley and Sons, 1999
• Karl E. Wiegers, Software Requirements, 1999
• Shari Lawrence Pfleeger, Software Engineering
  Theory and Practice, Prentice Hall, 2001

7
Chapter 1 Introduction
8
Objectives

• Appreciate the problems associated with
  developing software
• Understand the need for a managed approach to
  Software Development
• Be able to define the term Software Engineering

9
The statistics Chaos Report

• Standish Group 1995
• 365 IT executives in US companies in diverse
  industry segments.
• 8,380 projects

10
Over budget

• Home Office IT project millions over budget
• - Lisa Kelly 12-01-2001
• A Home Office IT project run by Bull Information
  Systems is
• expected to blow its budget by millions of pounds
  and is hampered by a restrictive contract,
  according to a leaked report. The National Audit
  Office report, due in the Spring, is expected to
  reveal damning evidence that the project to
  implement two systems - the National Probation
  Service Information Systems Strategy, and the
  Case Record and Management System - for the
  probation service will cost 118m by the end of
  the year, 70 per cent over its original budget.
• http//www.computing.co.uk/News/1116278

11
Over budget / Over schedule

• New air traffic system already obsolete
• By Steve Ranger 24-01-2002
• www.vnunet.com/News/1128597
• National Air Traffic Services (Nats) is already
  looking at replacing the systems at its new
  control centre at Swanwick in Hampshire, even
  though the system doesn't become operational
  until next week. Now running six years late and
  180m over budget, the system will control
  200,000 square miles of airspace over England and
  Wales, looking after two million flights a year.
  It will finally go live on 27 January.
• But long-term planners are already looking at
  replacing the systems. Nats told vnunet.com that
  it plans to do things very differently next time
  in a bid to avoid delays.
• Swanwick was originally meant to be operational
  by 1997, but problems with the development of
  software by Lockheed Martin caused delays,
  according to Nats.
• Air traffic control system crashes again
•    http//www.vnunet.com/News/1130791 
  10-04-2002

12
Data Integrity HP Labs

• We have just finished a study that shows how user
  interface design flaws allow users on Kazaa to
  share their personal files without their
  knowledge. In a laboratory user study, only 2 out
  of 12 subjects were able to correctly determine
  that Kazaa was sharing their entire hard drive.
  We looked at the current Kazaa network and
  discovered that many users are sharing personal
  information such as email and data for financial
  programs such as Microsoft Money. To see if other
  users on Kazaa were aware of this and taking
  advantage of users ignorance, we ran a Kazaa
  client for 24 hours with dummy personal files.
  During this time, files named "Inbox.dbx" and
  "Credit Cards.xls" where downloaded from our
  client by several unique users. The tech report
  can be accessed here http//www.hpl.hp.com/shl/pa
  pers/kazaa/KazaaUsability.pdf or from HP lab web
  page at http//www.hpl.hp.com/shl/
• Source Nathan Good, Information Dynamics Lab, HP
  Laboratories, Palo Alto

13
Data Integrity

• Canadian account holders information was
  accessible, AP, 29 May 2002
• A design flaw at a Fidelity Investments online
  service accessible to 300,000 people allowed
  Canadian account holders to view other customers'
  account activity. The problem was discovered over
  the weekend by Ian Allen, a computer studies
  professor at Algonquin College in Ottawa.
  Fidelity said it had fixed the problem and was
  offering customers the option of changing account
  numbers.
• http//www.msnbc.com/news/758979.asp

14
Safety - London Ambulance Dispatching System

• The full introduction of the computer system
  effectively did away with the radio and telephone
  calls to stations, with the computer dispatching
  crews to answer calls. But within hours, during
  the morning rush, it became obvious to crews and
  control room staff that calls were going missing
  in the system ambulances were arriving late or
  doubling up on calls. Distraught emergency
  callers were also held in a queuing system which
  failed to put them through for up to 30 minutes.
  Chris Humphreys, Nupe's divisional officer, said
  that it was hard to verify how many people might
  have died because of the delays but it could be
  as many as 20.
• However, the ambulance service contradicted
  claims that one 14-year-old boy had died of an
  asthma attach after waiting 45 minutes. It said
  that the call was dealt with in 28 minutes -
  although the Patient's Charter has a target of 14
  minutes. A man of 83 was also said to have died
  before the service reverted to the old system at
  2p.m. on Tuesday.
• Causes assumed location of ambulances known,
  memory leak, operators left out
• From http//128.240.150.127/Risks/13.88.htmlsubj1
  .1

15
Human Error

• EDB Fellesdata AS runs the computer services of
  about half of Norway's banks. On Thursday 2 Aug
  2001, they apparently installed about 280 disks
  in their Hitachi storage. Then, instead of
  initializing the new disks, they initalized all
  their disks -- thereby wiping out the entire
  warehouse. EDB Fellesdata itself declines to make
  any statements in the case pending further
  contact with their customers, the banks. They are
  considering lawsuits, but if one of their own
  employees made a "user error", they may have a
  hard time of it.
• http//www.digitoday.no/dtno.nsf/pub/dd20010807092
  448_er_28707255 (in Norwegian)

16
Threats to Human Life

• Very famous (infamous) case
• In 1986, two cancer patients at the East Texas
  Cancer Center in Tyler received fatal radiation
  overdoses from the Therac-25, a
  computer-controlled radiation-therapy machine.
  There were several errors, among them the failure
  of the programmer to detect a race condition
  (i.e., miscoordination between concurrent tasks).
  
• http//www.byte.com/art/9512/sec6/art1.htm
• Many many more - See http//catless.ncl.ac.uk/Ris
  ks

17
Programming/testing Error Ariane 5

• It took the European Space Agency 10 years and 7
  billion to produce Ariane 5, a giant rocket
  capable of hurling a pair of three-ton satellites
  into orbit with each launch and intended to give
  Europe overwhelming supremacy in the commercial
  space business. All it took to explode that
  rocket less than a minute into its maiden voyage
  scattering fiery rubble across the mangrove
  swamps of French Guiana, was a small computer
  program trying to stuff a 64-bit number into a
  16-bit space.At 39 seconds after launch, as the
  rocket reached an altitude of two and a half
  miles, a self-destruct mechanism finished off
  Ariane 5, along with its payload of four
  expensive and uninsured scientific satellites.
   This disintegration had begun an instant before,
  when the spacecraft swerved off course under the
  pressure of the three powerful nozzles in its
  boosters and main engine. The rocket was making
  an abrupt course correction that was not needed,
  compensating for a wrong turn that had not taken
  place.

18
Ariane 5 (continued)

• Steering was controlled by the on-board computer,
  which mistakenly thought the rocket needed a
  course change because of the numbers, which in
  fact were an error message, coming from the
  inertial guidance system. The guidance system had
  in fact shut down 36.7 seconds after launch, when
  the guidance system's own computer tried to
  convert one piece of data -- the sideways
  velocity of the rocket -- from a 64-bit format to
  a 16-bit format overflow error.
• When the guidance system shut down, it passed
  control to an identical, redundant unit, which
  was there to provide backup in case of just such
  a failure. Guess what - the second unit (having
  the same software) failed too.
• In an earlier design decision, the programmers
  had decided that this particular velocity figure
  would never be large enough to cause trouble.
  After all, it never had been before. BUT Ariane 5
  was a faster rocket than Ariane 4.
• One extra absurdity the calculation containing
  the bug actually served no purpose once the
  rocket was in the air. Its only function was to
  align the system before launch. So it should have
  been turned off.

19
Why does software fail (Charette 1989)

• Terminated for convenience/ non-performance of
  contract.
• Completed but the system is not deployed as users
  cannot or will not use it.
• Completed but the system does not meet the
  originally promised cost.
• Completed but the system does not meet the
  originally promised schedule.
• Completed but the system does not meet the
  originally promised quality.
• Completed but the system does not meet the
  originally promised capability.
• Completed but the system could not be evolved in
  a cost-effective manner

20
What makes software special?

• The main differences in software engineering
  compared to other engineering disciplines are
  listed BSI, 1995.
• It is difficult for a customer to specify
  requirements completely.
• It is difficult for the supplier to understand
  fully the customer needs.
• In defining and understanding requirements,
  especially changing requirements, large
  quantities of information need to be communicated
  and assimilated continuously.
• Software is seemingly easy to change.
• Software is primarily intangible much of the
  process of creating software is also intangible,
  involving experience, thought and imagination.
• It is difficult to test software exhaustively

21
A Solution - Software Engineering

• Greater emphasis on systematic development.
• A concentration on finding out the users
  requirements
• Formal/Semi Formal specification of the
  requirements of a system
• Demonstration of early version of a system
  (prototyping)
• Greater emphases on trying to ensure error free
  code
• Computer assistance for software development
  (CASE)
• Software Engineering is
• A modelling activity
• A problem solving activity
• Knowledge acquisition activity

22
Software Engineering Activities

• Modelling
• Abstraction
• To gain understanding
• Predict performance, trade-offs etc

• Problem Solving
• Formulate the problem
• Analyse the problem
• Search for solutions
• Decide on appropriate solution
• Specify the solution

Software Engineering

• Knowledge Acquisition
• Non-linear activity
• Knowledge can be new or can reinforce or refute
• New knowledge changes things

23
Software Engineering Concepts
24
Software Engineering

• Definition
• Software engineering is concerned with the
  theories
• methods and tools for developing, managing and
  evolving
• software products
• By I. Sommerville

25
Discussions

• Define Engineering. Use this to come up with an
  alternative definition of Software Engineering
• Why is Software Engineering Difficult?
• Why do you think modelling helps?
• What skills make a good software engineer?
• Give some practices that would have prevented the
  Ariane 5 disaster
• Give some examples of abstraction. How does
  abstraction help in Software Engineering?
• Why not just write the code without requirements
  gathering, design, testing etc?
• What things could we quantify in Software
  Engineering?

26
Discussions

• Define Engineering. Use this to come up with an
  alternative definition of Software Engineering
• Why is Software Engineering Difficult?
• Why do you think modelling helps?
• What skills make a good software engineer?
• Give some practices that would have prevented the
  Ariane 5 disaster
• Give some examples of abstraction. How does
  abstraction help in Software Engineering?
• Why not just write the code without requirements
  gathering, design, testing etc?
• What things could we quantify in Software
  Engineering?