Practical Support for CMMI-SW Software Project Documentation Using IEEE Software Engineering Standards [Paperback]

I am in a very large organization that is making all of our projects (at the least) CMMI Maturity level-3 compliant. We have Level-5 software factories (offshore centers), some Level-4 programs/projects, and 1,000s of Level-3 compliant (internally appraised) projects.
However, we have "custom" project management document templates that still rely tremendously on the author's (project manager) previous experience writing these references or LUCK (b/c a lower level grunt is actually writing the document!).
The IEEE project management documents (project management approach, risk and issue management plan, change management plan, etc.) are not perfect, but they ARE based on hundreds of project experiences and years or experience and input from 100s of IEEE member organizations.
This book provides the table of contents from the IEEE documents but Not 100% of the text (you have to spend a few $100usd to be a IEEE member to get the actual templates).
BUT, if you are starting a SEPG (software engineering process group) or Quality Management System (QMS) team dont waste time trying to create your templates from scratch. Step-1, get this book and create the ourline of the documents, step-2 harvest the best examples from your projects and insert the best sample sections into the templates.
Remember that 60-80% of these documents are essentially "boiler-plate" that apply to most of your projects, or projects of a certain type.
I RECOMEND that you fill in your templates with as much of the "boilerplate" as possible and make these management documents as close to "fill in the blank" as possible. Using the IEEE standards as a baseline for the structure and content will help you significantly.

CAVEATS: IEEE standards, like way too many I.T. documents, includes the Glossary section in the beginning of the document. Although this may be helpful to define key words before they are encountered, I find the least obtrusive location for the Glossary is as an Appendix. This is not only a common location for documents in many many other fields, it encourages the glossary to be as small or large as it needs to be, rather than drowning the reader with terms they may already know in the beginning of the document.
DITTO for large Tables and Diagrams. I suggest they are located either in the Appendix or as a separate external file that is maintained separately (and is easily referenced by several documents - something dificult to do if they are buried in a single document).

› Go to Amazon.com to see the review  4.0 out of 5 stars