We’ve kicked off a study of the cost impacts of various development standards, and this post discusses a customer request on the cost impacts of IEEE/EIA 12207.

IEEE 12207 establishes a common framework for software life cycle processes, with well-defined terminology that can be referenced by the software industry [1].  Adherence to this standard helps to eliminate misunderstandings between contractors and procurers and significantly improves chances of mission success, a major part of which is preventing cost and schedule overruns [2, 3].

IEEE 12207 contains a set of management, engineering, and data requirements for all parties involved (acquirers, suppliers, developers, operators, and maintainers) [4].  The increase in requirements would best be modeled in TruePlanning for Software as an increase in the “Operating Specification” driver, which defines the rigorousness of testing, reliability, security, and documentation.

How much should Operating Specification increase?  This will vary from organization to organization, depending on how well current practices align with IEEE 12207 practices.  The standard contains a set of software development processes that must be in place, and gives some high-level guidance for them, but contains very few specifics, leaving the implementation details up to the developer.  Chances are, if you’re a CMMI level 4 or 5 organization, you have most required processes in place and your cost impact will be minimal (an increase of approximately 0.1 to 0.3).  For CMMI level 2 or 3 organizations, there will likely be some process areas that need to be addressed to fulfill IEEE 12207 requirements, represented by an Operating Specification increase of approximately 0.1 to 0.3 from the value you would have picked without IEEE 12207 mandated.  The best method to find the perfect number would be to collect data on a sample of projects with and without IEEE 12207, and calibrate your operating specification to find an average increase.

There also may be a potential change in the Development Team Complexity driver, which captures the development team’s capability, experience, and familiarity with the product and development platform and tools.  The development platform and tools may (or may not) be changed in order to more easily adhere to the requirements.   The calculator provides easy-to-use guidance to address the team’s familiarity with development platform/tools, and any other foreseen impacts on the day-to-day activities of the development team.

The advice so far relates to the developers of the software (the contractor), which tends to increase cost.  From the government perspective, they will be more involved in the development process, guiding it toward a software product that meets their requirements, which results in less likelihood of rework or delivering something different than what was needed and fixing it via follow-on work.  Also, maintenance costs will be reduced, as there will be fewer defects and clear documentation (this impact will be automatically captured by the model due to the increased Operating Specification).  Ultimately, IEEE 12207 is intended to reduce costs over the entire lifecycle, based on the fact that the acquirer is more likely to get the product they need, on schedule and without excessive rework.  Research suggests this approach is effective [3].

The lack of specific guidance and implementation details of IEEE 12207 leads to high variability in its cost impact.  However, going forward we’ll be gathering data on this and other standards, to better understand their cost impacts and provide “industry average” values in the model that can be useful for earlier estimating.

[1] ISO/IEC 12207:2008.  https://www.iso.org/obp/ui/#iso:std:iso-iec:12207:ed-2:v1:en

[2] Hantos, Peter.  IEEE Life Cycle Standards and the CMMI®- Implementation Considerations.  2007.  http://www.dtic.mil/ndia/2007cmmi/Wednesday/7amHantos.pdf

[3] Eslinger, Suellen.  Reducing Software Acquisition Risk: Best Practices for the Early Acquisition Phases.  2006.  http://www.researchgate.net/publication/235118698_Reducing_Software_Acquisition_Risk_Best_Practices_for_the_Early_Acquisition_Phases

[4] Gray, Lewis.  A Comparison of IEEE/EIA 12207, ISO/IEC 12207, J-STD-016, and MIL-STD-498 for Acquirers and Developers.  1999.  http://www.abelia.com/docs/122_016.pdf