Consolidated Reference List for the IEEE Software Engineering Body of Knowledge
Posted on November 21, 2011 by Tommy McGuire
This is the first half of a none-too-serious annotated bibliography of the references that the IEEE Computer Society has identified as the most important sources for its Software Engineering Body of Knowledge (SWEBOK). (When you get done with this, you can read the second part.) Note: I have not actually read all (or most, for that matter) of these books, nor do I intend to. I will identify those I have, and those I have not are evaluated on what I, as a professional, think of their publicly available information. You have been warned.
- A. Abran, et al., Eds., Guide to the Software Engineering Body of Knowledge. Los Alamitos, CA: IEEE Computer Society, 2004.
This consolidated reference list (if I were a true software engineer, I would have written that as "CRL") is associated with the version 3 of the SWEBOK (which is really too long to type out). However, because that version is still in development, it refers to the previous, 2004 version. The new version is supposed to add knowledge areas on professionalism, software engineering economics, mathematical and computing foundations, and possibly measurement and security, and revise the existing structure. Duck and cover!
- J. H. Allen, et al., Software Security Engineering: A Guide for Project Managers. Upper Saddle River, NJ: Addison-Wesley, 2008.
Yes. Well. So, any book with "managers" in the title leaves me with a sort of squishy feeling, particularly as a reference for practitioners. The advertising text doesn't really help:
One view of secure software is software that is engineered “so that it continues to function correctly under malicious attack” [McGraw 2006] and is able to recognize, resist, tolerate, and recover from events that intentionally threaten its dependability. Broader views that can overlap with software security (for example, software safety, reliability, and fault tolerance) include the notion of proper functioning in the face of unintentional failures or accidents and inadvertent misuse and abuse, as well as reducing software defects and weaknesses to the greatest extent possible regardless of their cause. This book addresses the narrower view.(Emphasis mine.) Personally, I do not really feel I need to "increase [my] awareness and understanding of the security issues in the design and development of software"; rather I need good information on producing secure systems or, better yet, a general approach that leads to secure systems by construction. But then, I suspect I take the broader view described above.
- M. Bishop, Computer Security: Art and Science. Boston: Addison-Wesley, 2002.
This sounds like a much more useful book. It seems to have gotten good reviews in both SysAdmin and by Peter Salus in ;login, and appears to be an attempt at a complete reference tome. There are a couple of chapters available online at Bishop's UC Davis page; Chapter 13: Design Principles leaves me interested.
- Principle of Least Privilege
- Principle of Fail-Safe Defaults
- ...Economy of Mechanism
- ...Complete Mediation
- ...Open Design
- ...Separation of Privilege
- ...Least Common Mechanism
- ...Psychological Acceptability
- B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley, 2003.
This book about agile software development processes also looks pretty interesting. One common complaint about agile methods from traditional or more engineering-oriented developers is that they are undisciplined; a common complaint from agile developers is that more disciplined processes are unusable. Both are ironic, since most methods are followed in name only, in my experience.
- F. Bott, et al., Professional Issues in Software Engineering, 3rd ed. New York: Taylor & Francis, 2000.
Professional Issues in Software Engineering looks like a good reference to, well, professional issues: the profession and professional organizations, economics, contracts, intellectual property, employee relations, health and safety, liability, criminal law, and regulation of personal information are all represented in the table of contents. Now, professional issues may not interest most developers (or anybody else), but they are something that I am beginning to appreciate more, and something that I detect a serious lack of, now that I have moved into less technically-oriented employment. (Ahem.)
- J. G. Brookshear, Computer Science: An Overview, 10th ed. Boston: Addison-Wesley, 2008.
Again, this is an introductory text that doesn't seem to be terribly useful to someone engaged in the profession of creating software systems.
Computer Science: An Overview uses broad coverage and clear exposition to present a complete picture of the dynamic computer science field. Accessible to students from all backgrounds, Glenn Brookshear uses a language-independent context to encourage the development of a practical, realistic understanding of the field. An overview of each of the important areas of Computer Science (e.g. Networking, OS, Computer Architecture, Algorithms) provides students with a general level of proficiency for future courses.On the other hand, it looks like a very good book to give to someone who wants to know what computer science is about. On the other, other hand, however, it seems a little pricey.(The link is to the more-recent 11th edition.)
- D. Budgen, Software Design, 2nd ed. New York: Addison-Wesley, 2003.
I have my own ideas about the concept of software design, which I will keep to myself for the moment. In the mean time, this book appears to be more of a meditation on what "design" is than a useful guide to software designs-man-ship. The three parts of the book are the nature of the design process, transferring design knowledge (which includes a chapter on "some design representations" and a chapter on design patterns), and design practices; the last breaks down into chapters on stepwise refinement, incremental design, structured analysis and design, Jackson Structured Programming, Jackson System Development, object-oriented design, component-based design, and the formal approach to design. Certainly, it seems a limited and idiosyncratic choice of topics.
- E. W. Cheney and D. R. Kincaid, Numerical Mathematics and Computing, 6th ed. Belmont, CA: Brooks/Cole, 2007.
Strangely, I do not know either Ward Cheney or David Kincaid, although I've heard of the latter often enough. Also, I have never taken a course on numerical methods, which by my own rules means that I should never use floating-point numbers. I am afraid all I can say is that this looks like a textbook on numerical methods. Enjoy!
- P. Clements, et al., Documenting Software Architectures: Views and Beyond. Boston: Addison-Wesley, 2002.
This is a text on documenting software architectures. That is probably not as goofy an idea as it sounds, since the architecture of a system is, in the first place, somewhat fundamental to the software, but, in the second, usually hidden behind the mass of trees. The actual architecture of a system may not appear outside of its documentation, and the notation for that documentation may well guide the architecture you get. Note: I'm still reserving my ideas about design and indeed, architecture.
One reviewer on Amazon writes that this book is an extension of the Carnegie Mellon Software Engineering Institute technical report CMU/SEI-2001-TN-01, Documenting Software Architectures: Organization of Documentation Package by a subset of the authors. That document may be a good place to start. (Book link is to the second edition.)
- L. Copeland, A Practitioner's Guide to Software Test Design, 1st ed. Boston: Artech House, 2004.
This book seems to be a decent reference to some various forms of test design, black box and white box. On the other hand, the only references to unit testing are in chapter 1, the testing process, under "testing levels", and the introduction to white box testing. Test-driven development is not mentioned at all. In other words, it is a reference to old-school test methods. Not that those are unnecessary or detrimental, just that they are the kinds of things you run less than frequently, just prior to a release. Knowing how they work will certainly expand your options, even if you are into TDD, and somebody in your project will probably need to know this stuff.
- R. E. Fairley, Managing and Leading Software Projects. Hoboken, NJ: Wiley-IEEE Computer Society Press, 2009.
Some management topics are necessary to development projects: estimating, measuring, and risks. I might just buy it for this sentence on the back cover:
It introduces software development methods, from traditional (hacking, requirements to code, and waterfall) to iterative (incremental build, evolutionary, agile, and spiral), and illustrates and emphasizes how to tailor the development process to specific projects.(Emphasis mine.) On page 54, "hacking" is characterized by a reference to the cartoon with the caption, "You start coding and I'll go find out what they want," which is actually a pretty fair description of one of the few ways I know to reliably come up with a project's requirements.
-  E. Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software, 1st ed. Reading, MA: Addison-Wesley Professional, 1994.
And finally, a book that I own and have read. Now, this is an important book, and contains many good ideas, both for software designs and for communicating those designs. Yet, I am not a pattern-ista. In fact, I am of the set that regards design patterns as work-arounds for poor programming languages. Still, the contents of this book are probably necessary, if you are going to hang around software development for very long.
- T. Gilb and D. Graham, Software Inspection, 1st ed. Reading, MA: Addison-Wesley, 1993.
An inspection is a formal examination of some artifact specifically to detect problems.
Zero-defect software is the Holy Grail of all software developers. It has proved to be an elusive goal - until now. The Inspection techniques illustrated in this book have brought clear benefits in terms of lower (or even zero) defects, higher productivity, better project tracking and improved documentation.Maybe there is a silver bullet, after all.
- P. Grubb and A. A. Takang, Software Maintenance: Concepts and Practice, 2nd ed. River Edge, NJ: World Scientific Publishing, 2003.
Judging by the table of contents, this looks like an interesting book; it includes how new development differs from maintenance, what takes place during maintenance (program understanding, reverse engineering, reuse, testing), and tools. On the other hand, the authors write in the preface, "...challenges that software engineers face when modifying complex software systems...can be seen in the cost of modifying software...[which] can reach 70% of the total life-cycle cost." That number always leaves a strange taste in my mouth, since for any successful project I have encountered, the cost actually asymptotically approaches 100%.
- A. M. J. Hass, Configuration Management Principles and Practice, 1st ed. Boston: Addison-Wesley, 2003.
I am the first to claim that configuration management is one key to any reasonably successful project. However, I suspect that this is not the best book on the subject. The table of contents runs for 18 pages out of 350 or so with several interesting looking sections, but I do not see anything compelling overall. For example, Chapter 22 is "Getting started on configuration management---up to capability level 1" with subsections on "How to get started from nothing" and "First steps toward configuration management", but the next chapter, "Planning configuration management---up to capability level 2" seems to be all about a configuration management plan document, not what to do with the foundation from the previous chapter.
- E. Horowitz, et al., Computer Algorithms, 2nd ed. Summit, NJ: Silicon Press, 2007.
I have never seen this book before. If they had referenced Introduction to Algorithms by Comen, Leiserson, Rivest, and Stein, I would not have said anything at all; that is the book most people would think of, I believe. (Strange but true: that was the one computer science class I ever dropped. After a single class session.) Still, Computer Algorithms looks to be a good book, although at 773 pages of algorithmy goodness, I suspect it's not light reading.
- IEEE-CS/ACM Joint Task Force on Software Engineering Ethics and Professional Practices. (1999, July 22, 2010). Software Engineering Code of Ethics and Professional Practice (Version 5.2).
This one is free, reasonably short, and quick reading. The short version is:
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:Learn it; love it; live it.
- PUBLIC - Software engineers shall act consistently with the public interest.
- 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.
- PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
- JUDGMENT - Software engineers shall maintain integrity and independence in their professional judgment.
- MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
- PROFESSION - Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
- COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
- 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.
- S. H. Kan, Metrics and Models in Software Quality Engineering, 2nd ed. Boston: Addison-Wesley, 2002.
This is another topic that I have never spent much time with. Looking at the table of contents, this text seems to offer a lot of interesting options, although I do not know if it goes into enough detail to actually implement them. Certainly, it cannot be worse than the "time to fix" numbers from various build and bug tracking tools. Chapters 15, 16, 17, and 18, on quality assessments and process improvement, do leave me somewhat concerned about the amount of snake oil involved.
If you are not completely bored yet, you can go to the second half of the list.