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.

FIGURE 11.6 Data flow diagram for mail-in registration system.

It's very helpful to use a data flow diagram because people understand pictures much better than a whole lot of text. It also forces you to think the whole process through from beginning to end. You can test the process on paper to see if it's feasible. It doesn't matter whether you are using a structured approach to system development or one of the other types we've discussed in this chapter. If you use process specifications, which define the logic of the lowest-level transformations in the data flow diagram, you can review the details of each process to make sure they flow through the input, process, and output design correctly and efficiently.

Structured Design
Using a structured design makes sure your system is clear and simple. It may not seem so, but you can actually save time, money, and frustration by following the rules and techniques of a structured design. A structure chart like the one shown here will give you a visual picture of the system and help you understand the relationship between each element.

FIGURE 11.7 High-level structure chart for payroll system.

Structured Programming
Creating modular code is one of the best methods of creating easy-to-use and -maintain systems. If you can create a module of code that can be used several different ways, you'll be able to change the code more easily (for maintenance purposes) because it will be the same everywhere. Creating a block of code once, to be used many times, is certainly cheaper and faster than creating it over and over. The idea behind structured programming is that you create one way in and one way out. Doing so reduces the chance for programming error or conflicts in how the data will be processed.

Flowcharts
By using a system flowchart, you can track a piece of data from the beginning to the end just to see if the processes are going to work the way they are supposed to. You use the physical design view rather than the logical design view. Flowcharting is an old design tool that is still in use. It is used for physical design but not for program design because it does not provide top-down modular structure as effectively as other techniques. What it does provide is a method for tracking processes to make sure they all work and to show outside factors that may be necessary in support of the system.

Object-Oriented Software Development

Other methods keep data and processes separate. Object-oriented software development combines the two and treats them as one object. More important, the objects are created once and, if they are done right, can be used many times over. That reduces the cost of creating new objects. It also makes it easier to create new software, because you aren't continually starting from scratch.

Computer Aided Software Engineering (CASE)

Face it: many of the steps we've discussed in the traditional system development approach aren't completed because they are boring and mundane. Who likes writing user documents or coordinating the activities of the development team? These necessary functions often go undone because no one likes doing them. Computer-aided software engineering (CASE) tools automate much of the mundane, repetitious work and can sometimes do a better job of it than a human. CASE tools keep you organized by automatically updating data dictionaries and validating design diagrams and specifications. If you make a change in one diagram, any reference throughout the program will be automatically updated. Nice, huh?

FIGURE 11.11 Using Scitor's Process Charter for Windows to map and simulate business processes in real-time.

The figure shows an example of how CASE tools let you a visualize business processes while you're developing a process to automate them. These tools won't do everything for you, though. You still have to ask the hard questions: Is the system feasible? cost effective? right for our business? integrated with other areas of the organization? And they require organizational discipline. CASE tools enforce common methods and standards.

Rapid Application Development (RAD)

Supply and demand. The supply of technical specialists is not enough to support the demand for new systems, or maintenance of the old ones. Something has to fill the demand - that's why you see so many new methods already on the market and more

advanced, easier-to-use tools coming down the road. The shortage of skilled technicians is also why you see more and more companies moving away from the structured methods we've reviewed in this lecture. There just isn't enough time. Rapid Application Development (RAD) reduces the time it takes to build systems by using many of the tools we've discussed. You can choose from prototyping or fourthgeneration tools to develop systems much more quickly.

Software Reengineering
If you can squeeze just one more year out of that old car, you sigh. That's what a lot of companies think about their old information systems. We've talked about how costly new systems are - hardware, software, and persware. People don't like change. Changing information systems is very disruptive to organizations. Sometimes they choose to fix their old systems rather than build new ones. You're seeing examples of this with the Y2K bug. Many companies are reengineering their software rather than installing new for various reasons. Some find it cheaper, some find it easier, and some just don't have a choice but to fix the old. Software reengineering can be much easier to accomplish if the organization was smart enough to create good documentation when it was built and to change the documentation when the system was changed. Many companies are finding out that wasn't always the case, and now they're paying for it. Lots of good lessons are learned the hard way! If acceptable documentation doesn't exist, reverse engineering can help you determine how the underlying process works and how its structured. Essentially, you start with a functioning system and tear it apart to find out how it works. It's much like tearing down a perfectly good radio to see how the parts fit together. Forward engineering takes the information from the reverse engineering process and creates a new, structured program code for the system. Figure 12.12 can help you understand the reverse and forward engineering process.

FIGURE 11.12 The reengineering process.

Bottom Line: To get the best possible product, you have to have a sound structure and good methods for building your system. This will save time, money, and aspirin.

Discussion Questions:
1. How does the traditional systems lifecycle approach differ from the prototype method of developing systems? 2. What is the advantage of using an application software package? What types of application software packages could you use in your organization? 3. How can you determine if outsourcing is advantageous to your organization? 4. What makes object-oriented software development different from other tools for system development?

Systems Success and Failure: Implementation 12.1 Information System Failure

12.2 Causes of Information System Success and Failure

12.3 Managing Implementation Discussion Questions