Select the search type
  • Site
  • Web
Search

Project Management

Control Point Ref #: projraab

Software projects are categorized according to the type of development

Audit Steps
-----------
1) Determine the method that is used for categorizing software projects (i.e., broad vs. specific categories).

2) Ensure that the categories used by your installation to classify software projects which reflect the type of development within your installation.

2.1) Identify the types of software development that is performed by your installation based on broad or specific categories and ensure that they are appropriate.

Examples of Broad Categories
----------------------------
New System Development
Third party vendor product install
Major Enhancements
Minor Enhancements
Maintenance
Emergency Change

Examples of Specific Categories
-------------------------------
Control card changes
Procedures
Execution JCL
Report Changes requiring no function (e.g., screen, file,
table) changes
Report Changes requiring function changes
Screen changes requiring no calculation or selection changes
Screen changes requiring selection changes
Enhancement
Program abend
Emergency Change

2.2) Ensure that software projects are being categorized by reviewing a sample selection of projects.

Perform this step if broad categories used
3) Software projects are properly assigned to their categories.

3.1) Determine if standards are available which specifies the method used for selecting the appropriate category based on the type of software project (i.e., total cost of project, number of mandays, functional requirements of software project).

3.2) Ensure that software projects are being properly categorized by reviewing a sample selection of projects. 

F1 - Info Screen Ref # projraab
Background
----------
One of the requirements for Project Management is to track the type of development that is required for each project. Categories are used as means of assigning a software project to a logical grouping which in most environments determines the phases, deliverables, and deliverable components that need to be followed or developed. Therefore, it is of great importance to ensure that a software project as correctly categorized.

Software development can be categorized using the following approaches:

o Development activity can be structured in broad categories which include: New System Development, Major Enhancements, Minor Enhancements, Minor Maintenance, Major Maintenance, Emergency Changes.

o Development activity can be organized in specific categories which is tailored towards the specific activity that is unique to your 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), Pre-Processors (e.g., used to alter data before it is applied to the master or transaction files, report header changes, extract reports.

A determination must first be made if the approach of utilizing broad categories best serves your installation.

Since categories are used as a means of determining deliverable requirements for particular group of software projects, that should be the determining factor in the number of categories used by your organization. Regardless of the category approach that is used, it must reflect all of the types development activity that is taking place.

When broad categories are used to define the type of development activity (e.g., new system development, major & minor enhancements, major & minor maintenance), a methodology must exist for defining the method used for assigning a development project a specific SDLC category, especially when the categories consist of non-descriptive names as major or minor enhancements. Common methods that are used for determining the appropriate development category consist of: Number of mandays, total cost of the project, functionality requirements of the software request.

The number of mandays should not be the only method used for determining the category that a software project is assigned since a change could take relatively short amount of time but require substantial testing that would only be required for projects that require a greater number of mandays. 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 for determining 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 makes up a specific category.

When specific categories are used for categorizing software requests, there less of a need to develop procedures for determining how to map a software request to a category.

Definitions of Broad Categories
-------------------------------
New System

This applies to any new system that is developed which is a very general category since most new system would require all SDLC deliverables to be developed. However, many installation break a new system into many little projects which would not necessarily require all of the SDLC deliverables to be developed.

Major/Minor Enhancements

This should be divided into two separate categories. Enhancements is new functionality or a new subsystem that is developed for an existing system.

Major/Minor Maintenance

This should be divided into two separate categories. Maintenance includes bug fixes to previously developed systems or additions to functionality that might have been excluded when the system was previously developed which borders in interpretation to an enhancement.

Emergency Fixes
When a program bug requires to be implemented immediately bypassing the normal requirements of the maintenance category that it would normally fall under a separate emergency fix category is required.

Software Package Acquisition
When application systems are purchased from a vendor, it should be under its own category and not part of New System since the deliverables required to support its use in production would not be of the same as a new system (e.g., no need functional and system design specification). However, this category may need to be further subdivided based on packages that can't be changed by the user versus exits which allow user coding or the distribution of source code which allow user customization.

Prototyping
The prototyping category can be used as a main category for classifying software projects in determining deliverables that are required or it can be a subcategory within each of the above categories to further breakout the deliverables that are required to be developed. For instance a major enhancement might always require full design system specifications and full unit, integration, system, and acceptance testing to be performed but
if the prototyping development approach is used each of the mentioned deliverables will not require the typical component to be developed for the deliverable or the deliverable may not be
required at all.


Control Point Ref #: projraac

The deliverables and SDLC phases that are required to be performed for a project is documented at the onset of the project

Audit Steps
-----------
1) Ensure that the deliverables that are required to be developed based on the categories that your installation uses is formalized within the SDLC.

2) Ensure that there is a commitment to deliverables immediately after approval of its development.
F1 - Info Screen Ref # projraac
Background
----------
The Software Development Life Cycle is made up various phases which require deliverables to be developed. The SDLC deliverables that are required and the actual phases that are to followed is dependant on the type of development that is occurring. For example, a report change that involves no changes to the calculation or selection criteria which derives fields in the report would allow the Analysis and Design phase to be
combined along with the deliverables that developed (i.e., functional specification, business specification,

It should be noted that the components that are required for a deliverable can vary according to the type of development activity. For example, the components of a system design specification will require comprehensive flowchart and file layouts for a new General Ledger system but no requirements would be necessary for an enhancement which changes the calculation of an individual data field.

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 your SDLC is written for the type of development that is taking place. Two of these methods include:

o The first method is a closed end approach whereby specific deliverables that are required to be developed are clearly stated in the SDLC. More detailed approaches would consist of stating the deliverables that are required based on the manner that the software project was categorized. 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.

o The second scenario is an open ended process where the SDLC Phases/Phase deliverables/deliverable components for each development category is not predefined and a determination is made at the beginning of the project of the requirements

At the onset of a software project, an analysis must be performed to determine the phases and deliverables that are required to be developed for the software project. This commitment at the onset of the project allows an accurate budget to be set and allows the disposition of the project to be tracked.

The testing to ensure that these deliverables are actually being developed is the compliance tests associated with the controls within the SDLC main section review.

Control Point Ref #: projraad

Adequate standards are in place for the prioritization of software requests which are being used

Audit Steps
-----------
1) Determine if standards are in place for prioritization of software projects.

2) Determine the adequacy of the standards for the prioritization software projects.

2.1) Is a sufficient number of priority levels used in order to easily distinguish the requests that should be handled in the future and what their specific order is.

2.2) Are the factors which effect a software request's priority clearly stated.

3) Determine if the priority for a software request is formally tracked.

4) Determine if software requests were prioritized based on the standards in place.

4.1) Review a sample of software requests and determine if the priority assigned reflects what is stated in the standards.
F1 - Info Screen Ref # projraad
Background
----------
The prioritization of a software request is especially important in an environment where there are more program requests then what can be processed by the development staff based on the target dates required for each request.

Prioritization levels need to be established which enable software requests to be easily distinguishable in order to determine the request that should be next handled. Therefore, using a High/Low prioritization level is not sufficient since a mechanism would need to be in place to distinguish which request should be addressed next. Other methods used for managing priorities, is assigning an order number to all requests in that are to developed.

Based on the priority levels that are established, a development schedule can be planned for the entire application area.

An example of factors which determine the assignment of a software requests prioritization levels include:

o overall criticality to support the business
o availability of unique resources to meet the request (e.g., purchase a 4th generation development tools)

Control Point Ref #: projraae

A project tracking system is used to track all requests from the point it is initiated to its completion

Audit Steps
-----------
1) Ensure that all projects initiated are tracked.

1.1) Determine if a project tracking system is in place.

1.2) Determine if the project tracking system tracks the disposition of all software requests (i.e., approved or unapproved) and provides the current status of the project.

1.3) Based on your sample select of projects ensure that it is contained on the project tracking system.

Note:
If formal requests are not maintained there would be no method to determine whether unapproved requests are being tracked.

1.4) Identify the current status of active projects and determine whether the project tracking system has been updated to reflect the phase being worked on.

2) Determine if there is a process in place to notify the users writing when there software request has been denied.

2.1) Review all available documentation for the selected sample of projects and determine if the users were formally notified when there software request has been denied.
F1 - Info Screen Ref # projraae

Background
----------
User software requests should be tracked either manually or automated but a determination has to be made one way or the other if the project will be developed or not developed. There will be cases, where the project is put on hold based on its priority but it should not be used as a dumping ground in which the project is never developed. 
Control Point Ref #: projraaf
-------------
A project plan is developed and updated for each software project

Audit Steps
-----------
1) Select a sample of project plans and ensure that they contain the following components:

o tasks that need to be performed

o task dependencies

o target dates for the completion of all tasks

2) Ensure that the project plan is being updated throughout the life of the project.

2.1) Based on currently active projects, select a sample of projects and determine whether their project plans were updated based on target dates not met and new tasks that need to be performed.
F1 - Info Screen Ref # projraaf
Background
----------
A project plan is used to identify the various tasks that are required to be performed to complete the requirements of the software request. The tasks that are contained in the project plan can include components of an SDLC deliverable but is primarily used for the tasks that do not fall under an SDLC deliverables. In most cases, project plans would only be required for enhancements and new system development.

Some examples of tasks that are contained in the project plan includes analyzing disk space requirements for the datasets being defined, making arrangements with courier for the delivery of reports to users.

Audit Step Info
---------------
Unless you obtain a detailed understanding of the project requirements it would be difficult to identify missing tasks from the project plans.

Control Point Ref #: projraag

Problems related to a project are tracked and forwarded to appropriate members of the development team

Audit Steps
-----------
1) Determine if problems associated with projects are documented.

1.1) Ensure that there is a centralized tracking system which records all problems associated with a project.

2) Determine if members of the development team are kept abreast of the problems recorded and the disposition of its resolution.

3) Ensure that the disposition of a problem and its solution being formally tracked.
F1 - Info Screen Ref # projraag
Background
----------
During the course of the development of a software request problems arise which may require changes to the over project. The problems that are discussed in this control do not relate to debugging a program or problems that arise during the Testing phases which are discussed in the SDLC Main Section.

Audit Step Info
---------------
Since as an auditor you are probably not well versed in the problems associated with a project you will not be able to identify in your compliance testing when problems are not being reported. Instead you will only be able to determine whether the standards of what should be reported are comprehensive enough.

A test to ensure that each of the team members are informed of a problem is not possible. However, you can conduct interview with the users and the other members of the development team to determine how the members are kept informed (e.g., periodic meeting addressing the status of software requests, manual or automated problem tracking system)


************************************************************************
Copyright 1991 - 2009, 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.
*************************************************************