Process for Conducting a Make/buy Analysis
Process for Conducting a
Make/Buy Analysis
Number: 580-SP-075-01
Approved By: (signature)
Effective Date: July 24, 2009
Name: John T. Donohue
Expiration Date: July 24, 2014
Title: Chief, SED
Responsible Office: 580/Software Engineering Division (SED)
Asset Type: Sub-process
Title: Process for Conducting a Make/Buy Analysis
PAL Number: 2.1.1.1
Purpose
This document describes the tasks to be followed when evaluating whether to make or buy a software system or component. It also contains specific guidance for the evaluation and selection of off-the-shelf (OTS) software, including both commercial off-the-shelf (COTS) and government off-the-shelf (GOTS) products.
Scope
This process is applicable to all GSFC projects for which it is necessary to decide whether software should be developed (or maintained) in-house, acquired as custom software, or purchased off-the-shelf. This process applies to entire software systems as well as software system components.
This process is an application of the general Decision Analysis and Resolution (DAR) Subprocess to the specific case of a make-or-buy analysis.
Context Diagram
Roles and Responsibilities
Responsible Software Manager (SW Mgr)
A manager or leader with primary responsibility for management oversight of either a:
Mission Project Formulation Team
GSFC Directorate, Division or Branch
In-house software development or maintenance project, or
Software acquisition project.
The SW Mgr has primary responsibility for ensuring that the make/buy analysis is conducted and associated documentation is generated
Depending on the level at which the make/buy analysis will be performed, the SW Mgr may be an organizational-level manager such as a Branch Head; a Mission Project-level manager such as a System Manager, or a software project-level manager such as a Product Development Lead (PDL).
System Engineer (SE)
Lead engineer responsible for performing trade studies and other engineering analyses, and for liaison with other teams supporting a mission
Is generally responsible for requirements engineering
Typically leads or supports decision analysis resolution activities, including