chapter 4 systems development maintenance activities n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 4: Systems Development & Maintenance Activities PowerPoint Presentation
Download Presentation
Chapter 4: Systems Development & Maintenance Activities

Loading in 2 Seconds...

play fullscreen
1 / 39

Chapter 4: Systems Development & Maintenance Activities - PowerPoint PPT Presentation


  • 146 Views
  • Uploaded on

Chapter 4: Systems Development & Maintenance Activities. PARTICIPANTS. Systems professionals End users Stakeholders ACCOUNTANTS Internal External Limitations of involvement. ACCOUNTANTS/AUDITORS. Why are accountants/auditors involved? Experts in financial transaction processes

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 4: Systems Development & Maintenance Activities' - Rita


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
participants
PARTICIPANTS
  • Systems professionals
  • End users
  • Stakeholders
  • ACCOUNTANTS
    • Internal
    • External
    • Limitations of involvement
accountants auditors
ACCOUNTANTS/AUDITORS
  • Why are accountants/auditors involved?
    • Experts in financial transaction processes
    • Quality of AIS is determined in SDLC
  • How are accountants involved?
    • Users (e.g., user views and accounting techniques)
    • Members of SDLC development team(e.g., Control Risk being minimized)
    • Auditors (e.g., auditable systems)
is development
IS Development
  • In-house development
  • Purchase commercial systems
  • General Rule: Never build if you can acquire a system that will provide 80% of your needs.
  • Qstn: When would you want to build your own system?
trends in commercial software
TRENDS IN COMMERCIAL SOFTWARE
  • Trends in commercial software
    • Relatively low cost for general purpose software
    • Industry-specific vendors
    • Businesses too small to have in-house IS staff
    • Downsizing & DDP
types of commercial systems
TYPES OF COMMERCIAL SYSTEMS
  • Turnkey systems
    • General accounting systems
      • Typically in modules
    • Special-purpose systems
      • Example banking
    • Office automation systems
      • Purpose is to improve productivity
  • Enterprise systems (ERP)
    • SAP, Peoplesoft, Baan, Oracle
commercial systems
COMMERCIAL SYSTEMS
  • Advantages
    • Implementation time
    • Cost
    • Reliability
  • Disadvantages
    • Independence
    • Customization needs
    • Maintenance
systems development life cycle sdlc
SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)
  • New systems
    • Systems planning
    • Systems analysis
    • Conceptual systems design
    • System evaluation and selection
    • Detailed design
    • System programming and testing
    • System implementation
    • System maintenance
  • SDLC -- Figure 4-1 [p.141]
systems planning phase i
SYSTEMS PLANNING– PHASE I

PURPOSE:To link individual systems projects to the strategic objectives of the firm.

  • Link individual projects to strategic objectives of the firm - Figure 4-2 [p.142]
  • Who does it?
    • Steering committee
    • CEO, CFO, CIO, senior mgmt., auditors, external parties
      • Ethics and auditing standards limit when auditors can serve on this committee
  • Long-range planning: 3-5 years
  • Allocation of resources - broad
systems planning phase i1
SYSTEMS PLANNING-PHASE I
  • Level 1 = Strategic systems planning
    • Why?
      • A changing plan is better than no plan
      • Reduces crises in systems development
      • Provides authorization control for SDLC
      • It works!
  • Level 2 = Project planning
    • Project proposal
    • Project schedule
systems planning phase i2
SYSTEMS PLANNING-PHASE I
  • Auditor’s role in systems planning
    • Auditability
    • Security
    • Controls
systems planning phase i3
SYSTEMS PLANNING-PHASE I
  • SUMMARY
  • Identify user’s needs
  • Preparing proposals
  • Evaluating proposals
  • Prioritizing individual projects
  • Scheduling work
    • Project Plan – allocates resources to specific project
    • Project Proposal – Go or not
    • Project Schedule – represents mgmt’s commitment
systems analysis phase ii
SYSTEMS ANALYSIS-PHASE II

PURPOSE:Effectively identify and analyze the needs of the users for the new system.

  • Survey step
    • Disadvantages:
      • Tar pit syndrome
      • Thinking inside the box
    • Advantages:
      • Identify aspects to keep
      • Forcing analysts to understand the system
      • Isolating the root of problem symptoms
systems analysis phase ii1
SYSTEMS ANALYSIS-PHASE II

Gathering facts

  • Data sources
  • Users
  • Data stores
  • Processes
  • Data flows
  • Controls
  • Transaction volumes
  • Error rates
  • Resource costs
  • Bottlenecks
  • Redundant operations
systems analysis phase ii2
SYSTEMS ANALYSIS-PHASE II
  • Fact-gathering techniques
    • Observation
    • Task participation
    • Personal interviews
    • Reviewing key documents (see list, p. 147)
  • Systems analysis report
    • Figure 4-3 (p.148)
  • Auditor’s role
    • CAATTs (e.g., embedded modules)
conceptual systems design phase iii
CONCEPTUAL SYSTEMS DESIGN-PHASE III

PURPOSE:Develop alternative systems that satisfy system requirements identified during system analysis

1. Top-down (structured design)[see Figure 4-4, p.150]

    • Designs general rather than specific
    • Enough details for design to demonstrate differences
    • Example: Figure 4-5, p. 151
  • Object-oriented approach (OOD)
    • Reusable objects
    • Creation of modules (library, inventory of objects)

3. Auditor’s role

    • special auditability features
system evaluation selection phase iv
SYSTEM EVALUATION & SELECTION– PHASE IV

PURPOSE:Process that seeks to identify the optimal solution from the alternatives

  • Perform detailed feasibility study
    • Technical feasibility[existing IT or new IT?]
    • Legal feasibility
    • Operational feasibilityDegree of compatibility between the firm’s existing procedures and personnel skills, and requirements of the new system
    • Schedule feasibility[implementation]
  • Perform a cost-benefit analysis
    • Identify costs
    • Identify benefits
    • Compare the two
system evaluation selection phase iv1
SYSTEM EVALUATION & SELECTION-PHASE IV
  • Cost-Benefit Analysis: Costs

ONE-TIME COSTS:

  • Hardware acquisition
  • Site preparation
  • Software acquisition
  • Systems design
  • Programming
  • Testing
  • Data conversion
  • Training
  • RECURRING COSTS:
  • Hardware maintenance
  • Software maintenance
  • Insurance
  • Supplies
  • Personnel
    • Allocated existing IS
system evaluaton selection phase iv
SYSTEM EVALUATON & SELECTION–PHASE IV
  • Cost-Benefit Analysis: Benefits

TANGIBLE:

  • Increased revenues
    • Increased sales in existing markets
    • Expansion into new markets
  • Cost Reduction 1
    • Labor reduction
    • Operating cost reduction
      • Supplies
      • overhead
    • Reduced inventories
    • Less expensive eqpt.
    • Reduced eqpt. maint.
  • INTANGIBLE 2:
  • Increased customer satisfaction
  • Improved employee satisfaction
  • More current information
  • Improved decision making
  • Faster response to competitors’ actions
  • More effective operations
  • Better internal and external communications
  • Improved control environment
slide20

Cost-Benefit Analysis: Comparison

    • NPV 1[Table 4-4]
    • Payback 2[Figures 4-7a, 7b]
    • BE
  • Auditor’s role
    • Managerial accounting techniques 3
      • Escapable costs
      • Reasonable interest rates
      • Identify one-time and recurring costs
      • Realistic useful lives for competing projects
      • Determining financial values for intangible benefits
detailed design phase v
DETAILED DESIGN–PHASE V

PURPOSE:Produce a detailed description of the proposed system that satisfies system requirements identified during systems analysis and is in accordance with conceptual design.

  • User views
  • Database tables
  • Processes
  • Controls
  • i.e., a set of “blueprints”
detailed design phase v1
DETAILED DESIGN– PHASE V
  • Quality Assurance
  • “Walkthrough”
  • Quality assurance
detailed design phase v2
DETAILED DESIGN – PHASE V
  • Detailed Design Report
  • Designs for input screens and source documents
  • Designs for screen outputs, reports, operational documents
  • Normalized database
  • Database structures and diagrams
    • Data flow diagrams (DFD’s)
    • Database models (ER, Relational)
  • Data dictionary
  • Processing logic (flow charts)
system programming testing phase vi
SYSTEM PROGRAMMING & TESTING– PHASE VI
  • Program the Application
  • Procedural languages
  • Event-driven languages
  • OO languages
  • Programming the system
  • Test the application {Figure 4-8]
    • Testing methodology
    • Testing offline before deploying online
    • Test data
      • Why?
      • Can provide valuable future benefits
systems implementation phase vii
SYSTEMS IMPLEMENTATION– PHASE VII

PURPOSE: Database structures are created and populated with data, applications are coded and tested, equipment is purchased and installed, employees are trained, the system is documented, and the new system is installed.

  • Testing the entire system
  • Documenting the system
    • Designer and programmer documentation
    • Operator documentation
    • User documentation
systems implementation phase vii1
SYSTEMS IMPLEMENTATION–PHASE VII
  • Conversion
  • Converting the databases
    • Validation
    • Reconciliation
    • Backup
  • Converting the new systemAuditor involvement virtually stops!
    • Cold turkey cutover
    • Phased cutover
    • Parallel operation cutover
systems implementation phase vii2
SYSTEMS IMPLEMENTATION– PHASE VII
  • Post-Implementation Review
  • Reviewed by independent team to measure the success of the system
    • Systems design adequacy [see list p. 170]
    • Accuracy of time, cost, and benefit estimates [see list p. 170]
    • Auditor’s role
      • We’re back!!
      • Provide technical expertise
      • Specify documentation standards
      • Verify control adequacy
      • External auditors
systems implementation phase vii3
SYSTEMS IMPLEMENTATION–PHASE VII
  • Auditors’ Role
  • Provide technical expertise
    • AIS: GAAP, GAAS, SEC, IRS
    • Legal
    • Social / behavioral
    • IS/IT (if capable)
      • Effective and efficient ways to limit application testing
  • Specify documentation standards
  • Verify control adequacy
    • COSO – SAS No. 78 – PCAOB Standard #1
  • Impact on scope of external auditors
systems maintenance phase viii
SYSTEMS MAINTENANCE–PHASE VIII

PURPOSE:Changing systems to accommodate changes in user needs

  • 80/20 rule
  • Importance of documentation?
    • Facilitate efficient changes
    • Facilitate effective changes (at all!)
slide30

Project

Authorization

Preliminary

Feasibility

SystemsPlanning

Project

Proposal

Project

Schedule

SystemsAnalysis

System

Analysis Rpt

ConceptualDesign

DFD

(general)

SystemsSelection

System

Selection Rpt

FeasibilityStudy

Cost-BenefitAnalysis

DetailedDesign

DFD

(Detail)

ER

Diagram

Detailed

Design Rpt

Relational

Model

Normalized

Data

System

Implementation

Post-Impl.

Review

Program

Flowcharts

Documentation

User

Acceptance Rpt

slide31
A materially flawed financial application will eventually corrupt financial data, which will then be incorrectly reported in the financial statements. Therefore, the accuracy and integrity of the IS directly affects the accuracy of the client’s financial data.
controlling auditing the sdlc
CONTROLLING & AUDITING THE SDLC
  • Controlling New Systems Development
  • Systems authorization activities
  • User specification activities
  • Technical design activities
    • Documentation is evidence of controls
    • Documentation is a control!
  • Internal audit participation
  • User test and acceptance procedures
  • Audit objectives
  • Audit procedures
controlling auditing the sdlc1
CONTROLLING & AUDITING THE SDLC
  • Audit Objectives & Procedures
  • Audit objectives
    • Verify SDLC activities are applied consistently and in accordance with management’s policies
    • Verify original system is free from material errors and fraud
    • Verify system necessary and justified
    • Verify documentation adequate and complete
  • Audit procedures
    • How verify SDLC activities applied consistently?
    • How verify system is free from material errors and fraud?
    • How verify system is necessary?
    • How verify system is justified?
    • How verify documentation is adequate and complete?
    • See page 174 for a list
controlling auditing the sdlc2
CONTROLLING & AUDITING THE SDLC
  • Controlling Systems Maintenance
  • Four minimum controls:
    • Formal authorization
    • Technical specifications
    • Retesting
    • Updating the documentation
controlling auditing the sdlc3
CONTROLLING & AUDITING THE SDLC
  • Controlling Systems Maintenance
  • Source program library controls
    • Why? What trying to prevent?
    • Unauthorized access
    • Unauthorized program changes
    • SPLMS [Figure 4-13, p. 177]
  • SPLMS Controls
    • Storing programs on the SPL
    • Retrieving programs for maintenance purposes
    • Detecting obsolete programs
    • Documenting program changes (audit trail)
controlling auditing the sdlc4
CONTROLLING & AUDITING THE SDLC
  • Controlled SPL Environment
  • Password control
    • On a specific program
  • Separate test libraries
  • Audit trail and management reports
    • Describing software changes
  • Program version numbers
  • Controlling access to maintenance [SPL] commands
controlling auditing the sdlc5
CONTROLLING & AUDITING THE SDLC
  • Audit Objectives & Procedures
  • Audit objectives
    • Detect any unauthorized program changes
    • Verify that maintenance procedures protect applications from unauthorized changes
    • Verify applications are free from material errors
    • Verify SPL are protected from unauthorized access
controlling auditing the sdlc6
CONTROLLING & AUDITING THE SDLC
  • Audit Objectives & Procedures
  • Audit procedures
    • Figure 4-14, p.179
    • Identify unauthorized changes
      • Reconcile program version numbers
      • Confirm maintenance authorization
    • Identify application errors
      • Reconcile source code [after taking a sample]
      • Review test results
      • Retest the program
    • Testing access to libraries
      • Review programmer authority tables
      • Test authority table