Aguila, Paulo Timothy DR.

III – BSA

AUDITING IN CIS ENVIRONMENT

CHAPTER 5

Multiple Choices

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. C
18. D
19. E
20. A

Discussion Questions

1. 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. 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. 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. 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. 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. 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. 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. 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. 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. The legal concern has to do with the illegal selling of tickets to minors; however, some states
have such machines.

11. 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. 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. 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. 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 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. 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. 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. 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. 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. 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.