What is the role of the accountant in the SDLC Why might accountants be called on for input into the development of Nonaccounting information system?

Chapter 5 System Development and Program Change Activities Review Questions 1. Distinguish between systems professionals, end users, and stakeholders. Response: Systems professionals are systems analysts, systems designers, and programmers; these individuals actually build the system. End users are the individuals for whom the system is built. End users are found throughout the organization. Stakeholders are individuals either within the organization or outside who have an interest in the system but are not the end users. 2. What is the role of the accountant in the SDLC? Why might accountants be called on for input into the development of a nonaccounting information system? Response: Accountants are involved in systems development in three ways. First, accountants are users. All systems that process financial transactions impact the accounting function in some way. Like all users, accountants must provide a clear picture of their problems and needs to the systems professionals. Second, accountants participate in systems development as members of the developmentteam. Their involvement often extends beyond the development of strictly AIS applications. Systems that do not process financial transactions directly may still draw from accounting data. The accountant may be consulted to provide advice or to determine if the proposed system constitutes an internal control risk. In all cases, the level of auditor participation is limited by independence issues in professional standards and ethics. Third, accountants are involved in systems development as auditors. Accounting information systems must be auditable. Some computer audit techniques require special features that need to be designed into the system during the SDLC. 3. What are the three problems that account for most system failures? Response: This is a thought provoking question and student answers will vary. Examples are: Poorly specified systems requirements, ineffective development techniques, and lack of user involvement in systems development. 4. Why is it often difficult to obtain competent and meaningful user involvement in the SDLC? Response: This is a thought provoking question and student answers will vary. Users must be actively involved in the systems development process. Their involvement should not be stifled because the proposed system is technically complex. Regardless of the technology involved, the user can and should provide a detailed written description of the logical needs that must be satisfied by the system. The creation of a user specification document often involves the joint efforts of the user and systems professionals. However, it is most important that this document remain a statement of user needs. It should describe the user’s view of the problem, not that of the systems professionals. Unfortunately users maybecome discouraged when they discover the time they must actually invest, and communication between end users and systems professionals is generally not fluent. 5. Who should sit on the systems steering committee? What are its typical responsibilities? Response: The composition of the steering committee may include the following: the chief executive officer, the chief financial officer, the chief information officer, senior management from user areas, the internal auditor, senior management from computer services, external consultants, and external auditors. The typical responsibilities of the steering committee include: a. resolving conflicts that arise from the new system. b. reviewing projects and assigning priorities. c. budgeting funds for systems development. d. reviewing the status of individual projects under development. e. determining at various checkpoints throughout the SDLC whether to continue the project or terminate it. 6. Why is strategic systems planning not technically considered to be part of the SDLC? Response: Strategic systems planning is not part of the SDLC because the SDLC pertains to specific applications, whereas the strategic systems plan is concerned with the allocation of such systems resources as employees (the number of systems professionals to be hired), hardware (the number of workstations, minicomputers, and mainframes to be purchased), software (the funds to be allocated to new systems projects and for systems maintenance), and telecommunications (the funds allocated to networking and EDI). 7. What is strategic systems planning, and why should it be done? Response: Strategic systems planning involves the allocation of systems resources at the macro level. It usually deals with a time frame of 3 to 5 years. This process is similar to budgeting resources for other strategic activities, such as product development, plant expansions, market research, and manufacturing technology. There are four justifications for strategic systems planning: 1. A plan that changes constantly is better than no plan at all. 2. Strategic planning reduces the crisis component in systems development. 3. Strategic systems planning provides authorization control for the SDLC. 4. Cost management. 8. What is the purpose of project planning, and what are the various steps? Response: The purpose of project planning is to allocate resources to individual applications within the framework of the strategic plan. This involves identifying areas of user needs, preparing proposals, evaluating each proposal’s feasibility and contribution to the business plan, prioritizing individual projects, and scheduling the work to be done. The basic purpose of project planning is to allocate scarce resources to specific projects. The product of this phase consists of two formal documents: the project proposal and the project schedule. 9. What is the object-oriented design (OOD) approach? Response: OOD builds systems from the bottom up through the assembly of reusable modules rather than create each system from scratch. OOD is most often associated with an iterative approach to SDLC where small chunks or modules, cycle through all of the SDLC phases rather rapidly, with a short time frame from beginning to end. Then additional modules or chunks are added in some appropriate fashion until the whole system has been developed. 10. What are the broad classes of facts that need to be gathered in the systems survey? Response: Data sources, users, data stores, processes, data flows, controls, transaction volumes, error rates, resource costs, and bottlenecks and redundant operations. 11. What are the primary fact-gathering techniques? Response: Observation, task participation, personal interviews, and reviewing key documents 12. What are the relative merits and disadvantages of a current systems survey? Response: An advantage of studying the current system is that it provides a way to identify what aspects of the old system are positive and should be kept. Further, the tasks, procedures, and data of the old system need to be understood so that the phase-in of the new system can handle any changes. Also, a survey of the current system may help the analyst determine the underlying cause of the reported symptoms. A disadvantage is that the analysis of the current system may be too time-consuming, especially if conducted at too detailed a level. Further, the study of the current system may create tunnel vision and/or prohibit the analysts from thinking in an innovative fashion. 13. Distinguish among data sources, data stores, and data flows. Response: Data sources include two types of entities: (a) external, such as customers or vendors, and (b internal, other departments in the organization. Data stores are the files, databases, accounts, and source documents used in the system. Data flows represent the movement of document or reports among the data sources, data stores, processing tasks, and users. 14. What are some of the key documents that may be reviewed in a current systems survey? Response: Some of the key documents that may be reviewed are organization charts, job descriptions, accounting manuals, charts of accounts, policy statements, descriptions of procedures, financial statements, performance reports, system flowcharts, source documents, accounts, budgets, forecasts, and mission statements. 15. What is the purpose of a systems analysis, and what type of information should be included in the systems analysis report? Response: The purpose of systems analysis is to understand both the actual and the desired states. The systems analysis report should contain the problems identified with the current system, the user’s needs, and the requirements of the new system. 16. What is the primary objective of the conceptual systems design phase? Response: The purpose of the conceptual design phase is to produce several alternative conceptual systems that satisfy the system requirements identified during systems analysis. By presenting users with a number of plausible alternatives, the systems professional avoids imposing preconceived constraints on the new system. The user will evaluate these conceptual models and settle on the alternatives that appear most plausible and appealing. These alternative designs then go to the systems selection phase of SDLC, where their respective costs and benefits are compared and a single optimum design is chosen. 17. What are two approaches to conceptual systems design? Response: The structured approach and the object-oriented approach. 18. How much design detail is needed in the conceptual design phase? Response: The conceptual design phase should be general; however, it should possess sufficient detail to demonstrate how the alternative systems are conceptually different in their functions. 19. What is an object, and what are its characteristics in the object-oriented approach? Give two examples. Response: The object-oriented design (OOD) approach is to build information systems from reusable standard components or objects. The concept of reusability is central to the object- oriented approach to systems design. Once created, standard modules can be used in other systems with similar needs. Ideally, the organization’s systems professionals will create a library (inventory) of modules that can be used by other system designers within the firm. For example the tasks of validating data in a payroll system or an AR system prior to updating are similar in concept and may be performed by program modules derived from the same object. The benefits of this approach include reduced time and cost for development, maintenance, and testing and improved user support and flexibility in the development process. 20. What is the auditor’s primary role in the conceptual design of the system? Response: The auditor is a stakeholder in all financial systems and, thus, has an interest in the conceptual design stage of the system. The auditability of a system depends in part on its design characteristics. Some computer auditing techniques require systems to be designed with special audit features that are integral to the system. These audit features must be specified at the conceptual design stage. 21. Who should be included in the group of independent evaluators performing the detailed feasibility study? Response: This is a thought provoking question and answers will vary. The following individuals may be involved: The project manager, a member of the internal audit staff, a user representative, and systems professionals who are not part of the project but have expertise in the specific areas covered by the feasibility study. 22. What makes the cost-benefit analysis more difficult for information systems than for most other investments an organization may make? Response: The benefits of information systems are often very difficult to assess. Many times the benefits are intangible, such as improved decision-making capabilities. Also, maintenance costs may be difficult to predict. Most other investments that organizations make, for example, the purchase of a new piece of equipment, tend to have more tangible and estimable costs and benefits. 23. Classify each of the following as either one-time or recurring costs: a. training personnel one-time b. initial programming and testing one-time c. systems design one-time d. hardware costs one-time e. software maintenance costs recurring f. site preparation one-time g. rent for facilities recurring h. data conversion from old system to new system one-time i. insurance costs recurring j. installation of original equipment one-time k. hardware upgrades recurring 24. Distinguish between turnkey and backbone systems. Which is more flexible? Response: Turnkey systems are completely finished and tested systems that are ready for implementation. Backbone systems provide a basic system structure on which to build, and. come with the primary processing modules programmed. They are much more flexible than turnkey systems, but are also more expensive and time consuming. 25. Discuss the relative merits of in-house programs versus commercially developed software. Response: Although in-house programs are very time consuming and expensive to develop, and require a lot of skilled systems personnel, their many advantages lead firms to develop in-house systems. In-house systems are not dependent upon an outside vendor for updates and maintenance; these aspects are controlled locally. The in-house programs are completely customized, whereas commercially developed software is not. 26. Why is modular programming preferable to free coding? Response: Regardless of the programming language used, modern programs should follow a modular approach. This technique produces small programs that perform narrowly defined tasks. The following three benefits are associated with modular programming. 1. Programming efficiency. Modules can be coded and tested independently, which vastly reduces programming time. A firm can assign several programmers to a single system. Working in parallel, the programmers each design a few modules. These are then assembled into the completed system. 2. Maintenance efficiency. Small modules are easier to analyze and change, which reduces the start-up time during program maintenance. Extensive changes can be parceled out to several programmers simultaneously to shorten maintenance time. 3. Control. By keeping modules small, they are less likely to contain material errors of fraudulent logic. 27. Why should test data be saved after it has been used? Response: The saved data is called a base case and documents how the system performed at one point in time. At any point in the future, the base case should produce the same results. Therefore, it is saved to facilitate future testing. 28. Explain the importance of documentation by the system’s programmers. Response: Systems programmers, as well as systems designers, will need the documentation themselves in order to debug the system and perform maintenance. 29. What documents not typically needed by other stakeholders do accountants and auditors need for the new system? Response: Document flowcharts of manual procedures are needed by the accountants and auditors. These flowcharts describe the physical system by showing explicitly the flow of information between departments, the departments in which the tasks are actually performed, and the specific types and number of documents that carry information. Thus, this document provides a view of the segregation of functions, adequacy of source documents, and location of files. Discussion Questions 1. Comment on the following statement: “The maintenance stage of the SDLC involves making trivial changes to accommodate changes in user needs.” Response: The systems maintenance period may last from five to ten years. During this period changes may need to be made to accommodate changes in user needs, but these changes, however small they might be, are extremely important in keeping the system functioning properly. Further, some major changes may be required. 2. Discuss how rushing the system’s requirements stage may delay or even result in the failure of a systems development process. Conversely, discuss how spending too long in this stage may result in “analysis paralysis.” Response: If the system’s requirements stage is rushed, the users’ needs may not be fully investigated or revealed. Thus, the system may be built prior to determining the appropriate and complete requirements. If the system is built with an inadequate set of requirements, it will not produce the desired results. Users will become frustrated and unhappy if the new system does not meet their needs. On the other hand, too much analysis can prevent the firm from making any progress. Requirements and technology change over time. At some point, a decision must be made that the system will be based upon the requirements determined to date. Thus, the system’s requirements stage should not be rushed, but lingering and holding on to the phase too long should not be allowed either. 3. Is a good strategic plan detail-oriented? Response: A strategic plan should avoid excessive detail, and it should provide a plan for a general allocation of resources at a macro level. The plan should provide guidance to the systems specialists so that they can make the detailed decisions. 4. Distinguish between a problem and a symptom. Give an example. Are these usually noticed by upper-, middle-, or lower-level managers? Response: A symptom is the result of a problem. Unfortunately, firms often try to fix the symptom rather than the problem. Decreased output by workers is a symptom, not a problem. If management attempts to solve this situation by hiring more workers, the problem is not solved. The problem may be that the quality of the raw materials is so bad that more time must be spent on each unit. If the problem is appropriately addressed, better quality raw materials, not more workers will solve the problem. Hiring more workers merely has more workers working inefficiently. Symptoms are typically noticed and reported by operational level managers because they have the closest contact with the day-to-day operations. 5. What purposes does the systems project proposal serve? How are these evaluated and prioritized? Is the prioritizing process objective or subjective? Response: The systems project proposal provides management with a basis for deciding whether or not to proceed with the project. One of its purposes is to summarize the findings of the preliminary study into a general recommendation for either a new or a modified system. Another is to outline the links between the objectives of the proposed system and the firm’s business objectives. These projects are evaluated based upon their contribution to the strategic objectives of the firm. One factor that may be considered is the improved operational productivity, such as reduced processing costs and reduced inventory carrying costs. Another factor that may be considered is improved decision making by managers. Evaluating competing proposals can be difficult, especially where the expected benefit, such as improved decision making or increased customer satisfaction, is difficult to quantify. Further, weighting the criteria and determining which aspect of the system is most important and which is least important are subjective decisions. One method that exists for evaluating and prioritizing projects is to assign scores for different dimensions and calculate a composite score, which is then used to rank the projects. 6. Most firms underestimate the cost and time requirements of the SDLC by as much as 50 percent. Why do you think this occurs? In what stages do you think the underestimates are most dramatic? Response: Firms typically understate the implementation time. One reason is due to overly optimistic estimates of employee training time. Another reason is that hardware does not arrive on time. Debugging programs is another area where time is often underestimated. Data conversion from the old system to the new system often takes more time than expected. Further, systems that were rushed in the systems analysis stage may need more maintenance due to demands by unhappy users. 7. A lack of support by top management has led to the downfall of many new systems projects during the implementation phase. Why do you think management support is so important? Response: Top management must provide a clear message that the system is important and also support it with adequate financial resources. If top management does not send a signal that a system is important, employees (future users of the systems) who are already busy with their assigned duties may not understand the importance of their input into the new system. They may view the interviews and questions as a nuisance that disrupts their work. Top management needs to send the message that the systems requirements analysis is important and compensate for overtime if necessary. If the employees do not fully cooperate, the system may not be appropriately designed. Glitches in the system will become apparent in the implementation phase. Further, the implementation of systems typically employees’ work to increase temporarily as they learn the new system. Top management needs to be supportive (perhaps in terms of compensation). 8. Many new systems projects grossly underestimate transaction volumes simply because they do not take into account how the new, improved system can actually increase demand. Explain how this can happen, and give an example. Response: A system that is easier to access and provides information easily may generate more inquiries than the old system. Take for example the account balance inquiry systems offered by most credit card companies. The old method of account balance inquiry by a cardholder involved a conversation between the cardholder and an account representative. The account representative would ask the cardholder questions and then give the information to the cardholder. Many companies provided this service only during certain hours. The new systems allow account balance inquiries 24 hours a day, and no human representative is involved. The customer uses the telephone keypad as an input device and can obtain account balance information very rapidly and conveniently. The demand for this service has increased as a result of its greater convenience and greater privacy. 9. Compare and contrast the structured design approach and the object-oriented approach. Which do you believe is most beneficial? Why? Response: The structured approach develops each new system from scratch from the top down. Object-oriented design builds systems from the bottom up through the assembly of reusable modules. A top-down approach is advantageous in that the system is designed around the needs of top management; on the other hand, reusable modules are beneficial for quick development of new systems. A hybrid system where modules can be redesigned when necessary or used without redesign when appropriate combines the best of both approaches. 10. Do you think legal feasibility is an issue for a system that incorporates the use of machines to sell lottery tickets? Response: The legal concern has to do with the illegal selling of tickets to minors; however, some states have such machines. 11. Intangible benefits are usually extremely difficult to quantify accurately. Some designers argue that if you understate them, then conservative estimates are produced. Any excess benefits will be greatly welcomed but not required for the new system to be a success. What are the dangers of this viewpoint? Response: If intangible benefits are not carefully and diligently estimated and considered, then a suboptimal system may be chosen (i.e., one that does not provide as much customer satisfaction as another option). Because of their inherent nature, intangible benefits are easy targets for manipulation. These benefits should be included in the analysis and decision- making process in some form. Decision support systems exist that allow inclusion of both tangible and intangible decisions. 12. If a firm decides early on to go with a special-purpose system, such as SAP, based on the recommendations of the external audit firm, should the SDLC be bypassed? Response: The systems development life cycle should be conducted, albeit in a modified form. Better yet, the firm should not decide on a package until it has determined its needs requirements and considered alternatives. 13. During a test data procedure, why should the developers bother testing “bad” data? Response: If only “good” data is tested, then the control procedures for flagging “bad” data cannot be tested. Thus, bad data that can verify all error checking routines should be included, and testing it is just as important as testing good data. 14. If the system is behind schedule and if each program module is tested and no problems are found, is it necessary to test all modules in conjunction with one another? Why or why not? Response: Yes, all modules must be tested in conjunction with another. This is necessary to ensure that modules interact together in the desired fashion. In other words, the data may be processed by multiple modules and tests are necessary to ensure that one module does not corrupt the data processed by another module. 15. Run manuals for computer operators are similar in theory to the checklists that airplane pilots use for takeoffs and landings. Explain why these are important. Response: Run manuals list each system and the frequency with which it should be run. Further, the required hardware and file requirements are listed. These lists tend to be numerous, and even a seasoned computer operator may occasionally forget exactly which run should be performed on a given day. Pilots are trained and licensed to fly airplanes, yet they still have checklists to which they refer for pre-flight, take-offs, and landing just to ensure that one of the many procedures is not forgotten. Like pilots, computer operators should refer to run lists just to make sure they have not forgotten any runs on any particular day. 16. Who conducts the post-implementation review? When should it be conducted? If an outside consulting firm were hired to design and implement the new system, or a canned software package were purchased, would a post-implementation review still be useful? Response: The systems personnel should conduct the post-implementation review regardless of whether the system was developed in-house or purchased. The end users should be interviewed as well as the accountants. The post-implementation review should occur a few months after the implementation phase so that the user can adjust to the system and processing occurs at a normal rate. 17. Discuss the importance of involving accountants in the detailed design and implementation phases. What tasks should they perform? Response: The accountants should provide technical expertise during the detailed design phase. For AISs, the specifications must comply with GAAP, GAAS, SEC, and IRS regulations. Accounting choices, such as depreciation and inventory valuation methods, must be incorporated. The accountants should also participate in the implementation phase by specifying and reviewing system documentation because these documents play an important role in the audit process. 18. Discuss the independence issue when audit firms also provide consulting input into the development and selection of new systems. Response: This is a violation of the Sarbanes-Oxley Act. Having a system audited by the consulting firm that initially proposed it may produce a bias on the consulting firm’s part to view the system in a positive light. 19. Discuss the various feasibility measures that should be considered. Give an example of each. Response: There are several common feasibility measures.  One feasibility measure is technical feasibility, which is an assessment as to whether the system can be developed under existing technology or whether new technology is needed. An example might be a situation in which a firm wants to completely automate the sales process. A question would be: Is technology available that allows sales to be made without humans?  Another feasibility measure is economic feasibility, which is an assessment as to the availability of funds to complete the project. A question would be: Is it cost feasible to purchase equipment to automate sales?  Legal feasibility identifies any conflicts with the proposed system and the company’s ability to discharge its legal responsibilities. An example would be a firm that is proposing a new mail order sales processing system for selling wine. Is it legal to sell wine without identification? (The answer must be yes, because such systems exist.)  Another consideration is operational feasibility, which shows the degree of compatibility between the firm’s existing procedures and personnel skills and the operational requirements of the new system. The firm should ask: Do we have the right workforce to operate the system? If not, can employees be trained? If not, can they be hired?  Lastly, schedule feasibility is important, and the concern is whether the firm has the ability to implement the project within an acceptable time frame. An example would be a new ticket sales system for a sports team. The system would need to be implemented prior to the start of the new season. 20. Discuss three benefits associated with modular programming. Response: The following three benefits are associated with modular programming. a. Programming Efficiency. Modules can be coded and tested independently, which vastly reduces programming time. A firm can assign several programmers to a single system. Working in parallel, the programmers each design a few modules. These are then assembled into the completed system. b. Maintenance Efficiency. Small modules are easier to analyze and change, which reduces the start-up time during program maintenance. Extensive changes can be parceled out to several programmers simultaneously to shorten maintenance time. c. Control. If modules are kept small, they are less likely to contain material errors or fraudulent logic. Because each module is independent of the others, errors are contained within the module. Multiple Choice Problems 1. B 2. D 3. A 4. D 5. A 6. D 7. C 8. A 9. D 10. E 11. A 12. B 13. D 14. B 15. A 16. A 17. 18. D 19. E 20. A Problems 1. Systems Planning A new systems development project is being planned for the Reindeer Christmas Supplies Company. The invoicing, cash receipts, and accounts payable modules are all going to be updated. The controller, Kris K. Ringle, is a little anxious about this project. The last systems development project that affected his department was not very successful, and the employees in the accounting department did not accept the new system very well at first. He feels that the systems personnel did not interact sufficiently with the users of the systems in the accounting department. Prepare a memo from Ringle to the head of the information systems department, Sandy Klaus. In this memo, provide some suggestions for including the accounting personnel in the systems development project. Give some very persuasive arguments why prototyping would be helpful to the workers in the accounting department. Response: TO: Sandy Klaus FROM: Kris K. Ringle SUBJ: New systems development project In order to help make the new systems development project as successful as possible, I propose that we devise a plan that encourages user involvement in the front-end stages. Many of the everyday users of the system are accounting personnel. These personnel can contribute a lot to the format of the input screens. Implementation could be smoother for this project than it was for that last system. As you are aware, the input clerks have been unhappy with the input screens and the editing procedures. Further, the reports do not contain all of the necessary information, and the information that is included is shrouded by other less relevant information. I suggest that prototypes of the input screens and editing processes be developed by the systems personnel and tested by the input clerks. I also think examples of the reports would be useful so that we can determine upfront if the information presented is useful and clear. I really believe that if we encourage more communication between the accounting department members and the systems analysts, we may have an easier implementation process and less maintenance on the new system. Let’s set up a meeting for early next week to determine a plan. 2. Problem Identifications The need for a new information system may be manifest in various symptoms. In the early stages of a problem, these symptoms seem innocuous and go unrecognized. As the underlying source of the problem grows in severity, so do its symptoms, until they are alarmingly apparent. Classify each of the following as a problem or a symptom. If it is a symptom, give two examples of a possible underlying problem. If it is a problem, give two examples of a possible symptom, which may be detected. a. declining profits b. defective production processes c. low-quality raw materials d. shortfall in cash balance e. declining market share f. shortage of employees in the accounts payable department g. shortage of raw material due to a drought in the market h. inadequately trained workers i. decreasing customer satisfaction Response: a. declining profits—symptom. Possible problems are a production process that is producing defective products and causing a decline in sales or increased costs due to high maintenance of outdated machinery. b. defective production process—problem. Possible symptoms are declining sales or increased COGS due to labor time for reworks. c. low-quality raw materials—problem. Possible symptoms are declining sales or increased COGS. d. shortfall in cash balance—symptom. Possible problems are loose accounts receivable collections or over-purchase of inventory. e. declining market share—symptom. Possible problems are producing the wrong product mix (i.e. producing unwanted items) or poor customer service. f. shortage of employees in the accounts payable department—problem. Possible symptoms are increased discounts lost or increased errors in processing tasks g. shortage of raw material due to a drought in the Midwest—problem. Symptoms are declining profits or unfilled customer orders. NOTE: It could also be viewed as a symptom of relying too heavily on one supplier. h. inadequately trained workers—problem. Possible symptoms are higher COGS or decreased sales. i. decreasing customer satisfaction—symptom. Possible problems are defective production process or mean of poor distribution. 3. Systems Development and Implementation Kruger Designs hired a consulting firm three months ago to redesign the information system used by the architects. The architects will be able to use state-of-the-art CAD programs to help in designing the products. Further, they will be able to store these designs on a network server where they and other architects may be able to call them back up for future designs with similar components. The consulting firm has been instructed to develop the system without disrupting the architects. In fact, top management believes that the best route is to develop the system and then to “introduce” it to the architects during a training session. Management does not want the architects to spend precious billable hours guessing about the new system or putting work off until the new system is working. Thus, the consultants are operating in a back room under a shroud of secrecy. Required: a. Do you think that management is taking the best course of action for the announcement of the new system? Why? b. Do you approve of the development process? Why? Response: a. Management should announce the plan and try to gain support from the very beginning. The proposed plan will probably backfire and cause the architects to waste time trying to guess what is happening. (Secrets are not easily held in organizations. The consultants will be seen in meetings with management.) Anxiety may result, and as a worst-case scenario, some of the best and most marketable employees may seek employment elsewhere. b. The systems development process should include the end users. The day-to-day users of the CAD system will be the architects, and these architects should play a very active role in the development process. If they do not, their needs most probably will not be fully met. 4. Systems Analysis Consider the following dialogue between a systems professional, Joe Pugh, and a manager of a department targeted for a new information system, Lars Meyer: Pugh: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved. Meyer: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system. Pugh: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what is not. Meyer: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system! Required: a. Obviously, these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most. b. What method would you propose they take? Why? Response: a. The systems professionals will be able to understand the needs of the new system if they fully understand the operations of the old system. This understanding of the old system will help them to assess and incorporate the users’ likes of the old system into the new system. The manager of the user department, however, has a legitimate concern that too much time will be spent studying “what is” rather than “what should be.” A clean slate often results in more innovative solutions. b. The old system needs to be understood at some level. I would propose that a very fundamental analysis of the current system be conducted within a given time frame, with the focus on the likes and dislikes. Then a new systems requirements analysis could begin with a prioritized users’ “wish list.” This wish list could be used as the starting point for the user requirements. 5. Systems Design Robin Alper, a manager of the credit collections department for ACME Building Supplies, is extremely unhappy with a new system that was installed three months ago. Her complaint is that the data flows from the billing and accounts receivable departments are not occurring in the manner originally requested. Further, the updates to the database files are not occurring as frequently as she had envisioned. Thus, the hope that the new system would provide more current and timely information has not materialized. She claims that the systems analysts spent three days interviewing her and other workers. During that time, she and the other workers thought they had clearly conveyed their needs. She feels as if their needs were ignored and their time was wasted. Required: What went wrong during the systems design process? What suggestions would you make for future projects? Response: Some possible reasons the system is not meeting Ms. Alper’s needs are of the following: a. Ms. Alper and her co-workers did not clearly convey their requirements. b. The systems analysts did not clearly understand the requirements. c. The processing details and output details were not specified in enough detail. d. The specifications, once developed, were not reviewed by the end users, Ms. Alper and her co-workers, for accuracy and completeness. e. The system that was implemented does not meet all of the design specifications. For the future, the end users should be consulted again after the initial consultation to determine if the design specifications accurately incorporate their needs. If not, some reworking of the specifications needs to occur. A JAD session using CASE tools and prototyping would be ideal if the resources are available. 6. Conceptual Design Prepare two alternative conceptual designs for both an accounts payable system and an accounts receivable system. Discuss the differences in concept between the two designs. From a cost perspective, which is more economical? From a benefits perspective, which is more desirable? Which design would you prefer and why? Response: This is an open-ended question and student responses will vary. The instructor should direct students to apply the principles of conceptual alternative design and cost benefit analysis discussed in the chapter. 7. Systems Design Robert Hamilton was hired six months ago as the controller of a small oil and gas exploration and development company, Gusher, Inc., headquartered in Beaumont, Texas. Before working at Gusher, Hamilton was the controller of a larger petroleum company, Eureka Oil Company, based in Dallas. The joint interest billing and fixed asset accounting systems of Gusher are outdated, and many processing problems and errors have been occurring quite frequently. Hamilton immediately recognized these problems and informed the president, Mr. Barton, that it was crucial to install a new system. Barton concurred and met with Hamilton and Sally Jeffries, the information systems senior manager. Barton instructed Jeffries to make the new system that Hamilton wished to have a top priority in her department. Basically, he told Jeffries to deliver the system to meet Hamilton’s needs as soon as possible. Jeffries left the meeting feeling overwhelmed because the IS department is currently working on two other very big projects, one for the production department and the other for the geological department. The next day, Hamilton sent a memo to Jeffries indicating the name of a system he had 100 percent confidence in—Amarillo Software—and he also indicated that he would very much like this system to be purchased as soon as possible. He stated that the system had been used with much success during the past four years in his previous job. When commercial software is purchased, Jeffries typically sends out requests for proposals to at least six different vendors after conducting a careful analysis of the needed requirements. However, due to the air of urgency demonstrated in the meeting with the president and the overworked systems staff, she decided to go along with Hamilton’s wishes and sent only one RFP (request for proposal) out, which went to Amarillo Software. Amarillo promptly returned the completed questionnaire. The purchase price ($75,000) was within the budgeted amount. Jeffries contacted the four references provided and was satisfied with their comments. Further, she felt comfortable since the system was for Hamilton, and he had used the system for four years. The plan was to install the system during the month of July and try it for the August transaction cycle. Problems were encountered, however, during the installation phase. The system processed extremely slowly on the hardware platform owned by Gusher. When Jeffries asked Hamilton how the problem had been dealt with at Eureka, he replied that he did not remember having had such a problem. He called the systems manager from Eureka and discovered that Eureka had a much more powerful mainframe than Gusher. Further investigation revealed that Gusher has more applications running on its mainframe than Eureka did, since Eureka used a two-mainframe distributed processing platform. Further, the data transfer did not go smoothly. A few data elements being stored in the system were not available as an option in the Amarillo system. Jeffries found that the staff at Amarillo was very friendly when she called, but they could not always identify the problem over the phone. They really needed to come out to the site and investigate. Hamilton was surprised at the delays between requesting an Amarillo consultant to come out and the time in which he or she actually arrived. Amarillo explained that it had to fly a staff member from Dallas to Beaumont for each trip. The system finally began to work somewhat smoothly in January, after a grueling fiscal year-end close in October. Hamilton’s staff viewed the project as an unnecessary inconvenience. At one point, two staff accountants threatened to quit. The extra consulting fees amounted to $35,000. Further, the systems department at Gusher spent 500 more hours during the implementation process than it had expected. These additional hours caused other projects to fall behind schedule. Required: Discuss what could have been done differently during the design phase. Why were most of the problems encountered? How might a detailed feasibility study have helped? Response: The systems analysis and requirements phase was never conducted. Further, a conceptual design was never prepared. A crucial aspect, the feasibility study, was never carried out. Thus, no criteria were available to judge whether the vendor’s RFP was appropriate for Gusher. Due to time constraints, Gusher purchased the software hurriedly without conducting the proper analysis. The rush to put in a new project because the systems department was overworked caused more work, troubles, headaches, and cost outflows than would have occurred if the analysis had been appropriately conducted in the first place. Proper analysis would probably have addressed the major problems. The software purchased did not have data fields to capture some of the data captured by the old system. The mainframe, with all of the other processing, was not sufficiently powerful to process transactions using the new system. A benchmark test using Gusher’s mainframe and data would have discovered both problems. 8. Programming Languages Describe the basic features of the following three types of programming languages: procedural, event-driven, and object oriented. Give examples of each type of language. Response: a. Procedural Languages. A procedural language requires the programmer to specify the precise order in which the program logic is executed. Procedural languages are often called thirdgeneration languages (3GLs). Examples of 3GLs include COBOL, FORTRAN, C, and PL1. In business (particularly in accounting) applications, COBOL was the dominant language for years. COBOL has great capability for performing highly detailed operations on individual data records and handles large files very efficiently. On the other hand, it is an extremely wordy language that makes programming a time-consuming task. COBOL has survived as a viable language because many of the legacy systems written in the 1970s and 1980s, which were coded in COBOL, are still in operation today. Major retrofits and routine maintenance to these systems need to be coded in COBOL. Upward of 12 billion lines of COBOL code are executed daily in the United States. b. Event-Driven Languages. Event-driven languages are no longer procedural. Under this model, the program’s code is not executed in a predefined sequence. Instead, external actions, or “events” that are initiated by the user dictate the control flow of the program. For example, when the user presses a key, or clicks on an icon on the computer screen, the program automatically executes code associated with that event. This is a fundamental shift from the 3GL era. Now, instead of designing applications that execute sequentially from top to bottom in accordance with the way the programmer thinks they should function, the user is in control. Microsoft’s Visual Basic is the most popular example of an event-driven language. The syntax of the language is simple yet powerful. Visual Basic is used to create real-time and batch applications that can manipulate flat files or relational databases. It has a screen-painting feature that greatly facilitates the creation of sophisticated graphical user interfaces (GUI). c. Object-Oriented Languages. Central to achieving the benefits of the object oriented approach is developing software in an object-oriented programming (OOP) language. The most popular true OOP languages are Java and Smalltalk. However, the learning curve of OOP languages is steep. The time and cost of retooling for OOP is the greatest impediment to the transition process. Most firms are not prepared to discard millions of lines of traditional COBOL code and retrain their programming staffs to implement object-oriented systems. Therefore, a compromise, intended to ease this transition, has been the development of hybrid languages, such as Object COBOL, Object Pascal, and C++. 9. Program Testing When program modules have been coded and tested, they must be brought together and tested as a whole. Comment on the importance of testing the entire system. Response: User personnel should direct system-wide testing as a prelude to the formal system cutover. The procedure involves using the system to process hypothetical data. The outputs of the system are then reconciled with predetermined results, and the test is documented to provide evidence of the system’s performance. Finally, when those conducting the tests are satisfied with the results, a formal acceptance document should be completed. This is an explicit acknowledgment by the user that the system in question meets stated requirements. The user acceptance document becomes important in reconciling differences and assigning responsibility during the post-implementation review of the system. 10. Database Conversion What is database conversion? Why is it a risky activity, and what precautions should be taken? Response: Database conversion is a critical step in the implementation phase. This is the transfer of data from its current form to the format or medium required by the new system. The degree of conversion depends on the technology leap from the old system to the new one. Some conversion activities are very labor intensive, requiring data to be entered into new databases manually. For example, the move from a manual system to a computer system will require converting files from paper to magnetic disk or tape. In other situations, companies can accomplish data transfer by writing special conversion programs. A case in point is changing the file structure of the databases from sequential direct access files. In any case, data conversion is risky and must be carefully controlled. The following precautions should be taken. a. Validation. The old database must be validated before conversion. This requires analyzing each class of data to determine whether it should be reproduced in the new database. b. Reconciliation. After the conversion action, the new database must be reconciled against the original. Sometimes this must be done manually, record by record and field by field. In many instances, this process can be automated by writing a program that will compare the two sets of data. c. Backup. Copies of the original files must be kept as backup against discrepancies in the converted data. If the current files are already in magnetic form, they can be conveniently backed up and stored. However, paper documents can create storage problems. When the user feels confident about the accuracy and completeness of the new databases, the paper documents may be destroyed. 11. System Cutover Discuss three common approaches to system cutover. Comment on the advantages and disadvantages of each approach. Response: A system cutover will usually follow one of three approaches: cold turkey, phased, or parallel operation. a. Cold Turkey Cutover. Under the cold turkey cutover approach (also called the big bang approach), the firm switches to the new system and simultaneously terminates the old system. When implementing simple systems, this is often the easiest and least costly approach. With more complex systems, it is the riskiest. Cold turkey cut over is akin to skydiving without a reserve parachute. As long as the main parachute functions properly, there is no problem. But things don’t always work the way they are supposed to. System errors that were not detected during the walkthrough and testing steps may materialize unexpectedly. Without a backup system, an organization can find itself in serious trouble. b. Phased Cutover. Sometimes an entire system cannot, or need not, be cut over at once. The phased cutover begins by implementing the new system in modules. For example, one might implement the sales subsystem, followed by the inventory control subsystem, and finally the purchases subsystem. By phasing in the new system in modules, the risk of a devastating system failure is reduced. However, the phased approach can create incompatibilities between new subsystems and yet-to-be-replaced old subsystems. This problem may be alleviated by implementing special conversion systems that provide temporary interfaces during the cutover period. c. Parallel Operation Cutover. Parallel operation cutover involves running the old system and the new system simultaneously for a period of time. Running two systems in parallel essentially doubles resource consumption. During the cutover period, the two systems require twice the source documents, twice the processing time, twice the databases, and twice the output production. The advantage of parallel cutover is the reduction in risk. By running two systems, the user can reconcile outputs to identify errors and debug errors before running the new system solo. Parallel operation should usually extend for one business cycle, such as one month. This allows the user to reconcile the two outputs at the end of the cycle as a final test of the system’s functionality. 12. Audit of Systems Development The Balcar Company’s auditors are developing an audit plan to review the company’s systems development procedures. Their audit objectives are to ensure that 1. The system was judged necessary and justified at various checkpoints throughout the SDLC. 2. Systems development activities are applied consistently and in accordance with management’s policies to all systems development projects. 3. The system as originally implemented was free from material errors and fraud. 4. System documentation is sufficiently accurate and complete to facilitate audit and maintenance activities. The following six controllable activities have been identified as sources of audit evidence for meeting these objectives: systems authorization, user specification, technical design, internal audit participation, program testing, and user testing and acceptance. Required: a. Explain the importance of each of the six activities in promoting effective control. b. Outline the tests of controls that the auditor would perform in meeting audit objectives. Response: a. Systems Authorization Activities All systems should be properly authorized to ensure their economic justification and feasibility. This requires a formal environment in which users submit requests to systems professionals in written form. User Specification Activities Users need to be actively involved in the systems development process. User involvement should not be stifled by the technical complexity of the system. Regardless of the technology involved, the users should create detailed written descriptions of their needs. The creation of a user specification document often involves the joint efforts of the user and systems professionals. However, this document must remain a statement of user needs. It should describe the user’s view of the problem, not that of the systems professionals. Technical Design Activities The technical design activities translate user specifications into a set of detailed technical specifications for a system that meets the user’s needs. The scope of these activities includes systems analysis, feasibility analysis, and detailed systems design. The adequacy of these activities is reflected in the quality of the documentation that emerges from each phase. Internal Audit Participation To meet the governance-related expectations of management under SOX, an organization’s internal audit department needs to be independent, objective, and technically qualified. As such, the internal auditor can play an important role in the control of systems development activities. An internal audit group, astute in computer technology and possessing a solid grasp of the business problems to be solved, is invaluable to the organization during all phases of the SDLC. Program Testing All program modules must be thoroughly tested before they are implemented. The results of the tests are then compared against predetermined results to identify programming and logic errors. The auditor should verify that all braches of the application's logic has been tested. The task of creating meaningful test data is time consuming. The data should therefore be saved and will give the auditor a frame of reference for designing and evaluating future audit tests. For example, if a program has undergone no maintenance changes since its implementation, the test results from the audit should be identical to the original test results. Having a basis for comparison, the auditor can thus quickly verify the integrity of the program code. User Test and Acceptance Procedures Prior to system implementation, the individual modules of the system need to be formally and rigorously tested as a whole. The test team should comprise of user personnel, systems professionals, and internal auditors. The details of the tests performed and their results need to be formally documented and analyzed. Once the test team is satisfied that the system meets its stated requirements, the system can be transferred to the user. b. In meeting the audit objectives the auditor would perform a combination of tests of application controls and substantive tests of transaction details and account balances. The auditors would examine the audit trail of program changes by reconciling program version numbers and confirming maintenance authorizations. The auditors identify application errors by reconciling the source code, reviewing test results, and re-testing the program. 13. Fact-Gathering Techniques Your company, Tractors, Inc., is employing the SDLC for its new information system. You have been chosen as a member of the development team because of your strong accounting background. This background includes a good understanding of both financial and managerial accounting concepts and required data. You also possess a great understanding of internal control activities. You do not, however, fully understand exactly what the internal auditors will need from the system in order to comply with Section 404 of the Sarbanes-Oxley Act. Lay out the factgathering techniques you might employ to increase your understanding of this important component of your new system. Response: Neither observation or task preparation will provide much help in learning how auditors comply with Section 404, instead personal interviews and review of key documents would be more helpful. Perhaps the review of two key documents might be a good starting point. The first might be the Sarbanes-Oxley Act itself. This document could provide the framework of compliance. Another document of which a review could be helpful is a previously prepared report on internal controls. Since this document is an end requirement of the Act, the information and content of the report should provide additional understanding of the information the system must be able to produce. Conducting a personal interview of members of the internal audit department who are responsible for compliance will also be helpful. These auditors can provide answers to such questions as what data must come from the system and which controls must be programmed in order to comply. 14. Systems Selection Your company, Kitchen Works, is employing the SDLC for its new information system. The company is currently performing a number of feasibility studies, including the economic feasibility study. A draft of the economic feasibility study has been presented to you for your review. You have been charged with determining whether only escapable costs have been used, the present value of cash flows is accurate, the one-time and recurring costs are correct, realistic useful lives have been used, and the intangible benefits listed in the study are reasonable. Although you are a member of the development team because of your strong accounting background, you have questions about whether some costs are escapable, the interest rates used to perform present value analysis, and the estimated useful lives that have been used. How might you resolve your questions? Response: Information about escapable costs may be found in a review of contracts. It may be that some costs included include clauses to alter the contract. It may also be that routine costs (like future orders and leases) are not escapable and have not been included in the computations. Several sources exist that tie interest rates to risks and industries. A search for such sources must be taken and the cited rates compared to those used in the present value analysis. Estimates of useful life may best be examined by interviewing those responsible for their preparation. Care should be taken to understand whether estimates are biased due to a preference in the part of the preparer. 15. Cost-Benefit Analysis Listed in the diagram for Problem are some probability estimates of the costs and benefits associated with two competing projects. a. Compute the net present value of each alternative. Round the cost projections to the nearest month. Explain what happens to the answer if the probabilities of the recurring costs are incorrect and a more accurate estimate is as follows: A B .10 $ 75,000 .4 $ 85,000 .55 95,000 .4 100,000 .35 105,000 .2 110,000 b. Repeat step (a) for the payback method. c. Which method do you think provides the best source of information? Why? Response: Weighted Average Recurring Benefits: Project A: (.10*75,000)+(.55*95,000)+(.35*105,000)=$96,500 Project B: (.4*85,000)+(.4*100.000)+(.2*110,000)=$96,000 These numbers are the weighted average of the recurring costs only, and do not take into consideration the benefit. NPV = Benefits – Costs: Project A: (.3*220,000)+(.5*233,000)+(.2*240,000) - (.10*75,000)+(.55*95,000)+(.35*105,000) = $134,000 Project B: (.25*215,000)+(.5*225,000)+(.25*235,000) - (.4*85,000)+(.4*100.000)+(.2*110,000) = $ 129,000 Present Value of an Annuity of 1 over 5 years at 10% = 3.79079 Present Value Project A Project B $134,000 * 3.79079 = $507,966 $129,000 * 3.79079 = $489,012

Presume that only the 10% factor for A was incorrectly determined. Further presume a more accurate rate would be 08%. This is only a 2% difference, but this difference results in a weighted average for A of $95,000 and a present value of $360,125. A minor misestimate will result in a different decision The second part of this question is confusing because the ‘accurate estimates’ given in part a of this question are exactly the same as the ‘incorrect’ estimates in the table for problem 7.