SE – Week 1 – 30/09/16


Course assessment

  • The exam at the end is 80%
  • The coursework is 20%
    • Assigned coursework 10%
    • 4 lab exercises at 2.5% each
      • The labs are for practical things
      • Not necessarily based on lectures
      • That’s why each lab has a video for it, to watch beforehand
  • Labs start next tuesday (oct 4, 9-11,11-1,1-3)

Visual Paradigm

Examples of famous software disasters

  • Mariner Bugs Out (1962) (source)
    • Cost: $18.5 million
    • Disaster: The Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight path shortly after launch.  Mission Control destroyed the rocket 293 seconds after liftoff.
    • Cause: A programmer incorrectly transcribed a handwritten formula into computer code, missing a single superscript bar.  Without the smoothing function indicated by the bar, the software treated normal variations of velocity as if they were serious, causing faulty corrections that sent the rocket off course.
  • Ariane Rocket Goes Boom (1996) (source)
    • Cost: $500 million
    • Disaster: Ariane 5, Europe’s newest unmanned rocket, was intentionally destroyed seconds after launch on its maiden flight.  Also destroyed was its cargo of four scientific satellites to study how the Earth’s magnetic field interacts with solar winds.
    • Cause: Shutdown occurred when the guidance computer tried to convert the sideways rocket velocity from 64-bits to a 16-bit format.  The number was too big, and an overflow error resulted.  When the guidance system shut down, control passed to an identical redundant unit, which also failed because it was running the same algorithm.

Tree house and skyscraper analogy

  • Tree house
    • Not much planning
    • No internal structure
    • Simple instructions to follow
    • Make adjustments on the fly
  • Skyscraper
    • Major planning and project management
    • Major internal structure and framework
    • Complex requirements and major design decisions
    • Adjustments must be planned
  • The point of the analogy was to show how a small scale software project, first year’s Procedural Programming mini project for example, cannot really be compared to something on a larger scale
  • Making multiple programs with 1000 lines of code or so is not equivalent to completing one larger project
  • Techniques which might work for smaller projects do not “scale up”
  • Small project
    • Simple, precise, unchanging requirements
    • Used by only a few people
    • Probably not used frequently
  • Large projects
    • Often for a client or a more significant purpose, resulting in more complex requirements which can change
    • Can be used by many people
    • May have significant use every day

Size of software

  • Visit here for a visual

Reasons for project failure

  • Lack of end-user involvement
    • Main reason for failure in most projects
  • Poor communication
    • Internal
    • External
      • Language difficulties
  • Poor configuration management
  • Inadequate testing
  • Poor management
  • Technical complexity issues

Consequences of failure

  • Poor quality
  • Reduced functionality
  • Late delivery
  • Excessive costs


  • Engineering is the application of scientific and mathematical principles to practical ends such as the design, manufacture, and operation of efficient and economical structures, machines, processes, and systems

Software engineering

  • Software engineering is the systematic application of scientific and technological knowledge, through the medium of sound engineering principles, to the production of computer programs, and to the requirements definition, functional specification, design description, program implementation, and test methods that lead up to this code

What makes software special

  • Major cost and effort is in the design, not manufacture
  • Inevitable novelty
  • Discontinuous behaviour
    • Sometimes behaves unexpectedly
  • Changes have side effects
    • e.g. a new feature makes a mobile app slow
    • people will start looking for a different one

Practitioner myths

  • Myth 1: ‘The sooner we start coding, the sooner the project will be complete’
  • Myth 2: ‘Once the program has compiled successfully, our job is done’
  • Myth 3: ‘Until we get a program running we can’t assess the quality of the project’
  • Myth 4: ‘The only deliverable for a software project is the working program’
  • Myth 5: ‘The project is 90% complete’
  • Myth 6: ‘Software is easy and cheap to change’

Course content

  • Systems concepts
  • Object oriented design
  • Software life-cycles
  • Project management and planning
  • UML for software design
  • Software Testing strategies
  • Software Quality Assurance
  • Software metrics and risk
  • Design patterns


  • Use QMPlus forums



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s