SOFTWARE

SOFTWARE ENGINEERING
ENGINEERING

INTRODUCTION
INTRODUCTION AND
AND OVERVIEW
OVERVIEW
INTRODUCTION &
OVERVIEW OUTLINE
• Trends
• software demand
• importance of software
• software effort (cost)
• software maintenance

• Problems
• software “construction”
• software development

• Solutions
• modular development
• personal development
• quality development

• What is Software Engineering?

2
 TRENDS — SOFTWARE
DEMAND
Software Demand

Personal computing,
information,
education

Commercial

Scientific & Technical

1950 1960 1970 1980 1990 2000

• several hundred billion dollars/year spent worldwide and growing
• essential part of almost all organizations
• key part of many products  embedded systems
• essential for designing many products

3
 TRENDS — IMPORTANCE OF
SOFTWARE

• shift of focus: from hardware to software Engineering

software is becoming ubiquitous

Sales Inventory
 challenges:
– improve quality
– reduce cost
– meet (user) requirements Manufacturing Accounting

4
TRENDS — SOFTWARE
EFFORT (COST)
8000
Man-months

6000

4000

2000

100 200 300 400 500 600

1000’s of language statements
• sample code sizes:
• hand-held bar code scanner: 10-50KLOC [Symbol Technologies
Inc.]
• cellular telephone: 30KLOC [Motorola]
• automated teller network: 600KLOC [IBM]
• B-2 Stealth bomber: 3.5MLOC [Leonard Lee]
• telephone switch; Windows 95: 15MLOC [Nokia; Ted Lewis]
5
 TRENDS — SOFTWARE
MAINTENANCE
100%
Maintenance
effort
Effort

New
development
effort ?
Time (years)

• maintenance is generally considered to include

correction, retargeting, and enhancement
• Corrective maintenance Vs Adaptive maintenance

• only “useful” software goes through maintenance

 5,000 estimated bugs in Windows 95 6

PROBLEMS — SOFTWARE
“CONSTRUCTION”
1. nature: physical versus logical
2. failure: hard versus soft
Hardware failure curve Software failure curve

Infant Wear Infant

mortality out mortality
Failure rate

Failure rate
Actual
Idealized
Time Time

3. development: manufactured versus created

7
PROBLEMS — SOFTWARE
DEVELOPMENT
1.schedule and cost estimates often grossly inaccurate
• over schedule
• over budget

2. productivity of software developers has not kept pace with demand for
their services

3. quality of software is sometimes less than adequate

– unreliable  Hong Kong Airport Project; Ariane 5 rocket,
Boeing 747 Crash in Ethiopia
– unsafe  London Ambulance System; Therac-25
– inflexible  hard to change/maintain
– abandoned  London Stock Exchange

WHY?
8
SOLUTIONS — MODULAR
DEVELOPMENT
Large software systems are complex and changing.

There is a limit to how much a human can

understand at any one time.

 divide and conquer

The coupling
System

module: any identifiable “bit” of a system which it makes

sense to consider separately
 BUT modules need to depend on each other
9
SOLUTIONS — MODULAR
DEVELOPMENT (cont’d)
coupling – a measure of the number and types of
interconnections (dependencies) a module has with other
modules
 a module has the lowest coupling when it has minimal
dependencies with other modules

interface encapsulates module knowledge so the developer is

prevented from using information inside the module

 internally changing a module without changing its

interface will not require any changes anywhere
else in the system
10
SOLUTIONS — MODULAR
DEVELOPMENT (cont’d)
cohesion – a measure of the number of functionally
different things a module has to do
 a module is most cohesive when it does only one
thing (i.e., provides an abstraction of some intuitively understood
function which may nevertheless be complex to implement)

interface  abstracts a module so the developer does not

have to understand everything about a module to use it

 developer is shielded from irrelevant information about

how the module works internally

encapsulation + abstraction = information hiding

11
SOLUTIONS — MODULAR
DEVELOPMENT (cont’d)
• modularity defined with interfaces allows for:
• more productivity in team development
• fewer bugs
• more maintainable software
• more reusable software

 and the possibility of component-based development using a

suitable software architecture

CHALLENGES
– define good modules with the right things in their interfaces
– specify suitable software architectures to support components

12
SOLUTIONS — PERSONAL
DEVELOPMENT
“programming-in-the-small” vs. “programming-in-the-large”

 may use and apply several design approaches

 need to translate vague requirements and desires into precise
specifications
 need to talk with user in terms of the application, rather than
computer jargon
 need to move among different levels of abstraction at different
stages of the project
 need to build a “model” of the application (actually several)
 need to choose among alternatives (tradeoffs)
 need to work in well-defined roles but a rigid fragmentation of
roles is often counterproductive
13
SOLUTIONS — QUALITY
DEVELOPMENT
 What does this mean?

correct user friendly evolvable understandable

reliable verifiable reusable productive
robust maintainable portable timely
efficient repairable interoperable visible

 How do we measure it?

 How do we achieve it?

14
SOLUTIONS — QUALITY
DEVELOPMENT
correct - behaves according to the specifications of its functions (functionally correct)
reliable - probability that the software will work as expected over a specified time
interval
robust - if it behaves “reasonably” in unanticipated circumstances
efficient - in use of time, space (memory, bandwidth…), etc.
user friendly - if human users find it easy to use (user interface aspect very important)
verifiable - if properties can be easily checked (e.g., correct, efficient, etc.)
maintainable - if software can be easily fixed/changed after implementation
repairable - if defects can be easily corrected with limited/reasonable effort
evolvable - if software can be easily changed over time
reusable - if we can reuse parts, perhaps with minor changes
portable - if software can run in different hardware/software environments
interoperable - if software can co-exist and cooperate with other hardware/software
systems
understandable - if it is easy to figure out what is going on/being done
productive - efficiency of the software production process
timely - ability to deliver a product on time
visible - if all steps/current status are available and easily accessible for external
examination 15
WHAT IS SOFTWARE
ENGINEERING?
“The establishment and use of sound engineering
principles in order to obtain economically
software that is reliable and works efficiently on
real machines.” — Frtiz Bauer
“... multi-person construction of multi-version
software.” — Dave Parnas

 engineering principles  disciplined effort: methodology, tools

 economically…reliable…efficiently  built-in quality: metrics
 multi-person  team effort: management, training
 multi-version  not a “one-shot” effort: documentation, maintenance

16
WHAT IS SOFTWARE
ENGINEERING?
• a modeling activity
• problem domain model  models the application domain
• solution model  models the system to be built

 a problem solving activity

– search for an appropriate solution in the presence of change
– not algorithmic, but should be systematic

 a knowledge acquisition activity

– not a linear process
– may need to start over!

 a rationale management activity

– may need to revisit decisions already made  bugs, technology, etc.
– Why did we make this choice?

17
SOFTWARE ENGINEERING —
COMPONENTS
• project management
• team organization, dynamics
• requirements based development
• systematic use of methodologies, techniques and tools
• modular approach to system building – phases
• formal testing of modules and system as a whole
• meaningful quality assurance (e.g., standards)
• excellent documentation
• store of relevant knowledge, architectures and
components
18