Title: 1 of 176
1ISACA
The recognized global leader in IT governance,
control, security and assurance
2Chapter 3Systems and Infrastructure Life Cycle
Management
2010 CISA? Review Course
3Course Agenda
- Learning Objectives
- Discuss Task and Knowledge Statements
- Discuss specific topics within the chapter
- Case studies
- Sample questions
4Exam Relevance
Ensure that the CISA candidate Understands
and can provide assurance that the management
practices for the development/acquisition,
testing, implementation, maintenance and disposal
of systems and infrastructure will meet the
organizations objectives. The content area
in this chapter will represent
approximately 16 of the CISA examination
(approximately 32 questions).
5Learning Objectives
- Evaluate the business case for the proposed
system development/acquisition to ensure that it
meets the organization's business goals - Evaluate the project management framework and
project governance practices to ensure that
business objectives are achieved in a
cost-effective manner while managing risks to the
organization - Perform reviews to ensure that a project is
progressing in accordance with project plans, is
adequately supported by documentation and status
reporting is accurate
6Learning Objectives(continued)
- Evaluate proposed control mechanisms for systems
and/or infrastructure during specification,
development/ acquisition and testing to ensure
that they will provide safeguards and comply with
the organization's policies and other
requirements - Evaluate the processes by which systems and/or
infrastructure are developed/acquired and tested
to ensure that the deliverables meet the
organization's objectives - Evaluate the readiness of the system and/or
infrastructure for implementation and migration
into production
7Learning Objectives(continued)
- Perform postimplementation review of systems
and/or infrastructure to ensure that they meet
the organization's objectives and are subject to
effective internal control - Perform periodic reviews of systems and/or
infrastructure to ensure that they continue to
meet the organization's objectives and are
subject to effective internal control - Evaluate the process by which systems and/or
infrastructure are maintained to ensure the
continued support of the organization's
objectives and are subject to effective internal
control - Evaluate the process by which systems and/or
infrastructure are disposed to ensure that they
comply with the organization's policies and
procedures
83.2.1 Portfolio/Program Management
- A program is a group of projects and time-bound
tasks that are closely linked together through
common objectives, a common budget, intertwined
schedules and strategies - Programs have a limited time frame (start and end
date) and organizational boundaries
93.2.1 Portfolio/ProgramManagement (continued)
- Methodology and processes used in program
management are similar to those in project
management and run parallel to each other - To formally start a program, some form of written
assignment from the program owner to the program
manager/team is necessary
103.2.1 Portfolio/Program Management (continued)
- The objectives of project portfolio management
are - Optimization of the results of the project
portfolio - Prioritizing and scheduling projects
- Resource coordination (internal and external)
- Knowledge transfer throughout the projects
113.2.2 Business Case Development and Approval
- A business case provides the information required
for an organization to decide whether a project
should proceed - The initial business case normally derives from a
feasibility study as part of project planning - The business case should be of sufficient detail
to describe the justification for setting up and
continuing a project
123.2.3 Benefits RealizationTechniques
- Benefits realization requires
- Describing benefits management or benefits
realization - Assigning a measure and target
- Establishing a tracking/measuring regime
- Documenting the assumption
- Establishing key responsibilities for realization
- Validating the benefits predicted in the business
- Planning the benefit that is to be realize
133.3.1 General Aspects
- IS projects may be initiated from any part of an
organization - A project is always a time-bound effort
- Project management should be a business process
of a project-oriented organization - The complexity of project management requires a
careful and explicit design of the project
management process
143.3.2 Project Context and Environment
- A project context can be divided into a time and
social context. The following must be taken into
account - Importance of the project in the organization
- Connection between the organizations strategy
and the project - Relationship between the project and other
projects - Connection between the project to the underlying
business case
153.3.3 Project Organizational Forms
- Three major forms of organizational alignment for
project management are - Influence project organization
- Pure project organization
- Matrix project organization
163.3.4 Project Communication and Culture
- Depending on the size and complexity of the
project and the affected parties, communication
when initiating the project management project
process may be achieved by - One-on-one meetings
- Kick-off meetings
- Project start workshops
- A combination of the three
173.3.5 Project Objectives
- A project needs clearly defined results that are
specific, measurable, achievable, relevant and
time-bound (SMART) - A commonly accepted approach to define project
objectives is to begin with an object breakdown
structure (OBS) - After the OBS has been compiled, a work breakdown
structure (WBS) is designed
183.3.6 Roles and Responsibilities of Groups and
Individuals
- Senior management
- User management
- Project steering committee
193.3.6 Roles and Responsibilities of Groups and
Individuals (continued)
- Project sponsor
- Systems development management
- Project manager
- Systems development project team
203.3.6 Roles and Responsibilities of Groups and
Individuals (continued)
- User project team
- Security officer
- Quality assurance
213.4 Project Management Practices
223.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
233.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
243.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)
253.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
263.4.2 Project Planning (continued)
- FPA feature points
- Cost budgets
- Software cost estimation
273.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 - GANTT
- http//en.wikipedia.org/wiki/Gantt_chart
- PERT
- http//en.wikipedia.org/wiki/Program_Evaluation_an
d_Review_Technique
283.4.2 Project Planning (continued)
- Critical path methodology
- A critical path is 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 - http//en.wikipedia.org/wiki/Critical_path_method
293.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
303.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
313.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 - http//en.wikipedia.org/wiki/Timeboxing
323.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 - http//en.wikipedia.org/wiki/Decision_support_syst
em
333.4.4 Project Controlling
- Includes management of
- Scope
- Resource usage
- Risk
- Inventory
- Assess
- Mitigate
- Discover
- Review evaluate
343.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
353.5 Business ApplicationDevelopment
- The implementation process for business
applications, commonly referred to as an SDLC,
begins when an individual application is
initiated as a result of one or more of the
following situations - A new opportunity that relates to a new or
existing business process - A problem that relates to an existing business
process - A new opportunity that will enable the
organization to take advantage of technology - A problem with the current technology
- http//en.wikipedia.org/wiki/Systems_Development_L
ife_Cycle
363.5 Business Application Development (continued)
- Benefits of using this approach
- All affected parties will have a common and clear
understanding of the objectives and how they
contribute to business support - Conflicting key business drivers (e.g., cost vs.
functionality) and mutually dependent key
business drivers can be detected and resolved in
early stages of an SDLC project
373.5 Business ApplicationDevelopment (continued)
- From an IS auditors perspective, an approach
with defined life cycles and specific points for
review provides the following advantages - Influence is significantly increased when there
are formal procedures and guidelines - Can review all relevant areas and phases of the
systems development project and report
independently to management - Can identify selected parts of the system and
become involved in the technical aspects - Can evaluate the methods and techniques applied
through the development phases
383.5.1 Traditional SDLC Approach
- Also referred to as the waterfall technique, this
life cycle approach is the oldest and most widely
used for developing business applications - Based on a systematic, sequential approach to
software development that begins with a
feasibility study and progresses through
requirements definition, design, development,
implementation and postimplementation
393.5.1 Traditional SDLC Approach (continued)
- Some of the problems encountered with this
approach include - Unanticipated events
- Difficulty in obtaining an explicit set of
requirements from the user - Managing requirements and convincing the user
about the undue or unwarranted requirements in
the system functionality - The necessity of user patience
- A changing business environment that alters or
changes the users requirements before they are
delivered
403.5.2 Integrated Resource Management Systems
- A growing number of organizations are shifting to
a fully integrated corporate solution, i.e., an
ERP solution - This type of software implementation is much
larger than a regular software acquisition
project - ERP systems impact the way a corporation does
business, its entire control environment,
technological direction and internal resources
413.5.3 Description of Traditional SDLC Phases
- Feasibility study
- Concerned with analyzing the benefits and
solutions for the identified problem area - Includes development of a business case, which
determines the strategic benefits of implementing
the system either in productivity gains or in
future cost avoidance - Identifies and quantifies the cost savings of the
new system and estimates a payback schedule for
the cost incurred in implementing the system or
shows the projected return on investment (ROI)
423.5.3 Description of Traditional SDLC Phases
(continued)
- Requirements definition
- Concerned with identifying and specifying 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, and the information criteria the system
should meet - This phase deals with the issues that are
sometimes called nonfunctional requirements
433.5.3 Description of Traditional SDLC Phases
(continued)
- Entity relationship diagrams
- An ERD depicts a systems data and how these data
interrelate - An ERD can be used as a requirements analysis
tool to obtain an understanding of the data a
system needs to capture and manage - An ERD can also be used later in the development
cycle as a design tool that helps document the
actual database schema that will be implemented
443.5.3 Description of Traditional SDLC Phases
(continued)
- Software acquisition
- Not a phase in the standard SDLC. However, if a
decision was reached to acquire rather than
develop software, software acquisition is the
process that should occur after the requirements
definition phase - Decision based on various factors such as the
cost differential between development and
acquisition, availability of generic software,
and the time gap between development and
acquisition
453.5.3 Description of Traditional SDLC Phases
(continued)
- Software acquisition
- The project team needs to carefully examine and
compare the vendors responses to the request for
proposal (RFP) - It is likely that more than one product/vendor
fits the requirements with advantages and
disadvantages with respect to each other - Once vendors are short listed, it can be
beneficial for the project team to talk to
current users of each potential product
463.5.3 Description of Traditional SDLC Phases
(continued)
- Design
- Key design phase activities include
- Developing system flowcharts and entity
relationship models - Determining the use of structured design
techniques - End of design phase
- Describing inputs and outputs
- Determining processing steps and computation
rules - Determining data file or database system file
design - Preparing program specifications
- Developing test plans for the various levels of
testing - Developing data conversion plans
473.5.3 Description of Traditional SDLC Phases
(continued)
- Development
- Key activities performed in a test/development
environment 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
- Ensure modifications are documented and applied
accurately
483.5.3 Description of Traditional SDLC Phases
(continued)
- Development
- Programming methods and techniques
- Online programming facilities (integrated
development environment) - Programming languages
- Program debugging
- Testing
49Practice Question
- 3-1 To assist in testing a core banking system
being acquired, an organization has provided the
vendor with sensitive data from its existing
production system. An IS auditors PRIMARY
concern is that the data should be - sanitized.
- complete.
- representative.
- current.
503.5.3 Description of Traditional SDLC Phases
(continued)
- Development
- Elements of a software testing process
- Test plan
- Conduct and report test results
- Address outstanding issues
- Testing classifications
- Unit testing
- Interface or integration testing
- System testing
- Final acceptance testing
51Practice Question
- 3-2 An IS auditor is performing a project review
to identify whether a new application has met
business objectives. Which of the following test
reports offers the MOST assurance that business
objectives are met? - User acceptance
- Performance
- Sociability
- Penetration
523.5.3 Description of Traditional SDLC Phases
(continued)
- Development
- Other types of testing
- Alpha and beta testing
- Pilot testing
- White box testing
- Black box testing
- Function/validation testing
- Regression testing
- Parallel testing
- Sociability testing
- Automated application testing
533.5.3 Description of Traditional SDLC Phases
(continued)
- Implementation
- During the implementation phase, the actual
operation of the new information system is
established and tested - Final user-acceptance testing is conducted in
this environment - The system may also go through a certification
and accreditation process to assess the
effectiveness of the business application at
mitigating risks to an appropriate level
543.5.3 Description of Traditional SDLC Phases
(continued)
- Implementation planning
- Phase 1Develop to-be support structures
- Phase 2Establish support function
- End-user training
- Data migration
- Refining migration scenario
- Fallback (rollback) scenario
- Changeover (go-live or cutover) techniques
- Parallel changeover
- Phased changeover
- Abrupt changeover
- Certification/accreditation
553.5.3 Description of Traditional SDLC Phases
(continued)
- A postimplementation review should meet the
following objectives - Assess the adequacy of the system
- Evaluate the projected cost benefits or ROI
- Develop recommendations that address the systems
inadequacies and deficiencies - Develop a plan for implementing the
recommendations - Assess the development project process
- A postimplementation review should be performed
jointly by the project development team and
appropriate end users
563.5.4 Risks Associated with Software Development
- Business risk relating to the likelihood that the
new system may not meet the users business
needs, requirements and expectations - Potential risks that can occur when designing and
developing software systems - Within the project
- With suppliers
- Within the organization
- With the external environment
573.5.5 Use of Structured Analysis, Design and
Development Techniques
- Closely associated with the traditional, classic
SDLC approach - Techniques provide a framework for representing
the data and process components of an application
using various graphical notations at different
levels of abstraction, until it reaches the
abstraction level that enables programmers to
code the system
583.6.1 Electronic Commerce
- E-commerce models include the following
- Business-to-consumer (B-to-C) relationships
- Business-to-business (B-to-B) relationships
- Business-to-employee (B-to-E) relationships
- Business-to-government (B-to-G) relationships
- Consumer-to-government (C-to-G) relationships
- Exchange-to-exchange (X-to-X) relationships
593.6.1 Electronic Commerce(continued)
- With increasing emphasis on integrating the web
channel with a business internal legacy systems
and the systems of its business partners, company
systems now typically will run on different
platforms, running different software and with
different databases - The challenge of integrating diverse technologies
within and beyond the business has increasingly
lead companies to move to component-based systems
that utilize a middleware infrastructure, based
around an application server
603.6.1 Electronic Commerce (continued)
- Databases play a key role in most e-commerce
systems, maintaining data for web site pages,
accumulating customer information and possibly
storing click-stream data for analyzing web site
usage - Extensible Markup Language is also likely to form
an important part of an organizations overall
e-commerce architecture
613.6.1 Electronic Commerce(continued)
- E-commerce risks
- Confidentiality
- Integrity
- Availability
- Authentication and nonrepudiation
- Power shift to customers
- It is important to take into consideration the
importance of security issues that extend beyond
confidentiality objectives
623.6.1 Electronic Commerce(continued)
- An IS auditor should assess applicable use of
- A set of security mechanisms and procedures that
constitute a security architecture for e-commerce - Firewall mechanisms that are in place to mediate
between the public network and an organizations
private network - A process whereby participants in an e-commerce
transaction can be identified uniquely and
positively - Digital signatures
- An infrastructure to manage and control public
key pairs and their corresponding certificates - The procedures in place to control changes to an
e-commerce presence - Logs of e-commerce applications
633.6.1 Electronic Commerce(continued)
- An IS auditor should assess applicable use of
- The methods and procedures to recognize security
breaches when they occur - The features in e-commerce applications
- The protections in place to ensure that data
collected about individuals are not disclosed
without their consent - The means to ensure confidentiality of data
communicated between customers and vendors - The mechanisms to protect e-commerces presence
and their supporting private networks from
computer viruses
643.6.1 Electronic Commerce(continued)
- An IS auditor should assess applicable use of
- The features within the e-commerce architecture
to keep all components from failing - A plan and procedure to continue e-commerce
activities in the event of an extended outage of
required resources for normal processing - A commonly understood set of practices and
procedures to define managements intentions for
the security of e-commerce - A shared responsibility within an organization
for e-commerce security - Communications from vendors to customers
- A regular program of audit and assessment of the
security of e-commerce environments and
applications
65Practice Question
- 3-9 When introducing thin client architecture,
which of the following risks regarding servers
is significantly increased? - Integrity
- Concurrency
- Confidentiality
- Availability
663.6.2 Electronic Data Interchange
- The benefits associated with the adoption of EDI
include - Less paperwork
- Fewer errors during the exchange of information
- Improved information flow, database-to-database
and company-to-company - No unnecessary rekeying of data
- Fewer delays in communication
- Improved invoicing and payment processes
673.6.2 Electronic Data Interchange (continued)
- General requirements
- An EDI system requires communications software,
translation software and access to standards - To build a map, an EDI standard appropriate for
the kind of EDI data to be transmitted is
selected - Final step is to write a partner profile that
tells the system where to send each transaction
and how to handle errors and exceptions
683.6.2 Electronic Data Interchange (continued)
- Moving data in a batch transmission process
through the traditional EDI process generally
involves three functions within each trading
partners computer system - Communications handler
- EDI interface
- EDI translator
- Application interface
- Application system
693.6.2 Electronic Data Interchange (continued)
- Web-based EDI has come into prominence due to
- Internet-through-Internet service providers
offering generic network access for all computers
connected to the Internet - Its ability to attract new partners via web-based
sites to exchange information - New security products available to address issues
of confidentiality, authentication, data
integrity and nonrepudiation of origin and return - Improvements in the x.12 EDI formatted standard
703.6.4 Controls in EDI Environment
- To protect EDI transmissions, the EDI process
should include - Standards set to indicate the message format and
content are valid - Controls to ensure standard transmissions are
properly converted for the application software
by the translation application - Procedures to determine messages are only from
authorized parties - Direct or dedicated transmission channels among
the parties - Data should be encrypted using algorithms agreed
to by the parties involved
713.6.4 Controls in EDI Environment (continued)
- The EDI process needs the ability to detect and
deal with transactions that do not conform to the
standard format or are from/to unauthorized
parties - The critical nature of many EDI transactions
requires that there be positive assurances that
the transmissions were complete - Organizations desiring to exchange transactions
using EDI are establishing a new business
relationship
723.6.4 Controls In EDI Environment (continued)
- The controls for receipt of inbound transactions
are - Use appropriate encryption techniques when using
public Internet infrastructures for communication - Perform edit checks
- Perform additional computerized checking
- Log each inbound transaction upon receipt
- Use control totals on receipt of transactions
- Segment count totals built into the transaction
set trailer by the sender - Control techniques in the processing of
individual transactions - Ensure the exchange of control totals of
transactions sent and received between trading
partners at predefined intervals
733.6.4 Controls in EDI Environment (continued)
- An IS auditor must evaluate EDI to ensure that
all inbound EDI transactions are received and
translated accurately, passed to an application
and processed only once - To accomplish this, an IS auditor must review
- Internet encryption process
- Edit checks
- Additional computerized checking
- Batch control totals
- The validity of the sender against trading
partner details
74Practice Question
- 3-10 Which of the following procedures should be
implemented to help ensure the completeness of
inbound transactions via electronic data
interchange (EDI)? - Segment counts built into the transaction set
trailer - A log of the number of messages received,
periodically verified with the transaction
originator - An electronic audit trail for accountability and
tracking - Matching acknowledgement transactions received to
the log of EDI messages sent
753.6.5 Electronic Mail
- At the most basic level, the e-mail process can
be divided into two principal components - Mail servers, which are hosts that deliver,
forward and store mail - Clients, which interface with users and allow
users to read, compose, send and store e-mail
messages
763.6.5 Electronic Mail (continued)
- Security issues involved with e-mail include
- Flaws in the configuration of mail server
applications - Denial-of-service (DoS) attacks may be directed
to the mail server - Sensitive information transmitted unencrypted
between mail server and e-mail client may be
intercepted - Information within the e-mail may be altered
- Viruses and other types of malicious code may be
distributed throughout an organization - Users may send inappropriate, proprietary or
other sensitive information via e-mail
773.6.5 Electronic Mail (continued)
- Digital signatures are a good method of securing
e-mail transmissions in that - The signature cannot be forged
- The signature is authentic and encrypted
- The signature cannot be reused
- The signed document cannot be altered
783.6.7 Electronic Banking
- Banks should have a risk management process to
enable them to identify, measure, monitor and
control their technology risk exposure - Risk management of new technologies has three
essential elements - Risk management is the responsibility of the
board of directors and senior management - Implementing technology is the responsibility of
IT senior management members - Measuring and monitoring risk is the
responsibility of members of operational
management
793.6.7 Electronic Banking(continued)
- E-banking presents a number of risk management
challenges - The speed of change relating to technological and
service innovation - Transactional e-banking web sites and associated
retail and wholesale business applications are
typically integrated with legacy computer systems - e-Banking increases banks dependence on
information technology - The Internet is ubiquitous and global by nature
803.6.7 Electronic Banking(continued)
- Effective risk management controls for e-banking
include 14 controls divided among three
categories - Board and management oversight
- Security controls
- Legal and reputational risk management
813.6.8 Electronic Finance
- Advantages of e-finance to consumers include
- Lower costs
- Increased breadth and quality
- Widening access to financial services
- A-synchrony (time-decoupled)
- A-topy (location-decoupled)
823.6.11 Electronic Funds Transfer
- Electronic funds transfer (EFT) is the exchange
of money via telecommunications without currency
actually changing hands - Allows parties to move money from one account to
another, replacing traditional check writing and
cash collection procedures - Usually function via an internal bank transfer
from one partys account to another or via a
clearinghouse network
833.6.12 Controls in anEFT Environment
- Security in an EFT environment ensures that
- All of the equipment and communication linkages
are tested - Each party uses security procedures that are
reasonably sufficient - There are guidelines set for the receipt of data
- Upon receipt of data, the receiving party will
immediately transmit an acknowledgment or
notification - Data encryption standards are set
- Standards for unintelligible transmissions are
set - Regulatory requirements are explicitly stated
843.6.15 Automated Teller Machine
- Recommended internal control guidelines for ATMs
include - Written policies and procedures covering
personnel, security controls, operations,
settlement, balancing, etc. - Procedures for PIN issuance and protection during
storage - Procedures for the security of PINs during
delivery - Controls over plastic card procurement
- Controls and audit trails of the transactions
that have been made in the ATM
853.6.20 Artificial Intelligence and Expert Systems
- Artificial intelligence is the study and
application of the principles by which - Knowledge is acquired and used
- Goals are generated and achieved
- Information is communicated
- Collaboration is achieved
- Concepts are formed
- Languages are developed
863.6.20 Artificial Intelligence and Expert Systems
(continued)
- Key to an expert system is the knowledge base
(KB), which contains specific information or fact
patterns associated with a particular subject
matter and the rules for interpreting these facts - The information in the KB can be expressed in
several ways - Decision trees
- Rules
- Semantic nets
873.6.20 Artificial Intelligence and Expert Systems
(continued)
- An IS auditor should
- Understand the purpose and functionality of the
system - Assess the systems significance to the
organization - Review the adherence of the system to policies
and procedures - Review procedures for updating information in the
KB - Review security access over the system
883.6.21 Business Intelligence
- Business intelligence (BI) is a broad field of IT
that encompasses the collection and dissemination
of information to assist decision making and
assess organizational performance - Some typical areas in which BI is applied
include - Process cost, efficiency and quality
- Customer satisfaction with product and service
offerings - Customer profitability
- Staff and business unit achievement of KPIs
- Risk management
893.6.21 Business Intelligence(continued)
- An optimized enterprise data flow architecture
consists of - Presentation/desktop access layer
- Data source layer
- Core data warehouse
- Data mart layer
- Data staging and quality layer
- Data access layer
- Data preparation layer
- Metadata repository layer
- Warehouse management layer
- Application messaging layer
- Internet/intranet layer
903.6.22 Decision Support System
A decision support system (DSS) is an
interactive system that provides the user with
easy access to decision models and data from a
wide range of sources, to support semistructured
decision-making tasks typically for business
purposes
913.6.22 Decision Support System (continued)
- A principle of DSS design is to concentrate less
on efficiency and more on effectiveness - A DSS is often developed with a specific decision
or well-defined class of decisions to solve - Frameworks are generalizations about a field that
help put many specific cases and ideas into
perspective - G. Gorry-M.S. Morton framework
- Sprague-Carson framework
923.6.22 Decision Support System (continued)
- Prototyping is the most popular approach to DSS
design and development - It is difficult to implement a DSS because of its
discretionary nature
933.6.22 Decision Support System (continued)
- Developers should be prepared for eight
implementation risk factors - Nonexistent or unwilling users
- Multiple users or implementers
- Disappearing users, implementers or maintainers
- Inability to specify purpose or usage patterns in
advance - Inability to predict and cushion impact on all
parties - Lack or loss of support
- Lack of experience with similar systems
- Technical problems and cost-effectiveness issues
943.6.22 Decision Support System (continued)
- The DSS designer and user should use broad
evaluation criteria, including - Traditional cost-benefit analysis
- Procedural changes, more alternatives examined,
less time consumer in making the decision - Evidence of improvement in decision making
- Changes in the decision process
953.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
963.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
973.7.1 Agile Development
983.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
993.7.3 Rapid ApplicationDevelopment
- 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
1003.8.1 Data-oriented SystemDevelopment
- A method for representing software requirements
by focusing on data and their structure - Major advantage of this approach is that it
eliminates data transformation errors such as
porting, conversion, transcription and
transposition
1013.8.2 Object-oriented System Development
- The process of solution specification and
modeling where data and procedures can be grouped
into an entity known as an object - OOSD is a programming technique and is not a
software development methodology itself - The major advantages of OOSD are
- The ability to manage an unrestricted variety of
data types - Provision of a means to model complex
relationships - The capacity to meet the demands of a changing
environment
1023.8.3 Component-basedDevelopment
- Process of assembling applications from
cooperating packages of executable software that
make their services available through defined
interfaces - Basic types of components are
- In-process client components
- Stand-alone client components
- Stand-alone server components
- In-process server components
1033.8.3 Component-based Development (continued)
- Components play a significant role in web-based
applications - Component-based development
- Reduces development time
- Improves quality
- Allows developers to focus more strongly on
business functionality - Promotes modularity
- Simplifies reuse
- Reduces development cost
- Supports multiple development environments
1043.8.4 Web-based Application Development
- Designed to achieve easier and more effective
integration of code modules within and between
enterprises - Different from traditional third- or
fourth-generation program developments in many
ways - Languages and programming techniques used
- Methodologies used to control development work
- The way users test and approve development work
1053.8.6 Reverse Engineering
- 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 - Major advantages
- Faster development and reduced SDLC duration
- Possibility of introducing improvements by
overcoming the reverse-engineered application
drawbacks
1063.9 Infrastructure Development/Acquisition
Practices
- The physical architecture analysis, the
definition of a new one and the necessary road
map to move from one to the other are critical
tasks for an IT department - Goals
- To successfully analyze the existing architecture
- To design a new architecture
- To write the functional requirements of this new
architecture - To develop a proof of concept
1073.9 Infrastructure Development/Acquisition
Practices (continued)
- Physical implementation of the required technical
infrastructure to set up the future environment
will be planned next - Task will cover procurement activities such as
contracting partners, setting up the SLAs, and
developing installation plans and installation
test plans
1083.9.1 Project Phases of Physical Architecture
Analysis
1093.9.2 Planning Implementation of Infrastructure
- To ensure the quality of results, a phased
approach is necessary - Communication processes should be set up to other
projects - Through these different phases the components are
fit together, and a clear understanding of the
available and contactable vendors is established
by using the selection process during the
procurement phase and beyond
1103.9.2 Planning Implementation of Infrastructure
(continued)
1113.9.2 Planning Implementation of Infrastructure
(continued)
1123.9.2 Planning Implementation of Infrastructure
(continued)
1133.9.2 Planning Implementation of Infrastructure
(continued)
1143.9.2 Planning Implementation of Infrastructure
(continued)
1153.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
1163.9.4 Hardware Acquisition(continued)
- Acquisition steps include, but are not limited
to, the following - Testimonials or visits with other users
- Provisions for competitive bidding
- Analysis of bids against requirements
- Comparison of bids against each other
- Analysis of the vendors financial condition
- Analysis of the vendors capability to provide
maintenance - Review of delivery schedules against requirements
- Analysis of security and control facilities
- Review and negotiation of price
- Review of contract terms
1173.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
1183.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
1193.10.1 Change ManagementProcess 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
1203.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)
1213.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 sign-off procedures - From an audit perspective, provides evidence of
managements commitment to careful control - Involves procedures throughout the software life
cycle
1223.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
1233.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
1243.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
1253.11.3 Fourth-generation Languages
- Common characteristics of 4GLs include
- Nonprocedural language
- Environmental independence (portability)
- Software facilities
- Programmer workbench concepts
- Simple language subsets
- 4GLs are classified as
- Query and report generators
- Embedded database 4GLs
- Relational database 4GLs
- Application generators
1263.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
1273.12.1 Business Process Reengineering and Process
Change Projects
1283.12.1 Business Process Reengineering and Process
Change Projects (continued)
- A successful BPR/process change project requires
the project team to perform the following for the
existing processes - Process decomposition to the lowest level
required for effectively assessing a business
process - Identification of customers, process-based
managers or process owners responsible for
beginning to end processes - Documentation of the elementary process-related
profile information
1293.12.1 Business Process Reengineering and Process
Change Projects (continued)
- BPR methods and techniques
- Benchmarking process
- Plan
- Research
- Observe
- Analyze
- Adapt
- Improve
130Practice Question
- 3-3 When conducting a review of business
process reengineering, an IS auditor found
that a key preventive control had been
removed. In this case, the IS auditor should - inform management of the finding and determine
whether management is willing to accept the
potential material risk of not having that
preventive control. - determine if a detective control has replaced the
preventive control during the process and, if it
has not, report the removal of the preventive
control. - recommend that this and all control procedures
that existed before the process was reengineered
be included in the new process. - develop a continuous audit approach to monitor
the effects of the removal of the preventive
control.
131Practice Question
- 3-4 During which of the following steps in the
business process reengineering should the
benchmarking team visit the benchmarking
partner? - Observation
- Planning
- Analysis
- Adaptation
1323.13 Application Controls
- Application controls are controls over input,
processing and output functions. They include
methods for ensuring that - Only complete, accurate and valid data are
entered and updated in a computer system - Processing accomplishes the correct task
- Processing results meet expectations
- Data are maintained
1333.13 Application Controls (continued)
- 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
- Testing the controls to ensure their
functionality and effectiveness - Evaluating the control environment
- Considering the operational aspects of the
application to ensure its efficiency and
effectiveness
1343.13.1 Input/Origination Controls
- Input authorization
- Input authorization verifies that all
transactions have been authorized and approved by
management - Types of authorization include
- Signatures on batch forms or source documents
- Online access controls
- Unique passwords
- Terminal or client workstation identification
- Source documents
1353.13.1 Input/Origination Controls (continued)
- Batch controls and balancing
- Batch controls group input transactions to
provide control totals - Types of batch controls include
- Total monetary amount
- Total items
- Total documents
- Hash totals
1363.13.1 Input/Origination Controls (continued)
- Batch controls and balancing
- Batch balancing can be performed through manual
or automated reconciliation - Types of batch balancing include
- Batch registers
- Control accounts
- Computer agreement
1373.13.1 Input/Origination Controls (continued)
- Error reporting and handling
- Input processing requires that controls be
identified to verify that data are accepted into
the system correctly and that input errors are
recognized and corrected - Input error handling can be processed by
- Rejecting only transactions with errors
- Rejecting the whole batch of transactions