MODULE 3: INFORMATION SYSTEMS ACQUISITION,

DEVELOPMENT AND IMPLEMENTATION

PART A: INFORMATION SYSTEMS ACQUISITION AND
DEVELOPMENT
 INTRODUCTION
 For an I.S auditor to provide assurance on information systems, its important
that he understands how an organization evaluates, develops, implements,
maintains and disposes of its information systems and related components.
 PROJECT GOVERNANCE AND MANAGEMENT
 In order to identify relationships among concurrently running projects, a
common approach is to establish a project portfolio and/ or a program
management structure.
 This assists in:
 identifying common objectives for the business organization
 identifying and managing risks
 identifying resource connections
 All projects require governance structures, policies and procedures, and
specific control mechanisms to assure strategic and tactical alignment with
the org’s respective goals, objectives and risk Mngt strategy.
 Without proper governance, all aspects of a project may be compromised.
 All governance decisions about the project should be driven through the
business case, and there must be periodic review of the benefits achieved.
 PROJECT GOVERNANCE AND MANAGEMENT
 Effective and efficient project management requires that projects be
managed based on hard factors such as deliverables, quality, costs and
deadlines; on soft factors such as team dynamics, conflict resolution,
leadership issues, cultural differences and communication; and on
environmental factors such as the political and power issues in the
sponsoring organization.
 The role of an I.S auditor is to ensure that rules of system development , as
they relate to segregation of duties (SoD) and responsibilities, are not
compromised.
 I.S auditors must be familiar with the project management approaches and
standards in use within their org. prior to involvement in specific projects.

NOTE: CISA candidates will not be tested on their knowledge of any particular
project Mngt approach or std. However, they must understand the basic
elements of project Mngt structures, policies and procedures, and, more
specifically, related controls.
 PROJECT MNGT PRACTICES
 The project Mngt process begins with the project charter and ends with the
completion of the project.
 Project Mngt practices are initiating, planning, executing, controlling,
monitoring and closing a project.
 3 types of project Mngt organizational structures outline the authority and
control within an organization:
i. Functional-structured organization
 Project manager has only a staff function without a formal Mngt authority.
ii. Project-structured
 Project manager has formal authority over those taking part in the project,
budget, schedule and team.
iii. Matrix structured project organization
 Management authority is shared between the project manager and the
department heads.
 PROJECT MNGT PRACTICES
 Requests for major projects should be submitted to and prioritized by an IT
steering committee.
 The project manager (identified by the steering committee) who need not
be an IT staff member, should be given complete operational control over
the project and be allocated appropriate resources.
 An I.S auditor may be included in the project team as control expert.
 The I.S auditor may also provide an independent, objective review to ensure
that the level of commitment by responsible parties is appropriate (I.S
auditor’s advisory role).
 Depending on the auditor’s level of involvement, s/he may become ineligible
to perform audits of the application when it becomes operational.
 PROJECT MNGT ROLES AND RESPONSIBILITIES

Project steering committee

 Responsible for all deliverables, project costs and schedules.
 Performs the following functions:
i. Reviews project progress regularly
ii. Serves as coordinator and advisor
iii. Takes corrective action if necessary on progress and issues escalated to the
committee
Senior Mngt
 Approves necessary resources to complete the project.
Project sponsor
 provides funding for the project and works closely with the project manager
to define the critical success factors.
 PROJECT MNGT ROLES AND RESPONSIBILITIES

User Mngt
 Assumes ownership of the project and resulting system
 Allocates qualified representative to the team
 Actively participates in the project
 Reviews and approves systems deliverables
User project team
 Completes assigned tasks
 Communicates with system developers by actively involving themselves in the
process as subject matter experts
Project manager
 Provides day to day management and leadership of the project
Quality Assurance
 Reviews results and deliverables
 Confirms compliance with requirements
 PROJECT MNGT ROLES AND RESPONSIBILITIES
Systems development Mngt
 Provides technical support for hardware and software environments by
developing, installing and operating the requested system.
Systems development project team
 Completes assigned tasks, communicates effectively with users by actively
involving them in the development process.
 Advises the project manager of necessary project plan deviations.
Security officer(or security team)
 Ensures that system controls and supporting processes provide an effective
level of protection, based on the data classification set in accordance with
corporate security policies and procedures.
Information system security engineer
 Identifies security vulnerabilities and minimize or contain risk associated
with these vulnerabilities.
 PROJECT MNGT TECHNIQUES
 Project management techniques provide systematic quantitative and qualitative
approaches to software size estimating, scheduling, allocating resources and
measuring productivity.
 Project mngmt should pay attention to three key intertwining elements:
deliverables, duration and budget.
 Project duration and budget must be commensurate with the nature and
characteristics of the deliverables.
 The objective of the PMO is to improve project and program mngmt quality and
secure project success. It focusses only on activities and tasks and not on project
or program content.
 An I.S auditor should differentiate between auditing project content and/or
procedural aspects of a program or project.
 Objectives of project portfolio management:
 Results optimization
 Prioritizing and scheduling projects
 Resource coordination
 Knowledge transfer throughout the projects
 PROJECT BENEFITS REALIZATION
 The objective of benefits realization is to ensure that IT and the business fulfil
their value management responsibilities, particularly that:
 I.T enabled business investments achieve the promised benefits and deliver
measurable business value
 Required capabilities are delivered on time and within budget
 IT services and other IT assets continue to contribute to business value

 Key elements of project benefits realization are:

 Describing benefits management or benefits realisation.
 Assigning a measure and target.
 Establishing a tracking/measuring regimen.
 Documenting the assumption.
 Establishing key responsibility for realisation.
 Validating the benefits predicted in the business.
 Planning the benefit that is to be realised.
 PROJECT BENEFITS REALIZATION

 An I.S auditor should understand how the business defines value or a return
on investments (ROI) for development-related projects. If an organisation
fails to consistently meet its ROI objectives, this may suggest weakness in its
SDLC and related project management practices.
 PROJECT OBJECTIVES
 A project must have clearly defined results that are specific, measurable,
attainable, realistic and timely ( SMART ).
 A commonly accepted approach to define project objectives is to start off
with an object breakdown structure( OBS ).
 After the OBS has been compiled or a solution is defined, a work breakdown
structure ( WBS ) is designed to structure all the tasks that are necessary to
build up the elements of the OBS during the project.
 In contrast to the OBS, the WBS does not include basic elements of the
solution to build but shows individual work packages ( WPs ) instead.
 Key things to remember with WBS and respective WPs include the following:
 The top WBS level represents the final deliverable or project.
 Subdeliverables contain WPs that are assigned to an organisations
department or unit.
 All elements of the WBS do not need to be defined to the to the same level.
 WPs define the work, duration and costs for the tasks required to produce
the sub deliverable.
 PROJECT OBJECTIVES
 Key things to remember cont….
 WPs should not exceed a duration of 10days
 WPs need to be independent of each other in the WBS
 WPs are unique and should not be duplicated across the WBS

Assignment: Read on Function Point Analysis

NOTE: The CISA candidate should be familiar with the use of FPA; however, the
CISA exam does not test the specifics on how to perform an FPA calculation.
 Cost Budgets
 Estimates for each task should contain:
 Personnel hours by type.
 Machine hours.
 Other external costs.
 Software cost estimation

 Cost estimation is a result of software size estimation and helps to properly scope a
project.
 Automated techniques for cost estimation of projects at each phase of information
systems development are available.
 To use these products, an information system is usually divided into main
components and a set of cost drivers is established.
 Components include:
 Source code language.
 Execution time constraints.
 Main storage constraints.
 Data storage constraints.
 Computer access.
 The target machine used for development.
 The security environment.
 Staff experience.
 Scheduling and establishing the time frame

Assignment: Read on Gantt Charts, Critical Path Methodology (CPM), Program

Evaluation Review Technique (PERT)
 PROJECT EXECUTION
 A key success factor is the project’s oversight of the integrated team in the
IT system requirements, architecture, design, development, testing,
implementation and transitioning to production operations.
 PROJECT CONTROLLING AND MONITORING
 The controlling and monitoring activities of a project include management of
scope, resource usage and risk.
 It is important that new requirements for the project be documented and, if
approved, allocated appropriate resources.
 Control of change during a project ensures that projects are completed
within stakeholder requirements of time, use of funds and quality
objectives.
 Stakeholder satisfaction should be addressed with effective and accurate
requirements capture, proper documentation, baselining and skilled steering
committee activity.
 Scope changes, resource usage, and risk should be managed.
 PROJECT CLOSING
 Any outstanding issues need to be assigned and the project sponsor should
be satisfied that the system produced is acceptable and ready for delivery.
 Key questions to consider:
 When will the final project closure notification be issued? By who?
 How will the project manager assist the project team transition to new
projects or release them to their regular assigned duties?
 What will the project do for actions, risk and issues that remain open? Who
will pick up these actions and how will these be funded?
 I.S AUDITOR’S ROLE IN PROJECT MANAGEMENT
 Determine the main components, objectives and user requirements of the
system to identify the areas that require controls.
 Determine and rank the major risk to and exposures of the system.
 Identify controls to mitigate the risk to and exposures of the system.
 Evaluate available controls and advise the project team regarding the design
of the system and implementation controls.
 Identify and test existing controls to ensure the integrity of production
resources
 Review and analyse test plans to determine if defined system requirements
are being verified.
 Analyse test results and other audit evidence to determine whether control
objectives were achieved.
 Examine supporting records to test system maintenance procedures to
ensure that they are being applied as described in the standards.
 Participate in post-implementation reviews.
 BUSINESS CASE AND FEASIBILITY ANALYSIS
 A business case provides the information required for an organization to
decide whether a project should proceed.
 A business case should adequately describe the business reasons or benefits
for a project and be of sufficient detail to describe the justification for
initiating and continuing a project.
 It should answer the question, “Why should this project be undertaken
and/or continued?”
 If at any stage the business case is thought to no longer be valid, the project
sponsor or IT steering committee should consider whether the project should
proceed.
 There will be decision points, often called “stage gates” or “kill points”, at
which a business case is formally reviewed to ensure that it is still valid.
 If the business case changes during the course of an IT project, the project
should be reapproved through the departmental planning and approval
process.
 BUSINESS CASE AND FEASIBILITY ANALYSIS
 A feasibility study will normally include the following six elements:
1. Project scope- Definition of the business problem and/or opportunity to be
addressed.
2. Current analysis-An understanding of a system, a software product.
3. Requirements-Definition of project requirements based upon stakeholder
needs and constraints.
4. Approach-Course of action.
5. Evaluation-Examination of the cost-effectiveness of the project.
6. Review-Reviews( formal ) of the previously completed elements of the
feasibility study.
 IS AUDITOR’S ROLE IN BUSINESS CASE
DEVELOPMENT.
 An IS auditor plays an important role in the review and evaluation of a
feasibility study.
 This is to ensure that the process and decisions were made in an effective
and unbiased manner.
 The following are tasks typically performed by an IS auditor when reviewing
a feasibility study:
 Review and evaluate the criticality of the business and information system
process requirements.
 Determine if a solution can be achieved with systems already in place. If
not, review the evaluation of alternative solutions for reasonableness.
 Determine the reasonableness of the chosen solution based on their
strengths and weaknesses.
 Determine whether all cost justifications/benefits are verifiable and reflect
anticipated costs and benefits to be realized.
 Review the documentation produced for reasonableness.
 IS AUDITOR’S ROLE IN BUSINESS CASE
DEVELOPMENT.
 As it applies to the requirements definition within a feasibility study, an I.S
auditor should perform the following functions:
 Verify accuracy and completeness of detailed requirements definition
document
 Verify that all affected key user groups have appropriate representation on
the team
 Verify that project initiation and cost have received proper management
approval
 Ensure that the conceptual design specifications address the needs of the
user
 Review the conceptual design to ensure that control specifications have
been defined
 Determine whether a reasonable number of vendors received a proposal
covering the project scope and user requirements.
 SYSTEM DEVELOPMENT METHODOLOGIES
 A systems development methodology is a structure that an org. uses to plan and
control the development of information systems, software and applications.
 A business application system developed will fall in one of two major
categories:
 Org centric-its objective is to collect, collate, store, archive and share
information with business users and various applicable support functions on
need-to-know basis
 End-user centric-objective is to provide different views of data for their
performance optimization.
 A business application development project is initiated as a result of one or
more of the following:
 A new opportunity that relates to a new or existing business process
 A problem that relates to a new or existing business process
 A problem with current technology that will enable the org. to take advantage
of technology
 Alignment of business applications with business partners
 SDLC MODELS
Traditional(waterfall)model
 Ensures that potential mistakes are corrected early and not solely during
final acceptance testing.
 Oldest and most widely commonly used
 Based on a systematic, sequential approach to system and/or software
development.
 Primary advantage is that it provides a template into which methods for the
requirements can be placed.
 SDLC MODELS
Traditional(waterfall)model
 SDLC MODELS
V-shaped(verification and validation) model
 Emphasizes the relationship between development phases and testing levels
 It’s the most granular testing-the unit test occurs immediately after
programs have been written
 Advantages include:
 Formal procedures and guidelines identifying each phase in the business
application
 An auditor can review all relevant areas and phases of the systems and
report independently to management on the adherence to planned
objectives and organizational procedures
 An auditor can identify selected parts of the system and become involved in
the technical aspects on the basis of his/her skills and abilities.
 An auditor can provide an evaluation of the methods and techniques applied
through the development phases of the business application life cycle.
 SDLC MODELS
V-shaped(verification and validation) model
 SDLC MODELS
Iterative
 It’s a cyclic process in which business requirements are developed and
tested in iterations until the entire application is designed, built and tested.
 During each iteration, the development process goes through each phase,
from requirements through testing, and each subsequent cycle incrementally
improves the process.
 SDLC MODELS
Iterative
SDLC PHASES
Phase 1: Feasibility study
 A feasibility study is concerned with analyzing the benefits and solutions for
the identical problem area.
 This study includes development of a business case that states the strategic
benefits of implementing the system either in productivity gains or in future
cost avoidance, identifies and quantifies the cost savings.
 A feasibility study achieves the following:
 Defines a time frame for the implementation of the required solution.
 Determines an optimum alternative risk-based solution for meeting business
needs and general information resource requirements( e.g, whether to
develop or acquire a system ). Such processes can easily be mapped to SDLC
and rapid application development (RAD).
 Determines whether an existing system can correct the situation with slight
or no modification( e.g workaround ).
 Determines whether a vendor product offers a solution to the problem.
SDLC PHASES
Phase 1: Feasibility study cont……
 Determines the approximate cost to develop the system to correct the
situation.
 Determines whether the situation fits the business strategy.
 Factors impacting whether to develop or acquire a system include the
following:
 The date the system needs to be functional.
 The cost to develop the system as opposed to buying it.
 The resources, staff( availability and skill sets )and hardware required to
develop the system or implement a vendor solution.
 In a vendor system, the license characteristics( e.g, yearly renewal,
perpetual ) and maintenance costs.
 The other systems needing to supply information to or use information from
the vendor system that will need the ability to interface with the system.
 Compatibility with strategic business plans.
SDLC PHASES
Phase 1: Feasibility study cont…
 Compatibility with risk appetite and regulatory compliance needs.
 Compatibility with the organization’s IT infrastructure.
 Likely future requirements for changes to functionality offered by the
system.
 The result of the completed feasibility study should be a comparative
report that shows the results of criteria analyzed( e.g, costs, benefits, risk
resources required and organization impact ) and recommends one of the
alternatives/solutions and a course of actions.
SDLC PHASES
Phase 2: Requirements definition
 It is concerned with identifying the business requirements of the system
chosen for development during the feasibility study.
 Requirements include descriptions of:
 What a system should do
 How users will interact with a system
 Conditions under which the system will operate
 Information criteria the system should meet
To successfully complete the requirements definition phase, the project team
should perform the following:
 Determine stakeholders requirements
 Analyze requirements to detect and correct conflicts
 Identify system bounds and how the system should interact with its
environment
SDLC PHASES
 identify relevant security requirements
 Convert user requirements into system requirements
 Record requirements in a structured format.
 Verify that requirements are complete, consistent, unambiguous ,
verifiable, modifiable, testable, and traceable.
 Resolve conflicts between stakeholders
 Resolve conflicts between the set requirements and available resources.

 An I.S auditor should pay close attention to the degree the org’s security
engineering team is involved in the development of security controls
throughout the data life cycle within the business application.
SDLC PHASES
Phase 3a: Software selection and acquisition
 It is appropriate to evaluate the risk and benefits of developing a new
system versus acquiring from a vendor
 Consideration should be given to the ability of the organization to
undertake the proposed development project, the costs, risk and benefit of
having total ownership and control over the new system rather than
becoming dependent on a vendor.
SDLC PHASES
Phase 3b: Design (in-house development)
Key design phases include:
 Develop system flowcharts and entity relationship models
 Determine the use of structured design techniques
 Describe inputs and outputs
 Determine processing steps and computation rules when addressing
functional requirements
 Determine data file or database system file design
 Prepare program specifications for various types of requirements
 Develop test plans for various level of testing
 Develop data conversion plans
 Perform a risk assessment of information flows.
Risks associated with software development
Strategic risk-arises when the business goals are identified and weighted
without taking the corporate strategy into account.
Business risk-relates to the likelihood that the new system may not meet the
user’s business needs, requirements and expectations.
Project risk- arises if the project activities to design and develop the system
exceed the limits of the financial resources set aside for the project and, as a
result, the project may be completed late, if ever.
I.S auditor’s role in Project Design
An I.S auditor is focused on:
 Whether an adequate system of controls is incorporated into system
specifications and test plans
 Whether continuous online auditing functions are built into the system
 Evaluating the effectiveness of the design process itself to establish a formal
software change process that effectively freezes the inclusion of any changes to
system requirements without a formal review and approval process.

An I.S auditor should perform the following functions:

 Review system flow charts for adherence to the design
 Review for appropriateness the input, processing and output controls designed
into the system.
 Interview key users of the system to determine understanding of the system
 Assess adequacy of audit trails to provide traceability and accountability
I.S auditor’s role in Project Design
An I.S auditor should perform the following functions:….cont’
 Verify the integrity of key calculations and processes
 Verify that the system can identify and process erroneous data correctly
 Review quality assurance results of the programs developed during this phase
 Verify that all corrections to programming errors were made and recommended
trails were coded into the appropriate programs.
 Perform a risk assessment.
SDLC PHASES Cont…
Phase 4a: Configuration (purchased systems)
This consists of defining, tracking and controlling changes in an acquired
system to meet the needs of the business.
System configuration is supported by the change mngt policies and processes,
which define:
 Roles and responsibilities
 Classification and prioritization of all changes based on business risk
 Assessment of impact
 Authorization and approval of all changes by the business process owners
and IT
 Tracking status of changes
 Impact on data integrity
SDLC PHASES Cont…
Phase 4b: Development (in-house development)
 It uses the detailed design developed in phase 3b.
 Responsibilities rest with programmers and systems analysts who are building the
system.
 Key activities include:
 Coding and developing program and system level documents
 Debugging and testing the programs developed
 Developing programs to convert data from the old system for use on the new system
 Creating user procedures to handle transition to the new system
 Training selected users on the new system because their participation will be needed
 Ensuring modifications are documented and applied accurately and completely to
vendor-acquired software.
 Identifying secure coding and configuration standards.
SDLC PHASES Cont…
Phase 5: Final testing and implementation
 The actual operation of the new information system is established and
tested.
 Final UAT is conducted
 The system may go through a certification and accreditation process to
assess the business application’s effectiveness at mitigating risk.
 After a successful full-system testing, the system is ready to migrate to the
production environment.
Phase 6: Post-implementation
Following successful implementation, it is beneficial to verify the system has
been properly designed and developed and that proper controls have been
built into the system.
I.S AUDITOR’S ROLE IN SDLC PROJECT MANAGEMENT
When reviewing the SDLC process, an I.S auditor should obtain documentation from
the various phases and attend project team meetings, offering advice to the team
throughout the process.
An auditor should assess key deliverables by the promised dates
An auditor should further review adequacy of the following activities:
 Levels of oversight by project committee/ board
 Risk management methods within the project
 Issue management
 Cost management
 Processes for planning and dependency Mngt
 Reporting processes to senior Mngt
 Change control processes
 Stakeholder Mngt involvement
 Sign off process
SOFTWARE DEVELOPMENT METHODS
 The selection of a software development method is generally independent of
the selection of a project organization model.

Prototyping-evolutionary development
 The initial emphasis during the development of the prototype is usually placed
on the reports and screens which are the system’s aspects most used by the end
users.
 This allows the end user to see a working model of the proposed system within a
short time.
 There are two basic methods or approaches to prototyping:
1. Build the model to create the design then based on that model, develop the
system design.
2. Gradually build the actual system that will operate in production
SOFTWARE DEVELOPMENT METHODS
Rapid Application Development(RAD)
 RAD is a mythology that enables an organization to develop strategically
important systems quickly while reducing development costs
 It has four major stages:
1. Concept definition-Defines the business functions and data subject areas that
the system will support.
2. Functional design- Uses workshops to model the system’s data and processes
and build a working prototype of critical system components.
3. Development –completes the construction of the physical database and
application system, builds the conversion system, and develops user aids and
deployment work plans.
4. Deployment –includes final user testing and training, data conversion and the
implementation of the application system.
SOFTWARE DEVELOPMENT METHODS
Agile Development
 An alternative method for software development which employs a more iterative
and incremental approach instead of the sequential approach of the SDLC.
 It is applied when all requirements cannot be articulated upfront.

Object-Oriented System Development(OOSD)

 Data and procedures are grouped into an entity known as an object.
 An object’s data are referred to as its attributes and its functionality is referred to
as Methods.

Advantages:
 Ability to manage an unrestricted variety of data types
 Provision of a means to model complex relationships
 Capacity to meet the demands of a changing environment
SOFTWARE DEVELOPMENT METHODS
Component-Based Development
 It means assembling applications from cooperating packages of executable
software that make their services available through defined interfaces
Web-based application development
 Designed to achieve easier and more effective integration of code modules
within and between enterprises.
 It seeks to avoid the need to perform redundant computing tasks with the
inherent need for redundant code.
 The risk of web application development is that the systems are widely known
and could be exploited by almost anyone, courtesy of the internet.
 A risk-based approach should therefore be taken in the assessment of web
application vulnerabilities:
 Identify the business goals and supporting IT goals related to the development,
then identify what can go wrong.
SOFTWARE DEVELOPMENT METHODS
Web-Based application Development cont….
 Identify risk related to inadequate specifications, poor coding techniques,
inadequate documentation, inadequate quality control,lack of proper change
control, among others, put them in the context of web application development
with the support of best practice material.
 The focus should be on application development risk, the associated business
risk and technical vulnerabilities, and how these could materialize and be
controlled.
SOFTWARE DEVELOPMENT METHODS
Software Reengineering
 Software reengineering is a process of updating an existing system by extracting
and reusing design and program component's.
 This process is used to support major changes in the way an organization
operates.
 Typical methodologies used in software reengineering generally fall into the
following categories:
 BPR-thorough analysis and significant redesign of the business processes and
management systems to establish a better performing structure.
 Service-oriented software reengineering methodology-its based upon the service
oriented computer architecture, and the reengineering processes apply many
concepts of RAD development leveraging Responsible, Accountable, Consulted
and Informed (RACI) charts and UML modelling.
SOFTWARE DEVELOPMENT METHODS
Reverse engineering
 Reverse engineering is the process of studying and analyzing an application, a
software application or a product to see how it functions and to use that
information to develop a similar system.
,
 This process can be carried out in different ways:

 Decompiling object or executable code into source code and using it to analyze
the program.
 Black-box- testing the application to be reverse-engineered to unveil its
functionality.
 The major advantages of reverse engineering are:
 Faster development and reduced SDLC duration.
 The possibility of introducing improvements by overcoming the reverse-
engineering application drawbacks.
SOFTWARE DEVELOPMENT METHODS
 An IS auditor should be aware of the following risk items:
 Software license agreements often contain clauses prohibiting the license from
reverse engineering the software so that no trade secrets or programming
techniques are compromised.
 Decompilers are relatively new tools with functions that depend on specific
computers, OSs and programming languages.
 Any change in one of these components may require developing or purchasing a
new decompiler.
SOFTWARE DEVELOPMENT METHODS
DevOps
 DevOps refers to the integration of development and operations processes to
eliminate conflicts and barriers.
 Decisions to adopt DevOps should be made based on factors such as an
organization’s climate, risk tolerance and culture and on the scope of the
development project.
 An IS auditor should ensure that there is a proper separation of duties.
 An organization should consider the following controls when embracing a DevOps
development approach:
 Automated software scanning.
 Automated vulnerability scanning.
 Web application firewall.
 Developer application security training
 Software dependency management.
SOFTWARE DEVELOPMENT METHODS
DevOps
 Access and activity login.
 Documented policies and procedures.
 Application performance management.
 Asset management and inventorying.
 Continuous auditioning and/or monitoring.
SOFTWARE DEVELOPMENT METHODS
Business Process Reengineering and Process Change
Defn:
 It’s the process of responding to competitive and economic pressures and customer
demands to survive in the current business environment.
 This is done by automating system processes so that there are fewer manual
interventions and manual controls.
 Advantages of BPR are experienced when the reengineering process appropriately
suits the business needs.
 Steps in a successful BPR:
 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
SOFTWARE DEVELOPMENT METHODS
I.S auditor’s role in Business Process Reengineering
Determine whether:
 The organization’s change efforts are consistent with the overall culture and
strategic plan of the organization
 The reengineering team is trying to minimize any negative impact the change
might have on the organization’s staff
 The BPR team has documented lessons to be learned after the completion of the
BPR/ process change project
 Provide assurance or conclusion with respect to the objectives of the audit.
SYSTEM DEVELOPMENT TOOLS AND PRODUCTIVITY AIDS
Computer-Aided Software engineering (CASE)
 It’s the use of automated tools to aid in the software development process.
 Their use may include the application of software tools for software requirements
capture and analysis, software design, code production, testing, document
generation, and other software development activities.
 Categories of CASE products:
1. Upper CASE-used to describe and document business and application requirements.
This information includes data object definitions and relationships, and process
definitions and relationships.
2. Middle CASE-products used for developing the detailed designs. When elements or
relationships change in the design, it is necessary to make only minor alterations to
the automated design and all other relationships are automatically updated.
3. Lower CASE-Products involved with the generation of program code and database
definitions. They use detailed design information, programming rules and database
syntax rules to generate program logic, data file formats or entire applications.
SYSTEM DEVELOPMENT TOOLS AND PRODUCTIVITY AIDS
 An I.S auditor should gain assurance that approvals are obtained for the
appropriate specifications, users continue to involved in the development
process and investments in CASE tools yield benefits in quality and speed.
 Other key issues an auditor should consider:
 Ensure that the design, programs and system are correct and that they fully
meet the needs of the organization.
 Ensure that CASE is understood and used effectively by the org. ‘s software
developers.
 The integrity of data moved between CASE products or between manual and
CASE processes is monitored and controlled.
 Changes to the application should be reflected in stored CASE product data.
 Application controls are designed
SYSTEM DEVELOPMENT TOOLS AND PRODUCTIVITY AIDS
Fourth-Generation Languages (4GLS)
 Are used in software development to reduce the overall effort and cost.
 Common characteristics of 4GLS are:
 Non-procedural language
 Environmental independence
 Software facilities
 Programmer workbench concepts
 Simple language subsets
SYSTEM DEVELOPMENT TOOLS AND PRODUCTIVITY AIDS
Fourth-Generation Languages (4GLS)
 Classification of 4GLS :
 Query and report generators
 Embedded database 4GLs
 Relational database 4GLS
 Application generators
INFRASTRUCTURE DEVELOPMENT/ ACQUISITION PRACTICES

 The physical architecture analysis, definition of a new one and the necessary
roadmap to move from one to the other are critical.
 Their impact is both economic as well as technological because it decides many
other choices downstream, such as operational procedures, training needs ,
installation issues and TCO.
Phases of physical architecture analysis:
1. Review of existing architecture
2. Analysis and design
3. Draft functional requirements
4. Vendor and product selection
5. Writing functional requirements
INFRASTRUCTURE DEVELOPMENT/ ACQUISITION PRACTICES
Proof of Concept
 POC proves that the selected hardware, software and data are able to meet all
expectations, including security requirements.
 The deliverable of the POC should be a running prototype , including the associated
document and test protocols describing the tests and their results.
 The prototype should demonstrate the following features:
 The basic setup of the core security infrastructure
 Correct functionality of auditing components
 Basic but functional implementation of security measures
 Secured transactions
 Characterization in terms of installation constraints and limits
 Performance
 Funding and costing model
 Resiliency to include fail-over to a trusted operational state
 Data and algorithm
INFRASTRUCTURE DEVELOPMENT/ ACQUISITION PRACTICES
Planning implementation of infrastructure
 To ensure the quality of the results, it is necessary to use a phased approach to fit the
entire puzzle together.
 Through these different phases, a clear understanding of the available and contactable
vendors is established by using the selection process during the procurement phase and
beyond.
 It is necessary to select the scope of key business and technical requirements to
prepare the next steps such as development of the delivery, installation and test plans.
4 phases:
 Procurement phase-during this phase communication between the business and the
analysis project is established to provide an overview of the chosen solution and
determine the quantity structure of the deliverables.
 Delivery time-the delivery plan is developed
 Installation plan-installation plan is developed in cooperation with all affected parties.
 Installation test plan-based on the known dependencies of the installation plan, the
test plan is developed.
INFRASTRUCTURE DEVELOPMENT/ ACQUISITION PRACTICES
Planning implementation of infrastructure
 To ensure the quality of the results, it is necessary to use a phased approach to
fit the entire puzzle together.
 Through these different phases, a clear understanding of the available and
contactable vendors is established by using the selection process during the
procurement phase and beyond.
 It is necessary to select the scope of key business and technical requirements to
prepare the next steps such as development of the delivery, installation and test
plans.
4 phases:
 Procurement phase
 Delivery time
 Installation plan
 Installation test plan
HARDWARE/SOFTWARE ACQUISITION
 Selection of a computer h/w and s/w environment requires the preparation of
specifications for distribution to hw/sw vendors and criteria for evaluating
vendor proposals.
 The specifications must define, as completely as possible, the usage, tasks and
requirements for the equipment needed and must include a description of the
environment in which that equipment will be used.
 I.S auditor’s role in hw acquisition:
 Determine if the acquisition process began with a business need and whether
the hw requirements were considered in the specifications
 Determine if several vendors were considered and whether the comparison
between them was done according to the aforementioned criteria.
SYSTEM SOFTWARE ACQUISITION
 When selecting new system software, the following business and technical issues
must be considered:
 Business, functional and technical needs and specifications.