3. TAILORING THE ORGANIZATION'S STANDARD SOFTWARE PROCESS

3.1 Introduction to Tailoring

Software projects have unique requirements. The products (or modifications to products) that result from a project generally are unique. Traditionally, the unique aspects of a project rather than a common set of building blocks has been the driving force behind software development planning. This focus often translates to using different sometimes conflicting processes for projects within a single organization, which means that the lessons learned in how to "do business better" for a given project can be very difficult to apply to new projects.

One of the factors that supports developing and using an organization's standard software process is that using common building blocks for all projects within the organization will help make planning and management easier through supporting the use of materials, methods, lessons learned, etc., from previous projects. Still, given the unique nature of most software projects, some tailoring needs to be made to the organization's standard software process to apply it to almost any new project. The steps used to tailor the organization's standard software process to the needs of a specific project will be somewhat different for each organization. In general, however, the following concepts can be used to help think through how to develop a project's defined software process.

New software project definitions often include the following information:

a. Project goals.

b. Project technical work requirements.

c. Performance requirements and standards.

This information is combined with the organization's inputs and external inputs, such as:

a. The organization's business goals,

b. The organization's standard software process,

c. Rules for tailoring the organization's standard software process,

d. Acquisition regulations, and

e. The acquisition organization's management philosophy,

to develop the project's defined software process. In its simplest form, tailoring an organization's standard software process to a specific software project can be thought of as shown in Figure 3-1.

Figure 3-1. Tailoring an organization's standard software process (overview).

Previous work in tailoring processes and standards has identified "axes for tailoring" organization's standard software processes [GINS95] that include formality, accuracy, scope, precision, and complexity and "key areas to tailor" for DOD-STD-2167A [MAIB94] that include documentation, product requirements, formal reviews, testing, and customer approval.

This report confines tailoring to a small, focused set of areas that have a high payoff in terms of cost and schedule. The areas that provide a focus for the tailoring method described in this report are:

a. Project Size and Complexity.

b. Formality.

c. Control.

3.2 Identifying Project Characteristics

Often, the answers to the questions in Table 3-1 can help define the characteristics of a project to the level of detail required to make informed tailoring decisions. Table 3-1 is roughly divided into three groups of questions to correspond with the three high payoff areas.[4] The development manager is expected to answer all the questions with rough order of magnitude answers before proceeding to the next tailoring step.

Once the project's characteristics are quantified at this level, the next step in tailoring the organization's standard software process to the needs of a project is to choose and tailor the process building blocks that will be used for the project.

3.3 Choosing and Tailoring the Building Blocks

Choosing and tailoring building blocks for a specific project is a two-step process. Step one involves selecting the appropriate building blocks from the inventory. This step involves adherence to some basic options for using individual building blocks, usually based on organizational policy, such as the ones that follow:

a. Some building blocks are always implemented as is.

b. Some building blocks may be tailored according to a set of guidelines. (Specific rules need to be documented for each tailorable building block. Generally, the guidelines will state whether the building blocks may be altered or whether only parts of the building blocks may be used.)

c. Some building blocks may be waived with appropriate approval.[5]

d. Some building blocks may be replaced with appropriate approval.

e. New building blocks may be added with appropriate approval.[6]

In all cases, the customer's needs and management philosophy provide major inputs to the tailoring decisions.

Step two involves tailoring the individual building blocks. The project characteristics, including technical and acquisition requirements, are the primary inputs needed to choose and tailor the correct set of building blocks for the project. Paragraph 3.3.1 defines the general approach to tailoring, and Paragraph 3.3.2 discusses making detailed tailoring decisions based on the project characteristics identified inTable 3-1.

Table 3-1. Sample project characteristics.

Characteristic	Quantification
Size and Complexity:
Software Product (estimated SLOC or FP)	.
Documentation (estimated # of pages)	.
Development Team (estimated # of people)	.
System Product Mix:
Number of HWCIs	.
Number of CSCIs	.
Number of Interfaces (External)	.
Type of Software (Command & Control, Embedded, MIS, ATE)	.
Type of System (Centralized, Distributed, etc.)	.
Intent (Feasibility study, research, operational system, incrementally developed operational system, upgrade to an existing system, etc.)	.
Criticality (Life Critical, Safety Critical, etc.)	.
Users
Number of Users	.
Type of Users	.
Local or Distributed	.
Number of Installations	.
Life of Product (Number of months or years)	.
Upgrade Interval	.
Formality
Development requirements	.
Formal reviews and audits	.
Formal approval of deliverables and baselines	.
Control
Management visibility level required
Development Organization	.
Acquirer Organization	.
Project Risk Management
Cost	.
Schedule	.
Technical	.
Key: ATE - automatic test equipment CSCI - computer software configuration item FP - function points HWCI - hardware configuration item MIS - management information system SLOC - source lines of code

3.3.1 The Tailoring Process

Tailoring rules are part of the organization's standard software process building blocks as shown in Figure 2-1. These rules provide directions on how to tailor the specific building blocks that comprise the organization's standard software process to the needs of a project. As previously mentioned, some of the building blocks always will be used, e.g., project management, SCM, etc. Other building blocks may be used only as required, e.g., peer reviews may only be required for projects with greater than three developers. Figure 3-2 expands on Figure 3-1 to show the basic steps required to tailor an organization's standard software process to the needs of a specific software process.

As shown in Figure 3-1, project information, organization inputs, and external inputs are all needed to tailor a software process for a specific project. Figure 3-2 shows that these inputs are required to identify the characteristics of the project. Then, in addition to the project characteristics identified during the first step of tailoring, subsets of the information shown in Figure 3-1 are needed as inputs to choose and tailor the correct set of building blocks for the project.

Figure 3-2. Tailoring a process for a software project.

For example, the building blocks that comprise the organization's standard software process and the rules for tailoring the building blocks to the needs of a project are the organization inputs required to help derive the project's defined software process.

3.3.2 Making Tailoring Decisions

Tailoring an organization's standard software process takes guidance from the organization's tailoring rules, information about the incoming project, knowledge of the requirements used by the acquisition organization, and software project management experience to make informed decisions. As an organization begins tailoring its standard software process, it is important to use experienced individuals to help mold the tailoring process and provide guidance as new project managers become involved with incoming projects. This will help reduce the amount of confusion and rework that often accompany an organization's first attempts at modifying/tailoring their processes for the needs of a project.

Table 3-2 provides examples of tailoring guidance based on the information obtained by filling out the project characteristics form identified in Table 3-1. The tailoring process for individual building blocks (Step 2) is as follows:

a. Quantify the project characteristics identified in Table 3-1.

b. Interpret the quantification of the project characteristic using the heuristics identified in Table 3-2 (or locally defined tailoring rules).

c. Identify the set of building blocks to modify (or use part of), waive, or replace.

d. Decide on the exact tailoring decisions for each selected building block.

It is assumed that the building blocks that are not identified in the tailoring process will be used for the project without change.

When the tailoring process is complete, the project's defined software process is first documented as an agreement between the project team and the organization regarding how the organization's standard software process will be tailored for this project. Second, the software development plan is developed to reflect the process to be implemented on the project. These two topics are addressed in Paragraph 3.4.

Table 3-2. Example tailoring guidance.

Key Area	Quantification	Heuristics	Examples of Affected Building Blocks
Size and Complexity	Large and complex. Many hardware and software elements that need to interact. Generally built by many distinct organizations.	· Formalize requirements traceability and cross-organization communication. · Use standardized documents. · Where possible combine documentation and testing across organizations. · Share SEEs and tools across organizations.	· Software Lifecycles · Support Tools · Risk Management · Technical Documentation · Software System Test
	Application or installation critical.	· If additional safety requirements, plan a safety program using MIL-STD-882C Safety Standard as a guide. · Use reliability modeling and testing. · Use secure development and test environments (as applicable).	· Software Lifecycles · Reviews · Metrics · Technical Documentation · Unit Test · Software System Test
	Medium size and complexity. Some interfaces with other software. Coordination with other software projects required.	· If interim software but still operational, need to worry about reliability, availability, testing, etc.	· Requirements Management · Software Lifecycles · Technical Documentation · Reviews · Metrics · Unit Test · Software System Test
	Special purpose. Limited application. Small number of users. Essentially an independent prototype.	· If a throw-away, minimize documentation; use engineering notes only. · If small team, limit inspections. · No formal, independent testing. · No specific language requirements. · Still need SCM control, but with limited formality.	· Requirements Management · Software Configuration Management · Inspections · Software Lifecycles · Unit Test · Technical Documentation · Reviews · Metrics · Software System Test · Programming Languages · Project Management
Formality	Military Standards	· If a system upgrade or existing system replacement, should you change standards for the new software, e.g., from DOD-STD-2167A to MIL-STD-498?	· Risk Management · Reviews · Technical Documentation · Software Lifecycles · Software Configuration Management · Support Tools · Project Management
	Commercial Standards	· Know what to expect in advance.	· Possibly All Available for Tailoring
	Subcontractor Defined Standards	· Don't do it without fully understanding the subcontractor's standards and ensuring they meet the project's needs.	· Only the Building Blocks Affected by other Project Criteria
	Traditional Acquisition Requirements	· Use traditional reviews (e.g., PDR, CDR, etc.) using MIL-STD-1521B as a guide. · Use traditional project management rather than IPTs.	· Reviews · Software Lifecycles · Software Configuration Management · Project Management
	Integrated Products Teams	· Use in-process reviews and open developer/ acquirer relations and agreements.	· Reviews · Software Lifecycles · Technical Documentation · Software Configuration Management · Project Management
	Loose	· Don't do it, except for throw-away prototypes.	· Software Lifecycles · Metrics · Building Blocks Affected by Other Criteria
Control	Cost Risk(s)	· Minimize deliverable documents, formality of reviews.	· Reviews · Software Lifecycles · Technical Documentation · Project Management · Risk Management
	Schedule Risk(s)	· Choose simplest adequate life cycle. · Use parallel implementations. · Language choices e.g., 4GL/rapid prototyping. · Reduce documentation.	· Reviews · Software Lifecycles · Programming Languages · Technical Documentation · Project Management · Risk Management
	Technical Control and Risks	· If the problem and solution not well understood, choose either rapid prototyping, incremental deliveries, or evolutionary model. · If requirements expected to be unstable, plan for rework, provide metrics for requirements stability. · If the project will reuse legacy or reusable software, ensure strong SCM. · If the project is expected to produce reusable code, enforce coding standards and ensure strong SCM. · If technical risks, use prototyping or COTS as risk mitigation.	· Possibly All Available for Tailoring
Key: CDR - Critical Design Review COTS - Commercial-Off-The-Shelf 4GL - Fourth-Generation Language PDR - Preliminary Design Review SEE - Software Engineering Environment