Developing Patterns and Templates - An enterprise that sets out to develop patterns for the diagrams, documents and models used in their product lines has several possible approaches. One is to assign a team of highly experienced systems engineers to develop the patterns for a family of systems from scratch. This is an effective approach but it can be an expensive approach, even if experienced consultants are used to facilitate the process. However, it does achieve the desired patterns in a few weeks or months so that the patterns are available for near term design efforts. Often the expense is justified because having the patterns provides a competitive advantage over enterprises not used PBSE by significantly reducing the cost of the systems engineering portion of developing new products. If the experienced engineers are waiting for a new job to start then they can work on developing patterns at no additional cost to the enterprise.
A second approach is to save copies of the diagrams from a previous design effort and treat the copies as draft patterns. The diagrams for a current design effort are developed in two steps. First, all new items are added to the draft pattern diagram and none of the items in the draft pattern are deleted even if they don’t apply to the current design. The resulting diagrams and models are saved as revised draft patterns. Second, the revised draft patterns are edited to delete items that don’t apply to the new design effort. These diagrams and models are saved as the working documentation for the new design effort. This approach can take considerable time to develop patterns that are complete but it has the advantage of being nearly cost free.
Of course it is possible to combine the two approaches by initiating the second approach and then assigning experienced engineers that are temporarily between jobs to continuing the development of patterns. In all three approaches it is critical to thoroughly peer review the resulting patterns in order to have confidence that the patterns evolve to become complete and accurate.
Specific examples of models that should become patterns are presented in the following chapters as part of the description of the tasks systems engineers perform in carrying out the systems engineering process. This is a somewhat awkward way to present PBSE but it avoids having to present two versions of all of the models used in the systems engineering process. In some cases two or more methods are described for the same task; the intent is that the different methods can be used to verify the accuracy of work. Also individual engineers may have preferences for diagrams over matrices or vice versa. All methods should be considered candidates for patterns. Finally, in the version of PBSE presented here we include templates for text documentation as part of PBSE so that we extend the definition of PBSE beyond pure MBSE. We do this because many customers require text documents for items such as specifications, and because some documentation e.g. plans and data dictionaries are done in text documents. Using templates speeds the production of text documents and improves their accuracy just as using patterns speeds the production of labeled graphical models and improves their accuracy.
Candidate Models and Documents for Patterns – Listed here are example models and documents that are candidates for developing patterns and templates that support PBSE. Some are planning documents previously describes, some are described in subsequent chapters and some are outside of the scope of systems engineering. Not all apply to every type of system development but many do and not all possible candidates are listed. It is suggested that readers consider how to develop plans discussed in previous postings as templates. As systems engineering models and documents are described in the following chapters consider how these items can be developed as patterns for their specific organizations and systems.
Pattern Diagrams for a Family of Products:
- Parameter Diagrams at System and Key Subsystem Levels
- Context (or Domain) Diagram
- Logical Architecture Diagram
- Modes Diagram
- Sub Modes Diagrams
- Functional Flow Block Diagrams at Top and Second Level
- N-Squared Interface Diagram
- System Block Diagram
- Control Electronics Block Diagram (For products have digital processors and/or digital controllers)
Document Templates for Family of Products:
- Integrated Management Plan and SEMP
- Information Architecture (Document tree)
- System Specification
- Interface Control Document
- Mapping and Transition Matrices
- Top Level Quality Control/Mission Assurance Document
- Subordinate Quality Control/Mission Assurance Plans
- Design Description Document
- Typically Used Electronics Sub Systems Specifications
- Any Subsystems likely in most Products in Family
- Dictionary of Definitions
Consider what fraction of the total cost of a system development is involved in developing the models and documents listed. The cost likely varies with the type of system and organization but suppose it’s ten percent. If using patterns and templates saves half the time and cost, a very conservative estimate based on the authors’ experience, then the use of PBSE gives an organization a five percent cost advantage over its competition. If an organization doesn’t adopt PBSE and its competitors do then the organization is likely to be at least at a five percent cost disadvantage. In today’s global competitive environment cost advantages translate directly into bottom line profits or into increased market share with even greater contributions to the bottom line profits. Thus there is a high return on the investment necessary to develop and manage a pattern and template database.
No comments:
Post a Comment