Software Engineering 9th Edition PDF

 SOFTWARE ENGINEERING Ninth Edition Ian Sommerville Addison-Wesley Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delh...

 SOFTWARE ENGINEERING Ninth Edition Ian Sommerville Addison-Wesley Boston Columbus Indianapolis New York San Francisco Upper Saddle River Amsterdam Cape Town Dubai London Madrid Milan Munich Paris Montreal Toronto Delhi Mexico City São Paulo Sydney Hong Kong Seoul Singapore Taipei Tokyo Editorial Director: Marcia Horton Editor in Chief: Michael Hirsch Acquisitions Editor: Matt Goldstein Editorial Assistant: Chelsea Bell Managing Editor: Jeff Holcomb Senior Production Project Manager: Marilyn Lloyd Director of Marketing: Margaret Waples Marketing Coordinator: Kathryn Ferranti Senior Manufacturing Buyer: Carol Melville Text Designer: Susan Raymond Cover Art Director: Elena Sidorova Front Cover Photograph: © Jacques Pavlovsky/Sygma/Corbis Interior Chapter Opener: © graficart.net/Alamy Full-Service Project Management: Andrea Stefanowicz, GGS Higher Education Resources, a Division of PreMedia Global, Inc. Composition and Illustrations: GGS Higher Education Resources, a Division of PreMedia Global, Inc. Printer/Binder: Edwards Brothers Cover Printer: Lehigh-Phoenix Color/Hagerstown Copyright © 2011, 2006, 2005, 2001, 1996 Pearson Education, Inc., publishing as Addison-Wesley. All rights reserved. Manufactured in the United States of America. This publication is protected by copyright, and permission should be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. To obtain permission(s) to use material from this work, please submit a written request to Pearson Education, Inc., Permissions Department, 501 Boylston Street, Suite 900, Boston, Massachusetts 02116. Many of the designations by manufacturers and seller to distinguish their products are claimed as trade- marks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed in initial caps or all caps. Library of Congress Cataloging-in-Publication Data Sommerville, Ian Software engineering / Ian Sommerville. — 9th ed. p. cm. Includes index. ISBN-13: 978-0-13-703515-1 ISBN-10: 0-13-703515-2 1. Software engineering. I. Title. QA76.758.S657 2011 005.1—dc22 2009053058 10 9 8 7 6 5 4 3 2 1–EB–14 13 12 11 10 ISBN 10: 0-13-703515-2 ISBN 13: 978-0-13-703515-1  PREFACE As I was writing the final chapters in this book in the summer of 2009, I realized that software engineering was 40 years old. The name ‘software engineering’ was proposed in 1969 at a NATO conference to discuss software development problems— large software systems were late, did not deliver the functionality needed by their users, cost more than expected, and were unreliable. I did not attend that conference but, a year later, I wrote my first program and started my professional life in software. Progress in software engineering has been remarkable over my professional life- time. Our societies could not function without large, professional software systems. For building business systems, there is an alphabet soup of technologies—J2EE,.NET, SaaS, SAP, BPEL4WS, SOAP, CBSE, etc.—that support the development and deployment of large enterprise applications. National utilities and infrastructure— energy, communications, and transport—all rely on complex and mostly reliable computer systems. Software has allowed us to explore space and to create the World Wide Web, the most significant information system in the history of mankind. Humanity is now faced with a new set of challenges—climate change and extreme weather, declining natural resources, an increasing world population to be fed and housed, international terrorism, and the need to help elderly people lead satisfying and fulfilled lives. We need new technologies to help us address these problems and, for sure, software will play a central role in these technologies. Software engineering is, therefore, a critically important technology for the future of mankind. We must continue to educate software engineers and develop the disci- pline so that we can create more complex software systems. Of course, there are still problems with software projects. Software is still sometimes late and costs more than expected. However, we should not let these problems conceal the real successes in software engineering and the impressive software engineering methods and tech- nologies that have been developed. Software engineering is now such a huge area that it is impossible to cover the whole subject in one book. My focus, therefore, is on key topics that are fundamental iv Preface to all development processes and topics concerned with the development of reliable, distributed systems. There is an increased emphasis on agile methods and software reuse. I strongly believe that agile methods have their place but so too does ‘tradi- tional’ plan-driven software engineering. We need to combine the best of these approaches to build better software systems. Books inevitably reflect the opinions and prejudices of their authors. Some read- ers will inevitably disagree with my opinions and with my choice of material. Such disagreement 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 engi- neering students can find something of interest here. Integration with the Web There is an incredible amount of information on software engineering available on the Web and some people have questioned if textbooks like this one are still needed. However, the quality of available information is very patchy, information is sometimes presented badly and it can be hard to find the information that you need. Consequently, I believe that textbooks still have an important role to play in learning. They serve as a roadmap to the subject and allow information on method and techniques to be organized and presented in a coherent and readable way. They also provide a starting point for deeper exploration of the research literature and material available on the Web. I strongly believe that textbooks have a future but only if they are integrated with and add value to material on the Web. This book has therefore been designed as a hybrid print/web text in which core information in the printed edition is linked to supplementary material on the Web. Almost all chapters include specially written ‘web sections’ that add to the information in that chapter. There are also four ‘web chapters’ on topics that I have not covered in the print version of the book. The website that is associated with the book is: http://www.SoftwareEngineering-9.com The book’s web has four principal components: 1. Web sections These are extra sections that add to the content presented in each chapter. These web sections are linked from breakout boxes in each chapter. 2. Web chapters There are four web chapters covering formal methods, interaction design, documentation, and application architectures. I may add other chapters on new topics during the lifetime of the book. 3. Material for instructors The material in this section is intended to support peo- ple who are teaching software engineering. See the “Support Materials” section in this Preface. 4. Case studies These provide additional information about the case studies used in the book (insulin pump, mental health-care system, wilderness weather system)  Preface v as well as information about further case studies, such as the failure of the Ariane 5 launcher. As well as these sections, there are also links to other sites with useful material on software engineering, further reading, blogs, newsletters, etc. I welcome your constructive comments and suggestions about the book and the website. You can contact me at [email protected]. Please include [SE9] in the subject of your message. Otherwise, my spam filters will probably reject your mail and you will not receive a reply. I do not have time to help students with their homework, so please don’t ask. Readership The book is primarily aimed at university and college students taking introductory and advanced courses in software and systems engineering. Software engineers in the industry may find the book useful as general reading and as a means of updating their knowledge on topics such as software reuse, architectural design, dependability and security, and process improvement. I assume that readers have completed an introductory programming course and are familiar with programming terminology. Changes from previous editions This edition has retained the fundamental material on software engineering that was covered in previous editions but I have revised and updated all chapters and have included new material on many different topics. The most important changes are: 1. The move from a print-only book to a hybrid print/web book with the web mate- rial tightly integrated with the sections in the book. This has allowed me to reduce the number of chapters in the book and to focus on core material in each chapter. 2. Complete restructuring to make it easier to use the book in teaching software engineering. The book now has four rather than eight parts and each part may be used on its own or in combination with other parts as the basis of a software engineering course. The four parts are an introduction to software engineering, dependability and security, advanced software engineering, and software engi- neering management. 3. Several topics from previous editions are presented more concisely in a single chapter, with extra material moved onto the Web. 4. Additional web chapters, based on chapters from previous editions that I have not included here, are available on the Web. vi Preface 5. I have updated and revised the content in all chapters. I estimate that between 30% and 40% of the text has been completely rewritten. 6. I have added new chapters on agile software development and embedded systems. 7. As well as these new chapters, there is new material on model-driven engineer- ing, open source development, test-driven development, Reason’s Swiss Cheese model, dependable systems architectures, static analysis and model checking, COTS reuse, software as a service, and agile planning. 8. A new case study on a patient record system for patients who are undergoing treatment for mental health problems has been used in several chapters. Using the book for teaching I have designed the book so that it can be used in three different types of software engineering courses: 1. General introductory courses in software engineering The first part of the book has been designed explicitly to support a one-semester course in introductory software engineering. 2. Introductory or intermediate courses on specific software engineering topics You can create a range of more advanced courses using the chapters in Parts 2–4. For example, I have taught a course in critical systems engineering using the chapters in Part 2 plus chapters on quality management and configuration management. 3. More advanced courses in specific software engineering topics In this case, the chapters in the book form a foundation for the course. These are then supple- mented with further reading that explores the topic in more detail. For example, a course on software reuse could be based around Chapters 16, 17, 18, and 19. More information about using the book for teaching, including a comparison with previous editions, is available on the book’s website. Support materials A wide range of support material is available to help people using the book for teach- ing software engineering courses. This includes: PowerPoint presentations for all of the chapters in the book. Figures in PowerPoint.  Preface vii An instructor’s guide that gives advice on how to use the book in different courses and explains the relationship between the chapters in this edition and previous editions. Further information on the book’s case studies. Additional case studies that may be used in software engineering courses. Additional PowerPoint presentations on systems engineering. Four web chapters covering formal methods, interaction design, application architectures, and documentation. All of this material is available free to readers of the book from the book’s web- site or from the Pearson support site below. Additional material for instructors is available on a restricted basis to accredited instructors only: Model answers to selected end-of-chapter exercises. Quiz questions and answers for each chapter. All support material, including restricted material, is available from: http://www.pearsonhighered.com/sommerville/ Instructors using the book for teaching may obtain a password to access restricted material by registering at the Pearson website, by contacting their local Pearson rep- resentative, or by requesting a password by e-mail from [email protected]. Passwords are not available from the author. Acknowledgments 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 commented on previous editions and made constructive suggestions for change. I’d particularly like to thank my family (Anne, Ali, and Jane) for their help and support while the book was being written. A big thank-you especially to my daugh- ter, Jane, who discovered a talent for proofreading and editing. She was tremen- dously helpful in reading the entire book and did a great job spotting and fixing a large number of typos and grammatical errors. Ian Sommerville October 2009  Contents at a glance Preface iii Part 1 Introduction to Software Engineering 1 Chapter 1 Introduction 3 Chapter 2 Software processes 27 Chapter 3 Agile software development 56 Chapter 4 Requirements engineering 82 Chapter 5 System modeling 118 Chapter 6 Architectural design 147 Chapter 7 Design and implementation 176 Chapter 8 Software testing 205 Chapter 9 Software evolution 234 Part 2 Dependability and Security 261 Chapter 10 Sociotechnical systems 263 Chapter 11 Dependability and security 289 Chapter 12 Dependability and security specification 309 Chapter 13 Dependability engineering 341 Chapter 14 Security engineering 366 Chapter 15 Dependability and security assurance 393 Part 3 Advanced Software Engineering 423 Chapter 16 Software reuse 425 Chapter 17 Component-based software engineering 452 Chapter 18 Distributed software engineering 479 Chapter 19 Service-oriented architecture 508 Chapter 20 Embedded software 537 Chapter 21 Aspect-oriented software engineering 565 Part 4 Software Management 591 Chapter 22 Project management 593 Chapter 23 Project planning 618 Chapter 24 Quality management 651 Chapter 25 Configuration management 681 Chapter 26 Process improvement 705 Glossary 733 Subject Index 749 Author Index 767  CONTENTS Preface iii Part 1 Introduction to Software Engineering 1 Chapter 1 Introduction 3 1.1 Professional software development 5 1.2 Software engineering ethics 14 1.3 Case studies 17 Chapter 2 Software processes 27 2.1 Software process models 29 2.2 Process activities 36 2.3 Coping with change 43 2.4 The rational unified process 50 Chapter 3 Agile software development 56 3.1 Agile methods 58 3.2 Plan-driven and agile development 62 x Contents 3.3 Extreme programming 64 3.4 Agile project management 72 3.5 Scaling agile methods 74 Chapter 4 Requirements engineering 82 4.1 Functional and non-functional requirements 84 4.2 The software requirements document 91 4.3 Requirements specification 94 4.4 Requirements engineering processes 99 4.5 Requirements elicitation and analysis 100 4.6 Requirements validation 110 4.7 Requirements management 111 Chapter 5 System modeling 118 5.1 Context models 121 5.2 Interaction models 124 5.3 Structural models 129 5.4 Behavioral models 133 5.5 Model-driven engineering 138 Chapter 6 Architectural design 147 6.1 Architectural design decisions 151 6.2 Architectural views 153 6.3 Architectural patterns 155 6.4 Application architectures 164 Chapter 7 Design and implementation 176 7.1 Object-oriented design using the UML 178 7.2 Design patterns 189  Contents xi 7.3 Implementation issues 193 7.4 Open source development 198 Chapter 8 Software testing 205 8.1 Development testing 210 8.2 Test-driven development 221 8.3 Release testing 224 8.4 User testing 228 Chapter 9 Software evolution 234 9.1 Evolution processes 237 9.2 Program evolution dynamics 240 9.3 Software maintenance 242 9.4 Legacy system management 252 Part 2 Dependability and Security 261 Chapter 10 Sociotechnical systems 263 10.1 Complex systems 266 10.2 Systems engineering 273 10.3 System procurement 275 10.4 System development 278 10.5 System operation 281 Chapter 11 Dependability and security 289 11.1 Dependability properties 291 11.2 Availability and reliability 295 11.3 Safety 299 11.4 Security 302 xii Contents Chapter 12 Dependability and security specification 309 12.1 Risk-driven requirements specification 311 12.2 Safety specification 313 12.3 Reliability specification 320 12.4 Security specification 329 12.5 Formal specification 333 Chapter 13 Dependability engineering 341 13.1 Redundancy and diversity 343 13.2 Dependable processes 345 13.3 Dependable system architectures 348 13.4 Dependable programming 355 Chapter 14 Security engineering 366 14.1 Security risk management 369 14.2 Design for security 375 14.3 System survivability 386 Chapter 15 Dependability and security assurance 393 15.1 Static analysis 395 15.2 Reliability testing 401 15.3 Security testing 404 15.4 Process assurance 406 15.5 Safety and dependability cases 410 Part 3 Advanced Software Engineering 423 Chapter 16 Software reuse 425 16.1 The reuse landscape 428 16.2 Application frameworks 431  Contents xiii 16.3 Software product lines 434 16.4 COTS product reuse 440 Chapter 17 Component-based software engineering 452 17.1 Components and component models 455 17.2 CBSE processes 461 17.3 Component composition 468 Chapter 18 Distributed software engineering 479 18.1 Distributed systems issues 481 18.2 Client–server computing 488 18.3 Architectural patterns for distributed systems 490 18.4 Software as a service 501 Chapter 19 Service-oriented architecture 508 19.1 Services as reusable components 514 19.2 Service engineering 518 19.3 Software development with services 527 Chapter 20 Embedded software 537 20.1 Embedded systems design 540 20.2 Architectural patterns 547 20.3 Timing analysis 554 20.4 Real-time operating systems 558 Chapter 21 Aspect-oriented software engineering 565 21.1 The separation of concerns 567 21.2 Aspects, join points and pointcuts 571 21.3 Software engineering with aspects 576 xiv Contents Part 4 Software Management 591 Chapter 22 Project management 593 22.1 Risk management 595 22.2 Managing people 602 22.3 Teamwork 607 Chapter 23 Project planning 618 23.1 Software pricing 621 23.2 Plan-driven development 623 23.3 Project scheduling 626 23.4 Agile planning 631 23.5 Estimation techniques 633 Chapter 24 Quality management 651 24.1 Software quality 655 24.2 Software standards 657 24.3 Reviews and inspections 663 24.4 Software measurement and metrics 668 Chapter 25 Configuration management 681 25.1 Change management 685 25.2 Version management 690 25.3 System building 693 25.4 Release management 699 Chapter 26 Process improvement 705 26.1 The process improvement process 708 26.2 Process measurement 711  Contents xv 26.3 Process analysis 715 26.4 Process change 718 26.5 The CMMI process improvement framework 721 Glossary 733 Subject Index 749 Author Index 767 This page intentionally left blank  PART 1 I n t ro d u c t i o n to Software Engineering My aim in this part of the book is to provide a general introduction to software engineering. I introduce important concepts such as software processes and agile methods, and describe essential software development activities, from initial software specification through to system evolution. The chapters in this part have been designed to support a one-semester course in software engineering. Chapter 1 is a general introduction that introduces professional software engineering and defines some software engineering concepts. I have also written a brief discussion of ethical issues in software engineering. I think that it is important for software engineers to think about the wider implications of their work. This chapter also introduces three case studies that I use in the book, namely a system for managing records of patients undergoing treatment for mental health problems, a control system for a portable insulin pump and a wilderness weather system. Chapters 2 and 3 cover software engineering processes and agile devel- opment. In Chapter 2, I introduce commonly used generic software process models, such as the waterfall model, and I discuss the basic activities that are part of these processes. Chapter 3 supplements this with a discussion of agile development methods for software engineer- ing. I mostly use Extreme Programming as an example of an agile method but also briefly introduce Scrum in this chapter. The remainder of the chapters in this part are extended descriptions of the software process activities that will be introduced in Chapter 2. Chapter 4 covers the critically important topic of requirements engineer- ing, where the requirements for what a system should do are defined. Chapter 5 introduces system modeling using the UML, where I focus on the use of use case diagrams, class diagrams, sequence diagrams, and state diagrams for modeling a software system. Chapter 6 introduces architectural design and I discuss the importance of architecture and the use of architectural patterns in software design. Chapter 7 introduces object-oriented design and the use of design pat- terns. I also introduce important implementation issues here—reuse, con- figuration management, and host-target development and discuss open source development. Chapter 8 focuses on software testing from unit test- ing during system development to the testing of software releases. I also discuss the use of test-driven development—an approach pioneered in agile methods but which has wide applicability. Finally, Chapter 9 pres- ents an overview of software evolution issues. I cover evolution processes, software maintenance, and legacy system management. 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 software engineering is and why it is important; understand that the development of different types of software systems may require different software engineering techniques; understand some ethical and professional issues that are important for software engineers; have been introduced to three systems, of different types, that will be used as examples throughout the book. Contents 1.1 Professional software development 1.2 Software engineering ethics 1.3 Case studies 4 Chapter 1 Introduction We can’t run the modern world without software. National infrastructures and utili- ties are controlled by computer-based systems and most electrical products include a computer and controlling software. Industrial manufacturing and distribution is completely computerized, as is the financial system. Entertainment, including the music industry, computer games, and film and television, is software intensive. Therefore, software engineering is essential for the functioning of national and inter- national societies. Software systems are abstract and intangible. They are not constrained by the properties of materials, governed by physical laws, or by manufacturing processes. This simplifies software engineering, as there are no natural limits to the potential of software. However, because of the lack of physical constraints, software systems can quickly become extremely complex, difficult to understand, and expensive to change. There are many different types of software systems, from simple embedded sys- tems to complex, worldwide information systems. It is pointless to look for universal notations, methods, or techniques for software engineering because different types of software require different approaches. Developing an organizational information system is completely different from developing a controller for a scientific instru- ment. Neither of these systems has much in common with a graphics-intensive com- puter game. All of these applications need software engineering; they do not all need the same software engineering techniques. There are still many reports of software projects going wrong and ‘software failures’. Software engineering is criticized as inadequate for modern software development. However, in my view, many of these so-called software failures are a consequence of two factors: 1. Increasing demands As new software engineering techniques help us to build larger, more complex systems, the demands change. Systems have to be built and delivered more quickly; larger, even more complex systems are required; systems have to have new capabilities that were previously thought to be impos- sible. Existing software engineering methods cannot cope and new software engineering techniques have to be developed to meet new these new demands. 2. Low expectations It is relatively easy to write computer programs without using software engineering methods and techniques. Many companies have drifted into software development as their products and services have evolved. They do not use software engineering methods in their everyday work. Consequently, their software is often more expensive and less reliable than it should be. We need better software engineering education and training to address this problem. Software engineers can be rightly proud of their achievements. Of course we still have problems developing complex software but, without software engineering, we would not have explored space, would not have the Internet or modern telecommuni- cations. All forms of travel would be more dangerous and expensive. Software engi- neering has contributed a great deal and I am convinced that its contributions in the 21st century will be even greater.  1.1 Professional software development 5 History of software engineering The notion of ‘software engineering’ was first proposed in 1968 at a conference held to discuss what was then called the ‘software crisis’ (Naur and Randell, 1969). It became clear that individual approaches to program development did not scale up to large and complex software systems. These were unreliable, cost more than expected, and were delivered late. Throughout the 1970s and 1980s, a variety of new software engineering techniques and methods were developed, such as structured programming, information hiding and object-oriented development. Tools and standard notations were developed and are now extensively used. http://www.SoftwareEngineering-9.com/Web/History/ 1.1 Professional software development Lots of people write programs. People in business write spreadsheet programs to simplify their jobs, scientists and engineers write programs to process their experi- mental data, and hobbyists write programs for their own interest and enjoyment. However, the vast majority of software development is a professional activity where software is developed for specific business purposes, for inclusion in other devices, or as software products such as information systems, CAD systems, etc. Professional software, intended for use by someone apart from its developer, is usually developed by teams rather than individuals. It is maintained and changed throughout its life. Software engineering is intended to support professional software development, rather than individual programming. It includes techniques that support program specification, design, and evolution, none of which are normally relevant for per- sonal software development. To help you to get a broad view of what software engi- neering is about, I have summarized some frequently asked questions in Figure 1.1. Many people think that software is simply another word for computer programs. However, when we are talking about software engineering, software is not just the programs themselves but also all associated documentation and configuration data that is required to make these programs operate correctly. A professionally devel- oped software system is often more than a single program. The system usually con- sists of a number of separate programs and configuration files that are used to set up these programs. It may include system documentation, which describes the structure of the system; user documentation, which explains how to use the system, and web- sites for users to download recent product information. This is one of the important differences between professional and amateur soft- ware development. If you are writing a program for yourself, no one else will use it and you don’t have to worry about writing program guides, documenting the pro- gram design, etc. However, if you are writing software that other people will use and other engineers will change then you usually have to provide additional information as well as the code of the program. 6 Chapter 1 Introduction Question Answer What is software? Computer programs and associated documentation. Software products may be developed for a particular customer or may be developed for a general market. What are the attributes of good software? Good software should deliver the required functionality and performance to the user and should be maintainable, dependable, and usable. What is software engineering? Software engineering is an engineering discipline that is concerned with all aspects of software production. What are the fundamental software engineering Software specification, software development, activities? software validation, and software evolution. What is the difference between software Computer science focuses on theory and engineering and computer science? fundamentals; software engineering is concerned with the practicalities of developing and delivering useful software. What is the difference between software System engineering is concerned with all aspects of engineering and system engineering? computer-based systems development including hardware, software, and process engineering. Software engineering is part of this more general process. What are the key challenges facing software Coping with increasing diversity, demands for reduced engineering? delivery times, and developing trustworthy software. What are the costs of software engineering? Roughly 60% of software costs are development costs; 40% are testing costs. For custom software, evolution costs often exceed development costs. What are the best software engineering techniques While all software projects have to be professionally and methods? managed and developed, different techniques are appropriate for different types of system. For example, games should always be developed using a series of prototypes whereas safety critical control systems require a complete and analyzable specification to be developed. You can’t, therefore, say that one method is better than another. What differences has the Web made to software The Web has led to the availability of software engineering? services and the possibility of developing highly distributed service-based systems. Web-based systems development has led to important advances in programming languages and software reuse. Software engineers are concerned with developing software products (i.e., soft- Figure 1.1 Frequently asked questions about ware which can be sold to a customer). There are two kinds of software products: software 1. Generic products These are stand-alone systems that are produced by a develop- ment organization and sold on the open market to any customer who is able to  1.1 Professional software development 7 buy them. Examples of this type of product include software for PCs such as databases, word processors, drawing packages, and project-management tools. It also includes so-called vertical applications designed for some specific pur- pose such as library information systems, accounting systems, or systems for maintaining dental records. 2. Customized (or bespoke) products These are systems that 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. An important difference between these types of software is that, in generic products, the organization that develops the software controls the software specification. For cus- tom products, the specification is usually developed and controlled by the organization that is buying the software. The software developers must work to that specification. However, the distinction between these system product types is becoming increasingly blurred. More and more systems are now being built with a generic product as a base, which is then adapted to suit the requirements of a customer. Enterprise Resource Planning (ERP) systems, such as the SAP system, are the best examples of this approach. Here, a large and complex system is adapted for a com- pany by incorporating information about business rules and processes, reports required, and so on. When we talk about the quality of professional software, we have to take into account that the software is used and changed by people apart from its developers. Quality is therefore not just concerned with what the software does. Rather, it has to include the software’s behavior while it is executing and the structure and organization of the system programs and associated documentation. This is reflected in so-called quality or non-functional software attributes. Examples of these attributes are the soft- ware’s response time to a user query and the understandability 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 interactive game must be responsive, a telephone switching system must be reliable, and so on. These can be generalized into the set of attributes shown in Figure 1.2, which I believe are the essential characteristics of a professional software system. 1.1.1 Software engineering Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification through to maintain- ing 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. However, they use them selectively 8 Chapter 1 Introduction Product characteristics Description Maintainability Software should be written in such a way so that it can evolve to meet the changing needs of customers. This is a critical attribute because software change is an inevitable requirement of a changing business environment. Dependability and security Software dependability includes a range of characteristics including reliability, security, and safety. Dependable software should not cause physical or economic damage in the event of system failure. Malicious users should not be able to access or damage the system. Efficiency Software should not make wasteful use of system resources such as memory and processor cycles. Efficiency therefore includes responsiveness, processing time, memory utilization, etc. Acceptability Software must be acceptable to the type of users for which it is designed. This means that it must be understandable, usable, and compatible with other systems that they use. and always try to discover solutions to problems even when there are no appli- Figure 1.2 Essential attributes of good cable theories and methods. Engineers also recognize that they must work to software organizational 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. It also includes activities such as software project management and the development of tools, methods, and theories to support software production. Engineering is about getting results of the required quality within the schedule and budget. This often involves making compromises—engineers cannot be perfec- tionists. People writing programs for themselves, however, can spend as much time as they wish on the program development. In general, software engineers adopt a systematic and organized 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 circumstances so a more creative, less formal approach to development may be effective in some circumstances. Less formal development is particularly appropri- ate for the development of web-based systems, which requires a blend of software and graphical design skills. Software engineering is important for two reasons: 1. More and more, individuals and society rely on advanced software systems. We need to be able to produce reliable and trustworthy systems economically and quickly.  1.1 Professional software development 9 2. It is usually cheaper, in the long run, to use software engineering methods and techniques for software systems rather than just write the programs as if it was a personal programming project. For most types of systems, the majority of costs are the costs of changing the software after it has gone into use. The systematic approach that is used in software engineering is sometimes called a software process. A software process is a sequence of activities that leads to the production of a software product. There are four fundamental activities that are com- mon to all software processes. These activities are: 1. Software specification, where customers and engineers define the software that is 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 reflect changing customer 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. In e-commerce systems, the specification and the program are usually devel- oped together. Consequently, these generic activities may be organized in different ways and described at different levels of detail depending on the type of software being developed. I describe software processes in more detail in Chapter 2. Software engineering is related to both computer science and systems engineering: 1. Computer science is concerned with the theories and methods that underlie com- puters and software systems, whereas software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers. Computer science theory, however, is often most applicable to relatively small programs. Elegant theories of computer science cannot always be applied to large, complex problems that require a soft- ware solution. 2. System engineering is concerned with all aspects of the development and evo- lution of complex systems where software plays a major role. System engineer- ing is therefore concerned with hardware development, policy and process design and system deployment, as well as software engineering. System engi- neers are involved in specifying 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.). 10 Chapter 1 Introduction As I discuss in the next section, there are many different types of software. There is no universal software engineering method or technique that is applicable for all of these. However, there are three general issues that affect many different types of software: 1. Heterogeneity Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices. As well as running on general-purpose computers, software may also have to execute on mobile phones. You often have to integrate new software with older legacy sys- tems written in different programming languages. The challenge here is to develop techniques for building dependable software that is flexible enough to cope with this heterogeneity. 2. Business and social change Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new soft- ware. Many traditional software engineering techniques are time consuming and delivery of new systems often takes longer than planned. They need to evolve so that the time required for software to deliver value to its customers is reduced. 3. Security and trust As software is intertwined with all aspects of our lives, it is essential that we can trust that software. This is especially true for remote soft- ware systems accessed through a web page or web service interface. We have to make sure that malicious users cannot attack our software and that information security is maintained. Of course, these are not independent issues. 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.1.2 Software engineering diversity Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers. How this systematic approach is actu- ally implemented varies dramatically depending on the organization developing the software, the type of software, and the people involved in the development process. There are no universal software engineering methods and techniques that are suit- able for all systems and all companies. Rather, a diverse set of software engineering methods and tools has evolved over the past 50 years. Perhaps the most significant factor in determining which software engineering methods and techniques are most important is the type of application that is being developed. There are many different types of application including: 1. Stand-alone applications These are application systems that run on a local com- puter, such as a PC. They include all necessary functionality and do not need to  1.1 Professional software development 11 be connected to a network. Examples of such applications are office applica- tions on a PC, CAD programs, photo manipulation software, etc. 2. Interactive transaction-based applications These are applications that execute on a remote computer and that are accessed by users from their own PCs or terminals. Obviously, these include web applications such as e-commerce appli- cations where you can interact with a remote system to buy goods and services. This class of application also includes business systems, where a business provides access to its systems through a web browser or special-purpose client program and cloud-based services, such as mail and photo sharing. Interactive applications often incorporate a large data store that is accessed and updated in each transaction. 3. Embedded control systems These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded sys- tems than any other type of system. Examples of embedded systems include the software in a mobile (cell) phone, software that controls anti-lock braking in a car, and software in a microwave oven to control the cooking process. 4. Batch processing systems These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs. Examples of batch systems include periodic billing systems, such as phone billing systems, and salary payment systems. 5. Entertainment systems These are systems that are primarily for personal use and which are intended to entertain the user. Most of these systems are games of one kind or another. The quality of the user interaction offered is the most important distinguishing characteristic of entertainment systems. 6. Systems for modeling and simulation These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects. These are often computationally intensive and require high-performance parallel systems for execution. 7. Data collection systems These are systems that collect data from their environ- ment using a set of sensors and send that data to other systems for processing. The software has to interact with sensors and often is installed in a hostile envi- ronment such as inside an engine or in a remote location. 8. Systems of systems These are systems that are composed of a number of other software systems. Some of these may be generic software products, such as a spreadsheet program. Other systems in the assembly may be specially written for that environment. Of course, the boundaries between these system types are blurred. If you develop a game for a mobile (cell) phone, you have to take into account the same constraints (power, hardware interaction) as the developers of the phone software. Batch pro- cessing systems are often used in conjunction with web-based systems. For example, 12 Chapter 1 Introduction in a company, travel expense claims may be submitted through a web application but processed in a batch application for monthly payment. You use different software engineering techniques for each type of system because the software has quite different characteristics. For example, an embedded control system in an automobile is safety-critical and is burned into ROM when installed in the vehicle. It is therefore very expensive to change. Such a system needs very extensive verification and validation so that the chances of having to recall cars after sale to fix software problems are minimized. User interaction is minimal (or perhaps nonexistent) so there is no need to use a development process that relies on user interface prototyping. For a web-based system, an approach based on iterative development and delivery may be appropriate, with the system being composed of reusable components. However, such an approach may be impractical for a system of systems, where detailed specifications of the system interactions have to be specified in advance so that each system can be separately developed. Nevertheless, there are software engineering fundamentals that apply to all types of software system: 1. They should be developed using a managed and understood development process. The organization developing the software should plan the development process and have clear ideas of what will be produced and when it will be com- pleted. Of course, different processes are used for different types of software. 2. Dependability and performance are important for all types of systems. Software should behave as expected, without failures and should be available for use when it is required. It should be safe in its operation and, as far as possible, should be secure against external attack. The system should perform efficiently and should not waste resources. 3. Understanding and managing the software specification and requirements (what the software should do) are important. You have to know what different customers and users of the system expect from it and you have to manage their expectations so that a useful system can be delivered within budget and to schedule. 4. You should make as effective use as possible of existing resources. This means that, where appropriate, you should reuse software that has already been devel- oped rather than write new software. These fundamental notions of process, dependability, requirements, management, and reuse are important themes of this book. Different methods reflect them in dif- ferent ways but they underlie all professional software development. You should notice that these fundamentals do not cover implementation and pro- gramming. I don’t cover specific programming techniques in this book because these vary dramatically from one type of system to another. For example, a scripting lan- guage such as Ruby is used for web-based system programming but would be com- pletely inappropriate for embedded systems engineering.  1.1 Professional software development 13 1.1.3 Software engineering and the Web The development of the World Wide Web has had a profound effect on all of our lives. Initially, the Web was primarily a universally accessible information store and it had little effect on software systems. These systems ran on local computers and were only accessible from within an organization. Around 2000, the Web started to evolve and more and more functionality was added to browsers. This meant that web-based systems could be developed where, instead of a special-purpose user interface, these systems could be accessed using a web browser. This led to the development of a vast range of new system products that delivered innovative serv- ices, accessed over the Web. These are often funded by adverts that are displayed on the user’s screen and do not involve direct payment from users. As well as these system products, the development of web browsers that could run small programs and do some local processing led to an evolution in business and organizational software. Instead of writing software and deploying it on users’ PCs, the software was deployed on a web server. This made it much cheaper to change and upgrade the software, as there was no need to install the software on every PC. It also reduced costs, as user interface development is particularly expensive. Consequently, wherever it has been possible to do so, many businesses have moved to web-based interaction with company software systems. The next stage in the development of web-based systems was the notion of web services. Web services are software components that deliver specific, useful function- ality and which are accessed over the Web. Applications are constructed by integrating these web services, which may be provided by different companies. In principle, this linking can be dynamic so that an application may use different web services each time that it is executed. I cover this approach to software development in Chapter 19. In the last few years, the notion of ‘software as a service’ has been developed. It has been proposed that software will not normally run on local computers but will run on ‘computing clouds’ that are accessed over the Internet. If you use a service such as web-based mail, you are using a cloud-based system. A computing cloud is a huge number of linked computer systems that is shared by many users. Users do not buy software but pay according to how much the software is used or are given free access in return for watching adverts that are displayed on their screen. The advent of the web, therefore, has led to a significant change in the way that business software is organized. Before the web, business applications were mostly monolithic, single programs running on single computers or computer clusters. Communications were local, within an organization. Now, software is highly distrib- uted, sometimes across the world. Business applications are not programmed from scratch but involve extensive reuse of components and programs. This radical change in software organization has, obviously, led to changes in the ways that web-based systems are engineered. For example: 1. Software reuse has become the dominant approach for constructing web-based systems. When building these systems, you think about how you can assemble them from pre-existing software components and systems. 14 Chapter 1 Introduction 2. It is now generally recognized that it is impractical to specify all the require- ments for such systems in advance. Web-based systems should be developed and delivered incrementally. 3. User interfaces are constrained by the capabilities of web browsers. Although technologies such as AJAX (Holdener, 2008) mean that rich interfaces can be created within a web browser, these technologies are still difficult to use. Web forms with local scripting are more commonly used. Application interfaces on web-based systems are often poorer than the specially designed user interfaces on PC system products. The fundamental ideas of software engineering, discussed in the previous section, apply to web-based software in the same way that they apply to other types of soft- ware system. Experience gained with large system development in the 20th century is still relevant to web-based software. 1.2 Software engineering ethics Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of people working in that area. As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills. You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer. It goes without saying that you should 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 behavior are not bound 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 employ- ers or clients irrespective of whether or not 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 careful 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 people’s computers. Computer misuse ranges from relatively trivial (game playing on an employer’s machine, say) to extremely serious (dissemination of viruses or other malware).  1.2 Software engineering ethics 15 Software Engineering Code of Ethics and Professional Practice ACM/IEEE-CS Joint Task Force on Software Engineering Ethics 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 how 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 commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected 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 consistent with the public interest. 3. PRODUCT — Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. 4. JUDGMENT — Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION — Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. 7. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues. 8. SELF — Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. Professional societies and institutions have an important role to play in setting Figure 1.3 The ACM/IEEE Code of ethical standards. Organizations such as the ACM, the IEEE (Institute of Electrical Ethics (© IEEE/ACM and Electronic Engineers), and the British Computer Society publish a code of 1999) professional conduct or code of ethics. Members of these organizations undertake to follow that code when they sign up for membership. These codes of conduct are gen- erally concerned with fundamental ethical behavior. Professional associations, notably 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.3, and a longer form (Gotterbarn et al., 1999) that adds detail and substance to the shorter version. The rationale behind this code is summa- rized in the first two paragraphs 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, spec- ification, design, development, certification, maintenance and testing of software 16 Chapter 1 Introduction 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, that their efforts will be used for good, software engi- neers must commit themselves to making software engineering a beneficial and respected profession. In accordance with that commitment, software engineers shall adhere to the following Code of Ethics and Professional Practice. The Code contains eight Principles related 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 the profession. The Principles identify the ethically responsible relationships in which individuals, groups, and organizations participate and the primary obligations within these relationships. The Clauses of each Principle are illus- trations of some of the obligations included in these relationships. These obli- gations are founded in the software engineer’s humanity, in special care owed to people affected by the work of software engineers, and the unique elements of the practice of software engineering. The Code prescribes these as obliga- tions of anyone claiming to be or aspiring to be a software engineer. In any situation where different people have different views and objectives you are likely to be faced with ethical dilemmas. For example, if you disagree, in princi- ple, with the policies of more senior management in the company, how should you react? Clearly, this depends on the particular individuals and the nature of the dis- agreement. Is it best to argue a case for your position from within the organization or to resign in principle? If you feel that there are problems with a software project, when do you reveal these to management? If you discuss these while they are just a suspicion, you may be overreacting to a situation; if you leave it too late, it may be impossible to resolve the difficulties. Such ethical dilemmas face all of us in our professional lives and, fortunately, in most cases they are either relatively minor or can be resolved without too much dif- ficulty. Where they cannot be resolved, the engineer is faced with, perhaps, another problem. The principled action may be to resign from their job but this may well affect others such as their partner or their children. A particularly difficult situation for professional engineers arises when their employer acts in an unethical way. Say a company is responsible for developing a safety-critical system and, because of time pressure, falsifies the safety validation records. Is the engineer’s responsibility to maintain confidentiality or to alert the customer or publicize, in some way, that the delivered system may be unsafe? The problem here is that there are no absolutes when it comes to safety. Although the system may not have been validated according to predefined criteria, these crite- ria may be too strict. The system may actually operate safely throughout its lifetime. It is also the case that, even when properly validated, the system may fail and cause an accident. Early disclosure of problems may result in damage to the employer and other employees; failure to disclose problems may result in damage to others.  1.3 Case studies 17 You must make up your own mind in these matters. The appropriate ethical posi- tion here depends entirely on the views of the individuals who are involved. In this case, the potential for damage, the extent of the damage, and the people affected by the damage should influence the decision. If the situation is very dangerous, it may be justified to publicize it using the national press (say). However, you should always try to resolve the situation while respecting the rights of your employer. Another ethical issue is participation in the development of military and nuclear systems. Some people feel strongly about these issues and do not wish to participate in any systems development associated with military systems. Others will work on mili- tary systems but not on weapons systems. Yet others feel that national security is an overriding principle and have no ethical objections to working on weapons systems. In this situation, it is important that both employers and employees should make their views known to each other in advance. Where an organization is involved in military or nuclear work, they should be able to specify that employees must be will- ing to accept any work assignment. Equally, if an employee is taken on and makes clear that they do not wish to work on such systems, employers should not put pres- sure on them to do so at some later date. The general area of ethics and professional responsibility is becoming more important as software-intensive systems pervade every aspect of work and everyday life. It can be considered from a philosophical standpoint where the basic principles of ethics are considered and software engineering ethics are discussed with reference to these basic principles. This is the approach taken by Laudon (1995) and to a lesser extent by Huff and Martin (1995). Johnson’s text on computer ethics (2001) also approaches the topic from a philosophical perspective. However, I find that this philosophical approach is too abstract and difficult to relate to everyday experience. I prefer the more concrete approach embodied in codes of conduct and practice. I think that ethics are best discussed in a software engineer- ing context and not as a subject in their own right. In this book, therefore, I do not include abstract ethical discussions but, where appropriate, include examples in the exercises that can be the starting point for a group discussion on ethical issues. 1. 3 Case studies To illustrate software engineering concepts, I use examples from three different types of systems throughout the book. The reason why I have not used a single case study is that one of the key messages in this book is that software engineering prac- tice depends on the type of systems being produced. I therefore choose an appropri- ate example when discussing concepts such as safety and dependability, system modeling, reuse, etc. The three types of systems that I use as case studies are: 1. An embedded system This is a system where the software controls a hardware device and is embedded in that device. Issues in embedded systems typically 18 Chapter 1 Introduction include physical size, responsiveness, power management, etc. The example of an embedded system that I use is a software system to control a medical device. 2. An information system This is a system whose primary purpose is to manage and provide access to a database of information. Issues in information systems include security, usability, privacy, and maintaining data integrity. The example of an information system that I use is a medical records system. 3. A sensor-based data collection system This is a system whose primary purpose is to collect data from a set of sensors and process that data in some way. The key requirements of such systems are reliability, even in hostile environmental conditions, and maintainability. The example of a data collection system that I use is a wilderness weather station. I introduce each of these systems in this chapter, with more information about each of them available on the Web. 1.3.1 An insulin pump control system An insulin pump is a medical system that simulates the operation of the pancreas (an internal organ). The software controlling this system is an embedded system, which collects information from a sensor and controls a pump that delivers a controlled dose of insulin to a user. People who suffer from diabetes use the system. Diabetes is a relatively common condition where the human pancreas is unable to produce sufficient quantities of a hormone called insulin. Insulin metabolises glucose (sugar) in the blood. The con- ventional treatment of diabetes involves regular injections of genetically engineered insulin. Diabetics measure their blood sugar levels using an external meter and then calculate the dose of insulin that they should inject. The problem with this treatment is that the level of insulin required does not just depend on the blood glucose level but also on the time of the last insulin injection. This can lead to very low levels of blood glucose (if there is too much insulin) or very high levels of blood sugar (if there is too little insulin). Low blood glucose is, in the short term, a more serious condition as it can result in temporary brain malfunctioning and, ultimately, unconsciousness and death. In the long term, however, continual high levels of blood glucose can lead to eye damage, kidney damage, and heart problems. Current advances in developing miniaturized sensors have meant that it is now pos- sible to develop automated insulin delivery systems. These systems monitor blood sugar levels and deliver an appropriate dose of insulin when required. Insulin delivery systems like this already exist for the treatment of hospital patients. In the future, it may be pos- sible for many diabetics to have such systems permanently attached to their bodies. A software-controlled insulin delivery system might work by using a micro- sensor embedded in the patient to measure some blood parameter that is proportional to the sugar level. This is then sent to the pump controller. This controller computes the sugar level and the amount of insulin that is needed. It then sends signals to a miniaturized pump to deliver the insulin via a permanently attached needle.  1.3 Case studies 19 Insulin Reservoir Needle Pump Clock Assembly Sensor Controller Alarm Display1 Display2 Figure 1.4 Insulin Power Supply pump hardware Blood Analyze Sensor Blood Compute Insulin Sensor Reading Sugar Insulin Log Insulin Dose Insulin Control Insulin Pump Compute Pump Log Dose Pump Pump Data Commands Figure 1.4 shows the hardware components and organization of the insulin Figure 1.5 Activity model of the insulin pump. To understand the examples in this book, all you need to know is that the pump blood sensor measures the electrical conductivity of the blood under different conditions and that these values can be related to the blood sugar level. The insulin pump delivers one unit of insulin in response to a single pulse from a con- troller. Therefore, to deliver 10 units of insulin, the controller sends 10 pulses to the pump. Figure 1.5 is a UML activity model that illustrates how the software transforms an input blood sugar level to a sequence of commands that drive the insulin pump. Clearly, this is a safety-critical system. If the pump fails to operate or does not operate correctly, then the user’s health may be damaged or they may fall into a coma because their blood sugar levels are too high or too low. There are, therefore, two essential high-level requirements that this system must meet: 1. The system shall be available to deliver insulin when required. 2. The system shall perform reliably and deliver the correct amount of insulin to counteract the current level of blood sugar. 20 Chapter 1 Introduction MHC-PMS MHC-PMS MHC-PMS Local Local Local MHC-PMS Server Figure 1.6 The Patient Database organization of the MHC-PMS The system must therefore be designed and implemented to ensure that the sys- tem always meets these requirements. More detailed requirements and discussions of how to ensure that the system is safe are discussed in later chapters. 1.3.2 A patient information system for mental health care A patient information system to support mental health care is a medical informa- tion system that maintains information about patients suffering from mental health problems and the treatments that they have received. Most mental health patients do not require dedicated hospital treatment but need to attend specialist clinics regularly where they can meet a doctor who has detailed knowledge of their problems. To make it easier for patients to attend, these clinics are not just run in hospitals. They may also be held in local medical practices or community centers. The MHC-PMS (Mental Health Care-Patient Management System) is an informa- tion system that is intended for use in clinics. It makes use of a centralized database of patient information but has also been designed to run on a PC, so that it may be accessed and used from sites that do not have secure network connectivity. When the local sys- tems have secure network access, they use patient information in the database but they can download and use local copies of patient records when they are disconnected. The system is not a complete medical records system so does not maintain information about other medical conditions. However, it may interact and exchange data with other clinical information systems. Figure 1.6 illustrates the organization of the MHC-PMS. The MHC-PMS has two overall goals: 1. To generate management information that allows health service managers to assess performance against local and government targets. 2. To provide medical staff with timely information to support the treatment of patients.  1.3 Case studies 21 The nature of mental health problems is such that patients are often disorganized so may miss appointments, deliberately or accidentally lose prescriptions and med- ication, forget instructions, and make unreasonable demands on medical staff. They may drop in on clinics unexpectedly. In a minority of cases, they may be a danger to themselves or to other people. They may regularly change address or may be home- less on a long-term or short-term basis. Where patients are dangerous, they may need to be ‘sectioned’—confined to a secure hospital for treatment and observation. Users of the system include clinical staff such as doctors, nurses, and health visi- tors (nurses who visit people at home to check on their treatment). Nonmedical users include receptionists who make appointments, medical records staff who maintain the records system, and administrative staff who generate reports. The system is used to record information about patients (name, address, age, next of kin, etc.), consultations (date, doctor seen, subjective impressions of the patient, etc.), conditions, and treatments. Reports are generated at regular intervals for med- ical staff and health authority managers. Typically, reports for medical staff focus on information about individual patients whereas management reports are anonymized and are concerned with conditions, costs of treatment, etc. The key features of the system are: 1. Individual care management Clinicians can create records for patients, edit the information in the system, view patient history, etc. The system supports data summaries so that doctors who have not previously met a patient can quickly learn about the key problems and treatments that have been prescribed. 2. Patient monitoring The system regularly monitors the records of patients that are involved in treatment and issues warnings if possible problems are detected. Therefore, if a patient has not seen a doctor for some time, a warning may be issued. One of the most important elements of the monitoring system is to keep track of patients who have been sectioned and to ensure that the legally required checks are carried out at the right time. 3. Administrative reporting The system generates monthly management reports showing the number of patients treated at each clinic, the number of patients who have entered and left the care system, number of patients sectioned, the drugs prescribed and their costs, etc. Two different laws affect the system. These are laws on data protection that govern the confidentiality of personal information and mental health laws that govern the com- pulsory detention of patients deemed to be a danger to themselves or others. Mental health is unique in this respect as it is the only medical speciality that can recommend the detention of patients against their will. This is subject to very strict legislative safe- guards. One of the aims of the MHC-PMS is to ensure that staff always act in accor- dance with the law and that their decisions are recorded for judicial review if necessary. As in all medical systems, privacy is a critical system requirement. It is essential that patient information is confidential and is never disclosed to anyone apart from author- ized medical staff and the patient themselves. The MHC-PMS is also a safety-critical 22 Chapter 1 Introduction «system» «system» Weather Station Data Management and Archiving «system» Figure 1.7 The weather Station Maintenance station’s environment system. Some mental illnesses cause patients to become suicidal or a danger to other people. Wherever possible, the system should warn medical staff about potentially sui- cidal or dangerous patients. The overall design of the system has to take into account privacy and safety requirements. The system must be available when needed otherwise safety may be compromised and it may be impossible to prescribe the correct medication to patients. There is a potential conflict here—privacy is easiest to maintain when there is only a single copy of the system data. However, to ensure availability in the event of server failure or when disconnected from a network, multiple copies of the data should be maintained. I discuss the trade-offs between these requirements in later chapters. 1.3.3 A wilderness weather station To help monitor climate change and to improve the accuracy of weather forecasts in remote areas, the government of a country with large areas of wilderness decides to deploy several hundred weather stations in remote areas. These weather stations col- lect data from a set of instruments that measure temperature and pressure, sunshine, rainfall, wind speed, and wind direction. Wilderness weather stations are part of a larger system (Figure 1.7), which is a weather information system that collects data from weather stations and makes it available to other syste