Software Engineering for Students ppt

Douglas Bell A Programming Approach fourth edition for Students Engineering for Students Software Software “Bell covers the main areas of software engineering with accuracy and authority, and without getting bogged down in superfluous detail My students actually like this book; it's very readable.” Engineering Software Engineering Martin Bush, South Bank University ● Pragmatic, non-mathematical approach ● Self-test questions within each chapter help the reader to fully understand the concepts ● Numerous exercises are provided at the end of each chapter ● Consistent use of the UML as a design notation ● Case studies used throughout ● fourth edition Features A Programming Approach This fully revised version of Douglas Bell’s Software Engineering: A Programming Approach continues to use the successful formula of the previous editions The author’s approach is to present the main principles, techniques and tools used in software engineering, one by one, chapter by chapter He provides the reader with the knowledge to select the appropriate techniques for the project in hand He builds on the reader’s experience of coding small-scale applications, and examines everything they will need to begin programming large-scale software systems This book is a unique introduction to software engineering for all students of computer science and its related disciplines It is also ideal for practitioners wishing to remain current with new developments in the area An accompanying website with even more teaching and learning resources Douglas Bell is a lecturer at Sheffield Hallam University in the UK He has authored and co-authored a number of texts, including the best-selling Java for Students Douglas Bell an imprint of www.pearson-books.com Douglas Bell Software Engineering for Students for Students A Programming Approach fourth edition BELL_A01.QXD 2/2/05 3:20 PM Page i Software Engineering for Students BELL_A01.QXD 2/2/05 3:20 PM Page ii We work with leading authors to develop the strongest educational materials in computing, bringing cutting-edge thinking and best learning practice to a global market Under a range of well-known imprints, including Addison-Wesley, we craft high quality print and electronic publications which help readers to understand and apply their content, whether studying or at work To find out more about the complete range of our publishing, please visit us on the World Wide Web at: www.pearsoned.co.uk BELL_A01.QXD 2/2/05 3:20 PM Page iii Software Engineering for Students A Programming Approach Fourth Edition DOUGLAS BELL BELL_A01.QXD 2/2/05 3:20 PM Page iv Pearson Education Limited Edinburgh Gate Harlow Essex CM20 2JE England and Associated Companies throughout the world Visit us on the World Wide Web at: www.pearsoned.co.uk First published under the Prentice Hall imprint 1987 Second edition 1992 Third edition 2000 Fourth edition 2005 © Prentice Hall International 1987, 1992 © Pearson Education Limited 2000, 2005 The right of Douglas Bell to be identified as author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988 All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without either the prior written permission of the publisher or a licence permitting restricted copying in the United Kingdom issued by the Copyright Licensing Agency Ltd, 90 Tottenham Court Road, London W1T 4LP The programs in this book have been included for their instructional value They have been tested with care but are not guaranteed for any particular purpose The publisher does not offer any warranties or representations nor does it accept any liabilities with respect to the programs All trademarks used herein are the property of their respective owners The use of any trademark in this text does not vest in the author or publisher any trademark ownership rights in such trademarks, nor does the use of such trademarks imply any affiliation with or endorsement of this book by such owners ISBN 321 26127 British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library Library of Congress Cataloging-in-Publication Data Bell, Doug, 1944Software engineering for student/Douglas Bell 4th ed p cm Rev ed of: Software engineering 2000 ISBN 0-321-26127-5 Software engineering Computer programming I Bell, Doug, 1944Software engineering II Title QA76.758.B45 2005 005.1 dc22 2004062346 10 09 08 07 06 05 Typeset in 9.75/12pt Galliard by 71 Printed in Great Britain by Henry Ling Ltd, at the Dorset Press, Dorchester, Dorset The publisher’s policy is to use paper manufactured from sustainable forests BELL_A01.QXD 2/2/05 3:20 PM Page v Contents Preface xix Part A G Part B G 10 11 12 13 Part C G 14 15 16 17 18 Preliminaries Software – problems and prospects The tasks of software development The feasibility study Requirements engineering 22 30 36 Design 51 User interface design Modularity Structured programming Functional decomposition Data flow design Data structure design Object-oriented design Design patterns Refactoring 53 67 87 102 111 121 139 151 165 Programming languages The basics Object-oriented programming Programming in the large Software robustness Scripting 173 175 200 221 237 259 v BELL_A01.QXD 2/2/05 3:20 PM Page vi vi Contents Part D G Verification 19 Testing 20 Groups Part E G 21 22 23 24 25 26 27 Part F G Process models The waterfall model The spiral model Prototyping Incremental development Open source software development Agile methods and extreme programming The unified process Project management 28 Teams 29 Software metrics and quality assurance 30 Project management Part G G Review 31 Assessing methods 32 Conclusion Appendices A Case studies B Glossary C UML summary Bibliography Index 265 267 283 289 291 297 303 314 322 330 337 345 347 357 370 383 385 392 405 407 411 412 417 419 BELL_A01.QXD 2/2/05 3:20 PM Page vii Detailed contents Preface xix Part A G Software – problems and prospects 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11 Preliminaries Introduction Meeting users’ needs The cost of software production Meeting deadlines Software performance Portability Maintenance Reliability Human–computer interaction A software crisis? A remedy – software engineering? Summary Exercises Answers to self-test questions Further reading 3 10 10 11 11 13 16 16 17 18 19 20 20 The tasks of software development 22 2.1 2.2 2.3 2.4 2.5 22 23 26 27 28 28 28 29 Introduction The tasks Process models Methodology Hacking Summary Exercises Answer to self-test question vii BELL_A01.QXD 2/2/05 3:20 PM Page viii viii Detailed contents 30 3.1 3.2 3.3 3.4 3.5 3.6 The feasibility study 30 31 31 32 32 34 34 34 35 35 Introduction Technical feasibility Cost-benefit analysis Other criteria Case study Discussion Summary Exercises Answers to self-test questions Further reading Requirements engineering 36 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 36 37 38 40 41 42 45 46 47 47 48 49 Part B G Introduction The concept of a requirement The qualities of a specification How to elicit requirements The requirements specification The structure of a specification Use cases Use case diagrams Summary Exercises Answers to self-test questions Further reading Design 51 User interface design 53 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 53 54 54 56 57 60 62 63 64 64 Introduction An inter-disciplinary field Styles of human–computer interface Different perspectives on user interface design Design principles and guidelines Interface design Case study Help systems Summary Exercises BELL_A01.QXD 2/2/05 3:20 PM Page ix Detailed contents Answers to self-test questions Further reading ix 65 65 67 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 6.11 Modularity 67 68 70 70 73 74 76 77 79 82 84 84 85 85 86 Structured programming 7.1 7.2 7.3 7.4 7.5 Introduction Why modularity? Component types Component size and complexity Global data is harmful Information hiding Coupling and cohesion Coupling Cohesion Object-oriented programming Discussion Summary Exercises Answers to self-test questions Further reading Introduction Arguments against goto Arguments in favor of goto Selecting control structures What is structured programming? Summary Exercises Answer to self-test question Further reading 87 87 89 92 94 96 98 99 100 101 Functional decomposition 102 8.1 8.2 8.3 102 103 107 109 109 110 110 Introduction Case study Discussion Summary Exercises Answer to self-test question Further reading BELL_Z02.QXD 1/30/05 4:32 PM Page 410 Appendix A I Case studies 410 I year I borrower identification (if on loan) I date of issue (if on loan) The computer should be able to store information on up to 100,000 books The computer system should provide facilities to: I issue a book to a borrower I receive a book returned by a borrower I create information about a newly acquired book I display a list of the books on loan to a particular borrower The facilities should be accessible via a GUI The computer must respond within one second to any request The system should provide a search facility to find out whether the library possesses a particular book With suitable security precautions, the system will initialize the library information so that it contains zero books When a book becomes overdue, the system should display appropriate information The system should provide secure access by only the library staff The software must be delivered by such-and-such a date and cost no more than $100,000 It must be fully documented and easy to maintain A.5 G Patient monitoring system This is an example of a safety-critical system Other similar systems include a control system for a power station and a fly-by-wire system for an airplane A computer system monitors the vital signs of a patient in a hospital Sensors attached to a patient continually send information to the computer: I heart rate I temperature I blood pressure Some of the readings require conversion to useful units of measurement (e.g micro volts into degrees centigrade) The computer displays the information on a screen It also logs the information in a file that can be retrieved and displayed If any of the vital signs exceed safe limits, the screen flashes a warning and an alarm sounds The limits have default values, but can also be changed by the operator If a sensor fails, the screen flashes a warning and the alarm sounds BELL_Z03.QXD 1/30/05 4:33 PM Page 411 APPENDIX B Glossary Within the field of software engineering, different people use terms differently The following are the meanings of terms as used in this book development approach – a particular collection of tools, methods and work styles that are used in carrying out software development development life cycle – the complete process of software development from inception through to release and maintenance of the product development process – specific activities that are carried out during software development maintenance – fixing bugs, responding to changed requirements and upgrading the software for a new platform method – the term for a procedure, subprogram or subroutine methodology the study of methods, or a collection of methods, techniques and notations used for software development portability the degree to which a piece of software runs on different platforms (machine and/or operating system), or the issue of whether software needs to run on different platforms porting – moving a piece of software to a new platform process model – idealized plan of software development in general, or an analysis of the approach adopted for a particular software development project BELL_Z04.QXD 1/30/05 4:33 PM Page 412 APPENDIX C UML summary The Unified Modeling Language (UML) is a graphical notation for describing objectoriented software It is not a method for design, but a notation that can help with designing software or help to document software once it is complete This appendix gives a summary of those aspects of UML used in this book UML is a large and potentially complex notation and therefore we have only used a part of the notation Thus the diagrams described and used in this book are: I use case diagrams I class diagrams I package diagrams I activity diagrams C.1 G Use case diagrams These diagrams describe, in outline, the use cases associated with a system Figure C.1 shows an example of a use case diagram for users of a bank ATM In this example there is a single type of user, a bank customer A customer can ask the system to carry out either of two functions – withdraw cash and check balance withdraw cash Bank Customer check balance Figure C.1 A use case diagram BELL_Z04.QXD 1/30/05 4:33 PM Page 413 C.2 Class diagrams C.2 G Class diagrams These describe classes and their interrelationships Classes are shown as rectangles containing the class name The simplest relationship is where a class uses another For example, in Figure C.2, class Game uses classes Defender, Alien, Laser and Bomb This means that Game creates objects from these classes and/or calls methods in objects created from these classes A class diagram can also show the inheritance relationships between classes – the subclasses and superclasses As illustrated in Figure C.3, to show that a class extends another, a line is drawn from the subclass to the superclass, with the arrowhead pointing to the superclass Thus Sprite is the superclass of both Alien and Bomb If a class is an abstract class, the name of the class is written in italics This can be difficult to see, particularly when hand-written So the name of an abstract class can be followed by the text {abstract} to clarify the meaning An interface is described in the same way as a class – as a box The difference is that the text precedes the name A class that implements an interface has a dashed line with an arrow leading to the interface box (see Figure C.4) A class can be described in more detail, as illustrated in Figure C.5 There are three compartments in this type of class diagram The first compartment holds the class Defender Alien Game Laser Bomb Figure C.2 Class diagram Sprite Alien Figure C.3 Class diagram showing inheritance Bomb 413 BELL_Z04.QXD 1/30/05 4:33 PM Page 414 Appendix C I UML summary 414 StackInterface Stack Figure C.4 A class and its interface The arrow should be hollow Game panel timer mouseMoved mouseClicked actionPerformed Figure C.5 Class diagram showing the detail of a class name, the second describes variables and the third describes methods Any class (static) variables or methods are shown underlined The visibility of an element can, optionally, be described in a prefix as in Java – public, private, protected or default In keeping with information hiding, the diagram is often drawn with the second compartment (the variables) omitted C.3 G Package diagrams A package can be diagrammed as shown in Figure C.6 It is a rectangle with a tab at the top that holds the package name Optionally, the classes within a package can be shown within the rectangle This shows a class util that consists of classes Random, ArrayList and Stack C.4 G Activity diagrams An activity diagram describes a sequence of activities Thus an activity diagram can be used to show the flow of control through software An activity diagram can show: I conditions (corresponding to if statements) I loops (corresponding to for and while statements) I concurrent activity (corresponding to threads) BELL_Z04.QXD 1/30/05 4:33 PM Page 415 C.4 Activity diagrams util Stack Random ArrayList Figure C.6 A package diagram An activity diagram can also be used to show a human activity, such as carrying out throwaway prototyping, Figure C.7 Actions are written in boxes with curved corners The sequence of actions is shown by the arrows A sequence starts with a special “blob” symbol A sequence ends with a different symbol, as shown Draw up an outline specification Construct prototype Check with user Refine prototype [User requires change] [User happy] Deliver the specification Figure C.7 Activity diagram showing throwaway prototyping 415 BELL_Z04.QXD 1/30/05 4:33 PM Page 416 416 Appendix C I UML summary This diagram also uses the diamond-shaped branch symbol Associated with each output from the branch is a condition (termed a guard) If the condition is true, the route is taken – just as in an if statement • Further reading Two very clear and readable books on UML are: Martin Fowler, UML Distilled, Addison-Wesley Perdita Stevens, and Rob Pooley, Using UML, Addison-Wesley BELL_Z05.QXD 1/30/05 4:34 PM Page 417 Bibliography References to books and websites are given at the end of each chapter This bibliography presents some general sources Dates are not given because new editions of them are produced frequently Software engineering Here are the major books on the subject: Ian Sommerville, Software Engineering, Addison-Wesley Carlo Ghezzi, Mehdi Jazayeri and Dino Mandrioli, Fundamentals of Software Engineering, Prentice Hall Hans van Vliet, Software Engineering: Principles and Practice, John Wiley Roger S Pressman, Software Engineering, a Practitioner’s Approach, McGraw-Hill The Software Engineering Institute at Carnegie Mellon University, USA, is a prestigious organization They publish articles on software engineering topics and were the instigators of the capability maturity model Their website is at: http://www.sei.cmu.edu/ UML Here are two short and simple books on UML: Martin Fowler, UML Distilled, Addison-Wesley Perdita Stevens and Rob Pooley, Using UML, Addison-Wesley BELL_Z05.QXD 1/30/05 4:34 PM Page 418 418 Bibliography Programmers – their lives and work There are several exciting accounts of the personal outlook and work methods of programmers They give insights into how programming is actually done They also contribute to the folklore of programming An example of a book on how programmers actually work In the book, she reports on interviews with notable programmers: Susan Lammers, Programmers at Work, Microsoft Press, 1986 Another really exciting book, which charts the lives of the early programmers: Steven Levy, Hackers: Heroes of the Computer Revolution, Anchor Books, 1994 This is a good read if you are interested in how software projects really get done and what life is like at Microsoft: G Pascal Zachary, Show-Stopper: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft, Free Press, 1994 This book describes the methods used at Microsoft: Michael A Cusumano and Richard W Selby, Microsoft Secrets, Free Press, 1995 BELL_Z06.QXD 1/30/05 4:34 PM Page 419 Index abstraction 99, 107 acceptance test 251, 332 activity diagrams 414 Ada 177, 189, 215, 233, 254, 393 adaptive maintenance 11 adversary team 275 agile manifesto 330 agile methods 330 Algol 68 393 anti-patterns 151, 161, 162 architecture 338 array list 206 arrays 194 assertions 253 assessing methods 385, 387 ATM case study 32, 45, 62, 154, 157, 158, 300, 341, 407 audit module 241 automated testing 275 automatic garbage collection 215 automation 398 backward error recovery 244 beta testing 275 bibliography 417 big-bang development 315 black box testing 269, 387 blob anti-pattern 161 Bohm, B 373 Booch, G 337 bottom-up implementation 317 boundary values 269, 271, 273 bounty hunter 275 breadth-first 107 Brooks, F.P 348, 377 bugs, estimating 361 C 176, 214, 225, 254 C++ 214, 225, 254, 393 C# 177, 189, 191, 196, 212, 223, 233 call by reference 188 call by value 188 Capability Maturity Model, see CMM case studies 407 casting 193 chief programmer teams 351 class 201 class diagram 143, 144, 170, 209, 228, 413 class programmer 353–4 classes, finding 142 class–responsibility–collaborator cards, see CRC cards CMM, 366 Cobol 176, 393 COCOMO 373 cohesion 79 command line interface 54 communication 333, 347 compile-time checking 240 complexity 70, 358 component programmer 353–4 component size 70 BELL_Z06.QXD 1/30/05 4:34 PM Page 420 420 Index component types 70 components 399 composition refactoring 168 control 397 control structures 94, 179 cost 5, 6, 9, 12 cost estimation 372 cost-benefit analysis 31 coupling 77 courage 333 CRC cards 145, 332 crisis 16 Crystal 330 cyberspace invaders case study 103, 140, 154, 158, 200, 408 mediator 158 model, view controller 157 observer, observable 157 Pipe and Filter 158 proxy 159 singleton 154 deskilling 92 desktop metaphor 56 Dijkstra, E.W 278 direct manipulation 56 division of labor 349 driver 276 DSDM 330 dynamic data structures 213 dynamic typing 191 dangling else 180 dangling pointer 215 data flow design 111 data flow diagram 112 data hiding 74 data structure design 121 data structure diagram 122 data structures 213 data typing 190 database design 26 deadlines 10 defensive programming 241 delegation design pattern 153 Deming, W.E 365 depth-first 107 design data flow 111 data structure 121 functional decomposition 102 of programming language 176 OOD 139 user interface 53 design patterns 151 delegation 153 faỗade 156 factory method 155 immutable 157 inheritance 152 layers 159 efficiency, see performance Eiffel 212 ego-less programming 284 Encapsulate Data refactoring 166 encapsulation 74, 200 enumerations 193 equivalence partitioning 270 error 9, 13, 268, 283 evolutionary prototyping 307 exception handling 245 exceptions 93, 245 exhaustive testing 269 exploratory programming 396 Extract Class refactoring 167 extreme programming 332 faỗade design pattern 156 factory method 155 failure 13 fault 9, 13, 237, 283, 361, 362 fault density 278, 361 fault detection 239, 242 fault intolerance 238 fault tolerance 238 FDD 330 feasibility study 30, 373 feedback 293, 333 filter and pipe pattern 115, 260, 394 flowchart 88 BELL_Z06.QXD 1/30/05 4:34 PM Page 421 Index fork 324 formal methods 276, 388, 399 Fortran 176, 177, 179, 240, 394 forward error recovery 244 Free Software Foundation 323 FSF 323 function point 373 functional decomposition 102 functional teams 351 functional testing 269 future 398, 400 game case study, see cyberspace invaders case study Gantt chart 376 garbage collection 215 gender 397, 400 generics 212 get access 203 global data 73, 78 glossary 411 GNU General Public License 323 GNU/HURD 322 GNU/Linux 325 goals of software engineering 17 good enough software 14 goto 87, 89, 92, 180, 185, 249 GPL 323 groups 283 GUI 55 hacking 28, 322, 396 has-a test for composition 170 Haskell 399 HCI, see user interface design heavyweight method 379, 330, 389 help systems 63 history 400 Hoare, C.A.R 241 human–computer interaction, see user interface design IBM 5, 10, 14 immutable design pattern 157 inception 371 incremental development 314 incremental testing 277 information hiding 74 inheritance 152, 168, 207 inheritance design pattern 152 inheritance refactoring 168 Inline Class refactoring 168 inspection 286 integration testing 272 interfaces 227 interoperability 229 introducing methods 390 invariant 253 investment appraisal 31 is-a test for inheritance 170 iteration 146, 301, 306, 308, 338, 341 Jacobson, I 337 Java 176, 200, 215, 224, 254, 393 JSP, see data structure design Layer design pattern 159, 316 library 145, 206, 394 library case study 409 lightweight method 330, 379, 389 lines of code, see LOC LISP 396, 399 LOC 358 maintenance 11 managing people 378 McCabe complexity measure 359 mean time to failure, see MTTF mediator design pattern 158 memory corruption 215 memory leak 215 mental model 56 menu 54 methodology 27 methods 186 metrics 357, 358, 386 Michael Jackson, see data structure design Microsoft 395 421 BELL_Z06.QXD 1/30/05 4:34 PM Page 422 422 Index Microsoft Project 376 middle-out implementation 318 milestone 376 millennium bug 13 model, view controller design pattern 157 modularity 67, 68 module interconnection language 227 monolithic testing 277 Move Data refactoring 167 Move Method refactoring 167 MTTF 362 multiple inheritance 212, 230 multiple interfaces 230 Murphy’s law 278 mutation testing 275 MySQL 322 nesting 181 n-version programming 252 object-oriented design, see OOD object-oriented programming, see OOP observer, observable design pattern 157 OO teams, 353 OOD 139 OOP 82, 200 open source development 322 Open Source Movement 323 open-closed principle 83 OpenOffice 322 orthogonality 177 OSM 323 overwork 334 package diagrams 414 packages 223 pair programming 286, 334 paralysis 371 parameters 188 Pascal 393 patient monitoring system case study 113, 229, 410 patterns 151 PDL 103 performance 10, 93 Perl 260, 322 person months 358, 372 Pert 376 pipe and filter design pattern 79, 133, 158 PL/1 177 planning 376 pointers 213 polymorphism 170, 209 polymorphism refactoring 170 portability 11 postcondition 253 precondition 253 primitive data types 190 process improvement 365 process model 23, 26, 27, 372 agile 330 extreme programming 332 incremental 314 open source 322 prototyping, 303 spiral, 297 unified process 337 waterfall, 291 productivity profiler 275 program design language 103 program structure chart 122 programming in the large 221 programming language 175, 393 project management 345, 370 project teams 351 properties 203, 205 prototyping 60, 303 evolutionary 307 rapid 308 throwaway 305 proximity 134 proxy design pattern 159 pseudo-code 103, 125 Python 259 BELL_Z06.QXD 1/30/05 4:34 PM Page 423 Index quality 18, 362 quality assurance 18, 275, 357, 364 quality factors 363 rapid prototyping 308 Raymond, E.S 324 records 195 recovery blocks 249 recovery points 244 refactoring 165, 334 composition 168 Encapsulate Data 166 Extract Class 167 inheritance 168 Inline Class 168 Move Data 167 Move Method 167 polymorphism 170 regression testing 275 reliability 13 remedial maintenance 11 repetition 183 requirements 4, 36, 303 requirements engineering 398 return on investment 31 reuse 69, 144, 309, 394, 399 risk 297 robustness 237 Rumbaugh, J 337 run-time checking 240 safety-critical systems 15 scheduling 376 scoping 226 scripting 259 SCRUM 330 selecting tools and methods 375 selection 180 separate compilation 232 set access 203 simplicity 176, 333 single inheritance 212 singleton design pattern 154 skill 397 SLOC, see LOC Smalltalk 308 software engineering 17 software quality 362 software tools xxi, 331, 392, 398 specification 305 spiral model 297 spreadsheet 376 Stallman, R 323 stepping 274 stepwise refinement 108 story 332 strong typing 191 structural testing 272 structure chart 115 structure clash 130 structured growth 396 structured programming 87, 98 structured walkthrough 284 structures 195 stub 315 syntax 178 system testing 277 tasks of software development 22 teams 347 chief programmer 351 functional 351 OO, 353 project 351 technical feasibility 31 templates 212 test bed 315 test-driven development 333 testing 24, 25, 267 black box 269 functional 269 integration 272 structural 272 system 277 unit 276 white box 272 throwaway prototyping 305 tools, see software tools top-down implementation 316 423 BELL_Z06.QXD 1/30/05 4:34 PM Page 424 424 Index Torvalds, L 325–6 trust 379 UML 337, 399, 412 activity diagrams 414 class diagrams 413 package diagrams 414 use case diagrams 36, 412 Unified Modeling Language, see UML unified process 337 unit testing 276 Unix 133, 259 UP, see unified process use case 45, 142, 319, 332, 338, 373 use case diagram 46, 412 user-defined types 193 user interface design 16, 53, 57, 60 users validation 5, 24, 303 verification 14, 24 267, 387 Visual Basic 176, 254 walkthrough 387 waterfall model 291 weak typing 191, 262 Weinberg, G 283 white box testing 272, 387 Wirth, N 175 word processor case study 46, 159, 408 XP, see extreme programming Z 276, 399 zero defect software 14 ... introduction to software engineering for students in undergraduate programs in Computer Science, Computer Studies, Information Technology, xix BELL_A01.QXD 2/2/05 3:20 PM Page xx xx Preface Software Engineering. .. Introduction Software Engineering is about methods, tools and techniques used for developing software This particular chapter is concerned with the reasons for having a field of study called software engineering, ... (e.g software for the Apollo moon shots) The latter is sometimes called bespoke software All these types of software – except perhaps information systems – fall within the remit of software engineering