Have you ever sent or received a file or software release that looked correct but in fact turned out to be the wrong stuff? This can happen when authors and developers hand off files to test or QA, or when QA hands off files to the customer. Somewhere along the line either the wrong files were sent, they became corrupt, or existing files were overwritten.
This type of problem can waste huge amounts of time or, in an extreme situation, kill people. For example, in the 2015 Seville Airbus A400M Atlas crash, calibration parameter data was accidentally wiped out on three engines as the engine software was being installed. Four people were killed and two injured when the aircraft fell out of the sky*.
Physical Configuration Audit and Checksums
A Physical Configuration Audit** (PCA) is a common solution to detect errors like these. A PCA verifies that:
- All items identified as being part of the configuration are present in the product baseline
- The correct version and revision of each part are included in the product baseline
- All items correspond to information contained in the baseline’s configuration status report (release note)
A PCA is a comprehensive checklist that is used at each hand-off point to verify that the correct items are handed off. A PCA typically consist of these checks:
- Check code, drawings and deliverables (via peer reviews, difference checker, or checksums)
- Check that the correct versions are picked up and installed (via testing or checksums)
- Check that the actual changes made are the ones that were approved
- Check naming conventions (so that files can be found by people and other software)
A checksum calculation is a common practice to include in a PCA. When the checksum command is applied to a file, it generates a unique result. If you run the command on the author’s copy of a file and then on the recipient’s copy, and the checksum result is different, then the files are different even if they look the same.
Checksum applications exist in all operating systems. Two common ones are MD5 and SHA.
Example
I have a photo called neils-photo.jpg. When I run MD5 on it in the OS command line, I get a unique string of characters.
>MD5 neils-photo.jpg
>Checksum = 3003c12509fec85569a5a8c61bb0aed3
When I crop the picture and save it, the new MD5 result is:
>MD5 neils-photo.jpg
>Checksum = 57d6683e756acf8857a2314d3fae3cce
The picture looks the same and has the same file name, but it has been slightly modified. My picture could be your contract or a critical piece of code that was “tweaked” over the weekend because of a “brilliant” new idea. It happens.
There are many parameters that can be added to the MD5 and SHA commands, and many ways to save and compare the outputs. They can be applied to directories (with appropriate MD5/SHA parameters) and zip files. See your local IT person or OS user guide for help.
Conclusion
When you hand off or receive important files (software releases, drawings, and documents) and you want to verify that the destination matches the source copy, consider running a checksum before and after. For important handoffs, develop a simple Physical Configuration Audit that looks for other potential errors.
*https://en.wikipedia.org/wiki/2015_Seville_Airbus_A400M_crash
** IEEE definition of a Physical Configuration Audit
The Process Group helps you improve your organization's capability to routinely meet deadlines and delivery quality expectations. We are certified CMMI appraisers / trainers and Certified Scrum Masters. 
