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:
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.
The user community needs to be defined in terms how each of them are using the system.
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.
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.
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.
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. ************************************************************************
Free Audit Vision Newsletter Since 1991 Join 3,500 other subscribers
Advertise with Us