ICS 52: Introduction to Software Engineering - PowerPoint PPT Presentation

About This Presentation
Title:

ICS 52: Introduction to Software Engineering

Description:

... and not what the customer wanted' (Brooks) ... Institute processes through which software is engineered ... Not a silver bullet [Brooks 'No Silver Bullet' ... – PowerPoint PPT presentation

Number of Views:137
Avg rating:3.0/5.0
Slides: 37
Provided by: ICS95
Learn more at: https://www.ics.uci.edu
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com