The systems thinking concept must be kept firmly in mind as you read the chapter and the information on this page. E-Business systems do not exist in a vacuum. All subsystems within the organization must be designed, developed, implemented, and maintained within the context of the entire system. To do otherwise is to harm the system at the expense of the subsystem being developed. It is management's responsibility to ensure that systems thinking is utilized throughout the E-Business Systems Development process.
BTW, those of you who find this stuff interesting will want to consider:
We finally arrive at the point in the IT/IS development process where we are ready to design specific information systems, often referred to as applications. The managerial decision making process developed in Chapter 9 provides a basis for identifying information requirements. This chapter provides an introduction to various methods of system development, which are in fact detailed information requirements determination processes. I hope that all of you will find this interesting and that you will want to take ISM4113, Business Systems Development, in the future. The entire course is devoted to examining and practicing the concepts introduce here.
Why, you may ask, do you need to know how to develop an IS? Turban, McLean, and Wetherbe (three IS/IT heavyweights, text on reserve in library) provide the answer: "Since specific organizational environments and general technologies change over time, organizations need new systems, or major revisions to existing systems, to continue to meet their objectives. Therefore system development is an ongoing process in all organizations that use it." Systemically, existing systems are constantly under stress from managers who have new and changing information requirements. These information requirements force the existing systems to adapt, to change to accommodate the stress. Managers, and specifically their new and changing information requirements, are the reason why system development is an important concept to know.
A second reason is that studies have shown over and over that managers are best suited to lead the system development process. Managers can best define their information requirements and the business processes that both generate and use the information. User participation in the development process also ensures complete knowledge of the systems, leading to higher levels of acceptance of the resulting systems and satisfaction with the use of the systems.
The following figure, from Davis and Olson (on reserve in the library, chapters 9 and 10 are particularly good), page 97, illustrates the System Development process from an overall perspective. Reality is defined in terms of the organization, its managers and other personnel, and its environment including competitors and customers. We can look at reality in terms of the Competitive Forces Model in figure 2.2, page 50. From reality managers conceive mental models of how the organization ought to operate. These models are refined by managers into SOPs and specific procedures for conducting business. The mental models form the basis for logical system design. The logical system design converts the mental models into formally defined models that specify system outputs, inputs, database requirements, and procedures (see below). The models represent how the IS is supposed to operate. It is important that managers either completely design the logical models or lead the process. The logical models form the basis for physical system design. Computer analysts and programmers convert the logical models into physical models, called programs and data file definitions. The programs are installed onto a computer and data are acquired by the programs. The programs and data constitute the physical system and data storage.
It is important to understand two points. First, the physical system design can be no better than the logical system design from which it is developed. Second, the logical system design must be developed by mangers who understand reality and the mental models from which it is developed.
With this overview of system development, we are ready to examine in greater detail the various activities that define the process. Specific points in Chapter 10 include:
One very popular SDLC process is introduced on page 405: Prototyping. Prototyping is a modified form of the SDLC that works well when there are high levels of uncertainty associated with the IS development process. While prototyping is iterative in nature (as with SDLC), its focus is on speed and "putting something in the user's hands" rather than methodical IS design. This method works well when managers and users cannot, for whatever reason, completely specify information requirements. The concept relies upon the old saying, "The user doesn't know what he wants until you show it to him." Figure 10.4, page 407, illustrates this concept. Analysts and users/managers/owners meet to develop a preliminary IS design based on what knowledge is available and what information requirements can be identified. The analysts and programmers take the initial design and quickly develop a working prototype of the IS. "Quickly" means within days - the prototype IS is delivered to users within a few days while the "iron is hot." Users work with analysts and use the system and evaluate it. A second round of information requirements is completed, corrections and changes identified, and the analysts again quickly incorporate the requirements into the prototype. This process continues until the users are satisfied that the prototype is close to or actually achieves the IS design goals. Figure 10.5 provides a good example of the prototyping process.
While the prototyping process works well, it does have its disadvantages. Chief among them is that the process has no formal (or informal) provisions for producing documentation, particularly system documentation. Managers who participate in a prototyping project should insist on both user and system documentation as the prototype system is being developed. (Documentation is discussed later)
The examination of the SDLC process begins at the bottom of page 406 with the "Starting the Systems Development Process" section. Figure 10.3 illustrates the "traditional" SDLC, in this case as a five phase process. It is often called a waterfall method because the work progresses from one phase to another. The authors also point out that the specific number of phases is open to interpretation. Some texts represent it with fewer phases and some with more. The point is to recognize that all of the activities that define the SDLC phases must be accomplished regardless of how they are characterized. The figure below illustrates another SDLC model, one with 7 phases. It is equally as valid as the one illustrated in Figure 10.3, and the two representations can easily be mapped onto each other.
The traditional SDLC process works very well if uncertainty levels are relatively low. Manager know what they want and can specifically define it. Prototyping, introduced above, is the strategy to use when uncertainty levels are relatively high.
Each phase of the eight phase SDLC process is provided below. Each phase is examined from a somewhat different perspective.
Systems Analysis is introduced on page 410. It focuses on preliminary system design by performing an organizational analysis (page 410), an analysis of present systems (page 411), and a functional requirements analysis (page 411). After an analysis is complete, a preliminary understanding of the IS and its major functions have been defined. Figure 10.12 provides an example of functional requirements.
The process of logical design begins with the definition of outputs. Managers define what information and reports are required in order to effectively manage. The information definition process was first introduced in Chapter 9. There are three sets of questions that managers must answer when thinking about their information requirements and the outputs that deliver the information: (from Davis and Olson, page 462)
As you can see, these questions focus on information determination. The information is then described in terms of outputs from the IS. Managers literally take pencil and paper in hand and develop report formats. For example, let's consider a retail sales organization example. The sales system definition process may begin with the development of an invoice, a report of a specific sale. The figures below illustrate what managers may design. Style and form are not as important as content. What specific information must be outputted by the system in order for the sales department management to do their jobs?
Both of these invoices contain the same information. How detailed the output definition examples are is up to the managers defining the outputs.
Let's look at the second invoice. It has the following information on it:
The invoice defines the information required for the Sales department, the Inventory department, and the Personnel department to do their jobs. Managers from all three departments (plus any other departmental managers who may need access to the information) sit down and define what an invoice is and what information is required on it. Remember the systems concept of subsystem goal congruence.
This output definition process is done for every report, every form, every specific information request that all the managers in the organization can develop. This is a lot of work, but it must be done if a complete logical system is to be developed.
Once outputs have been identified, the inputs, database, and procedures are developed. The inputs and procedures define what data are captured and how the data are generated. The procedure for completing a sale defines the specific activities that a salesperson must accomplish. The inputs are the items of data that the salesperson must ascertain and enter into the IS in support of the sales procedure. For example, the customer's name and address, both billing and shipping, must be ascertained. This is usually done through a customer identification code for repeat customers. The specific items being sold, identified by Item Number, are entered into the system as well. The customer's purchase order number is recorded and a unique invoice number assigned to the sales transaction. All of these data items are required if the questions of who, to whom, what, and when a sale took place.
Consider this example of the importance of identifying all inputs. The salesperson's unique identifying code must be entered at the time of the sale if a report of "Sales by Salesperson" is to be produced at the end of the month. As the Sales Manager, it is your responsibility to identify the requirement for this input data item during the sale process. As the old saying goes, "You can't get it out if you don't put it in." Every datum required for subsequent reporting must be identified as an input and incorporated into the procedure that generates it.
The database logically defines how the data are stored in the IS in order to facilitate the processing of inputs into outputs. Chapter 5 introduced these concepts. The input data must be logically organized if it is to be retrieved and processed into useful information.
The primary benefit of developing the logical system design is that it provides a complete, specific, unambiguous definition of what the physical system is to do. User attitudes and perceptions are a major factor in determining use of an IS. Users who are active participants in the development process, studies have repeatedly shown, are much more likely to use an IS than users who had no input in system development.
Another important aspect of phase 3 is illustrated by the following graph. As the graph illustrates, the cost of IS modifications increases exponentially as development proceeds. It is much easier to make changes, additions, and corrections in the early phases of the SDLC than in later phases. For this reason it is important that managers work to make the logical system design specifications as complete and as correct as possible. The four most dreaded words of all programmers and analysts are, "Oh, by the way...."
If the IS is to be developed using internal resources (analysts and programmers), the logical system design serves as the IS specifications. If the IS is to be acquired from an external source (consultants, software development company), the logical system design serves as a "checklist" of requirements for the IS being considered. Either way, the logical system design serves to document the specific requirements of the new IS.
The author mention documentation on page 427. There are two types of IS documentation:
Since the users, managers, and owners of the IS are the ones directly benefiting from the system, it is ultimately their responsibility to see that complete documentation be developed.
The author briefly mentions IS testing on page 427. Testing is an important aspect of any IS development and is the responsibility of management and the users. There are three general types of testing:
It cannot be overemphasized that all testing is ultimately the responsibility of the owners, managers, and users of the IS. It is their system, they must depend upon it to accomplish their jobs, and they should not accept it until they are satisfied that it meets their requirements.
There are basically two ways to finally implement a new IS:
Which is the best implementation strategy? The answer is "Yes." Most companies have found that the extra work and expense of the parallel conversion method are a small price to pay for the convenience of having an existing system to provide backup support when needed.
Data backups are more important. When (not if) the system hardware crashes, a current copy of all data must be available in order to reestablish IS operations. Most organizations perform daily backups, thus ensuring that no more than one day's transactions need be reconstructed in the event of a system crash. Weekly backups and month end backups before closing are also highly recommended. Most business continuation insurance require off-site backups as well. When the building burns to the ground and the computer system is slag, there has to be a copy of the data somewhere to serve to reestablish the business. Do you want to trust your backup tapes to the "fireproof" file cabinet? The importance of backups cannot be overemphasized.
EUC is defined as the development of IS by end users, the (typically non-computer trained) people who directly use the IS. EUC is a direct result of two factors. First, today's microcomputers are so inexpensive and so powerful that they can support the IS/IT development tools that non-computer people typically need to develop systems. Most of the tools described in chapter 4 are the tools of EUC. Spreadsheets, word processors, presentation development, and RDBMSs are the most widely used EUC tools today. Today's microcomputers can support these tools and the resulting IS developed from them. The tools are quite inefficient from a computer perspective, but the effectiveness increases of the users make EUC a viable IS development alternative. The second reason for EUC is systemic in nature. Managers responding to ever changing business pressures place stress on existing IS. Information Service personnel respond to these stresses as fast as they can, but cannot keep up with demands. End users become frustrated when they don't receive "immediate" service, so they develop their systems themselves.
EUC systems can be as simple as a spreadsheet to assist with a loan interest calculation or as complex as a complete sales order entry system developed using an RDBMS. The key is that end users themselves develop the systems. The advantages and disadvantages of EUC are well explained in the text. Figure 10.18, page 417, provides an excellent perspective on the EUC process. The Providence Health Systems example on page 418 illustrates this point very well.
From a managerial perspective, EUC has another important aspect. Users who develop EUC systems are typically not trained in the rigor and science of Computer Science (it's called Computer Science for a reason). As such, EUC developed systems typically are not adequately tested or documented, nor does adequate user training occur. However, these system usually take on the same level of importance as systems properly developed by Information Services personnel. Major problems arise when errors surface in these systems. Major problems also arise when the developer leaves the company and takes the entire system with him/her. Managers who are responsible for the functional areas in which EUC systems are developed are vulnerable to these problems. It is important that managers understand that when they permit and support EUC, they are essentially taking on the same responsibilities as the Information Services Department. All EUC systems developed should be managed exactly as systems developed by Information Services department personnel. EUC is wonderful when properly managed. It is the responsibility of each functional department manager to ensure that EUC is properly managed. Failure to do so opens the manager to all manner of problems. The author mentions this point in the first paragraph on page 417.