Implementation strategies

11.6 Implementation strategies

There are several strategies for implementing an SQS. Probably the least effective methods are the ones that impose the SQS on the whole development organization without regard to which stage each project is at in its SDLC.

First is the all-at-once approach. In this case, the whole SQS is implemented at one time. Each project is expected to stop what it is doing and to bring the project in line with the new SQS requirements, whether or not every requirement is meaningful. The result is usually a period of confusion and a corresponding antagonism toward the SQS and the software quality group. Faced with this negative attitude, the software quality group has a very difficult time establishing itself and often fails and is disbanded.

Another poor method is the one-element-at-a-time approach. In this case, a particular element is chosen for organizationwide implementation, again without regard to the status of the various ongoing projects. Since there is varied success based on the position of each project in its SLC, the element tends to fade away due to decreasing application. When it is realized that element is ineffective, the decision is made to try one of the others. It, too, eventually fails. As each element is tried in turn, each faces the same fate. Finally, the decision is made to scrap the SQS because it is obviously not effective.

Both these implementation methods can work if consideration is given to each project to which they will be applied. There must be recognition that each project will be in a different portion of its life cycle and thus will have differing abilities, or needs, to comply with a new SQS. Provisions for deviations from, or waivers of, specific requirements of the SQS based on the projects' needs must be allowed, which will make either method of implementation much more likely to succeed.

11.6.1 Single-project implementation

The all-at-once approach can be successful when the software quality system is to be applied only to new projects.

One popular method of this type of implementation is to permit ongoing projects to complete on their own and to concentrate the software quality practitioners' efforts on new projects as they are begun. This has the drawback that some ongoing projects may be less successful since none of the system is formally applied to them. It has the advantage that no project has to change processes in the middle of its development. It is also likely that there are some portions of the SQS that will be adopted by the ongoing projects because they are seen to be of value and cause little disruption in the project's progress.

Another strong recommendation for this approach is in the data processing organization that experiences frequent project startup. Companies like defense contractors, which often have several dissimilar contracts starting and ending independently from one another, can use this method very successfully. It is often favored by software vendors as well because, again, there is wide project-to-project separation.

11.6.2 Single-element implementation

The one-element-at-a-time implementation picks one SQS element to impose on all projects, new and ongoing, but does so with careful consideration of each project's ability and need to conform to the element. This, too, can be a successful method of implementation, but it requires careful planning.

Two primary aspects of single element implementation must be considered: the order of implementation and the project benefit. Some SQS elements may add more value if implemented sooner, while some may actually have negative impact if implemented too soon.

Certainly, some elements are rather project-status independent. Portions of the education and security elements can be implemented irrespective of project status. Others, like documentation or CM, may require significant retrofitting of projects if implemented in the later phases of the SDLC.

An advantage of the single element approach is that each project has the opportunity to benefit from at least a portion of the overall SQS as early as possible. In this way, development personnel are able to see benefits of the system and tend to be more supportive of elements that are introduced later. A disadvantage is that new projects may not get the full benefit from the SQS because some of its elements are not yet in place.

The most likely type of organization to use the single element approach is that in which most of the development is closely related, for example, the more traditional in-house data processing for financial and business applications. Here, too, there is a rather steady flow of new projects, but they tend to be similar in nature. The single element approach allows each element to take root and become a routine part of the SDLC before another element is introduced.

11.6.3 Combined implementation

A combination of the two methods can be the best answer in most cases. As is the case in any discussion of methods or approaches, there is no single, always correct situation.

The single-project and single-element approaches are clearly the extremes of the implementation method spectrum. The single-project approach would be successful in the information systems organization that had no ongoing development projects to consider. The single-element approach could be the best answer if there is no new project activity. Neither of these situations is likely to be the case in most organizations. The answer, obviously, is to fit the implementation method, or combination of implementation methods, to the actual experience of the particular organization and to the specific projects being affected.

For new projects, it is almost always best to implement as much of the total system as possible. Only those elements that, in a given organization, would conflict with ongoing projects should be delayed. An example might be a new form of database security system that would seriously impact an ongoing development effort. In most cases, however, new projects can be started using the full SQS with little or no impact on the rest of the development activity.

Ongoing projects can be the subject of various subsets of the full SQS, depending on their status and needs. Projects late in the SDLC probably would be unaffected by the imposition of new programmer training but could benefit from increased user training requirements. A project early in the SDLC can be placed under more stringent CM procedures without much impact on completed work. Each project must be evaluated against the full SQS, and those elements that are feasible should be implemented.

As the SQS is implemented and experience is gained with it, it should be evaluated and modified as appropriate. The experiences of each project should be considered and changes, additions, and deletions made. Provisions for deviations and waivers will make the actual implementation of each element to each project as smooth as possible. A study of the waivers and deviations will show the modifications that may be needed in the overall system.

11.6.4 Adapting the SQS

It must be remembered that no one SQS is suited to all information systems organizations. The elements presented in this text are the building blocks, but the organization itself is the architect of its specific SQS. Each element will mean different things to different people. The various priorities, business considerations, political influences (both internal and external), and many other factors will determine the provisions of the SQS for a specific company.

In exactly the same manner, there will be adapting of the basic company SQS to meet the needs of each specific project. Contracts, visibility, official sponsorship, and other factors will affect the final contents of the project software quality plan and system.

It is desirable that each company develop a basic SQS. The SQS will present the minimum software quality requirements that must be met by all projects undertaken by the development groups. For each individual project, additional requirements may be added as the basic system is tailored to fit. The elimination of any portion or of the basic company SQS should be permitted only in the most justifiable of circumstances. All adaptation should be of an additive nature. The increase, not the reduction, of the potential for quality software should be the goal.