Chapter 4: Systems Development - PowerPoint PPT Presentation

Loading...

PPT – Chapter 4: Systems Development PowerPoint presentation | free to download - id: 20a13e-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 4: Systems Development

Description:

Tar pit syndrome. Thinking inside the box. Advantages: Identify ... Gathering facts. SYSTEMS ANALYSIS- PHASE II. IT Auditing & Assurance, 2e, Hall & Singleton ... – PowerPoint PPT presentation

Number of Views:107
Avg rating:3.0/5.0
Slides: 40
Provided by: tommiesi
Learn more at: http://www.swlearning.com
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 4: Systems Development


1
Chapter 4Systems Development Maintenance
Activities
2
PARTICIPANTS
  • Systems professionals
  • End users
  • Stakeholders
  • ACCOUNTANTS
  • Internal
  • External
  • Limitations of involvement

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

4
I.S. AQUISITION
  • In-house development
  • Purchase commercial systems

5
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

6
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
  • Backbone systems (ERP)
  • SAP, Peoplesoft, Baan, Movex
  • Vendor-supported systems
  • Hybrids

7
COMMERCIAL SYSTEMS
  • Advantages
  • Implementation time
  • Cost
  • Reliability
  • Disadvantages
  • Independence
  • Customization needs
  • Maintenance

8
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

9
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

10
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

11
SYSTEMS PLANNING-PHASE I
  • Auditors role in systems planning
  • Auditability
  • Security
  • Controls

12
SYSTEMS PLANNING-PHASE I
SUMMARY
  • Identify users 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 mgmts commitment

13
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

14
SYSTEMS ANALYSIS-PHASE II
Gathering facts
  • Data sources
  • Users
  • Data stores
  • Processes
  • Data flows
  • Controls
  • Transaction volumes
  • Error rates
  • Resource costs
  • Bottlenecks
  • Redundant operations

15
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)
  • Auditors role
  • CAATTs (e.g., embedded modules)

16
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. Auditors role
  • special auditability features

17
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 firms 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

18
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

19
SYSTEM EVALUATON SELECTIONPHASE IV
Cost-Benefit Analysis Benefits
  • 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
  • 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.

20
Cost-Benefit Analysis Comparison
  • NPV 1 Table 4-4
  • Payback 2 Figures 4-7a, 7b
  • BE
  • Auditors 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

21
DETAILED DESIGNPHASE 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

22
DETAILED DESIGN PHASE V
Quality Assurance
  • Walkthrough
  • Quality assurance

23
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 (DFDs)
  • Database models (ER, Relational)
  • Data dictionary
  • Processing logic (flow charts)

24
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

25
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
  • Novices
  • Occasional users
  • Frequent light users
  • Frequent power users
  • User handbook
  • Tutorials
  • Help features

26
SYSTEMS IMPLEMENTATIONPHASE VII
Conversion
  • Converting the databases
  • Validation
  • Reconciliation
  • Backup
  • Converting the new systemGo live
  • Auditor involvement virtually stops!
  • Cold turkey cutover
  • Phased cutover
  • Parallel operation cutover

27
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
  • Auditors role
  • Were back!!
  • Provide technical expertise
  • Specify documentation standards
  • Verify control adequacy
  • External auditors

28
SYSTEMS IMPLEMENTATIONPHASE VII
Auditors Role
  • Were back!!
  • 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

29
SYSTEMS MAINTENANCEPHASE VIII
  • PURPOSE Changing systems to accommodate changes
    in user needs
  • 80/20 rule 1
  • Importance of documentation?
  • Facilitate efficient changes
  • Facilitate effective changes (at all!)

30
Project Authorization
Preliminary Feasibility
SystemsPlanning
Project Proposal
Project Schedule
SystemsAnalysis
System Analysis Rpt
ConceptualDesign
DFD (general)
SystemsSelection
System Selection Rpt
FeasibilityStudy
Cost-BenefitAnalysis
DetailedDesign
ER Diagram
Detailed Design Rpt
DFD (Detail)
Relational Model
Normalized Data
System Implementation
Program Flowcharts
Post-Impl. Review
Documentation
User Acceptance Rpt
31
  • 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 clients financial data.

32
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

33
CONTROLLING AUDITING THE SDLC
Audit Objectives Procedures
  • Audit objectives
  • Verify SDLC activities are applied consistently
    and in accordance with managements 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

34
CONTROLLING AUDITING THE SDLC
Controlling Systems Maintenance
  • Four minimum controls
  • Formal authorization
  • Technical specifications
  • Retesting
  • Updating the documentation

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

36
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

37
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

38
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

39
Chapter 4Systems Development Maintenance
Activities
About PowerShow.com