Rayo Corporation: Completion of Systems and Programming Questionnaire. 1

Mike Kess, a senior auditor for the regional accounting firm Sanders and McDonald, was assigned to audit the Rayo Corporation. He was to conduct a preliminary review of the general controls over systems and programming. He has already identified the current applications and the equipment used in the data processing system Shown in figure below and is about to start on system maintenance.

.:.

Mike contacted Jim Stram, the manager of systems and programming in the EDP department. A summary of their conversation is presented below.

Mike: How is system maintenance projects initiated and developed?

Jim: All potential projects are sent to a member of my staff called an applications coordinator for analysis. We do all our systems and programming work in-house. If a programming change is required for a project, the applications coordinator prepares a revision request form. These revision request forms must be approved by both the manager of operations and myself. The director of data processing and the internal auditor receive copies of each revision request form for information purposes.

Mike: How does the applications coordinator keep track of the revision request form and any change that might be made to it?

Jim: The revision request forms are numbered in different series depending on the nature of the change requested. The applications coordinator assigns the next number in the sequence and records in a master log each request he prepares. Changes in revision requests, from whatever source, are prepared on request forms just as initial requests are. Each change request is given the same basic number with a suffix indicating that it is an amendment, and there is a place for recording amendments in the master log.

Miki :What is the distribution of an approved request form?

Jim: It goes to one of my systems supervisors for design, programming, and testing. The primary effort is usually performed by a programmer who has responsibility over the area of the application or the specific programs to be changed.

Mike: But how are projects controlled?

Jim: At the beginning of each programming project, an estimated start and completion date are assigned and entered on the request form and the master log. The system supervisor keeps on top of the projects assigned to him, and the applications coordinator also monitors the open requests. The system supervisor files a written status report with the applications coordinator twice a month, and he briefs me on any problems. However, I’m usually aware of any difficulties long before then. During the programming and testing phase, I think we have good control over the project. None of the compiles made during this phase changes any production source code for the existing computer programs. Also, all test object programs are identified by a strictly enforced naming convention that clearly distinguishes them from production programs. So far, this has been successful in inhibiting their use in processing production. If a programmer has specific questions or problems on a project, his or her systems supervisor generally is available to give advice.

Mike: Are there written guidelines to direct this activity? If so, how detailed are they?

Jim: Only informal procedures exist to provide any uniformity to the programs and the coding changes that are made to a program. But formal standards do exist that define what documentation should be present for a system and for the programs within a system. These apply to program changes as well and again are strictly enforced. There is a periodic management review to see that we comply. We just had one about a month ago and got a clean bill of health.

Mike: Are adequate tests and reviews made of changes before they are implemented?

Jim: The applications coordinator, the systems supervisor, and the individual programmer informally discuss the necessary tests for a specific project. Sometimes I get involved too, but our guidelines are pretty good in this area and provide a fairly thorough approach to test design. After the tests have been completed to the systems supervisor’s satisfaction, the applications coordinator reviews and approves the test results. This must be done on all revision requests before they are implemented into production. I usually review the programmer’s work to see that all authorized changes are made correctly and are adequately tested and documented.

Mike: How does implementation take place, and what controls are exercised over it?

Jim: After the test results for a revision request have been approved by the applications coordinator, it is the responsibility of the programmer to implement the changes into production. In order for a programmer to put a program change into production, he or she must update the source code of the production program version. The programmer is required to provide program name and compile date information for all changed programs to his or her system super-visor. The programmer also has the responsibility of updating the systems and programming documentation. His or her system supervisor is supposed to review this and certify completion to the applications coordinator, who then completes the log entry.

Mike: Are post implementation reviews undertaken on system maintenance projects?

Jim: Once the project is implemented, the applications coordinator reviews the output from the first few production runs of the changed program. He also questions users to see if any problem areas can be identified. A documented audit trail is provided by a completed project file that is maintained by the applications coordinator for each request number. This file contains all the required documentation, including test results. A copy of the final summary goes to the department that originally submitted the request. A table in the computer is updated to provide listings of the most current compile dates for each set of production object code within the system. Before any program is implemented it is checked against the table.

Mike: Well, that seems to be it. I think I have all that I need for now, but I’ll probably be back to take a look at the files and records. I may have more questions for you then. Thanks very much for your time and thoughtful answers. I really appreciate your help.

Jim: That’s quite all right. If I can be of any more help, just let me know.

Required

a. Keeping in mind that this is part of the preliminary phase of the review, are there any additional questions you would have asked of Jim if you had been in Mike’s place?\

b. Complete as much of the pages of the questionnaire shown in Figure 14.10 as you can from the information Mike did collect in the interview.

c. Make a list of weaknesses that you feel should be considered in the preliminary assessment of the internal control in this area.

Transcribed Image Text:

Clent Audit Date Systems and Programming Questionnaire Yes No NIA 1. Are there systems and programming standards in the following areas: a. Applications design? c. Systems and program documentation? d. Applications control? e. Project planning and management? 2. Does the nomal docurmentation for an application include the following: b. Systems lowchart? c. Deinition of input data and source format? d. Description of expected output data and format? e. A lising of all valid transactions and other codes and abbreviations and master file fialds afflected? f. File definition or layouts? g. Instructions for preparing input? h. Instructions for correcting erors? i. Backup requiraments? . Description of tost data? Program Docurmentaton a. Program narrative? b. Flowchart of each program? c. Curment source listing of each program? Operations Documentation a. Data entry instructions, including verification? b. Instructions for control personnel, including batching? o. Instructions for the tape ibrarian? d. Operator's run manual? e. Reconstruction procedure? Is there a período management review of documentation to ensuro that it is current and accurate? If yes, when and by whom was it last performed? 3. 4. Is al systems and programming work done in-house? If not, is it done: a. By computer manufacturer's personnel? c. Other? 5. Are all changes programmed by persons other than those assigned to computer operations? 6. Are program changes documented in a manner that preserves an accurate chronological reoord of the If yes, describe 7. Do the users participate in the development of new applications or modifications of existing applications through frequent rowiews of work performed? If yes, are the results of reviews documented? 8. Are testing procedures and techniques standardized? 9. Are program revisions tested as stringently as new programs? 10. Are tests designed to uncover weaknesses in the links between programs, as well as within programs? 11. Are users involved in the testing procees, i.e., do they use the application as it is intondad during the testing process? 12. Do user departments perfom the final reviow and sign off on projects betore acceptance? 13. What departments and/or individuals have the authority to authorize an operator to put a new or modified program into production? 14. What supervisory or management approval is neceesary for the conversion of files?