Corrected copy of AFIC REGULATION 700-2

AIAI33-104

AIR INTELLIGENCE AGENCY INSTRUCTION 33-104

25 SEPTEMBER 1992

DEPARTMENT OF THE AIR FORCE HQ AIR INTELLIGENCE AGENCY

Communications

USER-DEVELOPED SMALL COMPUTER SOFTWARE

This regulation provides guidance for the management and submission of user-developed software (UDS) for Air Force Intelligence Command (AFIC) evaluation and implementation throughout the command as appropriate. It applies to all Air Force Intelligence Command activities but does not apply to AFIC-gained Air National Guard and Air Force Reserve units. Refer recommended changes to this regulation to HQ AFIC/SCO. Any references to SDQ or SCCS refers to the 6900 CG/SDQ or 6900 CG/SCCS, respectively, who are organizationally responsible for userdeveloped software management and distribution within AFIC.

General. Air Force Regulation 700-26, paragraph 3-4c(1), states that the foremost objective of a MAJCOM small computer technical center (SCCS) is to "encourage sharing of, and help users locate existing software programs by maintaining a MAJCOM catalog of user-submitted programs." In order to accomplish this goal, HQ AFIC must establish reasonable standards , receive user-developed software, and evaluate it against these standards. The SDQ will maintain a library of all accepted software and advertise its availability to other users. The standards are not intended as an unnecessary burden, but to ensure software is supportable after the author departs, and that a complete software package is provided to all authorized recipients of the software.

Corrected copy of AFIC REGULATION 700-2

HQ AFIC/SCO

MSgt Mayfield

HQ AFIC/SC

Col Norman M. Slocum

HQ AFIC/IMOE

TSgt Marsha J. Bryan

F; X:

HQ AFIC/SCO

IMOE

AUL/LSE

AFCEDO/CED, Keesler AFB MS 39534

HQ AFIA/IMP, Norton AFB CA 99098

1. Terms Defined.

1.1. AFIC-Owned Small Computers. All AFIC owned DOS-based or UNIX-based small computer systems, networks, terminals, and stand-alone personal computers worldwide.

1.2. User-Developed Software. Software written by an end-user employing government provided development tools.

1.3. Accepted Software. User-developed software which has met documentation and performance requirements during evaluation by SDQ and is offered by SCCS to other units via the 6900 CG Small Computer Software Catalog, or periodic update messages.

2. Scope. This regulation applies to user-developed software designed for use on, and affecting only, AFIC-owned small computer systems. The requirements outlined below apply to user-developed software unique to a specific site or on any software which may be beneficial to other AFIC units. Consult with unit Communications-Computer Systems Office (SC) for guidance on granting approval of development efforts for computer systems not within the scope of this regulation.

3. Responsibilities:

NOTE: Centers and 696 IG will perform those applicable unit and wing responsibilities in managing their user- developed small computer software.

3.1. The Software Developer will:

3.1.1. Coordinate development efforts, from inception, through the unit SC to avoid duplication of effort

3.1.2. Obtain approval for development of software from the unit SC.

3.1.3. Perform development effort only on qualified computer systems as determined by the unit SC.

3.1.4. Obtain acceptance criterions from the unit SC to begin the documentation process early in the development effort.

3.1.5. Not bypass operating systems, security systems, or access controls provided by higher authority.

3.1.6. After completion of software development and testing, provide the unit SC a software package which includes items described in paragraph 4.

3.1.7. Resolve questions from SCCS and SDQ and from recipients of software. Keep unit SC apprised of software queries and their resolution.

3.2. The unit SC will:

3.2.1. Refer to 6900 CG, Small Computer Software Catalog, to determine if previously developed software is available for use and applicable to site requirements. Request applicable user-developed software described in 6900 CG Small Computer Software Catalog, using procedures described within the document.

3.2.2. Advise wing SC, if applicable, of development efforts undertaken by unit personnel.

3.2.3. Assist developers in interpreting and satisfying acceptance criterions for user-developed software.

3.2.4. Ensure locally-developed software and documentation comply with acceptance criterions described in paragraph 4 before forwarding to appropriate SCs, as well as SDQ.

3.2.5. Assist recipients of user-developed software in its use before contacting developer. If the developer is no longer available, contact SCCS for additional assistance.

3.2.6. Make copies of accepted user-developed software for use within his unit.

3.2.7. Where no intervening wing is assigned, wing responsibilities will fall upon the unit SC.

3.3. The wing SC will:

3.3.1. Coordinate with the developers unit SC during all stages to ensure compliance with development standards.

3.3.2. Ensure compliance with security standards during development.

3.3.3. Obtain a working knowledge of the software being developed to determine its scope and application.

3.3.4. Authorize a test-bed location for testing of the software during any stage of evaluation, using a unit within the wing's control.

3.3.5. Approve use of software within the developer's unit, after initial evaluation, on an interim basis, for a period of not more than 90 calendar days.

3.4. SCCS will:

3.4.1. Receive user-developed software and send it to SDQ for evaluation.

3.4.2. Advertise accepted software in 6900 CG Small Computer Software Catalog.

3.4.3. Provide secondary customer support for accepted software once the developer is no longer available to provide support.

3.4.4. Disseminate copies of accepted software and documentation, when requested.

3.5. SDQ will:

3.5.1. Acknowledge receipt of package to sender within 10 working days.

3.5.2. Perform an evaluation of software. Some evaluations may have to be performed at other than the headquarters, and, therefore, may require extended evaluation periods. This evaluation will include:

Performing an administrative evaluation of the software package to ensure the documentation complies with standards in paragraph 4.
Performing a technical evaluation, ensuring that the software and hardware available are capable of performing a full operational test of the software. The evaluation will include testing the software package to ensure documentation is accurate and adequate for installation and use of software, and that the software performs as specified.
Resolving conflicts or problems, if any, discovered during the evaluation process.
Informing sender of the conclusion of the evaluation process.

3.5.3. Release periodic messages with synopsis of newly accepted software.

3.5.4. Maintain library of accepted software.

3.5.5. Provide primary customer support for accepted software once the developer is no longer available to provide support.

3.5.6. Include with the software and documentation, a read file that notifies users of minor bugs or problem that are not critical to the main functions of the program.

3.6. The User or Recipient of Software will:

3.6.1. Request all user-developed software through their unit SC.

3.6.2. Consult with unit SC to resolve questions concerning use of user-developed software.

3.6.3. Make requests for changes or enhancements to the original developer of the software. Only if the developer is no longer available, will the user be allowed access to the source code. The SCCS and SDQ will only support the accepted software version. If enhancements are considered beneficial for other users within the command, it is suggested that the updated software package (code and documentation) be resubmitted to SDQ for the evaluation process, adding a statement explaining the added features. Changed software has the same acceptance criterions as the original package. Once the changed version of the software is accepted, a new version number will be issued by SDQ and annotated in the AFIC Small Computer Software Catalog. Users of previous versions of software always have the option of not implementing a new version of software.

4. Acceptance Criterions. Software and documentation packages should be classified at the lowest level practical to permit widest dissemination. The user-developed software packages will include:

4.1. Author or point of contact, organization and telephone.

4.2. A descriptive Unclassified title with version number. (First delivery should be Version I.O.)

4.3. A brief (one paragraph) Unclassified description of the software for use in publication of software catalogs, and a classified description, if necessary, to more fully explain software capabilities.

4.4. User's guide. All documentation described below will be provided on a 5 1/4", 360K floppy diskette (or the standard magnetic medium for that system) in a widely accessible word processing format, or in ASCII form. The user's guide will include:

4.4.1. The hardware configuration required.

4.4.2. The dependent software required, to include the operating system and, if any, commercial software with version release number.

4.4.3. Installation instructions.

4.4.4. Compiling and linking instructions, if applicable.

4.4.5. Descriptions of program implementation, required hardware setup, menus, and software capabilities and functions.

4.4.6. Samples of output screens, and print products produced.

4.4.7. Any other information useful in the effective use and maintenance of the software package.

4.5. Also Provide On Diskettes. All source and executable programs and files necessary for the software to run. The programs will adhere to AFIC standards and will not, therefore, contain shareware, public domain software, or copyrighted software.

5. Security. Security controls of computer systems and magnetic media must be maintained according to ESCR 56-10 and appropriate Air Force and national guidance. Consult unit CSO for system security guidance.

C. DOUGLASS COUTO

Lt Col, USAF

Director of Information Management