Trust in, and value from, information systems

1
Trust in, and value from, information systems

• ISACA

2
Chapter 3Information Systems Acquisition,
Development and Implementation

• 2012 CISA? Review Course

3
Course Agenda

• Learning Objectives
• Discuss Task and Knowledge Statements
• Discuss specific topics within the chapter
• Case studies
• Sample questions

4
Exam Relevance

• Ensure that the CISA candidate

• Understands and can provide assurance that the
  practices for the acquisition, development,
  testing and implementation of information systems
  meet the enterprises strategies and objectives.
• The content area in this chapter will represent
  approximately 19 of the CISA examination
  (approximately 38 questions).

5
Learning Objectives

• Evaluate the business case for proposed
  investments in information systems acquisition,
  development, maintenance and subsequent
  retirement to determine whether it meets business
  objectives.
• Evaluate the project management practices and
  controls to determine whether business
  requirements are achieved in a cost-effective
  manner while managing risks to the organization.
• Conduct reviews to determine whether a project is
  progressing in accordance with project plans, is
  adequately supported by documentation and status
  reporting is accurate.

6
Learning Objectives(continued)

• Evaluate controls for information systems during
  the requirements, acquisition, development and
  testing phases for compliance with the
  organizations policies, standards, procedures
  and applicable external requirements.
• Evaluate the readiness of information systems for
  implementation and migration into production to
  determine whether project deliverables, controls
  and the organizations requirements are met.
• Conduct postimplementation reviews of systems to
  determine whether project deliverables, controls
  and the organizations requirements are met.

7
3.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

8
3.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

9
3.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

10
3.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

11
3.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 realized

12
3.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

13
3.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

14
3.3.3 Project Organizational Forms

• Three major forms of organizational alignment for
  project management are
• Influence project organization
• Pure project organization
• Matrix project organization

15
3.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

16
3.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

17
3.3.6 Roles and Responsibilities of Groups and
Individuals

• Senior management
• User management
• Project steering committee

18
3.3.6 Roles and Responsibilities of Groups and
Individuals (continued)

• Project sponsor
• Systems development management
• Project manager
• Systems development project team

19
3.3.6 Roles and Responsibilities of Groups and
Individuals (continued)

• User project team
• Security officer
• Quality assurance

20
3.4 Project Management Practices
21
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

22
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

23
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)

24
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

25
3.4.2 Project Planning (continued)

• FPA feature points
• Cost budgets
• Software cost estimation

26
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

27
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

28
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

29
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

30
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

31
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

32
3.4.4 Project Controlling

• Includes management of
• Scope
• Resource usage
• Risk
• Inventory
• Assess
• Mitigate
• Discover
• Review evaluate

33
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

34
3.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

35
3.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

36
3.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

37
3.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

38
3.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

39
3.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

40
3.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)

41
3.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

42
3.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

43
3.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

44
3.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

45
3.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

46
3.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

47
3.5.3 Description of Traditional SDLC Phases
(continued)

• Development
• Programming methods and techniques
• Online programming facilities (integrated
  development environment)
• Programming languages
• Program debugging
• Testing

48
Practice 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.

49
3.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

50
Practice Question

• 3-2 Which of the following is the BEST
  preventive measure for reducing the risks of an
  IT system associated with possible natural
  disasters?
• A. Identify natural threats
• B. Choose a safe location for the facility
• C. Keep critical systems separate from general
  systems
• D. Update and store backups offsite

51
3.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

52
3.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

53
3.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

54
3.5.3 Description of Traditional SDLC Phases
(continued)

• Changeover (go-live or cutover) techniques
• Parallel changeover
• Phased changeover
• Abrupt changeover
• Certification/accreditation

55
3.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

56
3.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

57
3.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

58
3.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

59
3.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

60
3.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

61
3.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

62
3.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

63
3.6.1 Electronic Commerce (continued)

• An IS auditor should assess applicable use of
• Logs of e-commerce applications
• 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

64
3.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

65
Practice Question

• 3-9 When introducing thin client architecture,
  which of the following risks regarding servers
  is significantly increased?
• Integrity
• Concurrency
• Confidentiality
• Availability

66
3.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

67
3.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

68
3.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

69
3.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

70
3.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

71
3.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

72
3.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

73
3.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

74
Practice 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

75
3.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

76
3.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

77
3.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

78
3.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

79
3.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

80
3.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

81
3.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)

82
3.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

83
3.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

84
3.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

85
3.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

86
3.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

87
3.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

88
3.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

89
3.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

90
3.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

91
3.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

92
3.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

93
3.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

94
3.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

95
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

96
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

97
3.7.1 Agile Development
98
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

99
3.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

100
3.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

101
3.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

102
3.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

103
3.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

104
3.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

105
3.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

106
3.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

107
3.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

108
3.9.1 Project Phases of Physical Architecture
Analysis
109
3.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

110
3.9.2 Planning Implementation of Infrastructure
(continued)
111
3.9.2 Planning Implementation of Infrastructure
(continued)
112
3.9.2 Planning Implementation of Infrastructure
(continued)
113
3.9.2 Planning Implementation of Infrastructure
(continued)
114
3.9.2 Planning Implementation of Infrastructure
(continued)
115
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

116
3.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 using
  predefined evaluation criteria
• Analysis of the vendors financial condition
• Analysis of the vendors capability to provide
  maintenance and support (including training)

117
3.9.4 Hardware Acquisition(continued)

• Acquisition steps include, but are not limited
  to, the following
• Review of delivery schedules against requirements
• Analysis of hardware and software upgrade
  capability
• Analysis of security and control facilities
• Evaluation of performance against requirements
• Review and negotiation of price
• Review of contract terms (including right to
  audit clauses)
• Preparation of a formal written report
  summarizing the analysis for each of the
  alternatives and justifying the selection based
  on benefits and cost

118
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

119
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

120
3.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

121
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)

122
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 sign-off procedures
• From an audit perspective, provides evidence of
  managements commitment to careful control
• Involves procedures throughout the software life
  cycle

123
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

124
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

125
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

126
3.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

127
3.12.1 Business Process Reengineering and Process
Change Projects

• 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

128
3.12.1 Business Process Reengineering and Process
Change Projects
129
3.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

130
3.12.1 Business Process Reengineering and Process
Change Projects (continued)

• BPR methods and techniques
• Benchmarking process
• Plan
• Research
• Observe
• Analyze
• Adapt
• Improve

131
Practice 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.

132
Practice 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

133
3.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

134
3.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

135
3.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

136
3.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

137
3.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

138
3.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
• Holding the batch in suspense
• Accepting