Lecture - 20

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. This Lecture gives a more detailed look at the various methods for actually building a new system. We'll first look at the traditional system lifecycle method and then examine some alternative methods to building a system.

11.1 The Traditional Systems Lifecycle

The systems lifecycle describes large- and medium-size systems projects. It has existed for years and uses tried-and-true methods that help ensure success of the system from its humble beginnings as an idea to an old relic that eventually needs replacing. There are six stages to the lifecycle:

Project definition Systems study Design Programming Installation Post-implementation

The traditional lifecycle may seem rigid today: There are very definite roles for techies and non-techies. In fact, the user is left out of the loop on a lot of the development and implementation. Even though end users or managers have to sign off and accept the system at the end of each stage, they are not as involved in this method as some of the others we'll look at later. That's why this process may not be the best for small systems development .

FIGURE 11.1 The lifecycle methodology for systems development.

Stages of the Systems Lifecycle

The project definition stage helps you determine if a problem exists, or if there is an opportunity the company can take advantage of with a new information system. You can also determine if you need to modify an existing system in order to keep up with the competition. At this point you decide what the new system can do - something like the main page of the house blueprints. The systems study stage takes longer than you might expect. You need to gather as much information as you can about the current situation, what you expect from the new system, and how it will all fit together. Oh, and don't forget to check the business plan. The more information you gather at this stage, the more complete your information requirements statement will be and the better idea you'll have of the finished product. In the design stage, before you go much further, make sure techies and non-techies are speaking the same language, singing the same tune, using the same sheet of music, you get the idea. You'd be surprised how many times a failure to communicate at this stage really fouls things up later on. Often each side thinks it knows what the other side is saying: just make sure they do. Just before the programming stage begins you should get everyone together, review all documentation, rehash system requirements, and verify agreement (preferably in writing)

from all sides. It's hard work to create the programming code - it can be harder to recreate it later on. What you decide up to this point will be pretty much set in concrete during the programming stage. The installation stage includes the steps discussed i.e.: testing, training, and conversion. This is where the rubber meets the road! Don't think your job is done once the system is installed and fully operational. You still have work to do: you need to review the original specifications against the finished product and make sure they are met. Are users adequately trained, or do you still need work in this area? Does the system need a little bit of tweaking to make it run better? Is it fully integrated and supportive of the rest of the organization and the overall business plan? Double check just to make sure (post-implementation). Users shouldn't feel they have to accept errors or products that donot meet their specifications. Your job at this point is to uncover those areas that do need changing before they become a way of life. Do it early, when it's still easy to make changes. Finally, the system will break down or become obsolete and you'll have to start all over. Just like the house that seemed so perfect ten years ago and now seems small and outdated, it's the nature of the beast.

Limitations of the Lifecycle Approach

The lifecycle approach works well for major systems but does not fit the bill for smaller ones. It's expensive, time-consuming, and sometimes doesn't allow techies and nontechies to work together as they should. Bottom Line: The System Lifecycle works well for large system development projects. There are definitive roles for techies and non-techies. It's a highly structured method of developing systems.

11.2 Alternative System-Building Approaches

Prototyping, application software packages, end-user development, and outsourcing are alternatives to the Lifecycle approach and in most situations are actually preferred methods of building a new system.

Prototyping
Fast, cheap, user-centered: Prototyping can be the best way to develop a new system if the end users don't have a clue about what they really want the end product to look like. Even if they have a few clues, this approach works well because users can guide the process based on what they see as the system is being built. Have you ever watched a television show where the police artist draws a picture of the crook as the victim looks on? The artist draws the eyes and gets approval from the onlooker. Then the mouth is sketched in and approved. Pretty soon a composite drawing

is completed, and the cops are off and running. That pretty much describes the prototyping method of building a system. You would generally use prototyping for very small systems or small parts of a larger system. You wouldn't want to use this method to build a company-wide Information System. It can be too unstructured, making it harder to manage in large projects. Prototyping works well when you're developing user interfaces and output reports - areas the users will see the most. The text outlines the four steps you use when developing a prototype. The important thing to keep in mind is that these steps should be repeated many times over. If you work through them just once, you might be in trouble. Some additional tips: Step 1: Ask lots of questions. Step 2: Sketch an informal flowchart with a pencil and paper. Pay attention to the decision trees. Step 3: Have users try every part of the new system. Step 4: Repeat, repeat, repeat. If you are the developer, make sure the user signs off on every step of the process. Verify that the prototype does in fact meet the user's needs. If you're the user, are you happy with the new system and does it work well for you? If not, why not? If not, go back to Step 3.

Advantages and Disadvantages of Prototyping

Prototyping can be less costly than the traditional systems approach, but if you fail to follow some of the basic principles of systems development, it can be more costly. For instance, if you ignore the basic principle of how the prototype fits into the other Information Systems in the organization, or how it supports the business plan in general, you may be costing the organization more money than you realize. Did you just create an island of information that is incompatible with other systems, or is it fully supportive and easily utilized in other areas? The greatest advantage of the prototyping method of developing systems is that users see the product, or at least a pretty good replica of it, right away. If they like it, you press on. If they don't like it, changes can be made immediately. There's less red tape and bureaucracy (perceived or otherwise) to work through in this method. But be careful if you use the prototype as the actual production version. Is it the best it can be, or are you just tired of fiddling around with it?

Application Software Packages

Fast, easy, convenient, user-driven: Many software packages are extremely convenient for non-techies to use to build their own systems. Commonly called "off-the-shelf" software, these packages can be the best method of creating an Information System if that system is fairly standard across different types of businesses. Table 11.1 lists examples of Application Software Packages that are most commonly used in organizations and businesses of all types.

Accounts receivable Bond and stock management Computer-aided design (CAD) Document imaging E-mail Enterprise resource planning (ERP) Groupware Healthcare Hotel management Internet telephone Inventory control
TABLE 11.1

Job costing Library systems Life insurance Mailing labels Mathematical/statistical modeling Order processing Payroll Process control Tax accounting Web browser Word Processing

You don't have to worry about system documentation, since that usually comes with the software. You still have to write local procedures for using the program, but you don't have to start from scratch. Training is easier because once you learn how to use the menus and toolbars in one program, the same skills can be carried over to other programs. Training manuals often come with the program or are available through online help functions. Application software packages also provide an easier method of obtaining code corrections, updates, and enhancements: simply go to the Web site of the company that wrote the software and download the latest version. Need technical support for the program? Log on to the Web and you're there. No telephone calls, no waiting on hold for hours, no begging the IT staff to fix your problem. In fact, you'll probably find answers to questions you didn't even know you had! Most of the common programs still need to have standards for use within the organization. For instance, if you use an accounts receivable application software program, you should still set standards for how you will adapt that program to meet the unique requirements of your company.

Advantages and Disadvantages of Software Packages

Most off-the-shelf software can't be changed, so you have to take what comes. The unique requirements of your organization probably won't be met. You'll end up having to change your methods to match the software, instead of the other way around. Some software packages do allow some customization, but not as much as a program developed solely for your organization. Larger software programs such as Enterprise Resource Planning (ERP) may require extreme organizational changes to adapt to the software. Or you have to create or

purchase separate software programs called middleware that will bridge the gap. Make sure you understand up front what will be required for implementing the software before you purchase it. You can easily spend thousands of dollars, only to find out that you can't use the program. Application software packages still need lots of planning, especially when it comes to integrating them with the other Information Systems throughout the organization. Compatibility is key. You should determine the total cost of ownership with these programs beforehand. Is your hardware adequate to handle the new software? Many organizations and individuals learned this painful lesson in August 1995 when Microsoft released Windows 95. Expensive hardware upgrades were required in order to run the software. What are the training costs, implementation costs, and integration costs? They all add up.

FIGURE 11.4 Effects of customizing on total implementation costs.

The graph in Figure 11.4 shows that as modifications increase, so do the total costs of implementing a software package. Sometimes the changes, if they are numerous enough, can wipe out any expected savings.

Selecting Software Packages

Selecting software packages can be just as demanding as developing a system on your own. You have to evaluate:

The program's functions to make sure they fit your needs The flexibility to adapt to your business User-friendliness (persware) Hardware and software resources Database requirements Installation and maintenance efforts Documentation

Vendor quality (including follow-up) Cost

Just as you would for any piece of equipment, you would seek Requests for Proposal (RFP) from several vendors to evaluate the software package according to your needs. Remember, you give up a lot of control when you choose to go with a software package.

End-User Development
This method of system development is a bit like prototyping, but the end user designs and develops the new system using the fourth-generation language tools we reviewed . It's convenient for small applications, and the user can have complete ownership of the system.

FIGURE 11.5b End-user development.

This section of Figure 11.5 shows how much quicker it can be to have end-user system development rather than the traditional lifecycle development: end users can complete the system in minutes or days, whereas the traditional development takes weeks or months.

End-User Computing Tools: Strengths and Limitations

The tools available to the end user are getting easier to use all the time and increase the likelihood that the system will meet the user's specifications, since the user is building it. There's no one else to blame if the system doesn't do what the user wants it to do. But don't attempt to build larger and more complex systems using this method. The capabilities of the tools are limited.

Management Benefits and Problems

Managers should be aware of some inherent dangers when allowing users to develop their own systems. Standardization can be a tough issue when you use this method. You're almost begging for conflicts in data processing and storage, since each user will have his or her own method of creating, defining, and developing data. It may be faster to build a system using this process, but the system may not be as complete or as advanced. There are limitations to what you can do. While it may seem

less costly to use the fourth-generation language tools to build systems, you must still figure out the total cost of ownership (TCO), including the time it takes for the non-techie to learn to use the tools. The TCO should also include the cost of each version of the software license that the organization will have to pay for. The biggest danger is creating those islands of information. The chance of redundant end products just went up, since each user will have his or her own system with slight differences that may prohibit cross-utilization of the information. We're not trying to discourage this type of system development. As the text points out, the advantages of having users develop their own products are tremendous. You just need to be aware of the risks.

Managing End-User Development

One way to reduce some of the risks associated with this development process is to establish information centers in the organization. These are like technical support units that offer help and guidance to users. They can be the focal point for training, reviews, and advice. They could also ensure that systems meet certain organizational standards. Just don't make them too bureaucratic or difficult to access, because then no one will use them.

Outsourcing
What happens if an organization decides it doesn't have the in-house expertise to support the system development process or any of the system maintenance required? No problem: outsource. There are hundreds of outside companies that will do the job. These companies offer expertise and experience. They can also offer smaller organizations economies of scale that make overall information processing cheaper.

When to Use Outsourcing

To summarize the text, it is best to use an outsourcing company:

For mainstream applications such as payroll. You may not be able to do it cheaper because of economies of scale. When time is not of the essence. Can you process data updates at night? Can you afford to have the system go down without damaging core business processes? If you don't have the in-house support necessary to manage a system. Do you lack the necessary hardware, software, and persware your organization needs to succeed?

The total cost of ownership of a system can be cheaper because of outsourcing. Perhaps the outsourcing company can keep up with changing technologies better than the organization. It may simply be that the organization decides to spend in-house information resource dollars in other ways. Should you decide to use an outsourcing company to develop an Information System, you must be more careful than ever to ensure that everything, right down to the smallest detail, is in writing and agreed upon by both sides. You are signing a contract with the outsourcer that carries the full force of law. You must agree on how changes will be made to the current system. How responsive will the outsourcer be to changing requirements? You still have some responsibilities for the system; what will they be? Get it in writing!

You must continually analyze the outsourcing company's performance and cost and make sure it remains the cheaper, better way to handle the organization's needs. At some point in time, you may find a different method is in fact cheaper. Bottom Line: There are different ways to develop information systems: prototyping, application software packages, end-user development tools, outsourcing. Analyze each and then pick the right tool for the right job.

Lecture - 21 11.3 System-Building Methodologies and Tools

Remember our analogy about building a house? Let's go back to it for a minute. What if you only had a hammer and a screwdriver when you built the house? What if you didn't have any idea of how the finished product would look, but made it up as you went along? Worse, what if you ran out of money halfway through? These things happen all the time. From methods developed in the early 1970s that still apply in the 1990s, to snazzy new development processes, there are many useful tools organizations can use to help them build a new system that will work when it's done.

Structured Methodologies
Just as you use blueprints to build a house, you can use a step-by-step or structured approach to building an Information System. You lay a good, solid foundation first and then build upon that. You construct the walls, then you put the roof on. Once you have the outer structure completed, you can work on the details of the house. So too with an Information System. A structured methodology is oriented toward the actual processes used rather than the data generated. Each step must be completed before the next one is started--just like building a house. These methods all have their shortcomings. In fact, many of them simply aren't flexible enough to be used in designing systems in today's fast-paced world.

Structured Analysis
Structured analysis covers the inputs, the processes, and the outputs, much like the diagram we showed you in Lecture 1. Use data flow diagrams such as Figure 11.6 so you can track how the information enters, how it's processed, and how it comes out.