INTRODUCTION
INTRODUCTION TO
TO
SOFTWARE
SOFTWARE ENGINEERING
ENGINEERING
INTRODUCTION
INTRODUCTION AND
AND OVERVIEW
OVERVIEW
Venkat Srinivasan
1
[Link](I.T) INTRODUCTION & OVERVIEW
Evolution of a Developer
2
[Link](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
[Link](I.T) INTRODUCTION & OVERVIEW
Creating the illusion of simplicity
4
[Link](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
[Link](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
[Link](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
[Link](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
[Link](I.T) INTRODUCTION & OVERVIEW
How Are We Doing?
Performance
• Many Successes Analyst
Engineer
• Too Many Failures
Project
Manager
Developer
Tester
Release
Engineer
9
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](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
[Link](I.T) INTRODUCTION & OVERVIEW
SOFTWARE ENGINEERING INVOLVES …
a LOT of documentation
and SOME coding
20
[Link](I.T) INTRODUCTION & OVERVIEW