Computer-based system engineering is introduced by Sommerville as a discipline sitting above softwareengineering and encompassing hardware systems to take a whole system perspective. The introductionof hardware systems bring in a number of aspects such as the physical environment of the system,which need to be considered and controlled. Another key aspect is the consideration of systemproperties which exist within the system as a whole (emergent properties). Sommerville provides someexamples these emergent properties, such as the overall weight of a system (which could be computerfrom the weights of all the subsystems), and the usability of the system (which would have complexdependencies on the hardware, software the system’s environment and indeed the system’s users).Though it’s not actually relevant, I’ll wander off on that last point as I’ve always been quite interestedin usability (being a Mac user). Simplistic views of usability have always really frustrated me. Iremember once reading a really high level requirements specification written by a client which saidsomething along the lines of ‘The system should be user friendly – what more is there to say?’.Actually, there’s a lot. Who are these users? Can we assume they can use a computer? If not, maybe Ishould be getting out of the way so someone can design a paper based system. What are the usagepatterns in the system? A system which users will work on without any training needs to be designedvery differently to a system people will use day in and day out. In the end, what the client reallymeant here was that usability was an important factor for the system, which I would agree with wholeheatedly, but downplaying the complexity of usability just makes it more difficult to allocate the timeit requires.Emergent system propertiesSomerville begins by dividing emergent properties into functional and non functional. Functionalemergent properties are defined as those which appear when the system is assembled as a whole (likea properly assembled bike becoming a transportation device) as opposed to non-functional propertieslike safety and reliability which are not directly related to the system’s function.The focus of this section seems to be to get the reader to accept that emergent properties arecomplex, but to be honest anyone who has ever tracked down a subtle bug knows that interrelatingsystems can be almost impossible to anticipate.Reliability is the key example put forward by Somerville, and three key influences are introduced,specifically hardware reliability, software reliability and operator reliability. These three factors arealso described as interrelated, with hardware failures potentially causing further software failures, andstress caused by failures causing operator errors etc. This interrelationship can cause initially minorfailures to become more problematic. Personally I can attest in at least system administration
problems, that the stress of failed systems can very rapidly lead you to take ill-considered actionswhich make the situation worse (and leave you stuck there until 3 am).The groundwork for the next section is also put in place here, with a discussion or the reliability of asystem being affected by context in which the system is used. The example provided is of some systemdesigned to operate in a certain temperature range which might be exceeded due to a broken air-conditioner system. This sort of relationship, when unanticipated, can easily bring down otherwise veryreliable systems.Air-conditioner problems are usually a nightmare for those in charge of computer server rooms. Iremember being onsite with one of my old customers had the power in their server room fail. They hadmanaged to get at least the critical servers back up by running extension cords across the corridor, andmore amusingly, placing a large number of fans at the door to the server room. Quite impressive,albeit a gross violation of OH&S guidelines.Sommerville finishes this section with a brief mention of security and safety as being particularlycomplex emergent properties because they define things which should not happen rather than thingswhich should. This makes assessing these properties particularly difficult since there is no finite list totest against.Systems and their environmentWe being this section by expanding on the air conditioner example, looking at how systems tens toexist in an environment hierarchy. The building is in a street, which is in a town and so on, andproblems and trickle down (or sometimes up) that hierarchy. In addition to being affected by theenvironment, it is also important to understand the affect a system is intended to have on itsenvironment. Once again, we can go back to the air conditioner, which is designed to decrease theenvironment’s temperature, and so can only be properly assessed in this context.Sommerville next approaches the organisational environment of a system, where it intersects withhuman factors. Specifically highlighted are cases where a system might change work processes, de-skillworkers or change an organisation’s power structure. In each of these cases, the ‘environment’ mayactively resist the system, which opens out to the whole field of change management (which back inthe day I always used to confuse as just another name for configuration management).Electromagnetic radiation is an interesting environment example raised at the very end of the section.Being a software guy I don’t have much exposure to it, but it always amazes me when hardware guysstart worrying about interference between different bits inside a computer case etc. I guess it’s just
one of those things that never even crosses my mind, but must absorb a great deal of time for thoseworking on it.System modellingSystem modelling is introduced basically as the use of a block diagram to progressively break a systemdown into sub components until it reaches a level of functional components (which are defined asproviding a single function). I guess if you have never seen a block diagram before this might beinsightful, but it really seems very obvious to me. There is also a brief discussion about using thisbreakdown to make decisions about implementing various sub-systems in hardware vs software, whichpresumably makes sense.Functional system componentsSomerville provides some clasifications for functional components by the type of work they perform.Sensor components collect environmental informationActuator components create some change in the environmentCommunication components facilitate communication between the different sub-systemsCo-ordination components (surprisingly enough) co-ordinate the activities of other componentsInterface components translate between other componentsThe key point at the end of this system is that most systems should include components of each type,and if you find one is conspicuously missing from your design, you may well have missed something inthe design.The system engineering processThe system engineering process described is roughly analogous to the standard waterfall softwareprocess (which is apparently discussed further in the next chapter). The key differences between thesystem process and the software process are listed as interdisciplinary involvement (meaning increasedscope for misunderstanding) and the increased difficulty/expense of rework (with software being veryvaluable because of its relative flexibility).Software is also presented, in this section, as ‘glue’ holding systems together, and being used to patchup unforeseen problems which would be too expensive to solve at the hardware level. Sommervilleattributes changing system engineering requirements as the actual cause of many ’software failures’,in particular the fairly famous Denver airport baggage system.The rest of the section is basically a whirlwind tour of the components of the process itself, so I won’trepeat the individual components here.
System requirements definitionSomerville breaks out three classes of requirements, abstract functional requirements (high levelspecification of the functions of the system), system properties (non-functional requirements likesafety which affect all sub-systems) and the clumsily named but fairly obvious ‘characteristics whichthe system must not exhibit’.One key aspect of this process brought out by Somerville is to capture the underlying requirements at ahigh level without presupposing a particular solution. You tend to see this done very poorly in a lot ofsoftware RFTs and I assume it’s similar in system engineering. At the same time, Somerville also notesthat many problems to be solved as sufficiently complex that it’s practically impossibly to solve themcompletely in advance (i.e. Wicked problems).System designSomerville breaks down the system design process into the following steps.Partition requirementsIdentify sub-systemsAssign requirements to sub-systemsSpecify sub-system functionalityDefine sub-system interfacesThese steps are ordered, but there is expected to be feedback between the steps with a view towardsiterating towards a final design, with significant rework expected in the early stages.Somerville also highlights non-technical factors which may have an affect this process, includingorganisational and political factors.Sub-system developmentThe sub-system development level is where we may drop into a software engineering process todevelop the subsystem. This, of course, has it’s own requirements, design, etc phases.Sommerville also mentions that subsystems may, in many cases, be ‘implemented’ through commercialoff the shelf software (COTS). This may require changes to the original design to accommodate a COTSsystems which does not exactly meet the original requirements.Given that the sub-systems will generally be developed in parallel to reduce the overall systemdevelopment time, problems in one may require changes or work-arounds in another. Often software is
used here in a ‘glue’ capacity because it is generally less expensive to change (which is why it isconsidered important to design software for change in these cases).System integrationSystem integration is the process of joining all the separately developed sub-systems to create a singleworking system. This is sometimes done in a single process at the end of the project (the ‘big bang’approach), however Somerville recommends an incremental approach to reduce the schedulingdifficulty and identify problems earlier (and simplify tracking the problem down to a particularmodule).One key issue Sommerville raises here is the possibility of disputes between developers (or sub-contractors) about the responsibility for problems which occur between sub-systems due to incorrectassumptions. This is, obviously, more likely to occur in cases where the original design does not definesub-system responsibilities in sufficient details.System installationHopefully it’s pretty clear what this phase involves (although remember we’re talking systems whichwould usually have a hardware component). Somerville lists a number of factors which can causesystem installation to be problematic/take longer than expected.The system’s final environment may not match the assumed environment, and so may not operate asexpected.Hostility from the users may cause problems (likely where the system changes the nature or reducesthe number of jobs in an organisation).The system may need to work alongside an existing system (although hopefully this would beanticipated and planned for). This introduces problems in cases where the new system can not be fullyinstalled without removing the old one.Physical problems may become a factor, especially in buildings with limited space or restrictions(historic buildings etc.)The limit of my experience in installing hardware systems is at the server and network equipmentlevel, which never really exhibited any of these problems, so I don’t really have much else to add.System operationSomerville defines this system operation phase as the initial phase of operation, including training theusers, identifying and fixing where the specified requirements do not meet the business requirements,and generally getting things up and running. With any system there is likely to be an initial transition
period with increased problems as users become accustomed to the new system etc, but this shouldhopefully be minimised by appropriate planning and training.System evolutionMost systems, and especially large ones, tend to be evolved over time rather than being repeatedlyreplaced for cost reasons. That said, Somerville presents a number of reasons why system evolutiontends to be expensive.Proposed changes must be carefully analysed from a technical and business perspective (I’m not reallyconvinced by this – how it is different to the initial system development)Changes in one sub-system tend to have an effect on others, meaning that changes are usually requiredto multiple sub-systems.In cases where original design decisions were not appropriately documented and kept updated, theteam responsible for the changes may have to try to reverse engineer the reasons behind thesedecisions.As changes are made over time, the architecture of the system tends to become more complex, makingchanges increasingly expensive over time.Once again, I haven’t got much to add here, although I’ve worked on a number of legacy softwaresystems, I’ve never really been involved in evolution of anything with a hardware aspect beyond someserver hardware infrastructure.System decommissioningSystems with hardware component have a number of interesting considerations in the decommissioningphase. Some sub-systems may need special disposal procedures for environmental reasons, buthopefully these considerations are planned for in the original design. Software sub-systems don’t havethese considerations, however the migration of any data which needs to be retained into some othersystem may require significant effort.System procurementThe initial process for purchasing existing software systems is very similar to the engineering processjust presented, but obviously deviates at the sub-system design/development phases. The top levelrequirements and design must still be undertaken to allow decisions between purchasing and buildingto be made, and the integration and subsequent steps are also very similar.Large systems are almost always composed of a range of existing and custom built components, andsoftware ‘glue’ is often used to allow the sub-systems to be integrated as required (which may increasethe total cost of purchasing components).
In cases where custom built sub-systems are required, this development is often contracted out, whichcreates an issue request to tender, select tender, negotiate contract process to allow the contractor tobegin development. In many cases, this contact is then split into sub-systems and subcontracted toother organisations, the results of which are then integrated by the prime contractor.ConclusionSo, there we go. This one took a lot longer than the last, probably because the whole system levelperspective doesn’t interest me a great deal, making the motivation harder to find. I guess it isimportant to have this perspective when working as a sub-contractor on projects of this sort of scale,simply to understand how your work fits into the larger picture.No Comments Yet