IT APPLICATIONS REVIEWER ONLY

CHAPTER 13: MANAGING THE SYSTEMS DEVELOPMENT LIFE CYCLE

❖ THE SYSTEMS DEVELOPMENT LIFE CYCLE (SDLC)

o A logical sequence of activities used to:
▪ Identify new systems needs
▪ Develop new systems to support those needs
o A model for reducing risk through planning, execution, control, and
documentation
o The SDLC model may be shown in five stages
OVERVIEW OF PHASE 1 AND 2
❖ Phase 1 – Systems Strategy
o Understand the strategic needs of the organization
o Examine the organization’s mission statement
o Analyze competitive pressures on the firm
o Examine current and anticipated market conditions
o Consider the information system’s implications pertaining to legacy
systems
o Consider concerns registered through user feedback
o Produce a strategic plan for meeting these various and complex
needs
o Produce a timetable for implementation
❖ Phase 2 – Project Initiation
o Assess systems proposals for consistency with the strategic systems
plan
o Evaluate feasibility and cost-benefit characteristics of proposals
o Consider alternative conceptual designs
o Select a design to enter the construct phase of the SDLC
o Examine whether the proposal will require in-house development, a
commercial package, or both
❖ Systems Development Participants
o Systems Professionals – analyze problems in current systems and
formulate solutions
▪ Systems analysis
 ▪ Systems designers
▪ Programmers
o End Users – primary users of the system
▪ Addressing their needs is critical to success
o Stakeholders – individuals who have an interest in the system but
are not end users
❖ Systems Steering Committee
o Usually includes the CEO, CFO, CIO, senior management from user
areas, and computer services, and internal auditors
o Typical responsibilities
▪ Provide guidance
▪ Resolve conflicts
▪ Review projects and assigning priorities
▪ Budget and allocate funds
▪ Review the status of projects
▪ Determine whether projects should be continued
PHASE 1 – SYSTEMS STRATEGY
❖ Assessing Strategic Information Needs
o Strategic systems planning involves the allocation of resources at the
macro level
▪ Usually a time frame of three to five years
o Key inputs in developing a sounds systems strategy include:
▪ Strategic business needs of the organization
▪ Situations involving legacy systems
▪ End user feedback
❖ Strategic Business Needs
o Vision and Mission
▪ System strategy requires an understanding of top
management’s vision, which has shaped the organization’s
business strategy
o Industry and Competency Analysis
▪ Industry analysis: the driving forces that affect the industry and
their organization’s performance, such as important trends,
significant risks, and potential opportunities
 ▪ Competency analysis: a complete picture of the organization’s
effectiveness as seen via four strategic filters: resource,
infrastructure, products/services, and customers
Legacy Systems – use legacy components to help develop an architecture
description
➢ Business Benefits from Architecture Description
o Efficient IT operation
▪ Lower software development, support, and maintenance costs
▪ Increased portability of applications
▪ Improved interoperability and easier systems and network
management
o Ability to address critical enterprise-wide issues
▪ Easier upgrade and exchange of system components
▪ Better return on existing investment, reduced risk for future
investment
▪ Reduced complexity in IT infrastructure
▪ Maximum return on investment in existing IT infrastructure
▪ The flexibility to make, buy, or outsource IT solutions
▪ Reduced risk overall in new investment and the costs of IT
ownership
o Improved procurement
▪ Buying decisions are simpler, because the information governing
procurement is readily available in a coherent plan
▪ The procurement process is faster, maximizing procurement
speed and flexibility without sacrificing architectural coherence
END USER FEEDBACK
▪ Identifying user needs is fundamental to everything else
▪ During phase 1, pertains to substantial perceived problems rather than
minor systems modifications
▪ Has five key phases at this point in the SDLC:
o Recognize problems
o Define problems
o Specify systems objectives
o Determine feasibility and contributions of projects
 ▪ May entail prioritizing individual projects
o Preparing a formal project proposal
END USER FEEDBACK: RECOGNIZING THE PROBLEM
▪ The need for a new, improved information system is manifested through
various symptoms
o Symptoms may seem vague and innocuous or go unrecognized
initially
▪ The point at which the problem is recognized is often a function of
management’s philosophy
o Reactive management: responds to problems only when they reach a
crisis state
o Proactive management: alert to subtle signs of problems and
aggressively looks for ways to improve
END USER FEEDBACK: DEFINING THE PROBLEM
▪ Managers and end users should
o Avoid leaping to a single definition of a problem
o Keep an open mind and gather facts before deciding
o Learn to intelligently interact with systems professionals
▪ An interactive process between managers/end users and systems
professionals is necessary to arrive at an accurate problem definition
o The next three stages of the end user feedback process involve this
interactive process
END USER FEEDBACK: SPECIFYING SYSTEM OBJECTIVES
▪ The strategic objective of the firm and the operational objectives of the
information systems must be compatible
▪ At this point, the objectives only need to be defined in general terms
END USER FEEDBACK: PRELIMINARY PROJECT FEASIBILITY – TELOS
▪ Technical feasibility: is the technology necessary available
▪ Economic feasibility: are the funds available and appropriate for the
systems
▪ Legal feasibility: does the system fall within legal boundaries?
▪ Operational feasibility: can procedural changes be made to make the
system work?
 ▪ Schedule feasibility: can the project be completed by an acceptable time
period?
END USER FEEDBACK: PREPARING A FORMAL PROJECT PROPOSAL
▪ A systems project proposal provides management with a basis for
deciding whether or not to proceed with the project
▪ It summarizes the findings of the study and makes a general
recommendation
▪ It outlines the linkage between the objectives of the proposed system and
business objectives of the firm
❖ Strategic Systems Plan
o After collecting input, the steering committee and systems
professionals evaluate the pros and cons of each proposal
o Assessing each potential project’s:
▪ Benefits
▪ Costs
▪ Strategic impact
o Development will proceed on proposals with the greatest potential
for supporting the organization’s business objectives at the lowest
cost
 ❖ Create an Action Plan: The Balanced Scorecard
o The next step is to translate strategy into action
o Many companies have found the balanced scorecard (BSC) a useful
tool for this step
o The BSC recommends viewing an organization using four
perspectives:
▪ Learning and growth
▪ Internal business process
▪ Customer
▪ Financial
THE BALANCED SCORECARD
▪ Primary objective: capture information on orthogonal dimensions that are
important to every organization

▪ Second objective: prevent the proliferation of reports and information.

Concentrate only on critical success factors to which everyone in the
organization will pay attention
 PHASE 2: PROJECT INITATION
❖ Project Initiation
o The second phase in SDLC involves
▪ Understanding user’s needs and problems
▪ Proposing multiple alternative solutions
▪ Assessing alternatives in terms of feasibility and cost-benefit
characteristics
▪ Selecting the best option and proceeding to the construct phase
▪ Examining whether the selected option will require in-house
development, a commercial package, or both
❖ Systems Analysis
o A business problem must be fully understood before a solution can
be formulated
▪ A defective analysis will lead to a defective solution
o System analysis is a two-step process
▪ Survey of current systems
▪ Analysis of users’ needs
❖ Survey of current systems
o Advantages
▪ Identifies aspects of the old system which should be retained in
the new system
▪ Aids in planning the implementation of the new system
▪ May allow conclusive determination of the cause of the
reported problems
o Disadvantages
▪ The current physical tar pit
▪ Can stifle new ideas
❖ The survey steps
o Fact-gathering techniques include observing, participating,
interviewing, and reviewing documents
o Facts must be gathered regarding:
▪ Data sourcing and data stores
▪ Users
▪ Processes
▪ Data flows
▪ Controls, especially audit trails
 ▪ Transaction volumes
▪ Error rates
▪ Resource costs
▪ Bottlenecks and redundant operations
❖ The analysis steps
o Systems analysis is an intellectual process that is commingled with
fact gathering
o A formal systems analysis report, prepared and presented to the
steering committee, contains
▪ Reasons for system analysis
▪ Scope of study
▪ Problem identified with current system
▪ Statement of user requirements
▪ Resource implications
▪ Recommendations
THE CONCEPTUALIZATION PHASE
▪ Purpose: produce alternative conceptual solutions that satisfy the
requirements identified during systems analysis
▪ How much detail?
o Enough to highlight the differences between critical features of
competing systems rather than their similarities
ALTERNATIVE CONCEPTUAL DESIGNS FOR A PURCHASING SYSTEM
SELECTION EVALUATION AND SELECTION
▪ A critical juncture in the SDLC
o A formal mechanism for selecting the one system from the set of
alternative conceptual designs that will go forward for construction
o An optimization process that seeks to identify the best system
o A structured decision-making process that reduces uncertainty and
risk
THE ROLE OF ACCOUNTANTS
▪ Accountants ensure that the following are considered during evaluation
and selection’
o Only escapable (relevant) 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
DETAILED FEASIBILITY STUDY
▪ Similar to the preliminary project feasibility analysis (TELOS), but now
more detailed and oriented to deciding on a specific system design.
Examine:
o Technical feasibility
o Economic feasibility
o Legal feasibility
o Operational feasibility
o Schedule feasibility
COST-BENEFIT ANALYSIS: IDENTIFY COST
▪ One-time and Recurring Costs
o One-time cash
▪ Hardware acquisition
▪ Site preparation
▪ Software acquisition
▪ Systems design
 ▪ Programming and testing
▪ Data conversion from old system to new system
▪ Training personnel
o Recurring cash
▪ Hardware maintenance
▪ Software maintenance contracts
▪ Insurance
▪ Supplies
▪ Personnel
COST-BENEFIT ANALYSIS: IDENTIFY BENEFITS
▪ Tangible benefits
o Increased revenues
▪ Increased sales within existing markets
▪ Expansion into other markets
o Cost reduction
▪ Labor reduction
▪ Operating cost reduction (such as supplies and overhead
▪ Reduced inventories
▪ Less expensive equipment
▪ Reduced equipment maintenance
▪ Intangible benefits
o Increased customer satisfaction
o Improved employee satisfaction
o More current information
o Improved decision making
o Faster response to competitor actions
o More efficient operations
o Better internal and external communications
o Improved planning
o Operational flexibility
o Improved control environment
COMPARING COSTS AND BENEFITS
▪ Two methods commonly used for evaluating the costs and benefits of
information systems:
 o Net present value method: deduct the present value of costs from
the present value of benefits over the life of the project
▪ The optimal choice is the project with the greatest net present
value
o Payback method: do break-even analysis of total costs & one-time
costs plus present value of recurring costs) and total benefits
(present value of benefits) after the break-even point, the system
earns future profits
▪ The optimal choice is the project with the greatest future profits
HOW SHOULD WE GET THE SYSTEM?
▪ Once the optimal system is selected, decide how to acquire it:
o Develop the system in-house: best for systems that need to meet
unique and proprietary business needs
o Purchase commercial software: best for systems that are expected
to support “best industry practices”
o A mix of the first two approaches: make in-house modifications, to
varying degrees, of a commercial system to meet the organization’s
unique needs
ANNOUNCING THE NEW SYSTEM PROJECT
▪ Can be the most delicate aspect of the SDLC
▪ End user support is critical to success
▪ All end users need to be made to understand the objectives of the new
system
▪ End users and managers who view the new system as a potential benefit
to their jobs, rather than a threat, are more likely to cooperate with the
project
WHY ARE ACCOUNTANCTS INVOLVED WITH SDLC?
▪ The creation of an information system consumes significant resources and
has financial resource implications
▪ The quality of accounting information systems and their output rests
directly on the SDLC activities that produce them
HOW ARE ACCOUNTANTS INVOLVED WITH SDLC?
▪ As end users who must provide a clear picture of their problems and
needs
▪ As members of the development team
▪ As auditors who must ensure that the system is designed with appropriate
internal controls and computer audit techniques
THE ACCOUNTANT’S ROLE IN SYSTEMS STRATEGY
▪ Auditors should routinely review the organization’s system strategy
▪ Careful systems planning is a cost-effective way to reduce the risk of
creating unneeded, unwanted, inefficient, and ineffective systems
▪ Both internal and external auditors have vested interests in this outcome
THE ACCOUNTANT’S ROLE IN CONCEPTUAL DESIGN
▪ Accountants should be responsible for the conceptual system
o And the systems professionals for the physical system
▪ If important accounting considerations are not conceptualized at this
point, they may be overlooked, exposing the organization to potential
financial loss
▪ The auditability of a system depends in part on its design characteristics
THE ACCOUNTANT’S ROLE IN SYSTEMS SELECTION
▪ Economic feasibility is a primary concern to accountants. Accountants
should ensure that:
o Use only escapable costs in calculations of cost-savings benefits
o Use reasonable interest rates in measuring present values of cash
flows
o One-time v. recurring costs are accurately reported
o Use realistic useful lives in comparing competing projects
o Intangible benefits are assigned reasonable financial values
CHAPTER 14: CONSTRUCT, DELIVER, AND MAINTAIN SYSTEMS PROJECTS
OVERVIEW OF PHASES 3,4,5
❖ Phase 3: In-house Development
o Appropriate when organizations have unique information needs
o Steps include:
 ▪ Analyzing user needs
▪ Designing processes and databases
▪ Creating user views
▪ Programming the applications
▪ Testing and implementing the completed system
❖ Phase 4: Commercial Packages
o When acceptable, most organizations will seek a pre-coded
commercial software package
▪ Advantages
• Lower initial cost
• Shorter implementation time
• Better controls
• Rigorous testing by the vendor
▪ Risks
• Must adequately meet end user’s needs
• Computable with existing systems
❖ Phase 5: Maintenance and Support
o Acquiring and implementing the latest software versions of
commercial packages
o Making in-house modifications to existing systems to accommodate
changing user needs
o May be relatively trivial, such as modifying an application to produce
a new report, or more extensive, such as programming new
functionality into a system

❖ PHASE 3: SYSTEMS STRATEGY

Why Up to 25% of All Systems Projects Fail
▪ Poorly specified systems requirements
▪ communication problems
▪ time pressures
▪ Ineffective development techniques
 ▪ paper, pencils, templates, erasers instead of software tools, such as
CASE
▪ Lack of user involvement in systems development
Prototyping
▪ A technique for providing a preliminary working version of the system
▪ Built quickly and relatively inexpensively with the intention it will be
modified
▪ End users work with the prototype and make suggestions for changes.
▪ A better understanding of the true requirements of the system is
achieved.
Prototyping Techniques

Computer-Aided Software Engineering (CASE)

▪ CASE technology involves the use of computer systems to build computer
systems.
▪ CASE tools are commercial software products consisting of highly
integrated applications that support a wide range of SDLC activities.
Uses of CASE Tools
▪ Define user requirements
▪ Create physical databases from conceptual user views
▪ Produce system design specifications
▪ Automatically generate program code
 ▪ Facilitate the maintenance of programs created by both CASE and non-
CASE techniques
CASE Spectrum of Support Tools for the SDLC

PERT Chart for In-House Development Project

- PERT charts show the relationship among key activities that constitute the
construct and delivery process.
Gantt Chart

Structured Design Approach

▪ A disciplined way of designing systems from the top down
▪ Starts with the “big picture” of the proposed system and gradually
decomposes it into greater detail so that it may be fully understood
▪ Utilizes data flow diagrams (DFDs) and structure diagrams
Object-Oriented Design Approach
▪ It builds information systems from reusable standard components or
objects.
▪ Once created, standard modules can be used in other systems with similar
needs.
▪ A library of modules can be created for future use.
Elements of the Object-Oriented Approach
▪ Objects: equivalent to nouns
▪ vendors, customers, inventory, etc.
 ▪ Attributes: equivalent to adjectives
▪ part number, quantity on hand, etc.
▪ Operations: equivalent to verbs
▪ review quantity on hand, reorder item
Characteristics of an Inventory Object

Classes and Instances

▪ An object class is a logical grouping of individual objects that share the
same attributes and operations.
▪ An object instance is a single occurrence of an object within a class.
Inheritance
▪ Inheritance means that each object instance inherits the attributes and
operations of the class to which it belongs.
▪ Object classes may also inherit from other object classes.
Systems Design
▪ Follows a logical sequence of events:
▪ model the business process and design conceptual views
▪ design normalized database tables
▪ design physical user views (output and input views)
▪ develop process modules
▪ specify system controls
▪ perform system walkthroughs
Data Modeling
▪ Formalizes the data requirements of the business process as a conceptual
model
▪ Entity-relationship diagram (ERD)
▪ the primary tool for data modeling
▪ used to depict the entities or data objects in the system
▪ Each entity in an ERD is a candidate for a conceptual user view that must
be supported by the database.
Normalization
▪ User views in the data model must be supported by normalized database
tables.
▪ Normalization of database tables:
▪ A process of organizing tables so that entities are represented
unambiguously
▪ Eliminates data redundancies and associated anomalies
 ▪ Depends on the extent to which the data requirements of all users
have been properly specified in the data model
▪ REA modeling facilitates normalization by identifying entities at their
most fundamental levels
▪ The resulting databases will support multiple user views
Physical User Views:
Output Views
▪ Output is the information produced by the system to support user tasks
and decisions.
▪ Output attributes:
-relevance
-summarization
-exception orientation
Output Reporting Techniques
▪ Different users prefer different styles of output…
▪ tables, matrices, charts, and graphs
▪ …and modes of output.
▪ hard copy vs. display screen.
▪ Systems designers must identify these styles and provide output in the
desired style.
Physical User Views:
Input Views
▪ Input views are used to capture the relevant facts in business processes
and transactions (e.g., via REA model):
▪ Resources
▪ Events
▪ Agents
▪ Input may be either hard copy input documents or electronic input.
Designing Hard Copy Input
▪ Items to Consider:
▪ How will the document be handled?
▪ How long will the form be stored and in what type of environment?
▪ How many copies are required?
▪ What size form is necessary?
• Non-standard form can cause printing and storage problems.
Designing Electronic Input
Input may be from either hardcopy or electronic

Data Entry Devices

▪ Point-of-sale terminals
▪ Touch screens
▪ Mouse
▪ Magnetic ink character recognition devices
▪ Optical character recognition devices
▪ Voice and touch-tone recognition devices
Designing Process Modules
▪ Begins with the DFDs produced in the general design phase
▪ First, decompose the existing DFDs to a degree of detail that will serve as
the basis for creating structure diagrams
▪ Structure diagrams provide the blueprints for writing the actual program
modules
Data Flow Diagrams (DFDs)
▪ Used to represent multiple levels of detail.
▪ Can represent system physically or logically
▪ Context-level DFDs represent an overview of the business activities and
the primary transactions processed by the system.
▪ Do not include detailed definitions of data files and specific
procedures.
▪ Decompose high-level DFDs into more detailed lower-level DFDs.
DFD for Purchases and Cash Disbursements System
Lower Level DFD for AP Process I.4

The Modular Approach

▪ Each module performs a single task.
▪ Correctly designed modules possess two attributes:
▪ loosely coupled - low amounts of exchange of data between
modules
▪ strongly cohesive - small number of tasks performed in each module
Designing System Controls
▪ The last step in the detailed design phase
▪ Need to consider:
▪ computer processing controls
▪ data base controls
▪ manual controls over input to and output from the system
▪ operational environment controls
▪ Allows the design team to review, modify, and evaluate controls with a
system-wide perspective that did not exist when each module was being
designed independently
Systems Walkthrough
▪ Usually performed by the development team
▪ Ensure that design is free from conceptual errors that could become
programmed into the final system
▪ Some firms use a quality assurance (QA) group to perform this task.
▪ An independent group of programmers, analysts, users, and internal
auditors
Program Application Software
▪ If the organization intends to develop software in-house, then a
programming language must be selected:
▪ procedural languages or 3GLs
COBOL
▪ event-driven languages
Visual Basic
▪ object-oriented languages
Java
The Modular Approach to Programming
▪ Promotes programming efficiency
▪ modules can be both programmed and tested independently
▪ Promotes maintenance efficiency
▪ small modules are easier to analyze and change
▪ Promotes greater control
▪ modules are less likely to contain material errors of fraudulent logic
Deliver the System:
Testing
▪ Programs must be thoroughly tested before being implemented.
▪ All logic procedures should be tested.
 ▪ Test individual modules with test data containing both “good” and “bad”
data.
▪ After testing individual modules, the entire system should be tested as a
whole.
Deliver the System:
Documenting
▪ Describes how the system works
▪ Documentation should be provided for:
▪ designers and programmers - comment lines in programs, system
flowcharts, and program flowcharts
▪ operator documentation - run manuals
▪ user documentation - instructions on how to use the system,
tutorials, and help features
▪ accountants and auditors - all of the above as well as document
flowcharts
Deliver the System:
Converting the Databases
▪ The transfer of data from its current form to the format or medium
required by the new system
▪ Control risks with the following procedures:
▪ validation – inspect old database before conversion
▪ reconciliation – reconcile the new converted database against the
original
▪ backup - keep copies of the original files against discrepancies in the
converted data

Deliver the System:

Converting the Databases
Three data conversion cutover approaches:
 ▪ Cold turkey - switch to the new system all at once and simultaneously
terminate the old system.
▪ riskiest approach
▪ Phased - modules are implemented in a piecemeal fashion.
▪ reduces risk of a devastating failure
▪ Parallel operation - the old system and new system are run
simultaneously for a while.
▪ safest, yet costliest, approach
Deliver the System:
Post-Implementation Review
▪ Objective: measure the success of the new system.
▪ do after initial problems have been addressed
▪ Assess:
▪ system design adequacy
▪ accuracy of time, cost, and benefit estimates
▪ Provides feedback to improve future systems development projects,
including changes to the current system
Deliver the System:
The Role of Accountants
▪ Most system failures are due to poor design and improper
implementation.
▪ Accountants should provide their expertise to help avoid inadequate
systems by:
▪ providing technical expertise for financial reporting requirements
▪ specifying documentation standards for auditing purposes
▪ verifying control adequacy in accordance with SAS 78
 PHASE 4: COMMERICAL PACKAGES
The Purchase of Commercial Systems Packages
▪ Four factors have stimulated the growth of commercial software:
▪ relatively low cost
▪ prevalence of industry-specific vendors
▪ growing demand by small businesses
▪ trend toward downsizing and distributed data processing
Trends in Commercial Packages
▪ Turnkey systems - completely finished and tested systems ready for
implementation
▪ Backbone systems - provide a basic system structure on which to build.
▪ Vendor-supported systems - customized and maintained by a vendor for
a customer
▪ ERP systems - difficult to classify since they have characteristic of all of
the above.
Pros and Cons of Commercial Packages
▪ Advantages:
▪ decreased implementation time
▪ decreased cost
▪ reduced probability of program errors
▪ Disadvantages:
▪ dependent on the vendor for maintenance
▪ less flexibility in system
▪ greater difficulty in modifying the system as needs change over time
Four Steps in Choosing a Commercial Package
1. Analyze needs and develop detailed specifications of the system
requirements.
 2. Send out the request for proposals to all prospective vendors to serve as
a comparative basis for initial screening.
3. Gather the facts about each vendor’s system using multiple sources and
techniques.
4. Analyze the findings and make a final selection.
PHASE 5: MAINTENANCE AND SUPPORT
Maintenance and Support
▪ Approximately 80% of the life and costs of SDLC
▪ Can be outsourced or done in-house resources
▪ End user support is a critical aspect of maintenance that can be facilitated
by:
▪ knowledge management - method for gathering, organizing,
refining, and disseminating user input
▪ group memory - method for collecting user input for maintenance
and support
The Iceberg Effect