310414 introduction & overview 1 310414 software engineering 310414 software engineering...

310414310414 INTRODUCTION & OVERVIEWINTRODUCTION & OVERVIEW1

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

310414310414SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

INTRODUCTION AND OVERVIEWINTRODUCTION AND OVERVIEWINTRODUCTION AND OVERVIEWINTRODUCTION AND OVERVIEW


SOFTWARE IS …SOFTWARE IS …

Important– pervasive and essential part

of almost all organizations– key part of many products

(embedded systems)

Soft

ware

D

em

an

d

1950 1960 1970 1980 1990 2000

Personal computing,information,education

Commercial

Scientific &Technical

Man

-mon

ths

100 200 300 400 500 600

2000

4000

6000

8000

1000’s of language statements

Big business– several hundred billion

dollars/year spent worldwide and growing

but ComplexComplex to develop– B-2 bomber: 3.5MLOC– Windows 95: 15MLOC

(plus 5,000 estimated bugs!)


SOFTWARE COMPLEXITY COMES FROM …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


SOFTWARE COMPLEXITY LEADS TO …SOFTWARE COMPLEXITY LEADS TO …

1. grossly inaccurate schedule and cost estimates– over schedule

– over budget

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

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


TheSystem

divide and conquerdivide and conquer

Large software systems are complex and changing.

There is a limit to how much a person can understand at any one time.

Large software systems are complex and changing.

There is a limit to how much a person can understand at any one time.

module: any identifiable “bit” of a system which it makes sense to consider separately

BUT modules need to depend on each other

couplingcoupling

DEALING WITH COMPLEXITY —DEALING WITH COMPLEXITY —MODULARMODULAR DEVELOPMENTDEVELOPMENT


MODULAR DEVELOPMENT (cont’d)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



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)

A module’s coupling coupling and cohesioncohesionare managed and controlled via its interface.interface.

A module’s coupling coupling and cohesioncohesionare managed and controlled via its interface.interface.

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



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

CHALLENGESCHALLENGES

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

CHALLENGESCHALLENGES

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

and the possibility of component-based development using a suitable software architecture

>>> INTERFACE <<<>>> INTERFACE <<<(encapsulation + abstraction = information hiding)(encapsulation + abstraction = information hiding)

>>> INTERFACE <<<>>> INTERFACE <<<(encapsulation + abstraction = information hiding)(encapsulation + abstraction = information hiding)


DEALING WITH COMPLEXITY —DEALING WITH COMPLEXITY —QUALITY DEVELOPMENTQUALITY 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)

Need a way to measure if you have achieved them.Need a way to measure if you have achieved them.

HARD!HARD!

Choose most important for a given project (design goals) and base the development around these


DEALING WITH COMPLEXITY —DEALING WITH COMPLEXITY —PERSONNEL DEVELOPMENTPERSONNEL DEVELOPMENT

““programming-in-the-small”programming-in-the-small” vs.vs. “programming-in-the-large”“programming-in-the-large”““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


SOFTWARE ENGINEERING IS …SOFTWARE ENGINEERING IS … [1.2][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


SOFTWARE ENGINEERING INVOLVES …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?



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



a LOT of documentation

and SOME coding

310414 introduction & overview 1 310414 software engineering 310414 software engineering...

Documents