Evaluating Major Phases in Systems Development

Introduction
 There are several models of systems development process and there need to be a
common basis to evaluate the process.
 How can they ensure quality given the following complexities:
1. if the design and implementation of systems is dispersed across many users employing
high-level languages.

 One approach is to assume certain phases will always be present in the process even
though the conduct, timing and sequencing of these phases might differ markedly
across different projects
 The phases define an agenda of issues systems development stakeholders must
address
 If auditors are part-takers, they can be the stakeholders that make judgements on how
to best address these issues
 The topic discusses on the tasks that must be undertaken and controls that may be
important in the 13 Major Phases of Systems Development

4. Formulating Strategic Requirements

 Strategic requirements of a system are the overall goals and objectives the system
must accomplish eg reducing staff turnover by 30%
 These are identified based on a) deficiencies of the existing system b) or
perceived opportunities
 Strategic requirement need to be carefully elicited before designing the system as
much system failure is usually because of inadequate requirements elicitation.
 Stakeholders must recognize they have different or sometimes conflicting
strategic requirements eg managers have task-accomplishment oriented
requirement while users/employees have work-life-quality oriented requirements.
 These 2 sets of requirements might be incompatible
 If conflict is to be reduced or avoided, careful negotiation on these requirements
needs to be done.
  A given job design, often, can be supported via multiple IS designs. If strategic
objectives are clear, stakeholders are better positioned to consider and evaluate
alternative designs
 If substantial uncertainty surrounds the proposed system, strategic requirements
might not be clear on the outset. In that case, methodologies like SSM and
prototyping can help clarify strategic requirements by identify as possible set of
feasible requirements
 Both also recognizes that in some cases, requirements elicitation and system
design work might proceed concurrently
 If the proposed system have substantial behavioral impact, then procedures used
to reach an agreement on requirements must be examined and evaluated.
 If the proposed system have substantial uncertainty around, then procedures used
to help clarify strategic requirements must be examined and evaluated.

5. Organizational and Job Design

 The requirements elicitation may influence initial design and redesign of
organizational structures and jobs.
 An information system can be adapted to meet any organizational structure or job
design but adapting organizational structures and job designs to fit an information
system is problematic and might cause implementation failure
 Several factors have to be taken into consideration in designing organizational
structures and job designs for those parts of the organization would be affected by
the system.
 For example, if the tasks to be accomplished by the proposed system are
uncertain, loose organizational structures and job designs might be successful
 These promote creativity, innovation and free flow of information needed to
address the uncertainties that can undermine work performance
 In some cases, organizational structures and job designs that provide
opportunities for people to strive to their full potential can be designed by the
designers
 In an organization that has history of autocratic leadership, this can be
inappropriate eg employees might be unwilling to take responsibility amd
management might not be comfortable with this due sensitivity of jobs
  Therefore if auditors assess that the system will have an impact on the
organizational structure and job design, then they must be concerned if system
development team obtained high-quality advice from people with skilled in
organizational theory and practice
 Auditors must assess whether or not the people responsible for organizational
structure and job design are representative of stakeholder groups, how design
tasks were undertaken, processes used to resolve conflict and uncertainties, and
the level of consensus reached in relation to design finally chosen

6. Information Processing Systems Design

 From a systems effectiveness viewpoint, the auditor is concerned if the design
performs the requirements given
 from a systems efficiency perspective, the auditor is concerned with the amount
of resources required to perform its tasks
 From an asset-safeguarding and data integrity perspective,the auditor assesses the
likely reliability of controls designed into the system
 Auditors might deem it necessary to evaluate the auditability of the system eg
audit capabilities to be built into the system in the form of audit modules or
purchase of certain audit tools
 When evaluating the Information Processing System Design Phase, auditors must
evaluate 6 major activities
1. Elicitation of detailed requirements
2. Design of data flow
3. Design of database
4. Design of user interface
5. Physical design
6. Design and acquisition of the hardware/system software platform

Elicitation of detailed requirements

 auditors must understand data that the system to to capture, produce and the
transformation that must happen to turn the data to information
 2 basic approaches for elicitation of detailed requirement are through asking
stakeholders and through analysis and experimentation
 Auditors must assess whether the appropriate elicitation strategies has been used
for this process in light of the uncertainties surrounding the proposed system.

Design of information/data flow

 It is undertaken in light of any organizational or job design and detailed
information requirements that have been elicited
 Designers must determine the following:
a) The flow of data and information and transformation points (Must be charted using
data flow diagrams and object-oriented notation)
b) Frequency and timing of these flows
c) The extent to which data and information flows will be formalized
 Failure to design data flow well leads to poorly timed decisions, out of date
information, data flowing to wrong decision-makers
 Auditors must asses this to ensure data flow meets requirements

Design of the database

 Involves determining scope(context) or structure
 A major influence of scope is extent of interdependence among organizational
units
 The greater the interdependence the greater the need for global database to
present sub-optimization by sub-units
 Interdependence of sub-units give more incentive for sharing data resources eg by
using a DBMS
 As database becomes more global, cost of maintenance and use increases eg data
integrity would be critical therefore more number of controls are needed, as data
is shared increasingly
 Choosing optimal structure is complex and requires undertaking the following 4
major activities:
1. Conceptual Modelling- building the semantics of a real-world application.
application domain in represented via entities/objects, their attributes and relationship
between these, and static and dynamic constraints of these
2. Data models- conceptual models must be transformed to data models so
they can be accessed and manipulated by both high and low level languages eg ER
model can be transformed into relational model that can be queried through sql
 3. Storage structure design- decisions on how to partition a data structure so
that it can be stored on some value eg tuples in a relational model must be assigned to
records and relationships among records implemented via symbolic pointer address
4. Physical layout design-decisions must be made on how to distribute certain
data structure across a certain storage media

 Auditors must evaluate the decision on database scope. For example, too many
private databases causes redundancy of data, inconsistencies
 Public databases on the other hand can be costly to maintain and use. They
undermine system effectiveness and efficiency
 A well known database design model must be used to design the database eg
semantic modelling using ER diagrams, or object oriented model, or data
structure design using the relational model

User Interface Design

Means by which users interact with the system.
Elements to consider:
1. source documents to capture raw data
2. hard-copy output report
3. screen layouts for dedicated source-document input
4. inquiry screens for database interrogation
5. command languages for decision support systems
6. interrogation languages to interrogate the database
7. icons for pictorial representation

General Design Process

1. Identify users and put them in homogeneous groups
2. Understand the characteristics of those groups
3. Eliciting tasks the groups will perform
4. Preliminary form design - by prototyping
  UI quality usually determines the extent to which users will make errors eg
poorly designed source-documents can cause improper data entry
 Auditor should check if good UI design standards were adhered to
 Should determine if proper prototyping was done ge using CASE tools

Physical design
 the prior activities addressed conceptual design
 logical design is converted to physical design here
 this can be done by drawing three physical boundaries

Types of boundary
1. Hardware - different parts of the system might be implemented more cost
effectively on different systems eg microcomputer for data entry and database update
can be done better using a mainframe computer
2. Batch or online/realtime- some parts need periodic actions eg report
generation others might be immediate eg responding to customer query
3. Cycle/periodic- monthly reports

 Other means can be used such as default physical design resulting from
experimentaion with high level language
 Auditor’s primary concern with be efficiency and effectiveness eg system myt be
inefficient because a task has been done by improper hardware or software
resources

Design of hardware or software platform

 Some cases might require hardware of software not currently available
 eg DSS may require high quality graphics that supported by the current system
 Auditors are concerned with the extent to which granularity and generality is
maintained by the design of the hardware of software platform
 Hardware and software should be able to communicate with each other
8. Application Software Aquisition and Development
 After the design phase, application software is acquired or developed
 Generalized packages may be bought and configured to be useful
 Som cases may lead to development and various activities are done- design,
coding, testing, and documentation
 Auditors might have several concerns here
1. if software is acquired the auditors can be concerned about adequacy of
requirements provided to vendors, quality of factors used to evaluate the tendered
software in terms of factors such as functionality, accuracy, quality of
documentation, vendor stability and support, adequacy of maintenance and
support, terms and conditions of the contract
2. If developed, auditors are concerned about procedures taken in designing, coding,
testing, documentation.
 if skilled programmers are developing the system, control risks are deemed as
lower as professional are aware of quality assurance procedures they should take
to reduce errors
 Auditors can be involved in acquiring or developing software for their own use eg
they might want to embed their own audit module to continuously monitor the
system
 They might also acquire generalized software to help them audit.

Hardware/System Software Aquisition