Previous Table of Contents Next


Section 16
Performing a Complete Evaluation

Controls over applications development should ensure that applications are only developed or acquired in ways that support the appropriate strategic or tactical interests of the organization. The IT Audit Professional will discover that there are a variety of ways a particular organization may choose to organize the development process, or development methodology.

It is possible to utilize a standard methodology for developing and maintaining applications because experience has shown that there are common activities to every development and maintenance effort. The common activities are described in the following list.

  Recognizing an opportunity or need.
  Identifying and evaluating alternatives.
  Making a decision to either implement one of the alternatives, defer it, or to discontinue any further consideration of it.
  Developing or acquiring the application code needed to realize the selected alternative. The IT Auditor should note that acquiring an application can be much less costly than developing one, if a purchased alternative can be found that is either able to fully meet the requirements or can be modified to do that with only a reasonable effort.
  Implementing the new application once the activities included in the prior step are complete.
  Correcting problems identified during implementation, and completing end-user and system documentation.
  Conducting a post-implementation review to evaluate the system as developed and implemented.

Each methodology encompassing these activities effectively guides the organization through the life of the development project. This led systems professionals to describe the development process as the Systems Development Life Cycle (SDLC). The SDLC in the organization under review should encompass the following general control objectives.

GENERAL CONTROL OBJECTIVES

The organization’s SDLC should be able to address the following general control objectives, regardless of the size of the project. The size of the project could be defined using only cash expenditures, the number of full-time-equivalent (FTE) working days, or the total of tangible and intangible costs. The control objectives can be addressed in different ways, as it is unreasonable to expect that projects requiring 40 hours to complete can be easily compared to projects requiring 4000 hours to complete.

1.  Development activities should always support either the strategic or tactical objectives of the enterprise.
2.  Development projects requiring approval for funding and resources should include mechanisms to ensure that all costs are captured and monitored in a manner that is consistent with company guidelines.
3.  Application security should complement the overall security approach taken within the enterprise.
4.  Application design and testing should ensure that the application would be available and responsive to the needs of the application end users.

Specific Objectives

Each one of the systems development life cycle’s common elements should meet specific objectives to increase the likelihood that the general objectives described above are met. The specific objectives described below are not meant to be all-inclusive, and can be modified or supplemented to better fit the specifics of the situation.

Recognizing Needs or Opportunities. The enterprise should develop mechanisms to promote this recognition so that problems are solved and opportunities are capitalized on in an effective manner. To make these mechanisms effective, company employees should receive specific training so they are better able to recognize these situations, as recognizing these situations can be advantageous to both the employee and to the enterprise.

Evaluating Alternatives and Details. The enterprise should have a policy that provides for assessing the proposed application, which includes general business issues, specific business issues, and the expected impact on revenues and expenses. This policy should include a form or at least a format for all of the appropriate information so that anyone looking at the proposed application can see that the homework has been done prior to submitting the request.

The IT Audit Professional should evaluate this form to ensure that it is not so complex that completing the form discourages company personnel from making the effort because they are unsure of the significance of their idea. The risk of never identifying an important opportunity can be more harmful to the organization than the resources spent on documenting applications the organization chooses not to pursue.

Making a Decision. There should be a place to record the authorization of the person or persons making the decision so there is later accountability in the event of a question. The authorization should be on the form or attached to the forms defining the application and work being requested to reduce the risk of misunderstanding or erroneous approval of the wrong specifications.

Develop or Acquire the Solution. Procedures should be in place to see that this is done on a timely basis. All costs should be in accordance with the approved request, and any potential overruns exceeding a predetermined threshold should go back to the persons authorizing the original activity so that any approval or denial of additional expenditures is consistent with the original decision.

Detailed specifications should be developed so that whether the application is acquired or developed, the information is available to make the application most effective in terms of meeting the needs as specified. These specifications should be the foundation for corresponding testing activities. Testing procedures should be included that test both individual programs and functions of the application but also the application taken as a whole, including the interfaces to other systems.

Implementing the New Application. When implementing any solution that includes data which already exists in the organization, care should be taken to ensure that the data is either converted or migrated in a way that ensures the integrity of that information and eliminates the risk of data loss to the enterprise.

Implementation procedures should also provide for making the actual change to the production environment either overnight, over a weekend, or during any other time when the production environment cannot be interrupted. This is one way to protect the continuity of business within the organization.

The implementation procedures should also include procedures for stopping the implementation, reversing the changes made through the stopping point, and falling back to the prior application. This backout procedure also protects the organization’s continuity, like the timing of the implementation does.


Previous Table of Contents Next