Areas of standardization

2.1 Areas of standardization

Standardization may be applied to any or all of the areas of software development and maintenance. Such broad use of standards is rarely the case and usually not appropriate. Areas that are usually involved in the standardization effort include, but are by no means limited, to the following:

• SLC;

• Documentation;

• Coding;

• Naming;

• Operating procedures and protocols;

• User development.

2.1.1 The software life cycle

The SLC describes the whole software process from conception through retirement of a given system. Two life cycles are used in discussing software. The overall SLC for a system, an example of which is shown in Figure 2.1, begins with the original idea for the software system, or its conception, and the evaluation of that concept for necessity and feasibility. The life cycle ends when the software system is retired from use and set aside. Figure 2.1 also shows that, within the full life cycle, there is the SDLC. This is the portion of the overall SLC that deals expressly with the development of the software system. It begins with the formation of the formal requirements documentation, which states specifically what the system will do, and ends with the implementation of the system into full use. Clearly, there are other software development paradigms; the example shown is only an example of one that is commonly used.

Figure 2.1: Two software life cycles.

The SLC, and thus the SDLC, is usually divided into portions of work or effort called phases. In the life of a software system, many functions or activities are performed. These activities are grouped into phases so that they can be conveniently referenced, monitored, and managed. In Figure 2.1, the SLC is divided into six major phases, plus the effort required to retire a system at the end of its useful life. The SDLC is composed of the middle four major phases. In any particular organization, the various activities may be grouped differently, or the phases may be combined, further divided, or given different names.

It is appropriate at this point to recognize the methodology called prototyping. Prototyping, a simplified overview of which is presented in Figure 2.2, is an increasingly popular adjunct to the SDLC as we present it in this text. Prototyping has as its goal the quick analysis of the problem to be solved and experimentation with potential solutions. Used properly, it is a powerful requirements analysis and design tool. Used improperly, it can lead to undocumented and unmaintainable software.

Figure 2.2: General prototyping approach.

A detailed discussion of prototyping is beyond the intent and scope of this text. It is the subject of much current literature and the interested reader is encouraged to pursue the topic. It is sufficient to observe that, while the development of a prototype system can support activities within the SDLC, the prototyping development itself is expected to follow a standard SDLC. Prototyping is often used when the requirements determination and expression techniques include use cases. A use case is a description of what the software must do, or how it must behave, if the user is exercising some particular functionality. As discussed in Chapter 4, use cases are also popular means of determining test cases for the software.

The SLC is the basis for many standards applicable to the development and use of quality software. One of the first standards that should be prepared is the life-cycle description, sometimes called the software development methodology. Which phases comprise the SLC and the SDLC and which activities comprise each of the phases must be clearly delineated. Once the life-cycle phases are defined, the process of determining proper subjects for standardization within the life-cycle activities can begin.

Most standards will be applicable to activities during the SDLC, since that is where the heaviest concentration of tasks is found. This in no way means that standards for the other phases should be ignored or not prepared. As the SQS matures, it will determine, together with the rest of the software organization, new areas to which standards can be usefully applied.

The arrival of computer-aided software engineering tools has opened another opportunity and necessity for SLC standardization. Which tools to use; how to specify, acquire and apply them; and the interfaces among them; may need to be addressed by standards.

2.1.2 Documentation

Comprehensive documentation standards are a basic necessity for thorough design, test, operation, and maintenance.

A major complaint against most software systems is that they are poorly documented. A generality is that documentation is done, if at all, after the software system is delivered. Thus, while in the best of worlds the documentation describes the delivered system, it often fails to describe what was originally requested by the customer. Further, there is often little documentation of the test program applied to the software system. This makes the software's ability to perform as desired suspect. Also, user documentation-how to use the software system-frequently is accused of being unusable itself.

Standards for documentation should address two fronts-the required documentation for each software system and the format and content requirements for that documentation. Documents prepared in nonstandard formats increase the likelihood of misunderstanding or incorrect interpretation.

A comprehensive set of documentation standards can help assure that the documentation of a software system is capable of the tasks for which it is intended. Without standards with regard to what to document and how to document it, the system may well go into production and fail for one of the following reasons:

• It is not what the customer really wanted.

• The users and operators do not know how it works.

The most important document, and frequently the least standardized and least well done, is the requirements document. The requirements document is intended to spell out specifically the problem of need to be addressed by the software. It must describe the intended software system from an external, operational point of view. Once the requirements have been determined and expressed, they must be managed. Every system being developed will undergo requirements changes. Some will be necessary, some just "nice to have"; others actually may be harmful or detrimental to the system as a whole. Without rigorous standards for the analysis, definition, expression, and control of the requirements, a software development project is in danger of failing to satisfy its users.

2.1.3 Coding

Coding standards can help reduce artistry and enhance clarity and maintainability.

Some coding standards take effect earlier than others, sometimes reaching back into the design phases. A standard that calls for structured coding techniques will usually imply the imposition of a standard that calls for structured design techniques. Conversely, standards requiring object-oriented development techniques will often lead to standards for coding in one or another of the newer languages that support object development.

Standards such as these are intended to permit greater understanding throughout the balance of the SLC. Peers who are involved in walkthroughs and inspections are better able to understand the code as they prepare for the review. Maintainers have a much easier time of correcting and enhancing code that is well structured and follows adequate standards.

Some coding standards deal with which specific language is to be used. Many shops relying on large mainframe-based systems still use Cobol or PL/I as their standard application language. Another, differently oriented, development organization may standardize on Visual Basic, C++, or Java. Some organizations have several standard languages, depending on which type of application is being developed, or even specific characteristics of a given application.

Beyond standards specifying a given language, an organization may prepare standards for subroutine calls, reentrant or recursive coding techniques, reuse of existing code, or standards covering restrictions on verbs or coding constructs.

Most organizations have specific approaches that are preferred or, perhaps, prohibited. The coding standards will reflect the needs and personality of the organization. A set of standards is useful in creating an environment in which all programmers know the rules that govern their work. If a coding convention is beneficial to the performance of the coding staff, it should be made a standard so that all coding can benefit from it. On the other hand, if a particular coding technique is found to be detrimental, a standard prohibiting its use is appropriate so that all programmers know to avoid it.

2.1.4 Naming

Standard naming conventions assist in readability and CM. The standardization of naming conventions for system components (units, modules), data, and even entry points within the code is both easy and beneficial. There is usually little resistance to a consistent naming or labeling scheme, and its major benefit is the ease of identifying the object being named or labeled. Beyond that, CM, especially configuration identification, is much more difficult if there are no consistent rules or standards for component identification.

Naming standards are based on consistent identifiers in specific locations within the name. As Figure 2.3 shows, identifiers may be assigned to decreasing hierarchical levels within a system; the first characters specifying the system itself and subsequent characters define lower levels within the system. Data can be similarly named, as can subroutines and even external interfaces.

Figure 2.3: Identification based on hierarchy.

The important point in naming conventions is that all components of a given software system can be identified as belonging to that system. This, in turn, can simplify the bookkeeping for testing, integrating, and delivering the system, since each component is uniquely identified. This, as will be discussed later, is also very important for managing the overall configuration or version of a product. To have the user or customer accept one version of the system and then mistakenly deliver a different version obviously is undesirable.

Configuration identification, while going beyond the basic naming standards and conventions, depends on unique identifiers for all components of a particular software system. It can perform its function with whatever naming standards, conventions, schemes, or methods are used. However, a standard naming convention greatly eases the configuration identification task.

The tasks of the software developer and tester are also simplified if standard naming conventions are used. Confusion and doubt as to exactly which interface is to be exercised or which module is to be tested are minimized. The developer can easily determine the subroutine to call or entry point to use if there are standard rules and formats for the names of those items.

2.1.5 Operating procedures and protocols

Operating procedures are standardized so that everyone does the same thing the same way with a given software system.

Standardizing the operational environment is important to software system results. Correct data, entered in different ways, can give different, yet seemingly correct, results. Sequencing subsystem operations in nonstandard ways may lead to varied results, all of which might be taken as correct. To be sure, much of the opportunity for variation in use or operation of a software system can be eliminated by the software itself. On the other hand, software cannot easily control procedures, so standards are used to govern the remaining variables.

Standard user procedures tend to reduce errors and defects, maximize system response time, simplify user education, and increase understanding of system outputs.

Standards applied to users may address time of day or cycle considerations with respect to the running of the system. A payroll system may be run on Friday as a standard to permit proper interface with the timecard reporting system. A corresponding standard may call for running on Thursday in holiday situations. By having standards for use, the user is not put in the position of making decisions that could conflict with those made by someone else. Further, it reduces the likelihood that a person making the same decision will make it differently from time to time.

The standardization of operating procedures and protocols applies to large centralized data centers, client-server installations, standalone and networked workstations, and specific application systems. Specific application systems standards can regulate when the system is run, how to recover from system crashes, and the like. Equally important, though, the overall operation of the data center or network should have governing standards. Such things as scheduled maintenance time, job-entry rules, mass storage allocation, remote job-entry procedures, log-on and log-off procedures, password use, data access, and distributed computing are all subjects for appropriate standardization. Such standards have high payback in smoother operation, reduced errors and defects, and easier education of personnel.

2.1.6 User development

User development of software needs strict standards so that the actions of one user do not affect other users or the data center itself.

The rapidly growing capability for user-developed software provides a fast, easy method of providing quick service for small tasks. Another, associated area is the availability of off-the-shelf software from both regular commercial suppliers and on-line bulletin boards. Software can be purchased or downloaded and made into an integral part of larger systems being developed. Users have the ability to buy a package, merge it with another package, write some special code for their own needs, and run this amalgam of software without the intervention of the regular software organization. While convenient and often productive, this has opened the door for uncontrolled software development, potentially damaging access to the organizational database, excessive loading of the data processing facilities, and wasteful duplication of effort and resources. Standards for user development of software are needed to address these potential conditions.

User development can take many forms. The development can be done by someone on behalf of the user (but not via the established software development processes). For example, some years ago, a company that made computer systems for restaurants and resorts had a salesman who fancied himself a wizard programmer and configured some function keys at the top of the keyboard to do specific tasks such as create an end-of-shift report. Customers were impressed by his programming prowess and his ability to take a simple request and automate it quickly.

The trouble came later when a customer called the company's customer support center after a power failure at the restaurant wiped out all the fancy function key programs created by the salesman. When the customer began complaining that the F8 function did not work anymore, customer support was baffled. It took some time, and the tracking down of that particular salesman, to figure out what had gone wrong.

This is a simple case of uncontrolled, undocumented, and unsupervised development. Instead of enhancing the customer relationship, as the salesman thought he was doing, this case of rogue programming actually put the account in peril and potentially cost the company thousands of dollars and a customer.

User understanding and observation of standards is required to avoid negative impact on the overall data processing facility. Uncontrolled purchase of small, local (departmental) computational facilities can be an unnecessary drain on a company's resources and can lead to incompatibilities between local facilities and the main data center or network. Further, as software is developed, it can, if unregulated, lead to data interface, integrity, and security problems. Acquisition of software from nonstandard sources or suppliers also increases the likelihood of virus infections and other security concerns.

User development of software can be a beneficial addition to the computational capabilities of an organization. However, standards are easier to develop and enforce in traditional mainframe environments, since all processing is done under a central operating system. As control and processing move toward a decentralized environment, enforcement becomes more difficult. Not only are user development standards more necessary, but increased surveillance of storage and files is appropriate to reduce the chances of misuse of unauthorized or nonlicensed commercial software. Standards for user development, ranging from equipment and language selection to data security and networking, will permit maximum user flexibility and still maintain central control for efficient overall data processing.

Changes to standards affecting user work flow and tasks may also be impacted by new standards governing user development of software. Users should have the opportunity to participate in the standardization activities. They might even have a trial-use period. The quality practitioner will want to assure that addressing the dangers inherent in uncontrolled user development are not creating unnecessary restrictions.

2.1.7 Emerging technologies

The software development and maintenance world is in a period of great expansion and change. While most of the new technologies can be traced back to old methods and look more like changes than innovations, the applications of the technologies are often new or at least different. Some of us see object-oriented design and development as little more than a refinement of subroutines and independent modules. Client-server technology probably really began when IBM introduced its CICS operating system; the clients were terminals, and the server was a big mainframe. GUIs are no longer new but necessary. Further, the proliferation of software for e-commerce has added a new dimension of technology.

In any event, developers are having a hard time finding standards to govern these technologies. That is not to say that there are no standards available; some new concepts have gained wide industrial acceptance and are more de facto standards than formal standards. This places the burden on the users of these technologies to develop their own approaches and standards. The alternative is to gamble on adopting one or another of the de facto standards and hope that the industry as a whole goes in the same direction. The same is true for the burgeoning field of multimedia software.