Architecture-Centric Software Project Management A Practical Guide

by Paulish, Daniel J.

• ISBN13: 9780201734096
• ISBN10: 0201734095
• Edition: 1st
• Format: Paperback
• Copyright: 2001-12-27
• Publisher: Addison-Wesley Professional
• More Book Details
• Purchase Benefits

Summary

As computer hardware provides more functionality at a lower cost, the need for new applications software is exploding. The world-wide-web is providing more information to more people at an ever-faster rate. Software products must be developed quicker, with increased functionality, performance, and quality. The pressure on the software engineers who are developing new products and maintaining existing products is increasing.

This book provides some support to the software project managers who are attempting to juggle the demands of meeting their schedule while delivering features with good quality. Our experience with observing and participating in many software development projects indicates that good design and project management skills go a long way in achieving successful projects. What is very clear is that it is unlikely that projects will be successful when the software architecture is not well designed or project management skills are missing. We have observed the connections between good software architecture and good project management on many projects, and we hope that some of the tips provided will result in better products.

Motivation

As an industry, we have not been very successful in managing successful software projects. Successful projects are those that meet their planned development schedule, provide the functionality promised, and deliver good quality software. From the 1995 Standish Group CHAOS report, their research on software projects reported that 16% of projects were completed successfully, 31% were cancelled outright, and 53% were substantially over budget and schedule and delivered less functionality than specified. By 1998, more projects were successful, with 26% completed successfully, 28% cancelled, and 46% over budget and schedule with less functionality Johnson 1999. Thus, things are improving, but we still have a terrible track record in our industry for successfully completing software development projects.

Background

The experience for writing this book was gained while managing software design and development projects in Siemens. As part of the Siemens Software Architecture R&D Program, a large number of Siemens projects have been investigated in order to capture how Siemens software architects design software systems. The knowledge gained from this research has been embodied within the four views architecture design approach described in the Applied Software Architecture book written by Christine Hofmeister, Rod Nord, and Dilip Soni Hofmeister 2000. As the four views approach was being developed, we had opportunities to participate as architecture design team members for new products being designed in various Siemens businesses. In some cases, we were also asked to plan and manage these new product developments and implement subsystems of components of the architecture. Thus, our project planning and management methods were developed in parallel with the four views design approach.

A concrete example of this correlation between architecture design methods and project planning methods is our architecture centered software project planning (ACSPP) approach described in chapter 2. We used this approach to develop cost and schedule estimates for the development projects, based on the software architecture. Since we were heavily involved with participating in software architecture design teams, we began to believe in the advantages to be gained when project planning was done in parallel with design. We were also called into Siemens companies as reviewers, from time to time, and we consistently observed warning flags for projects that either were not planned well or were missing a software architecture that could be easily communicated to the reviewers or the development team.

Over this same time period, the importance of software products and good development practices increased. We began to observe that our project planning and management methods were having a significant business impact in that they helped get software products to the market quicker and more predictably. Thus, our initial research interest was focussed more towards design methods and tools, but also we began to see the importance of good project management practices for meeting project goals.

As we became involved with real design and development projects, we realized that the key to effectively applying our methods rested with the working relationship between the project manager and the chief architect. These roles are described respectively within chapter 8 of this book and chapter 12 of Hofmeister 2000. When the chief architect and project manager work together as a decision making team, it's much easier to introduce and tailor the methods we describe herein within a specific development project. We also got to observe the problems that can arise when one individual tries to fulfill both of these roles for development teams that are bigger than a few people.

Not all the project management tips we present in this book are directly related to architecture design. But, enough of them are related, and we feel that a good software architect needs to understand some simple project management techniques in order to be successful within the chief architect/project manager leadership team. Good architects are primarily involved in making technical decisions, but they also appreciate the soft factors involved with leading projects. They often serve as sounding boards or critics of the project manager concerning any decisions that may affect the morale of the developers. Furthermore, we believe that project managers should provide a supportive environment to the chief architect and the entire development team, such that good design practices are consistently applied.

The biggest benefit of working within an industrial laboratory is that you have opportunities to do both research and development. In our case, we've had the opportunity to research methods such as the ones that are described in this book. But, we've also had the chance to apply the methods to real projects. As a result, the methods have been tweaked to be practical such that they are relatively easy to apply. Along the way, we've had the opportunity to design, plan, and develop Siemens software products that have been successfully sold in the market. We have attempted to conceal the real identity of these products in our examples and case studies, since we often describe real world problems that we have had to overcome. But, for the most part, the products that we have applied our design and project management methods to have been successfully developed and sold in the market.

The projects that we have worked on tend to be mid-sized projects. Typically, they have been in the order of ten to twenty software engineers. We cannot claim that our project management methods will work for very large or very small projects, since we have limited experience. Furthermore, since software development projects can last a year or more in duration, we have limited personal experience even for the types of projects that we have worked on. We will conveniently ignore these facts, and we will explain the various tips and methods as if they are great things that every project manager should do. However, there are no silver bullets within what we describe, although it may sound that way at times. A "leap of faith" will be required on the part of the reader to experiment with applying the methods we describe. Unfortunately, this is a persistent problem within most of software engineering since real experimentation is often very limited. Thus, our tips are mostly anecdotal in nature.

How to Use this Book

The primary audience for this book is software project managers. The secondary audience is software architects who must work closely with project managers. The third audi

Author Biography

0201734095AB09052001

Table of Contents

Foreword	xiii
Preface	xvii
PART ONE Overview	1	(16)
Introduction	3	(14)
What Is Project Management?	3	(2)
What Is Software Architecture?	5	(1)
Core Beliefs	6	(1)
Project Management Process	7	(1)
Architecture-Centric Project Management	7	(3)
Planning	10	(2)
Organizing	12	(1)
Implementing	13	(2)
Measuring	15	(1)
Summary	16	(1)
PART TWO Planning	17	(62)
Architecture-Centered Software Project Planning	19	(26)
Developing Realistic Schedules	19	(2)
Approach	21	(18)
Benefits	39	(1)
Experience	40	(1)
Rules of Thumb	41	(2)
Summary	43	(2)
Global Analysis	45	(22)
What Is Global Analysis?	46	(2)
Global Analysis Activities	48	(8)
Using Global Analysis for Project Planning	56	(8)
Using Global Analysis for Test Planning	64	(1)
Benefits	65	(2)
Managing Expectations	67	(12)
When to Plan and When to Commit	68	(2)
Managing Upward	70	(2)
Managing Sideways	72	(2)
Information Flow	74	(1)
Using the Software Development Plan	75	(2)
Summary	77	(2)
PART THREE Organizing	79	(66)
The Project Organization	81	(16)
Using Software Architecture to Define the Project Organization	81	(4)
Architecture Team Roles During Development	85	(3)
Project Functions That Support Development	88	(5)
Responsibilities, Roles, Authority, and Ownership	93	(1)
Summary	94	(3)
Global Development	97	(22)
Why Global Development?	98	(2)
Architectures for Supporting Global Development	100	(1)
Development Processes for Global Development	101	(10)
Multicultural Variables	111	(2)
Recommendations for Global Development Teams	113	(3)
Conclusions	116	(3)
Building a Project Culture and Team	119	(16)
Establishing Project Goals	120	(1)
Characteristics of Good Teams	121	(1)
Building a Project Culture	122	(7)
Building Consensus	129	(1)
Setting the Amount of Direction	130	(3)
Summary	133	(2)
The Role of the Software Project Manager	135	(10)
Creating a Vision	136	(1)
Coaching	136	(1)
Making Decisions	137	(1)
Coordinating	138	(1)
Working with Your Project Team	139	(3)
Software Project Management as a Career	142	(2)
Summary	144	(1)
PART FOUR Implementing	145	(46)
Trade-Offs and Project Decisions	147	(12)
Using the Project Goals to Make Decisions	148	(1)
Managing Creeping Functionality and Architecture Drift	148	(3)
Taking Responsibility	151	(1)
When to Accept or Reject Changes	152	(3)
Ethical Decisions of the Project Manager	155	(2)
Summary	157	(2)
Incremental Development	159	(12)
Baselining the Software Development Plan	160	(1)
Build Planning and Management	161	(1)
Getting Everyone Involved	162	(1)
Tracking Progress	163	(3)
Incremental Testing	166	(1)
Release Criteria Meeting	167	(2)
Tooling	169	(1)
Summary	169	(2)
Creating Visibility and Avoiding Surprises	171	(8)
Risk Management	172	(2)
Communicating Status and Issues	174	(1)
Building Credibility with Management	175	(1)
Recognizing and Celebrating Success	176	(2)
Summary	178	(1)
Staying Calm in the Heat of Battle	179	(12)
Cheerleading, Micro-Management, and Discipline	180	(3)
Remaining Optimistic	183	(2)
Playing the Quality Card	185	(1)
Providing Support and Removing Obstacles	186	(1)
Handling Problem Employees	187	(1)
Emotions and Avoidance	187	(2)
Quality of Work Life	189	(1)
Summary	190	(1)
PART FIVE Measuring	191	(26)
Measures to Pay Attention To	193	(14)
Global Metrics for Project Managers	194	(5)
Phase Metrics for High-Level Design	199	(1)
Cost-to-Completes	200	(2)
Engineering Budgets	202	(1)
Watching the Test Results	203	(1)
Summary	204	(3)
What Is a ``Good Job''?	207	(10)
Trading Off Among Schedule, Functionality, and Quality	208	(1)
Defining Project Success	209	(1)
Measuring Team Members' Contributions	210	(1)
Rewards	211	(3)
Staff Turnover	214	(1)
Summary	215	(2)
PART SIX Case Studies	217	(34)
IS2000	219	(12)
Background	219	(1)
System Overview	220	(1)
Project Planning	221	(4)
Project Management	225	(3)
Lessons Learned	228	(3)
DPS2000	231	(14)
Background	231	(1)
Global Analysis	232	(3)
Product Line Design Strategies	235	(2)
DPS2000 Architecture	237	(3)
Project Planning	240	(1)
Project Management	241	(1)
Lessons Learned	242	(3)
Conclusions	245	(6)
Sharing Best Practices	245	(2)
Benefits	247	(1)
Summary	248	(3)
PART SEVEN Appendix	251	(10)
Appendix: Useful forms	253	(8)
Acronym List	261	(6)
Bibliography	267	(8)
Index	275

Excerpts

As computer hardware provides more functionality at a lower cost, the need for new applications software is exploding. The world-wide-web is providing more information to more people at an ever-faster rate. Software products must be developed quicker, with increased functionality, performance, and quality. The pressure on the software engineers who are developing new products and maintaining existing products is increasing.This book provides some support to the software project managers who are attempting to juggle the demands of meeting their schedule while delivering features with good quality. Our experience with observing and participating in many software development projects indicates that good design and project management skills go a long way in achieving successful projects. What is very clear is that it is unlikely that projects will be successful when the software architecture is not well designed or project management skills are missing. We have observed the connections between good software architecture and good project management on many projects, and we hope that some of the tips provided will result in better products. MotivationAs an industry, we have not been very successful in managing successful software projects. Successful projects are those that meet their planned development schedule, provide the functionality promised, and deliver good quality software. From the 1995 Standish Group CHAOS report, their research on software projects reported that 16% of projects were completed successfully, 31% were cancelled outright, and 53% were substantially over budget and schedule and delivered less functionality than specified. By 1998, more projects were successful, with 26% completed successfully, 28% cancelled, and 46% over budget and schedule with less functionality Johnson 1999. Thus, things are improving, but we still have a terrible track record in our industry for successfully completing software development projects. BackgroundThe experience for writing this book was gained while managing software design and development projects in Siemens. As part of the Siemens Software Architecture R&D Program, a large number of Siemens projects have been investigated in order to capture how Siemens software architects design software systems. The knowledge gained from this research has been embodied within the four views architecture design approach described in the Applied Software Architecture book written by Christine Hofmeister, Rod Nord, and Dilip Soni Hofmeister 2000. As the four views approach was being developed, we had opportunities to participate as architecture design team members for new products being designed in various Siemens businesses. In some cases, we were also asked to plan and manage these new product developments and implement subsystems of components of the architecture. Thus, our project planning and management methods were developed in parallel with the four views design approach.A concrete example of this correlation between architecture design methods and project planning methods is our architecture centered software project planning (ACSPP) approach described in chapter 2. We used this approach to develop cost and schedule estimates for the development projects, based on the software architecture. Since we were heavily involved with participating in software architecture design teams, we began to believe in the advantages to be gained when project planning was done in parallel with design. We were also called into Siemens companies as reviewers, from time to time, and we consistently observed warning flags for projects that either were not planned well or were missing a software architecture that could be easily communicated to the reviewers or the development team.Over this same time period, the importance of software products and good development practices increased. We began to observe that our project planning and