Midterm Examination

Suggested Solution

10. Discuss the importance of the accountant in the detailed design and implementation phases. What tasks should they be sure to perform?

Response: The accountant should provide technical expertise during the detailed design phase. For AlSs, the specifications- must comply with GAAP, GAAS, SEC, and IRS regulations. Further, 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 since these documents play an important role in the audit process.

4. A good structure diagram should be weakly coupled, yet strongly cohesive. These sound incompatible, how can you achieve both characteristics simultaneously? What implications do these characteristics have on error-prone problems during maintenance?

Response: Modules are considered to be weakly coupled if they have very little interaction with each other. Modules which perform a single, well-defined task are considered to be strongly cohesive. Thus, if each module performs a single-well defined task and is basically independent of the other modules, then they are considered to be both weakly coupled and strongly cohesive. These characteristics make problem solving during the maintenance phase much easier to perform. Due to the independence of the modules, maintenance or error correction of one module should not affect the other modules.

Question 3

Response:

TO: frank Kennedy

. FROM: Mark Bloom

SUBJ: New systems development project

In order to help make the new systems development project as successful as possible, l proposes that we devise a plan, which 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. Further, implementation could possibly be smoother for this project than it was for that last new system which was developed. As you are aware, the input clerks have been less than thrilled with the input screens and the editing procedures. Further, the reports do not contain all of the necessary information, and the information, which is included, is shrouded in other less relevant information. L would like to suggest that prototypes of the input screens and editing processes be developed by the systems personnel and tested by the input clerks. Further, l think examples of the reports would be useful so that we can determine upfront if the information presented is useful and clear. L really believes 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.

Question 4

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 conducted. Thus, no criteria were available to judge whether the vendor's RFP was appropriate for Gusher. Due to time constraints, the software was purchased hurriedly without conducting the proper analysis. What happened in this situation is characteristic of what happens oftentimes; a rush to put in a new project clue to an overworked systems department causes more work, troubles, headaches, and cost outflows than would have occurred if the analysis had been appropriately conducted in the first place. The following problems would probably have been addressed. First, the software purchased does not have data fields to capture some of the data being captured by the old system. The mainframe, with all of the other processing, is not sufficiently powerful enough to process the transactions using the new system. A benchmark test using Gusher's. Mainframe and data would have discovered both of these problems.

Question 5

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 user's likes and dislikes 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 oftentimes results in more innovative solutions.

b. The old system needs to be understood at some level. I would propose that a very fundamental analysis, within a given time frame, of the current system be conducted with the focus on the likes and dislikes. Then a new systems requirements analysis could begin with a prioritized "wish list" of the users. This wish list could be used as the starting point for the user requirements.