I would classify both Workcaenter and the Millenium Bridge as "b" system engineering projects.
I would classify both Workcaenter and the Millenium Bridge as "b" system engineering projects.
such an effective lessons
I've returned to a course after a particularly period at work. But I cant find the extra reading material, where is it hidden. I remember I had this problem when I first started your course. Frustrated!
Rommel Anthony Miranda United Arab Emirates Science is about understanding the origins, nature, behavior of the universe and all it contains; engineering is about solving problems by rearranging the stuff of the world to make new things. Conflating these separate objectives leads to uninformed opinions, which in turn can delay or misdirect management, effort, and resources.
As you would expect, since this course deals with systems engineering, it embodies the principles and methods associated with a systems perspective. So it is important that you understand systems and the systems perspective at the beginning of the course.To have engineered a system successfully, all its features - the technology, control systems, people and related aspects of the physical environment - have to contribute to the achievement of its objectives. In other words, it has to operate in an integrated, coherent way.
It has to meet the requirements of all stakeholders. There are also things that it must not do. For example, it should not exceed its agreed or projected running costs; it should not, in achieving its requirements, wantonly harm individuals or the physical environment, and so on. These sets of requirements and constraints can be represented by the three models shown in Figure 21.
The demands, choices and constraints associated with a system can arise from any of the stakeholders in that system. If stakeholders are denned as an identifiable group of people or an organization, or organisations, having a legitimate interest in the process or outcomes of a systems engineering project (see also Box 6), identify the stakeholders in the Millennium Bridge project.
You should now read the document " Box 6- Stakeholders", in the section tilted 'Extra reading materials'
The constraints define the area in which the system can legitimately operate. The articulated demands or requirements of the system are at the core of the system. They, together with the constraints, define the amount of choice that the systems engineers will enjoy. In practice, and even with the best endeavors of the various stakeholders in the system, demands and constraints are rarely articulated in a way that the clarity of the circles in Figure 21 might suggest.
One way of looking at systems engineering is to regard it as a process of progressively refining demands (requirements) and constraints in such a way that design choice is eliminated. This process of progressing from an initial, fuzzy concept of what the system will do to a final, implemented and ambiguity-free system is illustrated in Figure 22.
Into which of the three categories shown in Figure 21 would you place the Autodesk and Millennium Bridge examples discussed in module 1?
I would classify both Workcenter and the Millennium Bridge as type ‘b’ systems engineering projects.
The success of a systems engineering activity is judged by:
• How well the outputs of the activity fulfil demands and how well the design of the system has avoided violating constraints,
• How successfully the systems engineers have implemented the choices that were available to them,
• The quality of the systems engineering process.
Although the quality of the systems engineering process may be regarded as a tertiary measure of a systems engineering project, it is the foundation of the primary and secondary measures of success.
Adopting a systems approach addresses the need to establish and maintain the internal coherence of the project and its external requirements. The systems approach consists of:
• A set of concepts that provide a philosophic basis for the approach,
• A methodology that forms a framework for designing, developing, operating the system and managing change,
• A set of techniques, used within the context of the methodological framework, that provide a toolkit for planning, analysis and design work.
The relationship of these three elements of the systems approach is illustrated in Figure 23. Each of these elements of the systems approach will be discussed in turn.
The word ‘system’ is from the Greek word meaning a complex, organized whole. It has been used in this sense throughout history, and the Oxford English Dictionary records examples of usage dating from the early eighteenth century.
Figure 24 shows a simplified diagram of a typical system. It indicates the boundary of the system, which divides those elements that are considered to be within the boundary, and therefore part of the system, from those elements in the environment of the system. I will discuss each of these features of systems in turn.
Drawing or positioning a system boundary is a difficult matter of judgement involving decisions about what is to be included and what should be placed in the environment. The difficulty of this act of judgement reflects its importance to the success of the system, since the placement or delineation of the boundary reflects the perspective of the system's designer.
For example, in the Autodesk Workcenter project the designers within the company drew the ‘boundary of the product’ around what could be placed in the box (literally). They considered that they were designing a piece of software and, of course, to some extent that was what they were doing. Had they adopted a different, broader perspective they would have included within the product boundary the consultancy needed to achieve its successful implementation.
It is an easy matter to redraw the boundary of a system on paper at a very early stage of development.
However, as projects progress the boundary becomes embedded in the design concept, investment is made, and it becomes progressively more difficult to alter the position of the boundary.
Positioning the system boundary is vitally important in systems engineering and is recognized in BS ISO/IEC 15288 ‘Systems engineering - system life cycle processes’.
• The system of interest- the system whose life cycle is of interest to a particular project.
• Enabling systems- a system that contributes to the system of interest during one or more of the stages of its life cycle but which does not contribute directly to its operation. For example, a production system may be required to realise the system. Enabling systems have their own life cycles and will probably, at one time, have been, themselves, systems of interest. The standard notes that a systems engineering project may also have to take responsibility for creating an enabling system. (ISO/IEC 15288, p. 56).
• Systems in the operating environment- these are systems with which the system of interest interacts when it is operational. The nature of the interaction may be goods and services, energy, or information.
The Standard's view on the relationship of these three types of system is shown in Figure 25.
My perspective is that all systems are designed. This is demonstrably the case for systems that are engineered to be of utility, but is also true of systems that are formulated for research or analytical purposes.
In both instances decisions on what is included in the system, and therefore what is in its environment, and the establishment of the relationship between the elements within the boundary constitute design decisions.
Therefore, whether explicitly designed or not, systems are in the eye of the beholder.
In 1928/29 the Belgian surrealist painter René Magritte exhibited a work that he called The Treachery of Images. It depicted a smoker's pipe with the cautionary label ‘Ceci n'est pas une pipe’ (This is not a pipe). Preoccupied with the flimsy veil between image and reality, Magritte was making the point that an image of a thing is not the thing itself. Magritte's image is reproduced in Figure 26 with another level of caution!
To go beyond Magritte's image and answer the question ‘What, in reality, is a pipe?’ it would be necessary to get hold of a real pipe and demonstrate it. Setting aside solipsist objections we might conclude ‘OK, that really is a pipe’.
As the eighteenth century empirical philosopher John Locke stated, ‘External objects furnish the mind with the ideas of sensible qualities …’ (Locke, 1997 ) which are all those different perceptions which they produce in us. We can experience the reality of a pipe by looking at it, touching it and (perhaps especially) by smoking it and smelling it. However, none of our senses, neither singly nor in combination, can be used to detect the reality of a system.
While we may accept that knowledge is derived from our senses, nobody sees, feels, hears, tastes or smells a system.
What we conceive are objects, people, information, ideas and relationships to which we give the label ‘system’. In attaching the label ‘system’ to them we are expressing explicitly or implicitly:
• A purpose for the assemblage.
• That a relationship or set of relationships exists between the elements in the assemblage.
A system is therefore an intellectual artifact and the label ‘system’ can be used for two purposes. First, it is a convenient way of putting a conceptual boundary around a disparate set of elements. For example, ‘the public transport system’ might include within its boundary railways, air transport, buses and coaches, and taxis. Second, using the label ‘system’ suggests a (different) way of looking at the world (Boehm, 1988). The systems viewpoint is one that emphasises purpose and process.
The image shown in Figure 27(a) represents a fountain pen, but it might also be described as a system for turning thoughts into marks on paper (b) that another person can (more or less) read. The object label ‘fountain pen’ emphasises existential form, whereas the system label tells us what it is for and the transformation (thoughts into marks on paper) that it is part of. Using the systems viewpoint is extremely valuable in engineering since it can prevent premature judgements being made. Setting out on a project with the objective of ‘designing a new fountain pen’ is a very different proposition from ‘designing a system for turning thoughts into marks on paper’.
Starting from the requirement of a new system to put marks on paper might produce a solution radically different from a fountain pen. Another important attribute of the systems viewpoint is that it encourages a holistic perspective, which we discussed in unit 3- part 2.
Each of the elements in the system is affected by being part of the system, and the way that the system operates would change if an element were to be removed.
Elements of a system can be decomposed into a more detailed set of sub-elements that are included as part of the system. The level of analytical detail will depend on the perspective of the analyst and the purpose that he or she has in mind. The elements that should be included as part of the system's environment are those that influence the system in some important way, but over which the system has no direct control.
Each element in a system can be regarded as a process, and the system itself consists of processes that are coupled together in an identifiable way. By process, I mean a set of activities that produce an identifiable output. A process may be formally defined, and in systems engineering most processes will be of this type. One of the objectives of systems engineering methodology is to make processes and their associated outputs explicit. This characteristic will be examined in more detail later.
All the elements in a system and its environment are connected in some way. The connection may be physical - raw materials, components, assemblies and products move from one element to another. But the connection or relationship can take many forms - organizational power and authority, information and political influence.
The nature and form of the relationship between the processes in a system express the intent of its designers, whether the system is utilitarian or analytical in character. Therefore, as I suggested earlier, as its creator and the identifier of the system, the engineer, researcher or analyst is an important feature of the system.
This is not to imply that the whole thing is completely subjective; that would be true to an extent neither greater nor less than any other form of engineering or analysis. But it does mean that the perspective and purpose of the system's creator have to be taken into account, as Figure 27 suggests.
To summarize, a system may be formally defined as:
An intellectual artifact that consists of an assembly of processes that are connected in a determinable relationship, which has a purpose that is either utilitarian or analytical in character.
This definition is wider than that proposed in the standard - ‘a combination of interacting elements organized to achieve one or more stated purposes’ (ISO/IEC 15288, p. 4) - but has recognizably common characteristics.
The main differences are that the T837_1 definition explicitly reflects the subjective character and recognizes that systems thinking can be used for analytical as well as design purposes.