Previous | Table of Contents | Next |
The IT Audit Professional is less likely to find an IT department utilizing the classical methodology today than in the past, but it is still in use in many of the larger IT departments, and contains all of the elements that are normally found in any of the other development methodologies.
Part IV is divided into the five phases of the systems life cycle: initiation, definition, system design, programming and training, and evaluation and acceptance. It prescribes audit coverage for consideration throughout the systems development life cycle. The audit approach and considerations for each phase, however, are presented as separate modules for use in review during the systems development phase or at the completion of a particular phase.
The IT Audit Professional, armed with an understanding of the general and specific control objectives and process participants, may choose to perform a basic evaluation of the systems development methodology in place. This review may even be done as a discovery effort, with the results used as the foundation to perform a more extensive review.
The Basic Evaluation Approach
The basic information can be gathered by obtaining answers to the following list of questions. A brief discussion of the significance of each question follows this list.
What Methodology Is in Use?
The company should have a methodology to ensure that systems are implemented using techniques designed to provide effective systems without taking unacceptable risks with the enterprises ability to do business. The IT Auditor may be told that there is no methodology, but this cannot be the case.
The organization may choose to have a completely informal process that each systems developer may modify to suit his or her own preferences, and this would be their methodology. The IT Audit Professional might very well choose to make a number of comments on the risks associated with such an approach to systems development, but that would not change the reality of the development methodology in place.
The IT Auditor may know what methodology has been selected, but the auditor must still remain aware that the experienced professionals on the development staff are likely to have their own opinions about what constitutes an effective set of procedures. Even if they agree with the selected methodology, there may be performance pressures on the individual that are not easy to meet. If they are too difficult, it may lead the information systems professionals to take shortcuts, and to fail to comply with even their own set of best or proper procedures.
Is the Methodology Documented?
This is a very important follow-up question when the systems audit professional is told that a methodology is in place and followed. A documented methodology is available to all of the systems developers, and there is no need to interpret oral instructions. If the plan is not documented, the systems audit professional will not be able to rely on the methodology because compliance with it cannot be tested, measured, and quantitatively measured.
An undocumented methodology does not mean that the audit is over, only that there is almost no other circumstance for which the systems audit professional can come to a positive conclusion for the systems development area. The auditor still needs to discuss the answers to the remaining questions so that a preliminary opinion can be formed. This gives the auditor the opportunity to advise the information systems staff on whether formalizing their informal methodology will be sufficient, or whether they should consider changes or improvements before making the effort to formalize the existing procedures.
What Are the Stages in the Methodology?
The common elements discussed earlier will be present in some form in every development methodology unless someone in the enterprise has specifically decided to eliminate it for business or cultural reasons. Variations between projects are more likely, such as not comparing alternatives in a situation where a completely new idea is being pursued, and no one else is going to have a product that would be a competitor.
The phases will also differ based on the type of methodology in use by the enterprise. The methodology may have eight or more phases if it has its roots 10 to 15 years in the past when it was considered more important to have every activity and decision fully documented, reviewed, and formally approved by two or more persons. On the other hand, the entire process may only have three phases in todays environment of total quality, continuous improvement, and employee empowerment.
Either of these alternatives can be well controlled and completely appropriate for an enterprise, as well as a myriad of other alternatives in between. The number of people in the information systems department, and how many of them are assigned to systems development, is also likely to be significant. Until the number is large enough to reach critical mass, any formal methodology is likely to be unreliable due to a lack of segregation of duties through the program implementation/change control process.
The number of people required to reach critical mass is not a fixed value, so the systems audit professional will have to exercise judgment when forming an opinion on the development methodology, the adequacy of the development staff size, and what recommendations are appropriate for the circumstances.
Are There Deliverables?
Deliverables are important because they have the potential to provide substantial value to the enterprise. Each systems development life cycle phase represents a milestone in that certain objectives should have been met, decisions made, data gathered or analyzed, etc. The least deliverable may be a one- or two-paragraph memo that documents a judgmental decision made without any other support, but even that decision can now be evaluated, if needed.
The IT Audit Professional will have to evaluate the deliverables based on the situational considerations, although there are certain assumptions that can be made. The minimum deliverables should be defined in advance, and examples provided so the person preparing the deliverable has complete information and thus the best chance to efficiently develop an effective deliverable.
Previous | Table of Contents | Next |