• Military Menu                       

• Introduction
• Systems
• Facilities
• Agencies
• Industry
• Operations
• Countries
• Hot Documents
• News
• Reports
• Policy
• Budget
• Congress
• Links

• WMD
• Intelligence
• Homeland Security
• Space

	Director, Operational Test & Evaluation
FY97 Annual Report

STANDARD INSTALLATION/DIVISION PERSONNEL SYSTEM VERSION 3 (SIDPERS-3)

	Army ACAT IAM Program 50 systems Total program cost (TY$) $244M Average unit cost (TY$) $5M Full-rate production (IOC) 2Q FY98 Life cycle cost (TY$) $517M Prime Contractor Statistica (through 1994) Washington Software Development Center (current)

SYSTEM DESCRIPTION & CONTRIBUTION TO JOINT VISION 2010

SIDPERS-3 is a Standard Army Management Information System. The system consists of a relational database, application software written in Ada, and a hardware suite. The hardware architecture is a host-based design with a terminal server as the hub and on which the database resides. Up to four personal computers (PCs) can connect to the terminal server to access the database and to run office automation applications while not performing SIDPERS-3 functions.

The original system configuration consists of 486 PCs as workstations and terminal servers using an XDB database running on the UNIX operating system. Because of inherent speed and throughput limitations, this configuration was modified in May 1997. The new system design will include Pentium PCs, the INFORMIX database, and the SCO UNIX operating system. In addition, the SCO UNIX operating system will include an automated security appliqué so that the system can be in compliance with the trusted computer security requirements corresponding to "C2."

SIDPERS-3 will replace the current versions of SIDPERS (Version 2 and its extensions). The new version is not an upgrade of the previous system(s). The applications software has been rewritten and the relational database is new. As such, SIDPERS-3 automates several functions which were not automated previously. The fundamental change that SIDPERS-3 will implement is the way personnel information is updated within the Army. The current SIDPERS operates in a batch processing mode. Personnel data to be updated is collected from various units and submitted at certain specified times. This process can take up to a week from data entry. The implication is that at any given instant the data in the database is out-of-date and may be unreliable. Further, it may take two weeks to correct errors. With SIDPERS-3, an electronic connection between personnel units will be established. Data can be transferred much more quickly up the chain of command.

The operational mission of SIDPERS-3 is to provide commanders and their staffs with real-time interactive access to personnel information so as to enhance decision-making in the area of personnel resource management. This mission buttresses the Joint Vision 2010 concept in several ways:

• by supporting information superiority through an increased access to personnel and strength information.
• by providing commanders up-to-date information on the strength of their forces, which could lead to an enhanced economy of force as well as a reduction in "build-up time."
• by improving our capability for rapid, world-wide deployment.

The IOTE for SIDPERS-3 was conducted from June 13 to July 8, 1994, at Fort Bragg, NC; Fort Jackson, SC; and the US Total Army Personnel Command in Alexandria, VA. The bulk of the testing took place at Fort Bragg and involved the simulated operation of several personnel work centers at different command levels. Interfaces with the Reception Battalion Automated Support System (RECBASS) and with the Total Army Personnel Data Base (TAPDB) were monitored at Fort Jackson, SC; and Alexandria, VA respectively. SIDPERS-3 was tested under different simulated conditions including peacetime, mobilization, war, and demobilization. Also, the ability of operators to convert their present SIDPERS databases to the SIDPERS-3 format was tested.

The results of the IOTE clearly indicated that SIDPERS-3 did not accomplish its operational mission:

• US Army soldiers could not successfully complete a significant number of mission essential tasks using SIDPERS-3.
• SIDPERS-3 did not communicate effectively within Army's personnel chain of command (units using SIDPERS-3), regardless of the method of communications: modem, local area network, tactical communication, or floppy disk.
• SIDPERS-3 did not communicate effectively with two of its required interfaces that were tested during the IOTE, TAPDB and RECBASS.
• SIDPERS-3 training was inadequate to prepare and maintain operator skills required for operational proficiency.

For these reasons, DOT&E concluded that the system was not operationally effective and not operationally suitable.

Since SIDPERS-3 failed to resolve positively the critical operational issues concerning mission performance, interoperability, and training during the IOT&E, the Army was directed to conduct additional operational testing, prior to a fielding decision. A follow-on OA was conducted in November 1995 at Aberdeen Proving Ground (APG), MD in conjunction with developmental testing, which was necessary to verify corrections to the software failures found during the IOTE. Although SIDPERS-3 performed better in certain areas during the OA, problems in mission performance, interoperability, and database conversion led DOT&E to conclude that the system was still not operationally effective nor operationally suitable.

Following the results from the November 1995 OA, the MAISRC approved a corrective action plan for the system that included combined DT/OT at three beta test sites: APG, Ft. Jackson, SC, and Ft. Drum, NY, respectively. At each beta site, SIDPERS-3 was to be installed and employed for live operations for a period of approximately one month. The test sites were selected and ordered based on the size of the personnel database and the number of transactions, with APG being the smallest site and Ft. Drum the largest. An OA was to be conducted at each site to determine if the system was mature enough to proceed to the next beta site.

The OA from the first beta test site, APG, indicated that the system's performance had improved in many areas. However, the system still fell short of being declared operational effective and suitable in the following areas:

• Mission Performance: many untrained workarounds, slow transaction processing, unvalidated error resolution, and multi-tasking and multi-user limitations;
• Interoperability: processing excessively burdensome with two interfaces;
• Data Conversion: inadequate plan for implementation;
• RAM: inadequate maintenance and logistics support concepts.

The OA at Ft. Jackson, which was conducted in July/August 1997, in compliance with the TEMP approved by DOT&E on July 25, 1997, indicated severe problems with data base synchronization. This problem precluded the assessment of the other operational issues outstanding after the first OA. It is difficult to determine whether the data base synchronization difficulties are extrinsic or intrinsic to the system. That is, whether the problem lies in the training and motivation of the soldiers, in the implementation of revised personnel business practices, or in the data base architecture.

SIDPERS-3 has now been tested under "live" conditions on three different occasions in the last three years at both a small site, Aberdeen Proving Ground, and a large recruitment and training center, Ft. Jackson. The results are not encouraging. Specifically, the workload on the soldiers to implement, use, and maintain the system has been identified time and time again as a major problem area for the system. It is unclear whether the business process environment engendered by SIDPERS-3 is an improvement over that of the existing SIDPERS-2 systems. Although the evidence is indirect, the results of the testing to date imply that the client server architecture with record data bases residing at each level in the hierarchical personnel command chain is too complicated to implement. If transactions do not get processed or entered at, or communicated to/from one level in the path, data base synchronization suffers severely. Needless to say, the system is not operationally effective nor suitable.