2009 CISA Review Course

Chapter 3 Systems and Infrastructure Life Cycle Management

3.4.2 Project Planning

The project manager needs to determine:
The various tasks that need to be performed to produce the expected business application system The sequence or the order in which these tasks need to be performed The duration or the time window for each task The priority of each task The IT resources that are available and required to perform these tasks Budget or costing for each of these tasks Source and means of funding

3.4.2 Project Planning (continued)

Software size estimation
Relates to methods of determining the relative physical size of the application software to be developed Can be used as a guide for the allocation of resources, estimates of time and cost required for its development, and as a comparison of the total effort required by the resources available

3.4.2 Project Planning (continued)

Lines of source code
The traditional and simplest method in measuring size by counting the number of lines of source code, measured in SLOC, is referred to as kilo lines of code (KLOC)

3.4.2 Project Planning (continued)

Function point analysis
Widely used for estimating complexity in developing large business applications The results of FPA are a measure of the size of an information system based on the number and complexity of the inputs, outputs, files, interfaces and queries with which a user sees and interacts

3.4.2 Project Planning (continued)

FPA feature points Cost budgets Software cost estimation

3.4.2 Project Planning (continued)

Scheduling and establishing the time frame
Involves establishing the sequential relationship among tasks The schedule can be graphically represented using various techniques such as Gantt charts or Program Evaluation Review Technique (PERT) diagram

3.4.2 Project Planning (continued)

Critical path methodology
A critical path if one whose sum of activity time is longer than that for any other path through the network The critical path is found by working forward through the network (forward-pass) and computing the earliest possible completion time for each activity until the earliest possible completion time for the total project is found

3.4.2 Project Planning (continued)

Gantt charts
Constructed to aid in scheduling the activities (tasks) needed to complete a project Charts show when an activity should begin and end Charts show which activities can be in progress concurrently and which activities must be completed sequentially

3.4.2 Project Planning (continued)

Program evaluation review technique (PERT)
PERT is a network management technique often used in system development projects based on well-defined events and activities for specific project management tasks

3.4.2 Project Planning (continued)

Timebox management
Project management technique for defining and deploying software deliverables within a relatively short and fixed period of time and with predetermined specific resources

3.4.3 General Project Management

Involves automated techniques to handle proposals and cost estimations, and to monitor, predict and report on performance with recommended action items Many of these techniques are provided as decision support systems (DSS) for planning and controlling project resources

3.4.5 Closing a Project

When closing a project, there may still be some issues that need to be resolved, ownership of which needs to be assigned The project sponsor should be satisfied that the system produced is acceptable and ready for delivery Custody of contracts may need to be assigned, and documentation archived or passed on to those who will need it

3.7 Alternative Forms of Software Project Organization

Other approaches an IS auditor may encounter include:
Incremental or progressive development Iterative development
Evolutionary development Spiral development Agile development

3.7.1 Agile Development

Agile development refers to a family of similar development processes that espouse a nontraditional way of developing complex systems. Agile development processes have a number of common characteristics, including: The use of small, time-boxed subprojects or iterations Replanning the project at the end of each iteration Relatively greater reliance on tacit knowledge Heavy influence on mechanisms to effectively disseminate tacit knowledge and promote teamwork A change in the role of the project manager

3.7.2 Prototyping
The process of creating a system through controlled trial and error procedures to reduce the level of risks in developing the system Reduces the time to deploy systems primarily by using faster development tools such as fourth-generation techniques Potential risk is that the finished system will have poor controls Change control often becomes more complicated

3.7.3 Rapid Application Development

A methodology that enables organizations to develop strategically important systems quickly, while reducing development costs and maintaining quality Achieved through the use of:
Small, well-trained development teams Evolutionary prototypes Integrated power tools A central repository Interactive requirements and design workshops Rigid limits on development time frames

3.8.6 Reverse Engineering

The process of taking apart an application, a software application or a product to see how it functions, and to use that information to develop a similar system Major advantages:
Faster development and reduced SDLC duration Creation of an improved system using the reverse-engineered application drawbacks

3.9.4 Hardware Acquisition

For acquiring a system, the invitation to tender (ITT) should include the following:
Organizational descriptions Information processing requirements Hardware requirements System software applications Support requirements Adaptability requirements Constraints Conversion requirements

3.9.5 System Software Acquisition

When selecting new system software, the following technical issues should be considered:
Business, functional, technical needs and specifications Cost and benefits Obsolescence Compatibility with existing systems Security Demands on existing staff Training and hiring requirements Future growth needs Impact on system and network performance

3.9.7 System Software Change Control Procedures

All test results should be documented, reviewed and approved by technically-qualified subject matter experts prior to production use Change control procedures are designed to ensure that changes are authorized and do not disrupt processing

3.10.1 Change Management Process Overview

Change management process begins with authorizing changes to occur Requests initiated from end users, operational staff and system development/maintenance staff Change requests should be in a format that ensures all changes are considered for action and that allows the system management staff to easily track the status of the request All requests for changes should be maintained by the system maintenance staff as part of the systems permanent documentation

3.10.1 Change Management Process Overview (continued)

Deploying changes Documentation Testing changed programs Auditing program changes Emergency changes Deploying changes back into production Change exposures (unauthorized changes)

3.10.2 Configuration Management

Maintenance requests must be formally documented and approved by a change control group Careful control is exercised over each stage of the maintenance process via checkpoints, reviews and signoff procedures From an audit perspective, provides evidence of managements commitment to careful control Involves procedures throughout the software life cycle

3.10.2 Configuration Management (continued)

As part of the software configuration management task, the maintainer performs the following tasks:
Develop the configuration management plan Baseline the code and associated documents Analyze and report on the results of configuration control Develop the reports that provide configuration status Develop release procedures Perform configuration control activities Update the configuration status accounting database

3.11.2 Computer-aided Software Engineering

CASE is the use of automated tools to aid in the software development process May include the application of software tools for software requirements analysis, software design, code production, testing, document generation and other software development activities Three categories:
Upper CASE Middle CASE Lower CASE

3.11.2 Computer-aided Software Engineering (continued)

Key issues an IS auditor needs to consider with CASE include:
CASE tools do not ensure that the design, programs and system are correct or that they fully meet the needs of the organization CASE tools should complement and fit into the application development methodology The integrity of data moved between CASE products needs to be monitored and controlled Changes to the application should be reflected in stored CASE product data

3.12.1 Business Process Reengineering and Process Change Projects (continued)

The steps in a successful BPR are:
Define the areas to be reviewed Develop a project plan Gain an understanding of the process under review Redesign and streamline the process Implement and monitor the new process Establish a continuous improvement process

3.14 Auditing Application Controls

An IS auditors tasks include the following:
Identifying the significant application components and the flow of transactions through the system Identifying the application control strengths and evaluating the impact of the control weaknesses to develop a testing strategy by analyzing the accumulated information Reviewing application system documentation to provide an understanding of the functionality of the application

3.14.5 Data Integrity in Online Transaction Processing Systems

The ACID principle:
Atomicity Consistency Isolation Durability

3.14.7 Continuous Online Auditing

Provides a method for an IS auditor to collect evidence on system reliability while normal processing takes place Continuous audit techniques are important IS audit tools, particularly when used in a time-sharing environment that process a large number of transactions with a scarce paper trail

3.14.8 Online Auditing Techniques

There are five types of automated evaluation techniques applicable to continuous online auditing:
Systems Control Audit Review File and Embedded Audit Modules (SCARF/EAM) Snapshots Audit hooks Integrated test facility (ITF) Continuous and intermittent simulation (CIS)