Getting to Grips with Complexity
D K Hitchins
We often talk about complexity as though it were well understood. Ask people what makes something complex, however, and you could get many different answers. So, what is complexity? Is it a commodity? Can you add some, take some away? From what is it constituted? How can it be measured? How does it arise? How does complexity relate to order? Can order arise spontaneously from complexity—or not? Is complexity "good", "bad", or immaterial? How does complexity relate to stability and chaos? This paper seeks answers to these questions.
Developments in Systems Engineering Standards at the DERA
Peter Brook, DRA
The Defence Evaluation and Research Agency (DERA) is committed to improving the competence of its staff in the field of systems engineering. Following the successful reception of a prototype document, a project has been initiated to develop more fully systems engineering standards to aid in the conduct of the business. After the first six months of work, there is a clear appreciation of the target audience for systems engineering standards, and a reference model is emerging which describes the relationships between the systems acquisition, systems engineering and component development processes. These and other observations arising from the work so far are described.
The Holistic Approach — Benefits of Visualisation in Systems Engineering
C N Smith, British Aerospace Dynamics Limited
The systems engineering process is continually developing in response to business and customer drivers and also to take advantage of new technological opportunities. Synthetic Environments (SE) allow systems to be demonstrated and visualised very early in the life cycle, creating exciting new possibilities for risk reduction and communication. The integration of SE capabilities into the systems engineering process will be called the Holistic Approach. This paper provides a cost/ benefit comparison of the Holistic Approach to the traditional and modern development approaches.
The Holistic Approach is shown to reduce life cycle costs through analysis which contrasts the three different approaches across key activities in the development life cycle, determining the cost drivers for each approach. Significant risk reduction is possible through visualisation and early experimentation in the Holistic Approach The use of an SE capability is not a universal panacea but must be applied to appropriate activities and tasks, complementing and aiding more conventional methods. Its place in a hierarchy of tools and methods can therefore be identified, with consequential impacts on the development of other tools and methods in an integrated environment. New possibilities afforded by the Holistic Approach are discussed, based on the visualisation capability provided by SE.
A Manifesto for Systems Engineering
S Mallon, INCOSE UK Chapter Systems Engineering Practices and Development Committee
In seeking to establish programmes of work within the UK Chapter it has become clear that without an understanding of the Principles of Systems Engineering, any such work would be built on shaky foundations. A Principles Interest Group was therefore set up to address this need.
The group is still in the early stages of its work, but has developed an initial view of what is important and essential about Systems Engineering. The approach taken has been to identify fundamental issues which can form either the basis for a test of existing or proposed processes, techniques or tools, or a point of reference for the development of new capabilities to fill perceived gaps.
This paper is presented as a 1st public draft, to allow for comment from a wider group, and in the hope that UK INCOSE members will want actively to influence and contribute to future work in this area.
P Moore, BSC Consulting Engineers
Complexity and its Management in Requirements Engineering
A Vickers, University of York
Requirements Engineering is one of the most crucial facets of any successful project. Errors introduced at the requirements phase of the life-cycle become increasingly expensive to repair as development proceeds because of the increasing amounts of rework that must be undertaken [1]. It is therefore vital to correctly elicit requirements and to subsequently validate them with the customer. Requirement specifications should be consistent, complete, and correct [2]. The problem of performing such an activity is hard enough in the development of stand alone software systems, it is countless times harder in the domain of Systems Engineering where the Requirements Engineer must work amongst different disciplines with different concepts, methods, and techniques. The process of negotiation and agreement is that much harder, and that much more important to get right.
Requirements Engineering is a topic that is rightly recognised as crucial by both the industrial and academic communities; however it is the contention of the authors that the two are not in complete agreement as to the problems that must be solved. The theme of this Symposium is ‘Getting to Grips with Complexity’, and nowhere is this maxim more applicable than in Requirements Engineering. In this paper we argue that whilst both communities agree that complexity is important, each is concerned with different aspects. This paper outlines the differences we perceive between the two communities and identifies the need for a more integrated, and ultimately more successful, solution to the problems of Requirements Engineering. It is in the facilitation of such interaction that organisations such as INCOSE can provide a crucial role. We do not compare and contrast any techniques in detail in this paper because we believe the central issue, and main contribution of this paper, is the identification of the nature of the complexity, rather than techniques to deal with specific aspects.
As a starting point to our discussion Section 2 summarises what we believe to be the principal characteristics of industrial Requirements Engineering. Using this as a foundation, Section 3 lists some of the major problems that such practices suffer. Section 4, in comparison, highlights the recent direction of academic Requirements Engineering and provides the basis for Section 5’s discussion of the disparity. Section 6 concludes the paper.
Beyond the Scientific Approach — The Ecology of Ideas
R Sharp, Roke Manor Research Ltd
Science and Engineering are often viewed as being similar or closely related. This paper takes a critical look at the methodology of science and its applicability to engineering. It concludes that beyond helping to bound possible solutions by eliminating the impossible, science cannot help in trying to identify what are good solutions. It is proposed instead that once scientific knowledge is applied it has no more status that any other ideas. There may be no methodology applicable to ideas but there is certainly a process of selection in operation, and this process has many similarities to the process of natural selection. In natural selection the driving force for success is not the process of creation itself, which is simply random, but rather the process of selection. If this concept is applied to engineering then it suggests that we have overemphasised the process of design and neglected the process of selection. The paper concludes by establishing a model for the ecology of ideas that shows the contributors and barriers to success. This model is applied to the processes of engineering to demonstrate how it might be used to improve our technical capability. The implications of this concept are far reaching and potentially very significant but there is a lot to do if it is to survive.
Giving "top-down" and "bottom-up" their rightful place
J Boardman, de Montfort University
The subject of this paper is the Company Intranet, and its main focus is on the need for this relatively recent innovation to be system engineered. The paper’s thesis is that the Company Intranet is capable of enabling radical cultural change and of delivering extra-ordinary productivity improvement, provided that it is systems engineered. If it is not to be system engineered, then it very likely will be vendor-driven. Those companies who adopt this approach, rather than one based on a thorough and thoughtful requirements-driven design (of what could become an essential item of corporate infrastructure), must be prepared to live with the consequences of that decision.
Task Analysis in Systems Engineering
Michael Goom, British Aerospace Dynamics Ltd
It is now recognised that the user is part of almost all systems, and that integrating the human component effectively can be crucial to total system performance and through life costs. The development of the Human Factors Integration programme within the UK has highlighted the key role played by task analysis data in this integration process. In 1995 a joint Ministry of Defence and Industry working group organised a two day workshop to examine if, and how, task analysis could bridge some of the gulfs between projects, project phases and between the different disciplines in order to truly integrate the users into the systems development process. The conclusions were extremely positive, showing a remarkable degree of agreement across the many professions represented, and providing a number of recommendations as to the steps needed to capitalise on this approach.
Last Updated: 01 August, 2002