What the development process essentially does is to transform the expression of an idea for an IS – a problem to be solved, an opportunity to be taken advantage of – into a set of detailed, unambiguous instructions to a computer to implement that idea. The biggest problem is that computers are excessively stupid and will only do what they have been told to do. For example, suppose you create a billing program for an electric utility and specify that bills must be paid within a certain time or the customer’s electricity will be cut off. Suppose further that a customer receives a bill stating that he owes USD 0.00 (he might have a previous credit). Contrary to a manual system where all the work is done by humans, a computerized system may well treat this bill as any other bill and insist on payment; it may even send a signal to the customer relations department to cut off power for non-payment. To avoid this, explicit instructions must be included in the billing program to avoid dunning for amounts of less than a certain limit.
Systems developers must therefore pay attention to an excruciating amount of detail – not only when business goes on as normal, but anticipating all the exceptions that may arise. The exceptions may in fact amount to several times the work required for normal cases. The system then becomes, through sheer accumulation of details, more and more complex. This complexity is in itself a source of difficulty – it becomes hard to “see the forest for all the trees,” to keep your eye on the big picture of the business benefits to be achieved, while at the same time making sure that every technical and business detail is right and finding out what went wrong whenever something does go wrong – as it invariably will.
From the earliest days of computer technology, the method for developing information systems has addressed the need to proceed from the general to the ever more detailed. The first well-known effort at formalizing the process came in 1970, in an enormously influential paper by W. W. Royce describing the waterfall model of the systems development life cycle 1. Every author on systems development bases his or her work on some variation of this model, and we, too, have our favorite, depicted in Figure 3.3.
The work products or “deliverables” to be created during systems development start with the business case, the formal description of the rationale for developing a system in the first place, the results to be achieved and a cost- benefit analysis detailing planned development costs (often treated as an investment) as well as operational costs and savings. The business case is often considered part of project management rather than the development process per se; we include it here because it is the developers’ best tool for not losing sight of the essential – the end result they are trying to achieve. As development work proceeds, developers make choices: one of the main factors in deciding which alternative to pick is the impact of the choice on the business case. For example, a choice that increases benefits may also increase costs: is the trade-off worth it? As a result, the business case must be maintained all along the life of the project as decisions are made.
The next deliverable in the waterfall approach is the information system’s requirements. Requirements come in two flavors: functional requirements – what the system should do: processing, data and media content – and quality requirements – how well the system should do it: performance, usability, reliability, availability, modifiability and security.
The business objectives documented in the business case and the requirements, especially the quality requirements, dictate the architecture or overall shape of the information system being developed. The architecture describes the major components of the system and how they interact. It also documents design decisions that apply to the entire system, so as to standardize the solutions to similar design problems occurring at different places. Architectures or elements of architecture can be common to many applications, thus saving the project team time and money and reducing the amount of risk inherent in innovating. For example, many sales applications on the web use the concept of a "shopping cart," a temporary storage area accumulating product codes and quantities ordered until the customer decides that she has all she wants, at which point the application gathers all the products, computes the price, and arranges for payment and delivery. Shopping cart routines are available commercially from several sources.
- The design of the information system is at the heart of the development process. The design is in two parts:
- A description of how the system will appear to its users. This is called the external design or functional design.
A description of how the system will be operate internally, largely hidden from users. This is called the internal design (or technical design), and it lays the foundation for programmers to create the code which the hardware will execute.
The functional design specifies the interaction between the users and the system – what actions the user can take and how the system will react; it describes the inputs and outputs (screens, reports, messages exchanged with other systems); it establishes the different databases and their structure; and it shows at least a storyboard of the media content (text, graphics, photos, audio/video clips, etc.).
The technical design inventories the programs and modules to be developed, and how processing flows from one to the other. It also takes the architecture one step further in the implementation of some of the quality attributes, such as data integrity, fallback operation in case the system is unavailable, and recovery and restart from serious incidents. Finally, here is where any routines to create the initial data and media content required on day one of the new system’s operation.
Code is the technical name for the programming statements and database specifications that are written in a language that can be understood by the technology. Creating code is a highly self-contained activity; the details depend on the environment and the subject will not be treated further in this chapter.
Throughout these steps, the initial idea for the system has been transformed into a set of computer instructions. Each step is performed by human beings (even if assisted by technology in the form of development tools) and is therefore subject to error. It is therefore necessary to conduct tests to make sure that the system will work as intended. These tests are organized in reverse order from the development activities: first, the code is tested, module by module or program by program, in what is called unit tests. Next come string tests, where several modules or programs that normally would be executed together are tested. Then follow integration tests, covering all of the software and system tests, covering both the software and the people using the system. When the system test has been completely successful, the information system is ready to for use. (Some organizations add an additional test, called acceptance test, to signify a formal hand-over of the system and the responsibility for it from developers to management. This is especially used when the software is developed by a third party.)
To put the importance of testing into perspective, note that it statistically consumes just about 50% of the resources of a typical IS department.
With the system test complete and the initial data and media content loaded, the information system is put into production, and the development team is done. Right? Wrong! In fact, the most expensive part of the development process, called maintenance, is yet to come.
No sooner has a new system started to operate than it requires changes. First, users quickly discover bugs – errors in how the system operates – and needed improvements. Second, the environment changes: competitors take new initiatives; new laws and regulations are passed; new and improved technology becomes available. Third, the very fact that a new system solves an old problem introduces new problems, that you didn’t know about beforehand. To illustrate this, take the standard sign at railway level crossings in France: Un train peut en cacher un autre (“One train may hide another one”). This caution alludes to the fact that you don’t know what lies beyond your current problem until you have solved it – but then the next problem may take you completely unawares.
In theory, every change you make must go through a mini-life cycle of its own: business case, requirements, architecture, design, code and test. In reality, only the most critical fixes are done individually and immediately. Other changes are stacked up and implemented in periodic releases, typically a release of minor fixes every month and a major release every three to six months. Most often, the maintenance phase is performed by a subset (often around 25%) of the initial development team. But since the maintenance phase is likely to last for years – certainly more than ten and not infrequently 20 years, the total cost of maintenance over the life of a system can eclipse the cost of initial development, as shown in Figure 3.4.
(The increasing maintenance cost towards the end of the system life is due to the fact that the more a system has been modified, the harder it is to understand and therefore to make additional modifications to.
- 瀏覽次數：1869
