|
|
|
|
|
|
|
|
|
|
Keynote Speach: Systems Engineering in Retrospect and in Prospect , Peter Robson
Avoiding a nostalgic trip down the memory lane of too many past projects, in retrospect looks at the way that the conduct of systems engineering seems to have been inextricably linked with procurement practices, leadings to highs and lows as the pendulum (and sometimes the axe!) swung to and fro. The challenges of finding a better way led to various initiatives, notably the DTIs Foresight Systems Engineering Working Party. This has been the UKs most serious national attempt to date to get to grips with generic systems engineering and to try to plot the future for a capability seen as crucial to the UKs success. In parallel, the MODs initiative on Smart Procurement has brought systems engineering on board in a way which, at times, seems more akin to treating it as a silver bullet rather than a crucial all-pervasive discipline.
The establishment of the UK Chapter of INCOSE has helped to build a bridge to the USA; in particular, work on standards and capability maturity models has been widely adopted. The consequential dangers of turning systems engineering into systematic (tick-in-the-box) engineering need to be appreciated.
Nationally, far too many projects seem to fail; these are frequently to develop so-called unprecedented systems. Indeed, being unprecedented is sometimes used to excuse the failure. A wider awareness of generic systems engineering might make it more obvious that such unprecedented systems are actually the products of precedented project systems. Because they are (or should be) precedented, project systems should be subjected to systems engineering in a way that ensures consistency and performance from project to project. This is the bridge yet to be completed between systems engineering and project management or between customer and supplier.
A further bridge is that between systems engineering and software engineering. Software engineering impacts on most of todays projects; sometimes, this is beneficial and, sometimes, not. The paper will explore some of these pros and cons
In prospect looks to the near-term future of the topics that emerge from the above material in an attempt to identify an agenda for systems engineering. At this stage, one might expect to see the topics such as: Smart Procurement - will it deliver?; Systems of systems; Capability models; Standards; Competencies; Metrics; Process-based SE; Information-based SE; Humans as part of the system; SE applications; Education; Training.
1 . Bridging the Communications Gap between Systems and Software Engineers , Joe Kasser, University of South Australia
Kasser and Shoshany (2000) identified major differences between systems and software engineers as a cause of project failure (cancellation or massive cost and schedule overruns).
This paper introduces a methodology for use by integrated process teams (IPT) to bridge the communications gap between systems and software engineering.
The meta-model for problem solving (Kasser and Shoshany 2000) shows that engineers use pattern matching techniques. However, systems and software engineers use different patterns. This paper shows that the sharing of patterns may bridge the communications gap. For it is by sharing of mental patterns that the engineers can understand and communicate the impact of a concept on their discipline. The paper also provides some examples of how patterns may be shared in an integrated design team environment
2 . Systems Engineering The Ubiquitous Unicorn? , Dr John Davies, BAE SYSTEMS
INCOSE is dominated by Aerospace/Defence where complete processes have been developed and are used for the specification, design and development of big systems.
Other areas of engineering, such as Commercial Telecomms, IT and Software, work to market pressures, have much shorter development cycles but appear to ignore many aspects of Systems Engineering. The systems they produce are often as big and complex as in Aerospace/Defence, and they appear to be Faster/Cheaper/Better.
The average age in the IT, Software, Telecomms industry is around 30, the average age in INCOSE appears to be around 50. Systems Engineering has been regarded as an area for experienced engineers only. It has not, in general, been promoted in schools or taught alongside other engineering disciplines in Universities.
Is the writing on the wall for Systems Engineering? Will it take early retirement along with its practitioners? Can the systems industry be successful without Systems Engineering? Or is Systems Engineering actually alive and well, being applied everywhere but we do not recognise it?
The paper will explore what needs to happen to move Systems Engineering into the 21st Century.
Have we developed an implementation of Systems Engineering that is not appropriate to commercial business? Can we regain sight of Systems Engineering concepts, principles and methods, and learn to apply them in a flexible way? What needs to happen in education for Systems Engineering? What can Systems Engineering really offer in all areas and how can it be applied effectively?
3 . Applying an Iterative Lifecycle Model to ISO Processes , Keith Ellsmore and Jon Holt, Brass Bullet
One of the basic requirements for managing any systems project is to define a lifecycle model that describes the way that the project will be executed over a number of phases. One of the more recent developments in the software world is that of the iterative lifecycle model, that splits down a project into four definite phases, each of which contains a number of discrete iterations, each of which is treated like a mini-project. The more traditional lifecycle models, such as the waterfall model, spiral model and incremental model are then applied to each mini-project.
This approach has been applied using a set of ISO-defined processes, all of which has been modelled using the UML. The project itself, known as Cyberdogs (concerned with producing electronic guide dogs), is a three-year project involving an ever-changing number of engineers, consultants and researchers which means that the approach taken to managing the project must be as flexible as possible whilst, at the same time, adhering to the company-defined ISO processes that exist in the organisations project library. This paper will present the experiences of implementing this new approach to an existing infrastructure and discuss its pros and cons whilst being implemented on a systems engineering project.
4 . What the Systems Engineering Courses dont tell you - a practical framework for lifecycle of requirements-driven process , George Wallace Lockheed Martin Air Traffic Management
While there are many standards that define Systems Engineering, this paper provides a practical framework for managing the early life cycle of a requirements driven process, identifying scenarios that are often omitted from Systems Engineering Courses.
The paper refrains from prescribing specific tools. Instead attention is centred on the key practices that are necessary to underpin requirements management. It is proposed with appropriate tailoring, the key practices can help project managers define a requirements process suited to their own project.
5 . Practical Experience of using UML for Functional Specification , Rosamund Rawlings Praxis Critical Systems
Distributed systems often suffer severe problems at the integration stage. This can be prevented by the use of rigorous modelling techniques early in the development lifecycle.
The paper presents a process for the System Specification and System Design stages of development of a distributed system. It shows how the techniques of UML can be used to add rigour to the process. This increased rigour helps ensure consistency of intepretation accross sub-systems. This greatly reduces integration risks, and provides a way of ensuring that requirements changes are correctly mapped onto sub-system requirements changes.
We will show how the techniques of class modelling, operation specification using pre- and post-conditions and sequence diagrams can be used iteratively to reach the desired level of decomposition in a rigorous and traceable manner.
The method has been developed from practical experience of large distributed system development and is integrated with REVEAL, Praxis Critical Systems' requirements method.
6 . Systems Engineering Product Line Management , Hillary Sillitto Thales
The Product Line Approach moves beyond "design by re-use" (evolution of new systems from previous ones) to "design for re-use", which seeks to develop strategic architectures based on product platforms or modular product lines to allow the faster, cheaper and lower risk development of custom products and systems using largely standard components or design elements.
The key issues in systems engineering and marketing product lines are to:
get the customer to buy-in to the benefits of trading his technical requirements against other programme attributes (cost, schedule, risk) so that he can benefit from the product line investment,
architecting the product line so that customisation changes can be localised with minimum knock-on effect into other parts of the system,
establish the engineering processes and mind-set required to achieve and benefit from "design for re-use", and
developing and validating the product line architecture and getting variants to market within the available market window.
We have consolidated ideas from a number of literature sources, added some key ones of our own, and reviewed case studies of successful product line approaches from a number of Thales companies, whose applications range from large one-of-a-kind systems to high volume products with substantial customisation options.
We have developed some key high level presentation material which seeks to clarify and simplify the strategic concepts and issues involved in selecting between the various possible re-use approaches; and identified the process changes in marketing, business development, product portfolio management and systems engineering required to implement and leverage an effective product line approach. A concept of "re-use maturity levels" evolves naturally from the work. There are strong similarities to the Thales "Software Product Line approach" but also key differences.
The work has identified the tailoring of the company standard systems engineering method required to support a product line approach, and it is now intended to map the process tailoring onto the company's recommended Systems Engineering toolset and to identify and implement any necessary tool customisation.
The paper discusses the strategic and cross-functional co-ordination issues, and selected aspects of the case study experiences.
7 . Rebuilding the Tower of Babel The Case for UML Real-time Extensions , Matthew Hause ARTiSAN Software Tools
In the book of Genesis, the peoples of the earth came together to build an enormous tower. To confound them in their task, God changed the languages of the different groups of people so that they were unable to communicate. Since they could not coordinate their efforts, the project was abandoned and the different groups dispersed throughout the world. Projects today have the same basic need for communication. An important role of Systems Engineering is the communication between engineering and its customers, both of whom speak very different languages. Systems Engineering practitioners have recently been experimenting with the use of the Unified Modelling Language (UML) to help bridge this gap. Unfortunately, the UML as a language is deficient in specifying many important aspects of Systems Engineering. These include: Constraints, System Operational Modes, Physical and Logical Architecture and Concurrency. To get around this, Systems Engineers have developed a number of strategies: ad hoc notations, expressing them as written descriptions, or using UML incorrectly to express concepts for which it was not intended. Using ad hoc notations means that COTS case tools cannot be used and that the meanings can be ambiguous. Lack of a diagrammatic notation means that requirements cannot be fully modelled which can cause problems when requirements management tools like DOORS are used. Finally, using standard UML alone can result in ambiguous specifications where most requirements are expressed somewhat unsatisfactorily as classes. What is needed is a methodology that supports Systems Engineering concepts and a tool that allows full expression of the requirements. This paper will show the system requirements for an example petrol supply system using UML with real-time extensions. As a result, the requirements are more clearly and comprehensively covered, and more easily understood even by those who are unfamiliar with UML.
8 . A Systems View of Obsolescence , Ted Dowling DERA
All systems become obsolete at some stage and managing obsoleteness is an important concern for many systems. However, it is a subject that seems to attract surprisingly little attention. For example, it lacks explicit treatment in material such as ISO 15288 and even a common definition of obsolescence for systems seems to be absent. Traditionally, the view of obsolescence has been bottom-up, especially being concerned with electronic components, where 'obsolete' equals 'no longer in production'. Attempts have been made to extend the same approach to software. However, a top down, system- and user-oriented view is much more valuable, and allows us to encompass the softer aspects of systems.
This paper proposes a definition: a system is obsolete when it no longer meets user needs and it is not practical to make it do so. It explores how this covers both "internal" (failure) and "external" (changing needs) aspects. The paper shows that this approach subsumes the electronic component view, while also allowing for other types of system constituent such as other hardware, software and humans. It explores the relationship between different definitions, showing, for example, that a system is not necessarily obsolete just because its hardware is considered to be.
It also introduces the concept of "obsolescence cases": (<does not meet need>, <not practical to make it do so>) pairs that represent the various causes of system obsolescence and that vary for the different types of system constituent. A simple and familiar example of an obsolescence case is (component fails, no spares). An obsolescence management strategy can then be derived to address each obsolescence case and achieve an acceptable level of risk for each. The management applies through the system's life: minimising risk during system specification/ design, tracking the risk during system use, and taking steps to reduce the risk again when necessary. Each of these generic activities has particular instantiations for each type of system constituent. For electronic components the familiar obsolescence management steps emerge as special cases of the general approach, but the implications for softer constituents and systems can also be explored.
9 . The Design and Implementation of a Process Library using the UML , Jon Holt - Brass Bullet Ltd ; Dipesh Patel and Mick McManus - London Underground Ltd, InfraCo JNP
Processes are, arguably, one of the most important aspect of practical systems engineering in todays world. The definition and implementation of such processes, however, arguably, one of the most difficult things to get right in systems engineering!
This is a problem that has been tackled at London Underground, InfraCo JNP, by the creation of a process library. The main requirements for the process library were: to enable the definition of new processes based on best practice and standards; to allow these processes to be tailored; to retain lessons learned and past experiences on the implementation of these processes; to enable a project manager to assemble a lifecycle using these processes as building blocks; to demonstrate compliance with best practice, international standards and in-house procedures and to make use of off-the-shelf systems engineering tools.
The approach taken to meet these requirements was to use the unified modelling language (UML) for analysis, design and management activities and to use the DOORS tool to implement the final system.
This paper presents the results of this work and demonstrates, using real-life experiences, how the process library has been shown to be effective for the InfraCo JNP.
10 . Soft Systems Structures , John Boarder - Cartref Consulting Systems
Soft Systems approaches to Systems Engineering based on General Systems Theory (GST) led to the work of Checkland, Hitchins, Senge and others. The Soft System Methodology (SSM) of Checkland, the Hierarchical Issue Method (HIM) of Hitchins and the Fifth Discipline (System Archetypes) of Senge are among the principle outcomes. All such soft methods develop viewpoints of potential problem situations, influences directing change, before moving on to propose, if appropriate, methods for their resolution. While the approaches are structured, there are procedures to be followed by practitioners and semiformal architectures in terms of which problem situations are discussed, the various procedures and architectures are based on different definitions of fundamental concepts such as boundary, structure, environment, process and others.
Our paper outlines, in brief, the principle structural features of the GST, SSM, HIM, and System Archetypes to expose underlying system definitions. This raises the question, is there a common structure, one that rationalises, simplifies and a formalises soft methods? Is there a structure that could help bridge the gap between soft and hard approaches and so facilitate wider acceptance of soft methods and their application in Systems Engineering.
Our paper goes on to answer these questions positively using an example, fictional, class study from Airport-Security. Practice suggests there may well be such a common structure and a common approach to be supported by it. It is a novel structure; one that parallels the hard structures of business enterprise, i.e., both commercial and engineering enterprise. It may well rationalise, simplify and formalise soft system approaches to enterprise development. The approach allows stakeholder views of enterprise interactions to be captured, and valued systems of influences derived from them to be classified, modelled and interpreted in terms of a formally defined enterprise architecture.
The formality on which the paper is based is relegated to a brief appendix. Our paper and presentation are illustrated using a visual enterprise development model and a technique for unfolding an enterprise along supply chains that form structural dimensions. Without loss of generality, the technique unfolds the architecture over dimensioned and nested layers. The unfolding terminates in literature-based classifications of resources and their properties, processes and their characteristics and valued influences. The classifications are associated with real-world resources, properties, processes and characteristics using concordances so that the model architecture is rooted in the real world. Interestingly, current research suggests that our underlying definitions for soft system structures may be the same as that for traditional hard system structures.
11 . Formalizing the Application of Systems Engineering beyond the Traditional Hard Systems Boundaries , Margaret Myers: Director, Systems Engineering and Management Programme, Richmond University ; Agnes Kaposi Partner, Kaposi Associates
The paper present an integrating framework of concepts, together with a taxonomy and a toolkit of methods for Systems Engineering professionals. It goes on to report on the use of this methodology in practice in a wide rage of fields in the UK and abroad.
The toolkit includes a graphical language for Product/process (P/p) modelling which offers an interface between systems professionals, their clients, members of other professions, and members of the interested public. P/p modelling extends the scope of Systems Engineering from a conceptual discourse to an engineering methodology. Based on measurement, it supports an advanced approach to quality and safety, is suited to hard or soft systems alike, and can be used to describe the problem, the solution, and the processes involved in obtaining and utilizing the solution.
Experience shows that P/p modelling, together with its underlying concepts and methods, is teachable to undergraduates, postgraduates and practising professionals working in technical or managerial posts, and its value has been extensively demonstrated in a wide field of industry, business and public administration.
12 . BASE A Framework for Requirements Engineering Based on Systems Thinking , Professor D W Bustard, Head of Information & Software Engineering School, Faculty of Informatics Ulster University
Arguably, requirements engineering is the most challenging aspect of software engineering. Factors contributing to the challenge include (i) requirements are often not fully understood before a software system is built; (ii) requirements will change during and after system construction; and (iii) system requirements (beyond software specification) are difficult to understand and manage.
Handling such factors effectively, means approaching requirements engineering an integral part of the complete software engineering process and being aware of the impact that software has on the environment in which it is used.
This paper describes ongoing work to develop a framework for requirements engineering based on this ?systems thinking? view of the world. The paper presents details of the framework, BASE, together with a rationale for its approach and an example of its use. The main characteristics of BASE are that it encourages (i) the establishment of a long-term ?vision? for a software system; (ii) the development of an incremental plan for change; (iii) the modelling of the business process in which the software is used (information system), linked to the business activities that the software supports (business); and (iv) the alignment of organisational change to software change.
The business aspects of BASE build directly on Soft Systems Methodology (SSM). BASE is illustrated here through its use in developing a generic set of requirements to enable 30 Environmental Health Departments in Northern Ireland to develop computing systems independently.
13 . Building a Systemic Understanding of Whole Systems , David Cooper: Director, Probis
Systems Engineers have a well-developed and broadly agreed common language for discussing technical issues. This is drawn from a range of scientific and engineering disciplines, together with a rich variety of life-cycle , process and best-practice models and standards relating to specific professional or industry domains. Despite differences in approach, all these models share a rational, analytical and task or process view of systems.
However, the vocabulary for discussing management and people issues the difficult and challenging emotional work of the project- forms only a small part of this language. It relies on a limited and unrelated set of concepts derived from a hybrid mixture of management theory, organisational psychology, project management folk-wisdom and common-sense. This approach is exemplified in the numerous accounts of project failure attributed to politics, indecisive management, poor communications or simply bad project management.
In this paper, I suggest a broader framework for discussing people-related issues, drawing on social constructionist ideas currently widely used in systemic therapy and organisational change management. This framework provides a powerful and systemic way of understanding how projects are created, sustained and threatened through behaviour, beliefs and conversations.
I illustrate the application of the idea of the essential conversation to a variety of projects, both successes and failures, and look at the wider implications of these approaches for the professional body of knowledge.
14 . Hierarchical Task Analysis Bridging Organisational Goals and System Requirements , Bob Briggs
This paper describes the application of Hierarchical Task Analysis (HTA) as part of the requirements engineering process within a system development activity.
The paper opens with an overview of task analysis techniques and HTA in particular. It describes how HTA has been used effectively to understand how humans go about performing tasks to meet their organisational objectives. The paper then proposes an explicit role for HTA within the systems engineering process, showing how it can be used to elicit user and system requirements and assist in identification of Use Cases and Scenarios.
In addition, HTA models are shown as an effective means of:
communication between users and developers
documentation of the operational context of the required system and providing traceability to stated organisational objectives
optimising operator interaction with required system
designing new tasks to meet new operational and organisational objectives
enhancing impact analysis and system integrity in the face of changes to business needs
planning operational acceptance testing
assessing implementation priorities based on business benefit
providing procedural direction and training for operational personnel
Finally the issue of tool support is discussed with examples of how two specific tools, DOORS and RDD-100 can be adapted to support the proposed approach.
The paper concludes with a discussion of the likely benefits and cost drivers of implementing the approach.
15 . Requirements or Design Chicken or Egg , Mike Baker - Corata
Which came first, a requirement specification or a design?
Engineering methods, especially as proposed for software (intensive) systems, suggest that an engineering task begins with a set of defined requirements (or perhaps for system engineers, with the task of specifying those requirements), and that the design and development activities follow when the requirements have been agreed. In the beginning was the requirement...
When a system design is proposed to meet those requirements we expect to see a definition of some arrangement of parts that, when they operate together, will exhibit the desired behaviour. We also expect to see specifications for the parts and, perhaps most important of all, some reasoned argument that justifies the design. However, it seems to be common experience that we seek no such justification for the highest level specification, the original set of requirements. Despite the fact that a reasonably comprehensive requirement specification for any non-trivial system is likely to be a substantial document, we generally accept it more or less without question.
It might be helpful to think of the requirement definition stage as a design activity in its own right, with the detailed requirement specification being a product of that design, and more importantly with its own justification that a conforming system will indeed achieve its goals. Thus the requirement specification is actually the result of a design activity. This is entirely consistent with the later stages of design, which produce specifications for subsystems that are designed in their turn, and it helps to clarify the responsibilities of the requirements engineer.
Of course, this begs the question of what are the objectives of this design; surely they are just a higher level set of requirements? Well, perhaps. At some level it may be necessary to ignore the chicken and egg question and just accept that both a requirement specification and a justification are necessary. However, we should not ignore the obligation to justify a set of requirements, any more than we would ignore the requirements just because we think we have a nice design. Surely the obligation to justify a specification is no less important just because it occurred before we started to define things in terms of hardware and software. This should occur naturally if we think of requirement specification as a design process.
16 . Towards a Systems Engineering Methodology for Requirements Engineering Process Modelling , Ddembe Williams: Senior Lecturer in Systems Development and Decision Support Systems, School of Computing, information Systems and Mathematics, South Bank University
This paper proposes a descriptive model-based systems engineering methodology for requirements engineering process assessment and improvement. The success of requirements engineering projects for complex systems depends critically on the effectiveness of the requirements engineering process modelling and analysis. Poorly defined requirements process cause projects to fall behind schedule, go over budget and result in poor quality of system specification. The transformation of systems concerns into "what" the system needs in order to achieve its operational goals are stated in a requirements document, a product of the RE process. Many systems (software) development organisations are investing time and money in increasing the effectiveness of the RE process by incorporating improvements aimed at better understanding, improved communication and effective modelling and analysis. The activities within these process categories may be interactive, parallel, non-linear in nature, may contain feedback and time delays, which are inherent in a functioning Software Development Organisations. This paper derives 38 activities as key processes synthesised from different software engineering process models including CMM, SPICE, Bootstrap and ISO 9000. The paper argues that improving the RE process modelling and analysis improves the quality of the specification produced.
In developing such a model, the paper fills an important gap in the RE process modelling and analysis literature and has potential to provide requirement engineers, managers and software development organisations with a model-based process framework to aid quality assessment and improvement.
Contribution to the requirements engineering debate and to enhanced understanding of problems in requirements engineering is found in the definition of a dynamic synthesis (DSM), a RE process modelling and analysis methodology. DSM is characterised by a sound theoretical base and underpinned by synthesis as a philosophy of science. To exploit the DSM, descriptive theories, DYNAmic syntheSIS (DYNASIS) is developed. The generic model enables researchers and RE engineers to gain descriptive insights and perform process modelling and analysis assessments. DYNASIS may be used as a novel environment for modelling and analysing RE process in a learning and training situations for RE process stakeholders.
The paper concludes by suggesting that the framework makes a useful contribution both in providing the foundations for theory building in RE process assessment, modelling and quality improvement by aiding shared understanding through learning and training situations.
17 . Writing Requirements for Flexible Systems, Joe Kasser University of South Australia
This paper examines some attributes that make software and hardware systems flexible enough to be used for several purposes. Based on these attributes, the paper then develops some issues that need to be addressed in writing requirements for flexible systems. The paper concludes with lessons learned from failure or poor performance by systems that were designed to be flexible.
SS2001 Home | Tutorials | Tuesday | Wednesday | Exhibits | Accommodation | Contacts
Last Updated: 29 May, 2003
