RD Instruction 2006-X

PART 2006 - MANAGEMENT

Subpart X - Policies for Locally Developed Applications Software

§2006.1151 [General]{.underline}.

This Instruction establishes policies, responsibilities, and procedures
concerning development, use, approval, and distribution of locally
developed applications software.

§2006.1152 [Definitions]{.underline}.

[Information Resources Manager]{.underline}. Senior State official
responsible to the State Director for automation activities within a
State. Synonymous with Automated Data Processing Coordinator.

[Locally developed applications software]{.underline}. Locally developed
applications software is designed, developed, tested, and used by Rural
Development employees in County, District, or State Offices. The
applications software relies on existing word processing, spreadsheet,
and database software tools available to field offices.

[Programmed software]{.underline}. This includes executable programs
written using (in whole or in part) higher level languages or tools such
as BASIC, C, Unix Shell, and Oracle SQL.

[Software Review Team]{.underline}. A Software Review Team is
established to expedite clearance and approval of software proposed for
installation at one or more sites in more than one State. Computer
specialists are appointed to the team by the Assistant Administrator for
Information Systems Management (AAISM). The Deputy Administrators
appoint the appropriate Rural Development program or administrative
specialists. The originator and/or the Information Resources Manager
from the State submitting the documentation may be requested to
participate as a team member.

§2006.1153 [Policy]{.underline}.

The following applies to all software to be installed on Rural
Development owned or leased computers:

\(a\) All programmed software activities within Rural Development shall
follow life cycle management procedures and comply with the requirements
of Rural Development

\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_

DISTRIBUTION: WSDC Administration Management

## 1

## 

(09-01-93) PN 212

RD Instruction 2006-X

§2006.1153 (a) (Con.)

Instruction 2006-V. In a continuing effort to improve software usability
and quality, field office employees are encouraged to become
increasingly involved in contributing to the development of programmed
software by participating in life cycle management activities, such as
defining field user requirements and functional specifications,
evaluating existing programmed software and recommending enhancements,
developing user acceptance test criteria, conducting user testing, and
evaluating programmed software developed by the Agency.

\(b\) State Directors may authorize employees to work during normal duty
hours on the development of applications software.

\(c\) Automation of repetitive, resource-intensive tasks that must be
performed in field offices is intended to free employees to more
efficiently serve the public. Locally developed applications software
used to prepare reports, determine office budgets, to track
administrative or other similar activities, is encouraged. [Locally
developed applications software shall not be used to determine
eligibility for loans, grants, related servicing actions, or otherwise
impact an applicant or borrower, either directly or
indirectly.]{.underline} Recommendations for software that would affect
borrowers or applicants must be submitted on a Form RD2006-15, \"Request
for Automation\" to the appropriate Information Systems Management (ISM)
organization as prescribed in RD Instruction 2006-T.

\(d\) County, District, and State Office employees are to use vendor
software packages approved as \"Rural Development defined official
software\" in accordance with the unnumbered letter issued periodically
by the AAISM, and currently installed on local office equipment to
develop spreadsheet applications, database applications that prepare
reports from existing databases, graphics applications, and word
processing applications to accomplish applicable office operations.

\(e\) Locally developed applications software shall:

\(1\) Improve the efficiency and effectiveness of Rural Development
operations;

\(2\) Complement or support Agency program or administrative
procedures/policies rather than operate counter to, revise, or otherwise
alter them;

## 2

##  

RD Instruction 2006-X

§2006.1153(e) (Con.)

\(3\) Not duplicate or replace (in part or in total) a process performed
by Official Agency Automated Systems. (Employees are encouraged to
submit ideas and suggestions for improving Official Agency Automated
Systems through their State Directors.);

\(4\) Not alter the operating system, environmental variables, any
proprietary software (such as Microsoft Word, Prelude, Oracle), the AT&T
utility software, or official Agency software listed in the unnumbered
letter issued periodically by the AAISM;

\(5\) Be evaluated and tested by the developer for accuracy and
assurance that it has no impact on other software;

\(6\) Be supported by full documentation that consists of software
documentation, operating instructions, and installation/deinstallation
instructions; and

\(7\) Be evaluated and maintained in accordance with National and State
policies and procedures as well as Federal regulations and guidance on
software development.

§2006.1154 [Review and approval]{.underline}.

\(a\) [Applications software installed at more than one site within a
State]{.underline}. Software proposed for installation at more than one
site within the State Office jurisdiction shall be forwarded to the
State Information Resources Manager for evaluation, clearance and
approval in accordance with Agency policies and any policy established
by the State Director before it is installed at more than one site. The
State Information Resources Manager shall assign responsibility for the
support, use, and maintenance of such software.

\(b\) [Applications software installed in more than one
State.]{.underline}

Prior to being installed at one or more sites in more than one State,
applications software shall:

\(1\) Be submitted for review (along with all accompanying and
appropriate documentation) and recommendation to the State Information
Resources Managers involved in accordance with policy established by
each State Director; and

\(2\) Be submitted to the Software Review Team in the National Office
for expedited evaluation, testing, and approval.

## 3

## (Revision 1)

(09-01-93) PN 212

RD Instruction 2006-X

§2006.1155 [Roles and Responsibilities]{.underline}.

\(a\) The AAISM is responsible for:

\(1\) Implementation of RD Instruction 2006-V;

\(2\) National configuration management of all Agency computer equipment
and software;

\(3\) Evaluation, design, management, and distribution of all Agency
software at the national or multistate level;

\(4\) Assessing locally developed applications software for multistate
and nationwide applicability and assuring on-going maintenance and
support;

\(5\) Establishing and managing the Software Review Team;

\(6\) Monitoring utilization of Agency automation resources; and

\(7\) Coordinating with the appropriate program or administrative
organization in the National Office to provide support for applications
software to be installed on a national or multistate level.

\(b\) The Software Review Team is responsible for evaluating software
and related documentation submitted by a State for implementation on a
multistate or national level, making recommendations to the AAISM for
approval or disapproval of such software, and preparing a response to
the State Office. (Revised 09-04-96, PN 265.)

\(c\) State Directors have responsibility for:

\(1\) Establishing a State policy for the design, development, testing,
maintenance, clearance, and approval of locally developed applications
software including its review by the applicable State program chief;

\(2\) Ensuring that applications software developed and distributed
within their State are compatible with existing hardware and software
configurations;

\(3\) Monitoring locally developed applications software efforts to
minimize the number of redundant applications in their State;

## 

## 

## 

## 

## 4

## (Revision 1) 

§2006.1155 (c) (Con.) RD Instruction 2006-X

\(4\) Providing evaluation, approval, training, support, and maintenance
of locally developed applications software installed at more than one
site within their State jurisdiction; and

\(5\) Submitting for evaluation and review locally developed
applications software that is recommended for distribution to another
State.

\(d\) Information Resources Managers have responsibility for:

\(1\) Reviewing, evaluating, testing, and approving applications
software and related documentation in a timely manner and in accordance
with national and State policy prior to installation at more than one
site within the State;

\(2\) Training or appointing designated personnel that have adequate
experience and/or training to train other personnel on applications
software developed within their State; and

\(3\) Assembling and submitting a complete package consisting of all
appropriate documentation and applications software to the Software
Review Team when the application is proposed to be considered for use in
multiple States.

§2006.1156 [Submitting requests to the Software Review
Team]{.underline}. All requests to the Software Review Team shall be
submitted by the State Director to the AAISM and shall include, at a
minimum, a cover letter, Form RD\
2006-15, and supporting documentation. The cover letter shall request
review by the Software Review Team and list all attachments and
enclosures. In addition, the request must establish the following:

\(a\) description of the problem or need for automation;

\(b\) What the application software will do, how it will meet the need,
and who the user group will be;

\(c\) The relationship to other software and/or applications software,
if any;

\(d\) Recommendation on how and by whom it will be maintained;

\(e\) Benefits and costs associated with implementation, to the extent
they can be identified; and

\(f\) The impact of not implementing.

§§2006.1157 - 2006.1200 \[Reserved\]

## oOo

## 

##  5

(09-01-93) PN 212