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 levinemh@auditserve.com 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 installations 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 users 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 systems 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 Levinemh@auditserve.com.

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.