10 1 1 197 7962

Software Engineering
Mehdi Jazayeri TU Wien October 2001
What is software engineering

n n n n n
Software?
Makes computer do specific task
Engineering?
Building machines to do useful things
Science
Discovering rules of nature
Technology
Products of engineering
Art?
Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 3
Outline
n Introduction n History n The process n Process and product n Process and product qualities
The purpose of software

n Takes a general purpose physical
machine (the hardware) that in principle can solve any problem n Transforms it into a special-purpose abstract machine that solves a specific problem in the real world n The hardware is useless without the software!
2 Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 4
Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien
n Field of computer science dealing with
Definitions of Software Engineering
n Deals with cost-effective solutions to
software systems
Large and complex Built by teams Exist in many versions Last many years Undergo changes n Multi-person construction of multi-
practical problems by applying scientific knowledge in building software artifacts in the service of mankind
cost-effective practical problems scientific knowledge building things service of mankind
Engineering
version software
n Systematic approach to development,
Kinds of software (based on customer)

n Packaged (shrink-wrapped) software:
operation, maintenance, deployment, retirement of software n Methodological and managerial discipline concerning the systematic production and maintenance of software products that are developed and maintained within anticipated and controlled time and cost limits
produced for mass (consumer) market

n Custom software developed by
contractor for client

n Custom software produced in one
organization for another part of same organization (no adversarial relationships)

Kinds of software (based on function)

n Application software (e.g. MS Word) n Embedded software (e.g. flight control) n System software (e.g. UNIX, Linux) n Middleware (e.g. CORBA) n Single system: HW - System SW -
Roles involved in the process

Market/customer
Users Controlled real world
critical interface Developer

Analyst Designer Programmer Manager
Application
n Networked systems: HW - System SW -
Middleware - Application
Facilitator: interface (or, requirements) expert

Kinds of software (based on domain requirements)

n Real-time (e.g. process control) n Safety-critical (e.g. medical systems) n Secure (e.g. banking) n Fault-tolerant (e.g. flight control, plant
Roles involved in the process

n
Market / customer
Developer
Understands domain Evaluates feasibility Masters technology Masters development/ deployment/ maintenance processes Interacts with customer/ is market-aware
control)
Has needs Expresses requirements Knows technology and how it can affect business Selects IT provider Defines contract Controls contractors Accepts delivered product/service
10
12
Whats the focus here? Its the interface

Market / Customer
n
Engineering: evolution
Art: ad-hoc solutions intuition talented amateur invent/reinvent (slow transmission of knowledge) Routine production Management + production techniques Science
Developer
Engineering
13
15
Engineering tasks
Routine design
solution of familiar problems reuse of previous solutions
The engineering lifecycle

Ad-hoc solution Folklore (partial solutions, heuristics) New problems Codification (systematic procedures) Improved practice Models&Theory
n n
Innovative design
novel solutions for unfamiliar problems
Software is treated more often as original than routine

we do not capture and organize what we know! mature engineering disciplines capture, organize and share design knowledge
16
Differences and analogies

n Software engineering vs traditional
Bridge building vs. software development

n
engineering n Many points are in common

But must be careful because deep differences exist as well!
Bridges normally built on-time, on- budget, and do not fall n Software is rarely on-time and on-budget
Why?
Common complaint
n n
Traditional engineering
n Extreme detail of design n Alternative designs can be validated
Software is still immature Other branches of industry do better than software factories in terms of
Quality of the products Quality of the process
through models
n Design is frozen and contractor has
Is that right? Why?

almost no flexibility in changing specifications n Standard processes are followed

Software engineering: difference1

n Software is a key component of
Software engineering: difference 2

n Bridge design is 3000 years old n Large body of knowledge: underlying
applications and services that are at the heart of business n Frozen specifications and designs do not accommodate changes in the business practices n Continuous change and evolution
theories and methods

We are moving in this direction n Large body of knowledge: analysis of
failures
We seldom analyze failures!
Software is different
n Requests for change and rapid
Software engineer: required skills

n
Programming skill not enough

programmer
develops a complete program works on known specifications works individually
adaptation n Software products are necessarily less stable than other products n Other products are intrinsically unable to evolve n Development processes have to deal with changing requirements
software engineer
identifies requirements and develops specifications designs a component to be combined with other components, developed, maintained, used by others; component can become part of several systems works in a team (requires communication)
Examples
n
Domain knowledge
n
A telephone system
when one picks up the phone, the tone must be heard within x msec.
Document management in an office system

the boss can access all documents of all of his subordinates. Each subordinate can access only his/her documents. After the boss declares a document closed, the subordinate cannot modify it
Plays a fundamental role in sw development n To develop a banking system, one must understand how banks work
How does the process of issuing a loan work?
n
Software developed based on wrong domain assumption can generate disasters

Loss of money, damage to business, to environment, to people
25
Requirements&Specification
n
Skills
n n n n n n
From requirements and knowledge of the environment one derives a specification of the application
Exercise:
1. Do it for the document management system 2. Do it for word -processing of multi-file documents
Technical Project management Cognitive Enterprise organization Interaction with different cultures Domain knowledge Development technology is important Quality of human engineer is fundamental
Other examples:
traffic control systems hospital administration systems banking systems
28
History: initial situation

n n
Need for software engineering

n Development n Planning
Software is art Computers used for computing

mathematical problems designers = users no extended lifetime
The art of programming

low level languages resource constraints (speed and memory) the artist could really make the machine hum!
methods and standards and management n Automation n Verifiable quality n Componentization n . From art to industry
Term software engineering defined in a NATO conference in Garmisch, Oct. 1968
n n
From computing to information management Requests for new (custom) software explode
users designers EDP centers and software houses
From art to craft
Large systems--critical systems

n Examples
of large systems
Space shuttle project

5.6 million code lines, 22k man year, 1200 Million$
New high level languages n First large projects and first fiasco's
time and budget, human cooperation failures wrong specifications
CityBank teller machine

780,000 code lines, 150 man year, 13.2 Million$
n Critical
systems
failures generate risks or losses (financial, life)
The engineering approach should improve quality

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 30 Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 32
$ size of applications
Average development cost for
Large company
2,3 million $
Needs
n Recent (2000) study by Microsoft with
IDC and Datamonitor

In the year 2003 in Europe there will be a deficit of 1.700.000 people in IT Demand exceeds availability by 33%
Medium company
1,3 million $
Small company
430.000 $
33
35
Relevance
n In 1996 software was the third industrial
Professional responsibility of software engineers

n Personal, professional, social
sector after car and electronics

More than 250 billion$ a year spent on application development n In the EU the wider field of information
responsibilities n Professional responsibility

Accept individual responsibility Solve the real problem Be honest about capabilities Produce reviewable designs Produce maintainable products
technology is viewed as the key strategic sector

focused research funding within the 4th and 5th framework programs
Problem: project failures

n Almost 30% of development projects
Software lifecycle models

n The traditional waterfall model identify phases and activities force linear progression from a phase to the next no returns (they are harmful)
better planning and control
are canceled before they are completed! n About 53% of projects cost 190% of original estimates
And hidden costs due to lost opportunities!!! Example: failure to produce reliable software for baggage handling at Denver airport cost over 1 million $ per day!
standardize outputs (artifacts) from each phase
software like manufacturing

Understand and manage software lifecycle

LIFECYCLE From the problem to the product and its deployment and evolution until its retirement
A waterfall model
Feasibility study Requirements analysis& specification Design Coding&Unit test Integration&System test Deployment
38 Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien
It is necessary to do better than the common code&fix lifecycle (i.e., no model)!!!

Maintenance
40
10
Feasibility study
n n n
The 5 Ws
Who
who will use the system n n
Cost/benefits analysis Determines whether the project should be started (e.g., buy vs make), possible alternatives, needed resources Produces a Feasibility Study Document
Preliminary problem description Scenarios describing possible solutions Costs and schedule for the different alternatives
Why
why should it be developed + why will the users use it
What (vs How)

what will it provide
n n
Where
where will it be used, on which architecture
When
when and how long will it be used
43
Req. analysis and specification

n n n
Requiremensts Analysis and Specification Document

n
Analyze the domain in which the application takes place Identify requirements Derive specifications for the software
Requires interaction with the user Requires understanding of the properties of the domain
Required properties
Precise Complete Consistent
May include
Preliminary User Manual System Test Plan
Produces a Requirements Analysis and Specification Document (RASD)

44
11
Design
n n
Coding&Unit test
Each module is implemented using the selected programming language Each module is tested in isolation by the modules developer Programs include their documentation
Defines the software architecture

Components (modules) Relations among components Interactions among components
n
Goal
Support concurrent development, separate responsibilities
Produces the Design Document

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 45 Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien 47
Creativity & discipline in design

n n n
Integration&System test
n
Design requires creativity Designer (engineer) creates something that did not exist before Architectural styles try to capture common structures in software design (static) Design patterns try to capture recurring parts of designs (more dynamic issues)
Modules are integrated into (sub)systems and integrated (sub)systems are tested This phase and the previous may be integrated in an incremental implementation scheme Complete system test needed to verify overall properties Often we have alpha test and beta test
12
Effort distribution
n
Maintenance
n n
From 125 projects in Hewlett-Packard

18% requirements and specification 19% design 34% coding 29% testing
All changes that follow delivery Unfortunate term: software does not wear out
if a failure occurs, the cause was there from the beginning
Often more than 50% of total costs

Recent survey among EU companies:
80% of IT budget spent on maintenance
typical variations of 10%
49
51
Deployment
Maintenance
n
Distribute the application and manage the different installations and configurations at the clients sites
It includes different types of change: correction + evolution

corrective maintenance 20% adaptive maintenance 20% perfective maintenance 50%
50
52
13
Concepts underlying life cycle

n n
Quality dimensions
Process vs. Product Internal vs. External Internal qualities affect external qualities Process quality affects product quality
Phased development Communication among phases

documents people
Coordination of phases
The software product

n
Correctness
n n
Different from traditional types of products

intangible
difficult to describe and evaluate
malleable human intensive

does not involve any trivial manufacturing process primarily an intellectual endeavor determined by human intellectual ability Mehdi Jazayeri--SE-Intro (vers.
2001) / TU Wien
Software is correct if it satisfies the specifications If specifications are stated formally, since programs are formal objects, correctness can be defined formally
It can be proven as a theorem or disproved by counterexamples (testing)
Try to develop a priori correct sw

via suitable process (see later) suitable tools (high level languages, reuse)
54
56
14
The limits of correctness

n
Performance
n n
It is an absolute (yes/no) quality

there is no concept of degree of correctness there is no concept of severity of deviation
Efficient use of resources

memory, processing time, communication
Can be verified
complexity analysis performance evaluation (on a model, via simulation)
What if specification are wrong?

(e.g., they derive from incorrect requirements or errors in domain knowledge)
Performance can affect scalability

a solution that works on a small local network may not work on a large intranet
n n
Performance can affect usability (see next) Performance may change with technology
Reliability
Reliability, robustness
Usability
n n
informally, user can rely on it can be defined mathematically as probability of absence of failures for a certain time period if specs are correct, all correct software is reliable, but not vice-versa (in practice, however, specs can be incorrect )
n
Expected users find the system easy to use Important: define the expected user
if the user is an installer, ease of installation is part of usability
n n n n
Robustness
software behaves reasonably even in unforeseen circumstances (e.g., incorrect input, hardware failure)
Other terms: ergonomic, user friendly Rather subjective, difficult to evaluate Evaluation made less subjective via panels Affected mostly by user interface
e.g., visual vs textual
60
15
Key SE principles
n n n n n n n
Rigor and formality Separation of concerns Modularity Abstraction Anticipation of change Generality Incrementality
Reference
C. Ghezzi, M. Jazayeri, D. Mandrioli Fundamentals of software engineering, Prentice Hall, 1991
62
16

10 1 1 197 7962

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

10 1 1 197 7962

Încărcat de

Drepturi de autor:

Formate disponibile

Software Engineering

Mehdi Jazayeri TU Wien October 2001

What is software engineering

The purpose of software

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

n Field of computer science dealing with

Definitions of Software Engineering

n Deals with cost-effective solutions to

Definitions of Software Engineering

n Systematic approach to development,

Definitions of Software Engineering

Kinds of software (based on customer)

produced for mass (consumer) market

contractor for client

organization for another part of same organization (no adversarial relationships)

Kinds of software (based on function)

Roles involved in the process

critical interface Developer

Facilitator: interface (or, requirements) expert

Kinds of software (based on domain requirements)

Roles involved in the process

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Whats the focus here? Its the interface

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

The engineering lifecycle

Software is treated more often as original than routine

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Differences and analogies

Bridge building vs. software development

engineering n Many points are in common

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Is that right? Why?

almost no flexibility in changing specifications n Standard processes are followed

Software engineering: difference1

Software engineering: difference 2

theories and methods

Software engineer: required skills

Programming skill not enough

Document management in an office system

Software developed based on wrong domain assumption can generate disasters

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

History: initial situation

Need for software engineering

Software is art Computers used for computing

The art of programming

From art to craft

Large systems--critical systems

Space shuttle project

CityBank teller machine

failures generate risks or losses (financial, life)

The engineering approach should improve quality

IDC and Datamonitor

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Mehdi Jazayeri--SE-Intro (vers. 2001) / TU Wien

Professional responsibility of software engineers

sector after car and electronics

responsibilities n Professional responsibility

technology is viewed as the key strategic sector

Problem: project failures