System-Development Methodologies and Tools


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.

Table 6.1. Phases of the Traditional Systems-Development Life Cycle

SDLC Phase

General Description

Phase 1: Feasibility

Determine the strategic benefits of implementing the system either in productivity gains or in future cost avoidance, identify and quantify the cost savings of a new system, and estimate a payback schedule for costs incurred in implementing the system. This business case provides the justification for proceeding to the next phase.

Phase 2: Requirements

Define the problem or need that requires resolution, and define the functional and quality requirements of the solution system. This can be either a customized approach or a vendor-supplied software package, which would entail following a defined and documented acquisition process. In either case, the user needs to be actively involved.

Phase 3: Design

Based on the requirements defined, establish a baseline of system and subsystem specifications that describe the parts of the system, how they interact, and how the system will be implemented using the chosen hardware, software, and network facilities. (During the design phase of an application-development project, the IS auditor should strive to ensure that all necessary controls are included in the initial design.) Generally, the design also includes both program and database specifications, and a security plan. (Application controls should be considered as early as possible in the system-development process, even in the development of the project's functional specifications.) Additionally, a formal change-control process is established to prevent uncontrolled entry of new requirements into the development process.

Phase 4: Development

Use the design specifications to begin programming and formalizing supporting operational processes of the system. Various levels of testing also occur in this phase to verify and validate what has been developed.

Phase 5: Implementation

The actual operation of the new information system is established, with final user acceptance testing conducted in this environment. (Acceptance testing is used to ensure that the system meets user and business needs.) The system also may go through a certification and accreditation process to assess the effectiveness of the business application in mitigating risks to an appropriate level, and providing management accountability over the effectiveness of the system in meeting its intended objectives and in establishing an appropriate level of internal control.


In addition to following a structured approach to systems development, the IT organization must have a sound IT management methodology that includes the following:

  • Project management Utilizes knowledge, tools, and techniques to reach the goals of the project

  • IT organizational policies Ensures that organizational goals are fulfilled and business risks are reduced

  • Steering committee Ensures that the IS department closely supports the corporate mission and objectives

  • Change-management process Ensures that there is not uncontrolled entry of new requirements into the development process or existing systems

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:

  • Common Business Orientated Language (COBOL) and C programming Language High-level general-purpose languages.

  • C++ and Java Object-oriented languages.

  • SH (Shell), Perl, JavaScript, VBScript Scripting languages; primarily used in web development.

  • 4GL Fourth-generation high-level programming languages; are object-oriented but lack the lower-level detail commands.


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:

  • Review the system flowcharts for adherence to the general design. Verify that the appropriate approvals were obtained for any changes and that all changes were discussed and approved by appropriate user management.

  • Review the input, processing, and output controls designed into the system for appropriateness.

  • Interview the key users of the system to determine their understanding of how the system will operate, and assess their level of input into the design of screen formats and output reports.

  • Assess the adequacy of audit trails to provide traceability and accountability of system transactions.

  • Verify the integrity of key calculations and processes.

  • Verify that the system can identify and process erroneous data correctly.

  • Review the quality-assurance results of the programs developed during this phase.

  • Verify that all recommended corrections to programming errors were made and that the recommended audit trails or embedded modules were coded into the appropriate programs.

Prototyping

Prototyping 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 use of prototyping to develop applications systems often results in overly optimistic expectations of project timelines.

  • Change control becomes much more complicated because changes in design and requirements happen so quickly that they are seldom documented or approved.

  • Because of the iterative process, end users might define functions or extras that were not originally defined during the requirements phase. If not properly managed through a review and approval process, it can extend the cost and time required for the project.

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.

RAD

Rapid 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:

  • Small, well-trained development teams

  • Evolutionary prototypes

  • Integrated power tools that support modeling, prototyping, and component reusability

  • A central repository

  • Interactive requirements and design workshops

  • Rigid limits on development time frames

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 SDLC

As 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: Feasibility

In 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 Definition

The 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:

  • Users specify automated and nonautomated resource needs (access controls, regulatory restrictions, interface requirements, and so on) and how they want to have them addressed in the new system.

  • The IS auditor should verify that requirements are complete, consistent, unambiguous, verifiable, modifiable, testable, and traceable.

  • IS auditors should determine whether adequate security requirements have been defined for the new system.


Plans for testing for user acceptance are usually prepared in the requirements-definition phase of the systems-development project.


Phase 3: Design

Based 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).

  • A formal change-control process is established to prevent entry of new requirements into the development process.

  • Test plans are developed:

    • Unit (program)

    • Subsystem (module)

    • Integration (system)

    • Interface with other systems

    • Loading and initializing files

    • Security, backup, and recovery

  • The IS auditor is involved to ensure that an adequate system of controls is incorporated into the system specs and test plans, and to ensure that continuous online auditing functions are built into the system.


Procedures to prevent scope creep are baselined in the design phase of the system's SDLC model.


Phase 4: Development

Programming 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:

  • Program coding standards are essential to simply and clearly reading and understanding code without requiring review of specifications.

  • More cohesion (dedication to a single function) and less coupling (interaction with other functions) result in less troubleshooting and software-maintenance effort.

  • Logic path monitors can provide programmers with clues on logic errors.

  • Output analyzers validate processing accuracy.

  • Online programming facilities can increase programming productivity but can also increase risk of inappropriate access. An online programming facility stores the program library on a server, and developers use individual PC workstations to download code to develop, modify, and test.


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:

  • Bottom-up approach

    • Start testing with programs or modules, and progress toward testing the entire system.

    • Testing can be started before the entire system is complete.

    • Errors in critical modules are found early.

  • Top-down approach

    • Tests of major functions or processes are conducted early.

    • Interface errors can be detected sooner.

Testing levels identify the specific level of testing that will occur and are usually based on the size and complexity of the application:

  • Unit testing

  • Interface or integration testing

  • System testing

  • Recovery testing

  • Security testing

  • Stress/volume testing

  • Performance testing

  • Final acceptance testing

Phase 5: Implementation

Actual operation of the new system is established. Final user acceptance testing is conducted in this environment:

  • May include certification and accreditation processes

  • Includes implementation and migration plans. Implementation plans include procedures for setting up the production environment, connectivity and transaction testing, and user training. The migration plan includes data cleansing and conversion.



Exam Cram 2. CISA
Cisa Exam Cram 2
ISBN: B001EEFNHG
EAN: N/A
Year: 2005
Pages: 146

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net