2004 UK Spring Conference
|
|
|
|
|
Tuesday 27th April 2004 |
|
2004 UK Spring Conference
|
|
|
|
|
Tuesday 27th April 2004 |
|
How do we measure technical progress on projects delivering bespoke systems? Do we spend too much time and effort providing programmatic information rather than focus on technical progress? How do we ensure that measurement of technical progress is meaningful? Is there common ground or are they best kept separate? Another antagonising Systems Engineering vs Project Management issue! This presentation argues that simplistic measures can be at best misleading, or at worse counter-productive when resources are directed to meet metrics rather than achieving real progress.
Why do Projects run to Systems Engineering when it's too late? What happens on a major project when we don't apply Systems Engineering from the beginning? what are the lessons learnt for not applying concept modelling and thorough requirements analysis? Using case studies from the rail sector this presentation highlights the key lessons learnt and suggests ways to increase awareness of the advantages of implementing Systems Engineering at the early stages of every project.
A stimulating insight into the pioneering attempt by an organisation to address the critical area of training and education within the systems engineering community. The presentation describes the approach taken to introduce the engineering graduates to S.E. in an organisation. The course content is also discussed including, the SE Process; the relationship between requirements, design and acceptance; writing "good" requirements; discussion of the boundary of a system; and an introduction to some useful tools, methods or approaches used.
An excellent opportunity to see an interesting example of the application of the latest SE Standard. This will prove to be a lively presentation taking a realistic and novel look at the application and implications of ISO 15288 on the UK education system. The standard itself is compared to the current UK education system from Key Stages 1 through 4 (primary & secondary schools), to further and higher education (colleges, NVQs, universities, degrees, Masters). The findings may prove controversial and possibly challenge current thinking on systems engineering!
C4ISR or the Department of Defence Architectural Framework (DoDAF as it is now known) is the framework used to define the contents of operational requirements documentation for the US Department of Defence (DOD). The resulting document is then used to define specifications and ensure operational and communication compatibility for the various nodes, systems and subsystems used to achieve a particular operational requirement.
To provide compliance to the DoDAF standard certain views are essential, however the notation of these views and the process used to generate them is not defined. This can lead to very informal representations, ambiguities, contradictions and inconsistencies in the documentation.
This paper presents a formal notation for mapping the essential views for compliance with the DoDAF standard, to a 'systems of systems model', contained within Statemate Magnum©, the system engineering tool from I-Logix. Although the framework is US based the methods and notations described, can be applied to UK programs which are looking to a more integrated 'systems of systems' approach to system specification. The results will show how the tools and methods proposed, overcome the problems outlined above.
Building on the success of the Systems Dynamics and 'Hard vs Soft' systems sessions at the Autumn Assembly, the presentation explores the range of methods and techniques beyond System Dynamics and Soft Systems Methodology to include other soft approaches. Evaluation of alternative design options (requirement and design trade-offs) will also be discussed. Case studies will be drawn from a variety of industries including several from the defence sector.
This presentation will discuss the background of SysML, the modifications to UML that are being proposed, and new diagrams such as requirements and parametric diagrams. One of the strengths of UML is its built-in mechanisms for specializing the generic forms of its modelling elements to more application-specific variants. Collectively, these provide a capability for UML "Profiles" that package specific terminology and substructures for a particular application domain.
One of the great challenges in complex system development is the control of design properties throughout the lifecycle. There is a failure to provide proper traceability of design properties throughout the product breakdown structure. Typically, certifying that a model is appropriate for a specific purpose is an informal, ad hoc procedure. The presentation explains the benefits of formally capturing this procedure and present the need for the development of a decision support capability to advance the effective modelling of increasingly complex systems.
As Systems Engineering problems and solutions become more complex, it is harder for engineers to describe them and harder for reviewers and other stake-holders to understand the descriptions. By carefully combining textual and visual representation we can bring the best from two worlds together.
The presentation describes the benefits of integrating requirements management and systems modelling, including how the structure of the system model can be used to give structure to the requirements document and how system modelling supports the construction of a consistent vocabulary for the textual expression of requirements
In projects where Systems Engineering is applied, the basis for contract is usually a set of Requirements, captured in one or more requirements documents. The Supplier must understand the requirement set, and evaluate his potential to supply the required functionality and performance at acceptable cost, timescale and risk. The presentation introduces a simple checklist of ten questions, based on practical experience, that the Suppliers Requirements Analyst or Chief Engineer should ask himself, and ideally to ask his customer, before such a commitment.
Using the traditional balance of the Time, Cost and Quality equation, how do we determine the effective success of the system requirements? The sort of questions a Project Manager would ask are "would we have achieved the same design and product capability without spending all that time and effort on requirements" and "does spending more time up front give value for money?" From the Requirements Engineer perspective when are the requirements "good enough" to move on to the next stage?. The presentation provides examples of real life experiences from the defence and aerospace industries.
Use cases are frequently produced as a response to a set of system requirements, rather than as part of the requirements generation process itself. This can lead to user roles, system interactions, and domain data modelling not being properly explored and defined until the development phase, potentially causing changes to requirements and rework. This intriguing presentation outlines an iterative UML based development process that puts use cases at the heart of the process from the outset, using them as a vehicle for developing the required system from initial analysis through to the preparation of training materials.
Getting acceptance of a new SE tool in a Company or in a particular project can provoke resistance from the most unlikely people. The manager who is desperate for improved efficiency first needs to be able to quantify the return on investment. The engineer who is swamped with information can't afford the time to organise it. Based on actual experiences, this very informative presentation helps prepare you for some of the obstacles and gives some clues on how to win over the doubters
How do I introduce a requirements management tool in my organisation quickly?. How do I manage training and support? This presentation uses the introduction of DOORS into a large department of an international Company to show how a strategy of creating specialists, training and targeting support for chosen projects achieved a broad acceptance and quick take-up of the tool. The presentation describes the steps from problem definition to solution and also considers changes to existing company processes to accommodate the introduction of the tool.
Architecture frameworks (AFs) have emerged as an effective method for documenting and describing system architectures. An example is the United States (US) Department of Defence (DoD) AF (Architecture Working Group, 2003) which is specifically used to represent defence related systems and systems of systems. The success of this AF has led to the DoD mandating its use on all relevant procurement programs. The popularity of the DoD AF has led to the emergence of a number of software tools designed to aid DoD AF architects and systems engineers. This presentation assesses existing tool reviews and user feedback, to identify deficiencies and discusses their significance and importance within DoD AF projects .
Many papers and articles have been written on various aspects of systems modeling with UML, but little attention has been paid to system partitioning. Papers that address system partitioning do so with a "one size fits all" philosophy, by mandating a proscriptive structure that does not address the true needs of a particular systems development. A proper approach can help in the establishment of a component based development approach, leading to reuse of requirements, design, test, and implementation artifacts. The presentation discusses these issues and the drivers for systems partitioning, supported by 4 case studies.
Last Updated: 18 March, 2004