Chapter 1: Introduction
A Hypothetical Scenario
Imagine that you are an application programmer working for a midsize firm in the automobile industry that maintains numerous offices in a number of European countries. Your firm is pursuing the strategy of developing its own business applications in house. At first glance such a strategy may seem rather odd. But extreme competition and increasing cost pressures now demand a high level of flexibility and stability from the development team, and your division leader has guaranteed that the software systems developed will have these characteristics, and this is the justification for management's decision to support in-house development.
Up to now each office has installed and maintained its own software system, since the development teams in each branch have been working independently of one another.
First the Bad News
One fine day, you are summoned to your division leader's office. He informs you that big events are about to occur in the data processing division of the company. To accommodate increasing international growth and to promote efficiency, all the software in the entire company is to be unified, standardized, and streamlined into a single distributed system. The development teams will remain at the individual offices, but beginning at once they are all to report to a newly appointed division leader, under whose direction they are to work together to achieve the stated goals. Existing software at the individual branch offices is to be replaced piece by piece by the newly developed replacement packages. Isolated systems in various parts of the company (such as personnel management and accounting) are to be integrated into the new system. Thus you, a specialist in accounting and supply systems, are affected by the new developments.
Your job is to develop a prototype for this new system, which after an evaluation phase is to be further developed into a stable building block of the new system. Your piece of the action is to be a rudimentary accounting system. Other offices are to develop compatible inventory and annual accounts modules, and they together with your accounting module are to be presented to company management. A number of users from the various divisions must be able to use the system simultaneously. Since your company is planning on introducing telecommuting, the system must also be usable from outside the company, over the Internet, for example. In order to avoid bottlenecks during critical periods (such as the end of a quarter or year) the system must be able to operate under heavy usage. Furthermore, anticipated growth in the number of employees must also be taken into account.
A superficial reading of the above text could easily lead one to the conclusion that the task as set out should give little trouble to an application developer who is an expert in business applications. But if one reads more closely, a rather more complex picture begins to present itself (see Figure 1-1). The crux of the problem is in the new set of circumstances that confront our application specialist. These altered circumstances bring problems that will complicate the development of a prototype of a rudimentary accounting system. Let us examine the situation more closely in terms of the following observations.
Figure 1-1: Solution of a business problem.
The accounting system, which until now has been conceived as an isolated solution, must now be integrated into a larger system and enable a number of users to work simultaneously. For this the system must satisfy the following requirements:
multiprocess capability (multithreading),
A further consideration is the necessity of ensuring that the requirements listed above are standardized and consistent among all modules of the system. This is a very important requirement to consider. It is often overlooked because it does not directly map to any user requirements, and it becomes a critical factor in working with remote development teams.