Systems

Chapter 2

The word ‘system’ is widely used, but the useful working definition of a system when we talk about particular parts and particular goals sounds like: A system is a purposeful collection of interrelated components that work together to achieve some objective.

No matter how complicated and large any system might be, we can still apply this definition. Now if we talk about software systems, there are two categories:

1. Technical computer-based. This type of system includes hardware and software but not procedures and processes. Most of simple desktop software, OS etc. are examples of technical computer-based systems. Main point is: using this software has a purpose, but software itself does not know it, knowledge of this purpose is not part of a system.
2. Socio-technical systems includes hardware or/and software (actually, we can say it includes technical systems), but most important part it includes knowledge of how the system should be used and operated in order to achieve final objective. This kind of system includes predefined operational processes, people (to operate a system). Carleton University is a socio-technical system, because all of resources (library, buildings, computer labs, all physical things as well as general “knowledge”) are operated and used by certain people (profs, staff and students).

Socio-technical system is different from technical not only because of people. The book outlines three main distinctions:

• Parts of socio-technical system have properties that are properties of the system as a whole rather than associated with those parts particularly.
• Such system may be nondeterministic, which means that the same input don’t always produce the same output. System works and operated by human, who doesn’t always react the same way as some software.
• The way system works and achieves its objectives does not just depend on the system itself. It also depends on the stability of these objectives.

We should always keep in mind that the main principle of system is one of the main problems – system cannot be fully functional if even one part of it does not work. Interdependency causes this statement. This statement must be applied not only when we look at system and its parts, but also when we look broader – at different systems within another system. For example, we have a software program which is a system itself and consists of different components. They all work properly and system designed correctly, but if we actually plug this program into operating system (which is another system), and that OS operates all the hardware (which is also a system), we cannot be sure that the program will work as it suppose to. As a software engineer, person should always think wide.

One another source of possible problems is the ability of the system to involve and to be changed to accommodate modified system engineering requirements. It is very common when during such change software failure happens, even though software was working properly before an attempt to change it. Therefore, this kind of software failure is actually not software failure, but rather some mistake or series of mistakes during designing the system, so that modifying gone wrong. There is a complex relationship between system components and this very fact says that the system is more than just a box with some functional stuff in it. Parts and relationships have different emergent properties and those properties are properties of the whole system. Often those properties can only be derived from sub-system interrelationships and are “invisible” when we look at particular system component. There are two types of emergent properties:

1. Functional. Everything related to how the system works. For example, functional requirement of a phone is to be able to make and receive calls.
2. Non-functional. Everything related to behaviour and operating environment. For that same phone non-functional emergent requirement may be “to be easy to use”.

Emergent properties are often very complex and it is hard to describe them. It is even harder to analyze some properties. For example, reliability. First of all, we should know that reliability is such a property which cannot be seen and analyzed without detailed analyze of every part of a system. Even if 99 of 100 parts of a system are super reliable and solid-stone-never-fail-parts, one little piece may cause failure of a whole system.

There are three related influences on the overall reliability of a system:

1. Hardware reliability
2. Software reliability
3. Operator reliability

This is very obvious, because any problem may come from one of three main parts of a socio-technical system. System engineers are not just concerned with software but also with hardware and human interaction. They must think of services that system provides and how useful and easy to use different parts may be.

System requirements specify what the system must do and its properties. An important part of the requirements definition is to establish a set of overall objectives that the system should meet. A fundamental difficulty in establishing system requirements is that the problems are so complex, that there are so many related entities and there is no definitive problem specification. The true nature of a problem emerges only when a solution is created.

System design is concerned with how the system functionality is to be provided by the components of the system. Process of designing a system is fairy complicated and consists of different steps or phases. It starts with organizing requirements into related groups, then – identifying sub-systems that can (alone or interacting with each other) meet those requirements and cover all the groups of them. Then developers should actually assign requirements to sub-systems. Then, every sub-system’s functionality should be specified. It is also useful to specify relationships between sub-systems. When this step is done and all sub-systems are at least in some close to working state, software engineer should define sub-system interfaces. When this is done, it is possible to continue to develop these sub-systems in parallel.

Designing is one of the first and most important steps of product development. For almost all systems, there are many possible design decisions that meet the requirements. In perfect situation, developers choose design as they thing is the best for given requirements, but pretty often another facts affect this choice – customer’s desire, federal laws etc.

Next big step in developing is system modelling. Model of a system is an abstract representation of all parts and mechanisms of system. Usually model of a system is developed and shown as graphical image. There might be different scales of a model so it is possible to look at the system from different points of view and different scale.

Sub-system development is basically process of creating building blocks for a project. In fact, those sub-systems are not always developed from scratch for purposes of this particular project. Quite often developers can use sub-systems of different projects or even integrate some side-developed components. Sub-systems are usually developed in parallel. If the system developing process goes step-by-step, one component after another, it becomes very hard and expensive to make modifications. And there is (almost) always modifications to be done during development.

Systems integration is a process of putting all independently developed sub-systems into one. Integrating all the components at a time sounds like good way, but on practice it is not always possible, because development of different sub-systems takes different time. Also, adding sub-systems one-by-one or at least by blocks or sections reduces number of errors.

At finally, software evolution. This process is more abstract and doesn’t not directly related to first development, but still is very important. While developing software systems, changes can come even during designing and implementation, and of course more changes will come after some period of use. There may be just bug-fixing changes or adding new requirements. Changes should not be just technically motivated, different points of view should be taken to analyze process, such as business and technical prospective.

System decommissioning means taking the system out of service after the end of its useful operation lifetime. Hardware can be recycled, software can be reused for some different purposes or just be ‘forgotten’. Anyway, for a software, decommissioning is not such a big problem.

Software development might be such a complex process, so it is impossible to create a product alone or create it within small group of developers. In a complex projects organisational processes are important.

My thoughts:

After this chapter I can see the difference between two general types of systems when it comes to software or hardware, also now I understand why different objectives demand different sort of system. Any technical operation (mostly cyclic, or with no need to analyze situation in real-time, especially when it comes to something moral-related) can be done easily by technical systems, but there’s no such machine that can do anything without human. Socio-technical systems come along when there’s an objective and work on something to achieve that objective needs several decisions to make, and quite often those decisions can be made only by human.

Socio-technical systems seems more flexible and useful in many cases, still, there are a lot of disadvantages of this system. Human resource is not the best when it comes to errors (mistakes) and supporting socio-technical system in general is much more expensive.

Steps of developing model are familiar to me in general, but there are some new details we didn’t face while developing model for our Monopoly game, because even though we work almost as people work during large project, we didn’t face the same problems as, for example, Mac OS developers do. That’s why I found this chapter useful.