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.
4.3 Choosing and Tailoring the Building Blocks
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-1are 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 |
No comments:
Post a Comment