6 step of systems development methodology in audit perspective

The SDLC is designed to produce high-quality software in a structured way that minimizes risk. The traditional approach to SDLC is the waterfall model, which contain 6 step of implementation. ISACA uses a modified model that has five primary phases and the post implementation phase.

Phase 1: Feasibility
In this step, the feasibility of the project is considered. The cost of the project must be discussed, as well as the potential benefits that it will bring to the system’s users. A payback analysis must be performed to determine how long the project will take to pay for itself. In other words, the payback analysis determines how much time will lapse before accrued benefits will overtake accrued and continuing costs. If it is determined that the project will move forward, the team will want to develop a preliminary timeline. During the feasibility phase, everyone gets a chance to meet and understand the goals of the project.

Phase 2: Requirements Definition
This phase entails fully defining the need and then mapping how the proposed solution meets the need. This requires the participation of management as well as users. Users should also be involved because they should have input on how the applications are designed. At this phase, an entity relationship diagram (ERD) is often used. An ERD helps map the requirements and define the relationship between elements. The basic components of an ERD are an entity and a relationship. An entity is very much like a database, in that it is a grouping of like data elements. An entity has specific attributes, which are called the entity’s primary key. Entities are drawn as a rectangular box with an identifying name. Relationships describe how entities are related to each other and are defined as a diamond. ERDs can be used to help define a data dictionary. When a data dictionary is designed, the database schema can be developed. The database schema defines the database tables and fields, and the relationship between

During the requirements phase, auditors must verify the requirements and determine whether adequate security controls are being defined. These controls should include the following mechanisms:
. Preventive—Preventive controls can include user authentication and data encryption.
. Detective—Detective controls can include embedded audit modules and audit trails.
. Corrective—Corrective controls can include fault tolerance controls and data integrity mechanisms.

Phase 3: Design
During the design phase, users might not be involved, but the auditor will still be working in an advisory role. The auditor must again check that security controls are still in the design and test documents. Test plans should detail how security controls will be tested. Tests should be performed to validate specific program units, subsystems, interfaces, and backup/recovery. Change-control procedures should be developed to prevent uncontrolled changes.

There are ways to decrease design and development time. Reverse engineering is one such technique. Reverse engineering converts executable code into human-readable format and can be performed with tools such as IDA Pro. This is a somewhat controversial subject because, although reverse engineering has legitimate uses, a company could use it to disassemble another company’s program. Most software licenses make this illegal. Reverse engineering is also sometimes used to bypass access-restriction mechanisms.

Phase 4: Development
During the development phase, programmers work to develop the application code. Programmers might use online programming facilities so that many programmers can access the code directly from their workstation. Although this typically increases productivity, it also increases risk because someone might gain unauthorized access to the program library. Programmers should strive to develop modules that have high cohesion and low coupling. Cohesion addresses the fact that a module is focused on a single task. Coupling is the measurement of the interconnection between modules. Low coupling means that a change to one module should not affect another.

During development, auditors must verify that input and output controls, audit mechanisms, and file-protection schemes are used. Examples of input controls include dollar counts, transaction counts, error detection, and correction. Examples of output controls include validity checking and authorizing controls. Testing these controls and the functionality of the program is an important part of this phase.

Phase 5: Implementation
In the implementation phase, the application is prepared for release into its intended environment. Final user acceptance is performed, as are certification and accreditation. This is typically the final step in accepting the application and agreeing that it is ready for use. Certification is the technical review of the system or application. Certification testing might include an audit of security controls, a risk assessment, or a security evaluation. Accreditation is management’s formal acceptance of a system or application. Typically, the results of the certification testing are compiled into a report, and management’s acceptance of the report is used for accreditation. Management might request additional testing, ask questions about the certification report, or accept the results as is. Once accepted, a formal acceptance statement is usually issued.

Phase 6: Post-Implementation
In the post-implementation phase, some might be ready to schedule a party and declare success. What really needs to be done is to assess the overall success of the project. Actual costs versus projected costs should be reviewed to see how well cost-estimating was done at the feasibility phase. Return on investment (ROI) and payback analysis should be reviewed. A gap analysis can determine whether there is a gap between requirements that were or were not met. An independent group might conduct performance measurement, such as an audit. If this is the case, it should not be done by auditors who were involved in the SDLC process. Overall, post-implementation should answer the following questions:
. Is the system adequate?
. What is the true ROI?
. Were the chosen standards followed?
. Were good project-management techniques used?