Software Engineering

1
Software Engineering

• Introduction (The Product)
• James Gain
• (jgain_at_cs.uct.ac.za)
• http//people.cs.uct.ac.za/jgain

2
Objectives

• Of the course
• To cover the process, methods and tools of
  Software Engineering
• Emphasise the unfortunate necessity of SE
  practices
• Prepare you for the CS2 project
• Of this lecture
• Explain the nature of the beast
• Face the software crisis
• Consider the three tug-of-war aspects of software
  development
• Debunk some widely held myths about software

3
The Nature of Software

• Software is a set of items that form a
  configuration, including
• Programs
• Documents
• Data
• Software products may be developed for a
  particular customer (bespoke) or for a general
  market (generic)
• Most software is still custom-made rather than
  being assembled from existing components
• The programmer, like the poet, works only
  slightly removed from pure thought-stuff - Fred
  Brooks in The Mythical Man-Month

4
Complexity

• Software is inherently complex because
• Number of execution paths grow exponentially with
  size
• Interdependence of scattered parts
• Can be reduced but not eliminated
• Simplifying techniques of Maths and Physics
  (where complexity noise) dont always apply
• Consequences
• One person cannot understand a project in its
  entirety
• Makes management difficult
• Complicates maintenance

5
Explosion of Execution Paths
Two nested loops containing four if..then..else
statements. Each loop can execute up to 20 times
There are 1014 possible paths in this 15 line
program!
6
Conformity

• Cases of Conformity
• Must often conform to existing systems
• Even when building from scratch software is
  regarded as a second class citizen (most
  conformable component)
• Inherent
• Cannot be removed by redesign because it depends
  on the interface to humans and hardware
• Consequences
• Interfaces will invariably add complexity to an
  otherwise simple design

7
Changeability

• There will always be pressure to change software
• Software models reality, as reality changes, so
  must software
• If software is useful, users will want it
  extended
• Software is easier to change than hardware
• Successful software survives beyond the lifetime
  of the hardware for which it was originally
  written
• Consequences
• Constant change degrades quality
• Becomes progressively more expensive with
  lateness in the lifecycle

8
Invisibility

• Software (unlike architecture, circuits,
  molecules) cannot be effectively visualized
• Yes there are graphing techniques (UML), but
• Generally non-planar (crossing edges)
• Generally not hierarchical
• Cannot embody every aspect in a single visual
• Cannot easily identify oversights
• Consequences
• Software designs are difficult to understand and
  communicate

9
Exercise Beyond the Ivory Tower

• University is not the Real World
• CS pracs are not like real software projects
• Give 5 or more important ways in which they
  differ

• The Real World TM
• People can be bankrupted and even die (with
  safety critical systems) if your software fails
• You must almost always work within a team (Johnny
  must play well with others)
• Poor performance means losing your job (not just
  a poor mark)
• Your program will have to live longer
• The cost, complexity and time span of software
  projects are much larger

10
Exercise Beyond Bridge Building

• A NATO study group coined the term Software
  Engineering in 1967
• They believed that software would benefit from
  the philosophies and techniques of traditional
  engineering
• But building software is not like building
  bridges
• Give 4 (or more) important ways in which they
  differ

1. When bridges break they are redesigned and
   rebuilt from scratch (imagine doing that every
   time your Operating System crashed)
2. Bridges are analog, software is digital
3. Software does not wear out
4. Most of the cost of software is in design not
   manufacture

11
Lifetime of Software
12
The Software Crisis

• Often software is delivered late, over budget and
  with residual faults. Less a crisis, more a
  chronic affliction
• Worse, this isnt really changing
• software productivity has improved 6 per year
  (on average over 30 years)
• Unlike Hardware
• Moores law processor speed/memory capacity
  doubles every two years

Hardware
Productivity
Software
Time (10 years)
13
No Silver Bullet

• Software development is like a Werewolf (mostly
  calm but just wait for the full moon)
• We need a silver bullet to provide a one
  shot solution
• Fred Brooks in his essay No Silver Bullet
  postulates that
• Despite the promise of high-level languages,
  object orientation, integrated development
  environments and Artificial Intelligence
• There will never be a single order of magnitude
  breakthrough in productivity improvement
• Because of the intrinsic nature of software
• Question for the day Is reusability (and open
  source) the new silver bullet?

14
The Three-legged Stool

• There are three axes of software development
• Schedule (how long will it take to develop)
• Cost (how expensive is it to develop)
• Quality (indefinable excellence of the final
  product)
• Software Management is largely devoted to
  predicting, controlling and measuring these axes
• Interrelated
• A change in one axis affects the others
• E.g. Software that overruns on time usually
  overruns on budget (you had to pay more salaries)
• You can have it fast, cheap or good. Pick any two

15
Timeliness

• Because of software complexity, it is very
  difficult to schedule
• Also programmers are notorious for
  under-estimating coding time
• Generally fail to consider the time needed for
  testing and debugging
• Rule of thumb double programmers time estimates
  (without telling them)
• Software engineering is concerned with developing
  software in a timely manner.

16
Cost

• Software costs often dominate system costs
• For instance, software for a PC usually costs
  more than the hardware
• Software costs more to maintain than it does to
  develop
• Especially for systems with a long life, where
  maintenance may be many times more expensive than
  development
• Software engineering is concerned with
  cost-effective software development

17
Quality

• Need to deliver the functionality required by the
  user
• But also be
• Maintainable (can evolve to meet changing needs)
• Dependable (error free and reliable)
• Efficient (dont waste system resources)
• Usable (must be easily mastered by the target
  users)
• Software engineering is concerned with producing
  quality software

18
The Man-Month Myth

• Managers are under pressure, tend to grasp at
  myths
• Man-Month Myth
• Mongolian Horde approach works
• If a project is running late, add people to
  finish on time
• Implies that people and time are interchangeable
• Reality
• Mongolian horde assumes that tasks can be
  perfectly partitioned with no sequential
  constraints, intercommunication or training
• Cost depends on the number of people and number
  of months. Progress does not
• Brookes Law Adding people to a late software
  project makes it later (from The Mythical
  Man-Month)

19
The Chameleon Myth

• Myths held by customers often lead to false
  expectations and, ultimately, dissatisfaction
• Chameleon Myth
• Changing requirements can be easily accommodated
  at any time because software is flexible
• Reality
• Impact depends on the lateness of the change
• Changes are far easier during analysis (1x cost)
  than maintenance (60-100x cost)

20
The Maintenance Myth

• Early attitudes to programming have become
  entrenched
• Maintenance Myth
• Once the program is written and it works our job
  is done
• Reality
• You cant walk away without careful documentation
• Because 60-80 of effort occurs after software is
  first delivered

21
Relative Cost of Software Phases