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:

o Mission Project Formulation Team

o GSFC Directorate, Division or Branch

o In-house software development or maintenance project, or

o 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