January 2011 Edition
Computer Science Department, University of Cape Town
| MIT Notes Home | Edition Home |
| MSc-IT Study Material January 2011 Edition Computer Science Department, University of Cape Town | MIT Notes Home | Edition Home | |
The smaller the system, the sharper its boundary. Large systems may have multiple boundaries as they interface with multiple systems. The boundary also depends on the point from which it is viewed in relation to other systems with which it interfaces.
An example of the complexity and difficulties of defining system boundaries is the ATM (automated teller machines). Consider the following candidates for system boundary:
The physical machine itself
The customer and the machine
The machine and the bank's local database of customer accounts
The machine and the bank's national network and central database of transactions and account balances
The machine and the staff that loan and run regular software checks of the machine
Which of the above might be the “right” boundary for the analysis of the system in which the ATM is central? Different analysts may choose different boundaries, and these boundaries may change during talks with the customers wanting the system built, and with the ultimate end-users of the system. An important skill which systems analysts and software engineers must develop is to determine which boundaries are important to consider.
The software which we as software engineers develop are only a component of larger information systems in an organisation or group. This module concerns itself with the development and engineering of software, but to effectively engineer such software we must be able to understand the information system as a whole, and relate the software to it.
For effective and successful software engineering, software engineers have the difficult job of learning how the information system users perform their daily jobs, as well the tasks they attempt to achieve. If the software does not support the users in their tasks, then the software will not be used, and the software development has failed.
During the development of the American Federal Aviation Authority (FAA) automated flight control system software engineers tried to produce electronic counterparts for the flight strips — little bits of paper giving details of a particular flight which would be moved between operators and used for quick reference. This task proved to be impossible and the final system not only still has these bits of paper but the consoles have special slots to put them in.
This example illustrates an important point; that is any artificial system has a boundary which defines what is part of it and what is not. Sometimes this boundary is clear cut, say when the computer screen and keyboard are the boundary for a system, other times it is not, say when people and bits of paper form an integral part of the system. In the case of the FAA system some of the functions that were considered part of the system are solely performed by humans, but still within the boundary of the information system and the software being developed.