US Army Logistics
Army project
I had a contract with the United States Army to centralize several logistical data sources into a single system. The system enabled users to view and further analyze the metrics of a military command. The system followed a standardized software lifecycle process, included advanced database routines and had a Servlet portal to create charts. My role was to develop the database and web components as well make an interface for downloading and uploading datasets.
Specifications
The entire system was mapped out before a single line of code was written. The MIL-STD-498 was used as a basis of our process. The project started with several days of discussion directly with the client to develop a requirements document. After the requirements document was solidified, a specification was created for each component of the system. Several weeks were spent getting very specific about each metric that would be automatically calculated using a set of tables in several data sources. Finally, a test plan was produced to help determine if the code was functioning as expected.
Architecture
The system had an import server, truth server, analytical interface and web server. The import server did most of the work. This server did the syncronization from the existing data sources, cleansed the data and calculated metrics using complicated joins and algorithms. The truth server stored the data in a format to make it simple for the web portal and the analytical interface to use. The analytical interface downloaded the data from the truth server and ran a series of calculations and uploaded the results. The web interface read the information on the truth server and displayed it graphically to the user over a web browser.
Error Log
An error logging mechanism for the import server was implemented. Certain tables in the schema had an update trigger installed. Whenever, a value in the table was updated, the new and original data were preserved. This allowed for a type of automated version control of each record. Certain views were created to allow the user to see all the modifications of the data and when those modifications occurred. Adding the error log feature on an update trigger made it seemless to a user altering the data. The user can just change the record to the appropriate value without worrying about making an untraceable mistake.
Metrics
After the data was properly cleansed, a series of twelve metrics were calculated. Each of these metrics could be broken down from a battalion upto a division or even the entire army. The metrics would cross reference a list of serial numbers of equipment in each battalion to data sources containing maintence records, current inventory and usage histories. Each metric typically used a stored procedure to run a series of joins and algorithms to produce each metric. The result would be a data mine of metrics at each command level.
Portal
When the metrics were completed, they would be uploaded to the truth server. The truth server would serve this information to the web portal. A java-based charting application, JFreeChart, was used to create a JPG chart on a webpage of each metric. The charts would range from a simple scatter plot to a histogram with a value marker for the median. A servlet was created that took a command level and metric name and produced a chart with a listing of statistical details about the chart.