One of the main characteristics of information systems is that they are large, made up as they are of hundreds or thousands of individual components. In an invoicing subsystem, you might have a module to look up prices, a module to extend price by quantity, a module to add up the total of the invoice, a module to look up weight, a module to add up weights and compute freight costs, a description of the layout of the invoice, a module for breaking down a multi-page invoice, a module for printing... Each module is quite simple, but still needs to be tracked, so that when you assemble the final system, nothing is forgotten and all the parts work together. Compounding this is the fact that each module is so simple that when somebody requests a change or a refinement, you are tempted to respond, “Sure, that’s easy to do.”
And even though the components may be simple, they interact with each other, sometimes in unanticipated ways. Let us illustrate with an example – not taken from the world of IS, but relevant nonetheless. A large company installed a modern internal telephone system with many features. One of the features was “call back when available.” If you got a busy signal, you could press a key and hang up; as soon as the person you were calling finished his call, the system would redial his number and connect you. Another feature was “automatic extended backup.” This feature would switch all the calls that you could not or would not take to your secretary, including the case where your line was busy. If your secretary did not respond, the call would be sent to the floor receptionist, and so on, all the way to the switchboard, which was always manned. (This was in the era before voicemail.) The problem was of course that the backup feature canceled out the call-back feature—since you could never actually get a busy tone.
The effect of interaction between components in a business information system are often in the area of and quality requirements described earlier, such as performance, usability, reliability, availability, modifiability and security. None of these requirements are implemented in any one component. Rather, they are what are called emergent properties in complexity theory. For example, an important aspect of usability is consistency. If one part of the system prompts you for a billing address and then a shipping address, other parts of the system which need both should prompt for them in the same sequence. If you use a red asterisk to mark mandatory fields to be filled in on one screen, then you shouldn’t use a green asterisk or a red # sign on another screen. Neither choice is wrong – it is making different choices for the same function that reduces usability.
Finally, a critical aspect of complexity is the difficulty of reliably predicting system behavior. This means that you cannot be content with designing and coding the software and then start using it directly. You first have to test it to see whether it actually does behave as predicted (and specified). This test must be extremely thorough, because errors may be caused by a combination of conditions that occur only once in a while.
Unpredictability also applies to making changes to the system. This means that once you have made a change (as will inevitably happen), not only must you test that the change works, but you must also test that all those things that you didn’t want to change continue to work as before. This is called regression testing; how to do it at reasonable cost will be discussed later.
- 瀏覽次數：1330
