Download ppt - UCT

Software Engineering
Introduction (The Product)
James Gain
([email protected])
http://people.cs.uct.ac.za/~jgain
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
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
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) don’t always apply
 Consequences:
 One person cannot understand a project in its entirety
 Makes management difficult
 Complicates maintenance
Explosion of Execution Paths
Two nested loops
containing four
if..then..else
statements. Each
loop can execute up
to 20 times
There are 10^14 possible paths in this 15 line program!
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
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
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
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
1. People can be bankrupted and even die (with safety
critical systems) if your software fails
2. You must almost always work within a team (Johnny
must play well with others)
3. Poor performance means losing your job (not just a
poor mark)
4. Your program will have to live longer
5. The cost, complexity and time span of software
projects are much larger
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
Lifetime of Software
The Software Crisis
 Often software is delivered late, over budget and with
residual faults. Less a crisis, more a chronic affliction
 Worse, this isn’t really changing
 software productivity has improved 6% per year (on average over
30 years)
 Unlike Hardware
 Moore’s law: processor speed/memory capacity doubles every two
years
Hardware
“Productivity”
Software
Time (10 years)
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?
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
Timeliness
 Because of software complexity, it is very difficult
to schedule
 Also programmers are notorious for underestimating coding time
 Generally fail to consider the time needed for testing
and debugging
 Rule of thumb: double programmer’s time estimates
(without telling them)
 Software engineering is concerned with developing
software in a timely manner.
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 costeffective software development
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 (don’t waste system resources)
 Usable (must be easily mastered by the target users)
 Software engineering is concerned with producing
quality software
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
 Brooke’s Law: Adding people to a late software project makes it
later (from “The Mythical Man-Month”)
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)
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 can’t walk away without careful documentation
 Because 60-80% of effort occurs after software is first
delivered
Relative Cost of Software Phases