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 over-
worked 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 third-
generation 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 fact-
gathering 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
Project A Project B
Present
$134,000 * 3.79079 = $507,966 $129,000 * 3.79079 = $489,012
Value
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.