Project Metadata | Keywords | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
BACKGROUND
Sometime in the late 1960s or early 1970s the US government decided to replace its IBM computers with those manufactured by Honeywell. The replaced computers included those used to run the Joint Staff's combat models. All of these combat models, written in FORTRAN, needed to be converted to run on the new machines and tested to ensure that they produced the same outputs as before. It was known beforehand that converting from the 32 bit word in the IBM machines to the 36 bit word in the Honeywell machines would lead to some differences in outputs; however, it was expected that these would be minor.
RESULTS
I was in charge of the conversion of several of the combat models. I wrote contracts for the bulk of the conversion work and supervised the conversion work.
Tthe issue of comparing the outputs of the original models against the outputs of the converted models was more complex than initially assumed. Except for the Vector-1 model, the combat models in question were legacy models with no written documentation. For each difference in output, we had to trace back through the assembly code to ascertain whether the difference was due to the word length issue or was a conversion error. I had to interpret for the contractors what the legacy combat models were intended to do so that we could check to see if the conversions were producting the correct outputs. In addition to the word length differences, we found some errors in the assembly code interpretation of the FORTRAN statements on the Honeywell machine. I discovered that the Honeywell FORTRAN compiler was relatively new and had "known" errors that had not yet been fixed! We had to develop work-arounds to create the correct outputs.
The documentation problem had been known from the outset and I wrote the contracts to include documentation (see Set Documentation Standards for Combat Models).
The depth of investigation required to ensure successful conversion of these models elevated the testing process into a Verification and Validation (V&V) process, performed by independent parties in the legacy model instances. V&V was not formally defined at the time; however, this project helped in the later definition.
If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.
Return to Hartley's Projects Page