This example illustrates the issues that need to be addressed to tailor an organization's standard software process to the needs of a specific project. It includes both a sample project scenario and a set of software process characteristics. The example project and process characteristics are highly simplified to help show how software processes can be tailored to the needs of a project.
A software developer, known as XDEVEL, has been tasked to build an upgrade to one of the fighter aircraft used by the U.S. Air Force.
This aircraft needs to update its navigation system with Global Positioning System (GPS) capabilities. The GPS model chosen for this aircraft has been used in a similar application for a Navy aircraft, so it is considered to be an off-the-shelf item. Modifications to the GPS software will be required to integrate the GPS into the Air Force aircraft. Aircraft software will need to be written (and/ or modified) to support the following needs:
a. Integrate the GPS into the existing navigation system.
b. Display updated navigation information on the pilot's Head-Up Display (HUD).
c. Allow the pilot access to the modified navigation data through the Control Display Unit (CDU).
d. Communicate GPS information to ground control and to other aircraft in a mission. (No equipment upgrades are planned to support the increased communications requirements.)
The requirements for this modification are well known. The current navigation system and interface software for the aircraft is written in C, and due to the limited nature of the changes to the navigation software, no change in language will be required. MIL-STD-498 will be used as the software development and documentation standard for this acquisition.
The contractor that developed the GPS system for the Navy aircraft will make the GPS software modifications on a subcontract to XDEVEL. XDEVEL will provide a specification of the modification requirements to the subcontractor. This will reduce the cost and risk associated with modifying the GPS software.
XDEVEL has determined that about 9,000 SLOC will need to be developed and/or modified to implement this new capability in the aircraft. The condition of the existing navigation software is not known and the customer wants formal documentation, so it was assumed that the productivity for the development team will be about that of new development.
The acquirer will supply a System/Subsystem Specification (SSS), a System Design Description (SSDD), and an Operational Concept Document (OCD). The acquirer will modify the OCD during development to reflect the changing needs of the system.
The developer will be responsible for the following technical documents:
a. Software and Interface Requirements Specifications (SRS & IRS).
b. Software and Interface Design Descriptions (SDD & IDD).
c. Software test documents, including:
1. Software Test Plan (STP).
2. Software Test Description (STD).
3. Software Test Report (STR).
The developer will be responsible also for the following management and support documents:
a. Software Development Plan.
b. Software Transition Plan (STrP).
c. A Software Version Description (SVD).
This means that the software effort will take approximately 3.25 man-years over a period of 12 months. The development, test, and technical documentation effort will be approximately 2.25 man-years; the remaining 1.0 man-year will be dedicated to software project management, the support documents, SQA, and SCM. User documentation will be produced as part of the new CDU development effort. The GPS subcontractor will develop the SRS and SDD for the GPS from existing materials created for the Navy.
The pilots for this aircraft dislike the CDU and want a replacement. The current CDU has a very small keypad, and the display is only 4 lines by 40 characters. The pilots would like to at least double the display capacity, increase the display visibility, change the keypad, and add new query capabilities. The pilots want an opportunity to help determine the requirements for the CDU and to have significant inputs to the changes to the user interface.
Since the pilots want so much input to the new CDU, XDEVEL feels that prototyping will be useful to support the user interface development. Also, it is not known how many new capabilities will be added to implement the pilots' query requirements.
XDEVEL is assuming that the new CDU will have all new software. The Air Force wants the new CDU to be implemented in Ada, and the existing code is in assembly language so it is assumed that there will be no software code reuse. MIL-STD-498 also will be used for the CDU development, and as with the GPS integration, the customer is requesting significant amounts of formal documentation.
Based on XDEVEL's knowledge of the existing CDU and a rational appraisal of the possible new requirements, XDEVEL assumes that the new CDU will require about 20,000 SLOC to implement. Given the unknown nature of the new requirements, this is a soft estimate. The customer wants the new CDU to be a significant improvement from the current version, so there may be some flexibility to renegotiate the terms of the contract when the first sets of prototypes are completed and approved by the pilots.
In both parts of this aircraft upgrade, software supportability is a primary concern for the customer. Thus, planning for the software transition to the Government and for Post Deployment Software Support (PDSS) is stressed in the acquisition. This may add labor to the existing software estimates from XDEVEL.
This report uses the GPS example. The CDU example is described for the reader to use to explore the process tailoring concepts independently.
XDEVEL is a respected, successful development organization. The organization has a well defined, flexible process for planning for and developing software. It is known also as being an open and innovative place to work. XDEVEL received its CMM assessment as a Level 3 organization approximately one year ago.
Early software project planning is stressed, and the plans are developed to integrate effectively with the other engineering plans for each project. There is strong communication among all the engineering disciplines, and each new project is managed from an integrated system view.
The software development plans are reviewed and approved by all affected engineering groups and upper management before implementation. Software estimates are derived through expert analysis and documented for use throughout the project's life. These estimates are backed up with outputs from estimation tools that are used to give a "reality check" to the experts' initial ideas. Actual project data is retained to support an estimation improvement effort under way at XDEVEL.
Software project management metrics are used to provide visibility into project performance. When performance deviates from the initial plans, the project manager is responsible for either making changes to the way the project is being handled to bring the project back into conformance with the plan or replanning, as necessary. Software subcontracts are managed using a set of defined policies and procedures.
Software requirements, design, and code inspections are used to support development. Defect metrics from the inspections are maintained. Other product related metrics are identified and maintained for each development effort to help keep reasonable visibility into the development effort. These metrics also are used to support software project management and risk assessment.
SQA and SCM are part of all software development and maintenance efforts. Metrics from SQA product and process audits are used to help improve product quality and software process efficiency. SCM is used both in its classical role and as a support mechanism for software requirements management.
All software engineering personnel have and maintain a personal training plan that helps them keep up-to-date on their requisite engineering skills. Based on project needs, extra training may be required for special needs.
XDEVEL has three basic software life cycles that are approved for use within the organization. They are: waterfall; incremental development, which uses a basic waterfall within each "block release cycle" for an evolving product; and a spiral model that relies heavily on prototyping for the first iteration or two through the spiral. Alternatives to these life cycles are allowed as long as the alternatives are documented and approved by upper management and the SEPG. The "approved" engineering processes for XDEVEL are maintained on-line for easy access.
Testing also has defined processes from the unit level through to software system testing. All testing that comprises the formal qualification testing is performed by independent test personnel.
During the last three years, XDEVEL has implemented a "lessons learned" policy that requires that at the end of a software project, the project team meets to discuss the successes and problems encountered during project execution. The lessons learned are documented and maintained to help new projects avoid problems and to support software process improvement. The lessons learned, metrics data, approved software and management processes, and other useful information is maintained in a software engineering library for the corporation. Much of the information is accessible on line. The information that exists only in hard copy is catalogued and referenced in the on-line library. All information about each project is cross referenced for easy retrieval. SCM developed and maintains the library.
A team of engineers and managers from the software engineering organization are responsible for maintaining the building blocks in a library, keeping the approved software management and engineering processes up to date, and identifying new opportunities for improvement. This team reports to the manager of software engineering and to the corporate vice president of engineering. The vice president of engineering maintains a keen interest in the software engineering processes for the corporation. The manager of software engineering and the vice president of engineering are responsible for providing quarterly reports to the company president on the state of software engineering and software process improvement.
The basic information about the example is:
a. Size ~ 9000 SLOC.
b. 1 CSCI on aircraft. 1 CSCI on GPS to be modified through subcontract.
c. >= 5 interfaces external to the GPS.
d. 150 aircraft in the inventory to be upgraded; one user for each aircraft. It is assumed that the aircraft will remain in service for at least another decade.
e. ~ 800 pages of documentation (based on the definition in Paragraph 4.1.1).
f. Subcontract for modifications to GPS code and for new (or modified) GPS documentation.
g. Minimal technical complexity.
h. Life critical application.
i. Moderate need for management visibility.
j. Testing needs to be used to assure the reliability required to fulfill the requirements for the aircraft.
The first tailoring step is to list the known project characteristics in the project characteristics form to support further analysis, as shown in Table 4-1. The areas for concern are human safety, the level and formality of documentation, implementation of MIL-STD-498 and its changes in philosophy from previous standards, lack of formal reviews, and the unknown complexity that could exist in the interface code.
Table 4-1. Project characteristics for GPS example.
| Characteristic | Quantification |
| Size and Complexity: | |
| Software Product (estimated SLOC or FP) | ~9,000 |
| Documentation (estimated # of pages) | 800 pages, 275 from subcontract |
| Development Team (estimated # of people) | 7 - 3 developers, 2 testers, 1 doc., 1 mgr |
| System Product Mix: | |
| Number of HWCIs | 1 |
| Number of CSCIs | 2 - 1 new, 1 mod |
| Number of Interfaces (External) | 5 |
| Type of Software (Command & Control, Embedded, MIS, ATE) | Embedded |
| Type of System (Centralized, Distributed, Mission Critical, Weapons System,etc.) | Weapon System |
| Intent (Feasibility study, research, operational system, incrementally developed operational system, upgrade to an existing system, etc.) | Upgrade |
| Criticality (Life Critical, Safety Critical, etc.) | Life Critical |
| Users | |
| Number of Users | 1 per Installation |
| Type of Users | pilots |
| Local or Distributed | Local |
| Number of Installations | 150 |
| Life of Product (Number of months or years) | 10 Years |
| Upgrade Interval | Unknown |
| Formality | |
| Development requirements | MIL-STD-498 (Upgrade from DOD-STD-2167A) |
| Formal reviews and audits | In-Process Reviews |
| Formal approval of deliverables and baselines | Formal approval of plans and all artifacts delivered after CSCI test and revised after flight test |
| Control | |
| Management visibility level required | |
| Development Organization | Moderate |
| Acquirer Organization | Unknown |
| Project Risk Management | |
| Cost | Moderate |
| Schedule | Moderate |
| Technical | Low - Known Problem |
This is the project information that provides one of the primary
inputs for tailoring the XDEVEL's standard software process to
the needs of the project.
From the description of how XDEVEL does business, as presented in Paragraph 4.1.2, it is obvious that the organization has a well-defined software process. The building blocks identified in Figure 4-1 are either mentioned or strongly implied in Paragraph 4.1.2.
Figure 4-1. XDEVEL's building blocks.
Based on the project characteristics identified in Table 4-1, the guidance in Table 3-2, and XDEVEL's building blocks, Table 4-2 identifies the XDEVEL building blocks that may need to be tailored for the GPS software project.
On examining the project characteristics and candidate affected building blocks, the project manager notes the following regarding the issues related to the building blocks in question:
a. Adding the GPS to an existing aircraft is a known problem and the system will be small; thus a waterfall life cycle will be used.
b. Reliability modeling and testing are already documented in the unit test and software system test practices.
c. Reliability metrics will be stressed during testing. These metrics are already documented in the metrics practices for use with life-critical or safety-critical systems.
d. The SCM practices are focused on a standard set of deliverables with relatively standard reviews. Modifications may need to be made for the different baselines that will be established for this project.
e. The review practices stress a formal review process for projects using a waterfall life cycle; this will need to be modified for the in-process reviews used for this project.
f. Since use of MIL-STD-498 documentation is new to the organization, it will be important to track progress on document development for this project. These practices are already documented in the project management and metrics building blocks, so no change will be required.
g. The metrics practices are internal; they do not cover sharing data with the acquisition organization. This is a modification to the metrics building block, and it may want to be added to the metrics building block in the next release. (Sharing metrics data also may become interesting as part of the lessons learned at the end of the project.)
h. Although the risk management practices will be used, there is nothing in the approach to risk management for this application that is out of the ordinary. Use the risk management building block as written; no change.
The project manager is responsible for
developing the compliance agreement for the project's defined
software process and for developing the software development
plan.
Table 4-2. Candidate XDEVEL building blocks
to be tailored.
| Key Area | Quantification Factors | Heuristics | Candidate Affected Building Blocks |
| Size and Complexity | Small but life critical application to be installed on at least 150 aircraft, 10-year operational life, Unknown software upgrade schedule. | · Plan a safety program using MIL-STD-882C Safety
Standard as a guide · Use reliability modeling and testing |
· Software Lifecycles · Metrics · Unit Test · Software System Test |
| Formality | · MIL-STD-498 (Upgrade from DOD-STD-2167A) · In-Process reviews · Formal Documentation · Formal approval of plans during development · Formal approval of all other items after CSCI testing |
· Plan for strong internal SCM for developmental
artifacts to ensure traceability of changes to documents
and code · Use full implementation of MIL-STD-498 Data Item Descriptions (DIDs) for required documents · Use a metrics program to track project progress and conformance to estimates |
· Project Management · Reviews · Software Lifecycles · Software Configuration Management |
| Control | · Unknown acquirer's management visibility needs · Moderate cost and schedule risk |
· Share metrics data with acquirer · Choose simplest life cycle to implement for a known problem · Documentation set in contract - unable to modify · Use C for new system: No language change |
· Software Life Cycles · Metrics · Risk Management |
The changes to the organization's standard software process are relatively minor for this project. As discussed in Paragraph 3.4.1, the deviations can be documented by exception in a compliance agreement. In this case, the following tailoring is applicable:
a. Choose the waterfall model from the three available software life cycles.
b. Delete the allocated baseline (SRS and IRS) from the SCM practices and refer to internal control processes.
c. Add external control of the software development plan to the SCM practices.
d. Modify review requirements to reflect only in-process reviews with the acquirer.
e. Modify the metrics practices to add external distribution of metrics data to the acquisition organization.
In practice, these modifications need to be made with references to the document names and paragraph numbers that will need to be modified or deleted to reflect the tailoring. Additions can be made through descriptions of the changes and document references.
The first step in developing the software development plan is to examine the system WBS and determine the level of detail needed to identify the processes that will be employed to run the project. In the case of the GPS/CDU Upgrade program for XDEVEL, program's products can be decomposed as shown in Figure 4-2 to get to the GPS Interface and Communications Software Project, which is the project name for the example presented in this section.[11]
The software project then is decomposed into the processes that will be employed to run the project. In this case the major processes are project management, software development support, software development, software qualification, and post-development support. Then these processes are broken down into their respective elements to show more detail in how the project will be run. For example, the software development and qualification items show a decomposition that is consistent with the waterfall life cycle chosen for this project, as discussed in Paragraphs 4.3 and 4.4.1. The WBS decomposition is complete when it is determined that resource allocation, costs, and schedules can be tracked based on the work definitions shown in the WBS and an associated work breakdown description.
At this point, a schedule estimate needs to be documented based on the WBS. Figure 4-3 is a Gantt chart based on the WBS decomposition of the GPS Interface and Communications Software Project (starting with WBS element 1222).
When the schedule is completed, the activity network can be documented to show the dependencies among the activities identified in the WBS. Figure 4-4 is a simplified activity network based on the WBS and schedule provided in Figures 4-2 and 4-3.
The final planning steps are to record the processes, activities, and plans in the software development plan as discussed in Paragraph 4.4.2.4.
Paragraph 3.4.2.4 discussed the options for documenting the modifications to the building blocks in the software development plan. For the GPS Interface and Communications Software Project, three building blocks will be modified and a fourth will use one of the three life cycle options documented in the XDEVEL organization's standard software process. All other building blocks will be used as is.
Figure 4-2. GPS Interface and Communications Project WBS.
Figure 4-3. GPS Interface and Communications Project Gantt chart.
To document the project's defined software process in a software development plan using the outline identified in Table 3-3, the tailoring for the XDEVEL building blocks can be documented in the following ways:
a. Reference to the life cycle adopted for this project from the standard building blocks could be made in the software development plan, Paragraphs 3.3 or 4.1 (or their subparagraphs).
b. Modifications to the SCM practices to cover deletion of the allocated baseline and addition of external configuration control for the software development plan should be documented in the software development plan, Paragraph 5.14 (or its subparagraphs).
Figure 4-4. GPS Interface and Communications Project activity network.
c. Modifications to the review requirements to reflect only in-process reviews should be documented in Paragraph 5.18 (or its subparagraphs).
d. Modifications to the metrics practices for external distribution of metrics data should be documented in the subparagraphs for Paragraph 5.19 that deal with metrics.
Where no building block exists to cover a specific process area in the software development plan, that information will need to be generated. For example, XDEVEL does not have a process building block for establishing the software development environment; this will need to be documented in Paragraph 5.2 of the software development plan. Building blocks used as is should be referenced from the appropriate paragraphs in the software development plan (e.g., the SQA practices will be referenced from Paragraph 5.16 rather than repeated).
The WBS, schedule, and activity network provide inputs for Paragraphs 3.4, 4.2, and Section 6. The remainder of the plan is developed specifically to address the unique requirements of this project, e.g., the overview of the work and constraints on it that are covered in the paragraphs of Section 3 and the organization information presented in Section 7.
The plan, when completed, defines the work to be done, constraints on the work, and the processes used to complete the work. This information then is used to manage the project and to provide the foundation for measuring project progress, process conformance, and selected product measures.
Tailoring an organization's standard software process to the needs of a project is a detailed process that takes time and experience to complete successfully. The gains in streamlining software project planning and management appear to far outweigh the time and effort required to ensure that the project's defined software process (i.e., the tailored process) meets the needs of the project.
Throughout the research for this report, the following concepts emerged as important to the tailoring and planning processes:
a. Whenever possible, an organization's standard software process should be modular. It should consist of a set of building blocks that can be used in a number of ways to fulfill the needs of a software project.
b. While an organization's standard software process may need to fulfill the requirements of a process standard or other form of guidance, the organization's standard software process should be developed to fulfill the needs of the organization rather than simply comply to a specific form of guidance.
c. The organization's standard software process should be written as requirements so that compliance is mandatory and can be audited successfully.
d. The WBS, schedule, and activity network identify the processes to be employed on the project, their sequence, and their critical dependencies.
e. Software development plans contain logical descriptions of the process(es) to be employed on a software project (as exemplified in Table 3-3). These processes can be documented through references to the building blocks that will be used on the project along with descriptions of the modifications and waivers that provide the process tailoring specific to the project.
f. The software development plan forms the foundation for measurement to be implemented on a software project. It is important to ensure that the elements of the plan are measurable.
g. By using a defined, documented process to tailor the organization's standard software process to the needs of a project, a base of information can be developed that will help members of an organization understand the types of variations that can exist between projects and make the adjustments necessary to fulfill the needs of the project prior to project implementation.
The only way to finally prove the value of tailoring the OSSP to the needs of a project is to do it and to measure the results in improvements in the planning process and in project performance.
