Organizational considerations

11.4 Organizational considerations

Software quality management is the discipline that maximizes the probability that a software system will conform to its requirements, as those requirements are perceived by the user on an ongoing basis.

Like a hardware quality system, the software quality system is a measuring and monitoring function. It is a set of activities that is intended to encourage and, to a degree, enable conformance of the software to its requirements. Throughout this text, reference has been made to the role of the software quality practitioner. In general, this role has been one of monitoring the status of the software development or some aspect surrounding that development. The several aspects of the SQS—testing, education, security, and the others—are all factors that influence the capability of the software to conform to its requirements. The software quality practitioner's role is to monitor the status and progress of the organization with respect to these factors. Its findings are reported to the level of management that has the authority to take any necessary corrective action.

Two points are important here. First, software quality practitioners may, but usually do not, perform all the various activities that the SQS comprises or on which it reports. The software quality practitioner rarely writes the documentation, performs the testing, teaches the programming courses, installs disaster recovery procedures, and so on. Those tasks should be performed by the part of the organization best capable of performing them. The role of the software quality practitioner is to ascertain that those activities are being performed and whether that performance is sufficient to permit the software to conform to its requirements.

The second point is that software quality practitioners are not an enforcement agency. A software quality practitioner reviews, inspects, evaluates, measures, and then reports. The final report is usually a ship-or-don't-ship recommendation. The organizational level at which software quality practitioners report can strongly affect the perceived value of the reports that a software quality practitioner generates and the influence the practitioner can exert over the software development process. The task of enforcement is the responsibility of management. Only management has the authority to take corrective action in the case of reported deficiencies.

While it is true that everyone should be responsible for the quality of his or her own work, in most organizations the overall accountability for software quality rests with one person. It is simplistic to say that the overall accountability for software quality lies with the president, chairman, or CEO of the organization. Obviously, final accountability for everything in the organization lies with that person. The question is, to what level has the day-to-day, effective accountability been delegated? In most cases, the manager of the data processing organization (whatever title that person might have) has the delegated accountability. That is the person who can make the enforcement decisions, weighing the inputs from the various concerned areas such as software quality, development, and the user. The manager, in turn, will delegate the quality tasks and their performance to those parts of the organization that are best suited to accomplish them. Management must weigh the severity of the deficiency, business factors, resource utilization, schedule considerations, political aspects, and other considerations surrounding the SLC and then make a decision as to the action that should be taken for each specific situation. The reports received from software quality practitioners are one form of input to this decision-making process. Certainly, software quality practitioners may offer recommendations with its reported findings, but the enforcement actions are management's to take.

11.4.1 SQS task performance

The best-qualified entity of the organization should perform the day-to-day quality system tasks. There are few activities within the purview of the SQS that must be specifically performed by software quality practitioners. For this reason, it could be argued that there is no need to have a group called software quality at all. The basis for this idea is that since everyone is responsible for the quality of the software product, a separate group is not needed for the SQS tasks. If all persons involved in the specification, design, coding, testing, and operations of the software were infallible, this might be a workable situation. Humans are not infallible, however; in spite of their best intentions and efforts, they make errors, which cause defects. The intent of the SQS is to help discover those defects and correct them as early as possible. In addition, the formation of a software quality group, or at least the identification of a single accountable person, tends to focus attention on quality and efforts to attain it. And, just like in a software development project, it is a good idea to have a champion for the software quality system. If that champion is a member of senior management, so much the better.

The software quality group is responsible for ensuring that the various SQS tasks are performed. That does not mean that software quality is always the proper group to actually perform the tasks. Remember, software quality is a monitoring group. If there are tasks for which the software quality group is qualified from a technical standpoint and there is no other more logical group, software quality practitioners certainly may be assigned to the task. In some organizations, the practitioner does, in fact, perform all of the elements of the SQS. In most companies, however, the bulk of the tasks are handled outside the software quality organization. Each function should be assigned to the organizational entity that is in the business. Educational needs should be filled by the training and education entity, CM by the CM entity, and so forth. Each company must review its own needs, priorities, and capabilities and then determine the proper distribution of software quality tasks for its own situation. It may even be advisable or necessary to bring outside consultants in for specific tasks, at times.

11.4.2 Reporting level

Software quality must be independent of the group(s) that it monitors and thus should report at least the same organizational level. Reporting at lower managerial levels can dilute, or even negate, the influence of the software quality practitioner on the software development or maintenance projects.

Figure 11.4 shows the least-favorable structure and the one that should not be used. In this case, software quality reports to the very person whose group software quality is monitoring. It is unlikely that much useful reporting of noncompliance with standards, defect trends, or other insufficiencies will reach the ears of the portion of management that can take the necessary corrective action. Organizational independence from the groups being monitored is the single most important consideration in the placement of software quality.

Figure 11.4: Least-favorable organization.

Figure 11.5 presents the best realistic compromise. It shows software quality reporting at the same level as each of the other groups in the data processing department. The manager of software quality is a peer with the managers whose groups are being monitored. A common higher manager is available to mediate any issues that cannot be resolved directly between the affected managers.

Figure 11.5: Acceptable organization.

The advantages of this scheme are as follows:

• The software quality practitioner is reviewing the work of peer groups.

• A single superior is available to mediate questions or disputes.

• The software quality practitioner is independent of each of the groups it will monitor.

• The software quality practitioner is accessible to the other groups for assistance.

A very important aspect of the suggested reporting level is that the software quality practitioner is specifically not a part of any of the groups that it must monitor. When a situation that may need correction is found, it is reported to the manager of the data processing organization directly, not through an intermediate level.

Another arrangement is shown in Figure 11.6. This particular reporting scheme is sometimes found in manufacturing companies that have a strong and mature quality system. Software quality in these companies is a recognized extension of the overall quality system. In this case, the software quality practitioners report completely outside the data processing department and have a direct reporting line to top company management. A potential drawback is that, except in large organizations with experience in hardware product quality practices, this scheme may have the software quality practitioners too far removed from the development organization to be as effective on a day-to-day basis as is desirable. The success of this type of reporting structure depends on the interaction between the software quality group and data processing. If, in spite of the organizational separation, the software quality practitioner maintains a high degree of communication and rapport with the data processing groups, this can be a workable solution. It is also a candidate arrangement when there is a strong matrix organizational structure for project management.

Figure 11.6: Alternative organization.

There are probably many different reporting arrangements that can be envisioned. Most, though, if the software quality practitioner is at a lower level than the groups being reviewed, do not support a strong SQS effort.

Some arrangements would place the software quality practitioner at a higher level than the other groups. This can sometimes lead to conflict because the software quality group is perceived as having inordinate power. Whatever the reporting structure chosen, software quality practitioners will be most effective when they report to at least the same organizational level as those groups whose activities they must monitor.