Chapter 2 script
Friday, January 08, 2010
4:32 PM
Chapter 2 Notes
 
Slide1:
Welcome to the presentation for chapter 2. This chapter is so full of useful information that it is necessary to use 11 slides instead of the usual ten. The textbook distinguishes between frontend, or customer facing systems, and backend or internal systems. As we saw in the second discussion thread, backend systems such as payroll can be as important as front end systems such as Automated Teller Machine systems. Sometimes part or all of the development and the operation of a backend system may be outsourced. For example, my faculty paychecks are generated by ADP, and I can log onto the ADP server to see my Dominican earning statement. 
 
This is a useful diagram because you can use it to determine into which area a system project falls and this will help you locate existing software to evaluate

Slide 2. 
This second slide is one of my favorite pictures from our textbook, it is figure 2-2, and it shows in general how systems of various types fit together. Here are four specific things you can see from this diagram:
 
1. Management information systems generally operate off a copy of the online transaction database called the operational data store. This guards against management information system retrievals degrading the performance of the transaction processing system. 
2. Decision support systems and Executive information systems operate off of a data warehouse. The data warehouse contains historical data as well as current operational data. You can find entire books at Barnes and Noble or Borders or Amazon.com on designing and loading data warehouses. 
3. Expert systems are driven by knowledge bases. This is where the expert rules are stored. Some expert systems are built without connections to other systems. So the connection to the data warehouse is optional on this diagram. 
4. Work groups such as people who work in a user department can create data using tools such as Microsoft Excel and then use that data in the decision support system. In general, you don’t want data created with tools that don’t have validation built in to be entered into the transaction processing system. This diagram can also be used to help you decide where your systems projects fits within existing systems. 
 
Slide 3
 
The ways that system owners, system users, system designers and systems builders look at business systems are very different. As an analyst it’s your job to understand everyone’s perspective and cause productive communication to occur. The analyst must learn the needs of the system owners; work with the users to develop a system that would meet those needs *see chapters 5-11*. The analysts must also work with system designers to define a workable approach to build the system *see chapters 12 and 13*. The analyst also works with the designer to design the systems *see chapter 14-18*. In some organizations the analysts and designer is the same person. The designer needs a complete understanding of what will be happening during system construction *see chapters 19-20*. 
 
Slide 4
I’ve chosen the following slides because they can help us understand why the communication between owners, users, designers and builders is extremely difficult and how the analyst might work to prevent communication problems. 

 
Look at the wide gap between system owners who want to deal with business rules, and system builders who want to know what tables, keys and indexes to define to the database management system. The analyst must work with the owners and users to bridge this gap. This gives you an idea of the problems that can occur when the owners and programmer attempt to work together without using a systems analyst as a language translator. 
 
Slide 5
 
We’ve just discussed how owners and system implementers view data now let’s move on to processes. Owners are concerned with business functions, 
 
Slide 6
 
whereas users are concerned with policies and procedures and having a process that can respond to events in the business. 
 
Slide 7 
Designers need to specify the processes in terms that can be implemented on one or more computers by the system builders. 
 
Slide 8
 
The system builders must write and test the program code. Notice how disconnected this type of coding and testing is from understanding the major functions of the business. So again, the system owners and system builders are in totally different worlds and it is up to the analyst to act as a translator between those worlds. 
 
Slide 9
 
Another example of the major differences in views between the owners and the builders is in the system communication or interface area. Owners are concerned about which companies and departments will perform the work and in which countries and cities that work will be located. Users are concerned with the inputs and outputs and in what order those will appear on their screens and other devices. 
 
Slide 10 
Designers need to translate the users’ view of the system into the specification that the builders can implement in the selected technical environment. 
 
Slide 11
 
Builders are concerned with constructing the user interface as well as building the connection between system components. If you can find a single person that can speak the owners language, the users language, the designers language and the programmers language then you might have this person work with the owner and go directly to implement the system. This only works for fairly small systems and it requires a person that speaks all the languages that you’ll learn in this course as well as in your programming courses.
 
Recording Break
(Virtual slide 12 - slide 11 still showing)
 
I worked as a one person team at one of my current clients and it is fun to do everything yourself. After the presentation you just watched, you may wonder under what conditions one person can do the entire job. Here are the conditions.
 
1. The business problem was pretty simple-It was just a matter of meeting some sales and operations requirements using a system that already existed. 
2. The things that needed to be built could be built in the current technical environment-no new hardware or software was required.
3. The users were able to clearly communicate their requirements,
4. The system was small enough to build in a few months with a single person.
5. I worked in the past as an analyst, designer, builder and a project manager and therefore was comfortable with all the languages required by the project.
 
If these conditions aren’t met, then you need to use the approaches and methodologies that you will learn in this class rather than just “building it”. Meaning that, if these simplifying conditions don’t exist, you need to use the more complicated approach that uses a team that uses analysts, designers and system builders. 
 
This concludes the summary of Chapter 2