The Systems Development

Life Cycle
 Systems Development and Program
Change Activities
• Participants in Systems • The Systems Development Life Cycle
• Systems Planning—Phase I
Development
• Systems Analysis—Phase II
• Why Are Accountants and • Conceptual Systems Design—Phase III
Auditors Involved with SDLC? • System Evaluation and Selection—Phase IV
• How Are Accountants Involved • Detailed Design—Phase V
with the SDLC? • Application Programming and Testing—
Phase VI
• Information Systems Acquisition • System Implementation—Phase VII
• In-House Development • Systems Maintenance—Phase VIII
• Commercial Systems • Controlling and Auditing the SDLC
• Controlling New Systems Development
• The Controlling Systems Maintenance
 THE SYSTEMS DEVELOPMENT LIFE CYCLE
(SDLC)
• The SDLC in Figure 5.1 is an eight-
phase process consisting of two
major stages:
• 1) new systems development
• System Documentation:
• Each phase in the SDLC produces a set of
required documentation that together
constitutes a body of audit evidence about
the overall quality the SDLC.
• 2) maintenance
• Constitutes program change procedures
• begins once the seven phases are
complete and the system is fully
implemented.
 Phase 1: Systems Planning
Objective
• Objective: To link individual system projects or
applications to the strategic objectives of the firm.
• Organization’s business plan:
• Is the basis for the systems plan.
• specifies where the firm plans to go and how it will get there.
• IT strategic plan:
• is developed from and congruent with the organization’s
business plan.
Figure 5.2 presents the relationship
• Is used to analyze the systems projects . between these plans and the strategic
objectives of the firm.
• There must be congruence between the individual
projects and the business plan, or the firm may fail to
meet its objectives.
• Effective systems planning provides this goal congruence.
 Phase 1: Systems Planning
Steering Committee
Typical responsibilities for a steering
Who Should Do Systems Planning? committee
• Systems Steering Committee • Resolving conflicts that arise from new
• to provide guidance and review the status of systems
system projects. • Reviewing projects and assigning priorities
• may include
• the CEO
• Budgeting funds for systems development
• the CFO • Reviewing the status of individual projects
• the chief information officer under development
• senior management from user areas
• the internal auditor
• Determining at various checkpoints
• senior management from computer services. throughout the SDLC whether to continue
• External parties, such as management consultants with the project or terminate it
and the firm’s external auditors, may also
supplement the committee.
 Phase 1: Systems Planning
Occurs at Two Levels
1) Strategic Systems Planning 2) Project Planning
• the allocation of systems resources at the • identifying areas of user needs, preparing
macro level. proposals, evaluating each proposal’s
• employees (the number of systems professionals feasibility and contribution to the business
to be hired plan, prioritizing individual projects, and
• hardware (the number of workstations, scheduling the work to be done.
minicomputers, and mainframes to be
purchased), • Purposes of project planning
• software (the funds to be allocated to new • to allocate resources to individual applications
systems projects and for systems maintenance), within the framework of the strategic plan.
• telecommunications (the funds allocated to • to allocate scarce resources to specific projects.
networking and EDI).
• Product of this phase consists of two formal
• deals with a time frame of 3 to 5 years. documents:
• is not part of the SDLC because the SDLC • 1) project proposal
pertains to specific applications. • 2) project schedule.
 Phase 1: Systems Planning
Why Perform Strategic Systems Planning?
• Information system planning
• Is volatile
• any long-term plans a firm makes are likely to change
• Is unpredictable
• No one can accurately predict the state of systems technology

• Four (4) justifications for strategic systems planning:

• 1. A plan that changes constantly is better than no plan at all.
• 2. Reduces the crisis component in systems development
• 3. Provides authorization control for the SDLC.
• 4. Cost management
 Phase 1: Systems Planning

Risk Control
• An organization has produced • The Auditor’s Role in Systems
unneeded, inefficient, Planning
ineffective, and fraudulent • Auditors routinely examine the
systems. systems planning phase of the
SDLC.
• Both internal and external
auditors are interested in
ensuring that adequate systems
planning takes place.
 Phase 2: Systems Analysis
• is the foundation for the rest of the SDLC.
• formally state the goals and objectives of the system.
• a two-step process involving
• 1) System Survey Step: a survey of the current system
• A business problem must be fully understood by the systems analyst before he or she
can formulate a solution.
• 2) System Analysis Step: an analysis of the user’s needs.
• An incomplete or defective analysis will lead to an incomplete or defective solution.
• Deliverable or Product: Formal systems analysis report
• Which presents the findings of the analysis and recommendations for the
new system.
 Phase 2: Systems Analysis
1) System Survey Step
• 1) System survey
• Determine what elements, if any, of the current system should be preserved
as part of the new system.
• 2) Gathering facts
• Facts about the system are gathered and analyzed.
• 3) Fact-Gathering Techniques
• Assessment of the current system
• 4) Formally documents the impressions and understanding of the
system.
• the form of notes, system flowcharts, and data flow diagrams.
 Phase 2: Systems Analysis
1) System Survey Step
Advantages: Disadvantages
• Identifying what aspects of the • Current physical tar pit
old system should be kept • Thinking inside the box
• Forcing systems analysts to fully
understand the system.
• Isolating the root of problem
symptoms.
 Phase 2: Systems Analysis
1) System Survey Step
Gathering Facts Fact-Gathering Techniques
• System facts fall into the following broad • Systems analysts employ several
classes:
• Data sources
commonly used techniques to
• Users gather the previously cited facts.
• Data stores • Observation
• Processes
• task participation
• Data flows
• Controls • personal interviews
• Transaction volumes • reviewing key documents.
• Error rates
• Resource costs
• Bottlenecks and redundant operations
 Phase 2: Systems Analysis
2) System Analysis Step
• Systems analysis
• an intellectual process that is commingled (mix) with fact gathering.
• simultaneously analyzing as gathers facts.
• It is therefore difficult to identify where the survey ends and the analysis
begins.

• Primary purpose for conducting a systems analysis:

• To identify user needs
• To specify requirements for the new system.
• The requirements statement within the report
• constitutes a formal contract that specifies the objectives and goals of the system.
• establishes an understanding between systems professionals, Management, Users, & other stakeholders.
 Phase 2: Systems Analysis
2) System Analysis Step
• Systems Analysis Report

• Who to present:
• presents to management or the steering committee
• What to present:
• the survey findings, problems identified with the current system,
formally state the goals and objectives of the system, Analyzes user’s
needs, Specify requirements for the new system
• How to present:
• 1) Set out in detail what the system must do rather than how to do
it.
• 2) Establish in clear terms the data sources, users, data files, general
processes, data flows, controls, and transaction volume capacity.
• 3) Remains at the objectives level to avoid placing artificial
constraints on the conceptual design phase.
 Phase 2: Systems Analysis
2) System Analysis Step
Risk Controls
• Advanced audit features cannot • The accountant/auditor
be easily added to existing (external & internal) should be
systems. involved in the needs analysis of
the proposed system to
determine if it is a good
candidate for advanced audit
features and, if so, which
features are best suited for the
system.
 Phase 3: Conceptual Systems Design
• Purpose:
• is to produce several alternative conceptual systems that satisfy the system
requirements identified during systems analysis.
• Alternative designs/models
• Are presented to user, then the user will evaluate these models and settle on
the alternatives that appear most plausible and appealing.

• Two (2) approaches to conceptual systems design:

• 1) Structured approach
• 2) Object-oriented approach.
 Phase 3: Conceptual Systems Design
1) Structured Approach
• Develops each new system from
scratch, from the top down.
• Uses data flow and structure diagrams
in designing the business process.
 Phase 3: Conceptual Systems Design
1) Structured Approach
• System designs
• highlight the differences between critical features of
competing systems rather than their similarities.
• Demonstrate how the two systems are conceptually
different in their functions.
• identify all the inputs, outputs, processes, and special
features necessary to distinguish one alternative
from another

• Disadvantage: These designs lack the details

needed to implement the system.
• They do not include these necessary components:
Database record structures, Processing details,
Specific control techniques, Formats for input screens Figure 5.5 presents two alternative
and source documents, Output report formats conceptual designs for a purchasing system:
Batch System and EDI System
 Phase 3: Conceptual Systems Design
1) Structured Approach
Batch System (Traditional) EDI System
• The initial input for the process is the purchase • The trigger to this system is a purchase
requisition from inventory control. requisition from production planning.
• When inventories reach their predetermined reorder
• The purchases system determines the quantity
points, new inventories are ordered according to
their EOQ. and the vendor.
• Transmittal of POs to suppliers takes place once a day • Then transmits the order online via EDI
via the U.S. mail. software to the vendor.

• Advantages: • Advantage:
• simplicity of design
• ease of implementation
• may allow the firm to reduce or even eliminate
• lower demand for systems resources
inventories
• Disadvantage: • Disadvantage:
• requires the firm to carry inventories • more expensive and sophisticated system resources

Phase III  Identify plausible (reasonable) system designs.

Phase IV  Evaluate the relative merits of these alternatives.
 Phase 3: Conceptual Systems Design
2) Object-Oriented approach.
• Builds systems from the bottom up through the assembly of reusable
modules rather than create each system from scratch.

• How to develop the system using Object-oriented approach?

• User interface: build from scratch
• Other components of the system: comes from reusable standard
components
• standard modules can be used in other systems with similar needs.
• Library (inventory) of modules
• Are created by the organization’s systems professionals that can be used by other system
designers within the firm.
 Phase 3: Conceptual Systems Design
2) Object-Oriented approach.
• Most often associated with the iterative approach to SDLC
• where small “chunks” or modules cycle through all of the SDLC phases rather rapidly,
with a short time frame from beginning to end.
• Then additional modules are added in some appropriate fashion until the whole system
has been developed.

• Benefits of this approach:

• 1) reduced time and cost for development, maintenance, and testing
• 2) improved user support
• 3) flexibility in the development process
• by mixing and matching components according to the customer’s specification.
 Phase 3: Conceptual Systems Design

Risk Control
• The auditability of a system depends • The auditor is a stakeholder in all
in part on its design characteristics. FSs and, thus, has an interest in
the conceptual design stage of
the system.
• Systems should be designed with
special audit features that are
integral to the system
• These audit features must be
specified at the conceptual design
stage.
 Phase 4: System Evaluation and Selection
• An optimization process that seeks to identify the best system.
• Purpose of this phase:
• to structure this decision-making process and thereby reduce both uncertainty and the risk of
making a poor decision.

• The evaluation and selection process involves two steps:

• 1. Perform a detailed feasibility study
• 2. Perform a cost-benefit analysis

• After the process of evaluation and selection,

• Prepare Systems Selection Report
 Phase 4: System Evaluation and Selection
1) Perform a Detailed Feasibility Study
• Technical feasibility
• whether the system can be developed under existing technology or if new technology is needed.
• Economic feasibility
• pertains to the availability of funds to complete the project.
• Cost-benefit analysis - is used to identify the best system design for the cost.
• Legal feasibility
• identifies any conflicts between the conceptual system and the company’s ability to discharge its legal
responsibilities.
• Example: ordering system of wine for minors
• Operational feasibility
• shows the degree of compatibility between the firm’s existing procedures and personnel skills and the
operational requirements of the new system.
• Schedule feasibility
• relates to the firm’s ability to implement the project within an acceptable time.
 Phase 4: System Evaluation and Selection
2) Perform a Cost–Benefit Analysis
• Cost–benefit analysis
• Determines whether the benefits received from a proposed system will outweigh its costs.
• estimates the expected financial value of business investments.
• a useful tool for comparing competing systems designs

• Three (3) steps in the application of cost–benefit analysis:

• 1) identify costs
• One time costs & Recurring costs
• 2) identify benefits
• Tangible benefits & Intangible benefits
• 3) compare costs and benefits
• Two (2) most common methods used for evaluating information systems are
• a) net present value
• b) payback
 Phase 4: System Evaluation and Selection
2) Perform a Cost–Benefit Analysis
Identify Costs Identify Benefits
 Phase 4: System Evaluation and Selection
2) Perform a Cost–Benefit Analysis
Compare Costs and Benefits
Net Present Value Method Payback Method
• the present value of the costs is • a variation of break-even
deducted from the present value of analysis.
the benefits over the life of the
system. • The break-even point is reached
• Projects with a positive net present
when total costs equal total
value are economically feasible. benefits.
• When comparing competing projects, • In choosing an information
the optimal choice is the project with system, payback speed is often a
the greatest net present value. decisive factor.
 Phase 4: System Evaluation and Selection
Prepare Systems Selection Report
• Systems selection report
• The deliverable of the systems selection process.
• consists of
• a revised feasibility study
• a cost-benefit analysis
• a list and explanation of intangible benefits for each alternative design.
• The basis of the steering committee to select a single system.
 Phase 4: System Evaluation and Selection

• Risks: Errors, omissions, and misrepresentations in the accounting for such items can
distort the analysis and may result in a materially flawed decision.
• Controls:
• Auditors’ concern: that the economic feasibility of the proposed system is measured as
accurately as possible.
• Specifically, the auditor should ensure five things:
• 1. Only escapable costs are used in calculations of cost savings benefits.
• 2. Reasonable interest rates are used in measuring present values of cash flows.
• 3. One-time and recurring costs are completely and accurately reported.
• 4. Realistic useful lives are used in comparing competing projects.
• 5. Intangible benefits are assigned reasonable financial values.
 Phase 5: Detailed Design
• Purpose :
• To produce a detailed description of the proposed system that both satisfies the
system requirements identified during systems analysis and is in accordance with the
conceptual design.
• Output/Deliverable: Detailed Design report

• Two (2) Activities involved in the detailed design:

• 1) Perform a System Design Walkthrough
• System walkthrough  is a proven process designed to assess the effectiveness of the
system in achieving its desired results or outcomes.
• 2) Review System Documentation
 Phase 5: Detailed Design
1) Perform a System Design Walkthrough
• Purpose: to ensure that the design is free from conceptual errors that could become
programmed into the final system.

• Two (2) team or groups who perform design walkthrough:

• 1) Development team
• usually performs the walkthrough
• 2) Quality assurance group
• Is in charge of conducting the formal, structured walkthroughs.
• is an independent one made up of programmers, analysts, users, and internal auditors.
• Is hired to do the job of simulating the operation of the system to uncover errors, omissions,
and ambiguities in the design.
• Will make a recommendation, depending on the extent of the system errors,
 Phase 5: Detailed Design
1) Perform a System Design Walkthrough
• Decision is made either
• 1) to return the system design for modification
• 2) to reject the system design
• 3) to proceed to the next phase—system coding and testing.
 Phase 5: Detailed Design
2) Review System Documentation
• Detailed design report
• documents and describes the system to this point.
• Includes:
• Designs for all screen inputs and source documents for the system.
• Designs of all screen outputs, reports, and operational documents.
• Normalized data for database tables, specifying all data elements.
• Database structures and diagrams: ERDs, DFDs, Structure diagrams for the program modules in the
system, pseudocode description of each module.
• An updated data dictionary describing each data element in the database.
• Processing logic (flow charts).
• Quality control group
• scrutinizes these documents, and any errors detected are recorded in a walkthrough
report.
Pseudocode pronounced SOOdohkohd An outline of a program, written in a form that can easily be converted
into real programming statements.
 Phase 5: Detailed Design
• Risk: Most system errors emanate from poor designs rather than
programming mistakes.

• Controls:
• Detecting and correcting errors in the design phase thus reduces
costly reprogramming later.
• Hire Quality assurance group
• To do the job of simulating the operation of the system to uncover errors,
omissions, and ambiguities in the design.
 Phase 6: Application Programming and
Testing
• Two (2) Activities involved in phase 6:
• 1) Program the Application Software
• Select a programming language that is available and suitable to the
application
• 2) Test the Application Software
• All program modules must be thoroughly tested before they are implemented.
 Phase 6: Application Programming and Testing
1) Program the Application Software
• Program Languages:
• procedural languages like COBOL
• event-driven languages like Visual Basic
• object-oriented programming (OOP) languages like Java or C++.
• Three (3) factors that are used as a basis by Systems professionals to choose
on the program language:
• the in-house standards, architecture, and user needs.
 Phase 6: Application Programming and Testing
1) Program the Application Software
Procedural Languages Event-Driven Object-Oriented
Languages Languages
Features •Programmer is in control (specify •The user is in control * Binds related data
the precise order in which the (external actions or and functions into an
program logic is executed which “events” that are object and encourages
is sequentially from top to initiated by the user reuse
bottom). dictate the control of these objects
•The program’s code is executed flow of the program). within the same
in a predefined sequence. and other
Programs.
Languages Third-generation languages Microsoft’s Visual Java, Smalltalk, PHP,
(3GLs) such as COBOL, FORTRAN, Basic C/C++
C, and PL1. In
 Phase 6: Application Programming and Testing
1) Program the Application Software
• Programming the System
• Regardless of the programming language used, modern programs should follow
a modular approach.

• Three (3) benefits of modular programming:

• 1. Programming efficiency
• Modules can be coded and tested independently, which vastly reduces programming time.
• 2. Maintenance efficiency
• Small modules are easier to analyze and change, which reduces the start-up time during
program maintenance.
• 3. Control
• By keeping modules small, they are less likely to contain material errors of fraudulent logic.
 Phase 6: Application Programming and Testing
2) Test the Application Software
• Two entities who are involved in this activity:
• 1) System developers
• should follow the proven concepts about testing
• 2) Auditors
• should consider those concepts in conducting audits.

• Three (3) types of testing:

• 1) Testing Methodology
• The process itself has structured steps to follow.
• 2) Testing offline before deploying online
• Implementing a system without testing offline is an invitation to disaster.
• 3) Test data
• Creating meaningful test data is an extremely time-consuming aspect
of program testing.
• This activity can, however, provide future benefits to the auditor.
• Serves as a frame of reference for designing and evaluating future audit tests
 Phase 6: Application Programming and
Testing
• Risk: Implementing a system without testing offline is an invitation to
disaster.

• Controls:
• Test the application software by
• Testing methodology
• Testing offline before deploying online
• Testing data
 Phase 7: System Implementation
• The implementation process
• engages the efforts of designers, programmers, database administrators, users, and accountants.
• The activities in this phase
• entail extensive costs
• will often consume more personnel-hours than all other pre-implementation phases of the SDLC
combined.

• Five (5) activities that are involved in the system implementation:

• 1) Testing the Entire System
• 2) Documenting the System
• 3) Converting the Databases
• 4) Converting to the New System
• 5) Post-implementation review
 Phase 7: System Implementation
1) Testing the Entire System
•  the process of testing the system as a unified whole, after all modules have been
coded, tested, and brought together.

• What to test? All modules must be brought together and tested as a whole.
• Who will test? Test team
• comprising user personnel, systems professionals, and internal audit personnel.
• How to test? The procedure involves processing hypothetical data through the system.

• Formal acceptance document

• an explicit/formal acknowledgment by the user that the system in question meets stated
requirements .
• considered by many auditors to be the most important control over the SDLC.
 Phase 7: System Implementation
2) Documenting the System
• System’s documentation
• provides the auditor with essential information about how the system works.

• Three (3) groups of the documentation requirements:

• 1) systems designer and programmer documentation
• Systems designers and programmers need documentation to debug errors and perform maintenance on the system.
• Documents: DFDs, ERDs, structure diagrams, system flowcharts, program flowcharts, and program code listings.
• 2) computer operator documentation
• Computer operator uses documentation called a run manual, which describes how to run the system.
• 3) Users documentation
• Users need documentation describing how to use the system.
• Before designing user documentation, the systems professional must assess and classify the user’s skill level: novice,
occasional user, frequent light users, frequent power users
• Documents: user handbook and online documentation (tutorials & help features)
 Phase 7: System Implementation
2) Documenting the System
User’s Skill Novices Occasional users Frequent light users Frequent power users
Level

Features Have little or no Understood the •Familiar with limited •Understand the existing
experience with system but have aspects of the system. system and will readily adapt
computers. forgotten some •Tend not to explore to new systems.
essential commands beneath the surface & lack •Intolerant of detailed
and procedures. depth of knowledge. instructions, like to find
•Know only what it needs shortcuts, & use macro
to know. commands.

Trainings & User training & Require less training Requires training & Require only abbreviated
Documentation documentation & documentation documentation for documentation.
must be extensive than novices. unfamiliar areas.
and detailed
 Phase 7: System Implementation
2) Documenting the System
• User’s Documentation:
• 1) user handbook
• 2) online documentation
• guides the user interactively in the use of the system.
• Two (2) types of online features:
• 1) Tutorials
• can be used to train the novice or the occasional user.
• 2) Help features
• simple help feature  may be nothing more than an error message displayed on the screen.
• The user must “walk through” the screens in search of the solution to the problem.
• sophisticated help  is context-related.: The help feature analyzes the context of what the
user is doing at the time of the error and provides help with that specific function (or
command).
• When the user makes an error, the system will send the message, “Do you need help?”
 Phase 7: System Implementation
3) Converting the Databases
• Database conversion
• is a critical step in the implementation phase.
• the transfer of data from its current form to the format or medium required by the new system.
• data transfer may be accomplished by writing special conversion programs---changing the file structure of the
databases from sequential direct access files.
• Data conversion cost  the costs associated with transferring data from one storage medium to another
• Example:
• the move from a manual system to a computer system will require converting files from paper to magnetic disk
or tape.

• Three (3) precautions should be taken in data conversion:

• 1. Validation
• 2. Reconciliation
• 3. Backup
 Phase 7: System Implementation
3) Converting the Databases
• Data conversion is risky and must be carefully controlled.

• Three (3) precautions should be taken in data conversion:

• 1. Validation
• The old database must be validated before conversion.
• How to validate? By analyzing each class of data to determine whether it should be reproduced in the new
database.
• 2. Reconciliation
• After the conversion action, the new database must be reconciled against the original.
• How to reconcile?
• 1) manually - record by record and field by field. I
• 2) automated - by writing a program that will compare the two sets of data.
• 3. Backup
• Copies of the original files must be kept as backup against discrepancies in the converted data.
• How to backup? magnetic form or paper documents
 Phase 7: System Implementation
4) Converting to the New System
• System Cutover
• the process of converting from the old system to the new one.

• Three (3) approaches in the system cutover:

• 1) Cold Turkey Cutover
• also called the “Big Bang” approach
• the firm switches to the new system and simultaneously terminates the old system.
• Advantage: For simple system, it is the easiest and least costly approach.
• Disadvantage: For complex system, it is the riskiest.
• System errors that were not detected during the walkthrough and testing steps may materialize unexpectedly.
• Risk: unable to process transactions and meet its obligations to customers and creditors.
• Control: backup system
• 2) Phased Cutover
• begins operating the new system in modules.
• Advantage: Reduce the risk of a devastating system failure.
• Risk: Incompatibilities between new subsystems and yet-to-be-replaced old subsystems.
• Control: Implementing special conversion systems that provide temporary interfaces during the cutover period.
• 3)Parallel Cutover
• involves running the old system and the new system simultaneously for a period of time.
• Advantage: The reduction in risk since the user can reconcile outputs
• Disadvantages: The most time-consuming and costly of the three.
 Phase 7: System Implementation
4) Converting to the New System
• System Cutover
• the process of converting from the old system to the new one.

• Three (3) approaches in the system cutover:

• 1) Cold Turkey Cutover
• 2) Phased Cutover
• 3)Parallel Cutover
 Phase 7: System Implementation
4) Converting to the New System
• Three (3) approaches in the system cutover:
• 1) Cold Turkey Cutover
• also called the “Big Bang” approach
• the firm switches to the new system and simultaneously terminates the old
system.
• Advantage: For simple system, it is the easiest and least costly approach.
• Disadvantage: For complex system, it is the riskiest.
• System errors that were not detected during the walkthrough and testing steps may
materialize unexpectedly.
• Risk: unable to process transactions and meet its obligations to customers
and creditors.
• Control: backup system
 Phase 7: System Implementation
4) Converting to the New System
• Three (3) approaches in the system
cutover:
• 2) Phased Cutover
• begins operating the new system in
modules.
• Advantage: Reduce the risk of a
devastating system failure.
• Risk: Incompatibilities between new
subsystems and yet-to-be-replaced old
subsystems.
• Control: Implementing special conversion
systems that provide temporary
interfaces during the cutover period.
 Phase 7: System Implementation
4) Converting to the New System
• Three (3) approaches in the system
cutover:
• 3)Parallel Cutover
• involves running the old system and
the new system simultaneously for a
period of time.
• Advantage: The reduction in risk since
the user can reconcile outputs
• Disadvantages: The most time-
consuming and costly of the three.
 Phase 7: System Implementation
5) Post-Implementation Review
•  conducted by an independent team to measure the success of the
system (whether it is on budget, on time, and it meets user needs).
• Risk: The goal of producing systems that are on budget, on time, and
meet user needs is not attained.

• Two (2) uses or advantages of post-implementation review:

• 1) For management: Can provide insights into ways to improve the
process for future systems.
• 2) For internal & external auditors: Can provide evidence regarding the
adequacy of the SDLC in general and the risks associated with a particular
system.
 Phase 7: System Implementation
5) Post-Implementation Review
• Two (2) types of post-implementation evidences:
• 1) Systems Design Adequacy
• The physical features of the system should be reviewed to see if they meet
user needs.
• 2) Accuracy of Time, Cost, and Benefit Estimates
• a review of actual performance compared to budgeted amounts provides
critical input for future budgeting decisions
 Phase 7: System Implementation
Internal Auditor’s Role in System Implementation
• External auditors
• are prohibited by SOX legislation from direct involvement in systems implementation.

• Three (3) ways that Internal auditors may get involved in the system
implementation:
• 1) Provide Technical Expertise
• Specifications must comply with GAAP, GAAS, SEC regulations
• 2) Specify Documentation Standards
• Since financial systems must periodically be audited, they must be adequately documented.
• 3) Verify Control Adequacy and Compliance with SOX.
• Adequacy: AIS applications must possess adequate controls
• Compliance with SOX: Requires management to certify the existence and effectiveness of
those controls.
Phase 7: System Implementation

Risks Controls
• If operator documentation • The activities of programmers and
includes system flowcharts, logic operators should be separated.
• Consistent with this segregation of duties
flowcharts, and program code issue, operators should not have access
listings. to the details of a system’s internal logic.
• If operators have access to the • For security and control reasons,
details of a system’s internal system flowcharts, logic flowcharts,
logic. and program code listings should not
be part of the operator
documentation.
Phase 8: Systems Maintenance
•  the longest period in the SDLC, often spanning several years (5 years or longer).
•  represents a significant resource outlay compared to initial development costs: 80/20 rule
• 80% of the total cost of a system occurs in the Maintenance phase!
• Only 20% actually occurs in the other 7 phases.

• Two (2) types of maintenance:

• 1) Trivial  such as modifying the system to produce a new report or changing the length of a
data field.
• 2) Extensive  such as making major changes to an application’s logic and the user interface.

• If not feasible to continue to maintain an aging system:

• It is scrapped, and a new systems development life cycle begins.
 Phase 8: Systems Maintenance
• Risk: Program fraud & Lack of documentation

• Control: Programmer under system development should be different

from programmer under system maintenance.