Depending on the architecture level needed (e.g., high levels of abstraction that hide design and implementation details) and the intended audience, the Framework products may be developed by applying an iterative method. Iterative development crosses all views. OVs can drive SV and TV changes, SVs can drive OV and TV changes, etc. Products iterate across views in the same way that they iterate within one view but across levels of detail. During this iterative development process different models are developed at varying levels of abstraction with products that trace from one model to another [Booch, 1999]. That is, at the highest level of abstraction, when only a minimum of Framework products are developed to help describe a new concept of operations, a few products may be developed to produce one model of this architecture (denoted Model A). This first model may consist of only highly abstract/generic sets of operational nodes, operational activities, and so forth. Later, when new details need to be added and the architecture expanded to show more design detail, a new model (Model B, consisting of modified Model A products plus additional products as necessary) must be developed.
The new products that make up Model B will include and trace back to the original group of products (that make up Model A of the architecture). For example, an operational node in an OV-2 product (as part of Model A) may have been used to represent an aggregated organization or command (one that may consist of multiple subordinate operational nodes, but it is deemed unnecessary to show those subordinate nodes at the Model A level). In Model B, the operational node of Model A’s product may now be expanded to show the subordinate nodes. No new “root-level” Framework operational nodes should be introduced at this level that do not trace back to the previous model. For example, if in the process of model refinement, it is determined that an operational node is part of the architecture, and that this node is not yet a part of any of the aggregated operational nodes of OV-2 included in Model A, then Model A’s OV-2 needs to be updated to include the newly identified node. Model B’s OV-2 can then include that subordinate node, which will be a decomposition of the Model A node, and will trace back to that node.
Defines standard
Replaced/Superseded by document(s)
Cancelled by
Amended by
File | MIME type | Size (KB) | Language | Download | |
---|---|---|---|---|---|
DoD Architecture Framework Vol. II Product Descriptions.doc | application/msword | 7.56 MB | English | DOWNLOAD! |