Just in Case You Wanted to Know Box 1.7
1.12 Ethical Issues
We conclude this chapter on a cautionary note. Software products are developed and maintained by humans. If those individuals are hard working, intelligent, sensible, up to date, and above all, ethical , then the chances are good that the way that the software products they develop and maintain will be satisfactory. Unfortunately, the converse is equally true.
Most societies for professionals have a code of ethics to which all its members must adhere. The two major societies for computer professionals, the Association for Computing Machinery (ACM) and the Computer Society of the Institute of Electrical and Electronics Engineers (IEEE-CS) jointly approved a Software Engineering Code of Ethics and Profes-sional Practice as the standard for teaching and practicing software engineering [IEEE/
ACM, 1999]. It is lengthy, so a short version, consisting of a preamble and eight principles, was also produced. Here is the short version:
Software Engineering Code of Ethics and Professional Practice 2 (Version 5.2) as recommended by the IEEE-CS/ACM Joint Task Force on
Software Engineering Ethics and Professional Practices Short Version
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 tions change the way we act as software engineering professionals. Without the aspira-tions, 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, specifi cation, design, development, testing and maintenance of software a benefi cial 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.
26 Chapter 1 The Scope of Software Engineering
2 © 1999 by the Institute of Electrical and Electronics Engineers, Inc., and the Association for Computing Machinery, Inc.
sch76183_ch01_001-034.indd 26
sch76183_ch01_001-034.indd 26 04/06/10 12:30 PM04/06/10 12:30 PM
3. Product —Software engineers shall ensure that their products and related modifi cations meet the highest professional standards possible.
4. Judgment —Software engineers shall maintain integrity and independence in their profes-sional 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 profes-sion 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.
The codes of ethics of other societies for computer professionals express similar senti-ments. It is vital for the future of our profession that we adhere rigorously to such codes of ethics.
In Chapter 2 , we examine various life-cycle models to shed further light on the differ-ences between the classical and the object-oriented paradigm.
Chapter Review
Software engineering is defi ned (Section 1.1) as a discipline whose aim is the production of fault-free software that satisfi es the user’s needs and is delivered on time and within budget. To achieve this goal, appropriate techniques have to be used throughout software production, including when performing analysis (specifi cation) and design (Section 1.4) and postdelivery maintenance (Section 1.3). Software engineering addresses all the steps of the software life cycle and incorporates aspects of many different areas of human knowledge, including economics (Section 1.2) and the social sciences (Section 1.5).
There is no separate planning phase (Section 1.6), no testing phase (Section 1.7), and no documenta-tion phase (Secdocumenta-tion 1.8). In Secdocumenta-tion 1.9, objects are introduced, and a comparison between the classi-cal and object-oriented paradigms is made. Then the object-oriented paradigm is evaluated (Section 1.10). Next, in Section 1.11, the terminology used in this book is explained. Finally, ethical issues are discussed in Section 1.12.
For Further Reading
The earliest source of information on the scope of software engineering is [Boehm, 1976]. The future of software engineering is discussed in [Finkelstein, 2000]. The current state of the practice of software engineering is described in a variety of articles in the November–December 2003 issue of IEEE Soft-ware. An investigation of the factors leading to successful software development appears in [Procac-cino, Verner, and Lorenzet, 2006].
For a view on the importance of postdelivery maintenance in software engineering and how to plan for it, see [Parnas, 1994]. Software development for COTS-based products is the subject of [Brownsword, Oberndorf, and Sledge, 2000]. Acquiring COTS components is described in [Ulkuni-emi and Seppanen, 2004] and in [Keil and Tiwana, 2005]. Risk management when software is devel-oped using COTS components is described in [Li et al., 2008]. The July–August 2005 issue of IEEE Software contains six articles on integrating COTS components into software products, including [Donzelli et al., 2005] and [Yang, Bhuta, Boehm, and Port, 2005]. A reassessment of risk manage-ment appears in [Bannerman, 2008].
Risks in enterprise systems are described in [Scott and Vessey, 2002] and in information systems in general in [Longstaff, Chittister, Pethia, and Haimes, 2000]. Zvegintzov [1998] explains just how little accurate data on software engineering practice actually are available.
The fact that mathematics underpins software engineering is stressed in [Devlin, 2001]. The importance of economics in software engineering is discussed in [Boehm and Huang, 2003].
The November–December 2002 issue of IEEE Software contains a number of articles on software engineering economics.
Two classic books on the social sciences and software engineering are [Weinberg, 1971] and [Shneiderman, 1980]. Neither book requires prior knowledge of psychology or the behavioral sci-ences in general.
Brooks’s [1975] timeless work, The Mythical Man-Month , is a highly recommended introduction to the realities of software engineering. The book includes material on all the topics mentioned in this chapter.
An excellent introduction to open-source software is [Raymond, 2000]. Paulsen, Succi, and Eberlein [2004] present an empirical study comparing open- and closed-source software products.
Reuse of open-source components is described in [Madanmohan and De’, 2004]. A variety of articles on open-source software appears in the January/February 2004 issue of IEEE Software and in issue No. 2, 2005, of IBM Systems Journal . The issue of whether open-source software leads to increased security is discussed in [Hoepman and Jacobs, 2007]. The interplay between business and open-source software is the subject of [Watson et al., 2008], [Ven, Verelst, and Mannaert, 2008], and [Wesselius, 2008].
An excellent introduction to the object-oriented paradigm is [Budd, 2002]. Three successful projects carried out using the object-oriented paradigm are described in [Capper, Colgate, Hunter, and James, 1994], with a detailed analysis. A survey of the attitudes of 150 experienced software developers toward the object-oriented paradigm is reported in [Johnson, 2000]. With regard to eth-ics, an ethical code common to both business and software professionals is presented in [Payne and Landry, 2006].
28 Chapter 1 The Scope of Software Engineering
acceptance testing 7
sch76183_ch01_001-034.indd 28 04/06/10 12:30 PM04/06/10 12:30 PM
1.1 You are in charge of automating a multi-site architectural practice. The cost of developing the software has been estimated to be $530,000. Approximately how much additional money will be needed for postdelivery maintenance of the software?
1.2 Is there a way of reconciling the classical temporal defi nition of maintenance with the opera-tional defi nition we now use? Explain your answer.
1.3 You are a software-engineering consultant. The chief information offi cer of a regional gaso-line distribution corporation wants you to develop a software product that will carry out all the accounting functions of the company and provide online information to the head offi ce staff re-garding orders and inventory in the various company storage tanks. Computers are required for 21 accounting clerks, 15 order clerks, and 37 storage tank clerks. In addition, 14 managers need access to the data. The company is willing to pay $30,000 for the hardware and the software to-gether and wants the complete software product in 4 weeks. What do you tell him? Bear in mind that your company wants his corporation’s business, no matter how unreasonable his request.
1.4 You are a vice-admiral in the Velorian Navy. It has been decided to call in a software develop-ment organization to develop the control software for a new generation of ship-to-ship missiles.
You are in charge of supervising the project. To protect the government of Veloria, what clauses do you include in the contract with the software developers?
1.5 You are a software engineer whose job is to supervise the development of the software in Prob-lem 1.4. List ways your company can fail to satisfy the contract with the navy. What are the probable causes of such failures?
1.6 Nine months after delivery, a fault is detected in the software of a product that analyzes mRNA using the Stein–Röntgen reagent. The cost of fi xing the fault is $18,900. The cause of the fault is an ambiguous sentence in the specifi cation document. Approximately how much would it have cost to correct the fault during the analysis phase?
1.7 Suppose that the fault in Problem 1.6 had been detected during the implementation phase.
Approximately how much would it have cost to fi x then?
1.8 You are the president of an organization that builds large-scale software. You show Figure 1.6 to your employees, urging them to fi nd faults early in the software life cycle. Someone responds that it is unreasonable to expect anyone to remove faults before they have entered the product.
For example, how can anyone remove a fault while the design is being produced if the fault in question is a coding fault? What do you reply?
1.9 Describe a situation in which the client, developer, and user are the same person.
1.10 What problems can arise if the client, developer, and user are the same person? How can these problems be solved?
1.11 What potential advantages accrue if the client, developer, and user are the same person?
1.12 Look up the word system in a dictionary. How many different defi nitions are there? Write down those defi nitions that are applicable within the context of software engineering.
1.13 It is your fi rst day at your fi rst job. Your manager hands you a program listing and says, “See if you can fi nd the bug.” What do you reply?
1.14 You are in charge of developing the product in Problem 1.1. Will you use the object-oriented paradigm or the classical paradigm? Give reasons for your answer.
1.15 Instead of implementing component c9 of a software product, the developers decide to buy a COTS component with the same specifi cations as component c9. What are the advantages and disadvantages of this approach?
1.16 Instead of implementing component c37 of a software product, the developers decide to uti-lize an open-source component with the same specifi cations as component c37. What are the advantages and disadvantages of this approach?
1.17 Object P invokes method m1 of object Q. Suppose we wish to reuse object P in a new soft-ware product. Can P be reused without reusing Q as well? What does this say about objects as
“independent entities” (as stated in Section 1.9)?
1.18 Is it correct to state that, as a consequence of Linus’s Law, all open-source software is of high quality?
1.19 (Term Project) Suppose that the product for Chocoholics Anonymous of Appendix A has been implemented exactly as described. Now the product has to be modifi ed to include endocrinolo-gists as providers. In what ways will the existing product have to be changed? Would it be better to discard everything and start again from scratch?
1.20 (Readings in Software Engineering) Your instructor will distribute copies of Schach et al.
[2003]. What is your opinion of the relative merits of results based on managers’ estimates compared to results computed from actual data?
30 Chapter 1 The Scope of Software Engineering
[Bannerman, 2008] P. L. BANNERMAN, “Risk and Risk Management in Software Projects: A Reas-sessment,” Journal of Systems and Software 81 (December 2008), pp. 2118–33.
[Boehm, 1976] B. W. BOEHM, “Software Engineering,” IEEE Transactions on Computers C-25 (December 1976), pp. 1226–41.
[Boehm, 1979] B. W. BOEHM, “Software Engineering, R & D Trends and Defense Needs,” in:
Research Directions in Software Technology , P. Wegner (Editor), The MIT Press, Cambridge, MA, 1979.
[Boehm, 1980] B. W. BOEHM, “Developing Small-Scale Application Software Products: Some Ex-perimental Results,” Proceedings of the Eighth IFIP World Computer Congress, October 1980, IFIP, pp. 321–26.
[Boehm, 1981] B. W. BOEHM, Software Engineering Economics, Prentice Hall, Englewood Cliffs, NJ, 1981.
[Boehm and Huang, 2003] B. BOEHMAND L. G. HUANG, “Value-Based Software Engineering: A Case Study,” IEEE Computer 36 (March 2003), pp. 33–41.
[Brooks, 1975] F. P. BROOKS, JR., The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, Reading, MA, 1975; Twentieth Anniversary Edition, Addison-Wesley, Reading, MA, 1995.
[Brownsword, Oberndorf, and Sledge, 2000] L. BROWNSWORD, T. OBERNDORF, AND C. A. SLEDGE,
“Developing New Process for COTS-Based Systems,” IEEE Software 17 (July–August 2000), pp. 40–47.
References
sch76183_ch01_001-034.indd 30
sch76183_ch01_001-034.indd 30 10/06/10 2:08 PM10/06/10 2:08 PM
[Budd, 2002] T. A. BUDD, An Introduction to Object-Oriented Programming , 3rd ed., Addison-Wesley, Reading, MA, 2002.
[Capper, Colgate, Hunter, and James, 1994] N. P. CAPPER, R. J. COLGATE, J. C. HUNTER, AND M. F.
JAMES, “The Impact of Object-Oriented Technology on Software Quality: Three Case Histories,”
IBM Systems Journal 33 (No. 1, 1994), pp. 131–57.
[Cutter Consortium, 2002] Cutter Consortium, “78% of IT Organizations Have Litigated,” The Cut-ter Edge , www.cutCut-ter.com/research/2002/edge020409.html, 3 April 09, 2002.
[Daly, 1977] E. B. DALY, “Management of Software Development,” IEEE Transactions on Software Engineering SE-3 (May 1977), pp. 229–42.
[Devlin, 2001] K. DEVLIN, “The Real Reason Why Software Engineers Need Math,” Communica-tions of the ACM 44 (October 2001), pp. 21–22.
[Donzelli et al., 2005] P. DONZELLI, M. ZELKOWITZ, V. BASILI, D. ALLARD, AND K. N. MEYER,
“Evaluating COTS Component Dependability in Context,” IEEE Software 22 (July–August 2005), pp. 46–53.
[Elshoff, 1976] J. L. ELSHOFF, “An Analysis of Some Commercial PL/I Programs,” IEEE Transac-tions on Software Engineering SE-2 (June 1976), pp. 113–20.
[Fagan, 1974] M. E. FAGAN, “Design and Code Inspections and Process Control in the Development of Programs,” Technical Report IBM-SSD TR 21.572, IBM Corporation, December 1974.
[Finkelstein, 2000] A. FINKELSTEIN (Editor), The Future of Software Engineering , IEEE Computer Society Press, Los Alamitos, CA, 2000.
[GJSentinel.com, 2003] “Sallie Mae’s Errors Double Some Bills,” www.gjsentinel.com/news/
content/coxnet/headlines/0522_salliemae.html, May 22, 2003.
[Grady, 1994] R. B. GRADY, “Successfully Applying Software Metrics,” IEEE Computer 27 (September 1994), pp. 18–25.
[Hatton, 1998] L. HATTON, “Does OO Sync with How We Think?” IEEE Software 15 (May–June 1998), pp. 46–54.
[Hoepman and Jacobs, 2007] J.-H. HOEPMANAND B. JACOBS, “Increased Security through Open Source,” Communications of the ACM 50 (January 2007), pp. 79–83.
[IEEE 610.12, 1990] “A Glossary of Software Engineering Terminology,” IEEE 610.12-1990, Insti-tute of Electrical and Electronic Engineers, Inc., 1990.
[IEEE Standards, 2003] “Products and Projects Status Report,” standards.ieee.org/db/status/
status.txt, June 3, 2003.
[IEEE/ACM, 1999] “Software Engineering Code of Ethics and Professional Practice, Version 5.2, as Recommended by the IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practice,” www.computer.org/tab/seprof/code.htm, 1999.
[IEEE/EIA 12207.0-1996, 1998] “IEEE/EIA 12207.0-1996 Industry Implementation of Interna-tional Standard ISO/IEC 12207:1995,” Institute of Electrical and Electronic Engineers, Electronic Industries Alliance, New York, 1998.
[ISO/IEC 12207, 1995] “ISO/IEC 12207:1995, Information Technology—Software Life-Cycle Pro-cesses,” International Organization for Standardization, International Electrotechnical Commis-sion, Geneva, 1995.
3 This and the other URLs cited in this book were correct at the time of going to press. However, Web addresses tend to change all too frequently and without prior or subsequent notifi cation. If this happens, the reader should use a search engine to locate the new URL. The date given in a reference to a URL is the publication date.
[Johnson, 2000] R. A. JOHNSON, “The Ups and Downs of Object-Oriented System Development,”
Communications of the ACM 43 (October 2000), pp. 69–73.
[Josephson, 1992] M. JOSEPHSON, Edison, A Biography , John Wiley and Sons, New York, 1992.
[Kan et al., 1994] S. H. KAN, S. D. DULL, D. N. AMUNDSON, R. J. LINDNER, AND R. J. HEDGER, “AS/400 Software Quality Management,” IBM Systems Journal 33 (No. 1, 1994), pp. 62–88.
[Keil and Tiwana, 2005] M. KEILAND A. TIWANA, “Beyond Cost: The Drivers of COTS Application Value,” IEEE Software 22 (May–June 2005), pp. 64–69.
[Kelly, Sherif, and Hops, 1992] J. C. KELLY, J. S. SHERIF, AND J. HOPS, “An Analysis of Defect Den-sities Found during Software Inspections,” Journal of Systems and Software 17 (January 1992), pp. 111–17.
[La Libre Online, 2007a] “Lalibre.be—Une erreur à 883 millions d’euros,” www.lalibre.be/index.
php?view=article&art_id=305607.
[La Libre Online, 2007b] “Lalibre.be—C’est la faute à l’informatique,” www.lalibre.be/index.
php?view=article&art_id=307021.
[Leveson and Turner, 1993] N. G. LEVESONAND C. S. TURNER, “An Investigation of the Therac-25 Accidents,” IEEE Computer 26 (July 1993), pp. 18–41.
[Li et al., 2008] J. LI, O. P. N. SLYNGSTAD, M. TORCHIANO, M. MORISIO, AND C. BUNSE, “A State-of-the-Practice Survey of Risk Management in Development with Off-the-Shelf Software Compo-nents,” IEEE Transactions on Software Engineering 34 (March–April 2008), pp. 271–86.
[Lientz, Swanson, and Tompkins, 1978] B. P. LIENTZ, E. B. SWANSON, AND G. E. TOMPKINS, “Char-acteristics of Application Software Maintenance,” Communications of the ACM 21 (June 1978), pp. 466–71.
[Longstaff, Chittister, Pethia, and Haimes, 2000] T. A. LONGSTAFF, C. CHITTISTER, R. PETHIA, AND
Y. Y. HAIMES, “Are We Forgetting the Risks of Information Technology?” IEEE Computer 33 (December 2000), pp. 43–51.
[Madanmohan and De’, 2004] T. R. MADANMOHANAND R. DE’, “Open Source Reuse in Commercial Firms,” IEEE Software 21 (November–December 2004), pp. 62–69.
[Mellor, 1994] P. MELLOR, “CAD: Computer-Aided Disaster,” Technical Report, Centre for Software Reliability, City University, London, July 1994.
[Meyer, 1992] B. MEYER, “Applying ‘Design by Contract’,” IEEE Computer 25 (October 1992), pp. 40–51.
[Naur, Randell, and Buxton, 1976] P. NAUR, B. RANDELL, AND J. N. BUXTON (Editors), Software Engineering: Concepts and Techniques: Proceedings of the NATO Conferences , Petrocelli-Charter, New York, 1976.
[Neumann, 1980] P. G. NEUMANN, Letter from the Editor, ACM SIGSOFT Software Engineering Notes 5 (July 1980), p. 2.
[Parnas, 1994] D. L. PARNAS, “Software Aging,” Proceedings of the 16th International Conference on Software Engineering , Sorrento, Italy, May 1994, IEEE, pp. 279–87.
[Paulson, Succi, and Eberlein, 2004] J. W. PAULSON, G. SUCCI, AND A. EBERLEIN, “An Empirical Study of Open-Source and Closed-Source Software Products,” IEEE Transactions on Software Engineering 30 (April 2004), pp. 246–56.
[Payne and Landry, 2006] D. PAYNEAND B. J. L. LANDRY, “A Uniform Code of Ethics: Business and IT Professional Ethics,” Communications of the ACM 49 (November 2006), pp. 81–84.
[Procaccino, Verner, and Lorenzet, 2006] J. D. PROCACCINO, J. M. VERNER, AND S. J. LORENZET,
“Defi ning and Contributing to Software Development Success,” Communications of the ACM (August 2006), pp. 79–83.
32 Chapter 1 The Scope of Software Engineering
sch76183_ch01_001-034.indd 32
sch76183_ch01_001-034.indd 32 04/06/10 12:30 PM04/06/10 12:30 PM
[Raymond, 2000] E. S. RAYMOND, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary , O’Reilly & Associates, Sebastopol, CA, 2000; also avail-able at www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/.
[Rubenstein, 2007] D. RUBENSTEIN, “Standish Group Report: There’s Less Development Chaos Today,” www.sdtimes.com/content/article.aspx?ArticleID=30247, March 1, 2007.
[Schach et al., 2002] S. R. SCHACH, B. JIN, D. R. WRIGHT, G. Z. HELLER, AND A. J. OFFUTT, “Main-tainability of the Linux Kernel,” IEE Proceedings—Software 149 (February 2002), pp. 18–23.
[Schach et al., 2003] S. R. SCHACH, B. JIN, G. Z. HELLER, L. YU, AND J. OFFUTT, “Determining the Distribution of Maintenance Categories: Survey versus Measurement,” Empirical Software Engi-neering 8 (December 2003), pp. 351–66.
[Scott and Vessey, 2002] J. E. SCOTTAND I. VESSEY, “Managing Risks in Enterprise Systems Imple-mentations,” Communications of the ACM 45 (April 2002), pp. 74–81.
[Shapiro, 1994] F. R. SHAPIRO, “The First Bug,” Byte 19 (April 1994), p. 308.
[Shneiderman, 1980] B. SHNEIDERMAN, Software Psychology: Human Factors in Computer and Information Systems , Winthrop Publishers, Cambridge, MA, 1980.
[Spiegel Online, 2004] “Rheinbrücke mit Treppe—54 Zentimeter Höhenunterschied,” www.spiegel.
de/panorama/0,1518,281837,00.html.
[St. Petersburg Times Online, 2003] “Thousands of Federal Checks Uncashable,” www.sptimes.
com/2003/02/07/Worldandnation/Thousands_of_federal_.shtml, February 07, 2003.
[Stephenson, 1976] W. E. STEPHENSON, “An Analysis of the Resources Used in Safeguard System Software Development,” Bell Laboratories, Draft Paper, August 1976.
[Ulkuniemi and Seppanen, 2004] P. ULKUNIEMI, AND V. SEPPANEN, “COTS Component Acquisition in an Emerging Market,” IEEE Software 21 (November–December 2004), pp. 76–82.
[Ven, Verelst, and Mannaert, 2008] K. VEN, I. VERELST, AND H. MANNAERT, “Should You Adopt Open Source Software?” IEEE Software 25 (May–June 2008), pp. 54–59.
[Watson et al., 2008] R. T. WATSON, M.-C. BOUDREAU, P. T. YORK, M. E. GREINER, AND D. WYNN, “The Business of Open Source,” Communications of the ACM 51 (April 2008), pp. 41–46.
[Weinberg, 1971] G. M. WEINBERG, The Psychology of Computer Programming , Van Nostrand Reinhold, New York, 1971.
[Wesselius, 2008] J. WESSELIUS, “The Bazaar inside the Cathedral: Business Models for Internal Markets,” IEEE Software 25 (May–June 2008), pp. 60–66.
[Wirfs-Brock, Wilkerson, and Wiener, 1990] R. WIRFS-BROCK, B. WILKERSON, AND L. WIENER, Designing Object-Oriented Software , Prentice Hall, Englewood Cliffs, NJ, 1990.
[Yang, Bhuta, Boehm, and Port, 2005] Y. YANG, J. BHUTA, B. BOEHM, AND D. N. PORT, “Value-Based Processes for COTS-Based Applications,” IEEE Software 22 (July–August 2005), pp. 54–62.
[Yourdon, 1992] E. YOURDON, The Decline and Fall of the American Programmer , Yourdon Press, Upper Saddle River, NJ, 1992.
[Zelkowitz, Shaw, and Gannon, 1979] M. V. ZELKOWITZ, A. C. SHAW, AND J. D. GANNON, Principles of Software Engineering and Design, Prentice Hall, Englewood Cliffs, NJ, 1979.
[Zvegintzov, 1998] N. ZVEGINTZOV, “Frequently Begged Questions and How to Answer Them,” IEEE Software 15 (January/February 1998), pp. 93–96.