Software Engineering: Principles and Practice Hans van Vliet (c) Wiley, 2007 Contents 1 Introduction 1 Chapter 1 Introduction 1 1.1 What is Software Engineering? .2 Phases in the Development of Software .3 Maintenance or Evolution .4 From the Trenches .3 The London Ambulance Service .4 Who Counts the Votes? .5 Software Engineering Ethics. 30 I Software Management 33 2 Introduction to Software Engineering Management 34 Chapter 2 Introduction to Software Engineering Management 34 2.1 Planning a Software Development Project .2 Controlling a Software Development Project. 43 3 The Software Life Cycle Revisited 45 Chapter 3 The Software Life Cycle Revisited 45 3.1 The Waterfall Model .3 Rapid Application Development and DSDM .3 The Rational Unified Process (RUP) .4 Intermezzo: Maintenance or Evolution .5 Software Product Lines. 76 4 Configuration Management 78 Chapter 4 Configuration Management 78 4.1 Tasks and Responsibilities .2 Configuration Management Plan.
88 5 People Management and Team Organization 89 Chapter 5 People Management and Team Organization 89 5.3 Chief Programmer Team .6 Open Source Software Development .7 General Principles for Organizing a Team. 105 6 On Managing Software Quality 107 Chapter 6 On Managing Software Quality 107 6.1 On Measures and Numbers .2 A Taxonomy of Quality Attributes .3 Perspectives on Quality .4 The Quality System .5 Software Quality Assurance .6 The Capability Maturity Model (CMM) .7 Some Critical Notes. 141 7 Cost Estimation 144 Chapter 7 Cost Estimation 144 7.4 Function Point Analysis .5 COCOMO 2: Variations on a Theme .2 Guidelines for Estimating Cost .3 Distribution of Manpower over Time. 174 8 Project Planning and Control 176 Chapter 8 Project Planning and Control 176 8.1 A Systems View of Project Control .2 A Taxonomy of Software Development Projects .4 Techniques for Project Planning and Control.
195 II The Software Life Cycle 197 9 Requirements Engineering 199 Chapter 9 Requirements Engineering 199 9.1 Requirements Engineering Paradigms .2 Requirements Elicitation Techniques .3 Goals and Viewpoints .2 Requirements Documentation and Management .3 Requirements Specification Techniques .1 Specifying Non-Functional Requirements .4 Verification and Validation. 243 10 Modeling 246 Chapter 10Modeling 246 10.1 Classic Modeling Techniques .1 Entity--Relationship Modeling .2 Finite State Machines .3 Data Flow Diagrams (DFD) .2 On Objects and Related Stuff .3 The Unified Modeling Language .1 The Class Diagram .2 The State Machine Diagram .3 The Sequence Diagram .4 The Communication Diagram .5 The Component Diagram .6 The Use Case. 274 11 Software Architecture 276 Chapter 11Software Architecture 276 11.1 Software Architecture and the Software Life Cycle .1 Architecture as a set of design decisions .5 Software Architecture Assessment. 311 12 Software Design 313 Chapter 12Software Design 313 12.6 Object-Oriented Metrics .2 Classical Design Methods .2 Data Flow Design (SA/SD) .3 Design based on Data Structures .3 Object-Oriented Analysis and Design Methods .1 The Booch Method .4 How to Select a Design Method .1 Object Orientation: Hype or the Answer? .7 Verification and Validation.
389 13 Software Testing 394 Chapter 13Software Testing 394 13.1 Test Adequacy Criteria .2 Fault Detection Versus Confidence Building .3 From Fault Detection to Fault Prevention .2 Testing and the Software Life Cycle .5 Test-Driven Development (TDD) .3 Verification and Validation Planning and Documentation .4 Manual Test Techniques .2 Walkthroughs and Inspections .5 Coverage-Based Test Techniques .1 Control-Flow Coverage .3 Coverage-Based Testing of Requirements Specifications .6 Fault-Based Test Techniques .7 Error-Based Test Techniques .8 Comparison of Test Techniques .1 Comparison of Test Adequacy Criteria .2 Properties of Test Adequacy Criteria .9 Different Test Stages .10Estimating Software Reliability. 449 14 Software Maintenance 453 Chapter 14Software Maintenance 453 14.1 Maintenance Categories Revisited .2 Major Causes of Maintenance Problems .3 Reverse Engineering and Refactoring .4 Software Evolution Revisited .5 Organizational and Managerial Issues .1 Organization of Maintenance Activities .2 Software Maintenance from a Service Perspective .3 Control of Maintenance Tasks. 492 15 Software Tools 494 Chapter 15Software Tools 494 15.2 Language-Centered Environments .3 Integrated Environments and Workbenches .4 Integrated Project Support Environments .4 Process-Centered Environments. 512 Bibliography 514 1 Introduction LEARNING OBJECTIVES To understand the notion of software engineering and why it is important To appreciate the technical (engineering), managerial, and psychological aspects of software engineering To understand the similarities and differences between software engineering and other engineering disciplines To know the major phases in a software development project To appreciate ethical dimensions in software engineering To be aware of the time frame and extent to which new developments impact software engineering practice 2 INTRODUCTION Software engineering concerns methods and techniques to develop large software systems.
The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints. This chapter gives a brief overview of the field and points at emerging trends that influence the way software is developed. Computer science is still a young field. The first computers were built in the mid 1940s, since when the field has developed tremendously.
Applications from the early years of computerization can be characterized as follows: the programs were quite small, certainly when compared to those that are currently being constructed; they were written by one person; they were written and used by experts in the application area concerned. The problems to be solved were mostly of a technical nature, and the emphasis was on expressing known algorithms efficiently in some programming language. Input typically consisted of numerical data, read from such media as punched tape or punched cards. The output, also numeric, was printed on paper.
Programs were run off-line. If the program contained errors, the programmer studied an octal or hexadecimal dump of memory. Sometimes, the execution of the program would be followed by binary reading machine registers at the console. Independent software development companies hardly existed in those days.
Software was mostly developed by hardware vendors and given away for free. These vendors sometimes set up user groups to discuss requirements, and next incorporated them into their software. This software development support was seen as a service to their customers. Present-day applications are rather different in many respects.
Present-day pro- grams are often very large and are being developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc.
Putting a man on the moon was not conceivable without computers. In the 1960s, people started to realize that programming techniques had lagged behind the developments in software both in size and complexity. To many people, programming was still an art and had never become a craft. An additional problem was that many programmers had not been formally educated in the field.
They had learned by doing. On the organizational side, attempted solutions to problems often involved adding more and more programmers to the project, the so-called ‘million-monkey’ approach. As a result, software was often delivered too late, programs did not behave as the user expected, programs were rarely adaptable to changed circumstances, and many errors were detected only after the software had been delivered to the customer. This 3 became known as the ‘software crisis’.
This type of problem really became manifest in the 1960s. Under the auspices of NATO, two conferences were devoted to the topic in 1968 and 1969 (Naur and Randell, 1968), (Buxton and Randell, 1969). Here, the term ‘software engineering’ was coined in a somewhat provocative sense. Shouldn’t it be possible to build software in the way one builds bridges and houses, starting from a theoretical basis and using sound and proven design and construction techniques, as in other engineering fields? Software serves some organizational purpose.
The reasons for embarking on a software development project vary. Sometimes, a solution to a problem is not feasible without the aid of computers, such as weather forecasting, or automated bank telling. Sometimes, software can be used as a vehicle for new technologies, such as typesetting, the production of chips, or manned space trips. In yet other cases software may increase user service (library automation, e-commerce) or simply save money (automated stock control).
In many cases, the expected economic gain will be a major driving force. It may not, however, always be easy to prove that automation saves money (just think of office automation) because apart from direct cost savings, the economic gain may also manifest itself in such things as a more flexible production or a faster or better user service. In either case, it is a value-creating activity. Boehm (1981) estimated the total expenditure on software in the US to be $40 billion in 1980.
This is approximately 2% of the GNP. In 1985, the total expenditure had risen to $70 billion in the US and $140 billion worldwide. Boehm and Sullivan (1999) estimated the annual expenditure on software development in 1998 to be $300-400 billion in the US, and twice that amount worlwide. So the cost of software is of crucial importance.
This concerns not only the cost of developing the software, but also the cost of keeping the software operational once it has been delivered to the customer. In the course of time, hardware costs have decreased dramatically. Hardware costs now typically comprise less than 20% of total expenditure (figure 1. The remaining 80% comprise all non-hardware costs: the cost of programmers, analysts, management, user training, secretarial help, etc.
An aspect closely linked with cost is productivity. In the 1980s, the quest for data processing personnel increased by 12% per year, while the population of people working in data processing and the productivity of those people each grew by approximately 4% per year (Boehm, 1987a). This situation has not fundamentally changed (Jones, 1999). The net effect is a growing gap between demand and supply.
The result is both a backlog with respect to the maintenance of existing software and a slowing down in the development of new applications. The combined effect may have repercussions on the competitive edge of an organization, especially so when there are severe time-to-market constraints. These developments have led to a shift from producing software to using software. We’ll come back to this topic in section 1.
The issues of cost and productivity of software development deserve our serious attention. However, this is not the complete story. Society is increasingly dependent 4 INTRODUCTION Figure 1.1 Relative distribution of hardware/software costs. Boehm, Software Engineering, IEEE Transactions on Computers, 1976 IEEE.
The quality of the systems we develop increasingly determines the quality of our existence. Consider as an example the following message from a Dutch newspaper on June 6, 1980, under the heading ‘Americans saw the Russians coming’: For a short period last Tuesday the United States brought their atomic bombers and nuclear missiles to an increased state of alarm when, because of a computer error, a false alarm indicated that the Soviet Union had started a missile attack. Efforts to repair the error were apparently in vain, for on June 9, 1980, the same newspaper reported: For the second time within a few days, a deranged computer reported that the Soviet Union had started a nuclear attack against the United States. Last Saturday, the DoD affirmed the false message, which resulted in the engines of the planes of the strategic air force being started.
It is not always the world that is in danger. On a smaller scale, errors in software may have very unfortunate consequences, such as transaction errors in bank traffic; reminders to finally pay that bill of $0.00; a stock control system that issues orders too late and thus lays off complete divisions of a factory. WHAT IS SOFTWARE ENGINEERING? 5 The latter example indicates that errors in a software system may have serious financial consequences for the organization using it.