- 3.1 Failure Story: Sequential RPV Systems Engineering and Development
- 3.2 Success Story: Concurrent Competitive-Prototyping RPV Systems Development
- 3.3 Concurrent Development and Evolution Engineering
- 3.4 Concurrent Engineering of Hardware, Software, and Human Factors Aspects
- 3.5 Concurrent Requirements and Solutions Engineering
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.3 Concurrent Development and Evolution Engineering
As good as the success story in Section 3.2 appears to be, it could have a fatal flaw that is shared by many outsourced system acquisitions—namely, its primary focus on satisfying today’s requirements as quickly and inexpensively as possible. This may build architectural decisions into the system that make it difficult to adapt to new opportunities or competitive threats. From an economic standpoint, this approach neglects the Iron Law of System Evolution:
- For every dollar invested in developing a sustained-use system, be prepared to pay at least two dollars on the system’s evolution.
Data from hardware-intensive systems indicates that the average percentage of life-cycle cost spent on operations and support (O&S%) is a relatively small 12% for single-use consumables, but is 60% for ships, 78% for aircraft, and 84% for ground vehicles 5. For software-intensive systems, O&S% figures from seven studies range from 60–70% to more than 90% 6.
Even so, many projects (and some system acquisition guidance documents) continue to emphasize such practices as “maximizing system performance while minimizing system acquisition costs.” Such practices generally lead to brittle, point-solution architectures that overly constrain evolution options and inflate evolution costs, and to a lack of key system deliverables for reducing operations and support costs, such as maintenance and diagnostic tools and documentation, test case inputs and outputs, and latest-release COTS components. (COTS vendors generally support only their latest three releases. In one maintenance study, we encountered a system that was delivered with 120 COTS products, 66 of which were on releases that were no longer supported by the vendors.)
Several good practices for avoiding such situations can be applied in the initial ICSM Exploration phase. These include early addressing of post-deployment and aftermarket considerations such as development of a full operations concept description, including the following considerations:
- Identification and involvement of key operations and maintenance stakeholders
- Agreement on their roles and responsibilities
- Inclusion of total ownership costs in business case analyses
- Addressing of post-deployment supply chain management alternatives
- Identification of development practices and deliverables needed for successful operations and maintenance
Since operations and maintenance costs can consume 60% to 90% of an enterprise’s resources, it is also important to build up a knowledge base on their nature, and to apply the knowledge to reduce their costs and difficulties. For example, this was done for the two TRW projects summarized in Figure 3-2. As indicated in Figure 3-2, their major sources of rework effort were found to be off-nominal architecture-breakers. This source of risk was added to the TRW risk management review guidelines for future projects. Also, their additional major sources of life-cycle change were determined to be hardware–software interfaces, new algorithms, subcontractor interfaces, user interfaces, external application interfaces, COTS upgrades, database restructuring, and diagnostic aids, as shown in Table 3-1.
){kind=link}
TABLE 3-1 Projects A and B Cost-to-Fix Data (Hours)
|
Category |
Project A |
Project B |
|
Extra-long messages |
3404 + 626 + 443 + 328 + 244 = 5045 | |
|
Network failover |
2050 + 470 + 360 + 160 = 3040 |
|
|
Hardware-software interface |
620 + 200 = 820 |
1629 + 513 + 289 + 232 + 166 = 2832 |
|
Encryption algorithms |
1247 + 368 = 1615 |
|
|
Subcontractor interface |
1100 + 760 + 200 = 2060 |
|
|
GUI revision |
980 + 730 + 420 + 240 + 180 = 2550 |
|
|
Data compression algorithm |
910 |
|
|
External applications interface |
770 + 330 + 200 + 160 = 1460 |
|
|
COTS upgrades |
540 + 380 + 190 = 1110 |
741 + 302 + 221 + 197 =1461 |
|
Database restructure |
690 + 480 + 310 + 210 + 170 =1860 |
|
|
Routing algorithms |
494 + 198 = 692 |
|
|
Diagnostic aids |
360 |
477 + 318 + 184 = 979 |
|
Total |
13,620 |
13,531 |
Following Dave Parnas’s information-hiding principles 7, these sources of change were encapsulated in the architectures of similar projects, and additional systems engineering effort was devoted to addressing off-nominal architecture breakers. As detailed in the next chapter, by investing more effort in systems engineering and architecting, the highly successful Command Center Processing and Display System-Replacement (CCPDS-R) system 8 flattened the usual exponential growth in cost to make changes even later in the life cycle. The resulting savings in total cost of ownership are shown in Figure 3-4 9. This figure indicates that the added investment in CCPDS-R was recouped via rework reduction by the end of the initial development cycle, and generated increasing savings in later cycles.
)
FIGURE 3-4 TOC’s for Projects A, B, and C (CCPDS-R) Relative to Baseline Costs