ICS 52: Introduction to Software Engineering

1
ICS 52 Introduction to Software Engineering

• Lecture Notes for Summer Quarter, 2003
• Michele Rousseau
• Set 2
• Partially based on lecture notes written by
  Richard N. Taylor, André van der Hoek, Dan Frost,
  Doris Tonne Sommerville. Duplication of course
  material for any commercial purpose without the
  written permission of the lecturers is prohibited.

2
The goal of Software Engineering

• Overcoming the Software Crises often late,
  over budget and not what the customer wanted
  (Brooks)
• High quality software -- what does that mean???
• There are many qualities -
• Which to choose?

3
Software Qualities

• Correctness - behaves according to specifications
• Reliability Statistical property
• i.e. Mean time between failures
• Robustness - behaves reasonably in
  unanticipated circumstances.
• Performance - uses resources economically
  (efficient)
• Usability easy to use
• Keep in mind the intended audience

4
More Qualities

• Maintainability - conducive to corrective,
  adaptive, and perfective maintenance
• Corrective removal of bugs
• Adaptive adjust to changing enviornment
• Perfective change to improve qualities
• Repairability - conducive to correction of
  defects (which area of maintainability does this
  address?)
• Evolvability easy to add functionality or
  modify existing functions (which area of
  maintainability does this address?)

5
and More qualities

• Reusability how easily can you use it for
  another application (minor modifications allowed)
• Portability how easily can it run on different
  environments
• Safety deals with the absence of unsafe
  conditions
• Verifiability satisfaction of desired
  properties can easily be determined

6
Why Not Implement Them All?

• So many qualities so little time?
• How do you choose?

7
The essence of software engineering

• Or, What makes software engineering difficult?

8
Visibility vs
9
Invisibility

• Software as is cannot be viewed meaningfully
• Stack of paper
• Set of files
• Software cannot be interpreted easily
• How to read source code?
• How to read a million lines of source code?
• How to read a part of source code?
• Invisibility affects process
• How to measure progress?
• Is a bigger stack of paper closer to the
  end-result than a smaller stack of paper?

10
Manageable Complexity vs
11
Unmanageable Complexity

• Software cannot be easily abstracted
• Formulas
• Only in very few domains
• Diagrams, graphs, and other representations
• Typically non-hierarchical
• Far too many cross-references
• Tension between high-level understanding and
  low-level detailed specification
• High-level understanding leaves out important
  details
• Aggregation often does not work

12
Environment Can Be Changed vs
13
Environment Cannot Be Changed

• Software has to adhere to the world it is
  placed in
• Cannot change the hardware
• Cannot change the way people do business
• The world is often not clearly specified
• How can you change something that you cannot
  specify?
• Leads to many software changes
• Perception is that software is easier to change
  (malleability)

14
No Major Changes vs
15
Major Changes

• Software is remarkably easy to change
• Change the source code, recompile, rerun
• One line here, one line there
• Unfortunately, even small changes can have
  disastrous consequences
• A single wrong character can surreptitiously
  change the behavior of the software
• The effects of most changes are only visible in
  certain circumstances
• Sometimes, the environment does change
• Software is used in different organizations
• Software is used for different purposes

16
Drastic Consequences

• Deceased patients
• X-ray machine delivered very high doses because
  of a timing problem in its control software
• Crashed planes
• Software prevented pilots from performing
  emergency maneuvers
• Decreased national security
• NSA computers down for four days due to a
  software problem

Peter Neumanns Risks Forum http//catless.ncl.ac
.uk/Risks
17
High Cost
Analysis
2
Specification
5
Design 6
Maintenance
67
Module Coding
5
Module Testing
7
Integration
8
Schach
18
Cost of Change Progressively Higher
Schach
19
Processes as a Remedy

• Institute processes through which software is
  engineered
• Cover all steps from initial idea and
  requirements to delivery, maintenance, and final
  retirement
• Make sure we do the right things/things right
• Make sure we do not forget to do anything
• Different processes for different kinds of
  software
• Not a silver bullet Brooks No Silver Bullet
• Software is still intrinsically difficult to deal
  with
• Processes help, but cannot guarantee anything

Remember People Processes Tools ? Product
20
Software Process

• A set of activities and associated results which
  lead to the production of a software product.
• Four fundamental activities
• Software specification
• Design and implementation
• Validation (Testing)
• Evolution (Maintenance)
• Think about differences for generic
  (shrink-wrapped) and bespoke (custom-made).

21
Product and Process

• Products can be sold, bring in revenue
• Process retained by company
• Company culture
• Determines key properties of your products
• A key factor in the cost / reliability /
  up-to-dateness of the product
• E.g. Just-in-time, Quality is job 1
• Which is the more important product or process?

22
Process and Product

• Which is possible?
• Good process --gt good product
• Good process --gt bad product
• Bad process --gt good product
• Bad process --gt bad product
• In studying Software Engineering, we focus on
  both process and product

23
Software Life Cycle Models

• Build-and-fix
• Waterfall
• Rapid prototyping
• Incremental
• Synchronize-and-stabilize
• Spiral

A software life cycle model is a high-level
process
24
What is a Software Lifecycle Model?

• A software life cycle model is either a
  descriptive or prescriptive characterization of
  how software is or should be developed.
  scacchi
• abstract representation of a processsommerville
  

25
Build-and-Fix
Build first version
Modify until client is satisfied
Development
Maintenance
26
Stage-wise Development Benington, late 1950s

• operation plan
• machine and operational specifications
• program specifications
• coding specifications
• coding
• testing specifications
• system evaluation

27
Waterfall Royce , 1970s
Requirements phase
Changed requirements
Verify
Verify
Specification phase
Verify
Design phase
Verify
Implementation phase
Test
Integration phase
Development
Test
Maintenance
Operations mode
Retirement
28
Rapid Prototyping
Build and discardsimple prototype
Integration phase
Development
Maintenance
Test
29
Spiral Boehm
Risk analysis
Risk analysis
Risk analysis
Risk analysis
Rapid prototype
Verify
Verify
Specification
Verify
Design
Verify
Implementation
Full spiral model is discussed in Sommerville
30
Boehms Top Ten Software Risks

1. Personnel shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong software functions
4. Developing the wrong user interface
5. Gold plating

1. Continuing stream of requirements changes
2. Shortfalls in externally furnished components
3. Shortfalls in externally performed tasks
4. Real-time performance shortfalls
5. Straining computer-science capabilities

31
Incremental Mills
Architectural design
Verify
FOR EACH BUILD Perform detailed design,
implementation, and integration. Test. Deliver
to client.
Development
Maintenance
32
Synchronize-and-Stabilize(AKA Daily build and
smoke test)
Specifications
Implementation, Integration
Deliver to client (version 1)
Design
Specifications
Design
Implementation, Integration
Deliver to client (version 2)
Specifications
Design
Implementation, Integration
Deliver to client (version 3)
Specifications
Design
Implementation, Integration
Deliver to client (version n)
Specification team
Design team
Implementation/integration team
33
A Comparison of Approaches
Model Strengths Weaknesses
Build-and-Fix (not a model) Fine for small programs that do not require much maintenance Totally unsatisfactorily for nontrivial programs lacks in forethought Leads to bad Design
Waterfall Disciplined approach Document driven Delivered product may not meet clients needs Does not scale down its difficult to go back up
Rapid Prototyping Ensures that delivered product meets clients needs A need to build twice Cannot always be used
Spiral Incorporates features of all the above models Adds risk assessment Can be used only for large-scale products Developers have to be competent at risk-analysis
Incremental Maximizes early return on investment Lower risk of project failure Requires open architecture May degenerate into build-and-fix
Synchronize- and-stabilize Future users needs are met Ensures components can be successfully integrated Has not been widely used other than in Microsoft
34
SEI's Capability Maturity Model
Optimizing (5) Process change management Technolog
y change management Defect prevention
Continuously improving process
Managed (4) Software quality management Quantitati
ve process management
Predictable process
Defined (3) Peer reviews Intergroup
coordination Software product engineering Integrat
ed software management Training
program Organization process definition Organizati
on process focus
Standard, consistent process
Repeatable (2) Software configuration
management Software quality assurance Software
subcontract management Software project tracking
and oversight Software project planning Requiremen
ts management
Disciplined Process
Initial(1)
35
ICS 52 Software Life Cycle

• Requirements specification
• Interview customer (TA)
• Focus on what, not how
• Architectural and module design
• Based on provided official requirements
  specification
• Focus on interfaces
• Implementation
• Based on provided official design
• Focus on good implementation techniques
• Testing
• Based on provided official implementation
• Focus on fault coverage and discovery

36
Your Tasks

• Read and study slides of this lecture
• Read and study Chapters 4.4, 8 and 5 of
  Sommerville
• Make sure to study the details of the complete
  spiral model
• Visit Peter Neumanns Risks Forum
• Spend two hours (or more) reading the articles