SOFTWARE ENGINEERING

1
SOFTWARE ENGINEERING

• INTRODUCTION AND OVERVIEW

2
LEARNIING OBJECTIIVES

• 1. Understand the nature and importance of
  software.
• 2. Appreciate that developing large software
  systems is a complex
• process.
• 3. Know some approaches for dealing with software
  development
• complexity.
• 4. Understand what software engineering is and
  why it is important
• in software development.

3
A SOFTWARE ENGIINEERIING PROVERB

• Software and Cathedrals are much
• the same
• First we build them then we pray!!!
• -Sam Redwine, Jr.

4
SOFTWARE IS

• Computer programs plus
• Configuration data
• Documentation (System, user)
• Types of software Copies in Annual
  Requirements
• Use development effort come from
• Generic medium medium market research
• Custom low high client needs
• Embedded high low client/hardware
• needs
• Alternative classification
• data processing ? organizes and stores business
  data
• real-time ? controls devices/processes in real
  time

5
SOFTWARE IS

• Important
• pervasive and essential part of almost all
  organizations
• key part of many products (embedded systems)

• Big business
• several hundred billion dollars/year spent
  worldwide and growing

• but Complex to develop
• B-2 bomber 3.5MLOC
• Windows 95 15MLOC(plus 5,000 estimated bugs!)

6
SOFTWARE COMPLEXITY COMES FROM

• Application domain
• problems are complex
• developers are not domain experts

• Communication among stakeholders(developers,client
  )
• different vocabulary domain experts ltgt
  developers ltgt developers
• Inherent ambiguity of language
• Different background knowledge of stakeholders
• Managing the process of large development
  projects
• dividing the project into pieces and reassembling
  the pieces
• coordinating many people
• Coding
• creating useful software is a complicated
  engineering process

7
SOFTWARE COMPLEXITY LEADS TO

• 1. software quality problem
• unreliable Hong Kong airport project Ariane 5
  rocket
• unsafe London Ambulance System Therac-25
• inflexible hard to change/maintain
• abandoned London Stock Exchange

• 2. Project management problems
• Often over schedule and over budget by an order
  of magnitude!
• 3. programmer productivity problems

On average, large software projects take - 25
are canceled - 50 take longer than
planned -75 are operational failures
8
SOFTWARE COMPLEXITY LEADS TO (contd)

• 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 was 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.

9
DEALING WITH COMPLEXITY QUALITY DEVELOPMENT
Many desirable software quality characteristics
correct user friendly evolvable
understandable reliable verifiable reusable
productive robust maintainable portable timely ef
ficient repairable interoperable visible

• Impossible(or unnecessary) to achieve all of them
  simultaneously (time/cost/conflicting or not
  important)

• Need to choose most important qualities for a
  given project (design goals) and base the
  development around these

This reduces the complexity of designing the
system!
10
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

11
DEALING WITH COMPLEXITY MODULAR DEVELOPMENT
Large software systems are complex and
changing. There is a limit to how much a person
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
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
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

A modules coupling and cohesion are managed and
controlled via its interface.
14
MODULAR DEVELOPMENT (contd)

• gtgtgt INTERFACE ltltlt
• (encapsulation abstraction information hiding)

• modularity defined via interfaces allows for
• more productivity in team development
• fewer bugs
• more maintainable software
• more reusable software

• and the possibility of module base
  (component-based) development using a suitable
  software architecture

This reduces the complexity of cost and time
estimates for developing the system!
15
DEALIING WIITH PROJECT MANAGEMENT
PROBLEMSMODULAR DEVELOPMENT (contd)
SOFTWARE ENGINEERING CHALLENGES 1. Define good
modules with the right things in their
interfaces. 2. Specify suitable software
architectures to support modules (components).
16
DEALIING WIITH PROGRAMMER PRODUCTIIVIITYPROBLEMS
TRAIINIING SOFTWARE ENGIINEERS

• . programming-in-the-small ? coding
• programming-in-the-large ? software engineering

• Software engineers need to be able to
• talk with user in terms of the application,
  rather than computer jargon
• translate vague requirements and desires into
  precise specifications
• move among different levels of abstraction at
  different stages of the project
• build a model of the application (actually
  several models)
• use and apply several design approaches
• choose among alternatives (tradeoffs)
• work in well-defined roles in a team

This reduces the complexity of building the
system!
17
SOFTWARE ENGINEERING IS 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
• real machines It solves a real problem
  (implied).
• multi-person team effort management, training
• multi-version not a one-shot effort
  documentation, maintenance

18
SOFTWARE ENGINEERING IS

• engineering principles ? It is a disciplined
  effort that
• systematically uses methodologies, techniques
  and tools, and a store of
• relevant knowledge, architectures and components
• uses a modular approach to system building with
  phases
• applies appropriate project management
  techniques
• economicallyreliableefficiently ? It has
  built-in quality that
• meets cost, time and other constraints
• has meaningful quality assurance (e.g.,
  standards)
• does formal testing of modules and the system
  as a whole
• real machines ? It solves a real problem
  (implied), therefore
• development is focused on meeting user
  requirements
• multi-person ? It requires team effort that
• pays attention to team organization, dynamics,
  and management
• multi-version ? It is not a one-shot effort,
  therefore, we
• plan for maintenance
• have excellent documentation

19
SOFTWARE ENGINEERING INVOLVES

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

• applying project management techniques

• paying attention to team organization, dynamics
• doing requirements based development
• systematically using methodologies, techniques
  and tools
• using a modular approach to system building
  phases
• doing formal testing of modules and the system as
  a whole
• having meaningful quality assurance (e.g.,
  standards)
• having excellent documentation
• using a store of relevant knowledge,
  architectures and components

21
SOFTWARE ENGINEERING INVOLVES

• a LOT of documentation

• and SOME coding

22
SUMMARY

• Developing large software systems is a complex
  process.
• We need to deal with this complexity by
• Having appropriate quality design goals
• Using modular development techniques
• Training computer scientists to use effective
  software engineering techniques.
• Most of software engineering involves modeling
  and documenting system requirements and
  solutions, not coding.

Modeling and documenting may often seem tedious
and boring but they are essential for helping to
reduce complexity and thus building better
software systems!