Based on the 6th edition of ‘Software Engineering’ by Ian Sommerville, published by Addison Wesley. (amazon.com, amazon.co.uk)

Computer-based system engineering is introduced by Sommerville as a discipline sitting above software engineering and encompassing hardware systems to take a whole system perspective. The introduction of 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 system properties which exist within the system as a whole (emergent properties). Sommerville provides some examples these emergent properties, such as the overall weight of a system (which could be computer from the weights of all the subsystems), and the usability of the system (which would have complex dependencies 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 interested in usability (being a Mac user). Simplistic views of usability have always really frustrated me. I remember once reading a really high level requirements specification written by a client which said something 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 I should be getting out of the way so someone can design a paper based system. What are the usage patterns in the system? A system which users will work on without any training needs to be designed very differently to a system people will use day in and day out. In the end, what the client really meant here was that usability was an important factor for the system, which I would agree with whole heatedly, but downplaying the complexity of usability just makes it more difficult to allocate the time it requires.

Emergent system properties

Somerville begins by dividing emergent properties into functional and non functional. Functional emergent properties are defined as those which appear when the system is assembled as a whole (like a properly assembled bike becoming a transportation device) as opposed to non-functional properties like 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 are complex, but to be honest anyone who has ever tracked down a subtle bug knows that interrelating systems 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 are also described as interrelated, with hardware failures potentially causing further software failures, and stress caused by failures causing operator errors etc. This interrelationship can cause initially minor failures 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 actions which 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 a system being affected by context in which the system is used. The example provided is of some system designed 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 very reliable systems.

Air-conditioner problems are usually a nightmare for those in charge of computer server rooms. I remember being onsite with one of my old customers had the power in their server room fail. They had managed to get at least the critical servers back up by running extension cords across the corridor, and more 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 particularly complex emergent properties because they define things which should not happen rather than things which should. This makes assessing these properties particularly difficult since there is no finite list to test against.

Systems and their environment

We being this section by expanding on the air conditioner example, looking at how systems tens to exist in an environment hierarchy. The building is in a street, which is in a town and so on, and problems and trickle down (or sometimes up) that hierarchy. In addition to being affected by the environment, it is also important to understand the affect a system is intended to have on its environment. Once again, we can go back to the air conditioner, which is designed to decrease the environment’s temperature, and so can only be properly assessed in this context.

Sommerville next approaches the organisational environment of a system, where it intersects with human factors. Specifically highlighted are cases where a system might change work processes, de-skill workers or change an organisation’s power structure. In each of these cases, the ‘environment’ may actively resist the system, which opens out to the whole field of change management (which back in the 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 guys start 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 those working on it.

System modelling

System modelling is introduced basically as the use of a block diagram to progressively break a system down into sub components until it reaches a level of functional components (which are defined as providing a single function). I guess if you have never seen a block diagram before this might be insightful, but it really seems very obvious to me. There is also a brief discussion about using this breakdown to make decisions about implementing various sub-systems in hardware vs software, which presumably makes sense.

Functional system components

Somerville provides some clasifications for functional components by the type of work they perform.

  • Sensor components collect environmental information
  • Actuator components create some change in the environment
  • Communication components facilitate communication between the different sub-systems
  • Co-ordination components (surprisingly enough) co-ordinate the activities of other components
  • Interface components translate between other components

The 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 in the design.

The system engineering process

The system engineering process described is roughly analogous to the standard waterfall software process (which is apparently discussed further in the next chapter). The key differences between the system process and the software process are listed as interdisciplinary involvement (meaning increased scope for misunderstanding) and the increased difficulty/expense of rework (with software being very valuable because of its relative flexibility).

Software is also presented, in this section, as ‘glue’ holding systems together, and being used to patch up unforeseen problems which would be too expensive to solve at the hardware level. Sommerville attributes 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’t repeat the individual components here.

System requirements definition

Somerville breaks out three classes of requirements, abstract functional requirements (high level specification of the functions of the system), system properties (non-functional requirements like safety which affect all sub-systems) and the clumsily named but fairly obvious ‘characteristics which the system must not exhibit’.

One key aspect of this process brought out by Somerville is to capture the underlying requirements at a high level without presupposing a particular solution. You tend to see this done very poorly in a lot of software RFTs and I assume it’s similar in system engineering. At the same time, Somerville also notes that many problems to be solved as sufficiently complex that it’s practically impossibly to solve them completely in advance (i.e. Wicked problems).

System design

Somerville breaks down the system design process into the following steps.

  • Partition requirements
  • Identify sub-systems
  • Assign requirements to sub-systems
  • Specify sub-system functionality
  • Define sub-system interfaces

These steps are ordered, but there is expected to be feedback between the steps with a view towards iterating 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, including organisational and political factors.

Sub-system development

The sub-system development level is where we may drop into a software engineering process to develop 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 commercial off the shelf software (COTS). This may require changes to the original design to accommodate a COTS systems which does not exactly meet the original requirements.

Given that the sub-systems will generally be developed in parallel to reduce the overall system development 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 is considered important to design software for change in these cases).

System integration

System integration is the process of joining all the separately developed sub-systems to create a single working 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 scheduling difficulty and identify problems earlier (and simplify tracking the problem down to a particular module).

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 incorrect assumptions. This is, obviously, more likely to occur in cases where the original design does not define sub-system responsibilities in sufficient details.

System installation

Hopefully it’s pretty clear what this phase involves (although remember we’re talking systems which would usually have a hardware component). Somerville lists a number of factors which can cause system installation to be problematic/take longer than expected.

  • The system’s final environment may not match the assumed environment, and so may not operate as expected.
  • Hostility from the users may cause problems (likely where the system changes the nature or reduces the number of jobs in an organisation).
  • The system may need to work alongside an existing system (although hopefully this would be anticipated and planned for). This introduces problems in cases where the new system can not be fully installed 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 equipment level, which never really exhibited any of these problems, so I don’t really have much else to add.

System operation

Somerville defines this system operation phase as the initial phase of operation, including training the users, 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 should hopefully be minimised by appropriate planning and training.

System evolution

Most systems, and especially large ones, tend to be evolved over time rather than being repeatedly replaced for cost reasons. That said, Somerville presents a number of reasons why system evolution tends to be expensive.

  • Proposed changes must be carefully analysed from a technical and business perspective (I’m not really convinced 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 required to multiple sub-systems.
  • In cases where original design decisions were not appropriately documented and kept updated, the team responsible for the changes may have to try to reverse engineer the reasons behind these decisions.
  • As changes are made over time, the architecture of the system tends to become more complex, making changes increasingly expensive over time.

Once again, I haven’t got much to add here, although I’ve worked on a number of legacy software systems, I’ve never really been involved in evolution of anything with a hardware aspect beyond some server hardware infrastructure.

System decommissioning

Systems with hardware component have a number of interesting considerations in the decommissioning phase. Some sub-systems may need special disposal procedures for environmental reasons, but hopefully these considerations are planned for in the original design. Software sub-systems don’t have these considerations, however the migration of any data which needs to be retained into some other system may require significant effort.

System procurement

The initial process for purchasing existing software systems is very similar to the engineering process just presented, but obviously deviates at the sub-system design/development phases. The top level requirements and design must still be undertaken to allow decisions between purchasing and building to 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, and software ‘glue’ is often used to allow the sub-systems to be integrated as required (which may increase the total cost of purchasing components).

In cases where custom built sub-systems are required, this development is often contracted out, which creates an issue request to tender, select tender, negotiate contract process to allow the contractor to begin development. In many cases, this contact is then split into sub-systems and subcontracted to other organisations, the results of which are then integrated by the prime contractor.

Conclusion

So, there we go. This one took a lot longer than the last, probably because the whole system level perspective doesn’t interest me a great deal, making the motivation harder to find. I guess it is important 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.