DoD CIO Approves Open Source Software.. But Beware of Low Cost Assumptions
The DoD CIO’s office clarified its position on open source software in a DoD open source  memorandum issued by David M. Wennergren, deputy CIO for the DoD on October 16, 2009.
The memo states “positive aspects of OSS [open source software]” should be considered when evaluating its DoD use including auditable code, ability to modify, less reliance on a particular vendor, and no licensing costs.
While This Is Good It Does Not Necessarily  Mean Low Costs
While the lack of licensing licensing costs are certainly a benefit and there can be some cost savings , once the open source software is modified for DoD usage it is no longer in the public domain. That means a contractor or another developer will need to take ownership. The software will need to be reverse engineered, verified for security issues, probably more thoroughly tested under a controlled environment and other significant costs. Appropriate design documentation and other documents will need to be built in many cases, of course test cases will need to be built. Bottom line: The development and maintenance cost of government modified open source software could be expensive: perhaps cheaper than new but expensive none the less.. And when something goes wrong the contractor will expect to be paid to debug / fix the modified open source. A quick run through rework guidance from Galorath shows up to:
- Up to 80% of the design of new software for modified open source
- Up To 64% of the testing of new software fr modified open source
- The percentages don’t include new functionality, just getting the open source into shape for mission critical applications
- Could be better or worse depending on the amount of modification and the critically of the application.
This means that it could be around 54% of developing new just to be able to use the software, not counting the customization itself.
PS: It is not clear to me that the assertion by the CIO will be relevant for weapons systems, etc.
The formula and assumptions follow:
| Â | Formula | 0.22*A+0.78*B+0.5*C+0.3*(1-(0.22*A+0.78*B))*(3*D+E)/4 | |||
| Â | Result Redesign Percentage | 80.00% | 80.00% | 80.00% | Â |
| Â | Inputs | Least | Likely | Most | Definitions |
| A | Architectural Design Change | 0% | 0% | 0% | Percentage of the software requiring architectural design change |
| B | Detailed Design Change | 0% | 0% | 0% | Percentage of the software requiring detailed design change |
| C | Reverse Engineering Required | 100% | 100% | 100% | Percentage of the software that is not familiar and requires understanding or reverse engineering |
| D | Redocumentation Required | 100% | 100% | 100% | Percentage of software which has to be redocumented |
| E | Revalidation Required | 100% | 100% | 100% | Percentage of the pre-existing software that requires revalidation with the new design |
| Â | Â | Â | Â | Â | Â |
| Â | Â | Â | Â | Â | Â |
| Reimplementation Breakdown | Â | Â | Â | Â | |
| Â | Â | Â | Â | Â | Â |
| Â | Formula | .37* A + .11*B +.52*C | Â | ||
| Â | Result Reimplementation Percentage | 0.00% | 0.00% | 0.00% | Â |
| Â | Inputs | Least | Likely | Most | Definitions |
| A | Recoding Required | 0% | 0% | 0% | Percentage of the software requiring actual code changes |
| B | Code Review Required | 0% | 0% | 0% | Percentage of the software needing code reviews |
| C | Unit Testing Required | 0% | 0% | 0% | Percentage of the software requiring unit testing |
| Â | Â | Â | Â | Â | Â |
| Â | Â | Â | Â | Â | Â |
| Retest Breakdown | Â | Â | Â | Â | |
| Â | Â | Â | Â | Â | Â |
| Â | Formula | .10*A + .04*B + .13*C + .25*D + .36*E + .12*F | |||
| Â | Result Retest Percentage | 64.00% | 64.00% | 64.00% | Â |
| Â | Inputs | Least | Likely | Most | Definitions |
| A | Test Plans Required | 100% | 100% | 100% | Percentage of the software requiring test plans to be rewritten |
| B | Test Procedures Required | 100% | 100% | 100% | Percentage of the software requiring test procedures to be identified and written |
| C | Test Reports Required | 100% | 100% | 100% | Percentage of the software requiing documented test reports |
| D | Test Drivers Required | 100% | 100% | 100% | Percentage of the software requiring test drivers and simulators to be rewritten |
| E | Integration Testing | 0% | 0% | 0% | Percentage of the software requiring integration testing |
| F | Formal Testing | 100% | 100% | 100% | Percentage of the software requiring formal demonstration testing |
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Related posts:
- Open Source Software Is Not Free There is a great BLOG entry from someone who went back to Microsoft after a year at Google. Some of...
- European Union Warranty and Liability Cost Issues: The End of Open Source? The European Union is considering holding software vendors liable for damages caused by software defects. This poses several interesting cost...
- SEER Supporting Open Services For Lifecycle Collaboration Community Galorath’s Lee Fischman provided this insight on collaboration. From an introduction provided at http://open-services.net/, “the Open Services for Lifecycle Collaboration...
- Software Integrate Then Test I have recently heard people referring to the integrate then test approach to software development and was concerned about its...
- Counting XML Source Lines of Code A customer recently asked how to count XML for their software sizing activity. Turned out the question was more detailed...
Comments
Leave a Reply


