SYSTEM DEVELOPMENT

LIFE CYCLE
INFORMATION SYSTEM OPERATION AND MAINTENANCE
SYSTEM DEVELOPMENT LIFE CYCLE
OVERVIEW
SYSTEM DEVELOPMENT LIFE CYCLE

• The System Development Life Cycle (SDLC) is a conceptual model used in

project management that described the different stages involved in developing
an information system project:
• Planning for an information system
• Development and implementation
• Maintenance and program change

• The SDLC is of interest in the audit of an organization as the integrity of

information generated from the entity’s information system will be affected by
how the system is created and maintained.
PARTICIPANTS IN SDLC

Area Description
System • Includes the system analysts, engineers, and programmers that are involved
professionals in the actual development of the system.
• Gathers facts and analyzes facts about the current system and formulate a
solution to those problems by developing a new system.
End users • Persons for whom the system is build.
• System professional understand the user’s needs in order to formulate
solutions that is suited to their needs.
Stakeholders • Individual within or outside the organization that has an interest in the
system but not end user.
• Includes the auditors (internal/external) and steering committed overseeing
the system development.
Accountant/ • Professionals that address controls, financial data processing, and auditing
Auditors issues for system development.
• Involves the internal auditor and IT auditor.
• External auditor is prohibited from direct involvement in system
development.
INFORMATION SYSTEM ACQUISITION

• In-house development: Development of an organization’s own information system that is

highly tuned in with its operation.

• Commercial Systems: Purchasing from a software vendor.

Type of system Description

Turnkey systems Completely finished and tested systems that are ready for implementation (e.g.,
Peach Tree, Quickbooks).
Special-purpose Vendor creates specialized software that will cater the needs of a specific industry
systems (e.g., valuation software for the banking industry).
Office automation Computer system that improve office productivity (e.g., Microsoft Office
system applications).
Backbone system Vendor provides a basic system structure where the system will be build, and then
designs and programs the user interface to suit the client’s needs (e.g., ERP
systems like SAP)
Vendor-supported Vendor develops and maintains a custom system for its clients.
ADVANTAGES AND DISADVANTAGES OF
COMMERCIAL SYSTEMS
Advantages: Disadvantages:

• Short development and implementation

time • Vendor dependence
• Relatively cheaper since development
overhead is spread across multiple • Inflexible on customization
users and modifications needed
• Reliability is ensured with multiple
product testing conducted by the
developer before commercialization.
PHASES OF SDLC
Step 4:
Step 3: System
Step 1: Step 2:
Conceptual evaluation
System System system and
planning analysis design selection

System
Step 6: Step 5:
maintenance Step 7:
Programmin Detailed
and program Implementatio
n g and system
change
testing design
procedures
PHASE 1: SYSTEMS PLANNING
SYSTEMS PLANNING

• The main objective of system planning is to link systems

projects and applications with the strategic firm objectives.
• Performed by a steering committee composed of the top
management, internal auditor and any management consultant.
• Occurs at two levels:
• Strategic systems planning
• Project planning
STRATEGIC SYSTEMS PLANNING

• General/Firm-wide system plan

• The allocation of system resources (employees, hardware, software,
communication lines) at a macro level, usually dealing with time frame of
3 to 5 years.
• A strategic systems plan are prepared for the following reasons:
• A plan that changes constantly is better than having no plan at all.
• Early identification of future needs and recognize problems at an early stage.
• Lay-out authorization rules for SDLC activities.
• Better manage costs.
PROJECT PLANNING

• Detailed plan for a specific application/system

• The purpose of project planning is to allocate firm resources to
individual applications.
• The products/outputs of a project plan are:
• Project proposal: Basis for management in deciding whether to proceed with a
project.
• Summarize findings into a general recommendation, and
• Outline linkage of the project with firm objectives.
• Project schedule: Budget of time and costs for the SDLC activity
PHASE 2: SYSTEMS ANALYSIS
SYSTEMS ANALYSIS

• Performed by a system analyst.

• A business need or problem needs to a properly a systems
analyst before formulating a solution.
• Involves two step:
• Surveying the current system
• Analysis of user needs
• Final output of this phase is the systems analysis report.
SYSTEMS ANALYSIS

Surveying the current system Analysis step

• Understanding of the current system and determining the

elements of the current system that can preserved as part • Systems analysis is an intellectual process
of the new system.
that is commingled with fact gathering.
• The analyst gathers and analyzes facts in order to formulate
an assessment on the current system. • The analyst is simultaneously analyzing as
• Surveying the current system enables the organization to he or she gathers facts.
retain features of the current system that are worth keeping
and oblige the analyst to fully understand the current • The recognition of a problem presumes
system and identify the root cause of the problem. some understanding of the norm or desired
• On the other hand, if applied improperly, this step may hold state.
back the analyst from forming generating new ideas,
resulting in the development of improve old system instead • It is therefore difficult to identify where the
of a radically new one. survey ends and the analysis begins.
SYSTEMS ANALYSIS

Type of facts gathered

Fact gathering techniques
• Data sources
• Users
• Date storage • Observation
• Data flow
• Task participation
• Controls
• Transaction volume • Interviews/Inquiries
• Error rates
• Resource costs • Inspection of key documents
• Bottlenecks and redundant operations
SYSTEMS ANALYSIS REPORT

• The systems analysis phase concludes upon preparation of the

systems analysis report.
• This report presents to management or the steering committee the
survey findings, the problems identified with the current system,
the user’s needs, and the requirements of the new system.
• This report sets out in detail what the system must do rather than
how to do it - meaning, it does not specify the detailed design of
the proposed system.
PHASE 3: CONCEPTUAL SYSTEM DESIGN
CONCEPTUAL SYSTEM DESIGN
Conceptu Conceptu Conceptu Conceptu Conceptu
• The purpose of the conceptual design phase is to al design al designs al designs al designs al designs
produce several alternative conceptual systems that
satisfy the system requirements identified during
systems analysis. User evaluation
• Users will determine the plausible alternatives from
presented conceptual design, which will be subjected to
system evaluation and selection (Phase 4) to determine
the final system design.
Plausible Plausible Plausible
alternative alternative alternative
• Aims to reduce costs by filtering systems designs that
will be rejected by the user and hence will no longer be s s s
subjected to Phase 4 activities.
• Conceptual system design can be made using two System evaluation and selection (Phase 4)
approaches:
• Structured Design approach
• Object-Oriented approach

Final system design

CONCEPTUAL SYSTEM DESIGN
APPROACHES
Structured design approach Object oriented approach

• Conceptualizing the system design • Conceptualizing the system design

using reusable standard components
from scratch from top down.
(object) and assembled from bottom
• Starts with coming-up with an up.
over-all view the new system, and • Starts with conceiving the design for
then later disagregated into the individual part of the new system,
several parts or modules. and then later combined to get a big
picture of the entire system.
PHASE 4: SYSTEM EVALUATION AND
SELECTION
SYSTEM EVALUATION AND SELECTION
Plausible Plausible Plausible
• The procedure for selecting one system system system system
from the set of plausible conceptual designs designs designs
Feasibility study
system designs. (Organization’s capability to develop and implement the
system)
• Aims to identify the best system design
and create a structure for decision-
Feasible Feasible
making to reduce uncertainties and
designs designs
risk of making poor decisions.
• Involves two steps: Cost-benefit analysis
(Highest net benefit/Shortest break-even point)
• Perform a detailed feasibility study; and,
• Perform a cost-benefit analysis

Final system design

PROJECT FEASIBILITY STUDY
• Plausible alternatives are assessed against major constraints (restrictions/ limitations) in
order for the management to determine the success rate prior to committing any corporate
resources.

• Alternatives that are determined be to unfeasible will no longer be considered in the cost-
benefit analysis
Technical Economic Legal Schedule
• Factors considered in the project feasibility study includes: Operational
feasibility feasibility feasibility feasibility feasibility

Availability of Availability of funds Identification of Degree of Ability of the firm

technology to complete the conflicts between compatibility to implement the
necessary to project. the system design between the firm’s project within an
develop the system and the firm’s legal existing procedures acceptable
responsibilities. and personnel timeline.
skills and the
system’s
operational
requirements.
COST-BENEFIT ANALYSIS
Cost-benefits analysis enables the management to determine whether the benefits
of developing the new system outweighs the related costs.
Identify project costs Identify project benefits
One-time costs Recurring costs Tangible benefits Intangible benefits
• Hardware acquisition • Hardware • Sales growth • Customer satisfaction
• Site preparation maintenance • Cost reduction • Employee satisfaction
• Software acquisition • Software maintenance • Improved decision making
• System design • Insurance • Better communication
• Programming and • Supplies • Operational flexibility
testing • Personnel • Enhance control
• Data conversion environment
• Personnel training • Operational efficiency

Comparison of cost and

benefits Payback method
Net present value
(NPV) Break-even point (point when
PV of costs is deducted cost equals benefits) is
from PV of benefits determined

Projects with highest NPV Projects with shortest payback

is selected for period is selected for
PHASE 5: DETAILED DESIGN
DETAILED DESIGN

• The purpose of the detailed design phase is to produce a detailed description

of the proposed system that both:
– satisfies the system requirements identified during systems analysis; and,
– and is in accordance with the conceptual design
• At this phase, all system components are meticulously identified.
• A detailed design report is prepared at the end of this process, which
includes the following information:
– Design for screen input and source documents
– Design for screen outputs, report and operational documents
– Database specifications. structures and diagrams, and data dictionary
– Process logic
SYSTEM DESIGN WALKTHROUGH

• After creating the detailed design, a system design walkthrough is done by the
development team to identify potential errors prior to programming.
• This process is performed by simulating the operation of the system to uncover
errors, omissions, and ambiguities in the design
• Usually conducted by an independent quality assurance group comprised of:
• programmer
• user
• internal auditor
• analysts
PHASE 6: APPLICATION PROGRAMMING
AND TESTING
PROGRAMMING THE APPLICATION
SOFTWARE
• After preparing the detailed design, the next step is to determine the
appropriate programming language to be used.
• Regardless of the programming language used, system programming must
use the modular approach, where the entire software is divided into small
modules that performs specific defined tasks.
• The use of the modular approach provides the following benefits:
• Programming efficiency: Module are done in parallel and can be tested
independently
• Maintenance efficiency: Small modules are easier to analyze and maintain
• Control: Programming errors are contained in a module since the modules are
independent of each other.
TESTING THE APPLICATION SOFTWARE

• All program modules must be thoroughly tested before they are

implemented. • The testing process must have structured steps to follow.
Testing • Testing method may involve running a hypothetical master and
methodology transaction file. Afterwards, the output on the test run is generated
and compared with predetermined results.
• Software testing must be tested on a stand-alone devise detached
from the live server.
Offline testing • This is to prevent any undetected errors in the developed software
from affecting current business operations
• Test data should be developed during the implementation phase and
retained for reuse in the future.
Test data • Maintaining test data and its results is a significant control feature as
these can be reused on to test future systems development and
program changes.
PHASE 7: SYSTEM IMPLEMENTATION
SYSTEM IMPLEMENTATION

• In this phase, the detailed system plan is executed and implemented, and the following
activities are performed:
– Necessary equipment is purchased and installed
– Employees are oriented and trained with the use of the new software
– Database structures are created and populated with data
– New system is coded, documented and installed

• This phase is the most cost extensive part of SDLC and consume more personnel hours.
• Other necessary activity in facilitating system implementation include:
– Testing the entire system
– System documentation
– Converting the databases
– Conversion from the old system to the new system
TESTING THE ENTIRE SYSTEM

• When all modules have been coded and tested, they must be brought
together and tested as a whole.
• The procedure involves processing hypothetical data through the
system, then reconciling outputs of the system with predetermined
results.
• Finally, when those conducting the tests are satisfied with the results,
they should then complete a formal acceptance document. This is an
explicit acknowledgment by the user that the system in question meets
stated requirements.
SYSTEM DOCUMENTATION

• System documentation provides necessary information necessary

in order for the users and other stakeholders to understand how
the system works.
Designer and
• Documentation
Programmer requirements be classified into three:
Operator
User documentation
documentation
Documentation
Contains highly technical Contains information on how to Describes how to use the
information on how the system is run the system. system.
created as well as the internal
logic of the system. Since operators are involved in The nature of user
running the system, they should documentation will depend on
Necessary in debugging errors not have access on the designer the user’s degree of
and performing system and programmer documentation. sophistication with computers
maintenance. and
Technology.
DATABASE CONVERSION

• The transfer of data from the current format in the old system to the new format
required by the new system.
• Degree of conversion depends on the techlogy between systems and may be done by:
– Manually entering data from the old system to the new system
– Converting the data from a old system to a compatible format, then have it uploaded to the new
system

• With the risk involved in data conversion, the following precautions must be observed:
– Validated the data in the old system before coversion
– Reconcile data in the new system against the data stored in the old system
– Back-up copies of the original fime must be maintained in case of discrepancies in the converted
data.
TRANSITIONING TO THE NEW SYSTEM

• The process of converting from the old system to the new one is called the
cutover.
• A system cut-off usually follow one of the following approaches:
Parallel Operation
Cold Turnkey Cutover Phased Cutover
Cutover
Simultaneously switch to the new Operating the new system and Running the old and new
system and terminate the old terminating the old one by systems simultaneously for a
system entirely. module. defined period.

Easiest and less costly approach, Reduced the risk of devastating Most time consuming and costly
but risky for complex systems system failure but may pose approach, but the least risky of
Termination
Termination Old ERP
compatibility
system
issues. New ERP
system
theOld ERP
three. date
date system
Old ERP New ERP Module 1 Module 1 Reconcile outputs to
ensure accuracy
system system
Module 2 Module 1 New ERP system

Module 3 Module 3 Parallel operation

period
PHASE 8: SYSTEM MAINTENANCE
SYSTEM MAINTENANCE

• System maintenance is a formal process by which application

programs undergo changes to accommodate changes in user needs.
• Program changes may be trivial (e.g., modifying the system to
produce a new report) or extensive (e.g., major changes to an
application’s logic and the user interface.)
• When the organization deemed that it is no longer feasible to
maintain an aging system, it is scrapped, and a new systems
development life cycle begins.