Next Module Delivery
7-11 October 2013
|Example 5-Day intensive module|
Properties of systems
How to classify systems
Exploring systems perspectives
Introduction to systems engineering
Systems engineering lifecycle
Integrated design teams; Principles of systems engineering
Planning a systems engineering project
The Systems Engineering Management Plan (SEMP)
Controlling a systems engineering project
Managing design integrity
Case study: London 2012 Olympics
The challenge of systems engineering management
Soft Systems Methodology
Centre for Systems Engineering
3 Taviton St.,
London, WC1H 0BT, UK
T. 020 7679 4908,
F. 020 7679 4911
Systems Engineering Management
Systems Engineering and Project Management
In this course we present an overview of all of the systems engineering processes. Whereas the management of all project aspects according to time, cost and quality constraints will be under the control of a project manager, the responsibility for integrating the technology features of the product will be devolved to the Systems Engineer.
It should be remembered that businesses are themselves systems. These are often organised in a hierarchical manner, and require to be managed carefully in order to deliver the right products to the customer. Most frequently this will be done by considering the work as a project. A project is an assemblage of people and equipment, normally managed by a Project Manager (PM), working toward satisfying the set of goals set forth by a customer. The success of the system is dependent on the skills of the people on a project and how well they are able to work together. It is often the PM that will have the responsibility of driving this complex situation forward, but the role of the Systems Engineer in handling the technological aspect of the work is also vital.
A systems engineer will consider the holistic nature of the problem and of the system being developed. Although the product may rely on specialist technology or skills, these will not drive the solution in isolation.
A system of complex parts organised in a complex way will often exhibit emergent properties,
and these may well be the prime focus of the system engineering
efforts. An emergent property is something interesting about the system
as a whole that is not a characteristic of any of its parts. Very often
the collective properties of a system are driven by the way in which the
sub-systems interact, i.e. the architectural design, rather than by
their individual performance characteristics. Systems engineering is very concerned with
emergent properties, in promoting useful ones and suppressing harmful
ones. With a focus on emergent properties, it is possible to optimize a
whole system, rather than just individual parts (called “system
elements” in general). Formal methods for evaluating such tradeoffs
exist. Design budgets, monitoring and testing are focussed strongly
toward whole-system and emergent properties rather than those of
individual system elements. There are also techniques for evaluating
complex product quality, and various types of risk.
Process to guide problem solving
A rational process to guide an organisation (or team of organisations) through a long series of decisions is needed. There is no single process that will satisfy all contexts, but successful systems engineering processes have several themes in common. One aim of the systems engineering approach is to promote earlier action and decision-making, thereby increasing the effectiveness of the system. This is done specifically in relation to the activities on the left side of the V model – introduced below – and is often referred to as left-shift.
When the design focus is drawn to activities further downstream in the lifecycle, such as manufacturing, test or maintenance, so that we may have design-for-test as an additional factor in the design process, then this is termed concurrency.
This approach, which can be contrasted with an “over-the-wall”, i.e. serial, paradigm, will require more than merely high-level attention to the whole problem. It will require suitable technical tools (such as modelling and cross-disciplinary performance budgeting) as well as involvement and commitment across the engineering disciplines involved.
It remains important to keep the contexts of both the business and the end-users in mind. Because of the hierarchical nature of most systems and contractual practices in many engineering industries, it can be difficult to do so effectively. A function of systems engineering is to provide a continuous focus on relevant stakeholder needs when evaluating any design or change in the project. Systems engineering can be considered a functional part of a business enterprise. Taking this systems view of a business translates the ‘Heads up’ concept into a form of supersystem optimisation. Other than the immediate system development, the systems engineer will also be concerned with such matters as the maintenance and evolution of an ongoing technical capability to ensure downstream competitiveness. Systems need to be useful. To avoid obsolescence, the changing needs of the user must be kept under review, but without leading to a chaotic and expensive loss of focus.
Page last modified on 01 may 13 14:06 by Ian Raper