Insights into the practice of systems engineering
Vitech has published many technical papers at conferences, symposia, and other forums. These papers provide insights into the practice of systems engineering—specifically, model-based systems engineering—derived from practical experience on countless projects. Subjects range from broad industry topics such as requirements management and DoDAF, to specific topics that will assist you in learning more about GENESYS, CORE, and how to apply model-based systems engineering to your program.
A Concurrent Methodology for the Systems Engineering Design Process
Susan Childers and James Long, Vitech
The systems engineering design process as detailed in MIL-STD 499 does not adequately address the incorporation of design issues relevant to specialty engineering disciplines. This paper, presented at the 1994 International Symposium of the International Council on Systems Engineering in San Jose, CA, details a process by which the concerns of specialty engineers are addressed and incorporated into the system design in a consistent and efficient manner. The paper also introduces an incremental systems engineering process (The Onion Model) which allows complete interim solutions at increasing levels of detail during the system specification process.
Along with the three standard concurrent engineering focuses of requirements analysis, functional analysis, and architecture definition, the process includes concurrencies for specialty engineering. Each specialty engineer assesses the implications of the systems engineering design process in relation to the specific specialty requirements and evaluates the implications of the system functional and physical architectures on the realization of an adequate specialty engineering solution. Once an integrated solution achieves the approval of the acquisition agency, it is refined to the next level of detail. When the system level design is sufficiently refined to generate the System/Segment Specification, the segment development process may begin.
COTS: What You Get (In Addition to the Potential Development Savings)
James Long, Vitech
It comes as no surprise that incorporating an existing component into a system means you save in having to develop the component yourself savings in schedule and development costs. What often is surprising is the impact that incorporating an existing component has on the systems engineering process.
Foundational Concepts For Model Driven System Design
Loyd Baker, Paul Clemente, Bob Cohen, Larry Permenter, Byron Purves, and Pete Salmon; INCOSE Model Driven System Design Interest Group
This paper presents an initial viewpoint on an emerging technology: Model Driven System Design (MDSD). In contrast, the current state of practice has been characterized as document centered. Practitioners of system design are well aware of the technical and organizational difficulties of implementing current approaches. By modeling multiple aspects of a system throughout its life cycle, this new view of system design offers dramatic gains in productivity and product quality.
Integrating Information Security Engineering with systems engineering with systems engineering Tools
M. Douglas Higginbotham, Booz Allen & Hamilton; Joe Maley, Vitech; Albert J. Milheizler, Department of Defense; Bernard J. Suskie, Booz Allen & Hamilton
An Information System Security Engineering (ISSE) process will identify the quality of security services needed by users; help identify security mechanisms to satisfy user needs; lead to an effective security design; identify the quality of security services offered by the actual system; and develop the documentation necessary to effectively market the security services offered by a system. An effective and cost efficient method for managing and providing discipline for the ISSE process is for system developers to use an automated systems engineering tool.
Model-Based Proposal Development
Jerry Fisher, Vitech
The competition for new business is increasing. Bidders must increase their probability of win and reduce the cost of proposal preparation. This paper addresses the application of a model-based systems engineering tool, CORE, to the proposal preparation process and discusses how the user benefits by decreasing the cost of writing the proposal and being better prepared when the contract is awarded.
Model-Based Systems Engineering of Automotive Systems
Jerry Fisher, Vitech
For as long as systems engineers have been around, people have thought of them as “paper pushers.” Communicating the requirements to hardware and software designers with documents is fraught with problems. By using a model-based approach to systems engineering, there is no ambiguity. This method provides a unified, consistent and traceable design.
Most system engineers today use graphical representations of a system to communicate its functional and data requirements. The most commonly used representations are the Function Flow Block Diagram, Data Flow Diagram, N2 Chart, IDEF0 Diagram, Use Case, Sequence Diagram, Enhanced Function Flow Block (EFFBD), and Behavior Diagram. This paper discusses the characteristics of each, shows how they are related, and demonstrates that the EFFBD features comprise a “parent/unified” set of graphical system representations.
Requirements Development and Management Using Models
Loyd Baker, Vitech and Ann Christian, Standard Missile Company
Good program managers understand that a high pay-off in cost savings and schedule reduction can be attained by early analysis of their system requirements. Programs employing a traditional text-oriented requirements development approach experience significant numbers of misinterpretations and late-detected design errors resulting in increased costs, schedule slips, reduced capability, and canceled programs. This paper discusses how a well defined model-based approach to the development of requirements can eliminate or greatly reduce the incorporation of incorrect assumptions into system requirements.
Role of Systems Engineering Across The System Life Cycle
Jim Long and Loyd Baker, Vitech
The role of the system engineer does not end upon the publication of the system-level system specification, e.g., SSS, IRD, etc. In fact, the system engineer’s role does not end until the system has been decommissioned and discarded.
Systems Engineering in a COTS World
Richard Sorensen, Vitech
Using traditional systems engineering practices to accommodate commercial off-the-shelf (COTS) components requires focusing on those steps within the design process that allow identification of the constraints imposed by COTS items early in the design process. Two traditional systems engineering processes are reviewed for their insights into the major tasks, the goals, and the dependencies. With this understanding, the focus moves to discussion of a proposed approach for applying systems engineering practices using a process that retains a requirements-driven methodology while simultaneously adapting to the boundaries imposed by COTS items, thereby converging on a solution.
Interoperability Between the DOORS Requirements Management Tool and the CORE Systems Engineering Tool
Jody Fluhr and Pat Macdonald, Vitech
Many organizations use tools such as DOORS to facilitate basic requirements and document management. By leveraging the interoperability with CORE, projects extend automated support to the entire systems engineering effort including analysis, architectural, and management aspects critical to project success. This paper outlines the commonality and contrasts between the CORE and DOORS tools that affect data exchange, including the terminology and structure of each tool’s constructs. A mapping between each tool’s terminology/constructs is provided as well as a step-by-step illustration of one approach to port data between the tools.
Linking CORE with MS Project 2003
Pieter Bruring; ADSE
The project management capabilities of the CORE tool can be integrated with several commonly-used software tools. In this example, integration with MS Project is demonstrated. This enables the communication of task scheduling data central to the responsible team members. Normally, this information is locked in an MS Project sheet. Now it is available in CORE and can be published using a web interface. Contact Product Support to obtain the latest CORE custom scripts described in this paper.
A Natural Approach to DoDAF: Systems Engineering and CORE
Jim Long and Joe Maley; Vitech
The Department of Defense Architecture Framework (DoDAF), Version 1.0, specifies a set of “standard” views capturing various system perspectives. As with nearly all frameworks, the outline and contents are defined, but the methodology and support aids are left to the developmental organization’s discretion. Many organizations implement processes that develop and manage the various DoDAF artifacts as independent deliverables leading to artifacts which are often inconsistent. Removing these inconsistencies occupies much of the time and resources at every stage of development. Failing to recognize inconsistencies leads to actual developmental, integration, and operational problems along with expensive retrofit efforts.
Often, Program Offices and other responsible organizations estimate the cost, schedule, and other resource requirements (for program justification) from the architecture documentation without significant use of systems engineering tools. Managing frameworks (not just the DoD Architecture Framework) and integrating the relevant information into a single integrated package by applying proven systems engineering processes, methodologies, and tools results in early system insight to support program justification and planning. In addition, this results in higher quality systems, manageable and effective processes, and is less expense than other approaches. All of these benefits lead to lower developmental risk.
Network Centric Architectures: Are We Up to the Task?
Stuart Booth; Vitech
The emergence of network centric architectures and the achievement of information superiority is the new paradigm that is being embraced by the military’s next generation of systems to be developed and deployed. The changes dictated in this new architecture are instigating revolutionary changes throughout the DoD. These changes should have an equally profound effect on system integrators in terms of integration practices and policies that will allow network centric architectures to be realized within budgetary and schedule time constraints. The purpose of this paper is to identify key issues currently limiting the effectiveness of system integrators in their efforts to architect network centric architectures and offer suggestions on how to strengthen the integration process through the application of model-based systems engineering, integrated information repositories, and teams that have both a vertical and horizontal architecture definition and integration responsibilities.
Defensible C4ISR Architectures Require the Application of Good Systems Engineering Practice
Steven Dam, Ph.D. and James Willis, Jr., Systems Proposal and Engineering Company
The DoD C4ISR Architecture Framework was developed to facilitate comparison of like and dissimilar information systems architectures. To be compliant architects must produce operational, systems and technical views that contain particular sets of information. Although these could be produced in common word processing and presentation tools, the availability of systems engineering tools and their application as part of good systems engineering practice enhance accuracy and traceability of all information, as well as ease change to that information as new data becomes available or the situation changes. This paper describes how to apply good systems engineering practice, in terms of methodology, tools, process and people, to develop defensible C4ISR Architectures and increase customer satisfaction.
A System Engineer’s Position on the Unified Modeling Language
J. Franklin Skipper, Ph.D., Vitech
As a practicing systems engineer with extensive background in both software systems development and early UML development, I would propose that UML is “another systems engineering view”. However, this view in itself is incomplete and this paper will identify some key issues of why practicing systems engineers will continue using behavior diagrams as a powerful ally in designing and specifying systems.