|
(a) This appendix identifies issues which should be addressed
by a financial officer in reviewing documentation of a financial
systems development project. The nature of the system being
developed will determine the degree of responsibility which
should be exercised by the financial services organization in
dealing with those issues.
(b) The appendix is organized by phases of a system
development project, as defined in Treasury Board EDP policy. For
each phase it indicates the documentation that a financial
officer should review for adequacy of coverage.
(a) This phase of a project includes a definition of
management's requirements and an authorization to carry out the
project.
(b) The documentation should include:
(i) a statement of the problem, authorized by the managers who
initiated the project, including:
- identification of client;
- identification of resources available for the project;
- summary of problems to be solved;
- impact of the problems if not corrected; and
- summary of benefits to be realized.
(ii) formal terms of reference for the project including:
- identification of the project methodology; and
- identification of project responsibility and management
reporting requirements and relationships, including project team
members and their responsibilities.
(iii) a description of the problem area and nature of changes
desirable, as disclosed by preliminary analysis, including:
- outline of the current system;
- identification of areas to be changed;
- scope and objectives of changes;
- probable range of costs for system development and
operation; and
- plan for initial steps of the project.
This phase of a project is to present an analysis of practical
alternatives and, based on this analysis, to recommend the most
appropriate solution. The documentation should include:
(a) the specific terms of reference for the feasibility
study;
(b) identification of alternative approaches to address the
need, and analysis leading to determination of feasible
alternatives, including:
- retention of the current process with modification;
- alternative types of technology (e.g. micrographics,
computers);
- alternative methods of obtaining the service (e.g.
"in-house" versus outside);
- broad, conceptual design of system for each alternative;
and
- rational, objective documentation of reasons for excluding
certain alternatives.
(c) the costs and benefits addressed by the study,
including:
- quantification of costs and benefits of the current system
as well as all feasible alternatives; and
- declaration of any cost or benefit factors that were not
quantified, and explanation of how they were addressed.
(d) the conclusion of the study, including:
- the basis on which the most appropriate solution was
chosen;
- the additional person-years and financial resources required
to implement the recommended solution (both development and
operation resources); and
- the specific milestones requiring management decision
through the remaining project phases.
This phase includes the definition of system objectives and
analysis of system requirements, building an overview of the
basic structure of the new system in terms of data collection and
processing requirements, information flows, and reporting
requirements. The documentation should include:
(a) the general specification of requirements, including:
- purpose and objectives of the system;
- all legislative and regulatory requirements affecting the
system;
- Treasury Board directives and guidelines relevant to the
system;
- departmental management requirements;
- needs of the users of the system;
- financial control objectives specific to the system; and
- auditability objectives for the system (to minimize cost of
system review and audit).
(b) an overview of the system design, including:
- system flow charts showing the conceptual design;
- information collection, processing and reporting
requirements;
- a design framework for internal control, addressing:
- pre-and post-processing control requirements;
- concurrent processing control requirements, where
post-processing controls are incapable of ensuring accuracy and
integrity; and
- design features to facilitate audit and evaluation of system
integrity and efficiency of operation.
(c) reports or minutes of meetings or discussions with
management and the user(s) of the system; and
(d) explanation of all unresolved matters arising from the
general design phase.
(a) During this stage of development a system design will be
produced to the point where it will reflect all financial
controls, and the details of data collection, storage and
processing, and information enquiry and reporting.
(b) The documentation should include:
(i) evidence that control features designed address fully:
- legislative and regulatory requirements;
- Treasury Board policies;
- departmental financial control requirements; and
- specific control requirements of the individual
application.
(ii) a detailed description of the system design, including
flow charts and narratives of:
- data collection, processing and storage details;
- logic of all operations and calculations; and
- pre-processing, post-processing and concurrent control
processing.
(iii) The project working papers should include:
- minutes and correspondence relating to the project; and
- reference to all unresolved matters in the detailed design
phase and the method by which these will be handled.
(a) This phase includes development activities such as
computer programming, system testing, development of procedural
and other documentation, and training. In a large part the
financial officer's role will be covered with that of the other
participants in the system development project. In most cases the
financial officer will not be involved in the programming aspect
of the implementation phase unless significant changes are being
made to the detailed design, in which case the points addressed
in detail design should be reviewed in the light of new
information. Normally, emphasis by the financial officer will be
on the documentation from which the programming will be done, on
the testing procedures for programmed routines and, later, on the
validation of test results.
(b) The documentation should be thoroughly reviewed for all
internal control aspects and significant mathematical operations
in the system.
(c) The documentation should include:
(i) those programmed accounting procedures which are
considered to be important from a control point of view and their
scheduled testing;
(ii) the testing procedures;
(iii) test data for critical calculations;
(iv) test results compared with predetermined results;
(v) procedures for complete system implementation, including
detailed documentation of training procedures, and processing
procedures such as data capture, validation and correction;
and
(vi) all outstanding matters, with proposed resolutions.
(a) In this phase the financial officer will ensure that
procedures as outlined in the detailed design phase have been
implemented and are operating as intended. In the installation of
a new system, a conversion process may be required to bridge the
gap between the new system and its predecessor, in which case the
conversion process will be a critical factor as to accuracy of
the data upon which the new system will depend.
(b) The documentation should include:
(i) procedures for data and file conversion; and
(ii) details of all problem areas encountered in the
installation phase and their resolution.
(a) This final phase of the development project is concerned
with ensuring that the management-approved objectives for the
system have been met, the financial controls are reassessed and
adjusted, and the system is successfully in operation and
maintenance mode.
(b) The documentation should include:
(i) the post-installation review procedures and their
results;
(ii) the unresolved issues and their proposed resolution;
and
(iii) revised system documentation, training materials and
control procedures, adjusted to reflect the findings in the
post-installation review.
|
