The software development process often results in software size growth due to additional decomposed and derived requirements at the lower system tiers. A typical challenge for embedded systems is that software size often grows under the radar, unconstrained, unmanaged, and unattended.  In order to combat this situation, consider establishing a software size control program.

 

A software size control program would have the goal of controlling software growth in an acquisition program. It would be comprised of a group of stakeholders who have the ability to monitor, assess and control software size objectives and requirements. The program would have to work closely with the requirements working group and requirements configuration board to achieve the objectives of software size control.

 

The objectives of software size control are to: [1]

• Prevent uncontrolled growth in the amount of software that must be developed.
• Validate that newly defined derived requirements which are driving software growth are, in fact, necessary to meet overall system performance requirements.
• Avoid related growth in the requirement for computer processing resources.
• Prevent adverse impact on program schedule and resources.
• Provide a context for making decisions on corrective actions by understanding the impact of software change on cost, schedule, performance, and quality.
• Ensure the contractor implements software change management by establishing a process to control baselines. The process should begin by utilizing the proposal baselines from source selection, or software size estimates otherwise available at the start of a project. Ensure the contractor considers the following in managing software growth:
• Formal size estimating methods, based on actuals from the developer‘s experience.
• Integration with the system/software/hardware engineering process.
• Rigorous software size baseline control.
  • Control requirements creep.
  • Establish a verification requirement for each performance requirement at the time the performance requirement is written.
  • Use formal Engineering Change Proposals (ECPs) with adjustment to cost and schedule.
  • Defer “growth” requirements to a follow-on release.
• Process to eliminate software functionality which is not essential to meeting requirements.
  • Beware of design decisions that adversely affect planned reuse.
• Working groups or control boards responsible to manage requirements and to monitor derived requirements volatility.
• System/software architecture designed to accommodate growth.
• Prototypes or demonstrations of unprecedented, high risk areas.
• Incentives for software size containment.

 

AcqTips:  

• Decomposed requirements trace to higher level requirements documents, while derived requirements trace to design decisions or results of analyses.

 

AcqLinks and References:

• USAF Weapon Systems Software Management Guidebook
• Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software, – 16 May 2011
• Mil-STD-498 “Software Development and Documentation” – 5 Dec 1994
• MIL-STD-498 “Application and Reference Guidebook” – 3 Jan 1996
• Defense Acquisition Guidebook (DAG) – Chapter 4
• Software Development Plan Information Outline
• Joint Software Systems Safety Engineering Handbook (JSSSEH) – 27 Aug 2010

Defense Cost Resource Center (DCRC)