The Worldwide Connection for Audit, Security, Control and SOX Professionals
Analyzing the Deliverables Produced in the Software Development Life Cycle By: Mitchell H. Levine, CISA Audit Serve, Inc.
Low Cost & Highly Skilled IT Audit and SOX Consulting Resources Available Immediately Call Mitch Levine at (203) 972-3567 or email
[email protected] for additional information A Software Development Life Cycle (SDLC) represents the phases that a software project goes through in order to define and/or design the software requirements, perform the program changes, test the program cycle to ensure that changes are accurate, and install the changes into the running system.
SDLC Approaches There are various methods that can be used for documenting the deliverables that are required for a Software Project. The method that is used depends on how specific the SDLC in an organization is for the type of development that is taking place. The first method is an open-ended approach, whereby only the requirements for each SDLC deliverable are specified. This does not take into account any variation in the requirements for the deliverable based on the type of development required for a software request. In most cases an analysis is performed to determine the deliverables that are required to be developed for the software project. This commitment at the beginning of the project allows an accurate budget to be set and allows the disposition of the project to be tracked. However, many installations require no commitment to the deliverables that should be produced for a software project and leave the decision to the project managers. This approach does not provide any method for accountability of the decisions made since there is no overall process that is agreed to. The second method is a closed-end approach, whereby specific deliverables are developed based on the type of development activity are clearly stated in the SDLC. This detailed approach consists of specifying the deliverables required based upon the type of software development required for a particular project. This approach would require that the various types of software development be defined in broad categories or detailed categories. In addition, beyond the deliverables that are required, the SDLC phases to be performed and the specific components of a deliverable can be specified in order to customize the requirements of a software project. Software development activity can be defined in broad categories such as: New System Development
Major Enhancements Minor Enhancements Minor Maintenance Major Maintenance Emergency Changes When broad categories are used to define the types of development activity, a methodology must exist to define the method used to assign a development project a specific SDLC category. This becomes especially important when the categories consist of non-descriptive names such as major or minor enhancements. Common methods that are used to determine the appropriate development category consist of: number of work days, total cost of the project, and functional requirements of the software request. The number of work days should not be the only method used to determine the category that a software project is assigned since a change could take a relatively short amount of time but require substantial testing that would only be required for projects that require a greater number of work days. In addition, unless a process is in place to track the actual time spent on a project, this type categorization method can be circumvented. Using the total cost of the project alone is an ineffective way of categorizing a software request since again minor changes could require substantial deliverable requirements that would normally be associated with projects that cost more. Using the functional requirements of the request as the basis to determine the category that is selected is the most effective method for mapping the software request to its appropriate category. However, detailed procedures would be required to identify the various components of the functional change that make up a specific category when broad categories are used. When specific categories are used to categorize software requests, there is less of a need to develop procedures to determine how to map a software request to a category. Based on this approach, development activity can be organized in specific categories which is tailored toward the specific activity that is unique to an environment while maintaining some broad categories. Some examples of specific categories could include: Vendor Acquisition Software, JCL changes, direct changes to data (i.e., programs which directly change data which is used primarily after a data conversion), and Pre-Processors (e.g., used to alter data before it is applied to the master or transaction files, report header changes, and extract reports).
SDLC in the Real Business World Since the deliverables produced in the SDLC in many cases represent a regurgitation of the same information, it is not unusual for an SDLC environment to combine deliverables into one deliverable. The roles and responsibilities of performing specific deliverables at times vary from standards according to the practices of the business. For instance, the functional specification which is normally developed by the user may actually be developed by the programmer. The key to successful compliance with an installation’s SDLC requirements is dependant on the relationship between the development group and its users. In a perfect relationship, the user drives the entire process of requesting deliverables and defining the functional requirements of the enhancement. This requires the user to have a technical level of understanding of how their application functions. In addition, it requires a development group who does not demand to be in control of the functional definitions. This is usually the case when an environment has a bureaucracy which is too formal and which inhibits the coordination effort
between users and developers.
SDLC Deliverables Feasibility Study The feasibility study is the main component used to determine whether the software request should be approved for development. The feasibility study also determines the path that should be taken when approaching the development of a request. When evaluating alternative approaches it should be noted that development costs can be provided in terms of different estimates based upon the development approach taken. Therefore, unless the development approach is taken from the outcome of the feasibility study the manpower estimates will be inaccurate. This is the basis for making an informed decision about whether a project should be approved. From an overall standpoint, feasibility studies are not required for all types of software development except for possibly 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 enhancements and new system developments. In addition, an expected work day factor can be used to determine whether a feasibility should be performed for other categories of development activity (e.g., maintenance). Functional Specification A functional specification entails the analysis of business requirements to produce a preliminary design about the proposed system. The functional specification is from the user’s perspective. The technical deliverables required for the programmer is not developed at this stage of the project. The components of a functional specification and the level of detail depends on whether the development activity is a new system or enhancement versus maintenance type of activity. For maintenance or an enhancement that uses existing input, screens, and reports, the only requirement 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. Systems Design Specification The systems 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 in order to develop the software request, the functional and system design specification could be consolidated into one deliverable. Program Specification The program specification is used to describe the program logic and processing requirements that is used to meet the requirements of the software request. The program specification 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. The program specification is typically not required to be developed for small projects since the coding requirements may consist of only a few minor changes. System Test Plan 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. 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. Acceptance Test Plan The acceptance test is the stage of development where the software developed is tested in a controlled environment where no changes can be made. The test is performed by the user who is most familiar with determining whether the software meets the requirements of the business. The objectives of the acceptance test include the following: test all error handling conditions ensure processing accuracy ensure that audit trails are recording accurately all required data Conversion Plan 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: Data which is re-inputted into the new system Data which is massaged via conversion programs to meet the current system’s input requirements Data which requires no alteration
This article was written more than one year ago. Events may have changed since this article was written. For a free proposal to perform an audit of your organization or provide SOX support & testing services, contact Mitchell Levine of Audit Serve at (203) 972-3567 or via e-mail at
[email protected].
Copyright 2006, Audit Serve, Inc. All rights reserved. Reproduction, which includes links from other Web sites, is prohibited except by permission in writing.
This article appeared in a past issue of the Audit Vision E-Mail Newsletter.
