A Software Development Life Cycle is a logical process that systems analysts and systems developers use to develop software (applications). The SDLC should produce high-quality software that meets or exceeds business and user requirements, is produced within time and cost estimates, is efficient and effective, and provides for cost-effective maintenance and enhancement. The most common SDLC is the Classic Life Cycle Model, which can be either the Linear Sequential Model or the Waterfall Method. The SDLC is a framework, and specific activities in the framework will vary by organization. Figure 6.1 shows the high-level phases associated with a waterfall SDLC. Figure 6.1. The Waterfall SDLC.
The waterfall methodology is the oldest and most commonly used approach. It begins with the feasibility study and progresses through requirements, design, development, implementation, and post-implementation. It is important to remember that, in using this approach, the subsequent step does not begin until all tasks in the previous step are completed. When the process has moved to the next step, it does not go back to the previous step. The waterfall approach is best used in environments where the organization's requirements will remain stable and the system architecture is known early in the development process. Per ISACA, Table 6.1 describes the phases associated with the traditional systems-development life cycle approach.
In addition to following a structured approach to systems development, the IT organization must have a sound IT management methodology that includes the following:
To improve software life-cycle processes and software-processing capability, the organization can implement the Software Capability Maturity Model (CMM), developed by Carnegie Melon's Software Engineering Institute. Software process maturity is the extent to which a specific process is explicitly defined, managed, measured, controlled, and effective. The more mature an organization's software process is, the higher the productivity and quality are of the software products produced. As software process maturity increases, the organization institutionalizes its software process via policies, standards, and organizational structures. This institutionalization entails building an infrastructure and a corporate culture that support the methods, practices, and procedures of the business so that they endure after those who originally defined them have gone. Figure 6.2 shows the CMM maturity levels. Figure 6.2. CMM maturity levels.
A standard software-development process is included within Level 3 (defined) of the Software Capability Maturity Model (CMM). For the organization to ensure the production of high-quality software that meets or exceeds business and user requirements, it must be produced within time and cost estimates, be efficient and effective, and provide for cost-effective maintenance. This can be accomplished only with an efficient SDLC process. In addition to the life-cycle phases, the organization must utilize formal programming methods, techniques, languages, and library control software. The utilization of formal coding standards ensures the quality of programming activities and enhances future maintenance capabilities. Program coding standards serve as a control that enables clear communication among members of the programming team and between the programming team and the users. These standards should include methods of source code documentation, methods of data declaration, and naming standards.
Coding standards promote compliance with accepted field-naming conventions. In application development, programs are coded into statements that are then translated by the compiler into machine language. The language chosen will vary by the organization and will be based on the existing environment, skills sets, and application requirements. These are the commonly used programming languages and their attributes:
Fourth-generation languages (4GLs) are most appropriate for designing the application's graphical user interface (GUI). They are inappropriate for designing any intensive data-calculation procedures. Throughout the SDLC, it is important to protect the integrity of source code and executables. This integrity is maintained through the use of production source code and production libraries. The library control software provides access control to ensure, as an example, that source code is accessible only in a read-only state. The organization should have procedures in place to ensure proper access levels and segregation of duties. As an example, users and application programmers should not have access to the production source code. Per ISACA, IS auditors should perform the following functions during the design and development SDLC phases:
PrototypingPrototyping is the process of developing a system through the rapid development and testing of code. This process uses trial and error to reduce the level of risks in developing the system. In general, prototyping reduces the time required to deploy applications through iterative development and testing. The developers create high-level code (mostly 4G languages) based on the design requirements and then provide them to the end users for review and testing. The end users can then see a high-level view of the system (generally screens and reports) and provide input on changes or gaps between the code and requirements. A couple major challenges are associated with prototyping:
The IS auditor should be aware of risks associated with prototyping and ensure that the organization has implemented the proper controls to ensure that the project continues to meet the needs of the organization while providing a return on investment. These controls should be found in the project-management process as well as the change-control process. Both processes should have controls for the regular review and approval of changes in requirements, schedule, or cost. RADRapid application development (RAD) is used to develop strategically important systems faster, reduce development costs, and still maintain high quality. The organization should use a prototype that can be updated continually to meet changing user or business requirements. According to ISACA, this is achieved by using a series of proven application-development techniques within a well-defined methodology:
Although RAD supports analysis, design, development, and implementation, the initial development is based on requirements that are best understood. This reduces the time associated with traditional requirements gathering and documentation. The requirements (specification), development, and implementation are intertwined, allowing for the delivery of the application in phases. Most organizations have built their processes around a waterfall method of development and might not have the specialized skill sets or supporting processes required for RAD development. The IS auditor must ensure that the processes and skill sets support RAD development. The Phases of the SDLCAs stated earlier, there are five distinct phases in the SDLC. In the Waterfall Model, each of these phases has specific tasks and outcomes; the next phase does not start until the tasks and outcomes of the previous phase have been completed. The SDLC helps to ensure the software will meet user and business needs. Therefore, failing to adopt a systematic approach to application development such as that illustrated by the SDLC increases the risk that the system will not ultimately meet business and user needs. The following sections discuss the detailed tasks and outcomes associated with the five phases of the SDLC. Phase 1: FeasibilityIn this phase, the cost savings of a new system are identified and quantified, and the payback schedule for costs incurred in implementing the system is estimated. This provides the justification for proceeding to Phase 2. Phase 2: Requirements DefinitionThe need that requires resolution is defined and then mapped to the major requirements of the solution. It is critical to involve all management and the end-user business function in this phase, to make sure the new system supports business needs:
Plans for testing for user acceptance are usually prepared in the requirements-definition phase of the systems-development project. Phase 3: DesignBased on the requirements defined in Phase 2, a baseline of specifications for systems is established (application users need not be judiciously involved in this phase). The IS auditor should be allowed to participate in the design phase of the software in an overseeing advisory capacity: Establishing the baseline of specifications is one control used to prevent scope creep during the development phase. Scope creep occurs when new requirements are gradually added and exceed the requirements stated in the baseline of specifications. Although individual new requirements might appear small, they can have a cumulative effect on the cost or time associated with the project (scope creep).
Procedures to prevent scope creep are baselined in the design phase of the system's SDLC model. Phase 4: DevelopmentProgramming and testing of the new system occurs in this phase. The tests verify and validate what has been developed. The responsibilities in this phase rest primarily with programmers and systems analysts who are building the system:
Online programming can lower development costs, reduce response time, and expand programming resources available. Its disadvantages, however, include reduced integrity of programming and processing; in addition, version control and valid changes can be overwritten by invalid changes. Test plans identify specific portions of the application that will be tested, as well as the approach to testing:
Testing levels identify the specific level of testing that will occur and are usually based on the size and complexity of the application:
Phase 5: ImplementationActual operation of the new system is established. Final user acceptance testing is conducted in this environment:
|