Consolidated Reference List for the Software Engineering Body of Knowledge, Pt. 2

This post contains the second half of a somewhat annotated version of the Consolidated Reference List for the IEEE Software Engineering Body of Knowledge (SWEBOK). You may want to start with the previous half.

19. A. Lopez-Ortiz. (1998, July 22, 2010). Algebraic Structures. Available: http://www.cs.uwaterloo.ca/~alopez-o/math-faq/mathtext/node6.html.

    This one is more than a tiny bit ridiculous. The link is to the Frequently Asked Questions in Mathematics list from the Sci.Math FAQ Team. The specific link is to the section on algebraic structures: monoids, groups, rings, fields, and ordering. I'm sure that even the Sci.Math FAQ Team would find the reference to their FAQ in this list silly, if not insulting. Is that really all you need to know about abstract mathematics? Why not link to the FAQ's bibliography, one of the texts in it, or even my favorite, A Book of Abstract Algebra?

20. S. McConnell, Code Complete: A Practical Handbook of Software Construction, 2nd ed. Redmond, WA: Microsoft Press, 2004.

    Unlike the previous, this text is completely unsurprising. McConnell's is one of the most popular books on programming and is likely filled with information that a professional software developer cannot live without. I personally don't know; I don't have a copy. You see, when I was first looking at it in a bookstore many years ago, I flipped to the section on recursion to see what he had to say:

    One problem with computer-science textbooks is that they present silly examples of recursion. The typical examples are computing a factorial or computing a Fibonacci sequence. Recursion is a powerful tool, and it's really dumb to use it in either of those cases. If a programmer who worked for me used recursion to compute a factorial, I'd hire someone else. Here's the recursive version of the factorial routine:

    
     int Factorial( int number ) {
        if ( number == 1 ) {
          return 1;
        } else {
          return number * Factorial( number - 1 );
        }
      }
    

    In addition to being slow and making the use of run-time memory unpredictable, the recursive version of this routine is harder to understand than the iterative version, which follows:

    
      int Factorial( int number ) {
        int intermediateResult = 1;
        for ( int factor = 2; factor <= number; factor++ ) {
          intermediateResult = intermediateResult * factor;
        }
        return intermediateResult;
      }
    

    (Emphasis mine.) Now, where to start with this passage? Recursion is a powerful tool, and in some programming languages that McConnell may not be familiar with, it's fundamental; there may not even be any other iteration structures. So, whether it's dumb to use it in any specific case is a more difficult question than he seems to think. Heck, even most decent modern C compilers include tail call optimization, so the speed and memory use of recursion is an open question. On the other hand, McConnell previously presented as a good use of recursion a maze-solving function; maze solving is an application of state-space search, which has a simple, clear, and wildly flexible implementation based on a priority queue. Further, I find it simply bizarre that McConnell believes a recursive version of factorial is "harder to understand" than the iterative version. Quick! Prove to me that his two versions actually compute a factorial:

    \[ n! = \begin{array}{lr} 1 & \textrm{if \(n\) = 1} \\ n * (n-1)! & \textrm{if \(n\) > 1} \end{array} \]

    Finally, there's the whole "If a programmer who worked for me...I'd hire someone else" thing. The sections before and after recursion are on multiple returns in a routine and goto's; I'm afraid to look at either.

21. S. J. Mellor and M. J. Balcer, Executable UML: A Foundation for Model-Driven Architecture, 1st ed. Boston: Addison-Wesley, 2002.

    This is another topic that leaves me cold. UML is good enough for what it is, a way of communicating ideas about a project, and I'm certainly a programming language collector. However, I have never felt that UML would make a good programming language, which is exactly what xUML and other executable model languages are.

22. D. C. Montgomery and G. C. Runger, Applied Statistics and Probability for Engineers, 4th ed. Hoboken, NJ: Wiley, 2007.

    (The link is to the fifth edition.) Statistics and I have an uneasy relationship. I know there is a great deal of value in statistical data analysis, as an end itself as well as about the software development process. On the other hand, I don't really know much about the topic, and I reference my previous comments about lacking numerical methods experience and thus my inability to use floating point numbers. Anyway, it's an important topic; this may or may not be a good reference (several of the Amazon reviewers mention errors in the text), and I don't have a better one at hand. Your mileage may vary.

23. J. W. Moore, The Road Map to Software Engineering: A Standards-Based Guide, 1st ed. Hoboken, NJ: Wiley-IEEE Computer Society Press, 2006.

    The Road Map to Software Engineering organizes relevant IEEE software and systems standards, along with standards from other sources, using two frameworks: the SWEBOK Guide's topical knowledge areas and the widely used IEEE/EIA 12207 standard [IEEE Standard for Information Technology - Software Life Cycle Processes].

    The Road Map to Software Engineering allows practitioners to quickly locate the standards pertinent to questions arising in real projects. Providing students with a comprehensive body of knowledge, the text also assists experienced professionals in finding and filling gaps in their understanding.

    Probably a vital reference for those using official standards; probably not something I need.

24. J. Nielsen, Usability Engineering, 1st ed. Boston: Morgan Kaufmann, 1993.

    Jakob Nielsen is a very good writer on usability topics. I own and appreciate a copy of his Designing Web Usability even though my idea of usability seems to differ strongly from others'. I will be getting a copy, since I was not previously aware if this. On the other hand, this is nearly 20 years old; is there no more recent reference?

    Update: I just got a copy of this book, and I am very impressed so far. The emphasis, at least from the parts I have read so far, is on providing basic usability information and usability testing techniques that do not require massive investments of resources. I do not have the book handy while I'm writing this, but if I interpret Nielsen correctly he writes that a (quantifiable) big win can be had by simply observing actual users for a few hours, and by asking them what they think.

25. L. Null and J. Lobur, Essentials of Computer Organization and Architecture, 2nd ed. Sudbury, MA: Jones and Bartlett Publishers, 2006.

    (Link is to the third edition.) I love Linda Null's name, let me get that out of the way. Computer architecture is a topic I know a bit about, and, although I'm not familiar with this book, it does seem to cover most of the bases appropriately. Certainly, if a programmer who worked for me didn't know a good bit of this stuff, I'd hire someone else. But this text seems to relegate parallel and concurrent architectures to a section of a chapter on alternative organizations, which is somewhat surprising given the not-so-recent trend towards those architectures. There doesn't even seem to be anything on pipelines, which is vital for high-performance software. Another book, Computer Organization and Architecture: Designing for Performance by William Stallings, does have extensive coverage of parallel architectures although it looks to be less clear and well organized. Given the choice, I would probably favor clarity over coverage.

26. M. Page-Jones, Fundamentals of Object-Oriented Design in UML, 1st ed. Reading, MA: Addison-Wesley, 1999.

    Object-oriented design and programming are not the end-all of software development strategies. It is not appropriate for everything, and an uncritical use of it is not appropriate for anything. I view it as a technique for managing complexity since is pretty successful at that while bringing along its own complications. I, on the other hand, would prefer to remove complexity. That being said, you will need to know a lot about object-oriented design, and Page-Jones is probably a good-enough teacher. (I have his Practical Guide to Structured Systems Design and don't know of anything wrong with it.) On the other hand, if you need a guide to UML, I prefer UML Distilled: A Brief Guide to the Standard Object Modeling Language by Martin Fowler.

27. G. K. Palshikar, "Applying Formal Specifications to Real-World Software Development," IEEE Software, vol. 18, pp. 89-97, 2001.

    While formal methods are gaining acceptance in the software industry, there is a need for practical guidelines for making the best use of formal specifications. The author provides a few such pragmatic tips for people involved in the industrial use of formal specifications. The 15 guidelines are split into two areas, dealing with process and content. The author also includes a full-page reference for literature available over the Web.

    A very good introduction to the use of formal specification methods. I hope the computer.org link above is available to non-IEEE and non-Computer Society members; if it isn't, please let me know. I am tempted to throw propriety (and copyright) out the window and host a link to this paper myself.

28. S. Redwine, "Security-Oriented Pointwise Changes to SWEBOK Guide," 2009. Available: http://www2.computer.org/cms/Computer.org/SWEBOK/Information-for-Item-Writers-v14.pdf

    The original set of suggested changes to the 2004 SWEBOK to incorporate topics from the new security knowledge area. This paper is probably only useful in conjunction with that version of the SWEBOK guide. As an addition, two of the three referenced texts are Software Security Engineering and Computer Security, already found on this consolidated reference list; the third is Summerville's Software Engineering below. A fourth reference is to "Software Assurance: A Curriculum Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software Version 1.2", edited by Redwine and from the US Department of Homeland Security. (My tax dollars at work!)

29. K. Rosen, Discrete Mathematics and Its Applications, 6th ed. Boston: McGraw-Hill, 2006.

    (Link is to the seventh edition.) Discrete mathematics is probably more important to software developers than, say, differential and integral calculus, and I'm not just saying that because calculus and I didn't really agree back in my undergraduate years. More information is available from the McGraw-Hill site for the book, including a sample chapter.

30. A. Silberschatz, et al., Operating System Concepts, 8th ed. Hoboken, NJ: Wiley, 2008.

    True story: I was at a conference looking at the forthcoming books table and a full professor near me pointed to a copy of a new edition of one of Avi's (Abraham Silberschatz) books and asked "Avi has another kid going to college?" I seem to recall learning operating systems from a previous edition of this text, and databases from another of Avi's books, and I haven't been adversely affected. (The tics have mostly gone away.) They are pretty common, for a good reason, but there are alternatives from Tanebaum, Stallings, Deitel, and probably others that are just as good.

31. I. Sommerville, Software Engineering, 8th ed. New York: Addison-Wesley, 2006.

    (Link is to the ninth edition.) A general text on software engineering, this got good reviews from Dr. Tom Hilburn, who taught the software engineering course at the IEEE Smart Tech mini-conference. It's about 800 pages and should be good to bludgeon many, many infidel software developers, managers, and what-not.

32. The Data and Analysis Center for Software. (2008, July 22, 2010). Goal-Question-Metric (GQM) Approach. Available: https://www.goldpractices.com/practices/gqm/

    GQM is a top-down approach to establish a goal-driven measurement system for software development, in that the team starts with organizational goals, defines measurement goals, poses questions to address the goals, and identifies metrics that provide answers to the questions.... [It] is particularly useful for the following purposes:

    • Understanding and baselining an organization’s software practices
    • Guiding and monitoring software processes
    • Assessing new software engineering technologies
    • Evaluating and certifying improvement activities

    GQM seems to be a general, relatively process-agnostic method for generating metrics for software development processes; it looks interesting. I need to look at it further.

33. S. Tockey, Return on Software: Maximizing the Return on Your Software Investment, 1st ed. Boston: Addison-Wesley, 2004.

    Assuming this book does what it claims, it would be a very good text to have around. Particularly given the recent appearances of "Don't call yourself a programmer" postings, giving career advice on the advantages of appealing to the business side of technical decisions.

    • Estimate how much each proposed software technical decision will cost, and how much it will return.
    • Weigh the time frames for a software decision's costs and benefits against each other to reveal when there might be a more important factor than schedule.
    • Attach a value to quality and produce a rational answer to the question, "How much testing is enough?"
    • Account for risk and uncertainty in software technical decisions, such as when considering a new technology.
    • Communicate your decisions in a way that speaks to the all-important bottom line.

    Also from the back cover:

    "This just what the doctor ordered to help software programs solve the problem of how to introduce engineering economics and business decision-making into their curricula. The economics of software development should not only be part of any computing curriculum they are an essential element of recent accreditation and certification recommendations.

    This book is an accessible and relevant text for any student of software engineering. The style is clear and straightforward and the software examples will be appealing to students and faculty alike. I can't wait to use it in class!"

    Thomas B. Hilburn, Professor
    Department of Computer and Software Engineering
    Embry-Riddle Aeronautical University

    The introduction of the book is available online; I especially like this paragraph:

    In another case I was developing software to monitor radiation at nuclear power plants. Part of that software needed a sorting routine. I wrote a simple insertion sort routine and had that part of the system running in a matter of hours. A coworker insisted on developing a QuickSort routine because "everybody knows that QuickSort is better than insertion sort." At that time (early 1980s) reusable QuickSort routines weren't available; if you wanted one, you had to write it yourself. Unfortunately, QuickSort is a recursive algorithm, and the programming language we were using, Fortran-IV, didn't support recursion. My coworker spent more than a week developing QuickSort in Fortran-IV. Only later did he realize that the list that needed sorting averaged only about 30 entries and was predominantly sorted to begin with. Small lists that are already mostly sorted cause QuickSort to have extremely poor performance, typically worse than simpler algorithms such as insertion sort. Moreover, sorting happened in this system fewer than 50 times a day. Even if QuickSort did perform better than insertion sort, it would take decades for the company to recover its investment. My coworker's effort turned out to be a pretty big waste of the company's money and time.

    This is going onto my shopping cart.

34. G. Voland, Engineering by Design, 2nd ed. Upper Saddle River, NJ: Prentice Hall, 2003.

    This looks to be a very interesting book, and I'm saying that as a Henry Pretrovski addict. Judging by what I can find, it appears to come from the physical object design world.

    The book introduces readers to a broad range of important design topics. It provides numerous cases that illustrate both successes and failures in engineering design; qualitative presentation of engineering practices are easily understood by readers with little technical knowledge, and analytical techniques are given that allow the development and evaluation of proposed engineering solutions. Coverage includes: an overview of engineering design, needs assessment, structuring the search for the problem, structuring the search for a solution (design goals and specifications), acquiring and applying technical knowledge, abstraction and modeling, synthesis, ethics and product liability issues, and hazards analysis and failure analysis. An excellent handbook for design engineers.

    Gerard Voland is Provost and Vice Chancellor at the University of Michigan-Flint. I've got no idea if that is a good thing or a bad thing.

35. K. E. Wiegers, Software Requirements, 2nd ed. Redmond, WA: Microsoft Press, 2003.

    A book about requirements engineering. Keep in mind that, whatever I say about this book, the only reliable way I have found to identify, analyze, and satisfy requirements is by some variant of the "agile", open-source, throw-it-at-the-wall-and-see-what-sticks approach (which cannot with any justice be called prototyping). I do have a copy of the follow-on, More About Software Requirements: Thorny Issues and Practical Advice, and have not seen anything particularly wrong in it. Just not very applicable.

36. J. M. Wing, "A Specifier's Introduction to Formal Methods," Computer, vol. 23, pp. 8, 10-23, 1990.

    I found two links to PDF versions of this paper, one a copy of the article as it appeared in Computer and the other a CMU technical report, CMU-CS-90-136. Pick the way you want to read it, I guess.

    This paper is a decent introduction to formal methods, including examples of a fair number of specific techniques in the last half, as they stood in 1990. There is nothing really wrong with that; there have only been a few major changes in formal methods since then. Z (pronounced "Zed") and communicating sequential processes both appear, and both are as relevant or irrelevant as they ever were. (As an aside, I have a small stack of very good Z books.) I did not see anything covering model checking, and there certainly was nothing on dependently typed programming languages, two of what I believe to be the biggest changes in formal methods. That aside, it is a pretty good read.