Management documents

10.1 Management documents

Every software development project is going to be managed in some way. A plan will be prepared, in one form or another, that lays out the expected schedule and resources. Effort will be expended to review and test the software, at least at the end before delivery, and the components of the software will be identified so that the delivered software and its components are known.

The following management documents are common to all software development projects:

• Software development plan;

• SQS plan;

• CM plan.

These documents are the overall software development process control documents. Their size and depth of detail will vary with the size and complexity of the system being developed. They may even be merged into a single document for small projects. Even so, the content, describing how the development project will be managed and controlled, must be present for each software development project. It should not be surprising that the more formal the planning and its documentation, the more complete and effective it will be. Thus, the creation of the software development plan (SDP), the software quality system plan (SQSP), and the configuration management plan (CMP) is a necessary part of each software development project.

These plans for a project leading to 500,000 or more lines of code would probably cost more than a whole 500-line project. Therefore, the level of detail and control included in each plan must reflect the size and complexity of the project at hand.

10.1.1 Software development plan

The SDP is the document that lays out the management approach to the software project. In its most basic form, the SDP will include the schedule and resource needs for the project. The milestones for tracking the progress of the project will be specified, probably as a pictorial of the SDLC. The personnel loading will also be shown so that the required expertise and skills can be available when they are needed. The SDP should also specify hardware and environmental needs such as computer time, special test facilities, compilers and linkers, other systems, and the like.

For simple systems, the material covering the SQS and CM may also be included as separate sections in the SDP. As system complexity grows, so does the SDP. More and more detail is required to cover the larger scale of the software development activity. Schedules must contain intermediate checkpoints or milestones, and personnel loading will become more varied and complicated. Test support facilities will become more elaborate. The SDP will also begin to address software quality and CM to a level of detail that precludes their inclusion as SDP sections.

The more elaborate the software system, the more it probably interfaces with other systems and the outside world. While these interfaces are presented in requirements documentation, provision for their involvement in testing must be ensured and scheduled in the SDP.

Larger systems may require enough people or facilities to justify special offices or test laboratories. If so, these must be presented in the SDP so that their availability is ensured.

Budget control becomes more important as the size of the system grows. The SDP is the appropriate place to present budget considerations and to specify control mechanisms in support of the normal, companywide costs accounting system.

While the software quality practitioner obviously does not generate the SDP, the practitioner has the responsibility for reviewing it against SDP standards and ensuring that all appropriate information is present. Deficiencies detected both by the software quality practitioner and any other SDP reviews should be corrected before the project is permitted to commence.

The software quality practitioner also monitors the software development activities against the SDP. Deviations are reported so that corrective action may be taken by management.

Most corrective action will be to correct the software development process where it has strayed from the plan. Some corrections will be made to the SDP to keep it current with changes in the project. The software quality practitioner will review these changes to ensure that contracted requirements are not being violated and that the plan still complies with the standards for it.

See Appendix A for a sample SDP outline.

10.1.2 SQS plan

The SQSP addresses the activities to be performed on the project in support of the quest for quality software. Being careful not to exceed the requirements of the customer, company standards, or the SDP, the SQSP will discuss all of the activities to be performed on all of the various SLC products. A sample format for an SQSP is shown in Appendix B.

Remember that a software quality group is not necessary for the SQS functions be performed. Thus, the various software quality functions will be assigned, through the SQSP, to be the organizational entities that will perform these functions. All activities to be accomplished in the software quality area should receive the same personnel, resource, and schedule discussion as in the overall SDP, and any special tools and methodologies should be discussed. The SQSP may be combined with the CMP (see Section 10.1.3) for medium-sized efforts.

Whatever the format of the SQSP, it is important that the document (or its information if in another document) be complete and approved by management and the producers. The SQSP becomes the charter for the SQS functions for the particular project when approved by management. It lays out the entire SQS and how it will be implemented.

Without the involvement of and approval by the software developers, the SQSP can be a recipe for ineffectiveness and frustration on the part of the software quality practitioners. Without the cooperation of the developers, software quality practitioners can be severely hampered in their attempts to conduct the review and monitoring activities for which they are responsible. Involving the development organizations in the generation and approval of the SQSP can encourage their cooperation as the project progresses.

The software quality practitioners must also monitor their own plan and their activities according to the plan. Any deviation from the plan or any indication that it is inadequate must be corrected. The software quality practitioner will monitor all the software management and development activities. It is certain that management and the developers will be watching the software quality practitioners to be sure they perform according to the SQS plan, the whole plan, and nothing but the plan.

10.1.3 CM plan

CM, as discussed in Chapter 6, is a threefold discipline. Each of the three activities should be discussed in its own section of the CMP. The methods, requirements levied on the producers, contracted requirements, and tools to be used for software CM all should be spelled out. (See Appendix C for a sample format for a CM plan.)

If the project is small, the necessary information may be included in the SDP. On medium-sized projects, it may be appropriate to combine the CMP information with the SQS plan in a single, dual-purpose document.

While some of the information may be in the personnel and resource sections of the SDP, CM-specific information must be presented in the CMP. Schedules for baselining, major reviews, and auditing should be shown either on the overall project schedule or on the CM schedule.

Any special tools or resources needed to support CM must be called out in the CMP. Another topic that may appear in the CMP is the operation of the software development library, which is the depository of all software product master copies. If not discussed elsewhere (e.g., SDP or SQSP), the library, its responsibilities, functions, and so forth should be presented in the CMP.

As with the SDP, the software quality practitioner has the responsibility to review the CMP before its release and adoption. The software quality practitioner should ensure that the CMP is complete and appropriate for the project and that it meets any specified format and content standards.

Software quality practitioners will also review the CM activities on an ongoing basis. The reviews will ascertain whether the activities described in the plan are being performed and if they are still appropriate for the project.

10.1.4 Additional plans

As software becomes an increasingly critical part of our lives, additional plans may be required for some software system development efforts. Such plans might include the software safety plan (Appendix K) and the risk management plan (Appendix L). These plans are certainly not required for all development projects. It is the responsibility of the quality practitioner to evaluate their necessity for each new project and to recommend their preparation when appropriate.