- Copyright 2002
- Edition: 1st
-
Book
- ISBN-10: 0-13-065414-0
- ISBN-13: 978-0-13-065414-4
Software planning and specification development: no fluff—just results!
- Create better specifications-with less complexity, and less work!
- Best practices that work with any language or development environment
- CD-ROM exclusive: Software Blueprinter, a powerful software application for real-world specification development
- For all software team members: developers, architects, managers, clients, and software quality specialists
Planning Smarter demystifies software planning, cuts out to the chase, and shows exactly how to create higher quality, more useful specifications with less complexity and less work! Tyson Gill presents a complete blueprint for improving the quality of your software specifications, reducing errors and omissions, simplifying planning, and establishing a rock-solid foundation for any software development project. Coverage includes:
- Understanding the planning process-and why it so often fails
- Getting the planning process "just right" and identifying the best lifecycle approach
- Optimizing the communication that is critical to successful planning
- 13 powerful strategies for more effective requirements development
- Planning in the context of leading software process models: CMM, MSF, UML, and RUP
- Recognizing and making effective use of planning metadata
Planning Smarter is an invaluable resource for every member of the software development project team. It will help executives and clients understand the key factors associated with success-and it will give planners, developers, architects, and team leaders the proven techniques they need to build specifications that work.
CD-ROM INCLUDEDThe accompanying CD-ROM contains Software Blueprinter, a powerful specification development application that embodies the key principles in this book.
Online Sample Chapters
Improving the Planning Process
Project Planning for Successful Software Development
Table of Contents
Preface.
1. About Planning Smarter.
The Companion BooK. Executive SummarY. Getting Acquainted. Acknowledgments.
2. Understanding the Planning Process. The Pathology of Poor Planning. The Vision Document. The Functional Specification. Recognizing a Bad Plan. Excellence Is Attainable. A Software Blueprint.
3. Improving the Planning Process. A Project Planning Plan. Planning Phases. Life-cycle Models. Choosing a Life-cycle Approach. An Adaptive Life-cycle Approach. Process and Role Overlap. Getting Planning Just Right.
4. The Role of Communication in Planning. Software Communications 101. Use Simple Language. Go Look It Up. The Data Dictionary. Anyone Can Pseudocode. Show Me the Prototype! Direct to Blueprint. Effective Requirements Elicitation. Software for Planning. Creative Software Writing.
5. Strategies to Support Effective Planning. Putting Theory into Practice. A Developer Focus. Enlist a Champion. Hire the Cream. Specialize. Trust in Instinct. Collaborate. Catalyze. Work Smarter. Change Facilitation. Living with Estimates. No Silver Bullets. Code Smarter.
6. Software Process Models. Best Practices. The Capability Maturity Model. The Microsoft Solution Framework. The Unified Modeling Language. The Rational Unified Process.
7. Planning Metadata. Using Metadata Effectively. Types of Metadata. Envisioning Phase Metadocuments. Analysis Phase Metadocuments. Design Phase Metadocuments. Architecture Phase Metadocuments. Other Metadocuments.
8. Software and Beyond. Software and the Future. Software and Ethics. Software and Clients. Software and the Secrets Clients Should Know. Software and the CEO. Software and Process Improvement.
9. The Software Blueprinter Application. About Software Blueprinter. Using Software Blueprinter. Applying Software Blueprinter. Possible Enhancements.
10. Wrap Up. Nonnegotiable Demands. On the CD-ROM. Restrictions of Software Use. Join the Discussion. The Last Word.
Appendix: Postmortem Interview and Analysis. References. List of Terms. Index.
Preface
Preface
Did I write this? Other authors have almost certainly experienced that peculiar feeling when they reread their work after having been away from it long enough. As I went and reread Planning Smarter, that feeling definitely struck me. And it was a good feeling. The book does achieve the goals I set out to accomplish. It presents a balanced, sensible, and achievable strategy for software requirements planning set against a stimulating and entertaining industry backdrop.
Despite my satisfaction with the work, I don't for a moment imagine many readers will agree with everything in it. Quite the contrary. Given the astounding variety and range of projects, companies, and individuals involved in software projects, any specific recommendations will only be embraced by a relatively small segment of the industry. I have learned that even seemingly "apple pie" generalities like "error prevention is good" or "project planning is important" elicit strong objections from many professionals.
Since I give you lots of little anecdotes throughout the book, let me warm you up with one here. In teaching my programming class, I generally stress approach and style over specific language syntax. It is your approach to programming that will endure and serve you well as languages evolve and become extinct. In keeping with that philosophy, I was stressing the importance of error prevention, as opposed to mere error handling or trapping, to my students. I mentioned that most errors occur because the programmer makes a false assumption of some kind. I urged them never to assume an error would or could not occur.
One of my students raised his hand and objected angrily. He said he had been programming for 20 years and saw no need for error prevention. He insisted that all errors can be avoided by specifying that the situation should not occur. He went on to turn my assumptions logic back on me by insisting that it would be a false assumption to assume that errors will occur. I was not clever enough to counter his twisted logic on the spot so I simply indicated that I did not agree and got the class back on track. On the last week of class the students demonstrate their class projects. Out of 25 or so projects, only one project was simply too buggy to demonstrate. I'm sure you can guess which one.
What this story reflects is the dramatic range of opinion that exists in our industry. Even the most seemingly reasonable and common sense suggestions are not immune to debate, let alone the many perfectly legitimate and reasonable differences in perspective. There is simply too wide a range of opinion and experience in this industry to hope for consensus.
Nor should there be "one" approach to planning, because every project is unique. What I've tried to do is to provide recommendations that apply to the widest range of projects and permit the greatest degree of flexibility. Despite the dramatic variation that exists, however, there is commonality that is shared by almost every software project. I have tried to focus my recommendations on that core commonality.
Because I have strived for a minimalist approach to planning, many readers will feel that I underemphasize planning. Others will still feel that I overemphasize it. I know this to be true because I have already received this wildly differing feedback from my reviewers. Some felt that my recommendations were far too complex and costly to implement, while others felt I did project planning a disservice by simplifying it so much.
I find the fact that the criticism is evenly mixed between "too much" and "too little" to be a reassuring indicator that I am properly positioned in the center. Is the planning recommended in this book "just right" for you? I hope it is. At the very least, however, it should provide a sound starting point no matter where your needs and inclinations lie on the wide software--planning spectrum. Even if you don't agree with some or all of the recommendations in this book, I am confident that you will be stimulated by it and will hopefully benefit from reading it.
Given this wide and strong range of opinion on the topic of project planning, you may be asking yourself "Why in the world would anyone take on such a project?" Believe me, I have asked myself that same question many times. Although this book is based on considerable experience, it is still an "opinion" book. That makes it much more difficult to write and vulnerable to differing opinion than other kinds of books.
I have written fiction novels in the past. They are a joy because you can say anything you want and no one would think to dispute your version of the "facts." You try to invoke emotions, but no one takes anything in them personally. You don't tell your reader what they should be doing or thinking, at least not directly.
I have also written standard technical books before, which limit themselves to documenting or explaining languages, operating systems, and so on. Those are relatively easy as well because you simply organize and explain the facts. There is no room for interpretation. There is no "right or wrong" there is only "correct or incorrect." There are no emotional, political, and interpersonal issues to complicate the technical ones. There is nothing controversial or delicate to deal with. You don't have to persuade, convince, or justify.
This type of "opinion" book is by far the most difficult to write. You want everyone to take it personally. You want to stimulate emotions and challenge existing ideas. In doing so, you open yourself up to criticism and in the end the best you can hope for is that it has a huge impact on a few people and at least stimulates some others to improve their practices.
Why write it? In the hopes that you might be one of the people who resonates with it.
Why read it? For the same reason.
Enjoy!
Tyson Gill