ch.11 software engineering a preview. ch.12 outline definitions of software engineering (se)...

Ch.1 1

Software Engineering

A Preview

Ch.1 2

Outline

• Definitions of software engineering (SE)

• Historical origins of SE• SE as part of systems engineering• SE consists of many activities in

addition to programming• SE and other disciplines

Software Engineering: A Preview

• A computer science field that is dealing w/– large & complex sw systems– buit by a team or team of engineers– multi-version systems– long life-cycle (changes -> fix detects,

enhance, adaptation to new environment etc.)

Ch.1 3

Ch.1 4

Definitions• SE is

– «the application of engineering to software»

– «application of a systematic, disciplined, quantifiable, approach to development, operation, and maintenance of sw» IEEE

– «multi-person construction of multi verison sw» Parnas

Ch.1 5

Meaning

• Programmer – writes a complete program– a personal activity

• Software engineer– writes a sw component to be combined

w/ components written by other SEs.– components –> reusable, modifiable– a team activity

Ch.1 6

Need

• Programming evolved by algorithms, data structures, and OO programming.– not helping build [better, larger]

software.– writes a complete program– a personal activity

• differential equation solving (small program)• OS developing (scaled-up)

Ch.1 7

Strategy

• Vital engineering strategy– define problem– use and develop tools and techs.

• Parameters are not clear for SE– no mathematical tools exist– relies on experience & debate

Ch.1 8

Role of SE in system design

• SS is a part of a larger systems• Software requirements to be balanced against

others

– eg. Telephone switching system• Computers• Telephone lines• HW (satellite, telephones)• a controller SW

– eg. Traffic monitoring system– eg. Hospital administration

Satisfy requirements of HW, SW, and special devices

Ch.1 9

Role of SE in system design

• Complex balancing require SE to participate in developing requirements for the whole system.

• SE is a part of systems engineering– compromise & trade-offs– SW offers flexibility, HW offers

performance (eg. Coin-operated coffee machine)

A shortened history

• Programming – place sequence of instructions to get

the computer do sth useful– interaction btw programmer & computer– problematic when developing large

systems

• Large SW systems are significanty different

Ch.1 10

Ch.1 11

A shortened history

• The field of software engineering was born in 1968 in response to chronic failures of large software projects to meet schedule and budget constraints – recognition of "the software crisis"

• Term became popular after NATO Conference in Garmisch Partenkirchen (Germany), 1968

Ch.1 12

History – problem defined

• Problems in constructing large systems – understanding of problem– too much communication time– people leaving the Project– changes are not easy to apply

Ch.1 13

History – solutions

• Offered solutions– better managemet techs– different team organization– better programming languages & tools– uniform coding conventions– mathematical approaches

• Conclusion: apply engineering to software

History

SW costs < HW costs (was)SW costs >> HW costs (now)

•SE deals w/ entire life-cycle– conception -> design -> development

-> maintenance -> deployment -> evolution

Ch.1 14

Ch.1 15

Role of software engineer

• Software Engineer – must be a good-programmer

• Programming skill not enough (programming-in-the-small)

– familiar w/ design– translate vague requirements– form precise specifications– build models to balance trade-offs– A good Communicator– Schedule work (own and others)

programming-in-the-large

Ch.1 16

The software lifecycle«In theory- theory and practice are the same. In practice, they never are.»

Waterfall model -> life-cycle model1. Requirements analysis & specification

– feasibility study (costs & benefits)– by customer, developer, or marketing

org.– should be in end-user terms– requires interaction w/ users

Ch.1 17

The software lifecycleWaterfall model -> life-cycle model2. System design & specification

– architectural (high-level) design– detailed design– what – how dichotomy

3. Coding & module testing– produce actual code for end-user

the problem(analysis)

to solve(design)

Ch.1 18

The software lifecycleWaterfall model -> life-cycle model4. Integration & system testing

– integrate components & test whole system

– might require testing code

5. Delivery & maintenance– deliver product (SW) to the customer– make sure it works well

Ch.1 19

The software lifecycle(a preview)

Requirements analysis and specification

Design and specification

Code and module testing

Integration and system testing

Delivery and maintenance

waterfall model

Concurrent engineering?•parallelism

Ch.1 20

Relationships betweenSE and other CS disciplinesThere is a synergistic relationship1. Programming languages SE -> PL

– modularity (Java packages)– Exception-handling (reliable SW)– UI (visual languages)PL -> SE– precise requirement (by machine processible PLs)– Forming a language of commands (UNIX Shell commands)– Formalization leads to automation (exploited for automatic SW generation)

Ch.1 21

Relationships betweenSE and other CS disciplines2. Operating systems

OS -> SE–initial large projects–virtual machines, levels of abstraction–separation of policy from mechanism fairness in task scheduling – time-slicing concurrency (what – policy) (how – mechanism)

SE -> OS–portable OSs–Protected and unprotected kernels (command line interpreter)

Ch.1 22

Relationships betweenSE and other CS disciplines3. Databases

DB -> SE–data independence notion (separation&specification)

• Use data w/o worrying about representation• DB offers concurrent Access to data (useful component)

SE -> DB–long transactions

• CVS (lock code, work on a small piece, forbid access)

Ch.1 23

Relationships betweenSE and other CS disciplines4. Artificial intelligence

AI -> SE–explaratory development notion caused uncertainty handling (reverse Software Engineering)–programming assistants–cognitive models

• UI design

SE -> AI–expert systems

• Separation of «known» facts by «used» rules

Ch.1 24

Relationships betweenSE and other CS disciplines5. Theoretical models

TM -> SE–Finite-state machines

• SW specification & SW design

–Petri nets• Modeling of SW and HW

–Logic• Specification languages

SE -> TM–Abstract data type notion

Ch.1 25

Relationships betweenSE and other disciplines

SE cannot be practiced in vacuum.1.Management science

– project estimation, scheduling, human resource planning

2.Systems engineering– certain laws govern the behavior of

any complex system– analysis models

Ch.1 26

Concluding remarks

! SE is an evolving engineering discipline.

– deals w/ systematic approaches to building large SW systems by teams of programmers

! We will study essential principles to the engineering activity of building SW.