1

Introduction to the Course

Welcome to the course Management Information Systems II, the finalcomputer course in the B.Sc. Management Studies Degree programme.

At this stage in your studies, you would have taken one or more coursesthat introduced you to Management Information Systems (MIS). The focusof this course is on the analysis and design of computer-based informationsystems. An introduction to this topic has been covered in your previouscourses. This course builds on your current knowledge through exposingyou more deeply to the methodologies, tools and techniques of systemsanalysis. Examples of these include the process- and object-orientedapproaches to systems development, computer-aided software engineering(CASE), data flow diagrams and conceptual data modeling. As you progressthrough this course, you will develop competence not just in the theorybehind these methodologies, tools, and techniques; you will also becomecompetent in actually using them on systems development projects andin solving managerial problems that you may encounter on your job.

Here is some advice that will help you to get the most value out of thiscourse. You should:

1. Read quickly through each unit once to get a sense of what it covers.

2. Read the unit once again, but this time reading more slowly to developa full understanding of the material.

3. Try to develop a thorough understanding of the material. Manystudents place emphasis on recalling facts, figures, diagrams, etc. Yourgrade will mostly reflect your understanding of the material and, to alesser degree, your recollection of facts. The emphasis in this course ison your understanding and application of the methodologies, tools,and techniques of systems analysis.

4. Attempt the end-of-session exercises and problems provided.

5. Work in teams or groups as far as is possible to discuss your solutionsto the exercises, problems, and mini-cases in the text.

2

6. Seek clarification of things you are uncertain of or are unclear about asyou read the material. Your local tutor or course coordinator is availableto assist you. You are strongly urged to not wait until near examinations.At examination time everyone gets busier, including your tutor andcourse coordinator as they mark scripts or prepare examination papers,and so on.

We will now discuss the goals and objectives of the course. Followingthis discussion, this introduction ends with a discussion of assignments,examinations and grading in this course.

Course Goals and Objectives

This course seeks to have students develop competence in applying themethodologies, techniques, and tools of systems analysis and design in:

1. The development of information systems

2. The development of solutions to managerial problems

You may be wondering what precisely is meant by the terms“methodologies”, “techniques”, and “tools”. In the same way that acarpenter requires certain things to do his or her work, and in the sameway that he or she has a certain way of going about the job, the samething applies to the person who builds information systems.

You should note that you are required to learn how to apply thesemethodologies, tools, and techniques in two main settings: in developinginformation systems solutions and generally, in developing solutions tocommon managerial problems. Why these two solution domains?

The first, information systems problems, need no explanation as this is themain reason why people would generally want to learn about systemsanalysis and design. The second, general managerial problems, is therebecause systems analysis should be viewed as a problem identification andsolution discipline. As such, the methodologies, tools, and techniques canbe applied to any type of problem. Beyond this reason, there is a generalexpectation that many, if not most, students who take this course will notwork directly in the information systems area. However, the knowledgegained from this course is still profoundly useful if viewed from theperspective of a general problem solving methodology.

To end this section, a few examples of some of the things you shouldensure that you become comfortable with over the next 12 weeks,include:

3

• Process-oriented systems development

• Object-oriented systems development

• Systems thinking

• Data flow diagram (DFD)

• Decision tables

• Gantt and PERT charts

• Conceptual data modeling

Assignments, Examination and Grading

One major project will be given in this course. This project will be anindividual assignment. Your course coordinator will, in due course,announce the mark for this project. There will be no need to build anactual information system as a solution to the problem. However, theproject should demonstrate a thorough understanding and application ofthe methodologies, tools, and techniques covered in the course. A fulldescription of the project requirements will be provided for you.

The course project will be graded by your Course Coordinator. You areadvised to make and keep a copy of your project before submitting itto your local Distance Centre. The final examination will be marked andgraded by the Course Coordinator.

4

5

Unit 1Unit 1The Work Environment of theSystems Analyst

Overview

In this Unit, we attempt to answer the following main questions:

1. Who is a systems analyst? What does he or she do?

2. What is the nature of the environment in which the systems analystworks?

3. What makes the job a challenging one?

4. What special skills and education does the analyst require?

In addition, we introduce you to data flow diagrams, specifically the contextdiagram.

The Unit is divided into three sessions and five major topic areas. In thefirst topic area, we discuss the work of the systems analyst and variousroles that he or she may be expected to play in a systems developmentproject. The second topic area reintroduces you to systems thinking, aconcept you met in an earlier course. In the third topic area we brieflytouch on the education and special skills expected of the analyst. In thefourth area, we discuss some challenges of developing informationsystems, and the final topic is an introduction to the context diagram.

6

Unit Objectives

At the end of this Unit, you should be able to:

1. Define the terms systems analysis and systems design

2. Explain what is systems thinking and its importance to generalproblem solving

3. Describe some of the multiple roles that the systems analyst may playin systems development

4. Discuss some of the educational and skills requirements of systemsanalysts

5. Identify and discuss some of the challenges of designing and buildinginformation systems

6. Explain what is a data flow diagram is

7. Draw the DFD symbols

8. Explain what is a context diagram

9. Draw the context diagram

7

Session 1.1The Systems Analyst and Systems Thinking

Learning Objectives

At the end of this Session, you should be able to:

1. Define the terms systems analysis and systems design

2. Explain what is systems thinking and its importance to generalproblem solving

3. Describe some of the multiple roles that the systems analyst may playin systems development

What Does a Systems Analyst Do?

Supposing your friend asked you this question, “Who is a systems analyst?”What would you tell him or her? Quite likely, many people would answerby saying something along the line that a systems analyst is someone whobuilds information systems. Other persons might even add that the systemsanalyst is someone who also designs information systems. Well, you arenot wrong if that is what you said. You will discover, however, that thereare many variations on this answer. There are several other views as towhat the job of the systems analyst is.

Let us examine the possible answers given above. A systems analyst issomeone who designs and builds information systems. Hmmmmm, well,well. Several questions come to mind when we think about the definitiongiven above of the systems analyst. What do we mean by “builds”? Do wemean that the analyst writes the computer programme code? How doesthe analyst know what users want from a new information system? Shouldthe analyst tell the users what is best for them? Or is it left up to the userto just give instructions to the analyst as to what he or she requires? Thepossible answers to these questions should become clear to you by the endof this section.

Before we discuss more fully some alternative views on the work of theanalyst, we will provide a definition of what is systems analysis and design.

8

Systems Analysis and Design

Systems analysis and design is a structured process in which the systemsanalyst derives innovative (or creative) ways of using information technologyto better manage information for the organization’s objectives.

Let’s take a minute to examine the key terms in this definition.

Structured process: by structured we mean that the sequence of steps in asystems analysis and design project can be specified in advance of theproject. An analyst therefore knows precisely what must be done indesigning and building an information system. Contrast “structuredness”with its opposite: “unstructuredness” implies chaos.

Innovative: a main reason why companies build new information systems isto raise their level of competitiveness in the market. Clearly, it is difficultto achieve competitive advantage if you are doing the same thing thatothers in your industry are doing. The analyst therefore needs to come upwith very creative ways of meeting the information needs of theorganization. Several examples of strategic information systems abound inthe literature. You would have read about some of these systems in anearlier course.

Information technology: the analyst is attempting to find new ways to useinformation technology (IT) in the business. While most solutions tobusiness problems or opportunities will involve information technology,there is no absolute reason that the analyst has to recommend a solutionthat entails IT. For example, in the Caribbean context where smallbusinesses and itinerant traders dominate, many of these operations cando well if they merely put in place improved manual information systems.

Information: this can be regarded as the most critical part of the definition.Primarily, the analyst’s job is one of helping the organization to bettermanage its information resources. We live in what is referred to as the“Information Era”, similar to the earlier Industrial Era. Information is allaround us in our everyday lives. Information abounds in businesses of allsizes. The analyst’s job is to find ways of ensuring that the organizationmakes the best use of the information at its disposal in meeting the needsof the company or, where necessary, in providing new information toassist the business.

9

ACTIVITY 1.1

Go online the Internet. Try to locate some employment advertisements forpositions as systems analysts. Compare the stated job requirements in theseadvertisements to the definition of systems analysis given above. Discusswith your colleagues in the tutorial session any differences you found.

Roles of the Systems Analyst

The roles define various types of functional responsibilities that may beexpected of the analyst in his or her job. The expectations of the analystwill vary depending on the work environment. While it is unlikely that ananalyst will be required to portray all of the roles described here, the mostlikely situation, however, is that the analyst will have to fit into two ormore roles quite comfortably in most organizations. Several possible rolescould be defined beyond those mentioned here. As you read these roledescriptions, ask yourself what is the importance of identifying roles inany setting? Why should the analyst be concerned about this? The firstfour roles we will outline are based on Yourdon (1989).

Archaeologist and scribe. Much like how the archaeologist digs for things,the analyst is expected to uncover or unearth detail about things such ashow systems work. He is also expected to document business policy. Thisis more difficult than it sounds, partly due to the fact that in mostorganizations much of the business policy is unwritten. Even where policyis written it will often deviate from the policy expressed in action.

Innovator. This is certainly a very critical role that any good analyst shouldplay. In this capacity the analyst must help the user explore newapplications of information technology. All organizations may be using thesame basic software, but the question is, can you help the organizationfind really creative ways of using the software and so differentiate yourcompany in the market? The changing business environment neccessitatesnew or modified information systems. The analyst needs a great deal ofcreativity to fulfill this role.

Critical Thinking Activity

Is creativity something that can be learnt? If so, how is this accomplished? Or, iscreativity a characteristic that you are born with? What do you think? Discuss inyour tutorial session the implications of whatever position you adopt for careers insystems analysis.

10

Mediator: Systems analysis is a challenging job. The analyst has to workwith employees in various capacities and at varying levels of theorganization. These employees include users who may occupy any positionin the organization hierarchy. The analyst also works closely withmanagers. There are also IS professionals such as programmers, databasedesigners, network analysts, and others, with whom the analyst willinterface in his or her duties. Apart from having their own personalities,each of these groups of employees will have their own priorities, and thesepriorities will often conflict with each other. For example, managers haveto find the funds to pay for the new system. They may be concerned aboutminimizing expenditure and so will try to allocate as little as possible toget a functional system, perhaps just a system that meets the bare minimumset of features. Users, on the other hand, have a tendency to want all thelatest fanciful features, all the “bells and whistles.” Clearly, the objectivesof users and managers may conflict. The analyst, if he or she is to developa successful system, will have to bring about some consensus betweenthese two groups within the organization.

Project leader. Systems analysis projects are most often done in teamsconsisting of several employees, including systems analysts, programmers,and database developers. Someone has to manage the team. Typically, asenior systems analyst will lead the systems development effort. There arealso several times when a user will be in charge of the project team. Wealso encounter occasions where both a systems analyst and a user are putin charge of the development effort, a sort of “co-project manager”situation.

Computer expert (Alter, date unknown). One suspects that this may be thedominant view as to who or what the systems analyst is. In this role thesystems analyst takes clearcut specifications of the new system andtranslates these into computer code. This means that it is up to users tostate quite clearly what functionalities they want in new informationsystems. This view of the systems analyst is starkly different from someof the other roles expressed in this section.

Builder (Alter, date unknown). Here, the systems analyst is perceived assomeone who elicits information requirements from users. He or she thenwrites computer programmes to meet the information requirement asobtained from the users.

Architect (Alter, date unknown). This role portrays the analyst in a “helping”role. The analyst helps users to define what information they require froma new system. The analyst will then create new ideas for informationsystems and, further, help the users evaluate these ideas.

11

ACTIVITY 1.2

Think carefully about each of the above role expectations of the systemsanalyst. How will the education requirement vary, if at all, according to therole expected of the analyst? Which role would you find most challenging?Why?

Systems Concept and Systems Thinking

By this time in your studies, you would have met the “systems” conceptseveral times. Hence, some of the material here will be familiar to you.Systems thinking can be regarded as one of the most influential andcritical concepts to have been put forward in the research and academicliterature. Many people may nod in agreement when the concept ofsystems thinking and its applicability to everyday life are discussed;however, few people really put the concept into action in real life.Let us start by presenting a definition of system:

A system is “a set of related components that work together in a particularenvironment to perform whatever functions are required to achieve thesystem’s objective.” (Dewitz, 1996).

To help in illustrating these concepts, we tell the following story.

Mr. Brown owns a coffee factory in Mount View. Coffee berries are reaped twiceeach year by neighbouring farmers, who sell the berries to the factory. The berriesare washed in a large water tank. They are put to dry outdoor in the sun. Thedried berries are roasted, grounded, then packed before being shipped from thefactory. The water from the berry tank is emptied into a river that runs besidesthe coffee factory. The river flows several miles through the valley, before exitinginto the Caribbean Sea. During the 30 or more years since the factory has beenin operation, there has been a steady decline in the river’s population of fish,shrimp and crab. The adjoining beach near where the river exits into the sea hasseen a steady decline in the number of visitors using the beach. Mr. Browndisagrees with those who argue that it is the coffee factory that has led to theseproblems. He argues that the people have over-fished the river, and that thebeach problem is caused by the high entrance fees charged by the propertymanagement.

Without detailed and careful study by the responsible authorities, it is hardto say conclusively who is right and who is wrong. However, we all can seethat there is a close conection (certainly physically) between the coffeefactory, the river, and the sea into which runs the river. We can easilyimagine a connected whole. This is the essence of systems thinking. Toquote Peter M. Senge (1990):

12

“Systems thinking is a discipline for seeing wholes. It is a framework for seeing

interrelationships rather than things, for seeing patterns of change rather than

static ‘snapshots’. (p. 68)

Systems thinking has a number of concepts, principles, tools, andtechniques. One of the most important principles of systems thinking isfeedback. It is partly because of feedback that the interrelationships are soall-embracing in the systems field.

Most people would probably recognize the interrelationships in the examplegiven above of the coffee factory. These interrelationships include the onesbetween the factory, the river, the community, and the sea. There areseveral examples which could be given where people would not easilyrecognize the existence of interrelationships. Using systems thinking, wecan argue that any event, no matter how insignificant, in any part of theworld, has an effect on the rest of the world. The effect may be moredramatic in one corner of the earth and perhaps almost unnoticeableelsewhere.

ACTIVITY 1.3

Take a sheet of paper and list on one side some of the factors that you canthink of which might influence business performance. On the other side ofthe paper write “business performance“. Draw directional lines to show theeffect of each factor on business performance. Now think carefully aboutwhat you have done so far. Can you see the reverse influence of “businessperformance” on each factor? If so, draw a directional line going from“business performance” back to each factor. Finally, you should also be ableto see relationships among each of the factors themselves.

FeedbackLet’s assume that one of the factors you listed was “crime.” Now, many of usmight argue that it is government’s responsibility to control crime. Even if thisis so, however, a full understanding of the diagram should show that we cannotrationally argue that business performance depends solely on the governmentand its control of crime. (Assume that this was the only factor influencingbusiness performance.) The feedback from “business performance” to crimeshows that businesses themselves, through their performance, will influencecrime, which will feed back into business performance. Hence, when businessesperform poorly it is never due only to government policies, but also to the actionsof the businesses themselves. Systems thinking should stop us from alwaysseeing the enemy as being someone else, out there, somewhere. The enemy isalso within.

13

We will continue with systems thinking by introducing a topic that isimportant to the systems analyst. Information systems success is an issuethat concerns systems analysts and indeed all IS professionals. How canthe systems analyst try to ensure that the information system that isdesigned and built is a success? First, we need to define what is systemsuccess.

Information System Success

Information system success has been widely studied by academics andresearchers. Several measures of system success have been put forward inthe literature, among them (Laudon and Laudon, 1998):

• Levels of system usage. This is the extent of usage (for example, numberof hours used per week) of an information system. This is particularlyrelevant for systems where use is optional. It is a very interesting issue as towhat makes people use an information system when they could get bywithout using it.

Critical Thinking Activity

What are some of the reasons you can identify that you think would leademployees to use an information system in a case where use of the system isoptional?

• User satisfaction with the system. This has been a popular measure ofinformation system success in the IS research literature. To what extent areusers satisfied with the information system? User satisfaction can bemeasured along several dimensions such as satisfaction with user interface,information output, speed of system, ease of use, and so on. We may thinkof these dimensions as a measure of the quality of an information system.

• Extent to which the system met its objectives. Prior to building aninformation system, management should specify clear objectives as to whatthey expect to achieve from the system. Ideally, these objectives should bemeasurable and stated in precise terms. For example, one objective mightbe a decrease in the average customer wait period from five minutes tothree minutes. After the system is made operational this objective can beassessed precisely to see whether it has been met. Other objectives mightentail a general improved organizational performance (for example,reduced customer complaints, larger market share), and better decisionmaking.

14

• Financial payoff to the organization. Examples of financial payoff measuresinclude reduced costs, increased sales, and increased profits.

We have addressed one side of our problem, the measure of IS success.The next issue is to answer the question of what factors influence systemssuccess. Again, several factors have been presented in the literature. Briefly,we mention these (Laudon and Laudon, 1998):

• User involvement and influence. User involvement is the extent ofparticipation of users in the systems development process. IS professionalscan very cleverly consult users about their opinion on several issues duringthe systems development project. At the end of the day, however, it mightstill be the case that users’ views are given very minimal or no considerationin the decision making process. Hence, some people have argued that whatmatters is not so much involvement and participation but, moreso,influence. In fact, at least one study has shown that what matters is userinfluence and not the participation so much. When users have influenceover the systems development process they come away feeling a greatersense of satisfaction in the process. They see the system as their system andso they become much more likely to use the system.

• Management support. Management support includes not just financialsupport, but even more critically the extent of management’s belief in thesystem, the extent to which they see the system as being critical to theorganization. Does management allow staff time away from normal dutiesto participate in the systems development effort? Does management“champion” the system, virtually preaching to the organization thebenefits of having this new system? Generally, how supportive ismanagement overall of the systems development project?

• Project management skills. Managing a large systems developmentproject with several professionals who are often divided into several teamscan be a most challenging task. This is where good project managementskills come into sharp focus. If the project manager is unable to keep theproject on time and within budget while also delivering a truly greatsystem, then project and system failure looms large on the horizon.

• Level of complexity of the system. There are several measures ofcomplexity, including the number of variables in the system, the size, andother things. We all know how difficult it is to deal with complexity.Interestingly, though, we note that systems thinking is a principle andphilosophy designed expressly to deal with complexity. The point that isbeing made here, however, is that the more complex a system, the lesschance there is that the delivered system will be successful.

15

ACTIVITY 1.4

Using the factors discussed above, create a causal diagram to show theinter-relationships among the factors influencing system success and systemsuccess itself. Put “system success” on one side of your diagram, and placethe causal factors on the other side. Try to explain all the reverse links fromsystem success to each of the factors influencing system success.

Discuss your efforts in your tutorial session.

The Significance of Systems Thinking

Having spent all this time on systems thinking, we need to ask why is anunderstanding and appreciation of this concept of fundamentalsignificance to the systems analyst.

All systems are made of components or sub-systems. Depending on whatissue is being studied, any one or a set of the components of a system canbe regarded as a system. Further, looking at things at a higher level ofaggregation, the focal system itself is always a part of a larger system. Toillustrate our argument, hardware, software, data, programme, users, andprocedures make up an information system. A collection of the hardwareis a system or sub-system within the larger information system. Theinformation system itself is a part of a larger system known as theorganization. Based on this principle of system, two things arise.

The first thing is that since systems can always be broken down intosmaller systems, this suggests that an easier way to design and buildinformation systems is to break them down into smaller systems and workon each piece as a sub-project. Breaking down the system reduces thecomplexity of building information systems. The second thing is that sinceany system is always part of a larger system, this makes it conceptuallydifficult to decide where to draw the boundary of an information system(Yourdon, 1989). To define the boundary of a planned new informationsystem is to establish the scope of the project. Users, analysts, andmanagement have to agree on the project scope before working on thesystem. Failure to achieve this agreement on scope reduces the chance ofhaving a successful new information system.

Systems principles also suggest that in designing information systems, theanalyst should carefully consider how the information system willinterface with, and work with other systems that make up the organization.Some of these other systems include user departments such as marketingand finance, as well as culture, which is part of the organization. What

16

impact will these systems have on the information system? Is the culturalsystem one that regards computers as toys or just some artifact to decoratean office? If this is so, then new information systems may go largelyunused by the people for whom they were intended.

17

Session 1.2More on the Systems Analyst:Skills, Education, and Challenges

Learning Objectives

At the end of this Session, you should be able to:

1. Discuss some of the educational and skills requirements of systemsanalysts

2. Identify and discuss some of the challenges of designing and buildinginformation systems

Systems Analysts: Skills and Education

It is difficult to specify a list of invariant skills that the systems analyst shouldpossess. Given what we said earlier about the various role expectations ofthe systems analyst, it should be clear that the skills and education requiredof the analyst will depend mostly on the work environment in which theanalyst finds himself or herself. One organization may have an entirelydifferent expectation about the job role and responsibilities of the analystthan another organization. In spite of this caution, we will attempt tohighlight some specific skills that the analyst should strive to obtain. Thissection draws partly on Alter (date unknown).

• Technical skills. The analyst should be competent in the whole area ofcomputers and their usage. He or she should know at least one programminglanguage. Possession of programming skills helps the analyst to visualizehow an information system can help the organization. Programming skillshelp the analyst to know what is possible with information systems. Weshould note, though, that as technology advances at near lighteningspeeds there are very few things which cannot be done with IS these days.

• Knowledge of business processes. Systems analysis is all about designingand building information systems that will integrate with a company’sbusiness processes and people in delivering quality products and servicesto customers. It is critical, therefore, that the analyst has a thoroughunderstanding of business processes and specific aspects such as definingand reengineering business processes. A well-known technique used byanalysts in charting business processes is the data flow diagram (DFD)technique. This will be covered quite extensively in a later unit. While the

18

analyst should have knowledge of business processes in general, he or sheshould also know about the business processes in the organization towhich he or she is employed, and also about business processes in theparticular industry. Keeping abreast of developments in the operations ofother players in the industry helps the analyst to derive creative ideas forusing information technology in his or her own organization.

• Knowledge of accounting. Historically, early information systems werealmost exclusively accounting systems. Although the dominance ofaccounting systems is much reduced these days, the fact still is that a largenumber of information systems are integrated with or interface closelywith accounting systems. This is even more so currently with the trendtowards enterpise-wide information systems and systems linking theinternal value and external value chains.

• Competence in information display techniques. The analyst has a varietyof options available to display output of an information system. Availableoptions include text, tables, graphical output such as charts, and voice.Studies show that people have individual preferences for the type ofoutput used. Further, these preferences may vary depending on the type ofdata and the purposes for which the information is required. The analystshould be knowledgeable of the wide range of display techniques available,and when each technique may prove acceptable and useful.

• Competence in information gathering techniques. One of the critical phasesof a systems analysis and design study is finding out the information thatusers require in the new information systems. In defining this informationrequirement the analyst has to obtain data from users and management,and also has to examine business documents. A wide variety of techniques,including the use of interviews and questionnaires, can be used to obtaindata from users and management. The analyst should know how toorganize and conduct an interview as well as how to produce goodquestionnaires. Clearly, the analyst will often times be unable to obtaindata from all possible sources in the organization. This is where aknowledge of sampling becomes critical.

• Good analytical skills. This should almost go without saying. To analyzesomething, according to Webster’s New World Dictionary is to “separate ...into its parts so as to find out their nature, proportion, function, inter-relationship, etc.” Although not often mentioned, synthesis is also animportant skill for the systems analyst. In fact, from a systems thinkingperspective, synthesis might even be a far more critical skill than analysis.You may have heard the phrase “the whole is greater than the sum of theparts put together”. Think about this.

19

• Good communicator – both oral and written. In a systems analysis project,the analyst has to produce written reports for management. These reportsoften come at especially critical times in the life of a project such as at theend of each major phase – analysis, design, and coding and implementation.These reports form a part of what is referred to as the deliverables of asystems study. Management will make its decision as to whether to continueor terminate a project largely on these reports. The analyst has to give anoral presentation to management summarizing his or her findings andmaking recommendations about the project. The analyst should thereforehave good communication skills. Perhaps even more critically, the analysthas to interface with users, other analysts, and other IS personnel in thesystems project. He or she should have excellent speaking and listeningskills so that communication problems are minimized.

• Ability to work in teams. Most information systems projects are done byteams. The systems analyst must therefore be comfortable working along-side others. We will not elaborate further on this point at this time; sufficeit to say, however, that anyone who has ever done a group project for acollege course can attest to how difficult it often is for people to worktogether.

• Ability to manage teams. Most systems analysts will have to lead andmanage the systems development effort at some point in their careers.Effective management of the project team is critical to realizing asuccessful project. Project management is an entirely separate profession inits own right. It is probably no wonder that so many IS projects run lateand/or over budget. After all, we may be asking people who are not trainedas professional project managers to manage very large projects. Projectmanagement is an equally, if not more challenging, profession.

The Challenges of Developing Information Systems

Let’s start this section off with a tale that should sound familiar to most ofyou.

A few years ago a certain country in the Caribbean decided that it had hadenough voter malpractice in its political elections. The administrative bodyin charge of electoral reform recommended an automated system thatwould check and match finger prints so that nobody would be able to votemore than once in an election. After millions of US dollars were spent, theproject turned out to be a failure, as the company that was awarded thecontract was unable to deliver a working system that met the specifications.Politicians and the general public pointed fingers at the government, eachother, and the contractor for the failure.

20

As hard as it is to waste millions of dollars on any project (especially inour part of the world), the reality is that, on a probability basis, the projectoutcome was nothing more than what should have been expected.Information systems experts may disagree on the numbers, but a very highproportion of new information systems can be regarded as failures –either they are delivered beyond the budget, they are late, the deliveredfunctionalities do not meet the requirements specified, or the systems aredelivered with faulty programme code. The latter is in fact true for justabout all systems.

As bad as things may seem these days, we have come a very far way inbuilding better systems. This has been achieved partly due to new ways ofapproaching systems development, such as the structured analysis anddesign philosophy. Even with the use of this structured approach, thereare many factors that make it a real challenge to design, build and deliversystems of high quality. It is because of the challenges that systemsanalysis and design is such a rewarding career. Systems people feel a greatsense of pride and accomplishment when they finally deliver a system thatmeets the organization’s needs. Systems analysts, programmers and otherIS personnel work very long hours and in environments where to anoutsider, things can look so chaotic. Many times it is indeed chaotic.People who work in the computer field tend to have a sort of introvertedpersonality. They often prefer to interact with machines rather than withpeople. Typically, when they interact with users they feel that users do notreally know what they want. Hence, to the systems analyst, interactingwith people and trying to elicit the information requirements for a newsystem is one of the greatest challenges, and perhaps the one that theyenjoy least. The challenge of trying to accomplish the never-been-done-before system, perhaps using new and innovative tools, is the dream ofmost IS professionals.

Well, we hope so far we have painted a picture of what the analyst’sworking environment is like. However, there are a number of other issuesthat present challenges to the analyst, which are worthy of mention.

• Defining the scope of the project. The scope of a project tells what isincluded in the project. What areas of the business will the project touchon? What departments will be affected? Which functions will be includedin the system? Part of the reason for the difficulty in defining project scopewas discussed earlier in this unit when we covered systems principles.Review the relevant section of the unit if you find that you do not recallthe reason. We also need to realize that with three groups of peopleinvolved in any systems project – analysts, users, and management – it isimportant that both the users and management agree quite clearly on theproject scope prior to the start of the project. The analyst has to ensure

21

that he or she understands the scope. It is also the analyst’s responsibility topoint out the advantages and disadvantages of placing the boundary of thesystem (scope) in one place as against another. What systems will interfacewith the system for any given, agreed scope? It could take forever for users,management and analysts to agree on this, but we know time is limited.The important point to observe here is that there are tradeoffs involved indefining a project’s scope.

• Many computer-based information systems are really big systems. The sizeof many systems is measured by the millions of lines of computer code.The bigger the system, the longer the systems development effort will goon. Bigger systems may involve much larger numbers of systems analysts,programmers, database developers, and other IS personnel. Controlling,managing, and monitoring the work of several teams of people on an ISproject can be a difficult task. Further, bigger systems take longer to complete.Keeping team members focused on the tasks becomes that much moredifficult over long time periods. There are ways to get around this difficultyof keeping the team focused. One such way is to rotate staff and placethem in different areas of the project over time. But you know the oldmaxim, to every solution there is another problem.

Think about it: What potential problems can job rotation lead to?

• Extended project duration increases the chance that some team members willbe lost. Over time, some project members will resign or others may betransferred to work on other systems projects. Team members take valuableknowledge and experience with them when they leave the organization orthe project. Newly recruited team members need time to get ‘up to speed’as well as time to fully ‘mesh’ with the other team members. During thisintervening period valuable production time is lost.

• The longer it takes to build a new system, the greater the chance that “objectivesand functions creep” will occur. Over time, users’ needs may change, or usersmay keep asking for additional functions. One problem with this occuringis that it may prolong even further the systems development effort. It is nowonder that system requirements are sometimes frozen after the initialcontact with users during the systems analysis phase. Here again, however,freezing requirements may be counter productive – users may have agenuine need for requesting a change in features and functionality. Howmany times have you bought something, only to go home and then decideyou don’t want this item, but the other one? Change is a natural part ofliving.

22

• The longer it takes to deliver a system, the greater the chance that managementwill lose interest and commitment in the project. Imagine you’re hidden away(yes, systems folks like to work away from other people) in some corner ofthe organization for several months, with nothing tangible delivered tomanagement or users. Why should management pay you too much moreattention? Why is it taking so long for the experts to deliver a simple system?One way to minimize this risk of management (and users) losing interestin the project is to deliver the system in increments. Some IS expertsrecommend that some part or module of the system should be deliveredwithin six months after project initiation.

• Technology changes rapidly. What was perceived as state-of-the-arttechnology when the project was started will hardly likely be perceived assuch as the project drags on. Newer technology may solve the systemsproblems far better. However, many IS establishments are wary of usingnew and untried technology in their production environments. Further,changing technology mid-stream has other challenges. For example, workmay have to be stopped to allow team members to learn the newtechnology. Nevertheless, the use of new technology could also bringunparalleled advantages to the early adopters.

• New information systems must be integrated with existing informationsystems. Especially in the case of legacy systems, this is often verychallenging. In the United States, a project was started in 1994 to build anew system for Medicare insurance claims. Three years later, this projectwas abandoned, and this occurred after the expenditure of US$100 million.One difficulty cited in the project was the requirement to understand andthen integrate 72 separate systems operated by different insurancecompanies in order to get this new system to work.

• Recruiting good IS staff is very difficult in many parts of the world. This isdue to the critical shortage of “hot” skills, those skills in most demand. Ateach point in time there is usually some product that is the craze of the ISworld, for example, Java and ERP. It takes time to build knowledge in thesenewly emerging areas. Even after the technology has been around for awhile, shortage of skilled and experienced people may persist. People withthe talent will often extract high fees for their skills. (After all, this is allabout demand and supply, right?)

These are just a few of the many challenges which make it difficult todesign, build and deliver successful information systems. Are there othersthat you can think of? You should try to ensure that you understand howeach of these challenges mitigates against system success.

23

Learning Objectives

At the end of this Session, you should be able to:

1. Explain what a data flow diagram is

2. Draw the DFD symbols

3. Explain what is a context diagram

4. Draw the context diagram

One of the most important and most widely used tools of the systems analystis the data flow diagram (DFD). This session introduces you to this tool. Ina later unit we will come back to the data flow diagram in greater detail.

The Data Flow Diagram

A data flow diagram is a graphical representation of a (computer) informationsystem. That is to say that we use data flow diagrams to show the elementsof information systems – inputs, outputs, systems boundary, theenvironment, subsystems (or components), and inter-relationships. It iscalled a data flow diagram primarily to remind us that as systems analysts,our primary objective is to help the organization to better manageinformation (data). Hence, we need to focus on how data movethroughout the organization.

DFDs show:

• How data flow in a system

• Where data are transformed by a system (that is, changed or processed)

• Where data are stored by a system (that is, kept for later retrieval)

In drawing the DFD we begin with a general, overall or high-level view ofthe system. This is the context diagram, so known because it places thesystem in the context of the environment. The context diagram shows therelationship of the system to its environment. It answers the critical

Session 1.3Introducing Data Flow Diagrams

24

question, what external entities (people, departments, organizations,computer systems, and so on) does our organization interact with? That is,it shows us the boundary and system environment.

DFD Symbols

The data flow diagram symbols are shown in Figure 1.1 below. The symbolsare briefly described here.

Figure 1.1 • DFD Symbols

• The process (or data transform) symbol: shows where data is changedor processed. Transforms are usually described starting with an actionverb, for example, words such as prepare, get, print, edit, display.

• The data store symbol: shows where data comes to a rest.

• External entity (source or sink): this provides data to the system. And/orreceives data from the system

• Data flow: shown by an arrow. Note that the data flows are labelled.

25

Drawing Context Diagrams

Rules for Drawing Context Diagrams

1. Draw ONE process symbol to represent the entire system that youare studying.

2. Imagine yourself to be the person who does all the work in this onesystem.

3. Identify all people, departments, computer systems (that is, allexternal entities) which provide data to your system or to whichyou send data.

4. For each entity, identify the data it provides to you and the datayou provide to it (data flows).

5. Complete the diagram by drawing and labeling all external entitiesand data flows.

6. DO NOT show any interactions, exchanges or data flows betweenexternal entities. You cannot “see” this happening. What youcannot “see” (from your perspective as part of the system) shouldnot be shown on the context diagram.

Two Examples of Context Diagrams

In this section we will present two examples of context diagrams. Beforewe do this however, please try this activity.

ACTIVITY 1.5

Following the rules above, attempt to draw a context diagram to representthe University in relationship to its environment.

FeedbackOne possible representation of the context diagram of the University system isshown in Figure 1.2.

26

Figure 1.2 • Context Diagram of the University System

Here is a second example of a context diagram; it shows the University’sStudent Registration System (SRS). This is shown as Figure 1.3.

Figure 1.3 • Context Diagram of the SRS

There are three external entities in this representation of the StudentRegistration System – the Bursary, Academic Department, and Student. Theacademic department sends a list of courses being offered each semesterto the registration system. At the end of the registration, a list of studentsenrolled in each course offered is sent to the academic department. The

27

student makes a request to be registered in a number of courses. Before thestudent can be registered he or she has to show proof of having paid his orher fees. The bursary, as modelled here, also sends fee status informationto the registration system. The student receives confirmation as to thecourses for which he or she is registered.

If you examine the context diagram examples you will note that the emphasisis on the information being conveyed, not the physical form itself. Hence, thedata flow from student is labeled “fee status”, and not payment slip whichemphasizes the physical form.

This brings us to the distinction between the logical and the physical system.A logical description of a system portrays the purpose and function of the systemwithout tying the description to any specific physical implementation. Thephysical system description is a material depiction of the system; forexample, it will tell us that data are stored in a cabinet or on computertape, and so on.

ACTIVITY 1.6

1. Read the following description of the check-out process at Bookshop:

The customer browses the aisle, selects his book(s), then stands in line atthe check-out counter. The cashier takes the book(s) from the customer,reads the price from the cover, then key punches the price into the POSterminal. If the price is missing the cashier summons the clerk from theWarehouse Department to check the price. Invariably, the Warehouse clerkwill check with the Accounting Department to verify the price of the book.Once the price is verified the cashier proceeds to key punch the price. Thecustomer tenders payment in cash, cheque or by credit card once he is toldthe total owed. After payment is made, the books are handed to thecustomer. If the customer had brought a bag into the Bookshop, he willcollect it from the Baggage Storage Unit before leaving the building.

Draw the context diagram of the check-out process. (Hint: draw the diagramfrom the perspective of the cashier.)

Do only the context diagram for the next two examples. (Taken from Hofferet al. 1999.)

2. Starting with a context diagram, draw as many nested DFDs as youconsider necessary to represent all details of the employee hiring systemdescribed in the following narrative. You must draw at least a context anda level-0 diagram. In drawing these diagrams, if you discover that thenarrative is incomplete, make up reasonable explanations to complete thestory. Supply these extra explanations along with the diagrams. Here is thenarrative:

28

Projects, Inc. is an engineering firm with approximately 500 engineers ofdifferent types. The company keeps records on all employees, their skills,projects assigned, and departments worked in. New employees are hired bythe personnel manager based on data in an application form and evaluationscollected from other managers who interview the job candidates. Prospectiveemployees may apply at any time. Engineering managers notify thepersonnel manager when a job opens and list the characteristics necessaryto be eligible for the job. The personnel manager compares the qualificationsof the available pool of applicants with the characteristics of an open job,then schedules interviews between the manager in charge of the openposition and the three best candidates from the pool. After receivingevaluations on each interview from the manager, the personnel managermakes the hiring decision based upon the evaluations and applications ofthe candidates and the characteristics of the job, and then notifies theinterviewees and the manager about the decision. Applications of rejectedapplicants are retained for one year, after which time the application ispurged. When hired, a new engineer completes a nondisclosure agreement,which is filed with other information about the employee.

3. Develop a context diagram and level-0 diagram for the hospitalpharmacy system described in the following narrative. If you discover thatthe narrative is incomplete, make up reasonable explanations to completethe story. Supply these extra explanations along with the diagrams. Here isthe narrative:

The pharmacy at Mercy Hospital fills medical prescriptions for all patientsand distributes these medications to the nurse stations responsible for thepatient’s care. Medical prescriptions are written by doctors and sent to thepharmacy. A pharmacy technician reviews the prescriptions and sends themto the appropriate pharmacy station. Prescriptions for drugs that must beformulated (made onsite) are sent to the lab station, prescriptions foroff-the-shelf drugs are sent to the shelving station, and prescriptions fornarcotics are sent to the secure station. At each station, a pharmacistreviews the order, checks the patient’s file to determine the appropriatenessof the prescriptions, and fills the order if the dosage is at a safe level and itwill not negatively interact with the other medications or allergies indicatedin the patient’s file. If the pharmacist does not fill the order, the prescribingdoctor is contacted to discuss the situation. In this case, the order mayultimately be filled or the doctor may write another prescription dependingon the outcome of the discussion. Once filled, a prescription label isgenerated listing the patient’s name, the drug type and dosage, anexpiration date, and any special instructions. The label is placed on thedrug container and the orders are sent to the appropriate nurse stations.The patient’s admission number, the drug type and amount dispensed, andthe cost of the prescription are then sent to the billing department.

29

Concluding Remarks

This brings us to the end of the first Unit in this text. The Unit establishedthe foundation upon which we will build your knowledge of systemsanalysis and design in subsequent units. Several important concepts andprinciples were covered in this Unit – systems thinking, systems analysis,system scope, data flow diagram, and context diagram. These areimportant concepts and principles to keep in sharp focus throughout theentire course.

Review/Essay Questions

1. Who is a systems analyst? List some of the job functions that systemsanalysts might perform.

2. What do you understand by ‘systems thinking’? Why is an under-standing of this concept important in systems analysis and design?

3. What is ‘information systems success’? Which of the various definitionsor measures of system success do you think may be used most? Why?

4. List some specific skills required of systems analysts. Identify specificcourses at the UWI which may help prepare systems analysts with theseskills.

5. Of all the various challenges of systems analysis and design discussed inthis Unit, which three, in your opinion, present the greatest threat todelivering successful information systems? Why? How could anorganization overcome or minimize these challenges?

FeedbackYou may check your answers to questions 1–4 by reviewing the informationpresented in this Unit. In the case of question 5, think about it carefully, thenwrite your answer down and present it in your tutorial session.

30

References

Alter, S.. Certification Program for MIS Systems Analysts. (Undated)

Dewitz, S. Systems Analysis and Design and the Transition to Objects. New York:The McGraw-Hill Co., 1996.

Hoffer, J., J. George, and J. Valacich. Modern Systems Analysis and Design.Reading, Massachusetts: Addison-Wesley, 1999.

Laudon, K., and J. Laudon. Management Information Systems. NJ: PrenticeHall, 1998.

Senge, P. Fifth Discipline: The Art and Practice of the Learning Organization.Currency/Doubleday, 1990.

Yourdon, E. Modern Structured Analysis. Englewood Cliffs, NJ: Prentice-Hall,1989.