Week 6: Systems Development and Program Change Activities

At the end of this module you are expected to:

1. Determined the stages in the systems development life cycle

2. Understand the importance of strategic system planning.
3. Identify the basic features of both the structured and object-oriented approached to system
design
4. Identify and discuss the major steps involved in a cost-benefit analysis of proposed information
systems.
5. Understand the advantages and disadvantages of the commercial software option and be able
to discuss the decision-making process used to select commercial software.
6. Be familiar with the different types of system documentation and the purpose they serve
7. Understand the risks, controls, and audit issues related to systems development and
maintenance procedures.

The Systems Development Process

The systems development process is a set of methodological processes, activities, or phases used by
organizations to obtain IT-based information systems. During a financial statement audit, an auditor
would look into it as it involves the information of the company as a whole which includes important
financial data and transactions. The auditor would test the integrity of the process as how the
transactions are planned, authorized, scheduled, accounted for, and controlled.

Another reason by an auditor’s interest in the organization’s systems development process would be the
actual products that is apparent from it. There is a parallel line between the quality of the accounting
information presented in an organization’s financial statements and the quality of the accounting
information systems that process and report it. An auditor is concern on the domino effect that can
occur if an error in the development process exist. Financial reports are prepared and generated from
through the systems development process.

Participants in Systems Development

Systems Professionals

These individuals are the ones who actually build the system which involves systems analysts,
systems engineers and programmers. They identify the problems of the current system, gather
and analyze the facts pertaining to the problems, and formulate solutions to solve such
problems. The end result will be a brand new information system.

End Users

They are the reason why the systems are built. These include different levels in an organization
such as managers, personnel from various operation departments.

Stakeholders

These are individuals either within or without the organization who have an interest in the
system but are not formal end users. These includes accountants, internal and external auditors
 and the internal steering committee that oversees the systems development. This is to ensure
that the user’s needs are met, and adequate internal control are applied into the systems under
construction.

Information Systems Acquisition

Information systems are usually acquired by an organization by an in-house development of customized
systems through formal systems development activities and acquisition from software vendors of
commercial systems.

In-house Development

Some organizations aim to development information systems that can cater its unique
operations. With that these organizations would prefer to develop its own information systems
through the in-house systems development activities. In this method, full time group of analysts
and programmers are required to be maintained to identify the needs of user information and
to create the custom systems.

Commercial Systems

An organization, as an alternative, can outsource the development of information system

through the purchase from software vendors. This option, as may be taken easier than the in-
house development, still requires a planning and decision making on the part of the
management. Software vendors are competing, offering each product and how it is better than
the others. Management carefully compares and selects which software is the best and the
most suitable to the organization’s structure and needs.

Commercial systems are becoming more popular that the in-house development due to the
following factors:

 Lower cost. With the budget being taken into consideration, commercial systems are
relatively cheaper than the in-house development since, for an instance, the
maintenance of analysts and programmers are eliminated.
 Industry-specific vendors. Diverse classifications of vendors are available in the market
allowing the organization to narrow down its choices to select the best software that
can cater its needs.
 Growing demand from small businesses. In-house systems’ development staff is difficult
to afford given that it is too small for a growing demand from businesses.
 Downsizing organizational units. It is now a trend to downsize organizational units.
Moreover, the idea of distributed data processing makes the commercial software
option more appealing to organizations, especially the large ones.

There are three basic groups of commercial software packages namely:

1. Turnkey Systems. These are systems that are completely finished and tested and are readily
available for implementation. Depending on the specific industry, these are often general-
purpose systems or systems customized. Usually, turnkeys are available as compiled and
completed program modules limiting the users to customize them according to their specific
 needs. Although, vendors provide software, for a free, to let the users modify the input and
output of the system as well as processing some menu choices.
Presented below are the most common examples of turnkey systems:
 General Accounting Systems – this is a standard system developed in order to serve
a wide group of user needs. With this, the cost of creation becomes less expensive
and way more affordable than an in-house development. Some features of general
accounting systems modules include accounts receivable, inventory control, fixed
assets, accounts payable, general ledger and financial reporting.
 Special-Purpose Systems – as compared to general accounting systems, special-
purpose systems are created to serve specific industry. For an instance, the systems
for a banking industry is far different from the systems for a manufacturing
company. The software vendors, then, would offer systems to the previous that
specifically cater its operations and needs.
 Office Automation Systems – these are computer systems which improve the
employee’s productivity through the availability of word processing packages,
database management systems, spreadsheets programs, and desktop publishing
systems.
2. Backbone Systems. These provide a basic system structure on which to build. Backbone
systems come with all the primary programmed processing modules. To suit the client’s
needs, the user interface are designed and programmed. Some systems such as enterprise
resource planning (ERP) offer a vast array of modules for dealing with almost every
conceivable business process, and all are interfaced seamlessly into a single system. The
customer can create a highly customized system through the selection of the appropriate
modules. However, the customization of a commercial system, can be time consuming and
expensive.
3. Vendor*supported Systems. Customized systems for the client organization’s development
and maintenance. Some support levels that are possible under this model include the
following:
 Application, installation, system configuration, data conversion, personnel training,
and trouble shooting and maintenance.
 Database support involves developing and maintaining the database tables for the
application.
 Configuring the server and operating system to host the application and database.
 Interfacing the vendor supported application to other in-house supported systems
where data sharing between systems is necessary.
 Back-up and recovery of programs and data as part of an organization’s disaster
recovery plan.

Enumerated below are the advantages and disadvantages of commercial software.

Advantages of Commercial Software

 Implementation time. Apparently, commercial software are readily available in the

customer market and would only take up lesser period for the trial and testing phase,
transition phase and actual application phase.
  Cost. The acquisition cost of commercial software is lower than of the in-house
development as the costs are spread across many users.
 Reliability. Most of the commercial software packages with good reputation are tested
thoroughly before releasing them in the market. Although errors are inevitable and
might be inherent, commercial software is more likely free of errors than the in-house
development.

Disadvantages of Commercial Software

 Independence. A risk on vendor-supported system occur and dependent on the vendor’s

long-term viability.
 Need for customized systems. Although these are special-purpose systems under the
turnkey systems, the exact and accurate needs of an organization may not be met by
commercial software. Unlike in an in-house development, the system can be tailored to
each and every needs of the organization.
 Maintenance. Information systems are dynamic. The business information system would
adjust due to different factors, internal and external, resulting to a change in its needs.
With this change, the system must be modified which is difficult for a commercial
software.

The Systems Development Life Cycle

Information problem is recognized and it is the initial phase of the life of information systems.
This begins the systems development process, which a new information system is created and
implemented. As the time passes by, changes in the needs of a business, specifically in the
technology, occur. With these changes, the information systems of an organization must be
modified and updated. However, some systems become obsolete and modification becomes
impossible. Systems development process and the life cycle of systems are triggered due to the
recognition of these needs.

Figure 5.1

The Systems Development Life Cycle is a conceptual model that defines the organizational,
personnel, policy and budgeting constraints of a large scale systems project. This starts from
initial planning through maintenance and eventual retirement of the completed system. The
length of the SDLC varied depending on the needs and industry where the organization belongs.
As shown in figure 5.1 above, there are none (9) phases of SDLC and the first seven (7) phases
involve the process undergone for all new systems.

New systems development is composed of conceptual steps that can apply to any problem-
solving such as:

 Identification of the problem

 Understand what needs to be done
 Provide list of possible solutions
 Determination of the best solution
 Implementation of the chosen solution

The eight (8th) phase of the cycle involves the system maintenance which includes the change
and upgrades of the systems completed and fully implemented.

Each and every phase of SDLC is discussed thoroughly in the next parts.

Phase I – Systems Planning

The purpose of systems planning is to determine the scope of the problem and found out
possible solutions. Individual system projects or applications are linked to the strategic
objectives of the firm. Through the business plan, resources, costs, time, benefits and other
items are considered in this place. Analysis of systems projects against IT strategic plan is made
which is developed from and must be congruent with the organization’s business plan.

In most of the projects, the planning phase takes the longest period as everything must be taken
into consideration. The organization establishes a systems steering committee to provide
guidance and review the status of the system projects. The steering committee may be
composed of the CEO, CFO, CIO, senior management from user areas and computer services,
and internal auditor. Some of the responsibilities of steering committee are:

 Resolves conflicts of new systems

 Assigns priorities and reviews projects
 Budget funds for system development
 Reviews the individual’s project status that are under development
 Determines various checkpoints whether to continue or terminate the project.

Systems planning includes strategic planning and project planning.

Strategic Systems Planning

Strategic systems planning is the allocation of systems resources at the macro level. The
time frame for strategic systems planning is usually from three to five years. This
process involves activities like product development, market research, plant expansion
and manufacturing technology which are similar to strategic activities of budgeting
resources.
 Strategic planning is done in a SDLC due to the following justifications:

1. Changes of plans throughout SDLC is better than no plans at all.

2. Crisis component in systems development are reduced by strategic planning.
3. Strategic systems planning provides authorization control for the SDLC.
4. Managing systems and application development become cost-effective because of
strategic planning.

Project Planning

The objective of a project planning is to allocate resources to individual applications

within the framework of the strategic plan. This process involves:

 Identification of areas of user needs

 Preparation of proposals
 Evaluation of each proposal’s feasibility and contribution to the business plan
 Priority of individual projects
 Schedule of upcoming works

Two documents are prepared in this process such as:

1. Project proposal – this helps the management to decide whether to continue the
project or to terminate. It summarizes the findings of the study conducted to
provide a recommendation for the new or modified system. It also provides the
relation between the proposed system objectives and the business objectives of the
organization.
2. Project schedule – it is composed of the timeline and budget of the project for all
the phases of the SDLC.

Phase II – Systems Analysis

Systems analysis includes (1) Survey of the current system; and (2) Analysis of the user’s needs.
After this phase, a formal document. Systems Analysis Report, is prepared to present the
findings during the analysis and provide recommendations for the new system.

The Survey Step

The current systems are analyzed by determining which of its elements should be
preserved and retained to be part of the new system. This process involves a system
survey where the analyst gathers data regarding the new system and analyzed them
through understanding the problem and creating possible questions.

Facts Gathering

Gathering of facts during the survey step is done and includes the following broad
classes:

 Data sources – includes customers or vendors as external entities and internal

sources from other departments
 Users – operation users and managers
  Data stores – these are source documents used in the system, databases, files
and accounts.
 Processes – these are manual or computer tasks that serve as decision and
action triggered by information.
 Data flows – movement of documents and reports between data sources,
processing tasks, data stores and users represents data floes.
 Controls – these include both accounts and operational controls and may be
manual procedures or computer controls.
 Transaction volumes – the analyst must determine the capacity of transaction
volumes of the systems. Its determination as well as its rate of growth are
important factors in the assessment of the required capacity for the new
system.
 Error rates – error rates are closely related to transaction volumes as the system
reached its capacity, the higher the error rates. The analyst must determine the
tolerable level of the system in terms of errors.
 Resource costs – these includes the cost of materials, time, labor and direct
overhead. Escapable costs are any resource costs that disappear when the
current system is eliminated and will be treated as benefits of the new system
during the cost-benefit analysis.
 Bottlenecks and redundant operations – these involves delays and processing
errors because data flows come together to form a bottleneck. The analyst must
determine the point where the bottlenecks are occurred. Moreover, these
delays may also cause redundant operations which make the process ineffective
and inefficient.

The above-mentioned facts gathering can be obtained in different ways or a

combination of the following:

 Observation. Watching of physical procedures of the system and noting who

performs what tasks and how, why and how long it is done.
 Task participation. The analyst experiences first-hand the problems arises in the
current system.
 Personal interviews. Personal interviews are done either through providing
open-ended questions or questionnaires.
 Reviewing key documents. The analyst may look into and review the
organization’s documents such as the organizational charts, accounting records,
charts of accounts, system flowcharts, forecasts and others.

The Analysis Step

The analysis step can be done simultaneous to the facts gathering. The mere recognition
of a problem presumes some understanding of the norm or desired state. It is therefore
difficult to identify where the survey ends and the analysis begins.

Phase III – Conceptual Systems Design

The objective of the conceptual design phase is to provide various choices of conceptual systems
which are within the system requirements identified during the systems analysis. Pre-conceived
constraints on the new system can be avoided if there are number of alternatives presented to
the systems professionals. The user will evaluated these conceptual models and settle on the
alternatives that appear most plausible and appealing.

The conceptualization of systems design through the SDLC phase minimizes the investment of
resources in alternatives designs, which, ultimately will be rejected. The conceptual systems
design describes two approaches, namely:

a. Object-oriented design (OOD) – builds systems from the bottom up through the assembly of
reusable modules rather than create each system from scratch. This is 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 from beginning to end.
b. Structured design approach – builds systems from the top down which consists of the “big
picture” of the proposed system that is gradually decomposed into more and more detail
until it is fully comprehended. Data flow and structure diagrams are used in this approach.

Figure 5.2 Top-Down Decomposition of the Structured Design Approach

Figure 5.2 above shows the use of structure diagram and data flow diagrams to depict the top-
down decomposition of a hypothetical business process. The diagram started with an abstract
description of the system and, through successive steps, redefines this view to produce a more
detailed description.

Phase IV – System Evaluation and Selection

The fourth phase of SDLC is the selection of the system from the various alternative conceptual
designs that will go to the detailed design phase. The systems evaluation and selection phase is
an optimization process that seeks to identify the best system. The selection of the best system
is a critical decision in the SDLC as a poor judgment would result to a great uncertainty about
the system and can become disastrous. The evaluation and selection process involves two steps
as follows:

1. Perform a Detailed Feasibility study

There are five aspects of project feasibility which must be considered and assessed in the
same manner.

Figure 5.3 TELOS: Feasibility Study

https://business.tutsplus.com/articles/can-we-really-do-it-how-to-conduct-a-telos-
feasibility-study--cms-21442

 Technical Feasibility – This is concerned whether the system can be developed

under the existing technology or if new technology is needed.
 Economic Feasibility – Economic feasibility is concern if there are funds available to
complete the project.
 Legal Feasibility – Legal feasibility identifies any conflicts between the conceptual
system and the company’s ability to discharge its legal responsibilities.
 Operational Feasibility – It shows the degree of compatibility between the firm’s
existing procedures and personnel skills and the operational requirements of the
new system.
 Schedule Feasibility – This is the firm’s ability to implement the project within an
acceptable time.
2. Perform a Cost-Benefit Analysis

This analysis is performed to guide management in determining if the benefits received

from the proposed system are greater than the costs. This technique is frequently used for
estimating the expected financial value of business investments, therefore in this case, the
investment in an information system, the costs and benefits are identified and quantified.
This is more difficult than those of traditional capital projects.

Cost-benefit analysis involves three steps such as:

 Costs identification. Costs identification are done through categorizing the costs as
one-time costs and recurring costs. One-time costs include the initial investment to
develop and implement the system such as:
- Hardware acquisition
- Site preparation
- Software acquisition
- Systems design
- Programming and testing
- Data conversion from old system to new system
- Personnel training

On the other hand, recurring costs include the operating and maintenance costs
that recur over the life of the system. Examples are:

- Hardware maintenance
- Software maintenance contracts
- Insurance
- Supplies
- Personnel

 Benefits identification. Benefits can be classified as tangible and intangible. Tangible

benefits are further classified into two such as those that increase the revenue and
those that reduce the costs. Tangible benefits that increase the revenue are:
- Increased sales within existing market; and
- Expansion into other markets

While tangible benefits that reduce costs are:

- Labor reduction
- Operation cost reduction (supplies and overhead)
- Reduced inventories
- Less expensive equipment
- Reduced equipment maintenance

Meanwhile, intangible benefits are those benefits derived from the system which
are not quantifiable. These cannot be measured easily that sometimes organization
do not realize its importance in the information system decisions. Examples of
intangible benefits are:

- Increased customer satisfaction

- Improved employee satisfaction
- More current information
 - Improved decision making
- Faster response to competitor actions
- More efficient operations
- Better internal and external communications
- Improved planning
- Operational flexibility
- Improved control environment
 Costs and Benefits Comparison. After costs and benefits are identified, the final step
in the cost-benefit analysis is the comparison of the two to determine if the benefits
outweigh the costs or vice versa. The most common techniques in the costs and
benefits comparison are the net present value and payback.

Under the net present value method, the present value of the benefits over the life
of the system is deducted by the present value of the costs. Project with a positive
net present value or the one with the highest net present value is considered as the
most feasible.

In the payback method, the analysis of the break-even is done. Break-even is the
point when the total costs equal the total benefits.

At the end of the phase, the analysts are expected to prepare and present the Systems
Selection Report, which is a formal document that consists of a revised feasibility study, cost-
benefit analysis, and a list and explanation of intangible benefits for each alternative design.

Phase V – Detailed Design

A detailed description of the proposed system is produced in this phase to satisfy the system
requirement identified during the systems analysis and this must be in accordance with the
conceptual design. System components such as database tables, processes and controls are
specified meticulously in this phase and then presented in a formal way through a detailed
design report. A detailed design report constitutes a set of blueprints that specify input formats,
output report layouts, database structures, and process logic.

A detailed design report consists the following:

 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: Entity relationship (ER) diagrams describing the
data relations in the system, context diagrams for the overall system, low-level
data flow diagrams of specific system processes, structure diagrams for the
program modules in the system – including a pseudocode description of each
module.
 An updated data dictionary describing each data element in the database.
 Processing logic (flowcharts).

System Design Walkthrough

 A system design walkthrough is performed after the completion of the detailed design
to ensure that the design is free from conceptual errors that could become programmed
into the final system. A quality assurance group performs the system design
walkthrough for some firms. This group is composed of programmers, users, analysts
and internal auditors whose job is to simulate the operation of the system to detect
errors, omissions and ambiguities in the design.

Phase VI – Application Programming and Testing

Selection of the programming language is done in this phase. Among the several languages
available, the one suitable to the application is selected. These include procedural languages like
COBOL, event-driven languages like Visual Basic, or object-oriented programming (OOP)
languages like Java or C++.

Procedural Languages

Procedural languages, also known as third-generation languages (3GLs) require the

programmer to specify the precise order in which the program logic is executed. With
different examples like COBOL, FORTRAN, C, and PL1, COBOL is the most dominant in
business, particularly in accounting.

Event-driven Languages

Programs written in event-driven languages are designed to respond to external actions

or events that are initiated by the user. For an instance, when the user presses a key or
clicks on an icon on the computer screen, the program automatically executed code
associated with that event. This is a fundamental shift from the 3GL era; instead of
designing application that execute sequentially from top to bottom in accordance with
the way the programmer thinks they should function, the user determines the order of
code execution.

Object-oriented Languages

A computer language is considered to be object-oriented if it supports the following:

1. Object – a real-world phenomenon that has state and behavior. Example is an

online shopping system which objects are shopping cart, customers and products.
2. Class and instance – class is the attributed and methods common to all objects
while instance is considered as the particular class. For example, Inventory is a class
while pliers, hammers, screwdrivers are the instances of the inventory class.
3. Encapsulation – it is the act of binding together the data and methods which
manipulate the data, thus, keeps both safe from unauthorized access and misuse.
4. Inheritance – means that each object instance inherits the attributed and methods
of the class to which it belongs.
5. Polymorphism – allows multiple and different objects to respond to the same
message.

Programming the System

 A modular programming must be performed regardless of the program language used
because of the following benefits:

a. Programming efficiency
b. Maintenance efficiency
c. Control

Phase VII – System Implementation

This phase includes testing the entire system, documenting the system, converting the
databases and performing a post-implementation review. These processes requires the time an
effort of designers, programmer, database administrators, users and accountants resulting to
extensive costs.

Testing the Entire System

Once all modules are coded and tested, these will be all combined and tested as a
whole. A hypothetical data are used in the system to perform this process. The actual results will
be then compared to the predetermined results, and the test is documented to provide
evidence of the system’s performance. Once the results become satisfactory to those who are
conducting the tests, a formal acceptance document is prepared to explicitly acknowledge by
the user that the system meets the stated requirements.

Documenting the System

Documenting the system includes three groups such as the systems designers and
programmers, computer operators, and end users. Documenting the system helps the auditor in
aiding essential information about how the system works.

 Designer and Programmer Documentation. System designers and programmers need

documentation to debug errors and perform maintenance on the system. This group is
involved with the system on a highly technical level, which requires both general and
detailed information. Some of this is provided through DFDs, ER diagrams, and structure
diagrams. In addition, system flowcharts, program flowcharts and program code listings
are important forms of documentation. The system flowchart shows the relationship of
input files, programs and output files. However, it does not reveal the logic of individual
programs that constitute the system. The program flowchart provides a detailed
description of the sequential and logical operation of the program. Each program in the
system’s flowchart is represented by a separate program flowchart, as shown in Figure
5.4. From these, the programmer can visually review and evaluate the program’s logic.
The program code should itself be documented with comments that describe each
major program segment.
Operator Documentation

Run Manual is a documentation used by computer operators which described how to run
the system. The usual content of a run manual are as follows:

 Name of the system (example: Sales Systems)

 Schedule of run (daily, weekly, time of day, etc.)
 Required hardware devices (tapes, disks, printers or special hardware)
 File requirements specifying all the transaction (input) files, master files, and
output files used in the system.
 Run-time instructions describing the error messages that may appear, actions to
be taken, and the name and telephone number of the programmer on call
should the system fail.
 A list of users who receive the output from the run.

User Documentation

This describes how the user can use the system such as the process of entering input for
transactions, account balances inquiry process, how to update accounts, and generation of
output reports. The nature of user documentation will depend on the user’s degree of
sophistication with computers and technology. Therefore, the classification of users must be
determined before designing the user documentation. Classifications of users can be:

 Novices – have no or little experience with computers. They know little about
the assigned tasks making the training and documentation extensive and
detailed.
 Occasional users – require less training and documentation than novices as they
have understood the system. However, some essential command and
procedures are forgotten.
 Frequent light users – 3rd level of users who are familiar with limited aspects of
the system. However, they have lack depth of knowledge and tend not to
explore.
 Frequent power users – understand the existing system and will readily adapt to
new systems. They are intolerant of detailed instructions that waste their time.
They like to find shortcuts and use macro commands to improve performance.
 Converting Databases

Database conversion is the transfer of data from its current format to the format or medium
required by the new system. Thus, this is a critical step in the implementation phase. The
adaption in technology is the basis of the degree of conversion from the old system to the
new one. Some process are very labor intensive, which requires the data to be manually
entered in the database. During the data conversion, some precautions must be taken as
follows:

 Validation – validation of old database is required. This means that each class of
data must be analyzed to determine if which should be reproduced in the new
database.
 Reconciliation – the new database must be reconciled against the original. The
process can either be manual (record by record or field by filed) or automated
(writing a program that will compare the two sets of data).
 Backup – backup of keeping of the original files must be done to verify if there
are any discrepancy against the original database. The current files can be
conveniently backed up if they are already in magnetic form. On the other hand,
there will be a storage problem if data are still in paper documents.

Converting to the New System

Cutover is the conversion of old system to the new one. System cutover will usually follow
one of three approaches:

1. Cold Turkey Cutover – also known as Big Bang Approach, the old system s discarded
simultaneous to the use of the new system. This approach is considered as the easiest
and least costly, however, with more complex systems, considered as the riskiest as
there is no back up of data process.
2. Phased Cutover – in this approach, the entire system is not immediately terminated as
the new one started. Partial removal of the system is done as the new one is run.
3. Parallel Operation Cutover – it involves running the old system and the new system
simultaneously for a period of time.

Post-Implementation Review

An independent group conducts a post-implementation review to measure how successful the

system and how the problems initially determined were resolved. This process, which is
considered as the most important step in the implementation stage, helps the management in
providing insights on how to improve the processes of the newly installed system. A valuable
post-implementation review is evidenced by the following:

 Systems Design Adequacy – this involves the review of the physical features of the
system and should provide answers to, but not limited to the following questions:
o Does the output from the system possess such characteristics of information as
relevance, timeliness, completeness, accuracy, and so on?
o Are the databases accurate, complete and accessible?
o Were data lost, corrupted, or duplicated by the conversion process?
 o Are the users using the system properly?
o Is user documentation accurate, complete and easy to follow?
o Does the system provide the user adequate help and tutorials?
 Accuracy of Time, Cost and Benefit Estimates – this is done by the review of the
budgeted amount versus the actual performance to provide guidance for future
budgeting decisions. The post-implementation review should provide insights through
the following questions:
o Were actual costs in line with the budget costs?
o What were the areas of significant departures from budget?
o Was the degree of network due to design and coding errors acceptable?
o Were values assigned to tangible and, especially, intangible benefits accurate?

Phase VIII – System Maintenance

Upon system implementation, the final phase of SDLC occurs. Systems maintenance is the
formal process of updating the application programs to accommodate the changes in users’
needs. Some application changes are trivial, such as modifying the system to produce a new
report or changing the length of a data field. This phase is a significant resource outlay as
compared to the initial development costs.

Controlling and Auditing the SDLC

In this section, the work of the auditor is to verify that the processes previously discussed are controlled
and functioning properly and effectively. With this, the auditor may limit the extent of application of
control testing that needs to be done and can establish a basis for limiting substantive tests.

System Authorization Activities

All systems must be properly authorized to ensure their economic justification and feasibility. As
with all material transactions, authorizing the development of a new information system should
be a formal step in the process. Typically, this requires that each new system request be
submitted in writing by users to systems professional who have both the expertise and authority
to evaluate and approve (or reject) the request.

User Specification Activities

Involvement of the users in the system development process is highly important. Regardless of
the proposed system’s technical complexity, the involvement of the users should not be set
aside. The user should provide description of the logical needs that must be satisfied by the
system.

Technical Design Activities

The produced documents in user specification activities is translated in this phase into a
technical specification of a system. The activities involve system analysis, general systems
design, feasibility analysis, and detailed systems design. The adequacy of these activities is
measured by the quality of the documentation that emerges from each phase. Documentation is
both a control and evidence of control and is critical to the system’s long-term success.
 Internal Audit Participation

The internal auditor plays an important role in the control of systems development activities.
The auditor is involved from the beginning of the process up to the maintenance phase.

 Systems Planning. As this is a crucial phase and should be given importance, the role of
an internal auditor is to review the process to verify if the systems produced are
consistent with the organization’s goals and objectives.
 Systems Analysis. The internal auditor or the group of internal audit must have an ability
to accurately assess situation in relation to computer technology and with a solid grasp
of the business problems of users.
 Conceptual Systems Design. The internal auditor must have high knowledge and
expertise in an integrated audit features to check which feature is the most suitable for
the system. Integrated audit tools will add costs and significant features to the system
that should be specifies at the conceptual design stage and budgeted into the system.
 Evaluation and Selection. The auditor should ensure the following:
o Only escapable costs are used in calculations of cost savings benefits
o Reasonable interest rates are used in measuring present values of cash flows
o One-time and recurring costs are completely and accurately reported
o Realistic useful lives are used in comparing competing projects
o Intangible benefits are assigned reasonable financial values
 System Implementation. Auditors are needed to provide guidance in completing the
system3

The Controlling and Auditing Systems Maintenance

Maintenance, Authorization, Testing and Documentation

The benefits achieved from controlling new system development can be quickly lost during the
system maintenance if control does not continue into that phase. Access to systems for
maintenance purposes increases the possibility of systems errors. Logic may be corrupted either
by the accidental introduction of errors or intentional acts to defraud. To minimize the potential
exposure, all maintenance actions should require, as a minimum, four control: formal
authorization, technical specification of the changes, retesting the system and updating the
documentation.

Source Program Library (SPL) Controls

Source Program Library is a magnetic disk which stores application program source code in
larger computer services. The SPL must be controlled through some protective features and
procedures which must be explicitly addressed. An implementation of an SPL Management
System (SPLMS) is required and is used to control the following functions:

1. Storing program on the SPL

2. Retrieving programs for maintenance purposes
3. Deleting obsolete program from the library
4. Documenting program changes to provide an audit trails of the changes.