| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
4. From the Trenches And such is the way of all superstition, whether in astrology, dreams, omens, divine judgments or the like; wherein men, having a delight in such vanities, mark the events when they are fulfilled, but when they fail, though this happens much oftener, neglect and pass them by. But with far more subtlety does this mischief insinuate itself into philosophy and the sciences; in which the first conclusion colors and brings into conformity with itself all that come after, though far sounder and better. Besides, independently of that delight and vanity which I have described, it is the peculiar and perpetual error of the human intellect to be more moved and excited by affirmatives than by negatives; whereas it ought properly to hold itself indifferently disposed towards both alike. Indeed in the establishment of any true axiom, the negative instance is the more forcible of the two. Sir Francis Bacon, The New Organon, Aphorisms XLVI (1611) Historical case studies contain a wealth of wisdom about the nature of design and the engineering method. (Petroski, 1994) In his wonderful book Design Paradigms, Case Histories of Error and Judgment in Engineering, Henri Petroski tells us about some of the greatest engineering successes and, especially, failures of all time. Some such failure stories about our profession have appeared as well. Four of them are discussed in this section. These stories are interesting because they teach us that software engineering has many facets. Failures in software development projects often are not one-dimensional. They are not only caused by a technical slip in some routine. They are not only caused by bad management. They are not only the result of human communication problems. It is often a combination of many smaller slips, which accumulate over time, and eventually result in a major failure. To paraphrase a famous saying of Fred Brooks about projects getting late: 'How does a project really get into trouble?' 'One slip at a time.' Each of the stories discussed below shows such a cumulative effect. Successes in software development will not come about if we just employ the brightest programmers. Or apply the newest design philosophy. Or have the most extensive user consultation. Or even hire the best manager. You have to do all of that. And even more. 4.1 Ariane 5, Flight 501 The maiden flight of the Ariane 5 launcher took place on June 4, 1996. After about 40 seconds, at an altitude of less than 4 kilometers, the launcher broke up and exploded. This $500M loss was ultimately caused by an overflow in the conversion from a 64-bit floating point number to a 16-bit signed integer. From a software engineering point of view, the Ariane 5 story is interesting because the failure can be attributed to different causes, at different levels of understanding: inadequate testing, wrong type of reuse, or a wrong design philosophy. The altitude of the launcher and its movements in space are measured by an Inertial Reference System (SRI -- Systeme de Reference Inertielle). There are two SRIs operating in parallel. Their hardware and software is identical. Most of the hardware and software for the SRI was retained from the Ariane 4. The fatal conversion took place in a piece of software in the SRI which is only meaningful before lift-off. Though this part of the software serves no purpose after the rocket has been launched, it keeps running for an additional number of seconds. This requirement was stated more than 10 years earlier for a somewhat peculiar reason. It allows for a quick restart of the countdown, in the case that it is interrupted close to lift-off. This requirement does not apply to the Ariane 5, but the software was left unchanged -- after all, it worked. Since the Ariane 5 is much faster than the Ariane 4, the rocket reaches a much higher horizontal velocity within this short period after lift-off, resulting in the above-mentioned overflow. Because of this overflow, the first SRI ceased to function. The second SRI was then activated, but since the hardware and software of both SRIs are identical, the second SRI failed as well. As a consequence, wrong data were transmitted from the SRI to the on-board computer. On the basis of these wrong data, full nozzle deflections were commanded. These caused a very high aerodynamic load which led to the separation of the boosters from the main rocket. And this in turn triggered the self-destruction of the launcher. There are several levels at which the Ariane 5 failure can be understood and explained: _ It was a software failure, which could have been revealed with more extensive testing. This is true: the committee investigating the event managed to expose the failure using extensive simulations. _ The failure was caused by reusing a flawed component. This is true as well but, because of physical characteristics of the Ariane 4, this flaw had never become apparent. There had been many successful Ariane 4 flights, using essentially the same SRI subsystem. Apparently, reuse is not compositional: the successful use of a component in one environment is no guarantee for successful reuse of that component in another environment. _ The failure was caused by a flaw in the design. The Ariane software follows a typical hardware design philosophy: if a component breaks down, the cause is assumed to be random and it is handled by shutting down that part and invoking a backup component. In the case of a software failure, which is not random, an identical backup is of little use. For the software part, a different line might have been followed. For instance, the component could be asked to give its best estimate of the required information. 4.2 Therac-25 The Therac-25 is a computer-controlled radiation machine. It has three modes: _ field-light mode. This position merely facilitates the correct positioning of the patient. _ electron mode. In electron therapy, the computer controls the (variable) beam energy and current, and magnets spread the beam to a safe concentration. _ photon (X-ray) mode. In photon mode, the beam energy is fixed. A 'beam flattener' is put between the accelerator and the patient to produce a uniform treatment field. A very high current (some 100 times higher than in electron mode) is required on one side of the beam flattener to produce a reasonable treatment dose at the other side. The machine has a turntable which rotates the necessary equipment into position. The basic hazardous situation is obvious from the above: a photon beam is issued by the accelerator, while the beam flattener is not in position. The patient is then treated with a dose which is far too high. This happened several times. As a consequence, several patients have died and others have been seriously injured. One of the malfunctions of the Therac-25 has become known as 'Malfunction 54'. A patient was set up for treatment. The operator keyed in the necessary data on the console in an adjacent room. While doing so, he made a mistake: he typed 'x' (for X-ray mode) instead of 'e' (for electron mode). He corrected his mistake by moving the cursor up to the appropriate field, typing in the correct code and pressing the return key a number of times until the cursor was on the command line again. He then pressed 'B' (beam on). The machine stopped and issued the message 'Malfunction 54'. This particular error message indicates a wrong dose, either too high or too low. The console indicated a substantial underdose. The operator knew that the machine often had quirks, and that these could usually be solved by simply pressing 'P' (proceed). So he did. The same error message appeared again. Normally, the operator would have audio and video contact with the patient in the treatment room. Not this time, though: the audio was broken and the video had been turned off. It was later estimated that the patient had received 16 000--25 000 rad on a very small surface, instead of the intended dose of 180 rad. The patient became seriously ill and died five months later. The cause of this hazardous event was traced back to the software operating the radiation machine. After the operator has finished data entry, the physical set up of the machine may begin. The bending of the magnets takes about eight seconds. After the magnets are put into position, it again checks if anything has changed. If the operator manages to make changes and return the cursor to the command line position within the eight seconds it takes to set the magnets, part of these changes will result in changes in internal system parameters, but the system nevertheless 'thinks' that nothing has happened and simply continues. With the consequences as described above. Accidents like this get reported to the Federal Drugs Administration (FDA). The FDA requested the manufacturer to take appropriate measures. The 'fix' suggested was as follows: Effective immediately, and until further notice, the key used for moving the cursor back through the prescription sequence (i.e. cursor 'UP' inscribed with an upward pointing arrow) must not be used for editing or any other purpose. To avoid accidental use of this key, the key cap must be removed and the switch contacts fixed in the open position with electrical tape or other insulating material.... Disabling this key means that if any prescription data entered is incorrect then an 'R' reset command must be used and the whole prescription reentered. The FDA did not buy this remedy. In particular, they judged the tone of the notification not commensurate with the urgency for doing so. The discussion between the FDA and the manufacturer continued for quite some time before an adequate response was given to this and other failures of the Therac-25. The Therac-25 machine and its software evolved from earlier models that were less sophisticated. In earlier versions of the software, for example, it was not possible to move up and down the screen to change individual fields. Operators noticed that different treatments often required almost the same data, which had to be keyed in all over again. To enhance usability, the feature to move the cursor around and change individual fields was added. Apparently, user friendliness may conflict with safety. In earlier models also, the correct position of the turntable and other equipment was ensured by simple electromechanical interlocks. These interlocks are a common mechanism to ensure safety. For instance, they are used in lifts to make sure that the doors cannot be opened if the lift is in between floors. In the Therac-25, these mechanical safety devices were replaced by software. The software was thus made into a single point of failure. This overconfidence in software contributed to the Therac-25 accidents, together with inadequate software engineering practices and an inadequate reaction of management to incidents. 4.3 The London Ambulance Service The London Ambulance Service (LAS) handles the ambulance traffic in Greater London. It covers an area of over 600 square miles and carries over 5000 patients per day in 750 vehicles. The LAS receives over 2000 phone calls per day, including more than 1300 emergency calls. The system we discuss here is a computer-aided dispatch (CAD) system. Such a CAD system has the following functionality: _ it handles call taking, accepts and verifies incident details including the location of the incident; _ it determines which ambulance to send; _ it handles the mobilization of the ambulance and communicates the details of the incident to the ambulance; _ it takes care of ambulance resource management, in particular the positioning of vehicles to minimize response times. A fully-fledged CAD system is quite complex. In panic, someone might call and say that an accident has happened in front of Foyle's, assuming that everyone knows where this bookshop is located. An extensive gazetteer component including a public telephone identification helps in solving this type of problem. The CAD system also contains a radio system, mobile terminals in the ambulances, and an automatic vehicle location system. The CAD project of the London Ambulance Service was started in the autumn of 1990. The delivery was scheduled for January 1992. At that time, however, the software was still far from complete. Over the first nine months of 1992, the system was installed piecemeal across a number of different LAS divisions, but it was never stable. On 26 and 27 October 1992, there were serious problems with the system and it was decided to revert to a semi-manual mode of operation. On 4 November 1992, the system crashed. The Regional Health Authority established an Inquiry Team to investigate the failures and the history that led to them. They came up with an 80-page report, which reads like a suspense novel. Below, we highlight some of the issues raised in this report. The envisaged CAD system would be a major undertaking. No other emergency service had attempted to go as far. The plan was to move from a wholly manual process -- in which forms were filled in and transported from one employee to the next via a conveyor belt -- to complete automation, in one shot. The scheme was very ambitious. The participants seem not to have fully realized the risks they were taking. Way before the project actually started, a management consultant firm had already been asked for advice. They suggested that a packaged solution would cost $1.5M and take 19 months. Their report also stated that if a package solution could not be found, the estimates should be significantly increased. Eventually, a non-package solution was chosen, but only the numbers from this report were remembered, or so it seems. The advertisement resulted in replies from 35 companies. The specification and timetable were next discussed with these companies. The proposed timetable was 11 months (this is not a typo). Though many suppliers raised concerns about the timetable, they were told that it was non-negotiable. Eventually, 17 suppliers provided full proposals. The lowest tender, at approximately $1M,was selected. This tender was about $700,000 cheaper than the next lowest bid. No one seems to have questioned this huge difference. The proposal selected superficially suggests that the company had experience in designing systems for emergency services. This was not a lie: they had developed administrative systems for such services. The LAS system also was far larger than anything they had previously handled. The proposed system would impact quite significantly on the way ambulance crews carried out their jobs. It would therefore be paramount to have their full cooperation. If the crews did not press the right buttons at the right time and in the right order, chaos could result. Yet, there was very little user involvement during the requirements engineering process. The intended CAD system would operate in an absolutely objective and impartial way and would always mobilize the optimum resource to any incident. This would overcome many of the then present working practices which management considered outmoded and not in the interest of LAS. For instance, the new system would allocate the nearest available resource regardless of the originating station. The following scenario may result: _ John's crew has to go to an accident a few miles east of their home base. _ Once there, they are directed to a hospital a few miles further east to deliver the patient. _ Another call comes in and John happens to be nearest. He is ordered to travel yet a few miles further east. _ And so on. In this way, crews may have to operate further and further away from their home base, and in unfamiliar territory. They lose time, because they take wrong turns, or may even have to stop to ask for directions. They also have further to travel to reach their home station at the end of a shift. Crews didn't like this aspect of the new system. The new system also took away the flexibility local emergency stations had in deciding which resource to allocate. In the new scheme, resource management was fully centralized and handled by the system. So, suppose John runs down to where the ambulances are parked and the computer has ordered him to take car number 5. John is in a hurry and maybe he cannot quickly spot car number 5, or maybe it is parked behind some other cars. So John thinks about this patient waiting for him and decides to take car number 4 instead. This means trouble. The people responsible for those requirements were misguided or naive in believing that computer systems in themselves can bring about such changes in human practices. Computers are there to help people do their job, not vice versa. Operational straitjackets are doomed to fail. The eventual crash on 4 November 1992 was caused by a minor programming error. Some three weeks earlier, a programmer had been working on part of the system and forgot to remove a small piece of program text. The code in itself did no harm. However, it did allocate a small amount of memory every time a vehicle mobilization was generated by the system. This memory was not deal located. After three weeks, all memory was used up and the system crashed. The LAS project as a whole did not fail because of this programmer mistake. That was just the last straw. The project schedule was far too tight. Management of both the London Ambulance Service and the contractor had little or no experience with software development projects of this size and complexity. They were far too optimistic in their assessment of risks. They assumed that all the people who would interact with the system, would do so in exactly the right way, all of the time. They assumed the hardware parts of the system would work exactly as specified. Management decided on the functionality of the system, with hardly any consultation with the people that would be its primary users. Any project with such characteristics is doomed to fail. From the very first day. 4.4 Who Counts the Votes? It's not who votes that counts, it's who counts the votes Josef Stalin Traditional, non-automated election systems leave a paper trail that can be used for auditing purposes: have all votes been counted, have they been counted correctly. Such an audit is done by an independent party. These safeguards serve to build trust in the outcome. But what if these elections are supported by computers? As a voter, you then simply press a button. But what next? The recording and counting is hidden. How do you know your vote is not tinkered with? How can fraud be avoided? For the individual, one then needs a voter ballot, for instance a piece of paper similar to an ATM receipt, that serves to verify the voter's choice. The ballots of all voters may next be used in an independent audit of the election outcome. Most automated election systems of today do not provide these safeguards. What if we go one step further, and provide our voters with a web application to place their votes? Below is a story about a real system of this kind. The application was developed in Java. Due to governmental regulations, the voting model implemented mimicked the traditional one. The application maintains a voting register containing identifications of all voters, and a ballot box in which the votes are stored. One of the regulations that the system had to comply with is anonymity: a vote in the ballot box should not be traceable to a name in the voters' register. Another regulation concerns security: both registers have to be stored separately. The technical design envisaged two separate databases, one for the voters and one for the ballots. Placing a vote and marking a voter as 'has voted' should be performed in a single transaction: either both actions are done, or neither of them. This design would cater for the correctness requirement: the number of votes in the ballot box equals the number of voters being marked 'has voted'. At least, this is what we hoped for. Tests of the system though showed that, seemingly at haphazard moments in time, there were more votes in the ballot box than there were voters marked as 'has voted'. So the system allowed voters more than one vote. Taking a look under the hood, a coding error was revealed in the voting process. Part of the algorithm ran as follows: 1. Identify the voter. 2. Match the voter with an entry in the register. 3. If a match is found, check that (s)he has not voted yet. The test in the latter step had the form voter.getIdentifi ation()==identifi ation() i nstead of equals(voter.getIdentifi ation()==identifi ation()) In other words, references were compared, rather than actual values. This is one way to win the elections. 5. Software Engineering Ethics Suppose you are testing part of a big software system. You find quite a few errors and you're certainly not ready to deliver. However, your manager is pressing you. The schedule has already slipped by quite a few weeks. Your manager in turn is pressed by his boss. The customer is eagerly awaiting delivery of the system. Your manager suggests that you should deliver the system as is, continue testing, and replace the system by a better version within the next month. How would you react to this scheme? Would you simply give in? Argue with your manager? Go to his boss? Go to the customer? The development of complex software systems involves many people: software developers, testers, technical managers, general managers, customers, etc. Within this temporary organization, the relationship between individuals is often asymmetrical: one person participating in the relationship has more knowledge about something than the other. For example, a software developer has more knowledge about the system under construction than his manager. Such an asymmetric relationship asks for trust: if the developer says that development of some component is on schedule, his manager cannot but believe this message. At least for a while. Such reliance provides opportunities for unethical behavior, such as embezzlement. This is the more so if there also is a power relationship between these individuals. It is not surprising then that people within the software engineering community have been discussing a software engineering code of ethics. Two large organizations of professionals in our field, the IEEE Computer Society and ACM, have jointly developed such a code. The short version of this code is given in FIG. 5. In the long version of the code, each of the principles is further refined into a set of clauses. Some of these clauses are statements of aspiration: for example, a software engineer should strive to fully understand the specifications of the software on which he works. Aspirations direct professional behavior. They require significant ethical judgment. Other clauses express obligations of professionals in general: for example, a software engineer should, like any other professional, provide service only in areas of his competence. A third type of clause is directed at specific professional behavior within software engineering: for example, a software engineer should ensure realistic estimates of the cost and schedule of any project on which he works. There are a number of clauses which bear upon the situation of the tester mentioned above: _ Approve software only if you have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life or privacy or harm the environment (clause 1.031 ). _ Ensure adequate testing, debugging, and review of software and related documents on which you work (clause 3.10). Preamble The short version of the code summarizes aspirations at a high level of 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 FIG. 5 Software engineering code of ethics _ As a manager, do not ask a software engineer to do anything inconsistent with this code of ethics (clause 5.11). _ Be accurate in stating the characteristics of software on which you work, avoiding not only false claims but also claims that might be supposed to be speculative, vacuous, deceptive, misleading, or doubtful (clause 6.07). The code is not a simple algorithm to discriminate between acceptable and unacceptable behavior. Rather, the principles stated should influence you, as a software engineer, to consider who is affected by your work. The software you develop affects the public. The health, safety and welfare of the public is the primary concern of this code of ethics. Adhering to this, or a similar, code of ethics is not something to merely consider on a Friday afternoon. It should become a way of life. The code not only addresses software engineers. It also addresses managers, in that the code indicates what might reasonably be expected from professional software engineers. 6. Quo Vadis? A lot of progress has been made over the past 30 years. For each of the major phases, numerous techniques and tools have been developed. A number of these have found widespread use. In their assessment of design and coding practices for example, DeMarco and Lister found that a number of widely acclaimed techniques (such as the use of small units, strong component binding and structured programming) are indeed applied in practice and pay off (DeMarco and Lister, 1989). However, the short sketches in the preceding section (and the more elaborate discussion in the following sections) show that a lot of research is still needed to make software engineering into a truly mature engineering discipline. It takes some time before technology developed in research laboratories gets applied in a routine way. This holds for physical products such as the transistor, but also for methods, techniques, and tools in the area of software technology. The first version of the UNIX operating system goes right back to 1971. Only since the late 1980s, has interest in UNIX spread widely. In the early 1960s, studies of the cost of software were first made. In the 1980s there was a growing interest in quantitative models for estimating software costs (see also the later section on cost estimation). Dijkstra's article on programming as a human activity appeared in 1965. In the late 1970s the first introductory textbooks on structured programming were published. The term software engineering was introduced in 1968. In the 1980s large national and international programs were initiated to foster the transition of this new technology. The above list can be extended with many other examples. This maturation process generally takes at least 10 to 15 years. In a seminal article entitled 'No silver bullet: essence and accidents of software engineering', Brooks (1987) discusses a number of potentially fruitful approaches to dramatically increase software productivity. His main conclusion is: there is no silver bullet. But we need not be afraid of the werewolf either. By a careful study of the many innovations and an investigation of their true merits, a lot of improvements in both quality and productivity can be achieved. The remainder of this text is devoted to a critical assessment of these technological and non-technological developments. Several relatively recent developments have a dramatic impact on the field: _ The rise of agile methods. As noted before in this section, the term software engineering induces an orderly, factory-like approach to software development. This ignores the fact that for many a project, it is impossible to state the requirements upfront. They emerge as we go along. Armour (2001) compares traditional software development with shooting down a Zeppelin, and agile approaches with shooting down a supersonic plane. To shoot down a Zeppelin, we collect information on altitude, distance, velocity and the like, relay this information to the gun, aim, and shoot. This approach does not work for supersonic planes. We do not know where the intercept will be, and the missile will have to change direction while in the air. It is a challenge to try to successfully combine engineering and craft-like approaches to software development. _ There is shift from producing software to using software. Time-to-market, cost, and sheer complexity encourage organizations to assemble systems out of existing components, rather than developing those components from scratch. On one hand, builders build (pieces of) software, on the other hand integrators integrate those pieces into end-user applications. As one consequence, consumers of software often do not talk to developers anymore. Requirements come from a variety of other sources, such as helpdesk call-log analysis or market research. To the consumer, the software development process is not interesting any more, only the resulting product counts. This shift has given rise to new topics within software engineering, such as Component Based Software Development (CBSD), Commercial Off-The-Shelve (COTS) components, Software Product Lines (SPL), and services. _ Software development is becoming more heterogeneous. In the old days, a software development organization had everything under control. Or so it thought. Nowadays, software is being developed by teams scattered across the globe. Part of it may be outsourced to a different organization. Software incorporates components acquired from some other supplier, or services found on the Web. As a consequence, one is not in control anymore. To close this section is a list of important periodicals that contain material which is relevant to the field of software engineering: - Transactions on Software Engineering (IEEE), a monthly periodical in which research results are reported; - Software (IEEE), a bimonthly journal which is somewhat more general in scope; - Software Engineering Notes, a bimonthly newsletter from the ACM Special Interest Group on Software Engineering; - Transactions on Software Engineering and Methodology (ACM), a quarterly journal which reports research results. - The Journal of Systems and Software (Elsevier), a monthly journal covering both research papers and reports of practical experiences; - Proceedings of the International Conference on Software Engineering (ACM/IEEE), proceedings of the most important international conference in the field, organized every year; - Proceedings of the International Conference on Software Maintenance (IEEE), organized yearly; - Software Maintenance and Evolution: Research and Practice (Wiley), bimonthly journal devoted to topics in software maintenance and evolution. 7. Summary Software engineering is concerned with the problems that have to do with the construction of large programs. When developing such programs, a phased approach is followed. First, the problem is analyzed, and then the system is designed, implemented and tested. This practice has a lot in common with the engineering of physical products. Hence the term software engineering. Software engineering, however, also differs from the engineering of physical products in some essential ways. Software models part of the real world surrounding us, like banking or the reservation of airline seats. This world around us changes over time. So the corresponding software has to change too. It has to evolve together with the changing reality. Much of what we call software maintenance, actually is concerned with ensuring that the software keeps pace with the real world being modeled. We thus get a process model in which we iterate earlier phases from time to time. We speak about the software life cycle. Agile methods, reuse of components, and globalization are some of the relatively recent trends that have a huge impact on the way we view the field. There is a shift from producing software to using software. A major consequence hereof is that a development organization looses control over what it delivers. 8. Further Reading Johnson (1998) describes the early history of the software industry. The more recent state of the practice is described in (Software, 2003). For amore elaborate discussion of the differences and similarities between software engineering and a mature engineering discipline, viz. bridge design, see (Spector and Gifford, 1986). (Leveson, 1992) compares software engineering with the development of high-pressure steam engines. The four kinds of maintenance activities stem from (Lientz and Swanson, 1980). The Ariane failure is described in (Jezequel and Meyer, 1997). I found the report of the Inquiry Teamat http://www.nes.fr/ARCHIVES/news/rapport 501.html An elaborate discussion of the Therac-25 accidents can be found in (Leveson and Turner, 1993). The Inquiry into the London Ambulance Service is described in (Page et al., 1993). (Neumann, 1995) is a book wholly devoted to computer-related risks. The bimonthly ACM Software Engineering Notes contains a column 'Risks to the public in computer systems', edited by Peter Neumann, which reports on large and small catastrophes caused by automation. (Flowers, 1996) is a collection of stories about information systems that failed, including the LAS system. (Kohno et al., 2004) and (Raba, 2004) discuss problems with one specific electronic voting system. (Petroski, 1994) is a wonderful book on failures in engineering. (Software, 1999) is a special issue with stories about successful IT projects. The ACM/IEEE Software Engineering code of ethics is discussed in (Gotterbarn, 1999).The text of the code can also be found here: http://computer.org/tab/seprof/ode.htm (Epstein, 1997) is a collection of (fictional) stories addressing the interaction between ethics and software engineering. (Oz, 1994) discusses ethical questions of a real-life project. Exercises 1. Define the term software engineering. 2. What are the essential characteristics of software engineering? 3. What are the major phases in a software development project? 4. What is the difference between verification and validation? 5. Define four kinds of maintenance activity. 6. Why is the documentation of a software project important? 7. Explain the 40--20--40 rule of thumb in software engineering. 8. What is the difference between software development and software maintenance? 9. Do you think the linear model of software development is appropriate? In which cases do you think an agile approach is more appropriate? You may wish to reconsider this issue after having read the remainder of this text. 10. Discuss the major differences between software engineering and some other engineering discipline, such as bridge design or house building. Would you consider state-of-the-art software engineering as a true engineering discipline? 11. Quality and productivity are major issues in software engineering. It is often advocated that automated tools (CASE tools) will dramatically improve both quality and productivity. Study a commercial CASE tool and assess the extent to which it improves the software development process and its outcome. 12. Medical doctors have their Hippocratic oath. Could a similar ethical commitment by software engineers be instrumental in increasing the quality of software systems? 13. Suppose you are involved in an office automation project in the printing industry. The system to be developed is meant to support the work of journal editors. The management objective for this project is to save labor cost; the editors' objective is to increase the quality of their work. Discuss possible ramifications of these opposing objectives on the project. You may come back to this question after having read section 9 or (Hirschheim and Klein, 1989). 14. Discuss the difference between requirements-based software development and market-driven software development. 15. Discuss the impact of globalization on software development. 16. Study both the technical and user documentation of a system at your disposal. Are you satisfied with them? Discuss their possible shortcomings and give remedies to improve their quality. 17. Take a piece of software you wrote more than a year ago. Is it documented adequately? Does it have a user manual? Is the design rationale reflected in the technical documentation? Can you build an understanding of the system from its documentation that is sufficient for making non-trivial changes to it? Repeat these questions for a system written by one of your colleagues. 18. Try to gather quantitative data from your organization that reveals how much effort is spent on various kinds of maintenance activity. Are these data available at all? If so, is the pattern like that sketched in section 3? If not, can you explain the differences? 19. A 1999 Computer Society survey lists the following candidate fundamental principles of software engineering: A. Apply and use quantitative measurements in decision-making. B. Build with and for reuse. C. Control complexity with multiple perspectives and multiple levels of abstraction. D. Define software artifacts rigorously. E. Establish a software process that provides flexibility. F. Implement a disciplined approach and improve it continuously. G. Invest in the understanding of the problem. H. Manage quality throughout the life cycle as formally as possible. I. Minimize software components interaction. J. Produce software in a stepwise fashion. K. Set quality objectives for each deliverable product. L. Since change is inherent to software, plan for it and manage it. M. Since tradeoffs are inherent to software engineering, make them explicit and document them. N. To improve design, study previous solutions to similar problems. O. Uncertainty is unavoidable in software engineering. Identify and manage it. For each of these principles, indicate whether you (strongly) agree or (strongly) disagree, and why. You may wish to re-appraise these principles after having studied the rest of this guide. PREV. | NEXT Also see: |