INTRODUCTION

INTRODUCTION TO
TO
SOFTWARE
SOFTWARE ENGINEERING
ENGINEERING

INTRODUCTION
INTRODUCTION AND
AND OVERVIEW
OVERVIEW

Venkat Srinivasan

1
M.Tech(I.T) INTRODUCTION & OVERVIEW
 Evolution of a Developer

2
M.Tech(I.T) INTRODUCTION & OVERVIEW
 SOFTWARE IS …
 Important
– pervasive and essential part
of almost all organizations
– key part of many products
(embedded systems)

 Big business Personal computing,

information,
education
– several hundred billion

Software
Demand
Commercial
dollars/year spent worldwide
Scientific &
and growing Technical
1950 1960 1970 1980 1990 2000

8000
 but Complex to develop
Man-months

6000
– B-2 bomber: 3.5MLOC 4000
– Windows 95: 15MLOC 2000

(plus 5,000 estimated bugs!) 100 200 300 400 500 600
1000’s of language statements

3
M.Tech(I.T) INTRODUCTION & OVERVIEW
 Creating the illusion of simplicity

4
M.Tech(I.T) INTRODUCTION & OVERVIEW
 SOFTWARE COMPLEXITY COMES FROM …
 Application domain
– problems are complex
– developers are not domain experts

 Communication among stakeholders

– vocabulary plus different background knowledge
– ambiguity of language

 Managing the process

– dividing the project into pieces and reassembling the pieces
– coordinating many people

 Coding
– creating useful software is a complicated process
5
M.Tech(I.T) INTRODUCTION & OVERVIEW
 SOFTWARE COMPLEXITY LEADS TO …

1. grossly inaccurate schedule and cost estimates

– over schedule
– over budget

2. software quality that 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

On average, large software projects take 50% longer than planned

75% of large software projects are operational failures

25% of large software projects are canceled

6
M.Tech(I.T) INTRODUCTION & OVERVIEW
 SOFTWARE COMPLEXITY LEADS TO … (cont’d)
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.
7
M.Tech(I.T) INTRODUCTION & OVERVIEW
 Software Development is a Job for Teams

Challenges
Performance
• Larger teams Engineer

• Specialization Analyst

• Distribution Project
Manager
• Rapid technology Developer
change Tester

Release
Engineer

8
M.Tech(I.T) INTRODUCTION & OVERVIEW
 How Are We Doing?

Performance

• Many Successes Analyst

Engineer

• Too Many Failures

Project
Manager
Developer

Tester

Release
Engineer

9
M.Tech(I.T) INTRODUCTION & OVERVIEW
 DEALING WITH COMPLEXITY —
MODULAR DEVELOPMENT
Large
Largesoftware
softwaresystems
systemsare
arecomplex
complexand
andchanging.
changing.
There
Thereisisaalimit
limitto
tohow
howmuch
muchaaperson
personcan
can
understand
understandat atany
anyone
onetime.
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

10
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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
11
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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

AAmodule’s
module’scoupling
couplingand
andcohesion
cohesion
are
aremanaged
managedand
andcontrolled
controlledvia
viaits
itsinterface.
interface.
12
M.Tech(I.T) INTRODUCTION & OVERVIEW
 MODULAR DEVELOPMENT (cont’d)

>>>
>>> INTERFACE
INTERFACE <<< <<<
(encapsulation
(encapsulation++abstraction
abstraction==information
informationhiding)
hiding)
 modularity defined via 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
CHALLENGES
––define
definegood
goodmodules
moduleswith
withthe
theright
rightthings
thingsin
intheir
theirinterfaces
interfaces
––specify
specifysuitable
suitablesoftware
softwarearchitectures
architecturesto
tosupport
supportcomponents
components
13
M.Tech(I.T) INTRODUCTION & OVERVIEW
 DEALING WITH COMPLEXITY —
QUALITY DEVELOPMENT

Many desirable software quality characteristics

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

Usually impossible to achieve all of them simultaneously

(time/cost/conflicting)

 Choose most important for a given project (design goals)

and base the development around these

Need a way to measure if you have achieved them.

HARD!
14
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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

15
M.Tech(I.T) INTRODUCTION & OVERVIEW
 DEALING WITH COMPLEXITY —
PERSONNEL DEVELOPMENT

““programming-in-the-small”
programming-in-the-small”vs.
vs.“programming-in-the-large”
“programming-in-the-large”

 need to talk with user in terms of the application, rather than

computer jargon
 often need to translate vague requirements and desires into
precise specifications
 need to move among different levels of abstraction at different
stages of the project
 need to build a “model” of the application (actually several models)
 may need to use and apply several design approaches
 often need to choose among alternatives (tradeoffs)
 often need to work in well-defined roles but a rigid fragmentation of
roles is often counterproductive
16
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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

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

17
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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?

18
M.Tech(I.T) INTRODUCTION & OVERVIEW
 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

19
M.Tech(I.T) INTRODUCTION & OVERVIEW
 SOFTWARE ENGINEERING INVOLVES …

a LOT of documentation

 and SOME coding

20
M.Tech(I.T) INTRODUCTION & OVERVIEW