Raising the Drawbridge

One of our CFE Chapter members has had a request from her employer to assist an internal IT systems development team with fraud prevention controls during the systems development life cycle process of a new, web-based, payment application.  Evaluating and assessing the effectiveness of anti-fraud controls on the front end is much more efficient (and far less costly) than applying them on the back end on an emergency basis during or after a fraud investigation.  Our member asked us for a run down on the typical phases of a systems development project.

First off, in any systems development project the employment of a predefined set of “best practices” is generally viewed as having a positive impact on the overall quality of the system being developed. In the case of the systems development life cycle (SDLC), some generally accepted developmental practices can provide additional benefits to a CFE in terms of his or her proactive, fraud prevention control assessment. Specifically, throughout the eight steps of the SDLC, documentation is routinely created that provides valuable potential sources of control description for review. In other words, just employing generally accepted SDLC practice as prescribed in the CFE’s client’s industry is a powerful fraud prevention control in itself.

The first phase of the SDLC, system planning, is relatively straight-forward.  Executives and others evaluate the effectiveness of the proposed system in terms of meeting the entity’s mission and objectives. This process includes general guidelines for system selection and systems budgeting. Management develops a written long-term plan for the system that is strategic in nature. The plan will most probably change in a few months, but much evidence exists that such front-end planning pays dividends in terms of effective and well controlled IT solutions over the long term. CFEs can think of this phase of the life cycle as like IT governance, and the two are quite compatible. Thus, the first thing the CFE (or any auditor) would like to see is evidence of the implementation of general IT governance activities.  During this phase, several documents are typically generated. They include the long-term plan of development of the specific system within the context of the overall policies for selection of IT projects, and a short-term and long-term budget for the project, as well as a preliminary feasibility study and project authorization. Every project proposal should be documented in writing when originally submitted to management, and a master project schedule should exist that contains all the client’s approved developmental projects.  The presence of these documents illustrates a structured, formal approach to systems development within the client operation and, as such, evidences an effective planning system for IT projects and for systems in general. It also demonstrates a formal procedure for the approval of IT projects.  The CFE should add all the documents for this phase of the project under review to his or her work paper file and gather the same level of documentation for each of the subsequent SDLC cycles.

The systems analysis phase is the second in which IT professionals gather information requirements for the project. Facts and samples to be used in the IT project are gathered primarily from end users. A systems analyst or developer then processes the requirements, and produces a document that summarizes the analysis of the project.  The result is usually a systems analysis report. The systems analysis phase and its report should illustrate to the CFE the entity’s ability to be thorough in the application of its systems development process.

Phase three is the conceptual design phase. In phase two systems analysis, the requirements have been gathered and analyzed. Up to this point, the project is on paper and each of the future systems user groups will have a slightly different view of what it is and will be; this is totally normal and to be expected. At this point, a conceptual design view is developed that encompasses all the individual views. Although, a variety of possible documents could be among the total output of this phase, a data flow diagram (DFD), developed at a general level, is always the final, principal product of this phase.  For the CFE, the general DFD is evidence that the client is acting in accordance with a generally accepted SDLC framework.

Next comes phase four, systems evaluation and selection. Managers and IT staff choose among alternatives that satisfy the requirements developed in phases two and three, and meet the general guidelines and strategic policies of phase one. Part of the analysis of alternatives is to do a more exhaustive and detailed feasibility study, actually, several types of feasibility studies. A technical feasibility study examines whether the current IT infrastructure makes it feasible to implement a specific alternative. A legal feasibility study examines any legal ramifications of each alternative. An operational feasibility study determines if the current business processes, procedures and skills of employees are adequate to successfully implement the specific alternative. Last, a scheduling feasibility study relates to the firm’s ability to meet the proposed schedule for each alternative. Each of these should be combined into to a written feasibility report.

At the beginning of detail design, phase five, IT professionals have chosen the IT solution. The DFD design created in phase three is “fleshed out”; that is, details are developed and (hopefully) documented. Examples of some of the types of documentation that might be created include use cases, Unified Modeling Language (UML) diagrams, entity relationship diagrams (ERDs), relational models and normalized data diagrams.  IT professionals often do a walk-through of the software or system at this point to see if any defects in the system can be detected during development. The results of the walk-through should also be documented. To summarize this phase, a detailed design report should be written to explain the steps and procedures taken. It would also include the design documents referred to previously.

Phase six, programming and testing, includes current best practices like the use of object-oriented programs and procedures. No element of the SDLC is more important for CFEs than systems testing. Perhaps none of the phases has been more criticized than testing for being absent or performed at a substandard level. Sometimes management will try to reduce the costs of an IT project by cutting out or reducing the testing. Sound testing includes several key factors. The testing should be done offline before being implemented online. Individual modules should be tested, but even if a module passes the test, it should be tested in the enterprise system offline before being employed. That is, the modules should be tested as stand-alone and then, in conjunction with other applications, tested system wide. Test data and results should be kept, and end users should be involved in the testing.

Phase seven, implementation, represents system deployment.  The last step before deployment is a user acceptance sign-off. No system should be deployed without this acceptance. The user acceptance report should be included in the documentation. After deployment, however, the SDLC processes are not finished. One key step after implementation is to conduct a postimplementation review. This reviews the cost-benefit report, traces actual costs and benefits, and sees how accurate the projections were and if the project produces an adequate return.

The last and eighth phase is system maintenance.  The ACFE tells us that 80 percent of the costs and time spent on a software system, over its life cycle, occur after implementation. It is precisely for this reason that all of the previously mentioned SDLC documentation should be required. Obviously, the entity can leverage the 80 percent cost by providing excellent documentation. That is the place for the largest cost savings over the life of the system. It is also the argument against cutting corners during development by not documenting developmental steps and the system itself.

I’ll conclude by saying that by proactively consulting on fraud prevention controls and techniques during the SDLC, CFEs can verify that SDLC best practices are operating effectively by examining documentation to identify those major fraud related issues that should be addressed during the various phases. Of course, CFEs would certainly use other means of verification, such as inquiry and checklists as well, but the presence of proper SDLC documentation illustrates the level of application of the best practices in SDLC. Finally, a review of a sample of the documents will provide evidence that the entity is using SDLC best practices, which provides some assurance that systems are being developed efficiently and effectively so as to help raise the drawbridge on fraud.

Comments are closed.