Home > Articles > Programming

  • Print
  • + Share This
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.

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

FIGURE 3-4 TOC’s for Projects A, B, and C (CCPDS-R) Relative to Baseline Costs

  • + Share This
  • 🔖 Save To Your Account