RECOVERY

К оглавлению
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 
34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 
68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 
102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 
119 120 121 122 123 

Architecture recovery is an iterative and interactive process, accomplished in

four steps:

The first step is the discovery or definition of a set of views that represent

the system’s fundamental structural and behavioral elements.

The second step is a fusion of the extracted views.

The third step is the development of attribute-based relationships among the

system’s components.

The fourth step is revisiting the previous steps with a view to architectural

conformance and targets for reengineering.

52 DESIGN

52a (NO) The design process is not correct and/or traceable to

enterprise, customer, and standard processes.

Here we are talking about the design process, not the design. To be sure,

incorrect design processes can, and probably will, lead to incorrect design.

Whenever an incorrect design surfaces and is recognized, the design must be

changed. The question though is: ‘‘Why was the design incorrect in the first

place?’’ That cause is pursued in Cause Description 52c. So, chances are, we got

here by going through Cause Description 52c. Incorrect design processes are

determined by eliminating the other causes.

The design process is not correct and/or traceable to enterprise, customer,

and standard processes whenever the required numbers and types of Design

Reviews and the content of each Design Review are not traceable to the standard,

the customer, and the enterprise processes.

The design process is frequently defined by the customer in the Statement

OfWork. The customer will require that this particular program have a Preliminary

Design Review (PDR), a Critical Design Review (CDR), an In-Process Review

(IPR), or any number of other Design Reviews. In the supporting or standard

documents, the customer will define the content of those reviews. This is

the usual mode of operation. When an enterprise works with a customer or set

of customers, the enterprise generally incorporates the usual customer requirements

into the enterprise policies, plans, and processes. Probably the best example

of this is contractors who work with the federal government.

RECOVERY

Lay out the appropriate enterprise requirements (see glossary), the customer

requirements (from the requirements document), and the standard requirements

(see glossary) for the design process. Interrelate all the requirements and

summarize and organize them into a checklist that will drive the design process

paragraphs of the program plan. Retain that information to solidify all data

trails. You should end up with a general matrix that will boil down to an outline

similar to the one below. If it is not possible to accommodate the above steps,

go directly to the outline below and use and update it as necessary.

Paragraph Title

1.0 Organization

1.1 Objectives

1.2 Responsibilities

1.3 Authority

2.0 Decision and Control Process

3.0 Configuration Management

3.1 Hardware

3.2 Software

3.3 Documentation

4.0 Review Process

4.1 Design Reviews

4.2 Subcontractor Reviews

4.3 Design Approval and Certification

5.0 Continuous Acquisition and Logistic Support (CALS)

6.0 System Test Planning

7.0 Technical Performance Management

8.0 Communication Plan

9.0 Action Item Process

10.0 Conflict Resolution process

11.0 Requirement Management Process

12.0 Development Process (including trades)

52b (NO) The design is not correct and not traceable to the

requirements.

It is possible, but not likely, that a design is correct and yet not traceable to

the requirements. The primary ingredient in that process is luck. It is not a

desirable position in which to be. It is assumed that if you cannot trace the

design to the requirements, you do not have a Requirements Traceability Matrix

(RTM) or, if you do, the RTM is wrong or the design is wrong.