2. AN ORGANIZATION'S STANDARD SOFTWARE PROCESS: AN OVERVIEW

An organization's standard software process documents "the way it does business." It is a compendium of information that describes how a software organization plans for, manages, builds, qualifies, and maintains software. In other words, the organization's standard software process consists of a number of building blocks that are used in different ways to support software projects.

The organization's standard software process may be described in a number of ways, e.g., through Data and Control Flow Diagrams (DFDs and CFDs), flow charts, etc. Most often, the organization's standard software process is a book or notebook arranged in topic areas with text descriptions of processes and procedures, lists of standard tools, and some form of process diagrams to describe the way the organization operates using these building blocks. Figure 2-1 shows an organization's standard software process as an inventory of building blocks (or process pieces and support tools) that needs to be assembled and fitted to fulfill each project's needs. The organization's software process could be structured by topic area (e.g., all processes dealing with project management, product engineering, testing, etc., could be grouped together), it could be a simple inventory with the building blocks listed in alphabetical or numerical order, or it could take some other form. The goal of the organization's standard software process is to document how the organization does business; the form is not really important.

Figure 2-1. Example building blocks.

The organization's standard software process is not magic. It's not simply an oversized set of instructions to do the impossible or an imposing tome of unreadable, incomprehensible diagrams. It's a basic description of how an organization does business. Ideally, it is a living document that exists both in hard copy and easily accessible on-line formats.

For example, the organization's standard software process contains Software Configuration Management (SCM) processes and practices. Most often, the processes and practices are supported with procedures and tools. The procedures and tools need to be consistent with the processes and practices; they are part of the organization's software process building blocks.

Each organization needs to develop and maintain building blocks that fit its particular requirements. Although the CMM provides goals that need to be fulfilled and activities that need to be performed to prove conformance with the requirements of a given CMM level, the contents of the organization's standard software process do not need to be limited to the requirements of the CMM nor organized to reflect the organization of the CMM's KPAs. The organization's standard software process should contain the processes and practices required to fulfill the organization's software-related technical and business goals.

Usually, the contents of an organization's standard software process are chosen to cover the needs of software projects considered to be large or complex for that organization; the organization's standard software process contains the building blocks that will cover the needs for the worst-case software project. Examples of sets of practices within the organization's standard software process are:

a. Software engineering, e.g., requirements management, requirements engineering and design, software life cycles, development methodologies.

b. Software engineering support techniques/disciplines, e.g., Software Quality Assurance (SQA), SCM, product inspections (or peer reviews).

c. Software management, e.g., software development planning, ongoing project management, software metrics, software cost estimation techniques, multi-disciplinary team coordination.

The development of an organization's standard software process is not trivial. Many organizations spend three or more years developing a standard software process, and the development and approval effort is just the beginning of software process improvement. Software process improvement can only happen when the processes and practices are institutionalized and used routinely throughout the organization.