IEEE Descriptions

The discussion of the C4ISR Architecture Framework cites an architecture definition, attributed to the IEEE [9.6], as:

A structure of components, their relationships, and the principles and guidelines governing their design and evolution over time

This definition is useful, but does not give the prospective architect a blueprint for how to architect a system. Once an architecture has been formulated, it is very likely to satisfy the broad definition cited above.

Yet another view of systems and their architectures is presented in the IEEE standard for systems engineering [9.7]. In Chapter 7, we noted that the IEEE expanded from four to five the key elements of the systems engineering process, yielding the following:

1. Requirements analysis

2. Functional analysis/allocation

3. Synthesis

4. System analysis and control

5. Verification and validation

The process ultimately produces a preferred system architecture, which the IEEE defines as:

The composite of the functional, physical and foundation architectures, which form the basis for establishing a system design [9.7].

In addition, the definition points the reader to requirements traceability and allocation matrices that presumably connect the overall system design to various aspects of the above-cited three architectures. Although definitions of the above three subordinate architectures are provided in the standard, it is difficult to see how to construct these architectures without seeing an example or two. Nevertheless, one can accept the notion that ''views'' of the architecture can be associated with the ideas behind ''functional, physical and foundation.'' These views, by immediate observation, are not the same as those developed by the DoD C3I (command, control, communications, and intelligence) world, as discussed above.

As we move with the IEEE into the software domain, we find a standard that focuses upon a recommended practice for architectural description [9.8]. This standard explores ''the activities of the creation, analysis, and sustain-ment of architectures of software-intensive systems.'' The standard makes the very significant point that ''concepts of architecture have not been consistently defined and applied within the life cycle of software-intensive systems.'' Instead, it argues that it is indeed possible to describe architectures. These descriptions can also be thought of as ''views'' of an architecture, even though we may not be completely clear as to how to develop an architecture. Selected views of an architecture may be illustrated, in the hardware case, by Figures 9.1 through 9.3 which have already been discussed. Thus, we are seeing a difference between having a ''single accepted framework for codifying architectural thinking,'' and ''views'' or ''descriptions'' of an architecture. We attempt, in this chapter, to narrow this gap by setting forth a prescriptive method for developing an architecture, whether it be related to hardware, software, or a combination thereof.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment