Engineering Software

Software

Engineering

Software Engineering

(Eighth Edition)

m~(I~~jJi&~t Chino Mochire Press-

Ian Sommerville: Software Engineering, Eighth Edition (ISBN 13: 978-0-321-31379-9, ISBN 10: 0-321-31379-8).

Copyright © Addison-Wesley Publishers Limited 1982, 1984, © Pearson Education Limited 1989, 2001, 2004, 2007.

This edition of Software Engineering, Eighth Edition is published by arrangement with Pearson Education Limited. Licensed for sale in the mainland territory of the People's Republic of China only, excluding Hong Kong, Macau, and Taiwan.

*~~xJ3fPItR

fE

_~lliJPearsonEducation:f:if~~l!f t±J1tR~ffitt#t±JltRo _*~t±JltRetf

~OOW~, ~m0ffM~~~~~~.*~~$o

J1tJ3fPWRH~1:E9='lliJ*IltliJ1BlKf~1!J: (~'@tj§ffi~, i~n, i:li~J1BIK)o

ItIHJ{JilTfii,

~fJ{~'9Eo

*~j*~~iCJ :It*m~iti~Uili$*JilT

*.:t!Jt&~~iC~:

111*:

01-2006-2848

$Jc{tf:I~ (~xltR. 3!t8/lR) / (~) irJiMX~~ (Sommerville,1.) ~. -~tffi: tJltOCI AJ!.t±J ItR11, 2006.9

U2~JJJl:ItR~Jf)

~15JJJl:

X:

Software Engineering, Eighth Edition ISBN 7-111-19770-4

I.tX'" II.

iVi .. ·

^III.$Jc{tf:I~-~;f:t-~X IV.TP311.5

tJltOCI\lJt.t±JItR11 (~t;)\rni*iJ&IKR7JI±:*fij22\} ~r>iF:I:~li~ ^10(037) rJtff~JiUJj::

jiSt!R1F

~tffiffi~t1liJJJ\&fp,ljlljrfP,ljl1j . iT#<~m~tffi:&{'rFJT:&fi 2006~9JjW; 1 Jt&3!t 1 ixfp,ljlrj

170mm x 242mm . 54fp;H~

fl::{f)-: 79.005[:

~~*~,~~~M,RM,~M, ~*tl~fi$~~

*tlm±.J~t.M:£: (010) 68326294

~z.~~.,.~~*~ft~.~~~~m~~~*.ffi,~~~OO~a~~ft

~~4~.~*~T~.tt~~.I&~A~#~~.,~.OOaMAtt*~.~~

+$.~~~.W. ~.m~oa.ft~~*a~,.OO~F~~~

• •

_~~*~~

~

!1Mi!Ht, it3l:fJL

~

ft

~ ~

iff $

~

l1.J

_{~t4 ~}

flit

~B.bft/iJfflJ.~ ~ ~

M

~,

E8 ^!It ffij F:':t

~~Aft~.~,~&g~T/iJf~~M.,ili.~T~*~.~,

&• •

~*.ffi, x~~~.~tt,~~M#~~~.A~~~ffij.~o

~.,a~.MA~*~~.~~,aOO~it3l:fJLF~~.ili~,~~~A~~.

*s~~mo~~it3l:fJL

• •

~~W~~6&AfJL~'&~.~lffij~~.#~.~

a • •

M.~B.*~Q.oaaooMAtt*~.fIit~~m.M~Am~&~~~~,

.~.~~oo~a~it3l:fJLft~~.~~+~~~~~~A.#~~iff$M

• • •

~

~o ~!It, SI*-mOO9r~~it3l:fJL.M¥f~:J~OOit3l:fJL

• •

*~~~.jf:£~fi~.

~~m,&~~~~.~

. •

~.~~~~-~*~~~E8~.o

fJLfJltI~WII1iH~litOO~f~;[jj.ff~IH~'§j~lf·~ift¥U"WII1i~~

• •Bli9V

⁰ ~

1998

~*M,~lit~'§j.¥fI~.~~aT~~.n~OO*~~.#~o~~~.~~~

~j], aff1~Prentice

Hall, Addison-Wesley, McGraw-Hill, Morgan

Kaufmann.~~

.~WII1i~'§j.:lz:T fHf~itflp~~

,hf...

'Eff1ffl~ff~~(s#.#~fi~WTanenbaum,

Stroustrup, Kernighan, Jim

Gray.*~ffi~~i¥J-m~AflpJ1,

CJ.

"it3l:fJLf4~JA=t5"

~~.WIl1i,m

• •

~~./iJf~&~.o*~~tt~~#OO,&~~~T~.JA=t5~

~~tnlJf*~o

"it.fJLft~JA=t5"~WII1iI~.~TOO~*~.~~j].~,OO~~~~~&.

mT~fi~~mm~,ili~~~~~mffT~~~*~~I~lffij~~i¥J~.&~~

~~~~J1~~OO~~., ff~ili~a~~~~~~*~*o~~,"it.fJLft~JA=t5"

B~WII1iT~W~J1#,~~~.~

• •

~W:lz:T~M~o.,#.iff$~~*m~

~~.M~~~~., ~*-~.J~~.ff~T~~~~~o

fIj{i~~ft.i~~:m~7t:gnlJ.M&1i'i~~~~ft,

• •

~~

00

9rit.tJ1,.M~~*

~$mff~~A-~~~IlfI~~o ~J!It, ~~~~'§j~:jJlJ*91*.M~j]1t, ~ "~lit

• •"

~~.~~~WII1i=~~~~it3l:fJL.M: ~"it.fJLft~JA~"~*,~tiffill1i~

.#, 1Jl11J1i5!t7fB!FW

"g~A~~=t5~" ^I ~fIit, 91*~.jjfT~.~$ift~~

"Schaum s Outlines"

~7Ijm~ "~.~A~~t~~~71j" ⁰ ~THHiE~=.JA~~:tU&:·I1:, ~fIit

&~

T

J~M~~~~flJ~~ffifi1BIi*, ~lit~ '§jIP~i1f

T

~ OOf4~1l7t. ~t;j'(*~. m~*

iv

~,oo~~tt*~, ~~*~,~~~~*~, ~~*~, ~U*~, *OO~tt*~,

*/F~I~*~, jffi~~~*~, *OOA~*~, ~t~mt~mt7C*~, ~t~I!r~E!!*~,

*

l1J*~, M1it*t1l[I*~, *l)1+1*~, Wl~tI~IliC,

* 00

00~f1L~,~:@:ilJllJt-¥i)d[*

b~OOI*J:m:R.:*~llJf1J-1iJf;fJL~tEit.trLl3"J~1'ijj~I3"J~~~:ifm~ "~~m~~ w~",

~ft{nf)H~~Im:lf..!A~J:lJ tI:ll\i~1f⁰

~=.~~£~~

• • • •

tI:ll3"J~m*I\i.#I3"J%B,~OOI*J~~l3"Jit.trLRffi~

~~I3"J.~1t:!itiT~l3"Jo :j\:*i'f:$~#:M;]e..~M.I.T., Stanford

V.c.

Berkeley, C.

M.

V.~~~~~*~m*mo~~M~T~ff~it,~~M~,~~~~,it.m~~

M~,~~$,~w~t1l[,~#I~, OO%~,~ffi~~~, .~~~~OOI*J*~it .m~~ifjJ1i7fi~l3"J~jL'iJ:~, rmli~A~~-fl"l3"JtI:ll3m§i~it:ifz-'f,

fl"13"J1E

~~+~rm~~,fl"I3"Je..~:@:~~I3"J~sm~~*motE~®~~~~I3"J~~*~13"J

mslZr,

*:if~':l?ftEit.m~~I3"J'S~*E8~-grmA'¥:o

~~I3"J~:if, ~~I3"J.#, -~l3"Jw:if,F~I3"J$~,m~I3"J~~,~®~~~ft mI3"JOO~fl"TM.I3"J*~,mftml3"J§~£~.~~,rm&.I3"J:lf.m~£ftm~.~

- • •

§~I3"J:m:~.@o.#l3"JtI:lI\iR£ftml3"J~.R*I3"J~R.:o$.0~~~~~

~*:if~ftmI3"JI~.tI:l.~~~~m~,ftml3"J~~~~~r:

E!!-TI!r~#: hzjsj@hzbook.com

~~E!!i1S: (010) 68995264

~~ffi?:W:: ~t~rPjffi~IKS7JEti¥ifjjl%

I!r~m(~~: 100037

~r:=j~~~C:=-6 _~ 8 , ,. !NZi;

(

t:t:~~

J3C

_~@J }IIOO

J¥ )

£ JJ!1t i~#f~~ :t.,t~ii.

'0

Jt. ^1/J'~~: *i!t,t

0

~ 1i1Jt. ~ vif 'M- _~Jtt

Fit; _{FJIl~ Fit;~~~} F.tt; ~ If

)G]1$t* _Z./J'~:- * ^{FJIl i¥}

~1a lf~ 1r ^{~.ij~ Jii!t If)}

^'g1

~ ~ /fl _1t!~ ^?f.0

_{~' ~}

at

^'.t>

:IX. _~

The first edition of this textbook on software engineering was published more than twenty years ago. That edition was wJitten using a dumb terminal attached to an early minicomputer (a PDP-II) that probably cost about $50,000. I wrote this edition on a wireless laptop that cost less than $2,000 and is many times more powerful than that PDP-Ii. Software then was mostly mainframe software, but personal computers were just becoming available. None of us then realised how pervasive these would become and how much they would change the world.

Changes in hardware over the past twenty or so years have been absolutely remark- able, and it may appear that changes in software have been equally significant.

Certainly, our ability to build large and complex systems has improved dramatically.

Our national utilities and infrastructure-energy, communications and transport- rely on very complex and, largely, very reliable computer systems. For building business systems, there is an alphabet soup of technologies-J2EE, .NET, EJB, SAP, BPEL4WS, SOAP, CBSE-that allow large web-based applications to be deployed much more quickly than was possible in the past.

However, although much appears to have changed in the last two decades, when we look beyond the specific technologies to the fundamental processes of soft- ware engineering, much has stayed the same. We recognised twenty years ago that the waterfall model of the software process had serious problems, yet a survey published in December 2003 in IEEE Software showed that more than 40% of compames are still using this approach. Testing is still the dominant program validation technique, although other techniques such as mspections have been used more effectively since the mid-1970s. CASE tools, although now based around the UML, are still essentially diagram editors with some checking and code-generation functionality.

viii Preface

Our current software engineering methods and techniques have made us much better at building large and complex systems than we were. However, there are still too many projects that are late, are over budget and do not deliver the software that meets the customer s needs. While I was writing the 7th edition, a government enquiry in the UK reported on the project to provide a national system to be used in courts that

try

relatively minor offenders. The cost of this system was estimated at £156 million and it was scheduled for delivery in 2001. In 2004, costs had escalated to £390 million and it was still not fully operational. There is, therefore, still a pressing need for software engineering education.

Over the past few years, the most significant developments in software engineer- ing have been the emergence of the UML as a standard for object-oriented system description and the development of agile methods such as extreme programming.

Agile methods are geared to rapid system development, explicitly involve the user in the development team, and reduce paperwork and bureaucracy in the software process. In spite of what some critics claim, I think these approaches embody good software engineering practice. They have a well-defined process, pay attention to system specification and user requirements, and have high quality standards.

However, this revision has not become a text on agile methods. Rather, I focus on the basic software engineering processes-specification, design, development, verification, and validation and management. You need to understand these processes and associated techniques to decide whether agile methods are the most appropriate development strategy for you and how to adapt and change methods to suit your particular situation. A pervasive theme of the book is critical systems-systems whose failure has severe consequences and where system dependability is critical. In each part of the book, I discuss specific software engineering techniques that are relevant to critical systems engineering.

Books inevitably reflect the opinions and prejudices of their authors. Some readers will disagree with my opinions and with my choice of material. Such dis- agreement is a healthy reflection of the diversity of the discipline and is essential for its evolution. Nevertheless, I hope that all software engineers and software engineering students can find something of interest here.

The structure of the book

The structure of the book is based around the fundamental software engineering processes.

It

is organised into seven parts. The first six focus on software processes and the final part discusses some important new software engineering technologies.

Part 1: Introduces software engineering, places it in a broader systems context

and presents the notions of software engineering processes and management.

Preface ix

Part 2: Covers the processes, tech.niques and deliverables that are associated with requirements engineering. It includes II discussion of software requirements, system modelling, formal specification and techniques for specifying dependability.

Part

3:

This part is devoted to software design and design processes. Three out of the six chapters focus on the important topic of software architectures. Other topics include object-oriented design, n:al-time systems design and user interface design.

Part 4: Describes a number of approaches to development, including agile methods, software reuse, CBSE and critical systems development. Because change is now such a large part of development, I have integrated material on software evolution and maintenance into this part.

Part 5: Focuses on techniques for software verification and validation.Itincludes chapters on static

V

&

V,

testing and critical systems validation.

Part 6: This part covers a range of management topics: managing people, cost estimation, quality management, process improvement and configuration management.

Part 7: The final part includes three chapters that are devoted to important new technologies that are already starting to be used. The chapters cover security engineering, service-oriented software engineering and aspect-oriented software development.

In the introduction to each part, I discuss the structure and organisation in more detail.

Changes from the 7th edition

This new edition of my textbook can be thought of as a mid-life upgrade than a radical new revision of the book. I have designed it to be completelycompatible with the 7th edition but have included a new section on Emerging Technologies.

This discusses recent developments which I believe are significant for the future of software engineering. This section includes three additional chapters:

30. Security engineeringwhere I discuss issues of how to ensure that your soft- ware is secure and can resist external attacks.

31. Service-oriented software engineering where I describe new approaches to application development using reusable web services.

32. Aspect-oriented software developmentwhere I introduce a new technique of software development based around the separation of concerns.

As the other chapters in the book are still current and relevant, I have not mod- ified these, apart from very small changes to link to the new material in Chapters 30-32. More information on changes and the differences between the 6th and 7th editions is available from the book website.

x

Preface

Readership

The book is aimed at students taking undergraduate and graduate courses and at software engineers in commerce and industry.

It

may be used in general software engineering courses or in courses such as advanced programming, software specifica- tion, and software design or management. Software engineers in industry may find the book useful as general reading and as a means of updating their knowledge on particular topics such as requirements engineering, architectural design, dependable systems development and process improvement. Wherever practicable, the examples in the text have been given a practical bias to reflect the type of applications that software engineers must develop.

Using the book for teaching

The book is widely used in a range of software engineering courses and, if you already use the 7th edition, then you will find this edition to be completely compatible with it. I have deliberately left Chapters I to 29 of the 7th edition unchanged. If you use these in your teaching, there is no need to change any of your supplementary material or associa:ted coursework. The new chapters are stand-alone chapters and you may wish to introduce one or more of them to give students an understanding of new developments in the subject.

I have designed the book so that it can be used in three types of software engineering course:

1.

General introductory courses in software engineering For students who have

no previous software engineering experience, you can start with the introductory section, then pick and choose chapters from the other sections of the book.

This will give students a general overview of the subject with the opportunity of more detailed study for those students who are interested. If the course's approach is project-based, the early chapters provide enough material to allow students to get started on projects, consulting later chapters for reference and further information as their work progresses.

2. Introductory or intermediate courses on specific software engineering topics

The book supports courses in software requirements specification, software design,

software engineering management, dependable systems development and soft-

ware evolution. Each part can serve as a text in its own right for an introductory

or intermediate course on that topic. As well as further reading associated with

each chapter, I have also included information on other relevant papers and books

on the web site.

Web pages

Preface xi

3. More advanced courses in specific software engineering topics The chapters

can form a foundation for a specific software course, but they must be sup- plemented with further reading that explores the topic in greater detail. For example, I teach an MSc module in systems engineering that relies on material here. I have included details of this course and a course on critical systems engineering on the web site.

The benefit of a general text like this is that it can

be

used in several related courses. The text can be used in art introductory software engineering course and in courses on specification, design artd critical systems. Courses on component-based software engineering and systems engineering use the book along with additional papers that are distributed to students. Having a single text presents students with a consistent view of the subject-and they don't have to buy several books.

To reinforce the student's learning experience, I have included a glossary of key terms, with additional definitions on the web site. Furthermore, each chapter has:

a clearly defined set of objectives set out on the first page;

a list of key points covered in the chapter;

suggested further reading-eilher books that are currently in print or easily available papers (lists of other suggested readings and links can be found on my web site);

exercises, including design exercises.

The Software Engineering Body of Knowledge project (http://www.swebok.org) was established to define the key technical knowledge areas that are relevant to pro- fessional software engineers. These are organised under 10 headings: requirements, design, construction, testing,

maint~:nance,

configuration management, management, process.. tools and methods, and quality. While it would

be

impossible to cover all of the knowledge areas proposed by the SWEBOK project in a single textbook, all of the top-level areas are discussed in this book.

The publishers web site that is associated with the book is:

http://www.pearsoned.co.uk/sommerville

To support the use of this book in software engineering courses, I have included

a wide range of supplementary material on the web site.

If

you follow the Material

for Instructors links, you can find:

xii Preface

lecture presentations (PowerPoint and PDF) for all chapters in the book;

class quiz questions for each chapter;

case studies;

project suggestions;

course structure descriptions;

suggestions for further reading and links to web resources for each chapter;

solutions for a selection of the exercises associated with each chapter and for the quiz questions (available to instructor's only).

My own web site, includes all of the material on the publishers web site plus extensive supplementary material on software engineering such as links to other sites, invited lectures that I have presented, teaching material that I have developed for related courses such as Systems Engineering and the web sites of previous editions of

Software Engineering. The URL of this site is:

http;//www.software-engin.com

It

has been my policy, both in the previous edition and in this edition, to keep the number of web links in the book to an absolute minimum. The reason for this is that these links are subject to change and, once printed, it is impossible to update them. Consequently, the book's web page includes a large number of

links

to resources and related material on software engineering. If you use these and find problems, please let me know and I will update the links.

I

welcom~

your constructive commentsJUldsl:!ggestioDubolluhpvOOountl.tbp,.we

^h

site. You can contact me at ian@software-engin.com. I recommend that you include [SE8] in the subject of the e-mail message to ensure that my spam filters do not accidentally reject your

mail.

I regret that I do not have time to help students with their homework, so please do not ask me how to solve any of the problems in the book.

Acknowledgements

A large number of people have contributed over the years to the evolution of this book

and I'd like to thank everyone (reviewers, students and book users who have e-mailed

me) who has commented on previous editions and made constructive suggestions

for change. The editorial and production staff at Pearson Education in England and

the US were supportive and helpful, and produced the book in record time. So thanks

to Simon Plumtree, Mary Lince, Ros Woodward, Keith Mansfield, Patty Mahtani,

Daniel Rausch, Carol Noble and Sharon Burkhardt for their help and support.

Preface xiii

As I write, I am about to leave Lancaster University for new challenges at St Andrews University in Scotland. I'd like to thank all of my current and pre- vious colleagues at Lancaster for their support and encouragement over the years as software engineering has evolved.

Finally, I'd like to thank my family who tolerated my absence when the book was being written and my frustration when the words were not flowing. A big thank- you to my wife Anne and daughters Ali and Jane for their help and support.

Ian Sommerville,

February 2006

Preface

vii

Part

1

Overview

Chapter 1 Introduction

1.1 FAQs about software engineering 1.2 Professional and ethical responsibility Key Points

Further Reading Exercises

Chapter 2 Socio-technical systems

2.1 Emergent system properties 2.2 Systems engineering

2.3 Organisations, people and computer systems 2.4 legacy systems

Key Points Further Reading Exercises

1

3

5 14

17 18 18

20

23 25 34 38 40

41 41

Contents xv

Critical systems 43

3.1

A simple safety-critical system

46

3.2

System dependability

47

3.3

Availability and reliability

51

3.4

Safety

55

3.5

Security

58

Key Points 60

Further Reading

61

Exercises

61

~

SoftNvare processes 63

4.1

Software process models

65

4.2

Process iteration

71

4.3

Process activities

74

4.4

The Rational Unified Process

82

4.5

Computer-Aided Software Engineering

85

Key Points

89

Further Reading

90

Exercises

91

Project management 92

5.1

Management activities

94

5.2

Project planning

96

5.3

Project scheduling

99

5.4

Risk management

104

Key Points

111

Further Reading

112

Exercises

112

Requirements

Software requirements

6.1 Functional and non-functional requirements 6.2 User requirements

6.3 System requirements 6.4 Interface specification

6.5 The software requirements document Key Points

Further Reading Exercises

Requirements engineering processes

7.1 Feasibility studies

7.2 Requirements elicitation and analysis 7.3 Requirements validation

7.4 Requirements management Key Points

Further Reading Exercises

System models

8.1 Context models 8.2 Behavioural models 8.3 Data models 8.4 Object models 8.5 Structured methods Key Points

Further Reading Exercises

Chapter 9 Critical systems specification

9.1 Risk-driven specification 9.2 Safety specification 9.3 Security specification

9.4 Software reliability specification Key Points

Further Reading Exercises

Chapter 10 Formal specification

10.1 Formal specification in the software process 10.2 Sub-system interface specification

10.3 Behavioural specification Key Points

Further Reading Exercises

Part 3 Design

Chapter 11 Architectural design

11.1 Architectural design decisions 11.2 System organisation

11.3 Modular decomposition styles 11.4 Control styles

11.5 Reference architectures Key Points

Further Reading Exercises

Chapter 12 Distributed systems architectures

12.1 Multiprocessor architectures

Contents xvii

193

195 202 204 207 213 214 214

217

219 222 229 236 236 237

239

241

245 247 252 256 260 263 264 264

266

269

12.2 Client-server architectures 12.3 Distributed object architectures

12.4 Inter-organisational distributed computing Key Points

Further Reading Exercises

Application architectures

13.1 Data processing systems 13.2 Transaction processing systems 13.3 Event processing systems 13.4 Language processing systems Key Points

Further Reading Exercises

Object-oriented design

14.1 Objects and object classes 14.2 An object-oriented design process 14.3 Design evolution

Key Points Further Reading Exercises

Real-time software design

15.1 System design

15.2 Real-time operating systems 15.3 Monitoring and control systems 15.4 Data acquisition systems Key Points

Further Reading Exercises

Contents ^xix

Chapter 16 User interface design 362

16.1 Design issues 366

16.2 The UI design process 376

16.3 User analysis 378

16.4 User interface prototyping 381

16.5 Interface evaluation 383

Key Points 385

Further Reading 386

Exercises 386

Part 4 Development 389

Chapter 17 Rapid software development 391

17.1 Agile methods 396

17.2 Extreme programming 398

17.3 Rapid application development 405

17.4 Software prototyping 409

Key Points 412

Further Reading 413

Exercises 414

Chapter 18 Software reuse 415

18.1 The reuse landscape 418

18.2 Design patterns 421

18.3 Generator-based reuse 423

18.4 Application frameworks 426

18.5 Application system reuse 428

Key Points 437

Further Reading 437

Exercises 438

xx Contents

Chapter

19

Component-based software engineering

19.1 Components and component models 19.2 The CBSE process

19.3 Component composition Key Points

Further Reading Exercises

Chapter 20 Critical systems development

20.1 Dependable processes 20.2 Dependable programming 20.3 Fault tolerance

20.4 Fault-tolerant architectures Key Points

Further Reading Exercises

Chapter

21

Software evolution

21.1 Program evolution dynamics 21.2 Software maintenance 21.3 Evolution processes 21.4 Legacy system evolution Key Points

Further Reading Exercises

Part 5 Verification and Validation

Chapter 22 Verification and validation

22.1 Planning verification and validation 22.2 Software inspections

22.3 Automated static analysis 22.4 Verification and formal methods Key Points

Further Reading Exercises

Software testing

23.1 System testing 23.2 Component testing 23.3 Tes1 case design 23.4 Tes1 automation Key Points

Further Reading Exercises

Critical systems validation

24.1 Reliability validation 24.2 Safety assurance 24.3 Security assessment

24.4 Safety and dependability case's Key Points

Further Reading Exercises

Management

Managing people

25.1 Selecting staff 25.2 Motivating people 25.3 Managing groups

25.4 The People Capability Maturity Model

Contents ^xxi

527 530 535 535 536

537

540 547 551 561 563 564 565

566

568 574 581 583 586 587 587

591

593 596 599 607

xxii Contents

Key Points 610

Further Reading 610

Exercises 611

Chapter 26 Software cost estimation 612

26.1 Software productivity 614

26.2 Estimation techniques 620

26.3 Algorithmic cost modelling 623

26.4 Project duration and staffing 637

Key Points 638

Further Reading 639

Exercises 639

Chapter 27 Quality management 641

27.1 Process and product quality 644

27.2 Quality assurance and standards 645

27.3 Quality planning 652

27.4 Quality control 653

27.5 Software measurement and metrics 655

Key Points 663

Further Reading 663

Exercises 664

Chapter 28 Process improvement 665

28.1 Process and product quality 667

28.2 Process classification 669

28.3 Process measurement 672

28.4 Process analysis and modelling 673

28.5· Process change 678

28.6 The CMMI process improvement framework 680

Key Points 687

Further Reading Exercises

Configuration management

29.1 Configuration management plclnning 29.2 Change management

29.3 Version and release management 29.4 System building

29.5 CASE tools for configuration management Key Points

Further Reading Exercises

Emerging Technologies

Security engineering

30.1 Security concepts 30.2 Security risk management 30.3 Design for security 30.4 System survivability Key Points

Further Reading Exercises

Service-oriented software e:ngineering

31.1 Services as reusable components 31.2 Service engineering

31.3 Software development with services Key Points

Further Reading Exercises

Contents xxiii

687 688

689

692 695 698 705 706 711 711 712

715

717

720 722 727 737 741 742 742

743

747 751 760 768 768 769

Aspect-oriented software development

32.1 The separation of concerns 32.2 Aspects, join points and pointcuts 32.3 Software engineering with aspects Key Points

Further Reading Exercises

Glossary References Index

770

772 776

780

792 792 793

794

806

824

Supporting resources

Visitwww.pearsoned.co.uklsomnerville to find valuable online resources companion Websitefor

s1udents and instructors

• Lecture presentations (in PowerPoint and PDF) for all chapters in the book

• dass quiz questions for each chapter

• case studies

• Project suggestions

• Suggestions for further reading and links to web resources for each chapter

For instructors

only

• Course structure descriptions

• Solutions for a selection of the exercises associatedwith each chapter and for the quiz questions

For more information please contact your local Pearson Education sales representative or visit www.pearsoned.co.uk/3OI1II11eI.Vi11e

The basic structure of this book follows the essential software processes of specifica- tion, design, development verification and validation, and management. However rather than plunge immediately into these topics, I have included this overview section so that you can get a broad picture of the discipline. The chapters in this part are:

Chapter 1 is a general introduction to software engineering. To make this accessi- ble and easy to understand, I have organised it using a question/answer structure where I pose and answer questions such as 'what is software engineering'. I also introduce professionalism and ethics in this chapter.

Chapter 2 introduces socio-technical systems, a topic that I believe is absolutely essen- tial for software engineers. Software is never used on its own but always as part of some broader system including hardware, people and, often, organisations. These profoundly affect the software requirements and operation. In this chapter I cover the emergent system properties, systems engineering processes and some of the ways in which organisational and human concerns affect software systems.

Chapter

3

discusses 'critical systems'. Critical systems are systems where failure has severe technical, economic or human consequences, and where system safety, secu- rity and availability are key requirements. Chapters on aspects of critical systems are included in each part of the book. In this chapter, I also introduce the first of the running case studies in the book-the software for an insulin pump used in the treat- ment of diabetic patients.

The first three chapters set the scene for software engineering and Chapter

4

con- tinues this by introducing software process and software process models. I intro- duce basic software engineering processes, the subject of the book, in this chapter.

I also briefly discuss the Rational Unified Process, which is geared to object-oriented system development. The final section of the chapter discusses how software pro- cesses can be supported with automated software tools.

Chapter

5

introduces project management. Project management is part of all pro-

fessional development projects and

I

describe basic project planning, scheduling and

risk estimation here. Students in a software engineering course involved

in

a stu-

dent project should find the information they need here to draw up bar charts for

a project schedule and resource allocation.

1

Introduction

Objectives

The objectives of this chapter are to introduce software engineering and to provide a framework for understanding the rest of the book. When you have read this chapter, you will:

• understand what softViare engineering is and why it is important;

it know the answers to key questions that provide an introduction to software engineering;

• understand some ethical and professional issues that are important for software engineers

Contents

1.1 FAQs about software engineering 1.2 Professional and ethical responsibility

roduction

Virtually all countries now depend on complex computer-based systems. National infrastructures and utilities rely on computer-based systems and most electrical prod- ucts include a computer and controlling software. Industrial manufacturing and dis- tribution is completely computerised, as is the financial system. Therefore, producing and maintaining software cost-effectively is essential for the functioning of national and international economies.

Software engineering is an engineering discipline whose focus is the cost- effective development of high-quality software systems. Software is abstract and intangible.Itis not constrained by materials, or governed by physical laws or by manufacturing processes. In some ways, this simplifies software engineering as there are no physical limitations on the potential of software. However, this lack of nat- ural constraints means that software can easily become extremely complex and hence very difficult to understand.

The notion of software engineering was first proposed in 1968 at a conference held to discuss what was then called the 'software crisis'. This software crisis resulted directly from the introduction of new computer hardware based on integrated cir- cuits. Their power made hitherto unrealisable computer applications a feasible proposition. The resulting software was orders of magnitude larger and more com- plex than previous software systems.

Early experience in building these systems showed that informal software devel- opment was not good enough. Major projects were sometimes years late. The soft- ware cost much more than predicted, was unreliable, was difficult to maintain and performed poorly. Software development was in crisis. Hardware costs were tum- bling whilst software costs were rising rapidly. New techniques and methods were needed to control the complexity inherent in large software systems.

These techniques have become part of software engineering and are now widely used. However, as our ability to produce software has increased, so too has the com- plexity of the software systems that we need. New technologies resulting from the convergence of computers and communication systems and complex graphical user interfaces place new demands on software engineers. As many companies still do not apply software engineering techniques effectively, too many projects still pro- duce software that is unreliable, delivered late and over budget.

I think that we have made tremendous progress since 1968 and that the devel- opment of software engineering has markedly improved our software. We have a much better understanding of the activities involved in software development. We have developed effective methods of software specification, design and implemen- tation. New notations and tools reduce the effort required to produce large and com- plexsystems.

We know now that there is no single 'ideal' approach to software engineering.

The wide diversity of different types of systems and organisations that use these systems means that we need a diversity of approaches to software development.

However, fundamental notions of process and system organisation underlie all of these techniques, and these are the essence of software engineering.

1.1 II FAQs about software engineering 5

Software engineers can be righl1y proud of their achievements. Without com- plex software we would not have explored space, would not have the Internet and modem telecommunications, and all forms of travel would be more dangerous and expensive. Software engineering has contributed a great deal, and I am convinced that, as the discipline matures, its contributions in the 21 st century will be even greater.

1.1 FAQs about software lengineering

This section is designed to answer some fundamental questions about software engi- neering and to give you some impression of my views of the discipline. The for- mat that I have used here is the 'FAQ (Frequently Asked Questions) list'. This approach is commonly used in Internet news.groups^Ito provide newcomers with answers to frequently asked questions. I think that it is a very effective way to give a succinct introduction to the subject of software engineering.

Figure 1.1 summarises the answ,ers to the questions in this section.

1.1.1

What is software?

Many people equate the term software with computer programs. However, I prefer a broader definition where software is not just the programs but also all associated doc- umentatlon and configuration data that is needed to make these programs operate cor- rectly. A software system usually consists of a number of separate programs, configuration files, which are used to set up these programs, system documentation, which describes the structure of the system, and user documentation, which explains how to use the system and web sites for users to download recent product information.

Soft\\iare engineers are concerned with developing software products, i.e., soft- ware which can be sold to a customer. There are two fundamental types of software product

1. Generic productsThese are stand-alone systems that are produced by a devel- opment organisation and sold on the open market to any customer who is able to buy them. Examples of this type of product include software for pes such as databases, word processors, drawing packages and project management tools.

2. CuslOmised (or bespoke) productsThese are systems which are commissioned by a particular customer. A software contractor develops the software especially for that customer. Examples of this type of software include control systems for electronic devices, systems written to support a particular business process and air traffic control systems.

6 Chapter 1 D Introduction

Question Answer

What is software7

What is software engineering?

What is the difference between software engineering and computer science?

What is the difference between software engineering and system engineering?

What is a software process?

What is a software process model?

What are the costs of software engineering?

What are software engineering methods?

What is CASE (Computer-Aided Software Engineering)?

What are the attributes of good software?

What are the key challenges facing software engineering?

Computer programs and associated documentation. software products may be developed for a particular customer or maybedeveloped for a general market

Software engineering is an engineering discipline which is concerned with all aspects of software production.

Computer science is concerned with theory and fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software.

System engineering is concerned with all aspects of computer-based systems development, including hardware, software and process engineering. Software engineering is part of this process.

A set of activities whose goal is the development or evolution of software.

A simplified representation of a software process, presented from a specific perspective.

Roughly 60% of costs are development costs, 40% are testing costs. For custom software, evolution costs often exceed development costs.

Structured approaches to software development which include system models, notations, rules, design advice and process guidance.

Software systems which are intended to provide automated support for software process activities. CASE systemsare often used for method support.

The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable.

Coping with increasing diversity, demands for reduced delivery times and developing trustworthy software.

Figure 1.1 Frequently asked questions about software engineering

An

important difference between these types of software is that, in generic prod- ucts, the organisation that develops the software controls the software specification.

For custom products, the specification is usually developed and controlled by the organisation that is buying the software. The software developers must work to that specification.

However, the line between these types of products is becoming increasingly blurred.

More and more software companies are starting with a generic system and custQmising it to the needs of a particular customer. Enterprise Resource Planning (ERP) sys- tems, such as the SAP system, are the best examples of this approach. Here, a large and complex system is adapted for a company by incorporating information about business rules and processes, reports required, and so on.

1.1 8 FAQs about software engineering 7

1.1.2

What is software engineering?

Software engineering is an engineeling discipline that is concerned with all aspects of software production from the eady stages of system specification to maintaining the system after it has gone into use. In this definition, there are two key phrases:

1. Engineering discipline Engineers make things work. They apply theories, meth- ods and tools where these are appropriate,. but they use them selectively and always tryto discover solutions to problems even when there are no applicable theories and methods. Engineers also recognise that they must work to organisational and financial constraints, so they look for solutions within these constraints.

2. All aspects of software production Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, meth- ods and theories to support software production.

In general, software engineers adopt a systematic and organised approach to their work, as this is often the most effective way to produce high-quality software. However, engineering is all about selecting the most appropriate method for a set of circum- stances ,md a more creative, less fOlmal approach to development may be effective in some circumstances. Less formal development is particularly appropriate for the development of web-based systems. which requires a blend of software and graph- ical design skills.

1.1.3

What's the difference between software engineering and computer science?

- - - -

Essentially, computer science is concerned with the theories and methods that under- lie computers and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer sci- ence is (~ssential for software engineers in the same way that some knowledge of physicsISessential for electrical engineers.

Ideally, all of software engineering should be underpinned by theories of com- puter science, but in reality thisIS not the case. Software engineers must often use ad hocapproaches to developing the software. Elegant theories of computer science cannot always be applied to real, complex problems that require a software solution.

1.1.4

What is the difference betwE!en software engineering and system

engi~~ring?

_

System engineering is concerned wilth all aspects of the development and evolution of complex systems where software plays a major role. System engineering is there- fore concerned with hardware development, policy and process design and system

8 Chapter 1 • Introduction

deployment as well as software engineering. System engineers are involved in spec- ifying the system, defining its overall architecture and then integrating the different parts to create the finished system. They are less concerned with the engineering of the system components (hardware, software, etc.).

System engineering is an older discipline than software engineering. People have been specifying and assembling complex industrial systems such as aircraft and chem- ical plants for more than a hundred years. However, as the percentage of software in systems has increased, software engineering techniques such as use-case mod- elling and configuration management are being used in the systems engineering pro- cess. I discuss system engineering in Chapter 2.

1.1.5 What is a software process?

A software process is the set of activities and associated results that produce a soft- ware product. There are four fundamental process activities (covered later in the book) that are common to all software processes. These are:

1. Software specification

where customers and engineers define the software to be produced and the constraints on its operation.

2. Software development

where the software is designed and programmed.

3. Software validation

where the software is checked to ensure that it is what the customer requires.

4. Software evolution

where the software is modified to adapt it to changing cus- tomer and market requirements.

Different types of systems need different development processes. For example, real-time software in an aircraft has to be completely specified before development begins whereas, in e-commerce systems, the specification and the program are usu- ally developed together. Consequently, these generic activities may be organised in different ways and described at different levels of detail for different types of soft- ware. However, use of an inappropriate software process may reduce the quality or the usefulness of the software product to be developed and/or increase the develop- ment costs.

Software processes are discussed in more detail in Chapter 4, and the important topic of software process improvement is covered in Chapter 28.

1.1.6 What is a software process model?

A software process model is a simplified description of a software process that pre-

sents one view of that process. Process models may include activities that are part

of the software process, software products and the roles of people involved in soft-

1.1 /I FAQs about software engineering 9

ware engineering. Some examples of the types of software process model that may be produced are:

L A workflow model This shows the sequence of activities in the process along with their inputs, outputs and dependencies. The activities in this model rep- resent human actions.

2. A dataflow or activity model This represents the process as a set of activities, each of which carries out some data transformation. It shows how the input to the process, such as a specification, is transformed to an output, such as a design.

The activities here may represent transfOlmations carried out by people or by computers.

3. A role/action model This represents the roles of the people involved in the soft- ware process and the activities for which they are responsible.

Most software process models are based on one of three general models or paradigms of software development:

I. The waterfall approach Thistakl~Sthe above activities and represents them as separate process phases such as requirements specification, software design, imple- mentation, testing and so on. After each s,tage is defined it is 'signed-off, and development goes on to the following stage.

2. Iterative development This approach interleaves the activities of specification, development and validation. An initial system is rapidly developed from very abstract specifications. This is then refined with customer input to produce a system that satisfies the customer s needs. The system may then be delivered.

Altematively, it may be reimpkmented using a more structured approach to produce a more robust and maintainable system.

3. Component-based software engineering (CBSE) This technique assumes that parts of the system already exist. The system development process focuses on integrating these parts rather than developing them from scratch. I discuss CBSE in Chapter 19.

I return to these generic process models in Chapter 4 and Chapter 17.

1.1.7

What are the costs of softwalre engineering?

- - - - ' ' ' - - - -

There is 110simple answer to this question as the distribution of costs across the different activities in the software process depends on the process used and the type of software that is being develop«::d. For example, real-time software usually requires more extensive validation and testing than web-based systems. However,

10 Chapter 1 ^iJ Introduction

Weterfell model

o

25 50 75 ¹⁰⁰

Specification Design Development Integration and testing

Iteretlve development

o

25 50 75 ¹⁰⁰

Specification Iterative development System testing

Component-besed softwere engineering

0 2 5 5 0 75 ¹⁰⁰

Specification Development Integration and testing

Development end evolution costs for long-lifetime

o

100 200 300 400

System development System evolution

Figure 1.2 Software engineering activity cost distribution

each of the different generic approaches to software development has a different profile of cost distribution across the software process activities. If you assume that the total cost of developing a complex software system is 100 cost units then Figure 1.2 illustrates how these are spent on different process activities.

In the waterfall approach, the costs of specification, design, implementation and integration are measured separately. Notice that system integration and testing is the most expensive development activity. Normally, this is about 40% of the total development costs but for some critical systems it is likely to be at least 50% of the system development costs.

If the software is developed using an iterative approach, there is no hard line between specification, design and development. Specification costs are reduced because only a high-level specification is produced before development in this approach.

Specification, design, implementation, integration and testing are carried out in par- allel within a development activity. However, you still need an independent system testing activity once the initial implementation is complete.

Component-based software engineering has only been widely used for a short

time. We don't have accurate figures for the costs of different software develop-

ment activities in this approach. However, we know that development costs are reduced

Figure 1.3 Product development costs

1.1 • FAQs about software engineering 11

relative to integration and testing costs. Integration and testing costs are increased because you have to ensure that the components that you use actually meet their specification and work as expected with other components.

On top of development costs, costs are also incurred in changing the software after it has gone into use. The costs of evolution vary dramatically depending on the type of system. For long-lifetime software systems, such as command and con- trol syst,ems that may be used for 10 years or more, these costs are likely to exceed the development costs by a factor of 3 or 4, as illustrated in the bottom bar in Figure 1.3. However, smaller business sYi,tems have a much shorter lifetime and corre- spondingly reduced evolution costs.

These cost distributions hold for customised software that is specified by a cus- tomer and developed by a contractor. For software products that are (mostly) sold for pes, the cost profile is likely to be different. These products are usually devel- oped from an outline specification using an evolutionary development approach.

Specification costs are relatively low. However, because they are intended for use on a range of different configurations, they must be extensively tested. Figure 1.3 shows the type of cost profile that might be expected for these products.

The levolution costs for generic software products are particularly hard to esti- mate. In many cases, there is little formal evolution of a product. Once a version of the product has been released, work starts on the next release and, for market- ing reasons, this is likely to be prei,ented as a new (but compatible) product rather than as a modified version of a product that the user has already bought. Therefore, the evolution costs are not assessed separately as they are in customised software but are simply the development costs for the next version of the system.

1.1.8

What _are software engineering methods?

A software engineering method is a structured approach to software development whose aim is to facilitate the production of high-quality software in a cost-effective way. Methods such as Structured Analysis (DeMarco, 1978) and JSD (Jackson, 1983) were first developed in the 1970s. These methods attempted to identify the basic functional components of a system; function-oriented methods are still used. In the 1980s and 1990s, these function-oriented methods were supplemented by object- oriented

(00)

methods such as those proposed by Booch (Booch, 1994) and Rumbaugh (Rumbaugh, et al., 1991). These different approaches have now been integrated into a single unified approach built around the Unified Modeling Language (UML) (Booch, et al., 1999; Rumbaugh, et aI., 1999a; Rumbaugh, et al., 1999b).

o

25

IT _

^{50 75 100}

::.pecihcation . ueveTopnient ::.ystein testing

12 Chapter 1 !llI Introduction

Component DesCrIption Example

System model descriptions

Descriptionsofthe system models which should be developed and the notation usedtodefine these models.

Object models, data-flow models.

state machine models, etc.

Rules Constraints which always apply to system models. Every entity in a system model must have a unique name.

Recommendations Heuristics which characterise good design practice No object should have more than in this method. Following these recommendations seven sub-objeets associated should lead to a well-organised system model. with it

Process guidance Descriptions of the activities which may be followed to develop the system models and the organisation of these activities

Object attributes shouldbe documented before defining the operations associatedwithan object

Figure 1.4Method components

There is no ideal method, and different methods have different areas where they are applicable. For example, object-oriented methods are often appropriate for interactive systems but not for systems with stringent real-time requirements.

All methods are based on the idea of developing models of a system that may be represented graphically and using these models as a system specification or design.

Methods include a number of different components (Figure 1.4).

1.1.9

What is CASE?

The acronym CASE stands for Computer-Aided Software Engineering. Itcovers a wide range of different types of programs that are used to support software process activities such as requirements analysis, system modelling, debugging and testing. All methods now come with associated CASE technology such as editors for the nota- tions used in the method, analysis modules which check the system model according to the method rules and report generators to help create system documentation. Th CASE tools may also include a code generator that automatically generates source code from the system model and some process guidance for software engineers.

1.1.10

What are the attributes of good software?

As well as the services that it provides, software products have a number of other associated attributes that reflect the quality of that software. These attributes are not directly concerned with what the software does. Rather, they reflect its behaviour while it is executing and the structure and organisation of the source program and associated documentation. Examples of these attributes (sometimes called non- functional attributes) are the software s response time t9 a user query and the under- standability of the program code.

The specific set of attributes that you might expect from a software system obvi- ously depends on its application. Therefore, a banking system must be secure, an

Product charilcteristic Descripti Figure 1.5 Essential

attributes of good

software Maintainability

Dependability

Efficumcy

Usability

1.1 FAQs about software engineering 13

Software~;houldbe written in such a way thatitmay evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable consequence of a changing business environment Software dependability has a range of characteristics, including reliability, security and safety. Dependable software !ihould not cause physical or economic damage in the eVE,nt of system failure.

Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilisation,etc.

Software mustbeusable,withoutundue effort,bythetypeof user for ",hom it is designed. This means that it shouldhave an appropriate user interface and adequate documentation.

interactive game mustberesponsiv,e, a telephone switching system mustbereliable, and so on. These canbegeneralise:d into the set of attributes shown in Figure 1.5, which, I believe, are the essential characteristics of a well-designed software system.

1.1.11

What_are the key

challeng~s

facin.g software engineering?

Software engineering in the 21st century faces three key challenges:

1. The heterogeneity challengeIn~reasingly,systems are required to operate as dis- tributed systems across networks that include different types of computers and with different kinds of support systems. It is often necessary to integrate new software with older legacy systems written in different programming languages.

The heterogeneity challenge is the chall,enge of developing techniques for build- ing dependable software that is flexible enough to cope with this heterogeneity.

2. The delivery challenge Many traditional software engineering techniques are time-consuming. The time they take is reqUIred to achieve software quality.

However, businesses today must be responsive and change very rapidly. Their supporting software must char,ge equally rapidly. The delivery challenge is the challenge of shortening delivery times for large and complex systems without compromising system quality.

3. The trust challenge As software is inte:rtwined with all aspects of our lives, it is essential that we can trust mat software. This is especially true for remote software systems accessed through a web page or web service interface. The trust challenge is to develop techniques that demonstrate that software canbe trusted by its users.

14 Chapter 1 • Introduction

Of course, these are not independent. For example, it may be necessary to make rapid changes to a legacy system to provide it with a web service interface. To address these challenges, we will need new tools and techniques as well as innovative ways of combining and using existing software engineering methods.

1.2 Professional and ethical responsibility

Like other engineering disciplines, software engineering is carried out within a legal and social framework that limits the freedom of engineers. Software engineers must accept that their job involves wider responsibilities than simply the application of technical skills. They must also behave in an ethical and morally responsible way if they are to be respected as professionals.

It goes without saying that you should always uphold normal standards of honesty and integrity. You should not use your skills and abilities to behave in a dishonest way or in a way

that

will bring disrepute

to

the software engineering profession. However, there are areas where standards of acceptable behaviour are not bounded by laws but by the more tenuous notion of professional responsibility. Some of these are:

1. Confidentiality

You should normally respect the confidentiality of your employers or clients irrespective of whether a formal confidentiality agreement has been signed.

2. Competence

You should not misrepresent your level of competence. You should not knowingly accept work that is outside your competence.

3. Intellectual property rights

You should be aware of local laws governing the use of intellectual property such as patents and copyright. You should be care- ful to ensure that the intellectual property of employers and clients is protected.

4. Computer misuse

You should not use your technical skills to misuse other peo- ple's computers. Computer misuse ranges from relatively trivial (game play- ing on an employer s machine, say) to extremely serious (dissemination of viruses).

Professional societies and institutions have an important role to play in setting ethical standards. Organisations such as the ACM, the IEEE (Institute of Electrical and Electronic Engineers) and the British Computer Society publish a code of pro- fessional conduct or code of ethics. Members of these organisations undertake to follow that code when they sign up for membership. These codes of conduct are generally concerned with fundamental ethical behaviour.

The ACM and the IEEE have cooperated to produce a joint code of ethics and

professional practice. This code exists in both a short form, shown in Figure 1.6,

and a longer form (Gotterbam, et al., 1999) that adds detail and substance to the

1.2 Professional and ethical responsibility 15

Software Enslneerin, Code 0'1 Ethics and Professional Pradlce

ACM/IEEE-CS Joint Task Force on Software Engineering Ethic!; and Professional Practices PREAMBLE

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of hovv these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious;

without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall cc,mmit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respeCIted profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC - Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best interests of their client and employer consi!>1ent with the public interest.

3. PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standilrds possible.

4. JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT - Software engineering managers and leclders shall subscribe to and promote an ethical approach to the management of software development imd maintenance.

6. PROFESSION - Software engineers shall advance the intl!grity and reputation of the profession consistent with the public interest.

7. COLLEAGUES - Software e,ngineers shall be fair to and supportive of their colleagues.

8. SELF - Software engineers shall participate in lifelong leClming regarding the practice of their profession and shall promote an ethkal approach to the practice of the profession.

Figure 1.6ACM/IEEE Code of Ethics (©IEEE/ACM 1999)

shorter version. The rationale behind this code is summarised in the first two para- graphs of the longer form:

Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Software engineers are those who contribute by direct participation or by teaching, to the analysis, spe - ification, design, development, certification, maintenance and testing ofsoftware systems. Because of their roles in developing software systems, software engi- neers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. To ensure, as much as possible. thaI their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. In accordance with that commitment, software engi- neers shall adhere to the following Code of Ethics and Professional Practice.

The Code contains eight Principles relau,d to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of