STEPS IN BUILDING INFORMATION SYSTEM
You are consulting for the information technology division of a state university to guide and facilitate the design of a new system for handling college applications, which has previously been handled entirely with a paper-based process. They would like to set up a system by which prospective students can apply online. Describe in detail their first steps and any studies they should perform before designing the new information system.
You work for the IT department of a startup ASP, and it is your job to set up the testing processes for a new enterprise system the company will be hosting. Describe the processes you will recommend. What unique considerations will you have?Chapter 13 Building Information Systems
“What do you mean we have to change the way we make our candy bars? They are the number one selling product we have. Everyone loves them. Why can’t we just keep doing things the way we’ve always done them? It’s worked fine this long.”
It’s not unusual to hear this type of dialog in companies, large and small, all across the world. Change is hard on people and organizations. But it’s one of those necessary evils that keeps companies in the lead or helps destroy them. In this chapter, we’re going to focus on using information systems as a way to successfully help redesign organizations so they can improve their current processes or establish new ones.
It would be nice if we could give you a precise checklist of how to smoothly introduce a new information system, but we can’t. No one can. What we provide in this chapter is information you can use to help plan and analyze organizational changes associated with new systems development.
Change is disruptive. Change is dangerous. Change is good. Change is necessary. Change is constant.
Types of organizational change:
Rationalization of procedures
Business process reengineering (BPR)
BPR attempts fail 70 percent of the time. That’s an astonishing figure when you think about it. What if your car failed to start 70 percent of the time? Some of the reasons for the high failure rate are lack of planning, management’s inability to fully comprehend the enormity and complexity of the effort, and the fact that BPR usually takes much longer than expected.
How Information Systems Support Quality Improvements
Here are some ways companies can use information systems to achieve total quality management:
Simplify processes by using information to determine what the processes are in the first place
Identify benchmark targets
Gather, process, and store customer feedback in information systems that are available company-wide
Reduce cycle time by providing information earlier in the process
Redesign the process or redesign the product by using information about the process
Improve production processes by using available information from internal and external sources
Bottom Line: Continual change is a necessary part of corporate life. Four types of organizational change each carry their own level of risk and reward: automation, rationalization, reengineering, and paradigm shifts. The quality of a company and a product can be improved through the reliable, useful information produced by a well-developed, well-managed and integrated information system.
13.2 Overview of Systems Development
Systems development includes every resource and every step that goes into producing an information system that solves a problem or helps the organization take advantage of new opportunities.
Don’t start by thinking, “Oh, we’re going to develop a new computer system? Well, that problem belongs to the IT (Information Technology) department.” Nowadays, system development belongs to you as much as it belongs to the techies. You have to work hand-in-hand from start to finish within the entire organization to develop a usable system that will serve everyone.
The Role of End Users
Don’t forget that people are the most important component of any system. As soon as users begin to feel they have little input into the development process, you are courting disaster. Keeping the end user involved will produce a better system. The number one reason so many system development projects fail is due to insufficient user involvement.
The actual programming phase will in all likelihood be carried out by the IT department. If you’re using a fourth-generation language, the programming could very well be done by the end user. Either way, make sure that the programming supports the analysis and design phases. If not, go back and work through them again. It could very well be that what was designed simply can’t be programmed. The usual impulse is to program around the design flaws. Don’t! Redesign instead.
“Hey, it works!” But does it really work as it was designed in a real-world situation? Was every aspect thoroughly tested by independent testers in the actual setting? Several things that go wrong in the testing phase of the development process can severely hamper the project’s success.
For one thing, this step is glossed over by both techies and non-techies. People assume that because something was designed and programmed according to the specifications in the analysis stage, it is right. So they just fly right through the testing process. Or they run one or two tests, usually by the very people who designed and programmed the system. “Hey, I know it works ’cause I programmed it.” Uh, oh! Wrong! You should never have the people who were involved with the design and programming stages do all the testing. Get a fresh pair of eyes to look at the system according to the test plan that was developed by the programmers and the users.
Most of all, if you do find a flaw in the testing, do not give in to the temptation to ignore it or explain it away. Go back to the analysis, design, and programming stages. Get rid of the flaw the right way.
There are three types of testing; unit, system, and acceptance. The last is the one that is most important and yet the most underrated. Managers and users must be adamant about testing the system, measuring it against the analysis and design requirements, and then accepting the system only when it does in fact measure up.
There is no right way or wrong way to implement the system; you have to look at it in the context of your particular organization.
You can use the parallel strategy, but it’s expensive to run two separate systems at one time. If you don’t have a lot of confidence in your new system, you might want to go with this one.
If you’re really confident in your development process or if the old system simply doesn’t work anymore, you can use the direct cutover strategy. For instance, Friday you’re using the old system; come Monday you’re using the new one.
If neither of the above describes your organization or your new information system, you might want to consider the pilot study strategy. You can introduce the new system into a single area of the organization. If all goes well there, you can install the new system in other areas. You’re still going to have to figure out how to run two systems at once and also figure out how to integrate the new system with the old system.
The phased approach is similar to the pilot strategy, but now you install parts of the new system slowly into specific areas of the organization. Again, two systems, two methods, integration problems, support problems, etc.
If you’ve ever watched a house being built, you know everything starts with the blueprints. One page of the blueprint set has an overall picture of how the house will look when it’s done. Another page gives a front view, a side view, and a back view. There are several pages with extremely detailed drawings showing where and how everything fits together. You wouldn’t dream of building a house without all of this documentation – at least we hope not
STEPS IN BUILDING INFORMATION SYSTEM
Designing an information system to support a network system function requires a proper understanding of software development process and its lifecycle. Information system development also requires a good understanding of software lifecycle stages to ensure quality and correctness of the software (Pitoura & Bhargava, 1994 ). In this case, it is important to follow all stages of the software lifecycle as it an essential part of building a reliable information system network. Therefore, if there is one mistake in any of the lifecycle stage might jeopardize the whole information system for the institution. Any wrong step taken in the one may affect the entire development process of the software (Alter, 1998 ). Therefore, it is important to consider the first steps in developing a reliable information system before actually designing the whole software system.
The most important step before building an information system to support a network or a particular function is by considering gathering and analyzing requirement process. This is the brainstorming stage where sub-steps are considered, for example, feasibility analysis, which helps in the assessing how much an idea can be put in place for the development (Pitoura & Bhargava, 1994 ). At this stage, major stakeholders, end users, and project team need first to communicate about their expectation of the project and gather information for software development purposes. At this point, the institution is required to collect information through interviews and surveys. In addition, the school is required to build a multiple case scenario in describing the action each user will take once the system develops.
Once the institution has gathered and analyzed its findings for the development process, the information is then purposed for analysis. Once an information system expert or profession approves the results, the institution can now define the entire system for the purpose of the study (Pitoura & Bhargava, 1994 ). The institution will simply have to develop a blueprint of the various phases of the software development process in the project. The institution will have to define every stage in order to avoid errors and understand what the process the user will have to follow to apply successfully within the organization. The institution will have to provide a system that is well divided to make it easy for the developers, designers, testers, and project managers to work on the software in the latter stages provided. These an important section, as it will define the nature of the system, the institution will expect. Therefore, false information can jeopardize the whole process.
Recommendation and considerations
In successfully setting up a testing process for an enterprise system, it is important to prepare a test plan to define the methodology to be used in the testing processes of the company system. Setting the step program can act as a general guideline to omit errors likely to be faced during the testing process (Alter, 1998 ). In addition, developing a test plan can help testing the individual component separately. In completing single trials, the whole system will then be tested as a host application format. The testing process is accessible through a variety of platforms that are supported by the system application. It is vital to check the system by accessing through a variety of platforms, as the system is only available as a host application. Once the system is discovered to support a variety of platforms such as Mac and Windows, the system will then be tested through the clients running computer system. This is to ensure compatibility of the software in the customers’ running system (Alter, 1998 ). Repeat the process until there is certainty of the workability of the system in the clients’ running system.
Alter, S. (1998 ). Information Systems. Boston: Addison-Wesley Longman Publishing Co.
Pitoura, E., & Bhargava, B. (1994 ). Building information systems for mobile environments. New York: ACM.