1 Not just operating systems The basic issue 7 8 Developing - - PDF document

1

I ntroduction to Programming – Lecture 26

1 Chair of Softw are Engineering

Introduction to Programming Bertrand Meyer

Last revised 2 February 2004

I ntroduction to Programming – Lecture 26

2 Chair of Softw are Engineering

Lecture 26: From Programming to Software Engineering

I ntroduction to Programming – Lecture 26

3 Chair of Softw are Engineering

Software engineering (1)

The processes, methods, techniques, tools and languages for developing quality

• perational software.

I ntroduction to Programming – Lecture 26

4 Chair of Softw are Engineering

Software engineering (2)

The processes, methods, techniques, tools and languages for developing quality

• perational software that may need to

Be of large size Be developed and used over a long period Involve many developers Undergo many changes and revisions

I ntroduction to Programming – Lecture 26

5 Chair of Softw are Engineering

Operating systems: source lines

1990 1995 1998 2000 2 10 20 40 30 Lines of code (millions)

Windows 3.1: 3 M Windows NT: 4 M Windows 95: 15 M Windows 98: 18 M Windows 2000: 40 M 1992 Windows XP: > 45 M

I ntroduction to Programming – Lecture 26

6 Chair of Softw are Engineering

Not just Windows

1990

1992

1995 1998 2000 2 10 20 40 30 Lines of code (millions) Windows 3.1: 3 M Windows NT: 4 M Windows 95: 15 M Windows 98: 18 M Windows 2000: 40 M Red Hat 6.2 17 M Red Hat 7.1 30 M Linux: 10,000 Solaris 7: 12 Mio. Unix V7: 10,000 Windows XP: > 45 M

2

I ntroduction to Programming – Lecture 26

7 Chair of Softw are Engineering

Not just operating systems

I ntroduction to Programming – Lecture 26

8 Chair of Softw are Engineering

The basic issue

Developing software systems that are

On time and within budget Of high immediate quality Possibly large and complex Extendible

I ntroduction to Programming – Lecture 26

9 Chair of Softw are Engineering

US Software industry, 1998

Standish Group: “Chaos” Report 250,000 Software projects, $275 billions Project results:

• 28% abandoned (1994: 31% )
• 27% successful (1994: 16% )

The rest: “challenged”

Smaller projects have higher chances of success

I ntroduction to Programming – Lecture 26

10 Chair of Softw are Engineering

NIST report on testing (May 2002)

Financial consequences, on developers and users,

• f “insufficient testing

infrastructure” $ 59.5 B.

(Finance $ 3.3 B, Car and aerospace $ 1.8 B. etc.)

I ntroduction to Programming – Lecture 26

11 Chair of Softw are Engineering

Software quality factors

External: of interest to customers

Exam ples: Reliability, Extendibility

Internal: of interest to customers

Exam ples: Modularity, Style

I ntroduction to Programming – Lecture 26

12 Chair of Softw are Engineering

Some internal factors

Modularity Observation of style rules Consistency Structure ...

3

I ntroduction to Programming – Lecture 26

13 Chair of Softw are Engineering

External factors: reliability

Reliability = Correctness + Robustness + Integrity Hostility

Integrity

Errors

Correctness

Specification

Correctness

I ntroduction to Programming – Lecture 26

14 Chair of Softw are Engineering

Reliability

Correctness

The system’s ability to perform its functions according to the specification, in cases covered by the specification

Robustness

The system’s ability to handle erroneous cases safely

Integrity

The system’s ability to protect its users, its data and itself against hostile uses

Hostility

Integrity

Errors

Robustness

Specification

Correctness

I ntroduction to Programming – Lecture 26

15 Chair of Softw are Engineering

External factors

Product quality (immediate): Reliability Efficiency Ease of use Ease of learning Process quality: Timeliness Cost-effectiveness Product quality (long term): Extendibility Reusability Portability

I ntroduction to Programming – Lecture 26

16 Chair of Softw are Engineering

Software tasks

Requirements analysis Specification Design Implementation Validation & Verification (V&V) Management Planning and estimating Measurement

I ntroduction to Programming – Lecture 26

17 Chair of Softw are Engineering

Validation & Verification

Verification: checking that you have built the system right (followed all rules) Validation: checking that you have built the right system (satisfied user needs)

I ntroduction to Programming – Lecture 26

18 Chair of Softw are Engineering

Requirements analysis

Understanding user needs Understanding constraints on the system

4

I ntroduction to Programming – Lecture 26

19 Chair of Softw are Engineering

Software lifecycle models

Describe an overall distribution of the software construction into tasks, and the

• rdering of these tasks

They are models in two ways: Provide an abstracted version of reality Describe an ideal scheme, not always followed in practice

I ntroduction to Programming – Lecture 26

20 Chair of Softw are Engineering

The waterfall model (Royce, 1970)

FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION DISTRIBUTION VALIDATION & VERIFICATION

PROJECT PROGRESS

I ntroduction to Programming – Lecture 26

21 Chair of Softw are Engineering

Lifecycle: what not to achieve

As Management requested it As the Project Leader defined it As Systems designed it As Programming developed it As Operations installed it What the user wanted

(Pre-1970 cartoon; origin unknown)

I ntroduction to Programming – Lecture 26

22 Chair of Softw are Engineering

The waterfall model

FEASIBILITY STUDY REQUIREMENTS ANALYSIS SPECIFICATION GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION DISTRIBUTION VALIDATION & VERIFICATION

PROJECT PROGRESS

I ntroduction to Programming – Lecture 26

23 Chair of Softw are Engineering

A more realistic version

FEASIBILITY STUDY REQUIREMENTS ANALYSIS GLOBAL DESIGN DETAILED DESIGN IMPLEMENTATION ACCEPTANCE TESTING SYSTEM TESTING UNIT TESTING

I ntroduction to Programming – Lecture 26

24 Chair of Softw are Engineering

The spiral model

Apply a waterfall-like approach to successive prototypes

Iteration 1 Iteration 2 Iteration 3

5

I ntroduction to Programming – Lecture 26

25 Chair of Softw are Engineering

The problem with prototyping

Software development is hard because of the need to reconcile conflicting criteria, e.g. portability and efficiency A prototype typically sacrifices some of these criteria Risk of shipping the prototype

I ntroduction to Programming – Lecture 26

26 Chair of Softw are Engineering

Seamless, incremental development

The Eiffel view: Single set of notation, tools, concepts, principles throughout Eiffel is as m uch for analysis & design as for im plementation & maintenance Continuous, incremental development Keep model, im plementation and documentation consistent Reversibility: can go back and forth

I ntroduction to Programming – Lecture 26

27 Chair of Softw are Engineering

Seamless development (1)

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes Specification

I ntroduction to Programming – Lecture 26

28 Chair of Softw are Engineering

Seamless development (2)

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes Design Specification

STATE, USER_COMMAND...

I ntroduction to Programming – Lecture 26

29 Chair of Softw are Engineering

Seamless development (3)

Implementation

TRANSACTION, PLANE, CUSTOMER, ENGINE...

Example classes Design Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

I ntroduction to Programming – Lecture 26

30 Chair of Softw are Engineering

Seamless development (4)

Implementation

V & V

TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER, ...

Example classes Design Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

6

I ntroduction to Programming – Lecture 26

31 Chair of Softw are Engineering

Seamless development (5)

Implementation

V & V

TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER, ...

Example classes Design Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

Genera- lization

AIRCRAFT, ...

I ntroduction to Programming – Lecture 26

32 Chair of Softw are Engineering

Generalization

Prepare for reuse For example:

Remove built-in lim its Remove dependencies on specifics of project Improve documentation, contracts...

Few companies have the guts to provide the budget for this

I ntroduction to Programming – Lecture 26

33 Chair of Softw are Engineering

Seamless development

Implementation V & V

TRANSACTION, PLANE, CUSTOMER, ENGINE... TEST_DRIVER, ...

Example classes Design Specification

STATE, USER_COMMAND... HASH_TABLE, LINKED_LIST...

Genera- lization

AIRCRAFT, ...

I ntroduction to Programming – Lecture 26

34 Chair of Softw are Engineering

Reversibility

S V D I S G

I ntroduction to Programming – Lecture 26

35 Chair of Softw are Engineering

The cluster model

I V D S G I V D S G I V D S G I V D S G Cluster 1 Cluster 2 Cluster n

I ntroduction to Programming – Lecture 26

36 Chair of Softw are Engineering

Agile methods and extreme programming De-emphasize process and reuse Emphasize the role of tests to guide the development

7

I ntroduction to Programming – Lecture 26

37 Chair of Softw are Engineering

Validation and Verification

Not just testing: Static Analysis tools explore code for possible deficiencies, e.g. uninitialized variables Should be performed throughout the process, not just at the end

I ntroduction to Programming – Lecture 26

38 Chair of Softw are Engineering

Formal methods

Use mathematics as the basis for software development A software system is viewed as a mathematical theory, progressively refined until directly implementable Every variant of the theory and every refinement step is proved Proof supported by computerized tools Example: Atelier B, security system of newest Paris Metro line

I ntroduction to Programming – Lecture 26

39 Chair of Softw are Engineering

Metrics

Things to measure: Product attributes: lines of code, num ber of classes, complexity of control structure (“cyclomatic number”), com plexity and depth of inheritance structure, presence of contracts... Project attributes: number of people, person- months, costs, time to com pletion, time of various activities (analysis, design, im plementation, V&V etc.) Taking good m easurements helps take good measures

I ntroduction to Programming – Lecture 26

40 Chair of Softw are Engineering

Cost models

Attempt to evaluate cost of software development ahead of project, based on estim ate of parameters Exam ple: COCOMO (Constructive Cost Model), Barry Boehm

Time Effort (pm) Program type 2.5 ∗ pm ∗ 0.32 3.6 ∗ L ∗ 1.20 System 2.5 ∗ pm ∗ 0.35 3.0 ∗ L ∗ 1.12 Utility 2.5 ∗ pm ∗ 0.38 2.4 ∗ L ∗ 1.05 Application L: 1000 ∗ Delivered Source Instructions (KDSI)

I ntroduction to Programming – Lecture 26

41 Chair of Softw are Engineering

Software reliability models

Estimate number of bugs from

Characteristics of program Num ber of bugs found so far

Variant: “Fault injection”

I ntroduction to Programming – Lecture 26

42 Chair of Softw are Engineering

Project management

Team specialties: customer relations, analyst, designer, implementer, tester, manager, documenter... What role for the manager: managerial

• nly, or technical too?

“Chief Programmer teams”

8

I ntroduction to Programming – Lecture 26

43 Chair of Softw are Engineering

Software engineering

In the end it’s code Don’t underestimate the role of tools, language and, more generally, technology Bad management kills projects Good technology makes projects succeed

I ntroduction to Programming – Lecture 26

44 Chair of Softw are Engineering

End of lecture 26