1.5 Seven Principles for Software Engineering

In his famous paper [Bohem1983], Boehm in 1983 summarized seven principles for software engineering. These are still principles for today’s software engineers.

To distill the large number of individual aphorisms on good software engineering into a small set of basic principles, seven principles have been determined which form a reasonably independent and complete set.

1.5.1 Manage Using a Phased Lifecycle Plan

Based on this principle, the lifecycle of a software (project) can be divided into a few phases, therefore corresponding plans can be made, then management can be done. According to Boehm, there are at least six plans: Project overall plan, milestone plan, project control plan, product control plan, validation plan and operation plan.

1.5.2 Perform Continuous Validation

There is one single message about developing reliable software which outweighs all the others;it is to get the errors out early. This is the major thrust of Principle 2-Perform Continuous Validation.

1.5.3 Maintain Disciplined Product Control

When testers or users find that the actual system is different from the one they have been preparing for, it can often take a good deal of time, money, personal strain, and sometimes legal action to straighten things out. Thus, it is of great importance to maintain a disciplined product control throughout the system lifecycle to avoid such mismatches.

1.5.4 Use Modern Programming/Engineering Practices

Programming and engineering practices change very fast, modern techniques should be adopted whenever possible.

1.5.5 Maintain Clear Accountability for Results

Each individual on the project team should have a clear statement of the results for which he or his group are accountable, and a clear understanding that his future rewards depend on how well he does in producing those results. For a project to be able to do this, one additional thing is needed:adequate visibility into each person’s or group’s project performance. This visibility is particularly difficult to achieve on software projects, due to lack of tangible products. To get this visibility, it is necessary to break the software process down into a large number of well-defined steps, and to organize the project around these steps in such a way that each individual can tell whether he’s doing his job well or not.

1.5.6 Use Better and Fewer People

Let's suppose that you conscientiously follow Principles l～5 above. Will this guarantee you a successful project? Not necessarily. You could still fail very easily, for example, if you had to staff the project with EDP school dropouts. Avoiding such a pitfall is the subject of Principle 6: “Use Better and Fewer People.” If there are N people in the team, there will be N(N-1)/2 communication paths as shown in Fig.1-1. The more the people are in the team, the larger the management overhead.

Fig.1-1 communication paths of a team

1.5.7 Maintain a Commitment to Improve the Process

Principles l～6 is not quite enough to guarantee a healthy software engineering organization. They are enough to get an organization to do good 1982 vintage software engineering, but not enough to ensure that the organization keeps up with the times. Further, there needs to be a way to verify that the particular form of the principles adopted by an organization is indeed the best match for its particular needs and priorities. This is the motivation for Principle 7: “Maintain a Commitment to improve the Process.”

This commitment is not large in terms of dollars, but it is significant in terms of the need for planning and understanding your organization. It implies not only that you commit to trying new software techniques that look promising, but commit to set up some plan and activity for evaluating the effect of using the new techniques. This in turn implies that you have a way of collecting and analyzing data on how your software shop performs with and without the new techniques.