COMP 211 INTRODUCTION TO SOFTWARE ENGINEERING

1
COMP 211INTRODUCTION TOSOFTWARE ENGINEERING

• INTRODUCTION AND OVERVIEW

2
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?

3
TRENDS SOFTWARE DEMAND
Personal computing, information, education
Commercial
Scientific Technical

• 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

4
TRENDS IMPORTANCE OF SOFTWARE

• shift of focus from hardware to software
• software is becoming ubiquitous

• challenges
• improve quality
• reduce cost
• meet (user) requirements
• software development is no longer a seat of
  the pants art

WHY?
5
TRENDS SOFTWARE EFFORT (COST)

• 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

6
TRENDS SOFTWARE MAINTENANCE
100
Maintenance effort
New development effort
Effort
?
Time (years)

• maintenance is generally considered to include
  correction, retargeting, and enhancement
• only useful software goes through maintenance

• 5,000 estimated bugs in Windows 95

7
PROBLEMS SOFTWARE CONSTRUCTION 1.1

• 1. nature physical versus logical

2. failure hard versus soft
3. development manufactured versus created
8
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
• unsafe London Ambulance System Therac-25
• inflexible hard to change/maintain
• abandoned London Stock Exchange

WHY?
9
PROBLEMS SOFTWARE DEVELOPMENT

• Ariane 5 whose maiden flight on June 4, 1996
  ended in the launcher being exploded because of a
  chain of software failures
• London Ambulance System where because of a
  succession of software engineering failures,
  especially defects in project management, a
  system was introduced that failed twice in the
  autumn of 1992. Although the monetary cost, at
  only about 9m, was small by comparison with
  other examples, it is believed that people died
  who would not have died if ambulances had reached
  them as promptly as they would have done without
  this software failure.
• Therac-25 where between 1985 and 1987 six people
  (at least) suffered serious radiation overdoses
  because of software-related malfunctions of the
  Therac-25 radiation therapy machine. Three of
  them are thought to have died of the overdoses.
  An important root cause was a lack of quality
  assurance, which led to an over-complex,
  inadequately tested, under-documented system
  being developed, and subsequently to the failure
  to take adequate corrective action.
• Taurus a planned automated transaction settlement
  system for the London Stock Exchange, The project
  was canceled in 1993 after having lasted more
  than five years. The project cost was around
  75m the estimated loss to customers was around
  450m and the damage to the reputation of the
  London Stock Exchange was incalculable.

10
PROBLEMS SOFTWARE DEVELOPMENT (contd)

• lack of historical data on software development
  process (1)
• no good way to measure productivity (1, 2)
• poor communication with customer/other developers
  (1, 3)
• no systematic approach to software development
  (1, 2, 3)
• vague/unclear specification of customer
  requirements (1, 3)
• lack of systematic and complete software testing
  (3)
• little emphasis on software maintenance (3)

11
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 System
coupling
module any identifiable bit of a system which
it makes sense to consider separately

• BUT modules need to depend on each other

12
SOLUTIONS MODULAR DEVELOPMENT (contd)

• 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
  anywhereelse in the system

13
SOLUTIONS MODULAR DEVELOPMENT (contd)

• 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
14
SOLUTIONS MODULAR DEVELOPMENT (contd)

• 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
15
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

16
SOLUTIONS QUALITY DEVELOPMENT

• What does this mean?

correct user friendly evolvable
understandable reliable verifiable reusable
productive robust maintainable portable timely ef
ficient repairable interoperable visible

• How do we measure it?

• How do we achieve it?

17
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, 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

18
WHAT IS SOFTWARE ENGINEERING? 1.2

• 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
• economicallyreliableefficiently built-in
  quality metrics
• multi-person team effort management, training
• multi-version not a one-shot effort
  documentation, maintenance

19
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
• my need to revisit decisions already made bugs,
  technology, etc.
• Why did we make this choice?

20
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