Abstracts 1997 Frame

<body stylesrc="abs97.htm" background="images/wmark.jpg" bgcolor="#FFFFFF">  <h1>1997 Symposium Abstracts</h1> <h3><a name="Plastow"></a>How do you model a system?</h3> <h5>Dr Ian Plastow</h5> <p>In answering the question <i>How do you model a system?</i> this paper considers the requirements for modelling of a system in the context of the systems development lifecycle. It examines the issues that have to be resolved for a systems model particularly those related to integration (both horizontal and vertical). A means of satisfying the wide ranging requirements of a systems model is proposed. Neither the proposed requirements nor the means of satisfying them are intended as definitive but are anticipated and intended to stimulate further discussion.</p> <hr> <h3><a name="Evans"></a>Engineering Computer-Based Systems Using MOOSE</h3> <h5>Gareth Evans and Peter Green</h5> <p>Model-based Object Oriented Systems Engineering (MOOSE) is a full lifecycle approach to the engineering of computer systems, particularly those that require the concurrent development of software and hardware. </p> <p>This paper considers some of the motivations for the development of the MOOSE approach; the way that the MOOSE approach is used to support the development of a computer-based system; the role of models in the approach; and the features of the approachs supporting tools.</p> <hr> <h3><a name="Caple"></a>The Generic Unified Systems Engineering Model</h3> <h5>George Caple</h5> <p>The model described in this paper originated in mid 1993 when the author decided that it was not possible to explain systems engineering using current & previous two dimensional models. The <b>model</b> has therefore been <b>designed</b> from the outset to be <b>three dimensional</b>. It has been designed to be immensely decomposable & expandable in regard of processes & products, & within what could be described as a hard framework, to enable the use of Soft Systems Methodology to explore & define the many in-built processes. As it also includes programme/PERT, the model is described as <b>"unified"</b> in addition to being a<b> generic metamodel.</b></p> <hr> <h3><a name="Widmann"></a>Observations on the Measurement of Systems Engineering Capability</h3> <h5>E. R. Widmann, E. J. Dragavon, J. J. Schuster, G. Richman, D. W. Bradley </h5> <p>In the past few years, several models have been developed to measure systems engineering process maturity. Two of these models have gained a great deal of attention: the INCOSE SECAM and the EPIC (formerly Industrial Collaboration) SE-CMM. This paper describes the conduct of a dual systems engineering process assessment that applied both of these well known models to the same organization using the EPIC SE-CMM Appraisal Method, rather than the shorter duration INCOSE SECAM Assessment Method. The assessment was conducted at Hughes Aircraft Company (HAC), Electro-Optical Systems (EOS). The assessment is noteworthy since it is the first time both models have been applied concurrently. This paper provides a synopsis of both models along with a description of the dual assessment. Issues observed from the assessment regarding the models and the Appraisal Method are described; their resolution is important for the conduct of future assessments. Impacts upon the two models and application methods are discussed based upon the experiences gained from the dual assessment.</p> <hr> <h3><a name="Collins"></a>A Tutorial on the Essential Logic Model: Documenting Design Rationale</h3> <h5>R.J.Collins</h5> <p>This paper presents a tutorial on a diagramming convention for capturing design rationale. The convention is called the Essential Logic Models (ELM). An ELM is used to document the rationale for an emerging design during the Software Engineering process. An ELM tells the story of the system and the decisions that were made during its construction. The ELM shows the relationship between broad classes of requirements and how these relate to the explanatory concepts developed and used during system development. The diagram also shows the important processes that exist within the system and the objects that the new system will interface to and on which it is dependent.</p> <hr> <h3><a name="Potter"></a>Taking ILS & LSA into Account in SE</h3> <h5>Mike J. Potter,</h5> <p>The presentation covers: what ILS is, why, how and when it is used; it provides an overview of the LSA process, the main analytic tool used in a ILS programme, one which is used in Systems Engineering (SE); it also includes the relationship between LSA and LCC and other modelling activities; briefly discusses LSA Records (LSAR), some organisational aspects and lists the principal standards and software sources for the implementation of LSA and LSAR.</p> <hr> <h3><a name="Farncombe"></a>Tayloring (sic) System Engineering Processes to Project Management Circumstances</h3> <h5>Andrew Farncombe</h5> <p><font size="3">Within this overall purpose, the paper contains three threads:</font> <ul> <li> </li> <li><font size="3">a general plug for systems engineering. At a gathering such as this I hope this will turn out to be preaching to the converted</font></li> <li> </li> <li><font size="3">an opportunity to explore the overlap of concerns between systems engineering and project management</font></li> <li> </li> <li><font size="3">for the most part, discussion of some work GEC-Marconi has been doing over the past couple of years to construct a generic framework for systems engineering across a broad-based company. This is coupled to instantiating tactics for individual project circumstances.</font></li> </ul> <p><font size="3">Obviously, we cannot cover all aspects in a paper of this length, and some important aspects have had to be left out. Nevertheless, I hope to cover the main topics.</font></p> <hr> <h3><a name="Widmann1"></a>A Preliminary Description of the EIA Systems Engineering Capability Model</h3> <h5>E. R. Widmann</h5> <p>Two systems engineering capability models have gained a great deal of attention: the INCOSE SECAM and the EPIC SE-CMM. This paper provides a preliminary description of the results to date of merging the two models and application methods into a single model and assessment method under the auspices of the Electronic Industries Association (EIA). The EIA Working Group, which is responsible for accomplishing the merger, has representation from the EIA, INCOSE, and EPIC. The INCOSE representation is provided by the INCOSE Measurement Technical Committee. As such, the "merged" products may be regarded as part of the set of measurement products that the INCOSE Measurement Technical Committee is developing, both internally within INCOSE and jointly with external organizations, to measure and improve systems engineering activities. The paper provides a synopsis of the current versions of both models in order to assist in understanding the merging effort and provide a background to the resulting merged model, designated the EIA Systems Engineering Capability Model (SECM).</p> <hr> <h3><a name="Korn"></a>Problem of Identity of Systems Engineering</h3> <h5>J Korn</h5> <p>Current state of system science and systems engineering as branches of learning is discussed. The meaning of terms: engineering, system and identity is debated leading to a generic interpretation of engineering and a clarification of what is meant by system. The constituents of a situation are described from which the activities of systems engineers as "designers of situations" emerge. Appropriate empirical and theoretical knowledge rooted in currently available knowledge and required by systems engineers, is outlined. This should lead to integration of diverse domains through the common theme of "interacting objects" operating in a purposive scheme to produce specific changes in properties of objects. Activity within a domain of interest and the appropriate knowledge can identify systems engineering as a learned discipline, a part of systems science. In addition, the notions of "product" and "situation" engineer are introduced.</p> <hr> <h3><a name="Tollow"></a>Systems Engineering in Commercial IT</h3> <h5>David Tollow</h5> <p>Commercial IT systems are generally developed from the perspective of a software development activity, or as the straightforward integration of pre-existing off-the-shelf components. In reality the rapid pace of technological change and the resulting and often unexpected interactions between components means that systems may not operate as required or as desired. A more rigorous approach based on systems engineering techniques is needed.</p> <p>This paper aims to investigate the issues surrounding the introduction of systems engineering disciplines into IT implementation projects. It suggests mechanisms by which the principles of systems engineering can be adopted incrementally within an existing organisation.</p> <hr> <h3><a name="McInally"></a>Product Life Cycle Based Requirement Capture in Complex Instrument Design</h3> <h5>Steve McInally </h5> <p>This paper describes a framework and underlying concepts for the capture of complex instrument design requirements based on the needs of the instrument life cycle. However, it is believed that the framework and concepts proposed could be applied to a wider range of complex systems. The paper indicates the background to the research which resulted in the development of the framework, a model of the problem and a methodology for the solution. Further work is in hand to generate tools and procedures to support the solution methodology. The work described is sponsored by the SIRA-UCL Postgraduate Training Partnership and forms part of PhD research in the Defence Engineering Group at University College London.</p> <hr> <h3><a name="Sharpe"></a>Value Engineering -<br> A Practical Way to Change Systems Engineering?</h3> <h5>Robert James Sharp </h5> <p>The concept of value has been developed for strategic and marketing thinking. This paper shows how this concept can be used to understand the relationship between work done and value delivered to the customer and how this can be applied to the practice of Systems Engineering. It uses a simple model of Value Space to explore the "lean frontier" for any market, and the ways in which this frontier can be reached and moved. Finally it presents the model of value as providing an important insight into the process of selection, and therefore a useful perspective for systems engineers wishing to better understand how they can satisfy their customers and develop sustainable market positions.</p>  </body>