Previous | Table of Contents | Next |
Documentation
Is it documented? is an important follow-up question when the IT auditor is told that a methodology is in place and followed. A documented methodology is available to all of the systems developers, and it should not be necessary to interpret oral instructions. If the plan is not documented, the IT auditor will not be able to rely on the methodology because compliance cannot be tested and measured.
An undocumented methodology does not mean that the audit is finished, but that almost no other circumstances exist in which the IT auditor can come to a positive conclusion about the systems development area. The auditor still needs to discuss the answers to the remaining questions so that a preliminary opinion can be formed. A preliminary opinion gives the auditor the opportunity to advise the IT 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.
The Phases of Systems Development Methodology
The common elements of systems development methodology discussed earlier in this section are 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, such as not comparing alternatives in a situation in which a completely new idea is being pursued and believing that no competition exists, are more likely.
The phases also differ based on the type of systems methodology that the enterprise uses. 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 have only 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 myriad 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 and change control process.
The number of people required to reach critical mass is not a fixed value. Therefore, the IT auditor must 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.
The 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, and data gathered or analyzed. The smallest deliverable may be a one- or two-paragraph memo that documents a subjective decision made without any other support, but even that decision can be evaluated if needed.
The IT auditor evaluates the deliverables based on the circumstances, although certain assumptions can be made. The minimum deliverables should be defined in advance, and examples provided so that the person preparing the deliverable has complete information and the opportunity to develop an effective deliverable efficiently.
Providing Sample Deliverables. Example documents ensure that project by project deliverables are of the appropriate quality. In addition, the IT auditor can review the sample deliverables and establish a benchmark for auditing the deliverables in specific systems development projects. By reviewing the sample deliverables, the IT auditor has the opportunity to form opinions and develop recommendations that could affect the deliverables on any active and all potential future projects. This review may also foster improved relations with the internal customers because the review of a sample is objective, and the review of a deliverable in any specific project will more directly affect the involved information systems personnel.
System Compliance and Change Management Procedures
Systems development life cycle deliverables, being closely associated with project milestones, are more reliable when they are mandatory and not optional. For many enterprises, it has not been considered unreasonable to require a completed deliverable, including time for review and approval, before any work on the next phase can begin. Without such a requirement for production, there is a risk that other priorities will displace the deliverable, or at least delay it such that it has little value other than for providing information about the phase long after it is over and the next phase has begun.
Change Management Procedures. Most IT auditors should be familiar with the phrase program change controls because this phrase covers the identity of persons able to move programs into the production environment and specifies the procedures that must be followed. Program change controls developed with a limited focus on one type of change within the IT function. Over time, this focus expanded to encompass all of the changes that could affect information systems, with an emphasis on the ones that could affect or disrupt the production environment on the system. This expanded focus is referred to as change management. Change management should cover any change within the IT function that has the potential, directly or indirectly, to have a negative effect on the operating environment.
The environmental effects the IT auditor is most concerned about are those that could cause system functioning to be unexpectedly disrupted; those that could cause existing approved programs to function in unexpected and potentially unauthorized ways; and those that result in unauthorized programs being introduced into the systems environment and then functioning in an unauthorized fashion.
Emergency Maintenance Procedures. In every situation, whether applications are completely custom coded or purchased and processed without any customization or changes, applications can fail without warning and require immediate attention to resume normal processing. This attention or maintenance is therefore usually performed with little notice, performed in isolation, and performed while violating any standards program change control procedures.
The IT auditor should determine whether procedures for identifying emergency maintenance situations and for performing at least some of the critical control procedures after the fact exist. These emergency maintenance procedures should limit the exposure of an enterprise to an unauthorized change because the person making the change should easily be identified if there is a subsequent problem with the emergency change made.
Post-Implementation Reviews. Post-implementation reviews can be an effective technique with total quality and continuous improvement benefits if conducted in a positive manner. Emphasizing the positives protects individual personalities and gives people a chance to obtain the information that they need to perform more effectively during the next systems development life cycle project. Performing more effectively on the next systems development life cycle includes:
Previous | Table of Contents | Next |