Site ProblemsUsing the SW Acquisition Guidebook (SAG)It is often said “We don’t buy software, we buy systems”. While it is true that SMC procures systems, these systems rely heavily on software to meet almost every requirement. Software engineering is an integral part of sound systems engineering and needs to be included in the entire life cycle from conception through the decommissioning of the satellite or weapon system.The purpose of this guidebook is to assist the person responsible for “software” within a Program Office (PO) to identify their responsibility throughout the system (and software) life cycle. The intended audience is the first line software engineer but the organization and content should be helpful for everyone who interfaces with software including the Program Manger (PM), Systems Engineer (SE), Configuration Manager (CM) as well as the Chief Software Engineer (CSE).Software is an integral part of system planning and design. A large portion of this guidebook addresses the critical role “software” plays within system planning. This guidebook should be used as a roadmap to identify those activities that should be performed, predecessors necessary to those activities, and Subject Matter Experts (SMEs) to consult. It provides links to policies, instructions, laws, and official guidance that address the topic in greater depth.It is important to remember that, while this guidebook focuses on the software portion of the program, no piece of the software engineer’s job can be performed in a vacuum. It is imperative that other engineering disciplines be consulted to ensure the software is as robust as possible and execution is synchronized with the other disciplines.Currently, a repository does not exist to capture SMC-wide lessons learned. It would benefit the software engineer to review any program best practices and lessons learned early in the acquisition life cycle and at the start of each phase. Additionally the software engineer should capture the program’s lessons learned at the end of each phase to aid future staff and follow-on programs.ScopeThis guidebook is specifically targeted to the PO’s software roles and responsibilities and is not designed to address the tasks performed by a contractor. It is both a reference document and management tool for aiding engineers at all levels, but in no instance should it be considered a substitution for proper training. Nothing within the guidebook is intended to supersede any Agency policy, standard, or guidance nor is it intended to be used as a compliance document. It is written to clarify the software specific requirements and tasks specified in DoDI 5000.02.
Site Problems
Using the SW Acquisition Guidebook (SAG)
It is often said “We don’t buy software, we buy systems”. While it is true that SMC procures systems, these
systems rely heavily on software to meet almost every requirement. Software engineering is an integral part of
sound systems engineering and needs to be included in the entire life cycle from conception through the
decommissioning of the satellite or weapon system.
The purpose of this guidebook is to assist the person responsible for “software” within a Program Office (PO) to
identify their responsibility throughout the system (and software) life cycle. The intended audience is the first line
software engineer but the organization and content should be helpful for everyone who interfaces with software
including the Program Manger (PM), Systems Engineer (SE), Configuration Manager (CM) as well as the Chief
Software Engineer (CSE).
Software is an integral part of system planning and design. A large portion of this guidebook addresses the critical
role “software” plays within system planning.
This guidebook should be used as a roadmap to identify those activities that should be performed, predecessors
necessary to those activities, and Subject Matter Experts (SMEs) to consult. It provides links to policies,
instructions, laws, and official guidance that address the topic in greater depth.
It is important to remember that, while this guidebook focuses on the software portion of the program, no piece of
the software engineer’s job can be performed in a vacuum. It is imperative that other engineering disciplines be
consulted to ensure the software is as robust as possible and execution is synchronized with the other disciplines.
Currently, a repository does not exist to capture SMC-wide lessons learned. It would benefit the software engineer
to review any program best practices and lessons learned early in the acquisition life cycle and at the start of each
phase. Additionally the software engineer should capture the program’s lessons learned at the end of each phase
to aid future staff and follow-on programs.
Scope
This guidebook is specifically targeted to the PO’s software roles and responsibilities and is not designed to
address the tasks performed by a contractor. It is both a reference document and management tool for aiding
engineers at all levels, but in no instance should it be considered a substitution for proper training.
Nothing within the guidebook is intended to supersede any Agency policy, standard, or guidance nor is it intended
to be used as a compliance document. It is written to clarify the software specific requirements and tasks specified
in DoDI 5000.02.
