1. Software Engineering: The Production of Quality Software by Shari Pfleeger, 2nd Edition, Macmillan, 1991, ISBN 0-02-395115-X. hsrender@happy.colorado.edu: Like #2&#3, had the best explanations of what I want to cover (different engineering lifecycles, methods, and tools).
2. Software Engineering: A Practitioner's Approach by Roger Pressman, 4th Edition, McGraw-Hill, 1996, ISBN 0070521824
3. hsrender@happy.colorado.edu: (on 2nd edition): Like #1&#3, had the best explanations of what I want to cover (different engineering lifecycles, methods, and tools).
4. robb@iotek.uucp (Robb Swanson): The definitive book on the subject as far as I'm concerned.
5. johnson@aplcen.apl.jhu.edu (Michelle Johnson): A good text book as well as reference.
6. Software Systems Engineering by Andrew Sage and James D. Palmer.
7. hsrender@happy.colorado.edu: Like #1&#2, had the best explanations of what I want to cover (different engineering lifecycles, methods, and tools).
8. Fundamentals of Software Engineering by Ghezzi, Jayazeri and Mandrioli, Prentice-Hall, 1991
9. hsrender@happy.colorado.edu: Like #5, good, and covered the issue of specifications and verification better, but at the expense of other aspects of the development process. I may use one of them for a graduate course in software engineering.
10. nancy@murphy.ICS.UCI.EDU (Nancy Leveson): Better than Sommerville, although I like much of Sommerville.
11. Software Engineering with Abstractions by Valdis Berzins and Luqi, Addison Wesley, 1991, 624 pages.
12. hsrender@happy.colorado.edu: Like #4, good, and covered the issue of specifications and verification better, but at the expense of other aspects of the development process. I may use one of them for a graduate course in software engineering.
13. straub@cs.UMD.EDU (Pablo A. Straub): Both this and #9 have a good emphasis on using formal techniques (i.e., doing engineering properly), but they do not disregard informal methods; chapters are roughly organized around the traditional lifecycle. #5 is longer and can be used in a two-term sequence or for graduate students (it's possible to use it in a one-term undergrad course by covering only part of the material). One thing I like is that management and validation is given in all chapters, so that these activities are integrated into the development process. Emphasizes the use of formally specified abstractions. Uses the authors' specification language (Spec) to develop a project in Ada.
14. Software Engineering by Ian Sommerville, Addison-Wesley, ISBN 0-201-17568-1
15. hsrender@happy.colorado.edu: Our current text, and my basic problem with it is the vague way it covers many of the topics.
16. Software Engineering with Student Project Guidance by Barbara Mynatt
17. hsrender@happy.colorado.edu: Like #8, not bad, but fairly low-level and doesn't cover many tools and techniques I consider valuable.
18. Software Engineering by Roger Jones
19. hsrender@happy.colorado.edu: Like #7, not bad, but fairly low-level and doesn't cover many tools and techniques I consider valuable.
20. Software Engineering: Planning for Change by David Alex Lamb, Prentice-Hall, 1988, 298 pages.
21. straub@cs.UMD.EDU (Pablo A. Straub): Both this and #5 have a good emphasis on using formal techniques (i.e., doing engineering properly), but they do not disregard informal methods; chapters are roughly organized around the traditional lifecycle. #9 has the advantage of being shorter, yet covering most relevant topics (lifecycle phases, formal specs, v&v, configurations, management, etc.). It is very appropriate for an undergrad course. It emphasizes that maintenance is a given and should be taken into account (hence the title). Several specification techniques are covered and used to develop a project in Pascal.
22. A Practical Handbook for Software Development by N.D. Birrell and M.A. Ould, Cambridge University Press, 1985/88. ISBN 0-521-34792-0 (Paper cover); ISBN 0-521-25462-0 (Hard cover).
23. ewoods@hemel.bull.co.uk (Eoin Woods):
24. Fundamentals of Computing for Software Engineers by Eric S. Chan & Murat M. Tanik, Van Nostrand Reinhold.
25. kayaalp@csvax.seas.smu.edu (Mehmet M. Kayaalp MD):
26. Classic and Object-Oriented Software Engineering, 3rd Edition, by Stephen R. Schach, Richard D. Irwin, Inc. (ISBN 0-256-18298-1), 1996. Advertised as senior/first year graduate level, emphasizing the object-oriented paradigm, metrics, CASE tools, testing, and maintenance.
27. Practical Software Engineering by Stephen R. Schach, Aksen Associates and Richard D. Irwin Inc. (ISBN 0-256-11455-2), 1992. Advertised as sophomore through senior level, emphasizing teams, maintenance, reuse, CASE tools.

Function points and feature points are methods of estimating the "amount of functionality" required for a program, and are thus used to estimate project completion time. The basic idea involves counting inputs, outputs, and other features of a description of functionality. Bruno Peeters has collected a biblography on function points.

If interested, for a fee you can join:

International Function Point Users Group
5008-28 Pine Creek Drive
Blendonview Office Park
Westerville, Ohio  43081-4899
614-895-7130
Home page

The appendices of the latter give rules for counting procedural source code, as well as rules for counting function points and feature points. The following study, cited in Boehm's Software Engineering Economics, claims that anomalies that seriously "fool" the LOC metric show up rarely in real code.

Licencing isn't currently required for computing professionals; some people would like to see some jobs require it, as with established branches of engineering. Others don't like government intervention, and/or believe many people who wouldn't get licenced are perfectly competent.

Computing professionals in the USA have had a certification program for years, administered by the Institute for Certification of Computer Professionals (708-299-4227), a meta-organization with representatives from ACM, IEEE-CS, ADAPSO, ICCA, IACE, AIM, DPMA, AISP, COMMON, ASM, CIPS, and AWC. There are three certificates aimed at different broad types of practitioner, and many areas of specialization. To keep a certificate requires at least 40 hours of continuing education each year; credit can also be obtained for self-study, teaching, publication, etc.

ISO, ANSI, and IEEE standards are usually sold to raise some of the funds that the various national and international standards bodies (who usually own the copyright) need to keep afloat; thus they are not normally available electronically. Also, the organizations are concerned that electronic copies would make it too easy for people to disseminate doctored versions of the standards.

Some IEEE standards are available by annual electronic subscription; see http://standards.ieee.org/catalog/olis/

For ITU (formerly CCITT) standards, see the ITU gopher server,