Software Management Best Practices

Many software management best practices have been captured by various authors and industry organizations. One of the most visible efforts has been the Software Acquisition Best Practices Initiative, sponsored by the U.S. Department of Defense to "improve and restructure our software acquisition management process." Brown summarized the initiative [Brown, 1996], which has three components: the Airlie Software Council (composed of software industry gurus), seven different issue panels

Round-trip engineering Tackling the architecture Iterative and process instrumentation f¡rsf arMj change processes improve the level of automation management early manageme and insight into objective improves the achievable reuse aero; quality control. ^t quality. w projects.

and configurable improve risk nt and process 3S multiple k

Cost = (Personnel)(Environment)(Quality)(S

ze)Pro<

:ess

Evolving levels of detail Compone and a demonstration- developm based approach improve based not communications among the overall stakeholders. compexity

r nt-based ent and model-nation help reduce size and )f the solution.

Figure 15-4. Balanced application of modern principles to achieve economic results

Figure 15-4. Balanced application of modern principles to achieve economic results

(composed of industry and government practitioners), and a program manager's panel (composed of experienced industry project managers). Each component produced recommendations and results, and reviewed the work of the other components.

The Airlie Software Council was "purposely structured to include highly successful managers of large-scale software projects, internationally recognized authors, prominent consultants, and executives responsible for software development at major companies." One of the Council's products was a set of nine best practices. The Council attempted to focus on the practices that would have the greatest effect in improving the software management discipline for large-scale software projects and controlling the complexities therein.

The nine best practices are described next, with my commentary on how they resonate with the process framework, management disciplines, and top 10 principles that I have recommended. (Quotations are presented in italics.)

1. Formal risk management.

a Using an iterative process that confronts risk is more or less what this is saying.

2. Agreement on interfaces.

a While we may use different words, this is exactly the same intent as my architecture-first principle. Getting the architecture baselined forces the project to gain agreement on the various external interfaces and the important internal interfaces, all of which are inherent in the architecture.

3. Formal inspections.

a The assessment workflow throughout the life cycle, along with the other engineering workflows, must balance several different defect removal strategies. The least important strategy, in terms of breadth, should be formal inspection, because of its high costs in human resources and its low defect discovery rate for the critical architectural defects that span multiple components and temporal complexity.

4. Metric-based scheduling and management.

a This important principle is directly related to my model-based notation and objective quality control principles. Without rigorous notations for artifacts, the measurement of progress and quality degenerates into subjective estimates.

5. Binary quality gates at the inch-pebble level.

a This practice is easy to misinterpret. Too many projects have taken exactly this approach early in the life cycle and have laid out a highly detailed plan at great expense. Three months later, when some of the requirements change or the architecture changes, a large percentage of the detailed planning must be rebaselined. A better approach would be to maintain fidelity of the plan commensurate with an understanding of the requirements and the architecture. Rather than inch pebbles, I recommend establishing milestones in the engineering stage followed by inch pebbles in the production stage. This is the primary message behind my evolving levels of ' detail principle.

6. Programwide visibility of progress versus plan.

a This practice—namely, open communications among project team members—is obviously necessary. None of my principles traces directly to this practice. It seems so obvious, I let it go without saying.

7. Defect tracking against quality targets.

a This important principle is directly related to my architecture-first and objective quality control principles. The make-or-break defects and quality targets are architectural. Getting a handle on these qualities early and tracking their trends are requirements for success.

8. Configuration management.

a The Airlie Software Council emphasized configuration management as key to controlling complexity and tracking changes to all artifacts. It also recognized that automation is important because of the volume and dynamics of modern; large-scale projects, which make manual methods cost-prohibitive and error-prone. The same reasoning is behind my change management principle.

9. People-aware management accountability.

▲ This is another management principle that seems so obvious, I let it go without saying.

There is significant overlap and commonality of spirit between my top principles and the Airlie Software Council's best practices. However, I think the Council omitted some important principles: configurability and component-based, model-based, demonstration-based development. This omission is surprising, because my rationale for including component-based and model-based principles was to reduce the complexity of development. This is exactly the stated purpose of the Airlie Software Council. The demonstration-based principle is in my top 10 primarily to force integration to occur continuously throughout the life cycle and to promote better stakeholder relationships through a more meaningful medium of communications. Because the Airlie Software Council was focused on a particular domain—namely, large-scale, nationally important systems—configurability was less important.

The two Airlie Software Council practices I would not have included are inspections and binary quality gates at the inch-pebble level. Although they are useful, they are overemphasized in practice, and there are other important principles that should have been included.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment