HAPPY BOOKSGIVING
Use code BOOKSGIVING during checkout to save 40%-55% on books and eBooks. Shop now.
Register your product to gain access to bonus material or receive a coupon.
Software Project Management presents a new management framework uniquely suited to the complexities of modern software development. Walker Royce's pragmatic perspective exposes the shortcomings of many well-accepted management priorities and equips software professionals with state of the art knowledge derived from his twenty years of successful from the trenches project management experience.
This book provides a clear and provocative discussion of the economics, metrics, and management strategies needed to plan and execute a software project successfully. Royce discusses--with refreshing candor--some of the fads, follies, and excesses of the software industry, clearly differentiating proven techniques from obsolete methods. Paired with this insightful examination are compelling arguments for new management approaches that are sure to stimulate debate. The relative impacts of these new techniques are quantified through simple economic analyses, common sense, and anecdotal evidence. The resulting framework strikes a pragmatic balance between theory and practice that can be readily applied in today's challenging development environment. An extensive case study analysis of a large-scale, million-line project--deployed successfully on schedule and under budget using these techniques--further illustrates their application.
Software Project Management provides the software industry with field-proven benchmarks for making tactical decisions and strategic choices that will enhance an organization's probability of success. This book includes:
List of Figures.
List of Tables.
Foreword.
Preface.
I. SOFTWARE MANAGEMENT RENAISSANCE.
1. Conventional Software Management.The Waterfall Model.
In Theory.
In Practice.
Conventional Software Management Performance. 2. Evolution of Software Economics.
Software Economics.
Pragmatic Software Cost Estimation. 3. Improving Software Economics.
Reducing Software Product Size.
Languages.
Object-Oriented Methods and Visual Modeling.
Reuse.
Commercial Components.
Improving Software Processes.
Improving Team Effectiveness.
Improving Automation through Software Environments.
Achieving Required Quality.
Peer Inspections: A Pragmatic View. 4. The Old Way and the New.
The Principles of Conventional Software Engineering.
The Principles of Modern Software Management.
Transitioning to an Iterative Process.
II. A SOFTWARE MANAGEMENT PROCESS FRAMEWORK.
5. Life-Cycle Phases.Engineering and Production Stages.
Inception Phase.
Elaboration Phase.
Construction Phase.
Transition Phase. 6. Artifacts of the Process.
The Artifact Sets.
The Management Set.
The Engineering Sets.
Artifact Evolution over the Life Cycle.
Test Artifacts.
Management Artifacts.
Engineering Artifacts.
Pragmatic Artifacts. 7. Model-Based Software Architectures.
Architecture: A Management Perspective.
Architecture: A Technical Perspective. 8. Workflows of the Process.
Software Process Workflows.
Iteration Workflows. 9. Checkpoints of the Process.
Major Milestones.
Minor Milestones.
Periodic Status Assessments.
III. SOFTWARE MANAGEMENT DISCIPLINES.
10. Iterative Process Planning.Work Breakdown Structures.
Conventional WBS Issues.
Evolutionary Work Breakdown Structures.
Planning Guidelines.
The Cost and Schedule Estimating Process.
The Iteration Planning Process.
Pragmatic Planning. 11. Project Organizations and Responsibilities.
Line-of-Business Organizations.
Project Organizations.
Evolution of Organizations. 12. Process Automation.
Tools: Automation Building Blocks.
The Project Environment.
Round-Trip Engineering.
Change Management.
Infrastructures.
Stakeholder Environments. 13. Project Control and Process Instrumentation.
The Seven Core Metrics.
Management Indicators.
Work and Progress.
Budgeted Cost and Expenditures.
Staffing and Team Dynamics.
Quality Indicators.
Change Traffic and Stability.
Breakage and Modularity.
Rework and Adaptability.
MTBF and Maturity.
Life-Cycle Expectations.
Pragmatic Software Metrics.
Metrics Automation. 14. Tailoring the Process.
Process Discriminants.
Scale.
Stakeholder Cohesion or Contention.
Process Flexibility or Rigor.
Process Maturity.
Architectural Risk.
Domain Experience.
Example: Small-Scale Project versus Large-Scale Project.
IV. LOOKING FORWARD.
15. Modern Project Profiles.Continuous Integration.
Early Risk Resolution.
Evolutionary Requirements.
Teamwork among Stakeholders.
Top 10 Software Management Principles.
Software Management Best Practices. 16. Next-Generation Software Economics.
Next-Generation Cost Models.
Modern Software Economics. 17. Modern Process Transitions.
Culture Shifts.
Denouement.
V. CASE STUDIES AND BACKUP MATERIAL.
Appendix A. The State of the Practice in Software Management.COCOMO.
Ada COCOMO.
COCOMO II. Appendix C. Change Metrics.
Overview.
Metrics Derivation.
Collected Statistics.
End-Product Quality Metrics.
In-Progress Indicators.
Pragmatic Change Metrics. Appendix D. CCPDS-R Case Study.
Context for the Case Study.
Common Subsystem Overview.
Project Organization.
Common Subsystem Product Overview.
Process Overview.
Risk Management: Build Content.
The Incremental Design Process.
Component Evolution.
The Incremental Test Process.
DOD-STD-2167A Artifacts.
Demonstration-Based Assessment.
Core Metrics.
Development Progress.
Test Progress.
Stability.
Modularity.
Adaptability.
Maturity.
Cost/Effort Expenditures by Activity.
Other Metrics.
Software Size Evolution.
Subsystem Process Improvements.
SCO Resolution Profile.
CSCI Productivities and Quality Factors.
People Factors.
Core Team.
Award Fee Flowdown Plan.
Conclusions. Appendix E. Process Improvement and Mapping to the CMM.
CMM Overview.
Pragmatic Process Improvement.
Maturity Questionnaire.
Questions Not Asked by the Maturity Questionnaire.
Overall Process Assessment. Glossary.
References.
Index.
The software industry moves unrelentingly toward new methods for managing the ever-increasing complexity of software projects. In the past, we have seen evolutions, revolutions, and recurring themes of success and failure. While software technologies, processes, and methods have advanced rapidly, software engineering remains a people-intensive process. Consequently, techniques for managing people, technology, resources, and risks have profound leverage.
This book captures a software management perspective that emphasizes a balanced view of these elements:
Throughout, you should observe a recurring management theme of paramount importance: balance. It is especially important to achieve balance among the objectives of the various stakeholders, who communicate with one another in a variety of languages and notations. Herein is the motivation for the part opener art, an abstract portrayal of the Rosetta stone. The three fundamental representation languages inherent in software engineering are requirements (the language of the problem space), design (the transformation languages of software engineers), and realizations (the language of the solution space executable on computers). Just as the Rosetta stone enabled the translation of Egyptian hieroglyphics, software management techniques enable the translation of a problem statement into a solution that satisfies all stakeholders.
There is no cookbook for software management. There are no recipes for obvious good practices. I have tried to approach the issues with as much science, realism, and experience as possible, but management is largely a matter of judgment, (un)common sense, and situation-dependent decision making. That's why managers are paid big bucks.
Some chapters include sections with a pragmatic and often hard-hitting treatment of a particular topic. To differentiate this real-world guidance from the general process models, techniques, and disciplines, headings of these sections include the word pragmatic. By pragmatic I mean having no illusions and facing reality squarely, which is exactly the intent of these sections. They contain strong opinions and provocative positions, and will strike nerves in readers who are entrenched in some obsolete or overhyped practices, tools, or techniques.
I have attempted to differentiate among proven techniques, new approaches, and obsolete techniques using appropriate substantiation. In most cases, I support my positions with simple economic arguments and common sense, along with anecdotal experience from field applications. Much of the material synthesizes lessons learned (state-of-the-practice) managing successful software projects over the past 10 years. On the other hand, some of the material represents substantially new (state-of-the-art), hypothesized approaches that do not have clear substantiation in practice.
I have struggled with whether to position this book as management education or management training. The distinction may seem nitpicky, but it is important. An example I heard 15 years ago illustrates the difference. Suppose your 14-year-old daughter came home from school one day and asked, "Mom and Dad, may I take the sex education course offered at school?" Your reaction would likely be different if she asked, "May I take the sex training course offered at school?" (This meant less to me then than it does now that my three daughters are teenagers!)
Training has an aspect of applied knowledge that makes the knowledge more or less immediately useful. Education, on the other hand, is focused more on teaching the principles, experience base, and spirit of the subject, with the application of such knowledge left to the student. I have tried to focus this book as a vehicle for software management education. (I am not sure there is such a thing as management training other than on-the-job experience.) I will not pretend that my advice is directly applicable on every project. Although I have tried to substantiate as many of the position statements as possible, some of them are left unsubstantiated as pure hypotheses. I hope my conjecture and advice will stimulate further debate and progress.
My intended audience runs the gamut of practicing software professionals. Primary target readers are decision makers: those people who authorize investment and expenditure of software-related budgets. This group includes organization managers, project managers, software acquisition officials, and their staffs. For this audience, I am trying to provide directly applicable guidance for use in today's tactical decision making and tomorrow's strategic investments. Another important audience is software practitioners who negotiate and execute software project plans and deliver on organizational and project objectives.
Because I am writing for a wide audience, I do not delve into technical perspectives or technical artifacts, many of which are better discussed in other books. Instead, I provide fairly deep discussions of the economics, management artifacts, work breakdown strategies, organization strategies, and metrics necessary to plan and execute a successful software project.
Illustrations are included to make these complex topics more understandable. The precision and accuracy of the figures and tables merit some comment. While most of the numerical data accurately describe some concept, trend, expectation, or relationship, the presentation formats are purposely imprecise. In the context of software management, the difference between precision and accuracy is not as trivial as it may seem, for two reasons:
I occasionally provide anecdotal evidence and actual field experience to put the management approaches into a tangible context and provide relatively accurate and precise benchmarks of performance under game conditions. Several appendixes clarify how the techniques presented herein can be applied in real-world contexts. My flagship case study is a thoroughly documented, successful, large-scale project that provides a concrete example of how well many of these management approaches can work. It also provides a framework for rationalizing some of the improved processes and techniques.
Although my perspective of iterative development has been influenced by many sources, I have drawn on relatively few published works in writing this book. Providing a more detailed survey of related publications might have helped some readers and satisfied some authors, but most of the correlation with my views would be coincidental.
The foundation of my material comes basically from three sources, on which I have drawn extensively:
Several other sources had a significant effect on the management process presented in this book. Their influence is the result of long-term relationships that encapsulate years of interaction, exchange of ideas, and extensive firsthand communication.
The most important influence on this work was my father, Winston Royce, who set my context, validated my positions, critiqued my presentation, and strengthened my resolve to take a provocative stand and stimulate progress.
Several people invested their own time reviewing early versions of my manuscript and contributing to the concepts, presentation, and quality contained herein. My special thanks go to Ali Ali, Don Andres, Peter Biche, Barry Boehm, Grady Booch, Doug Ishigaki, Ivar Jacobson, Capers Jones, Hartmut Kocher, Philippe Kruchten, Eric Larsen, Joe Marasco, Lloyd Mosemann, Roger Oberg, Rich Reitman, Jim Rumbaugh, and John Smith.
Finally, the overall presentation quality, consistency, and understandability of this material are substantially the work of Karen Ailor. Her critique, sense of organization, attention to detail, and aggressive nitpicking contributed greatly to the overall substance captured in this book.