Get the Basics

At a minimum, a description of each application, existing and planned, needs to be written down and maintained. Whether the application is a stand-alone database that allows queries to be made using a variety of personal computer products or code that will convert a legacy system to the latest and greatest technology, it is critical to know what is going on in development. A good description of an application will include the following information.

■ Application purpose statement

■ Input and output requirements

■ Hardware requirements

■ Software environment requirements

■ Location of current version of source code or COTS installed

■ Version/last modified descriptions

With this information, all else can be reconstructed on an as-needed basis. Application Purpose Statement The application purpose statement tells the business reason for having the software, the limitations and capabilities of the product, and the point of contact for getting questions answered about the product. This is a nontechnical statement that explains what the application is and what it does. It is written at the application component level rather than system component level. For example, a financial system will in all probability include applications for general ledger, journal processing, and accounts payable. A purpose statement is written for general ledger, journal processing, and accounts payable. They can then be bound in one document but each needs to be clearly described independently of the others because they will be maintained and upgraded individually over time.

The purpose statement needs to be text. Diagrams are nice, but are only supportive to the text because diagrams generally cannot contain all of the necessary information without becoming too complex to read.

Input and Output Requirements It is essential to know what data is expected by the application and what data is generated by the application. When an application expects data, it is going to come from one of three sources: a file input, a program process, or a user. That information needs to be stated. If the application gets the information from a file or outside database, the file name and database tables need to be identified. When the application gets the information from a process within the program logic, the logic needs to be described. When the application gets the information from a user, valid values and ranges must be documented.

When an application generates data, it is going to either send it somewhere or keep it. If the application is sending the data somewhere, the target file name and database table need to be given. If it is going to display the data, this needs to be explained. If the application only stores the data within the application to be used for queries and reports, rules governing update rotations, archiving, and purging need to be provided.

The input/output information is best presented in a table format. The data items can be listed alphabetically, making it easy to find the data path for application maintenance and troubleshooting.

Hardware Requirements This should be a very basic list of what equipment is needed in order for the application to run in any organization. The list should give the minimum requirements for processor capability and memory.

Software Environment Requirements This list needs to specify any software components needed on the system in order to run the application. This includes the operating system release and version, database release and version, and any other applications the application being described needs.

Location of Current Version of Source and Object Code or COTS Installed

This piece of documentation becomes essential in maintaining the integrity in the development environment. The best way to have this information available and accurate is to use configuration management tools.

Version/Last Modified Descriptions This piece of documentation specifically states what changes have been made to the application and when they were made. Additional information about who made the changes can be of value only if the coding organization is static. The "who did it" factor becomes meaningless in dynamic organizations.

It is best to have individual version reports for each release, rather than continuing lists of changes. This approach promotes more thorough documentation.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment