Acknowledgments
Software Engineering
CSE470
(Spring 2002)
Instructor:
Dr. W. McUmber
[email protected]
3100 EB
G. Coombs
L. Dillon
M. Heimdahl
R. Stephenson
National Science Foundation:
01-intro
Tony Torre, Detroit Diesel Corp.
01-intro
What is Software Engineering
???
Improve quality
Reduce costs
01-intro
Why is software engineering
needed?
The study of systematic and effective processes
and technologies for supporting software
development and maintenance activities
VESL (Visions of Embedded Systems Laboratory)
CDA-9700732
To predict time, effort, and cost
To improve software quality
To improve maintainability
To meet increasing demands
To lower software costs
To successfully build large, complex software systems
To facilitate group effort in developing software
01-intro
Who Needs Software
Engineering?
Historical Perspective
Show me a business in the U.S.
that doesnt use Software
1940s: computers invented
1950s: assembly language, Fortran
1960s: COBOL, ALGOL, PL/1, operating systems
1969: First conference on Software Eng
So..
1970s: multi-user systems, databases, structured
programming
Everyone!
01-intro
01-intro
Hardware Costs vs Software Costs
(% of overall costs)
Historical Perspective (cont.)
*
s/w costs
1980s: networking, personal computing, embedded
h/w costs
systems, parallel architectures
1990s: information superhighway, distributed
systems, OO in widespread use.
2000s: virtual reality, voice recognition, video
conferencing, global computing, ...
Time
01-intro
01-intro
Why is software so expensive?
Hardware has made great advances
But, software has made great advances ...
We do the least understood tasks in software
Size of programs continues to grow
Trivial: 1 month, 1 programmer, 500 LOC,
Very small: 4 months, 1 programmer, 2000 LOC
Small: 2 years, 3 programmers, 50K LOC
Medium: 3 years, 10s of programmers, 100K LOC
When task is simple & understood, encode it in
hardware
Demand more and more of software
01-intro
Intro programming assignments
Course project
Nuclear power plant, pace maker
Optimizing compiler
01-intro
10
Whats the problem?
Size of programs continues to grow
*
Large: 5 years, 100s of programmers, 1M LOC
MS Word, Excel
Very large: 10 years, 1000s of programmers, 10M LOC
Air traffic control,
Telecommunications, space shuttle
Software cannot be built fast enough to keep up with
H/W advances
Rising expectations
Feature explosion
Increasing need for high reliability software
Unbelievable: ? years, ? programmers
W2K 35M LOC
Missile Defense System 100M LOC?
01-intro
11
01-intro
12
Whats the problem?
Goals of this Course
Software is difficult to maintain
Expose you to some of the problems typically
encountered in software eng
aging software
Difficult to estimate software costs and schedules
Too many projects fail
Expose you to some of the techniques that have been
found to be effective
Ariane Missile
Denver Airport Baggage System
Therac
Requiring more rigor
Often appearing obvious
(but only after being learned)
13
01-intro
01-intro
Overview of Course
Structure of Course
Emphasis on analysis and design
Learn/apply new techniques for software
development
Learn to work with a group
Improve technical writing skills
Become up to date on current trends in SE
Explore presentation media and techniques
15
01-intro
14
(Short) assignments over readings
In lab assignments (various SE tools)
Homework
Quizzes
Group projects (prototype, analysis, design)
One hour exam
Presentations: oral presentations, prototype
demos
01-intro
16
Software Engineering Phases
Software Engineering
A Brief Introduction
01-intro
17
Definition: What?
Development: How?
Maintenance: Managing change
Umbrella Activities: Throughout lifecycle
01-intro
18
The Standard Development
Cycle
Definition
Definition
Requirements definition and analysis
Coding
Requirements
Developer must understand
Application domain
Required functionality
Required performance
User interface
Testing
Design
19
01-intro
01-intro
Definition (cont.)
Development
Project planning
System analysis
Allocate resources
Estimate costs
Define work tasks
Define schedule
Allocate system
resources to
Hardware
Software
Users
Software design
User interface design
High-level design
Define modular components
Define major data structures
Detailed design
21
01-intro
Coding
Combine modules
module
System testing
Correction - Fix software defects
Adaptation - Accommodate changes
Unit testing
01-intro
22
Maintenance
Integration
Develop code for each
Define algorithms and procedural detail
01-intro
Development (cont.)
20
23
New hardware
New company policies
Enhancement - Add functionality
Prevention - make more maintainable
01-intro
24
Umbrella Activities
Software Engineering Costs
*
Reviews - assure quality
Documentation - improve maintainability
Version control - track changes
Configuration management - integrity of collection
Maintenance
Development
Defintiion
of components
25
01-intro
Whats a Methodology or
Process Model
Relative Costs to Fix Errors
This is why software
process pays off
80
70
60
50
40
30
20
10
0
Cost
Delivery
Testing
Code
Requirements
Design
27
01-intro
26
01-intro
Waterfall Process Model
Set of activities, notations, tools, in defined
sequence.
Goal: Order, predicitability, quality, cost control
Follows requirements=>design=>coding, etc.
sequence (usually)
Usually defines phases or steps
Often has notations
Sometimes has tools
28
01-intro
Prototyping Process Model
Requirements
Requirements
Design
Quick Design
Prototype
Coding
Evaluate
Testing
Design
Maintenance
01-intro
29
01-intro
30
When to use prototyping?
Spiral Process Model
* Help the customer pin down the requirements
Concrete model to test out
Often done via the user interface
Planning
Explore alternative solutions to a troublesome component
Improve morale
e.g., determine if an approach gives acceptable performance
Partially running system provides visibility into a project
Customer
Evaluation
NEVER Press a prototype into production
31
01-intro
Idealized views of the process
Different models are often used for different
subprocesses
Level 1: Initial
prototyping for a particularly complex component
waterfall model for other components
Level 4: Managed
Level 5: Optimizing
success depends on people
Level 2: Repeatable
may use spiral model for overall development
32
Capability Maturity Model
Engineering
01-intro
Process Models
*
Risk Analysis
track cost, schedule,
functionality
Level 3: Defined
collect detailed metrics
continuous process
improvement
built-in process improvement
use standardized processes
See Evolution of the Frameworks Quagmire,
Computer, July 2001, p.96
33
01-intro
Why is software development so difficult?
Communication
Between customer and
developer
Poor problem definition is
largest cause of failed software
projects
Within development team
Project characteristics
More people = more
communication
New programmers need
training
01-intro
Why is software development difficult?
Novelty
Changing requirements
Personnel characteristics
5 x cost during development
up to 100 x cost during
maintenance
Hardware/software
configuration
Security requirements
Real time requirements
Reliability requirements
34
01-intro
Ability
Prior experience
Communication skills
Team cooperation
Training
Management issues
Facilities and resources
35
Identification
Acquisition
01-intro
(cont.)
Realistic goals
Cost estimation
Scheduling
Resource allocation
Quality assurance
Version control
Contracts
36
Summary
Software lifecycle consist of
Definition (what)
Development (how)
Maintenance (change)
U.S. software is a major part of our societal
infrastructure
Costs upwards of $200 billion/year
Different process models concentrate on different aspects
Bottom Line
Waterfall model: maintainability
Prototype model: clarifying requirements
Spiral model: identifying risk
Need to
Improve software quality
Reduce software costs/risks
Maintenance costs much more than development
37
01-intro
01-intro
38
Computer System Engineering
Systems Engineering
Computer System Engineering is a problem-solving activity.
Itemize desired system functions
Analyze them
Allocate functions to individual system elements
Systems Analyst (computer systems engineer)
Start with customer-defined goals and constraints
Derive a representation of function, performance, interfaces, design
constraints, and information structure
That can be allocated to each of the generic system elements (i.e.,
Software, Hardware, People, database, documentation, procedures)
01-intro
39
Computer System Engineering
*
Derive
representation
that can
be allocated
Customer
goals;
constraints
Allocate
functions to
system elements
Problem solving
01-intro
Focus on WHAT, NOT how.
01-intro
40
Criteria for System Configuration:
Technical
Criteria for allocation of function and performance to generic system
elements:
Technical Analysis: (existence of necessary technology, function and
performance assured, maintainability)
Environmental Interfaces: (proposed configuration integrate with
external environment, interoperability)
Off-the-shelf options must be considered.
Manufacturing evaluation: (facilities and equipment available, quality
assured?)
Itemize
Functions
Analyze
Functions
41
01-intro
42
Hardware and
Hardware Engineering
Criteria for System Configuration:
Business Issues
*
Criteria for allocation of function and performance to generic system
elements:
Project_Considerations: (cost, schedules, and risks)
Business_Considerations: (marketability, profitability)
Legal_Considerations: (liability, proprietary issues, infringement?)
Human issues: (personnel trained? political problems, customer
understanding of problem)
test
results
Well defined
01-intro
43
Hardware and
Hardware Engineering
Components are packaged as individual building blocks
Standardized interfaces among components
Large number of off-the-shelf components
Performance, cost, and availability easily determined/measured
Hardware Engineering
Characteristics:
44
01-intro
Phases to system engineering of hardware:
Development Planning and requirements analysis:
Hardware configuration built from a hierarchy of "building
blocks."
best classes of hardware for problem,
availability of hardware
type of interface required
identification of what needs to be designed and built
Establish a Plan or "road map" for design implementation
May involve a hardware specification.
Use CAE/CAD to develop a prototype (breadboard)
Develop printed circuit (PC) boards
Manufacturing of boards
skip
01-intro
45
Software and
Software Engineering
Three high-level phases of
Software Engineering
Function may be the implementation of a sequential procedure for
data manipulation
Performance may not be explicitly defined (exception in real-time
systems)
Software element of computer-based system consists of two classes
of programs, data, and documentation
Application_Software:
Definition phase:
Software planning step
implements the procedure that is required to accommodate information
processing functions
implements control functions that enable application software to interface with
other system elements
01-intro
47
Software Project Plan
scope of project,
risk,
resource identification
cost and schedule estimates
Software Requirements Analysis
System Software:
46
01-intro
Requirements Specification
System element allocated to software is defined in detail.
Formal information domain analysis to establish models of information flow and
structure (expand to produce specification)
Prototype of software is built and evaluated by customer
Performance requirements or resource limits defined in terms of software
characteristics
Definition and Requirements must be performed in cooperation
01-intro
48
Third Phase of Software
Engineering
Development Phase:
Modularity Criteria:
Translate set of requirements into an operational system element
Structured Design: Design
Issues
Design
Design Specification
Coding (appropriate programming language or CASE tool)
Should be able to directly trace detail design descriptions from code.
Verification, release, and maintenance phase:
Testing software:
Testing Plan
to find maximum number of errors before shipping
Prepare software for release
Quality Assurance
Maintain software throughout its lifetime
49
01-intro
Uses Relation
*
Basic Design Principle:
M1
Linguistic modular units: correspond to syntactic units in
implementation language
Few interfaces: minimize the number of interfaces between
modules
Small interfaces (weak coupling): minimize amount of info moving
across interfaces
Explicit interfaces: when modules do interact, should be in
obvious way
Information hiding: all info about module is hidden from outside
access
50
01-intro
Design Issues
Decomposability: decompose large problem into easier to solve
subproblems
Composability: how well modules can be reused to create other
systems
Understandability: how easily understood without other reference info
Continuity: make small changes and have them reflected in
corresponding changes in one or a few modules
Protection: architectural characteristic to reduce propagation of side
effects of a given error in a module.
M3
M2
M5
M6
M4
M7
M8
Mx
51
01-intro
01-intro
Design Heuristics
*
Design Heuristics (contd)
Evaluate "First-cut" program structure
Reduce coupling:
Improve cohesion
Use exploding: common process exists in 2 or more modules
Use imploding: if high coupling exists, implode to reduce control transfer,
reference to global data, and interface complexity
Minimize Structures with high fan-out ; Strive for Fan-in as depth increases
Keep scope effect of a module within scope of control of that module effect of
module should be in deeper nesting
Evaluate module interfaces:
Reduce complexity
Reduce redundancy
Improve consistency
01-intro
52
Define predictable functions for modules, but not too restrictive:
"Single-entry-single-exit" modules: Avoid "Pathological Connections"
53
Enter at top, exit at bottom
Pathological connection: entry into middle of module
Package SW based on design constraints and portability requirements
OOD is going to help us
with these issues
Black box modules are predictable (like hardware)
Restricting module processing to single subfunction (high cohesion)
Pass only a few (like 3, max) and return one parm from module
High maintenance: if randomly restrict local data structure size, options within control
flow, or types of external interface
Assemble SW for specific processing environment
Program may "overlay" itself in memory reorganize group modules according to degree
of repetition, access frequency, and interval of calls
Separate out modules only used once.
01-intro
54
Design Postprocessing
Design Postprocessing
*
After Transaction or transform analysis: complete documentation to
be included as part of architectural design
Processing narrative for each module
Interface description for each module
Definition of local and global data structures
Description of all design restrictions
Perform review of preliminary design
"optimization" (as required or necessary)
Documentation is
critical
Data structures
description
Module Foo
;kskf;ldskfs;dfsdf
sdfjs;fjsldfksfd
skdjflsdjfsfjsdf
j3098wodfjsldfjs
sdfjslkdfjsldkfjsldkfjsdf
sdjflsdfjslkdfjslkdfj
sdjfsldfjsldkfjsldf
sjdflksjdfljkwruswdfusdf
sdhjsldfhsdfsldfjs
\98sf7sd89vhjsdvsdaofusd0f
sdhjsdfhskdjfhskdf
sdjfslhfkwfhiahjalsfjd
sdhfskdfhskdfjsfdk
sdhfksdjfhksdjfhskdf
shdfksdhfksdjfksdf
sdfkjhfjsdhfksdfhskdf
Interface
description
Pre-conditions
Design restrictions
Post-conditions
01-intro
55
01-intro
Narrative
Perform Review
56
Design Optimization
Objectives:
Smallest number of modules (within effective modularity criteria)
Least complex data structure for given purpose
Refinement of program structure during early design
stages is best
Time-critical applications may require further refinements
for optimizations in later stages (detailed design and
coding)
01-intro
57
10
