SDLC Audit Program


Control Point Ref #: sdlcsaab
------------
A formalized user request is prepared to initiate all software
development activity
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the user request
form:
o project objectives
o users of the system
o criticality of the proposed system in terms of the survival
of the business
o critical time frames for completion
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), ensure that a user request is present which
contains all of the required information.
F1 - Info Screen Ref #: sdlcsaab
Background
----------
A user request is a proposal of services which is part of the
Initiation Phase of the Software Development Life Cycle (SDLC).
The user request is typically initiated by the users of the
system and not the software development group. However, problems
identified by the development group could be initiated
internally. For example, in order to enhance restart recovery of
a batch job, automated restart steps may be included in the
procedure JCL.
Audit Step Info
---------------
The level of detail that is required for initial deliverables
especially during the Initiation Phase of the SDLC is dependant
upon the level of communication between the requestor and the
area which receives the request and performs the feasibility
study. Thereafter, it is also dependant upon the requestor's
involvement in participating in the development of the functional
specification. Finally, everything is dependant on the
product/business knowledge of the areas performing the
feasibility study and functional specifications.
The following points represent a detailed approach to the
requirements of a user request based on the type of development
the software request is categorized under:
o project objectives
Development Category: Maintenance
In a Maintenance Request which represent a specific change in the
software, the exact requirements from a technical and business
viewpoint should be specified. (e.g., specifying how a formula
should be recalculated or how a header in a report should be
changed)
Development Category: New System Development & Enhancement
It is impossible to expect a detailed description from a
technical standpoint but the business requirements in terms of
the functionality should be outlined. The System Design will
detail the specifications, but at this point we require enough
information to start an investigation of the manpower
requirements for the project. The level of detail depends on the
amount of communication between the requestor and the person who
is performing the feasibility study. It also depends if an
internal document is being produced which further details the
requestor's requirements. For example a user request which
specifies, "A Payroll system is requested which provides the
ability to generate paychecks bi-monthly based on the individuals
biweekly salary", is not sufficient to start the feasibility
study.
o users of the system
The user community needs to be defined in terms how each of
them are using the system.
o criticality of the proposed system in terms of the survival
of the business
ocritical time frames for completion
Provide information pertaining to the objectives of the
software request, time constraints, and cost/benefit in
order to initiate a feasibility study to be performed to
determine the viability of the project.
A control requirement that was not mentioned within the audit
steps is to ensure that the user request was signed by the
appropriate person who is authorized to initiate requests. You
may want to consider performing a compliance test to ensure that
there is an authorized signature list of those individuals that
are authorized to initiate user requests and to ensure that each
user request within your sample selection had the appropriate
signature.
Control Point Ref #: sdlcsaac
-------------
A Feasibility Study is performed which includes the necessary
research in order to make a decision on whether to develop the
request
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following areas be addressed within the feasibility study:
o business objectives
- impact on existing environment
o Project start-up delay factors
- staff development (e.g., training in new programming
language in order to code the request)
- resource requirements (e.g., equipment requirements)
o Potential Start & Completion Dates
o Project development cost analysis and program
maintainability costs based on the alternatives for
developing the request
- personnel costs for all phases of the SDLC
- additional personnel costs for maintaining the product
- software & hardware acquisitions
o Evaluate alternates and provide recommendations for
achieving the requestor's goals (e.g., purchasing vendor
software, contracting with service bureau, break a project
into multiple enhancements in order to provide the
functionality that the requestor requires in a time frame
that is acceptable)
o Proposed solution
o Time frames of when the request can be completed
o Risks associated with path taken for development (i.e.,
business and technological)
o Benefit Analysis
- cost reductions (elimination of personnel, equipment)
- error reduction
- attraction of new customers
- intangible benefits (improved customer service)
o Risk analysis to determine the projects criticality to the
business
o Overall recommendation or approval for determining if the
request should be developed
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require a
feasibility study to be performed (e.g., enhancement or new
system), and ensure that a feasibility study is present and
contains the appropriate information based on the type of
development activity.
F1 - Info Screen Ref #: sdlcsaac
Background
----------
The feasibility study is the main component that is used for
determining if the software request should be approved for
development. However, the feasibility study also determines the
path that should be taken when approaching the development of a
request. When evaluating alternatives approaches it should be
noted that development costs can be provided in terms of
different estimates based upon the development approach that is
taken. Therefore, unless the development approach is taken from
the outcome of the feasibility study the manpower estimates will
be inaccurate which is the basis for making an informed decision
if a project should be approved.
Audit Step Info
---------------
From an overall standpoint, feasibility studies are not required
for all types of software development except for maybe stressing
the importance of the project in order to classify the request as
a high priority project. A feasibility study should be required
for all major enhancement and new system development. In
addition, a expected manday factor can be used for determining if
a feasibility should be performed for other categories of
development activity (e.g., maintenance).
Control Point Ref #: sdlcsaad
-------------
A Business Requirements Specifications are developed to ensure
that the project requirements to support the business is
understood
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Business
Requirements Specifications:
o Business Functions
Details the business functions that the system is required to
support which includes:
- Data requirements
Data that is required to support the application along with the
manner in which it relates to other data which is used to
determine the method that should be used to organize and access
the data.
- Execution frequency
How often the application is used. For batch jobs, are they run
nightly or on request.
- Required response time for on-line processing and
turnaround time for batch processing
- Function relations/dependencies
Pertains to the various components of the application that share
common components and dependencies.
o Operational requirements

 
- Security requirements
- Contingency requirements
- Distributed/centralized processing requirements
- Data retention requirements
- Output Distribution requirements
- Expected transaction volumes
- Critical system performance requirements
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require a
Business Requirements Specification to be developed (e.g.,
enhancement or new system), and ensure that a Business
Requirements Specification is present and contains the
appropriate information based on the type of development
activity.
F1 - Info Screen Ref #: sdlcsaad
Background
----------
The Business Requirements Specification is the method that is
used to identify the business functions that are being supported
by the software request.
The Business Requirements Specification usually developed by the
user but would require input from the application development
group to ensure that all business objective of a software request
focus in the areas that effect the approach for developing
software functionality to meet the requirements of the request.
It should be noted that certain components of a deliverable that
is stated as being required might not be required and may not be
a weakness if it is not produced at this time since the same
components of this particular deliverable are required to be
further defined in later phases and within other deliverables.
An example of this consists of Data Requirements component of the
Business Requirements deliverable of the Analysis Phase is
further defined in the Functional Specification deliverable in
the Analysis Phase which is further defined in the Detail Design
Specifications which is further defined in the Program
Specifications in the Construction Phase.

 
Further Details of the Components Within the Business Requirement
-----------------------------------------------------------------
Security Requirements
The various components of the application that require security
must be specified. The actual method for providing the security
is completed in the Functional Specifications.
Data Input Requirements
A determination must be made of the area that will be responsible
for inputting data.
Job Processing
The submission of jobs for batch processing can be arranged in
many ways which includes:
o Data Center submission of jobs either through direct
submission from a TSO logon or through a job scheduling
system
o user submission of jobs
Output Distribution Requirements
A determination has to be made on the location of where the
output will be sent and the method of distribution.
There many alternatives for the printing of output:
o Printed at data Center
o Printed automatically at remote printer
o Transmitted to remote processor
Deliverable Requirements Based on Type of Development Activity
--------------------------------------------------------------
Maintenance
Maintenance Requests are changes to existing programs to correct
a problem which most of the times does not introduce new
functional requirements which would therefore not change any of
the business requirements.
Enhancements
An understanding of the enhancement must be obtained to determine
the components of the Business Requirements that need to be
developed.
New Systems
In almost all cases, most of the components of the Business
Requirements discussed would need to be completed for new
systems.
Emergency Changes
Not applicable since most emergency changes would be considered
bug fixes which falls under the maintenance category.
Control Point Ref #: sdlcsaae
-------------
Functional Specifications are prepared which transpose business
requirements to functional requirements
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Functional
Specifications:
o Data Flow Diagrams
o Screen Definitions
o Data Definitions
o Inputs
o Report Definitions
o Service level requirements
o Capacity Requirements
o Conversion Requirements
o Control & Security Requirements
o System Interface Requirements
o Backup, Restart, and Recovery
o Contingency Requirements
o Hardware Requirements
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require a
Functional Specification to be developed (e.g., enhancement
or new system), and ensure that a Functional Specification
is present and contains the appropriate information based on
the type of development activity.
F1 - Info Screen Ref #: sdlcsaae
Background
----------
A Functional Specification entails the analysis of business
requirements to produce a preliminary design of the proposed
system. The functional specifications is from the user's
perspective where the technical deliverables required for the
programmer is not developed at this stage.
The components of a functional specification and the level of
detail depends on if the development activity is a new
system/enhancement versus maintenance type of activity. For
maintenance or an enhancement that uses existing input, screens,
and reports, the only requirements is an identification of what
is changing. A before and after description may be appropriate
if there are complex changes or if there is a lack of
documentation available for the system that is being enhanced.
It should be noted that certain components of a deliverable that
is stated as being required might not be required and may not be
a weakness if it is not produced at this time since the same
components of this particular deliverable are required to be
further defined in later phases and within other deliverables.
The following is a detailed description of all of the components
of a functional specification:
Data Flow Diagrams
-----------------
Tracing the data through all of its processing points
A graphic representation of business functions into a data
representation of the processing of the business
Screen Definitions
------------------
- definition of input fields (i.e., description and purpose)
- any range checks
Data Definition
---------------
- definition of data
- data relationships
- naming conventions
Inputs
-----
- Source of input (e.g., disk, tape, RJE)
- Type of data (e.g., transaction or master file)
- description of data

Outputs & Report Definitions
----------------------------
- description of the report
- The data that is contained on the report and how the data
value was derived
- users that utilize specific reports
Service Level Requirements
--------------------------
- Up-time requirements
- for on-line, required response time for on-line transactions
- for batch
o scheduled processing time
o critical windows
o deadlines for input
o deadlines for report distribution
Capacity Requirements
---------------------
- transaction volumes
- expected growth
System Interface Requirements
-----------------------------
- interfaces to other systems and what they consist of
Conversion Requirements
-----------------------
- method used for creating data on the new system (e.g.,
retyping, convert data through conversion programs)
- method for reconciling the data
Control & Security Requirements
-------------------------------
- input edit requirements
- audit trails for critical data from the point of origination
to the point of disposition
Backup, Restart, and Recovery Requirements
------------------------------------------
- Backup requirements for how often the data should be backed
up and the rational behind the backup.
For example:
o complete master file backup is performed nightly after the
transactions have been applied
o An incremental backup is performed where the fields in the
the master file that has changed will be backed along with
all of the transaction files
o all on-line transactions are journaled to enable the
recovery of transactions
 
- Restart requirements which specifies how a process should be
restarted
o for batch processing the various restart points of job
execution and dataset names would need to be defined once
the system is in the construction phase of development
- Recovery requirements include
o for online processing where CICS is used Forward Recovery
Software is used for reapplying transactions
Contingency Requirements
------------------------
- An analysis needs to be performed of how long the
application can be unavailable before the business is
effected. This analysis is used to drive the timeliness of
response to disaster situations
- In later stages the datasets and catalogs of the application
needs to be defined to determine the resources that need to
be restored at the offsite processing center
Hardware Requirements
---------------------
- communication requirements (e.g., terminals)
- DASD space requirements due to extra capacity
- additional printers (e.g., printer located as user location)
Control Point Ref #: sdlcsaaf
-------------
Detail Design Specifications are developed which translates
functional specifications to a logical and a physical design
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Detailed
Design Specifications:
o Database Requirements
o File Requirements
o System Flow Diagram
o Program Requirements
o System Operations Requirements
o Screen Designs
o Reports Design
 
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require a
Detailed Design Specification to be developed (e.g.,
enhancement or new system), and ensure that a Detailed
Design Specification is present and contains the appropriate
information based on the type of development activity.
F1 - Info Screen Ref #: sdlcsaaf
Background
----------
The Detailed Design Specification is a deliverable that is
developed during the Design Phase of the SDLC. It describes how
the system is designed based on identifying the functional
components.
The System Design Specifications is developed by the application
development group. However, any changes to functionality during
the design phase should require the Functional Specifications to
be updated and reviewed by the user.
Based on the changes that are required to develop the software
request, the functional and system design specification could be
consolidated into one deliverable.
Further details of the components within the Detailed Design Spec
-----------------------------------------------------------------
Database Requirements
o relationship between data elements
File Requirements
o description of each file (e.g., input, vs temporary vs
output, type of information that it contains)
o file access method
o list of the fields within a record (record layout)
o data attributes (i.e., number of positions, numeric vs
alpha)
o anticipated number of records
o use of copybooks members (i.e., shareable working storage
section within a cobol program by multiple programs)
System Flow Diagram
o sequential flow of programs that are executed and their
relationships to inputs and outputs. This information can
be represented using CASE tools, flowcharts, Dataflow
diagrams, Warnier-Orr diagrams)
Program Requirements
o programs used and their purpose (e.g., updates, edits,
extracts data)
o description of formulas and calculations
o interrelationships between other programs
System Operations Requirements
o job streams (i.e., Procs that are triggered by execution
JCL which supports the batch processing cycle)
- purpose of processing performed by the PROC
- jobnames used and which jobstreams they are associated
with
- restart/recovery procedures (i.e., acceptable condition
codes, restartable points, and if restarts are done
automatically or manually)
o back-up/recovery procedures for the application
o Operational cutoffs (I/O deadlines, job processing
deadlines)
o external dependencies (e.g., tape feeds, RJE)
o system start-up and shut down procedures
o back-up and recovery procedures
Screen Designs
o fields in each screen and the purpose of each field
o description of how screen is triggered
o logical flow of the screens by specifying screens that pull
other screens (i.e., Screen Flow Diagram)
o input checks performed
o description of error messages
Reports Design
o data contained in each fields of the report
o Each data field needs to be defined in terms of how the
result was derived (i.e., selection criteria)
Control Point Ref #: sdlcsaag
-------------
Program Specifications are developed which addresses the content
of each input and output as well as a description of the program
logic
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Program
Specifications:
o description of all input and output
o description of all programs in terms of the logic
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require
a Program Specification to be developed (e.g., enhancement
or new system), and ensure that a Program Specification is
present and contains the appropriate information based on
the type of development activity.
F1 - Info Screen Ref #: sdlcsaag
Background
----------
Program Specifications is used to describe the program logic and
processing requirements that is used to meet the requirements of
the software request.
The Program Specifications is a deliverable that is developed as
part of the Construction Phase prior to the commencement of
programming. It provides the programmer with the thought process
required to determine the steps to code the required programs.
Program Specifications are typically not required to be developed
for small projects since the coding requirements may consist of
only a few minor changes.
Control Point Ref #: sdlcsaah
-------------
Unit testing is performed to adequately identify program problems
within a standalone environment
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following test criteria be contained within the Unit Test
Plan:
o file updating, merging, sorting
o all decision logic
o all system interfaces (integration testing)
o invalid transactions and their error handling routines
o restart/recovery routines
o stress (volume) testing
o error conditions
o page counters and overflow headers
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require
a Unit Test Plan to be developed, and ensure that a Unit
Test Plan is present and contains the appropriate test
criteria based on the type of development activity.
F1 - Info Screen Ref #: sdlcsaah
Background
----------
Unit testing involves the testing of individual program modules
and not how the program functions when it is linked with the
entire application. Unit testing is performed in a non-frozen
environment whereby the program can be changed during the course
of the test.
In many environments, it may be unreasonable to expect a formal
Unit Test Plan to be developed.
Control Point Ref #: sdlcsaai
-------------
System testing sufficiently tests all aspects of the system
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following test criteria be contained within the System Test
Plan:
o verification that all functionality is performed as
specified by the functional and design specifications
o program interfaces
o other system interfaces
o restart and recovery procedures
o Transaction validation and rejection
o all transaction processing cycles (daily, monthly, year-end)
o input, processing, updates
o system performance criteria
o system output generation (tapes, reports)
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), ensure that a System Test Plan is present and
contains the appropriate test criteria based on the type of
development activity.
3) Ensure that the test set-up, scope, test origination and
expected results are documented in the system test plan.
3.1) Determine if the type of test data that should be used is
specified.
3.2) Ensure the test data provides a full representation of the
various types of test conditions that should be tested.
3.3) Ensure that test set-up steps are specified.
Ensure that steps are specified which are needed to trigger
conditions.
3.4) Ensure that the expected results are specified.
F1 - Info Screen Ref #: sdlcsaai
Background
----------
The system test is the stage of development where all program
development for the software request is completed and the
programmer performs the required testing to ensure that all
functionality works as required.
The system test environment is typically a shared environment
amongst all programmers since the an entire online environment
must be established to perform testing which consists of defining
a separate CICS region. The batch environment is also shared
because the MVS PROCLIBs in which application PROCs are stored to
execute the batch processing cycle must be defined in the JES2
PROCLIB concatenation. It would be unreasonable to expect each
programmer to have their own MVS PROCLIB defined.
The testing of the batch process consists of pulling production
MVS PROCS for application PROCS that read data and to define test
PROCS for all application PROCS that update data. In order to
pull the procedure from production when required, the JES2
PROCLIB concatenation is set-up to pull from the system test
environment prior to the production environment. The alternative
is to establish a unique naming convention for test PROCs in
order for a production PROC not to be executed.
Audit Step Info
--------------
Based on the extent of the changes that were required in the
software request, it may be unreasonable to expect system test
results to be documented but there should be a test plan in
place.
A review of the system test plan by the application development
manager should also be required which is not included in the
audit steps for this control point.
Control Point Ref #: sdlcsaaj
-------------
Acceptance testing sufficiently tested all aspects of the system
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following test criteria be contained within the Acceptance
Test Plan:
o transaction processing (output generation, file maintenance,
inquiry capability)
o system processing constraints (e.g., critical cutoffs)
o error handling routines
o stress tests (i.e., simulation of production environment and
the measuring of the system's reaction to normal and
abnormal situations [i.e., average peak work loads,
component failure])
o pre-determined results
o input/output verification
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), ensure that a Acceptance Test Plan is present and
contains the appropriate test criteria based on the type of
development activity.
F1 - Info Screen Ref #: sdlcsaaj
Background
----------
The Acceptance Test is the stage of development where the
software developed is tested in controlled environment where no
changes can be made. The test is performed by the user who is
most fluent in determining whether the software meets the
requirements of the business.
The Acceptance Test should use production data in order to
simulate the production environment. The test is performed with
the module(s) that was developed which is link edited with the
entire production environment. The objectives of the acceptance
test include the following:
o test all error handling conditions
o ensure processing accuracy
o ensure that audit trails are recording accurate all required
data

 
Audit Step Info
---------------
A formal signoff from the user which states that the software
meets the requirements of the request is not included in the
audit steps for this control point.
Control Point Ref #: sdlcsaba min/1.2
-------------
The system acceptance test environment simulates the production
environment and the integrity of the test is maintained
Audit Steps
-----------
1) Determine if a separate MVS PROCLIB is established to
execute batch jobs during the Acceptance Test.
1.1) Obtain the JES startup procedure from SYS1.PROCLIB which
specifies all of the PROC DDnames and their corresponding
PROCLIBs (Ref mgpasaae or mgpasabg).
1.2) Based on the PROCLIBs defined in the JES PROC ask the
application development manager to identify the PROCLIBs
which is used for acceptance testing.
2) Ensure that programmers do not have update access to the
data files used for the test of the batch processing during
the Acceptance Test.
2.1) Based on the PROCLIB that is used for acceptance testing
review a sample of PROCs and determine whether they are
restricted from all programmers.
3) Ensure that all programs that are executed during the
acceptance test are contained within the acceptance test
load libraries and not an individual programmers load
library.
3.1) Review the individual PROCS that are contained in the
PROCLIBs defined for acceptance testing and identify the
JOBLIB or STEPLIB DD statement which represents the load
library where load modules are contained in and ensure that
it is not a programmers personal library.
F1 - Info Screen Ref #: sdlcsaba
Background
----------
The acceptance test environment is typically a shared environment
amongst multiple applications which share the same files which
consists of defining a separate CICS region. The batch
environment is also shared because the MVS PROCLIBs in which
application PROCs are stored to execute the batch processing
cycle must be defined in the JES2 PROCLIB concatenation. It
would be unreasonable to expect each application to have their
own MVS PROCLIB defined.
The testing of the batch process consists of pulling production
MVS PROCS for application PROCS that read data and to define test
PROCS for all application PROCS that update data. In order to
pull the procedure from production when required, the JES2
PROCLIB concatenation is set-up to pull from the system test
environment prior to the production environment. The alternative
is to establish a unique naming convention for test PROCs in
order for a production PROC not to be executed.
In order to execute the PROCS used during the testing of the
acceptance test batch processing cycle, the submitter of the
execution JCL which executes application PROCS must have update
access to the data files being updated. Since the test should be
performed by the user and not the application program the user
should be the one to have update access to the files. An
alternative is to run all acceptance testing through your
scheduling system, whereby no users require update access to the
data files which would be granted to the ID assigned to the
scheduling system.
Control Point Ref #: sdlcsabb
-------------
The Data Conversion Plan provides a methodology for accurately
converting data
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Conversion
Plan:
o method used to convert the data
o set-up procedures required to convert the data
o Cutover requirements (e.g., point in time where data is
converted)
o process for verifying that the data properly converted
o process for executing the conversion programs from a
secured library
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require
a Conversion Plan to be developed (e.g., enhancement or new
system), and ensure that a conversion plan is present and
contains the appropriate information based on the type of
development activity.
F1 - Info Screen Ref #: sdlcsabb
Background
----------
Conversion Plans are only required whenever the software request
changes the manner in which data is presented. Enhancements that
require additional files in many cases would not require any data
to be converted.
The conversion of data is the prelude to the Parallel Test Plan.
In many installation, the data that processed during the parallel
test will be the production data when the system goes live and
therefore would not require the data to be reconverted.
The method for the Conversion of data can be performed using one
of the following methods:
o Data which is re-inputed into the new system,
o Data which is massaged via conversion programs to meet the
current system's input requirements,
o Data which requires no alteration.
Audit Step Info
---------------
Based on your sample selection of projects ensure that the
following areas are addressed within the installation/conversion
plan:
o If the data is re-inputed into the system,
- ensure that there is a verification function for
all data that is inputted into the system
- ensure that there is a process to ensure that input file
captured the data correctly
o If the data is massaged via conversion programs,
- ensure that the conversion programs have been tested
- ensure that all transactions converted are verified via the
following checks:
field verification
totals,
cross-footing
record size
o If the data is transferred with no alterations,
- ensure that all transactions transferred are verified via
the following checks:
field verification
totals
cross-footing
record size
bit error checks (i.e., if performed via tape transfer)
Control Point Ref #: sdlcsabc
-------------
Parallel test plan ensure that the system functions in a
simulated production environment
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the Parallel
Test Plan:
o Method used for inputting and verifying results
o Timeframes in which parallel test will be performed
o Process for documenting results
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require
a Parallel Test Plan to be developed (e.g., enhancement or
new system), and ensure that a conversion plan is present
and contains the appropriate information based on the type
of development activity.
F1 - Info Screen Ref #: sdlcsabc
Background
----------
Parallel testing is appropriate for most of the following
development efforts:
o converting a manual system to an automated system
o a rewrite of an application which does not alter the
functionality of the system
Parallel testing is usually conducted in the production
environment when the system being implemented is a standalone
process. However, if the system is not autonomous from the rest
of the system, the testing is performed in pre-production
environment and the data is later converted to the production
system during the implementation and conversion stage.
Control Point Ref #: sdlcsabd
-------------
A Cutover/Installation Plan is in place to ensure that the system
is able to function within the production environment
Audit Steps
-----------
1) Determine whether the SDLC methodology requires the
following components to be contained within the
Cutover/Installation Plan:
o Notifications to the appropriate individuals of when the
cutover is to occur
o Steps for monitoring the initial stages of production
processing
o Determination of timeframes after cutover that processing
can be switched back to the old system in the event of a
failure to the new system
o Steps for fallback to old system
o Process for shutting down the old system
2) Based on your sample selection of projects (Ref MS PAS
sspiraab), select the type of projects which would require
a Parallel Test Plan to be developed (e.g., enhancement or
new system), and ensure that a conversion plan is present
and contains the appropriate information based on the type
of development activity.
F1 - Info Screen Ref #: sdlcsabd
Background
----------
The Cutover/Fallback Plan is the stage of development where the
old system ceases and the new system is brought up is a
production environment. In order to install the system a
decision needs to made whether the data converted for the
parallel test will be the data that will be used in the
production environment or whether the data will be converted.
If the system being developed does not require data to be
converted then the Installation Plan only contains the
coordination steps with the users of the system and fallback
procedures.
Control Point Ref #: sdlcsabe
-------------
A post implementation review is performed to ensure that the
system implemented is processing at a satisfactory level
Audit Steps
-----------
1) Ensure that a process is in place to solicit user feedback
on the overall effectiveness of a software request that was
installed using the following criteria:
o Functions delivered
o Response Time
o Meeting Scheduled delivery dates
Note:
Service level agreements can be used as the basis for determining
whether the system as a whole is functioning as required but may
not be able to be broken down by the individual software request.
1.1) Determine if user surveys are performed to determine if the
system is operating at an acceptable level.
2) Ensure that emergency changes and maintenance requests are
traced to their original software requests to determine
whether if it was attributed to breakdown in the SDLC.
F1 - Info Screen Ref #: sdlcsabe
Background
----------
The post implementation review is performed to ensure that system
meets the requirements of the business. In addition, a post
implementation review can disclose problems within the SDLC or
compliance with the SDLC.
An emergency change, a maintenance request, or even an
enhancement request could disclose a breakdown in the SDLC.
An emergency change reflects a bug in the program which could be
attributed to poor testing. Even more specifically, the type of
bug can pinpoint where in the testing there was a breakdown.
For example:
o If the error occurred on a subroutine call, then the problem
could be attributed to lack of testing.
o If garbage data is not being rejected during the input
process then the breakdown potentially ocurred in two
places; the functional and design specifications which is
suppose to identify all controls and the system acceptance,
system test, and unit test where invalid transactions are
suppose to be entered to test the system edits.
A maintenance request for a software request that was implemented
could disclose program problems or missing functionality that was
not coded.
An enhancement could at times be a request for additional
functionality which was not provided due to a lack of user
involvement in the initial functional specifications where the
request's functionality is determined.
Audit Steps
-----------
It should be noted that a post implementation review is not
required for all projects. Typically large systems that were
installed would be subject to post implementation reviews.
 
 
 

The information that is obtained in this Pre-Audit Step is used
throughout the audit review.

************************************************************************
Copyright 1991 - 2000, Audit Serve, Inc. All rights reserved. All Audit
Programs are copyrighted and may not be posted electronically or
redistributed unless written permission is granted by Audit Serve, Inc.
The Audit Programs may be used for internal use within organizations.
Audit Programs may not be resold.
************************************************************************

AuditNet - The Global Resource for Auditors

Free
Audit Vision
Newsletter

Since 1991
Join 3,500 other subscribers

General Data Protection Regulation Seminar

Copyright © 2015. All Rights Reserved.