Practical applications of systemsengineering do not have to bear the hallmarks of the latestsystems tools and techniques or be conducted using the in-vogueterms of the discipline. Indeed, as many of us in the professionalready recognise, systems engineering is often done"naturally", even unconsciously, as it were, itsbeneficial effects passing into a successful end-productunrecognised as an application of sound systems engineeringprinciples. Even some of the discipline's strongest proponentshave only recognised after the event that what they foundthemselves doing at some point in their careers was actuallysystems engineering!
This paper describes how a systemsengineering function evolved naturally during the engineering ofthe Channel Tunnel one of the largest single infrastructureprojects ever tackled and certainly the largest ever to have beenentirely privately financed. Designed and built by TML(Transmanche Link), a consortium of ten British and Frenchconstruction companies, the project emphasis was always onearliest possible completion using tried and tested technologyand well established construction industry methods. However, anentirely new transport system was, nevertheless, being createdrequiring very effective systems engineering techniques to bedeveloped "hot-foot", as it were, during the course ofthe design development process. Not only were these techniquessuccessfully developed and applied, they were also specificallyadapted to the construction industry environment with its strongemphasis on physical realisation within target date and costconstraints.
This paper addresses the integration of thehuman component into system design. It describes the backgroundto the changes that are taking place throughout the world'sdefence industry. Whilst the driving forces for this change hasbeen military the underlying problem applies to all systems ofany real complexity. The paper considers the problems ofdesigning complete systems that include not only hardware,software, but also the people who must operate and support themduring their service life. It outlines a programme that BritishAerospace Defence is implementing to integrate the human factorsinto the design process. It highlights the principal problemsencountered when trying to design for the end user, and finallyidentifies the support required from the MoD and other customersin designing effective systems.
Many systems fail to deliver their potentialbenefits. Major problems are found when the system has beenprocured and is going into service or during trials of thesystem. This is especially true of systems that in themselves maybe complex and have major interoperability requirements withother systems. Even relatively minor problems discovered at thatstage can result in large cost and timescale over-runs, and cancause loss of planned functionality and perceived benefit.Increasingly, standard system components can be specified toprovide detailed functionality and it is the integration ofsystems and their interoperation with other systems that are thecause of problems.
To tackle these problems, validation ofdesign is required early in the procurement life cycle to addressthe system behaviour and study the way in which componentsinteract. Finite state machines describe systems in terms ofexisting in a number of different states with transitions betweenthose states. However, they are conceptually difficult to relateto other views of the system.
Behaviour Diagrams provide an executablemodel of the functionality of a system or interoperating systems,as an extended finite state machine. They provide the means tomodel sequential and parallel processing, include representationof functions, control, states, information passing and storage.Unlike many techniques, Behaviour Diagrams allow therepresentation of a system with multiple allowed states whichexist concurrently and are intimately related to the functionsand messaging within the system. Large systems can be modelledusing the behaviour diagram method to create a hierarchy, complexfunctions are themselves modelled as behaviour diagrams.
This work demonstrates the development ofBehaviour Diagrams for a complex system from conventional finitestate machine and recognises the advantages that can be gainedfrom this technique. In addition, support for the BehaviourDiagramming technique provided by a commercial systemsengineering support tool, allows for simulation that providesvalidation of logic and operation. The use of such a computerbased tool to support a systems engineering repository provides amajor advantage over other methods. Further work into the use ofBehaviour Diagrams for the support of systems engineeringactivities is in progress.
This paper examines the nature of systemsengineering from a fundamental viewpoint. It discovers that thefoundations for this approach are set in a belief in the absolutenature of the world and our ability to understand it. This beliefhas been challenged in the field of science, most notably by thephilosopher and scientist Karl Popper. But this challenge has notbeen reflected in engineering. However, the concept of 'soft'systems can be seen to embrace this new science, and this papertries to show how this concept can be underpinned and extended toprovide a foundation capable of supporting the entire systemsengineering discipline.
The use of Yourdon-based functionalmodelling techniques for the requirements analysis and systemdesign of naval combat systems was pioneered by VSEL in the late1980s on the MOD sponsored SSN20 submarine project. Since thenthese techniques have been progressively developed and employedat both the combat system and equipment levels on an increasingvariety of studies.
This paper will survey the use of thesetechniques on combat system studies including Swiftsure andTrafalgar class tactical weapon system update. Vanguard SSBN, thefuture frigate and landing platform dock (replacement) anddescribes the technique developments currently taking place, suchas in the development and use of generic models.
It will describe how the techniques can beused for purposes such as configuration management and equipmentspecification. assessment and selection and indicate how thetechniques can be applied throughout the system life cycle and aspart of a systematic, integrated approach to combat systemdevelopment and procurement.
The RA (Requirement Analysis) processundertaken at any point during the SEP (Systems EngineeringProcess) results in some representation of the problem to besolved by the remaining activities. The outputs of this processare paramount to the success of the subsequent activitiesresulting in the creation of an effective system.
The 'competition baseline' establishes therequirements against which competing enterprises will beevaluated during a competitive tender. Implementing the RAprocess correctly in the production of this baseline affordsbenefits to both the customer and the competing enterprises.
A process for the creation of the competitionbaseline requirements set has been developed and implemented forthe RMPA project. The process provides an example of how the IEEEP1220 approach to RA can be used effectively prior to contractaward in such a way as to streamline the procurement process andprovide a head-start for the selection prime contractor in theapplication and management of the subsequent SEP.
With the transition from traditional civilservice to agency status, the DRA has seen the need to introducea more professional approach to its major revenue earningactivities. This has been evidenced most clearly by thecommitment to achieve full ISO 9000 certification for the wholeAgency in a phased manner over the next several years.
The CIS (Command and Information Systems)sector of the DRA was chosen to spearhead this drive, andachieved certification in October '94 for all its businessstreams, including systems and software engineering. This sectorwas chosen both because of its exposure to these types ofactivity and because of the perception that it could take thelead in selecting, and developing where necessary, an appropriaterange of tools and methods.
This paper will discuss the development of theresulting quality management system from a number of viewpoints.Firstly, the technical standards themselves. The decision wasmade early on to adopt the European Space Agency standard PSS-05(now generally available in published from Prentice Hall) as thecore standard for all software projects, and to build around it anumber of supplements covering of topics important to the DRA'sbusiness, such as prototyping, informal (laboratory standard)software, commercial off the shelf software, and a number ofitems necessary for compliancy with ISO 9000-3 (TickIT).Particular languages and application areas with special needs aresupported by detailed work instructions, maintained by the DRA'sSoftware Engineering Centre. The resulting structure of the setof procedures will be discussed, along with the reasons for thechoice of the ESA standard which has become pivotal to theapproach.
More recent work has led to the production, indraft form, of an additional systems engineering proceduresdocument, which has the same level of abstraction as the ESAstandard but aims to generalise it to address systems comprisedof software, hardware and people. A supplement has also beendrafted to cover the issues of tailoring project lifecycles, thatis dealing with the large number of instances in which projectsdo not comply with the simple 'waterfall' model, but adopt a morecomplex lifecycle, for example iterative or evolutionary.
A further aspect which will be covered is thatof staff training and 'roll out'. Because of the timescales set,this was necessarily compressed, but nonetheless successful. Atthe time of writing, a survey is being conducted to ascertain theopinions of staff as to the suitability and usability of theprocedures, and a second phase is being planned to accommodatethese points of view. Training has been an integral part of theexercise, with large numbers of staff being put through aspecially designed 3-day familiarisation course, backed up bymore specialised training in particular tools and methods. Atraining team, made up of DRA staff supplemented by outsideexperts, has been put in place to service the demand, which nowextends potentially across the whole DRA.
Finally, the success of this project hasopened up the prospect of extending the software and systemsengineering practices developed so far to cover the whole DRA, amove which can be expected to have far reaching implications notonly for the organisation itself but also for its principalcollaborators and customers.
This paper represents a summary of a 3 yearresearch programme carried out by 3SL. Issues that seniormanagement have in companies requiring and supplying large orcomplex systems are discussed. The emphasis of the paper is tocompare and contrast the needs and expectations of differentindustries.
Last Updated: Sunday, March 31, 1996