Previous Table of Contents Next


Section 10
Systems Development Process

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 process of developing an application is often described as the Systems Development Life Cycle (SDLC). The subject is covered at length in P07, and is one half of the purpose for this publication. It is included here because gaining a basic understanding of SDLC methodology while reviewing the general controls environment should facilitate future application reviews.

This process is a cycle because there are common elements to every development effort. The elements may have different specifications and levels of formality, but the same objectives are generally satisfied by the end of the cycle.

The common elements can be described as:

  Recognize a need or opportunity.
  Identify and evaluate alternatives.
  Decide whether to implement. If yes:
—Develop or acquire a solution.
—Test and implement the solution.
—Plan for maintenance and enhancement.
—Perform post-implementation review.

GENERAL OBJECTIVES

The following objectives should apply to all application development activities, regardless of their size, as defined by the internal and external resources required to complete their development. The development effort size has an effect on what is required to meet these objectives because it is not reasonable to hold a project taking 40 hours to the same standard as one requiring 4000 hours. General objectives are:

  Development activities should always support either the strategic or tactical objectives of the enterprise.
  Development projects requiring approval for funding and resources through a capital expenditure request (or other similar) process should include mechanisms to ensure that all costs are captured and monitored in a manner that is consistent with company guidelines.
  Application security should complement the overall security approach taken within the enterprise.
  Application design and testing should ensure that the application will be available and responsive to the needs of the involved end users of the application.

SPECIFIC OBJECTIVES

Each one of the following systems development life cycle elements should meet specific objectives to increase the likelihood that the general objectives previously described are met by the time an application has been implemented. The following objectives generally can be tailored to fit the specifics of a particular 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. Company employees should be trained so that they can effectively recognize these situations, because they 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 that includes general business issues, specific business issues, and the expected effect on revenues and expenses. This policy should include a form or format for all of the appropriate information so that anyone reviewing the proposed application can see that all preliminary work has been completed before submitting the request. Any form or process used should reduce or eliminate the risk that applications will never be considered because of the effort or difficulty involved in performing this evaluation.

Making a Decision. There should be a place to record the authorization of the person or persons making the decision for accountability in the event of a question. The authorization should be on the form or attached to the forms defining the application and the 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 a solution is developed or acquired 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.

Test and Implement the Solution. 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. Application data should be converted or migrated in a way that ensures the integrity of that information and eliminates the risk of loss to the enterprise. Implementation procedures should include making the change overnight, on a weekend, or after a financial closing or other time when the problems resulting from an incomplete implementation are minimized.

The implementation procedures should include a method for stopping the process, backing out changes, and falling back to the prior application if necessary, and if possible, to reduce the risk that the enterprise will be without the functionality of the application in the event of a problem.

Final Documentation. The systems, operations, and end-user documentation that is being developed throughout the development project should be finalized once the application is considered to be fully implemented so that it will reflect all final changes and corrections as well as a complete understanding of the lessons learned through the final development and implementation activities.

Post-implementation Review of the Application. Conducting a review after an application is implemented seems to contradict many of the modern business initiatives related to total quality and continuous improvement. Performing such a review is critical if the enterprise personnel are to learn to perform future development activities more effectively. The risk in performing these reviews is that they can become punitive instead of informative.

The IT auditor should conduct a basic review of the systems development process by using the sequence of information in the subsequent paragraphs. A preliminary review to gather and evaluate the basic information should be prepared as part of the general controls review.

Basic information can be gathered by obtaining answers to this list of questions:

  Is there a methodology?
  Is it documented?
—What are the phases?
—Are there deliverables?
—Are samples or examples provided?
—What compliance or enforcement method is in place?
—Does it include the recognition of need, authorization for expenditure or project justification, development of specifications, programming and testing, training and documentation, and implementation and conversions?
  Is anything in place for emergency maintenance?
  Are any change management procedures in place?
  Are post-implementation reviews conducted?
  How are priorities established and changes accommodated?

Methodology

The company should have a methodology to ensure that systems are implemented using techniques designed to provide effective systems without taking unacceptable risks that would hamper the enterprise’s ability to do business. If there is no methodology, the IT auditor is likely to be told that the enterprise is relying on the IT employees to implement the systems properly.

Even without having any personal knowledge of the people on the IT staff, the IT auditor can be assured that the systems staff is likely to have differing beliefs about what the most effective development and implementation approach is for the enterprise. Beyond this, the individual pressures to perform are likely to lead the IT auditor to take shortcuts and to fail to comply with even their own set of proper procedures.


Previous Table of Contents Next