2. Unit Development Folder Guide

2. Unit Development Folder Guide
	Chapter 19. UDF

Overview
The purpose of this guide is to define and require a standard format for writing Unit Development Folders (UDF. There are several purposes which are served by Unit Development Folders:
1. Provide an ordely and consistent approach in the development of each of the units of a program or project.
2. Provide an uniform and visible collection point for all unit documentation and code.
3. Aid individual discipline in the establishment and attainment of scheduled unit-level milestones.
4. Provide low-level management visibility and control over the development process.
5. Management can easily access the status of the unit
6. Much of the unit's deliverable documentation can be constructed from the UDF, when development is nearing completion.
7. Most of the information necessary for post-delivery maintenance will be assembled in one place.
The UDF is established in skeletal form prior to the start of design and becomes the primary tool for monitoring progress during software development and testing activities. All UDFs are controlled by a Project Engineer, who assigns a UDF Custodian (responsible designer) for each UDF. The UDF will be audited at periodic intervals during the development process by the responsible Project Engineer to assure that the required format of the UDF is maintained and to allow complete assessment of unit status to be made.
The UDF will be maintained in a binder with tabbed sections. Each UDF will be externally identified by a unique name, descriptive of the unit contained therein. Each UDF contains directly or provides a reference to the current documentation for each of its required items.
The UDF Custodians are responsible for assuring that their UDFs are properly prepared and maintained. The Project Engineers are charged with assuring that the UDFs are structured uniformly to provide clarity and ease of inspection. The Project Engineer is also responsible for performing audits of the UDFs to verify adherence to the standards and requirements established by this guide.

UDF Organization and Content
The organization and contents of a UDF can be adapted to reflect local conditions or individual projects requirements. The important considerations in the structuring of a UDF are:
1. The number of subdivisions is not so large as to be confusing or unmanageable.
2. Each of the sections contributes to the management and visibility of the development process.
3. The content and format of each section are afequately and unambiguosly defined.
4. The subdivisions are suficiently flexible to be applicable to a variety of software types.
5. The individual sections are chronologically ordered as nearly as possible.
The development of the UDF is geared to proceed logically and sequentially, and each section should be as complete as possible before proceeding to the next section. This is not always possible, and software development is usually an interative rather than sequencial process. These situations only serve to reinforce the need for an ordered process that can be understood and tracked even under adverse conditions.
A UDF should contain the following sections:
- Introduction
  This section contains a UDF cover sheet (figure 1) for the unit and identifies the status of the components of the UDF. The cover sheet delineates, for each of the sections, the start and completion dates, responsible originators, and reviewer sign-offs and dates.
  Following the cover sheet is a description of the unit, system overview, and how the unit fits into the system. A top level structure diagram of the units components will be provided. Also provide naming conventions used, plus any unique system capabilities required by the unit.
  Following this description, a unit schedule will be included. This schedule will show the state of all the unit's components. Each component will be listed along with start date, percent complete, and completion date for each of the following functions: Design, Code, and Test.
  Following each cover sheet, a UDF Change Log should be included to document all UDF changes subsequent to the time when the unit is put into a controlled test or maintenance environment.
- Requirements
  This section will contain as separately tabbed subsections program requirements specification documentation and the program operating environment. The program requirements specification subsection will contain a copy of any current requirements documentation applicable to the unit. The program operating environment subsection will contain the hardware and operating system configurations required for the operation of the unit.
- External Interfaces
  This section contains a detailed data description for all external interfaces either required or generated by this unit.
- Design Description
  This section will contain as subsections the design description for each unit component. Each subsection will contain the component functional description, the interfaces, the data organization (data dictionary, data flows), control flows, state diagrams, and PDL describing the process flow. Throughout the development and maintenance process, each Design subsection represents the current working version of the design, and therefore will be maintained and annotated as changes occur to the initial design. The information presented here should reflect the component's header.
  If you are doing development in an object oriented language (such as Java), add the Class Diagrams (UML) of your program as pictures. If you used other UML diagrams, add them also.
- Code
  As the unit components are modified, this section contains the listing for unit component.
  Do not forget to document the specification of every method (or procedure) of your program, a specification of a method (or procedure) consists of several clauses:
  - a precondition, indicated by the keyword requires;
  - a postcondition, indicated by the keyword effects;
  - a frame condition, indicated by the keyword modifies.
  Remember: not all clauses have to be present in all specifications; in Java, use the javadoc utility to generate documentation.
- Unit Test Plan
  This section contains a test plan for the unit and identifies the individual tests described. A description of each test case will be included. Whenever possible use a xUnit test framework. In Java, use the jUnit test framework.
- Test Results
  This section contains a compilation of all current successful test case results and analyses necessary to demonstrate that the unit has been tested as described in the test plan. Test output should be identified by test case numbers and results should be annotated to facilitate reviews of this results by other qualified individuals.
- Build Procedures
  This section will include a list of all the names of all the appropriate files (e.g., source and object) as well as their locations for system development, modification, and maintenance. This section will also include the detailed steps sufficient to supply an operator with the procedures necessary to produce the executable software.
- Problems Reports
  This section contains status logs and copies of all Design Problems Reports, Design Analysis Reports and Discrepancy Reports (as required) which document all design and code problems and changes experienced by the unit. This ensures a clear and documented traceability for all problems and changes incurred.
- Notes
  This section may be composed of any item pertaining to the unit that the UDF Custodian wishes to include.
- Audits/Reviews
  This section will contain copies of all audit/reviews reports applicable to the UDF. This includes PDL and Code walkthroughs and UDF audits. Include all notes pertaining to those audits and reviews.

UDF Maintenance
After code development and initial baselining, the design responsibility is unchanged. All changes made to the UDF will be as described in section 2, UDF Organization and Contents, of this guide.

Summary

The UDF concept has evolved into a pratical, efective and valuable tool not only for the management of software development but also for imposing a structured approach on the total software development process. The structure and content of the UDF are designed to create a set of milestones at the unit leval, each of which can be easily observed and reviewed.

PROGRAM NAME: __________________________________________________

UNIT NAME:______________________________ CUSTODIAN:______________

ROUTINES INCLUDED:______________________________________________

Table 19.1. UDF Cover Page

Section No.	Description	Due Date	Date Completed	Originator	Reviewer/Date
1	Requirements	.	.	.	.
2	External Interfaces	.	.	.	.
3	Design Description	.	.	.	.
4	Unit Code	.	.	.	.
5	Unit Test Plan	.	.	.	.
6	Test Results	.	.	.	.
7	Build Procedures	.	.	.	.
8	Problems Reports				.
9	Notes
10	Reviewers