SSC Pacific Standard Process Assets Architecture Definition

Document Sample
SSC Pacific Standard Process Assets Architecture Definition Powered By Docstoc
					                                                             SSC Pacific SPAA Definition
                                                                        DC-OPD-15 v1.0
                                                                                8/25/09




SPACE AND NAVAL WARFARE SYSTEMS CENTER PACIFIC
STANDARD PROCESS ASSETS ARCHITECTURE DEFINITION


                          DC-OPD-15 V1.0
                         AUGUST 25, 2009




            Systems Engineering Process Office, Code 842
           Space and Naval Warfare Systems Center Pacific
                          53560 Hull Street
                      San Diego CA 92152-5001




         Approved for public release; distribution is unlimited.
                                                                                SSC Pacific SPAA Definition
                                                                                           DC-OPD-15 v1.0
                                                                                                   8/25/09



                                             PREFACE

This Standard Process Assets Architecture (SPAA) defines the Space and Naval Warfare (SPAWAR)
Systems Center (SSC) Pacific set of standard processes and the process architecture. The document also
provides objectives and requirements information on six key subjects for SSC Pacific as listed below:
    a. Life cycle models and strategies
    b. Standard processes and architectures including the Organization’s Set of Standard Processes
       (OSSP)
    c. Guidelines for selection and tailoring of the OSSP
    d. Organization’s Measurement Repositories (OMR)
    e. Process Asset Libraries (PALs)
    f.   Work environment standards.
The approach defined in this document is based on policy, guidance and benchmark information
described in Section 2 and Appendix B.
This document is part of a four volume set which includes the documents listed below:
    a. SPAA Definition
    b. SPAA Implementation Guide
    c. Organizational Measurement Guide
    d. Process Institutionalization Guide
The Systems Engineering Process Office (SEPO) welcomes and solicits feedback from users of this
document, and its reference artifacts, so future versions will reflect improvements based on new
technology, organizational best practices, and lessons learned.
This document was produced according to the process defined in the Handbook for Process Management.
Updates to this document are performed in accordance with the SEPO Configuration Management
Procedure. Deficiencies and/or corrections to this document may be communicated to SEPO via the
Document Change Request form located at the end of this document, or online through the SSC Pacific
Process Asset Library at http://sepo.spawar.navy.mil/.




                                                 ii
                                                                            SSC Pacific SPAA Definition
                                                                                       DC-OPD-15 v1.0
                                                                                               8/25/09



                                   RECORD OF CHANGES
                                                     *A – ADDED, M – MODIFIED, D – DELETED
                     NUMBER OF           A*                                             CHANGE
VERSION
          DATE       FIGURE, TABLE OR    M     TITLE OR BRIEF DESCRIPTION               REQUEST
NUMBER
                     PARAGRAPH           D                                              NUMBER
  1.0      8/25/09   Throughout                This document replaces Space and
                                               Naval Warfare Systems Center San
                                               Diego Standard Process Assets
                                               Architecture, PR-OPD-35, v1.0 dtd
                                               7/10/07.
  1.0      8/25/09   Section 4           A     Add a description of the Department      OPD-0111
                                               Set of Standard Processes
  1.0      8/25/09   Section 4.1         A     Add a definition of process tailoring    OPD-0151




                                         iii
                                                                                                                           SSC Pacific SPAA Definition
                                                                                                                                      DC-OPD-15 v1.0
                                                                                                                                              8/25/09



                                                        TABLE OF CONTENTS
Section                                                                                                                                                  Page

SECTION 1. INTRODUCTION.................................................................................................................. 1
   1.1       Overview ...................................................................................................................................... 1
   1.2       Purpose ......................................................................................................................................... 1
   1.3       Scope ............................................................................................................................................ 2
   1.4       Acronyms and References ............................................................................................................ 2
   1.5       Document Structure ...................................................................................................................... 2
SECTION 2. LIFE CYCLE MODELS AND STRATEGIES ..................................................................... 4
   2.1     Life Cycle Models and Strategies Objectives and Requirements ................................................. 4
   2.2     Functions of Life Cycle Models and Strategies ............................................................................ 4
   2.3     Life Cycle Model for SSC Pacific ................................................................................................ 4
   2.4     Description of Life Cycle Strategies............................................................................................. 5
      2.4.1     Once-Through (Waterfall) Strategy ...................................................................................... 5
      2.4.2     Vee Strategy .......................................................................................................................... 6
      2.4.3     Incremental Strategy ............................................................................................................. 7
      2.4.4     Spiral Strategy ....................................................................................................................... 7
      2.4.5     Evolutionary Strategy ........................................................................................................... 8
   2.5     Selection and Tailoring of Life Cycle Models and Strategies ...................................................... 9
SECTION 3. STANDARD PROCESS ARCHITECTURE AND OSSP .................................................. 10
   3.1     Process Architecture and OSSP Objectives and Requirements .................................................. 10
   3.2     Standard Process-Related Policy Requirements ......................................................................... 10
   3.3     The Organization’s Set of Standard Processes ........................................................................... 11
   3.4     Architecture Views ..................................................................................................................... 11
      3.4.1     The Systems View of the Architecture ............................................................................... 14
      3.4.2     The Technical Standards View of the Architecture ............................................................ 15
      3.4.3     The Operational View of the Architecture .......................................................................... 15
      3.4.4     Process Categories and the OSSP ....................................................................................... 16
      3.4.5     Architecture Numbering System ......................................................................................... 16
   3.5     OSSP Relationships .................................................................................................................... 16
      3.5.1     Systems of Processes .......................................................................................................... 16
      3.5.2     Sub-Process and Process Element Relationships ................................................................ 17
      3.5.3     Process Components and Relationships .............................................................................. 17
   3.6     Documenting Processes .............................................................................................................. 18
      3.6.1     Process Documentation Principles ...................................................................................... 19
      3.6.2     Process Documentation Requirements ................................................................................ 20
      3.6.3     Process Documentation Criteria.......................................................................................... 20
      3.6.4     Procedure Documentation Requirements............................................................................ 21
   3.7     Roll-Out of Standard Processes .................................................................................................. 21
SECTION 4. OSSP TAILORING GUIDELINES ..................................................................................... 22
   4.1       OSSP Tailoring Objectives and Requirements ........................................................................... 22
   4.2       The OSSP and Defined Processes of Organizational Units ........................................................ 23
   4.3       The Essential Sub-Set of Processes ............................................................................................ 23
   4.4       Department and Project Tailoring Activities .............................................................................. 24


                                                                          iv
                                                                                                                        SSC Pacific SPAA Definition
                                                                                                                                   DC-OPD-15 v1.0
                                                                                                                                           8/25/09


   4.5       Documentation of OSSP Tailoring ............................................................................................. 26
   4.6       Options and Criteria.................................................................................................................... 26
SECTION 5. ORGANIZATION’S MEASUREMENT REPOSITORIES ................................................ 27
   5.1       OMR Objectives and Requirements ........................................................................................... 27
   5.2       Repository Allocation ................................................................................................................. 27
SECTION 6. PROCESS ASSET LIBRARIES.......................................................................................... 29
   6.1       PAL Objectives and Requirements ............................................................................................. 29
   6.2       Organizational Process Asset Library Relationships .................................................................. 29
SECTION 7. WORK ENVIRONMENT STANDARDS .......................................................................... 31
   7.1       Work Environment Standards Objectives and Requirements ..................................................... 31
   7.2       Purpose of Standards for the Work Environment ....................................................................... 31
APPENDIX A. ABBREVIATIONS AND ACRONYMS....................................................................... A-1

APPENDIX B. REFERENCES ............................................................................................................... B-1

APPENDIX C. SSC PACIFIC STANDARD PROCESS ASSETS CATALOG .................................... C-1


                                                           LIST OF FIGURES
Figure                                                                                                                                               Page
Figure 1-1.     OPD Four Volume Set .............................................................................................................. 1
Figure 2-1.     SSC Pacific Life Cycle Model for OSSP Architecture ............................................................. 4
Figure 2-2.     Life Cycle Model from ISO/IEC Standard 15288..................................................................... 5
Figure 2-3.     Life Cycle Model from SSC San Diego PMG .......................................................................... 5
Figure 2-4.     Once-Through Life Cycle Strategy ........................................................................................... 6
Figure 2-5.     Vee Strategy .............................................................................................................................. 6
Figure 2-6.     Incremental Strategy ................................................................................................................. 7
Figure 2-7.     Original Spiral Strategy ............................................................................................................. 8
Figure 2-8.     Evolutionary Strategy................................................................................................................ 9
Figure 3-1.     Standard Systems Engineering Process Architecture – Process Systems View...................... 13
Figure 3-2.     Process-Related Assets Framework – Process Operational View ........................................... 13
Figure 3-3.     Systems of Processes ............................................................................................................... 16
Figure 3-4.     Critical Components of Standard Process Descriptions .......................................................... 18
Figure 3-5.     Relationships of Process Assets Related to Documenting Processes ...................................... 19
Figure 4-1.     Department and Project Tailoring Activities........................................................................... 25
Figure 5-1.     Example Measurement Repository Hierarchy ........................................................................ 28
Figure 6-1.     PAL Relationships .................................................................................................................. 30

                                                              LIST OF TABLES
Table                                                                                                                                                Page
Table 2-1. Key Features of the SSC Pacific Life Cycle Strategies .............................................................. 9
Table 3-1. OSSP Process Technical View – Standard/Process Cross Reference ...................................... 12
Table 3-2. A Notional OSSP by Process Category ..................................................................................... 14
Table 3-3. Process Documentation Criteria ................................................................................................ 20


                                                                         v
                                                                                                    SSC Pacific SPAA Definition
                                                                                                               DC-OPD-15 v1.0
                                                                                                                       8/25/09


Table C-1. SSC Pacific Standard Process Asset Catalog ......................................................................... C-1




                                                             vi
                                                                                                                                                                                                                         SSC Pacific SPAA Definition
                                                                                                                                                                                                                                    DC-OPD-15 v1.0
                                                                                                                                                                                                                                            8/25/09




                                                                                            SECTION 1. INTRODUCTION

1.1                               OVERVIEW
This document is the primary process improvement-related source document applicable to the Space and
Naval Warfare (SPAWAR) Systems Center (SSC) Pacific because it lists the standard processes and
describes how the relationships of standard processes and other process assets are indexed and shared.
The Standard Process Assets Architecture (SPAA) Definition also clearly describes the relationship of the
SSC Pacific standard processes, the primary systems engineering standards that are the source of these
standard processes, and the policy which requires the use of specific systems engineering standards,
models, and guides. Recent Navy policy also requires the use of the Capability Maturity Model
Integration (CMMI) for Development, reference (a), for assessing the maturity of Navy organizations as
they implement the processes described in the systems engineering standards. A summary of these
policies is provided in Section 3.2, and the integration of these and other Systems Engineering (SE)
sources is fully described in Section 3.
The SPAA focuses on identification of the Organization’s Set of Standard Processes (OSSP), the
frameworks for linking them to life cycle models and other process assets, the tools and methods for
sharing the process assets, and how the OSSP can be tailored for use by organizational units including
departments and projects.
The SPAA is one of a four volume set of documents related to the Organization Process Definition (OPD)
as defined in reference (a). The four volume set and its contents are shown in Figure 1.



                                                                         Organizational Process Definition
                                                                                 Four Volume Set


                                                                                                               tatio          n
                                                                                                                                                                                  ment                                                             cess
                                            ctives
                                                   and                                                   lemen                                                              asure e                                                         4. Pro zation
      1                              1. Obje ments for:                      2                     A Imp                                     3
                                                                                                                                                                       3. Me
                                                                                                                                                                                                              4
                                                                                                                                                                                                                                                utiali
                                                                                             2. SPA uidance:                                                                    anc
                                                                                                                                    Organizational Measurement




                                                                                                                                                                                                                                          Instit idance
 Architecture (SPAA) Definition




                                            e                                                                                                                              Guid
                                                                                                                                                                                                      Process Institutialization




                                                                                                    G
                                     Requir                                                                                                                                                                                              cy   Gu
    Standard Process Asset




                                                                                                                                                                                                                                   • Poli ing
                                                                      SPAA Implementation




                                                                                                                    ls                                                                 tro.                                                          urces
                                                 Mode
                                                        ls                                                 Mode                                                                 ent In                                                    n
                                                                                                                                                                                                                                   • Plan ing Reso onsibility
                                          Cycle                                                    Cycle                                                                 surem           ns
                                                                                            • Life                                                                • Mea                                                                   id
                                                                                                                                                                                                                                   • Prov ning Resp
                                                                                                                                           Guide (OMG)




                                   • Life           s                                                      re s                                                                 e nt Pla
                                          ite cture                                                 itectu                                                              surem               ss                                           ig
                                                                                                                                                                                                                                   • Ass g People nagement
                                   • Arch                                                   • Arch                 sses                                           • M ea             Proce
                                                                                                                                                                                                               Guide




                                                       sses                                              Proce                                                                     t
                                                Proce                                                                                                                       emen                                                           in
                                                                             Guide




                                                                                                                                                                                                                                                      a
                                          dard                                                    ndard               e                                              easur               lysis                                     • Train guration M lvement
                                  • Stan          uid ance                                  • Sta           u idanc                                               •M           ent A
                                                                                                                                                                                      na                                                 fi           o
                                                                                                                                                                                                                                   • Con holder Inv trol
                                          ring G                s                                   ring G                  s                                           surem             rting
                                  • Tailo               ibrarie                             • Tailo                 ibrarie                                       • Mea              Repo                                                  e
                                                                                                                                                                                                                                    • Stak ring & Con on
                                                 sset L                                                   sset L                                                              ment             ries
                                          ess A               ories                               cess
                                                                                                        A                itorie
                                                                                                                                s
                                                                                                                                                                     easur
                                                                                                                                                                            e
                                                                                                                                                                                      e posito                                            ito           ati
                                                                                                                                                                                                                                    • Mon nce Evalu eviews
                                  • Proc               eposit                               • Pro              t Rep
                                                                                                                      os                                          •M           ent R                                                      ere
                                                 ent R                                                 emen                                                            surem                                                        • Adh            tus R
                                         surem            nmen
                                                                 t                             easur                  nmen
                                                                                                                             t                                   • M ea                                                                       gt. Sta n
                                  • M ea            nviro                                   •M
                                                                                                         e Env
                                                                                                                  iro                                                                                                                     er M
                                           p lace E                                                kplac                                                                                                                           • High ss Definitio rmation
                                                                                                                                                                                                                                                      fo
                                  •  Work s                                                 • Wor rds                                                                                                                                     e
                                                                                                                                                                                                                                   • Procovement In
                                           ard                                               Stand
                                                                                                    a                                                                                                                                    r
                                    Stand                                                                                                                                                                                          • Imp




                                                                                                  Figure 1-1. OPD Four Volume Set

1.2                               PURPOSE
This document is an SSC Pacific-level guidance document which is provided to implement SSC Pacific
policy, guidance, and initiative memoranda along with best practice information. However,
implementation of the standards, models, and/or referenced assets, discussed in this document may be



                                                                                                                               1
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09


adjusted, or tailored, as described in Section 4, to fit the needs of the organization or programmatic
requirements as long as these tailored methodologies also satisfy the intent of the higher-level direction
and guidance.
This document presents the SSC Pacific architectural framework for the development and presentation of
process architectures. The organization will likely use multiple process architectures. The framework
provides the structural views, guidance, and process descriptions for developing and presenting
architecture descriptions that ensure a common denominator for understanding, comparing, and
integrating process architectures. The application of the framework will enable architectures to contribute
most effectively to building interoperable and cost effective systems engineering process assets.
The SSC Pacific process architecture framework is intended to ensure that the architecture descriptions
developed by the departments are inter-relatable between and among each organization’s operational,
systems, and technical architecture views, and are comparable and may be integrated across
organizational boundaries. Architecture views are defined in Section 3.4.

1.3        SCOPE
This document contains process asset architecture and OSSP guidance applicable to SSC Pacific, and the
technical departments and organizational units within SSC Pacific. The process architecture described in
this document is designed to meet short-term and long-term objectives of SSC Pacific. It provides a
context for all process development and improvement activities.

1.4        ACRONYMS AND REFERENCES
Acronyms are located in Appendix A and references are located in Appendix B.

1.5        DOCUMENT STRUCTURE
The contents of this document have been organized to address SSC Pacific’s process assets in terms of the
policy and guidance summarized above.
The sections in this document are listed below:
      a. Section 1 – Provides an overview of the document and lead-in material including references and
         abbreviations.
      b. Section 2 – Describes the objectives and requirements for establishing a life cycle and life cycle
         strategies for use by organizational units.
      c. Section 3 – Discusses the objectives and requirements for establishing the OSSP and the
         architectures/frameworks used for defining process asset relationships. This section also defines
         the SSC Pacific OSSP and related architecture views.
      d. Section 4 – Defines the objectives and requirements for tailoring the OSSP and related process
         assets.
      e. Section 5 – Describes the objectives and requirements for establishing an Organizational
         Measurement Repository (OMR).
      f.    Section 6 – Describes the objectives and requirements for establishing Process Asset Libraries
            (PALs) within organizational units.
      g. Section 7 – Describes the objectives and requirements of establishing work environment
         standards.



                                                      2
                                                                            SSC Pacific SPAA Definition
                                                                                       DC-OPD-15 v1.0
                                                                                               8/25/09


h. Appendix A     Provides a list of all abbreviations and acronyms used in the document.
i.   Appendix B   Provides a list of all references used in the document.
j.   Appendix C   Provides the format for the SSC Pacific Standard Process Assets catalog




                                            3
                                                                                      SSC Pacific SPAA Definition
                                                                                                 DC-OPD-15 v1.0
                                                                                                         8/25/09




              SECTION 2. LIFE CYCLE MODELS AND STRATEGIES

2.1 LIFE CYCLE MODELS AND STRATEGIES OBJECTIVES AND
REQUIREMENTS
The objective is to establish and maintain life cycle models and strategies approved for use by the
organization. The purpose of the life cycle model is to define the phases applicable to projects to
organize and assess the adequacy of project activities and monitor progress. The life cycle model forms
the framework for project processes. Life cycle strategies describe iterations through some stages of the
life cycle model.
Requirements include those listed below:
      a. Describe different life cycle models and strategies to be used in situations applicable to
         organizational units and projects.
      b. Describe the selection of life cycle models and strategies based on the needs of organizational
         units and projects.

2.2     FUNCTIONS OF LIFE CYCLE MODELS AND STRATEGIES
The primary function of a life cycle model is to form a framework for process application. Some
processes are primarily applicable to specific life cycle phases.
The primary function of a life cycle strategy is to specify the iterative nature of the application of
processes. Some processes are repeated as some projects loop back through life cycle phases.
Systems Engineering-System life cycle processes, reference (b), provides the guidance listed below to
assist organizations in the development of life cycle models:
      a. A life cycle model shall be established
      b. The life cycle model is comprised of one or more stages as needed
      c. It is assembled as a sequence of stages that may overlap and/or iterate
      d. The stages provide a framework for the life cycle processes.

2.3     LIFE CYCLE MODEL FOR SSC PACIFIC
The life cycle model shown in Figure 2-1 is the SSC Pacific standard life cycle model. The model was
created for the specific purpose of providing a framework for the SSC Pacific process architecture. This
model was designed by integrating stages used in a number of models to include, the Department of
Defense (DoD) acquisition (life cycle) model, the International Council on Systems Engineering
(INCOSE) life cycle model, the example model in reference (b) and others. The integration of these
models provides the most complete model for the SSC Pacific OSSP, and is also suitable for some of SSC
Pacific’s large development and sustainment-type projects.




                      Figure 2-1. SSC Pacific Life Cycle Model for OSSP Architecture


                                                     4
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09


A typical intermediate-size life cycle model used as an example in reference (b) and shown in Figure 2-2,
contains six stages. It may be adopted by projects needing a model with a medium level of detail in
terms of stages.

        Concept      Development         Production         Utilization    Support         Retirement
         Stage          Stage              Stage              Stage         Stage            Stage


                           Figure 2-2. Life Cycle Model from ISO/IEC Standard 15288
A simple life cycle model using the five project management functions described in the Project
Management Body Of Knowledge (PMBOK Guide), reference (c) and used as the framework of the SSC
San Diego Project Management Guide (PMG), reference (d), is shown in Figure 2-3.

                                                      Control
                                                 (Management)
                                                  Processes


                                                Planning
              Initiation                        Processes
              Processes




                                                  Execution                       Closeout
                                                  Processes                       Processes




                            Figure 2-3. Life Cycle Model from SSC San Diego PMG
The three life cycle models in Figures 2-1, 2-2, and 2-3 are the standard approved models for SSC Pacific.
Projects are expected to select one of these models unless there is reasonable rationale for use of a
different model, which will require a deviation request. The adoption, adaptation or tailoring of life cycle
models is described in Section 2.5. Tailoring and deviation requests are described in Section 4.

2.4     DESCRIPTION OF LIFE CYCLE STRATEGIES
Life cycle strategy refers to the iterative philosophy to be employed in the planning and execution of the
life cycle model. At least five life cycle strategies are in common use in DoD programs and projects.
They are the: Once Through or Waterfall, “Vee”, Incremental, Spiral, and Evolutionary. The names of
the activities in each of the strategy descriptions are those selected by the original publishers of these
strategies. They have not been changed here for purposes of consistency. The intent is to illustrate
various strategy alternatives. Modification and tailoring of these alternatives is described in Section 2.5.
2.4.1    Once-Through (Waterfall) Strategy
The Once-Through strategy is another name for the “Grand Design” or “Waterfall”. It is a program
strategy associated with Department of Defense terminology for software projects. A sequential
development strategy, usually applied to the creation of software, in which development is seen as
flowing steadily downwards (like a waterfall) through the phases shown in Figure 2-4. "Waterfall" has



                                                       5
                                                                                            SSC Pacific SPAA Definition
                                                                                                       DC-OPD-15 v1.0
                                                                                                               8/25/09


come to refer to any approach to work product creation which is seen as inflexible and non-iterative. This
strategy was conceived during the early 1970s as a remedy to the undisciplined “code and fix” method of
software development. It is a once-through, do-each-step-once strategy. In this approach, each phase is
performed in sequence and must be completed before proceeding to the next phase in the sequence. For
example, design does not begin until project plans are prepared, reviewed, and complete. Likewise,
implementation does not begin until the requirements and design phases are complete.
The Once-Through strategy may be considered useful for some current non-software projects such as
study projects or selected integration or services projects.

                   Requirements


                                  Planning



                                                Design


                                                         Implementation


                                                                      Verification


                                                                                     Operational
                                                                                      Fielding


                             Figure 2-4. Once-Through Life Cycle Strategy
2.4.2   Vee Strategy
The Vee strategy is a software development strategy which is an extension of the Once-Through strategy.
The Vee concept has also been used for hardware development. Instead of moving down in a linear way,
the phases are bent upwards after the coding phase, to form the typical V shape shown in Figure 2-5. The
Vee strategy demonstrates the relationships between each phase of the development life cycle and its
associated phase of testing.




                                             Figure 2-5. Vee Strategy



                                                         6
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


2.4.3   Incremental Strategy
The Incremental strategy, as shown in Figure 2-6, is a cyclical software development strategy developed
in response to the weaknesses of the Once-Through strategy. Incremental development is a scheduling
and staging strategy in which the various parts of the system are developed at different times or rates, and
integrated as they are completed. This strategy is unlike the Once-Through strategy which historically
resulted in considerable rework. The alternative to incremental development is to develop the entire
system with a "big bang" integration, or employ a spiral strategy.




                                     Figure 2-6. Incremental Strategy
2.4.4   Spiral Strategy
The Spiral strategy, shown in Figure 2-7, also known as the spiral lifecycle strategy, is a systems
development method used in information technology. The original spiral diagram was published in 1988
by Barry Boehm. This strategy combines the features of prototyping models and the Once-Through
strategy. The Spiral strategy is intended for large, expensive, and complicated projects. Numerous
variations on the original version have been published since 1988.
The steps in the Spiral strategy can be generalized as listed below:
    a. The new system requirements are defined in as much detail as possible. This usually involves
       interviewing a number of users representing all the external or internal users and other aspects of
       the existing system.
    b. A preliminary design is created for the new system.
    c. A first prototype of the new system is constructed from the preliminary design. This is usually a
       scaled-down system, and represents an approximation of the characteristics of the final product.
    d. A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms
       of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3)
       planning and designing the second prototype; (4) constructing and testing the second prototype.
    e. At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk
       factors might involve development cost overruns, operating-cost miscalculation, or any other
       factor that could, in the customer's judgment, result in a less-than-satisfactory final product.



                                                   7
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


    f.   The second prototype is evaluated in the same manner as was the previous prototype, and, if
         necessary, another prototype is developed from it according to the fourfold procedure outlined
         above.
    g. The preceding steps are iterated until the customer is satisfied that the refined prototype
       represents the final product desired.
    h. The final system is constructed, based on the refined prototype.
    i.   The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a
         continuing basis to prevent large-scale failures and to minimize downtime.




                                   Figure 2-7. Original Spiral Strategy
2.4.5    Evolutionary Strategy
An Evolutionary strategy, shown in Figure 2-8, is the preferred DoD strategy for rapid acquisition of
mature technology for the user. An evolutionary approach delivers capability in increments, recognizing
the need for future capability improvements. Most major Acquisition Category programs are expected to
use this strategy. The objective is to balance needs and available capability with resources, and to put
capability into the hands of the user quickly. The success of the strategy depends on consistent and
continuous definition of requirements, and the maturation of technologies that lead to disciplined
development and production of systems that provide increasing capability towards a materiel concept.
This strategy usually calls for the repeated implementation of numerous systems engineering processes as
each system increment or block of changes goes through its own life cycle. The Operation of the Defense
Acquisition System, reference (e), provides top-level guidance for the Evolutionary strategy.
The Software Life Cycle Processes document, reference (f) provides an excellent discussion of three of
the example strategies. The strategies, while discussed in the context of software, are universally
applicable and serve as an excellent means of addressing the fundamental concepts. These strategies are
approved by SSC Pacific as the basis for planning and implementation as described in reference (d). To
assist in selection, the key features of all five strategies are summarized in Table 2-1.



                                                   8
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09




                                    Figure 2-8. Evolutionary Strategy
         TABLE 2-1. KEY FEATURES OF THE SSC PACIFIC LIFE CYCLE STRATEGIES
                                      Define All              Multiple
                                                                                  Field Interim
         Life Cycle Strategy         Requirements           Development
                                                                                    Solution?
                                        First?                Cycles?
        Once Through                      Yes                     No                    No
        Vee                               Yes                     No                    No
        Incremental                       Yes                    Yes                  Maybe
        Spiral                             No                    Yes                    No
        Evolutionary                       No                    Yes                    Yes

2.5   SELECTION AND TAILORING OF LIFE CYCLE MODELS AND STRATEGIES
Departments and projects select an approved standard model or create a life cycle model that satisfies
their needs and requirements. Use of a non-standard model may be necessary, but will require a deviation
request as described in Section 4 of the SSC Pacific SPAA Implementation Handbook, reference (g). The
life cycle model should form a framework for applicable processes and identify any decision gates
applicable to the project. This model may be dictated by the project sponsor.
Departments and projects also select an applicable life cycle strategy which facilitates the iterative and
recursive application of some processes over the life cycle of the project. The life cycle strategy may also
be dictated by the sponsor. This subject is discussed further in reference (g).




                                                   9
                                                                                      SSC Pacific SPAA Definition
                                                                                                 DC-OPD-15 v1.0
                                                                                                         8/25/09




           SECTION 3. STANDARD PROCESS ARCHITECTURE AND OSSP

3.1        PROCESS ARCHITECTURE AND OSSP OBJECTIVES AND REQUIREMENTS
The objective is to establish and maintain a useable set of standardized organizational processes and
related process assets, and to describe them in terms of multiple process architecture views. The OSSP
should collectively cover all processes needed by the organization and projects including those processes
described in policy and policy-related standards and models.
Requirements for standard processes and architectures are listed below:
      a. Identify policy and guidance documents, which in-turn, identify standards and models containing
         candidates for standard processes.
      b. Identify the processes to be included in the OSSP.
      c. Identify the relationships of the OSSP and process-related assets in terms of multiple process
         architecture views.
      d. Describe how the OSSP is decomposed into process elements and attributes.
      e. Specify the relationships and interfaces between processes, sub-processes, and process elements.
      f.    Develop a coherent and comprehensive process architecture that is segmented into process areas
            such as project management, process management, support processes, and technical engineering.
            The segmented and other architecture views are to make the architecture easy to understand and
            apply by process users and managers.
      g. The process architecture is to have the attributes listed below:
            1. Be engineering process-centered
            2. Be life cycle-oriented
            3. Include management-level processes (cross project)
            4. Include supporting processes (cross project)
            5. Include linkages to process-related assets such as policies, standards, guidelines, forms,
               checklists, templates, and samples.

3.2        STANDARD PROCESS-RELATED POLICY REQUIREMENTS
The standard systems engineering process-related policy is summarized below:
      a. Establish a model of common standard processes and other enabling standard processes in a
         process framework that is a hybrid of the primary systems engineering standards to include
         reference (b), the Processes for Engineering a Systems, reference (h) and Management of the
         Systems Engineering Process, reference (i). (Source: Defense Acquisition Guidebook, reference
         (j) and Systems / Software Engineering Management Policy, ref (k))
      b. Implement the Naval Systems Engineering Guide (NSEG), reference (l), which requires the
         systems engineering processes be imbedded in project planning and performed across the entire
         acquisition life cycle. (Source: Systems and Software Engineering Policy, reference (m))
      c. Incorporate reference (f) into common engineering processes, and use reference (a) to benchmark
         processes against best practices. (Source: reference (m))



                                                      10
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


      d. Projects are to implement a set of common engineering processes that are tailored from the
         standard set of engineering processes. (Source: reference (m))

3.3     THE ORGANIZATION’S SET OF STANDARD PROCESSES
The SSC Pacific OSSP contains fifty-five processes as shown in Table 3-1. This list is the result of
integrating the processes in seven key policy, standards and guidance documents fulfilling the
requirement that the OSSP be standards-based, and adopting the recommendation in reference (j), that the
OSSP be a hybrid of the standards. The seven key source documents are references (a), (b), (f), (h) – (j)
and (l). A cross reference to the applicable section of the source document is in the columns of Table 3-1.

3.4     ARCHITECTURE VIEWS
An architecture shows component parts of a system and how the components fit together (i.e., their
relationships). Many references concerning architectures use building blueprints as an example of
architecture. Building plans make a good analogy for process architectures because both show the
individual components and how they relate to each other and both need several views to make all of the
needed detail clear to different users. The DoD Architectural Framework, reference (n) defines a standard
way to organize a system architecture into complementary views. A term related to these alternative
views is “multi-views”, meaning the viewing of the object from different viewpoints to see new or
different details. The top view, front view, side view, etc. often gives much more information detail than
a single view.
Like a building or system, a standard process set is composed of processes, sub-processes, related
processes, and process elements. A process architecture provides the framework for connecting the
process elements, related processes, and other process related materials (assets), and the rules or methods
for showing relationships.
This section shows several views of the SSC Pacific process architecture. Three views of architectures
are described in reference (n) and the Command, Control, Communication, Computers, Intelligence,
Surveillance and Reconnaissance (C4ISR) Architecture Framework, reference (o). These references use
the phrase “one architecture, three views.” The views they are describing are listed below:
      a. Systems view – The systems view, in Figure 3-1, shows top-level relationships among the
         systems (processes in this case), and a mapping of systems to operational activities (life cycle
         phases in this case). The central component of the systems view is the SSC Pacific life cycle
         model, from Figure 2-1. The relationship of processes and process related assets is also shown in
         Figure 3-1.
      b. Technical Standards View – Table 3-1 lists the standard processes along with the source
         standards or references. The list of processes in this table represents the SSC Pacific OSSP, and
         is the process technical view since it shows the applicable standards and other sources.
      c. Operational View – Figure 3-2 shows a top level pictorial of the management and engineering
         functions in a general time sequence which represents an operational view.
Additional views are located in Table 3-2 and Appendix C. Table 3-2 shows the OSSP by process
category (Process Management, Project Management, Support, and Engineering). Appendix C shows the
standard process asset catalog (or catalog numbering system) for SSC Pacific process assets (processes,
forms, checklists, templates, guidebooks, and policy documents).




                                                   11
                                                                                                              SSC Pacific SPAA Definition
                                                                                                                         DC-OPD-15 v1.0
                                                                                                                                 8/25/09


      TABLE 3-1. OSSP PROCESS TECHNICAL VIEW – STANDARD/PROCESS CROSS REFERENCE
       Process                                                                   CMMI                                       ISO /       IEEE
ID                                                                                                   EIA        IEEE
       Catalog                          Process Name                              By      NSEG                               IEC        / EIA
#                                                                                                    632        1220
          #                                                                       ML                                        15288       12207
 1     PR TBD       Organizational Innovation and Deployment           (OID)      5
 2     PR TBD       Causal Analysis and Resolution                    (CAR)       5
 3     PR TBD       Organizational Process Performance                 (OPP)      4
 4     PR TBD       Quantitative Project Management                  (QPM)        4
 5     PR 1.4.1     Organizational Process Focus (Improvement)         (OPF)      3                               4.14                     7.3
 6     PR 1.3.1     Organizational Process Definition                 (OPD)       3                                5.6        5.2.3
 7     PR 3.8.1     Organizational Training – Plan Development           (OT)     3                                                        7.4
 8     PR 1.8.2     Project Investment Management (new projects)                                                              5.2.2
 9     PR 1.8.1     Project Initiation and Proposal              (PMBOK)
10     PR 2.3.9     Work Breakdown Structure-Create (WBS) (PMBOK)
11     PR 2.3.7     Project Cost Estimation                      (PMBOK)
12     PR 2.3.1     Project Planning/Documentation                       (PP)     2                                           5.3.1
13     PR 3.4.1     Project Management                                                                                        5.2.4        7.1
14     PR 1.8.8     Project Management Reviews                                                                                            6.6.2
15     PR 2.3.6     Integrated Project Management/teaming              (IPM)      3                               4.11        5.2.1        7.2
16     PR 3.5.4     Supply Products and Services Process                                   SP 1        1                                   5.2
17     PR 3.5.3     Acquisition Products and Services Process                              SP 2        2                      5.1.1        5.1
18     PR 3.5.1     Supplier Agreement/Performance Management (SAM)               2        SP 3        3                      5.1.2
19     PR 2.3.3     Process Implementation Strategy Planning                               SP 4        4
20     PR 1.3.4     Process Tailoring Process                   (INCOSE)
21     PR 2.3.4     Technical Effort Definition                                             SP 5        5
22     PR 2.3.5     Activity Organization and Scheduling                                    SP 6        6
23     PR 2.3.2     Technical Plan Documentation                                            SP 7        7         4.3
24     PR 3.5.2     Work Directives/Instructions/Tasks Definition                           SP 8        8
25     PR 1.8.6     Progress Assessment – of Plan s and Schedules                           SP 9        9                     5.3.2
26     PR 1.8.5     Progress Assessment – of Requirements Achieved                         SP 10       10
28     PR 1.8.4     Project Monitoring and Control                   (PMC)        2        SP-12       12                     5.3.3
29     PR 2.9.1     Project Closeout                            (PMBOK)
30     PR 3.2.1     Risk Management                                (RSKM)         3        SP 24       24                     5.3.5
31     PR 1.7.1     Measurement and Analysis                        (M&A)         2                                           5.3.2
32     PR 3.1.1     Configuration Management                            (CM)      2                                           5.3.6        6.2
33     PR 1.5.2     Quality Assurance (product and process)         (PPQA)        2                               4.13                     6.3
34     PR 3.3.1     Decision Analysis and Resolution                 (DAR)        3                                           5.3.4        6.8
35     PR 3.7.1     Project Information Management                                         SP 13       13                     5.3.7
36     PR 2.1.1     Requirements Development (project)                  (RD)      3        SP 14       14                    5.4.2.3
37     PR 2.1.2     Requirements Identification (stakeholder)                              SP 15       15                     5.4.1
38     PR 2.1.3     Requirements Identification (technical)                                SP 16       16
39     PR 2.1.4     Requirements Analysis / Management            (REQM)          2                              6.1-16    5.4.2.3-16
40     PR 2.4.1     Technical Solution (design/implement)                (TS)     3                    5                                   5.3
41     PR 2.4.6     Architectural Design Definition                                                                           5.4.3
42     PR 2.4.8     Logical Solution Definition                                            SP 17       17
43     PR 2.4.9     Physical Solution/Synthesis Definition                                 SP 18       18         6.5
44     PR 2.4.12    Design Solution (specifications) Documentation                         SP 19       19
45     PR 2.4.14    Product Integration (and testing)                     (PI)    3                                5.4        5.4.5
46     PR 2.4.7     Technical Data Package Development                                                           4.6/4.7                   6.1
       PR 2.6.3     Systems Engineering Technical Reviews           (SETR)                 SP 11      11          4.12                    6.6.3
47     PR 2.5.1     Implement the Product Design                                           SP 20      20           5.5        5.4.4
48     PR 2.7.1     Transition (to use)                                                    SP 21      21                      5.4.7
49     PR 2.2.2     Effectiveness Analysis                                                 SP 22      22
50     PR 2.2.1     Tradeoff Study                                                         SP 23      23
                                                                                          SP 25 to   25 to
51     PR 2.6.1     Validation                                         (VER)      3                               6.2         5.4.8        6.5
                                                                                            29        33
                                                                                          SP 30 to   30, to
52     PR 2.6.2     Verification                                      (VAL)       3                               6.6         5.4.6        6.4
                                                                                            33        32
53     PR 2.7.2      Operation (Monitor System Operations)                                                                   5.4.9         5.4
54     PR 2.8.1      Maintenance (Monitor System Performance)                                                               5.4.10         5.5
55     PR 2.9.2      Disposal                                                                                               5.4.11
     Notes-Other References: ID# 9 - Reference (c), Section 3.2.1; ANSI/PMI-STD-99-001-2. ID# 10 - Reference MIL-HDBK-881; reference (c)
     Section 5.3; ANSI/PMI-STD-99-001-2004. ID# 11 - Reference (c), Section 7.1; ANSI/PMI-STD-99-001-2004. ID# 20 - Reference (x), Section
     5. ID# 29 - Reference (c), Section 4.7; ANSI/PMI-STD-99-001-2004



                                                                         12
                                                                                                                                            SSC Pacific SPAA Definition
                                                                                                                                                       DC-OPD-15 v1.0
                                                                                                                                                               8/25/09




        Process Architecture – Operational View
      Figure 3-1. Standard Systems Engineering Process Architecture – Process Systems View
                    (High-Level Graphical View of Process Operations)
  Lead The Center                 SPI Agent Job Desc.     SPAA – PMG – PE&Q Proc               Team            SPAA – OSSP - PAL
                                    PI Consol. WBS                                                                                                   SEPO
 BSC SSC                                                                                      Training
                    PM Policy                                                                                                                      Customer
 San Diego                          PI Plan Template                                         Process &         SPI Agent Performance Objs
                   SEM Policy                                                                                                                    Survey Process
   Vision                          SPI Tracking Proc      Process Description Template       Materials         SPI Agent Status Procedure


Manage Projects/SPI
                          Successful Reviews and Meetings          Project Monitoring & Control            Project Status Review Template

Project Mgmt. Guide (PMG)       Sys. Eng. Plan (SEP) Preparation Guide        Risk Management Process      Project Health Hdbk          Project Closeout Plan TM

      CAPM Process – Guide – SOW STD                    Project Execution & Verification Guide             Quantitative Project Management Guide

Initiate Project            Perform Planning               Design Product                Produce Product              Produce Support             Support Product
                           PMP Template                        Requirements                Production                     Tech Manual                Provide
 Proposal Prep.
                           WBS Template                        Anal. Process             Implementation                    Production                Product
     Guide
                           Build Plan Template                                              Process                         Process                 Operations
                           SEP Plan prep guide                  Architecture                                                                         Support
  SPAA – PMG
                           Task Plan Template                     Process                Product Integration            Training Materials
   Life Cycle
                           Task Mgt Workbook                                                  Process                   Production Process           Engineering
    Guidance
                           Process Desc. Template              Logical Solution                                                                     Support Process
                           Estimation Process                 Definition Process         Design Requirements            Provisioning Process
PM Job Description
                           Estimation Plan TM                                             Validation Process                                        PBL-O Support
                           Measurement Plan TM                Physical Solution                                         ULSS Production                Process
   Project Mgt
                           Proj. Training Plan TM             Definition Process           Effectiveness &                 Process
  Plan Template
                           Test Planning Guide                                            Tradeoff Analysis
                                                                                                                                                    Modifications
                           SSA Estab. Process                   Design Doc.                   Processes                    Help Desk
                                                                                                                                                    and Updates
  Task Planning            SW Planning Process                    Process                                                   Process
                                                                                                                                                      Process
                           SDP Template                                                   Design Reqmts.
                           RM Guide (NAVAIR)                      Design                    Validation                  ILS Certification
 SEP Prep Guide                                                                                                                                    Transition Plan
                                                               Spec. Process                  Process                       Process
                                                                                                                                                     Template

 Support the Projects
Configuration Mgmt. Plan Template        Decision Analysis & Res. Process             Measurement Plan Template

                     Quality Assurance Plan Template           Perform Causal Analysis & Res.                  PAL Maintenance Procedure & tools sheet



                   Figure 3-2. Process-Related Assets Framework – Process Operational View



                                                                                 13
                                                                                                         SSC Pacific SPAA Definition
                                                                                                                    DC-OPD-15 v1.0
                                                                                                                            8/25/09


                    TABLE 3-2. A NOTIONAL OSSP BY PROCESS CATEGORY

                                     I    Proces                        Process Name
                                     D      s
                      Categories
                                     #    Catalo
                                           g#
                                     1    PR         Organizational Innovation and Deployment        (OID)
                                     2    PR         Causal Analysis and Resolution                  (CAR)
                       Process       3    PR         Organizational Process Performance              (OPP)
                      Management     4    PR         Quantitative Project Management                (QPM)
                                     5    PR 1.4.1   Organizational Process Focus (Improvement) (OPF)
                                     6    PR 1.3.1   Organizational Process Definition              (OPD)
                                     7    PR 3.8.1   Organizational Training – Plan Development (OT)
                                     8    PR 1.8.2   Project Investment Management (new projects)
                                     9    PR 1.8.1   Project Initiation and Proposal             (PMBOK)
                                     10   PR 2.3.9   Work Breakdown Structure-Create (WBS) (PMBOK)
                                     11   PR 2.3.7   Project Cost Estimation                      (PMBOK)
                                     12   PR 2.3.1   Project Planning/Documentation
                                     13   PR 3.4.1   Project Management
                                     14   PR 1.8.8   Project Management Reviews
                                     15   PR 2.3.6   Integrated Project Management/teaming           (IPM)
                                     16   PR 3.5.4   Supply Products and Services Process
                                     17   PR 3.5.3   Acquisition Products and Services Process
                       Project       18   PR 3.5.1   Supplier Agreement/Performance Management (SAM)
                                     19   PR 2.3.3   Process Implementation Strategy Planning
                     Management      20   PR 1.3.4   Process Tailoring Process                   ( INCOSE)
                                     21   PR 2.3.4   Technical Effort Definition
                                     22   PR 2.3.5   Activity Organization and Scheduling
                                     23   PR 2.3.2   Technical Plan Documentation
                                     24   PR 3.5.2   Work Directives/Instructions/Tasks Definition
                                     25   PR 1.8.6   Progress Assessment – of Plan s and Schedules
                                     26   PR 1.8.5   Progress Assessment – of Requirements Achieved
                                     27   PR 2.6.3   Systems Engineering Technical Reviews         (SETR)
                                     28   PR 1.8.4   Project Monitoring and Control                 (PMC)
                                     29   PR 1.7.1   Measurement and Analysis                      (M&A)
                                     30   PR 3.2.1   Risk Management                              (RSKM)
                                     31   PR 3.1.1   Configuration Management                         (CM)
                        Support      32   PR 1.5.2   Quality Assurance (product and process)        (PPQA)
                                     33   PR 3.3.1   Decision Analysis and Resolution                (DAR)
                                     34   PR 3.7.1   Project Information Management
                                     35   PR 2.1.1   Requirements Development (project)                 (RD)
                                     36   PR 2.1.2   Requirements Identification (stakeholder)
                                     37   PR 2.1.3   Requirements Identification (technical)
                                     38   PR 2.1.4   Requirements Analysis / Management            (REQM)
                                     39   PR 2.4.1   Technical Solution (design/implement)             (TS)
                                     40   PR 2.4.6   Architectural Design Definition
                                     41   PR 2.4.8   Logical Solution Definition
                       Engineering   42   PR 2.4.9   Physical Solution/Synthesis Definition
                                     43   PR
                                          2.4.12     Design Solution (specifications) Documentation
                                     44   PR
                                          2.4.14     Product Integration (and testing)          (PI)
                                     45   PR 2.4.7   Technical Data Package Development
                                     46   PR 2.5.1   Implement the Product Design
                                     47   PR 2.7.1   Transition (to use)
                                     48   PR 2.2.2   Effectiveness Analysis
                                     49   PR 2.2.1   Tradeoff Study
                                     50   PR 2.6.1   Validation
                                     51   PR 2.6.2   Verification
                                     52   PR 2.7.2   Operation (Monitor System Operations)
                                     53   PR 2.8.1   Maintenance (Monitor System Performance)
                                     54   PR 2.9.1   Project Closeout                        (PMBOK)
                                     55   PR 2.9.2   Disposal



3.4.1   The Systems View of the Architecture
The process architecture shown in Figure 3-1 is built around the SSC Pacific standard life cycle model
shown in Figure 2-1 and was derived from Process Architectures, reference (p).
The SPAA is centered on the component processes which are intended to be stored in a sharable PAL.
The SPAA is intended to have the characteristics (rules) listed below:
    a. Be structure/framework-oriented to include a method for cataloging processes and process-related
       assets which shows relationships and interdependencies.


                                                     14
                                                                                    SSC Pacific SPAA Definition
                                                                                               DC-OPD-15 v1.0
                                                                                                       8/25/09


    b. Be “project-focused” meaning most of the processes are intended to be tailored and executed at
       the project level.
    c. Be “life cycle-oriented” meaning processes may be catalogued in one life cycle phase, but may
       be iteratively executed at different times during the life cycle of a system or product.
    d. Be “CMMI and Related Standards-based” meaning that the process activities are synthesized
       from several applicable systems engineering standards as shown in Table 3-1.
    e. Be based on accepted life cycle management methodologies and best practices.
    f.   Be comprised of basic standard procedures necessary for a common system development process,
         portions of which can be applied across all projects within an organization regardless of the
         project type or life cycle phase.
    g. Be flexible in its ability to deal with hierarchies of processes, sub-processes, process elements,
       and process-related assets.
As departments, projects and other organizational units draw from the OSSP to adopt, adapt, define,
modify, and add processes, hierarchies of processes will emerge. The processes in the OSSP contain
detail of what needs to be done to implement a given process. Projects and organizational elements are
likely to add more detail, in the areas of how to perform some of the activities, to these processes before
implementing them in specific work environments. As projects and organizational units institutionalize
the sharing of process assets across SSC Pacific, the need for tailoring to make the shared processes
useful in the new work environment will increase, and new tailoring guidelines will be needed to guide
these efforts. Section 4 provides a summary of objectives and requirements for creating tailoring
guidelines.
The SPAA shown in Figure 3-1 contains three categories of processes. The Category 100 processes are
organizational-level processes. These are management-level activities that focus on how to lead and
manage organizations and projects. The Category 200 processes are project-level processes. There are
both systems engineering and project management-related processes included which are applicable during
the various life cycle phases of projects. The Category 300 processes are supporting processes. These
processes, which are normally performed by support staff rather than management personnel, can be
employed by any project.
3.4.2    The Technical Standards View of the Architecture
By definition, an architecture technical standards view shows the relationships to standards that apply to
systems view process elements. Table 3-1 shows the standard processes along with the source standards
or references.
SSC Pacific organizational elements such as departments, divisions, branches, and projects may define
their own tailored architecture and/or numbering system. These will need to be mapped to the SSC
Pacific standard architecture in applicable documentation.
3.4.3 The Operational View of the Architecture
The operational view of the process asset architecture is analogous to the standard operational view
discussed in reference (n). This view is “a graphical/pictorial view that comprises an identification of the
operational products and elements, tasks and activities and information flows. It describes what needs to
be accomplished.” This view is meant to provide a big picture representation to the operational
community. Large organizations, such as Boeing and Raytheon (best practice benchmark sources) that
have literally thousands of process assets in their PALs, use a view similar to the one in Figure 3-2 to
summarize the whole operational view.




                                                   15
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09


The operational view in Figure 3-2 shows operators and management that the SSC Pacific PAL contains
process assets at the management, engineering, and support levels which are linked in a life cycle flow.
3.4.4 Process Categories and the OSSP
Each of the primary standards and models group processes differently. CMMI groups processes into
categories like the grouping shown in Table 3-2.
3.4.5    Architecture Numbering System
The architecture shown in Figure 3-1 contains a numbering system that is the mechanism for both
categorizing and integrating the process assets. Another view of this numbering system is shown in
Appendix C. The numbering system indicates where individual process assets fit into the overall process
architecture. This numbering system serves the same purpose as the “Dewey Decimal System” used to
catalog and index books in a library. While the books may have unique identifiers such as the
International Standard Book Number, the library numbering system for categorizing and filing the books
is standard for all libraries. This same concept is used to integrate all process assets into a single catalog
which is used on the SSC Pacific PAL

3.5     OSSP RELATIONSHIPS
3.5.1    Systems of Processes
The definitions in this section explain the OSSP in terms of vertical and horizontal relationships. They
are summarized in Figure 3-3. Explanations in this and the following sections are key to understanding
the rationale for OSSP tailoring guidelines in Section 4.




                                     Figure 3-3. Systems of Processes
Quality Management Systems, reference (q), defines a system as a set of interrelated or interacting
elements, and defines a process as a system of activities which uses resources to transform inputs into
outputs. Reference (o) also notes that the inputs of processes are typically outputs of other processes.
Reference (a) defines a process element as a fundamental unit of a process. Reference (a) goes on to say
that a process can be defined in terms of sub-processes and/or process elements. A sub-process can be
further decomposed into (lower-level) sub-processes and/or process elements, but a process element
cannot be further decomposed. Reference (a) also describes an organizational defined process as a



                                                    16
                                                                                      SSC Pacific SPAA Definition
                                                                                                 DC-OPD-15 v1.0
                                                                                                         8/25/09


process that is tailored from the OSSP according to the organization’s tailoring guidelines (definition
summarized).
Using these definitions, this SPAA defines the SSC Pacific systems engineering process as the set of
fifty-five sub-processes listed in Table 3-1. Also, the fifty-five processes are defined as the
Organization’s Set of Standard Processes (OSSP). Therefore, the terms SSC Pacific OSSP, the SSC
Pacific’s defined systems engineering process are considered interchangeable terms.
Organizational units including departments and projects will define their systems engineering process by
selecting and tailoring SSC Pacific OSSP.
3.5.2   Sub-Process and Process Element Relationships
Two important characteristics of processes are that they are interactive, and numerous processes are
usually being performed simultaneously by various groups within a project. This dimension of
complexity often makes the consideration of individual processes in OSSP lists like Table 3-1 or
Appendix C misleading.
Just as systems should be considered in terms of systems-of-systems, processes should be considered in
terms of systems-of-processes. The SSC Pacific OSSP is a comprehensive set of processes formulated by
integrating all of the processes from the “primary” systems engineering standards and models described in
the policy and guidance documents listed in Section 3.2 and Table 3-1. This comprehensive set of
processes is meant to satisfy the needs of the entire organization including all categories of projects. The
most complex product development-type projects are likely to use most of the processes. All other types
of projects, such as integration projects, service projects, and acquisition/installation projects are likely to
use only selected portions of the OSSP set. These sub-sets are to be tailored from the SSC Pacific
standard set, and will reference that source.
All processes in the OSSP set and organizational unit sub-sets are related and interactive because the
outputs of processes are the inputs to one or more other processes as mentioned earlier. A systems view
or “big-picture” view of the defined set of processes is required as the activity of tailoring and
modification of processes is performed.
The process-related assets include reference assets and implementation assets. The relationship of
process-related assets related to specific OSSP processes is to be described in process description
documents.
3.5.3 Process Components and Relationships
As described in Figure 3-3, a process uses resources (tasks) to turn inputs into outputs. Components
considered critical in process descriptions include a purpose or objective, entry criteria and inputs, roles
related to the tasks, tasks or activity descriptions, outputs and exit criteria, measures, interface and related
assets. Figure 3-4 provides some additional detail on the process components and points out that the
outputs of one process are typically the inputs to other processes. The “horizontal interfaces” of
processes is related to this idea that the outputs of one process are typically the inputs to other processes.
There are at least three characteristic outputs of processes as listed below:
    a. Work products to be delivered to stakeholders.
    b. Inputs to one or more other processes.
    c. Outputs of one task within a process that are the inputs to another task within the process. These
       outputs can be the inputs to the same task of a process, but at a different stage of the
       product/project life cycle. This sometimes causes confusion when people wonder how the output




                                                     17
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09


          of a process can be an input to the same process. Again, the answer lies in the iterative and
          recursive nature of systems engineering.



                Critical Components                                Relationships & Interfaces
        The Purpose, Goal or Objectives
            •   Related to outputs needed to reduce
                project/product risk                                Purpose of outputs
        Inputs & Entrance Criteria                                  • Needed by stakeholders
            •   From requirements                                    • Input to other Processes or
            •   From reference assets or outputs of                    same process in later
                other processes                                        iteration
        Related Assets                                              • Input to other task or
            •   Reference assets (policy, standards,                   activity in same process
                guides, handbooks)
            •   Implementation assets (templates, forms,
                checklists, tools, etc.)
        Roles related to process activities
        Tasks, activities, or procedures
        Outputs and Exit Criteria
            •   Each task or activity has an output
        Product and Process Measures
            •   Inputs to M&A process and OMR
        Interfaces
            •   Where = Inputs, Related assets & Outputs


                       Figure 3-4. Critical Components of Standard Process Descriptions

This discussion leads to key points to remember during process tailoring including those listed below:
      a. Define required systems engineering outputs for any project stakeholder.
      b. Define interfaces between processes – are there any process outputs from a process being
         considered for deletion that produces the inputs to a process being considered for selection?
      c. Before modification of process tasks, consider if a task being deleted or modified produces the
         input to another task considered essential to satisfying process and project objectives.
      d. Process tasks explain what needs to be done while process implementation assets are how tasks
         are to be implemented. The how assets are prime candidates for tailoring.

3.6     DOCUMENTING PROCESSES
The value of identifying standardized contents and formats for process descriptions has been laid out in
reference (a), the Software Process Framework Handbook, reference (r), Defining Short and Usable
Processes, reference (s), and Software and Systems Engineering – Life Cycle Management – Guidelines
for Process Description, reference (t). Basically process format standardization promotes efficiency
because people know where process information is consistently located. The process documentation
framework shown in Figure 3-5 is an adaptation of the one in references (r) and (s). It shows the
relationships of documents relating to process definition. This framework was created to organize
information so that it is most usable and effective according to a basic set of principles, requirements, and
criteria extracted from reference (r).


                                                           18
                                                                                 SSC Pacific SPAA Definition
                                                                                            DC-OPD-15 v1.0
                                                                                                    8/25/09


3.6.1   Process Documentation Principles
    a. Separate information into usable parts: The operational framework separates information into
       usable parts used for different purposes. For example, detailed training information included with
       an organizational policy is irrelevant information (meaning either wasted time or masking the
       focus on policy).
    b. Identify and use only the relevant information for each part: Only relevant information needs to
       be in each part of the operational framework. For example, training information should only be
       in training documents, and policies should contain information that does not change frequently.
       By placing only relevant information in each part of the operational framework, people will learn
       where to look for information.
    c. Manage changes and improvements: Changes and improvements to the operational parts will be
       easier to manage because the information is well defined. For example, once defined, policies
       should not frequently change. Processes probably do not need to change if a step by step
       procedure changes. Training changes can be isolated to training documents. Only the necessary
       and important relationships between the operational parts need to be managed.
    d. Manage and improve communication: Communication improves because people know where to
       look for certain types of information, and they know the relationships between the information.
       Since the changes are isolated to the operational parts, less communication is needed and only the
       relevant changes need to be managed and communicated.




             Figure 3-5. Relationships of Process Assets Related to Documenting Processes




                                                 19
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


3.6.2    Process Documentation Requirements
The process documentation requirements in this section are summarized from references (p) - (s). Process
documents focus on what needs to be done and are to satisfy the requirements listed below:
    a. Process descriptions are to exhibit uniformity (standardization) to enable efficiency of use.
    b. Include the process “critical components” which address the five W’s (who, what, where, when,
       and why). Critical elements are outlined in Section 3.5.3.
    c. Include both pictures and words. Pictures include several types of diagrams (most people prefer
       pictures, but some people prefer words).
    d. Be “chunked” and labeled so that chunks can be found quickly. (Chunking means information
       should be grouped into small manageable units).
    e. Be relatively short. (Short means just enough information to summarize the source material for
       three levels of process users - Expert, Intermediate, and Beginner). This does not imply a page
       count limitation. A definition of each of the levels is listed below:
         1. Expert: Documentation includes just enough information for use by experts (people who have
            performed the process many times and just need a brief reminder. The expert level often
            includes only the critical components plus a picture (diagram).
         2. Intermediate: The intermediate level uses the expert level documentation, but builds and adds
            to it by providing a short explanation of the purpose or objective of activities along with some
            applicable guidance or lessons learned. There is no training or tutorial type information
            included in this level.
         3. Beginner: The beginner level is for people who are new to the process and need more detailed
            guidance and training. The beginner level uses intermediate level documentation, but adds
            training types of information to it. Beginners should feel free to use training materials and
            manuals until they become thoroughly familiar with the process.
    f.   Utilize a standardized set of formats and writing conventions. (standardization improves usability
         and efficiency)
3.6.3    Process Documentation Criteria
Process documentation criteria are a set of items that are considered critical, and must be included in a
process description for it to be effectively useable by people performing the process. The process
documentation criteria can be satisfied by answering the basic set of questions. Each basic question is
answered by an associated process element or component as shown in Table 3-3.
                        TABLE 3-3. PROCESS DOCUMENTATION CRITERIA
     This process
                                                 Answers this basic question
      component
   Purpose              Why is the process performed?
   Input                What work products are used?
   Entry Criteria       When (under what circumstances) can the process begin?
   Output               What work products are produced?
   Exit Criteria        When (under what circumstances) can the process be considered complete?
   Role                 Who (or what) performs the activity?
   Activity             What is done?
   Procedure            How are activities implemented



                                                   20
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


Other information that may be considered useful in process descriptions can include: institutionalization,
reviews and audits, products to be placed under configuration management, training, and implementation
assets. These other information “process components” are considered optional (non-critical) in SSC
Pacific process documents.
3.6.4     Procedure Documentation Requirements
A procedure is a detailed specified way to carry out an activity or process according to reference (q). A
procedure contains how-to, step-by-step information, and comes with three or four types of
implementation assets such as forms, checklists, step/action tables, and tools for automating procedure
activities. Implementation of procedure documentation is described in reference (g). Three of the
implementation assets are listed below:
      a. Step/Action Tables are an effective way to represent step sequence, task performer (role), and a
         detailed description of the action.
      b. Forms along with instructions for completing the forms are powerful repeatable mechanisms for
         collecting data showing that processes or procedures have been completed.
      c. Checklists are also powerful representations of completing process or procedure activities.
         Checklists add the flexibility of performing steps in more than one order or sequence.

3.7     ROLL-OUT OF STANDARD PROCESSES
SSC Pacific-level processes are peer reviewed using the process described in the Peer Review Process for
SSC Pacific, reference (u), and placed under configuration control using the process described in the
Systems Engineering Process Office Configuration Management Procedure, reference (v). The processes
are then placed on the SSC Pacific Process Asset library (PAL) as described in the PAL Update
Procedure, reference (w). Department SPI agents are then notified that a change in OSSP has occurred.
Notification is by e-mail and an announcement at periodic SPI Agent meetings.
Roll-out of department standard processes is to follow a similar set of activities as described in the
department level equivalent of this document.




                                                   21
                                                                                       SSC Pacific SPAA Definition
                                                                                                  DC-OPD-15 v1.0
                                                                                                          8/25/09




                        SECTION 4. OSSP TAILORING GUIDELINES

4.1        OSSP TAILORING OBJECTIVES AND REQUIREMENTS
The objective of this section is to establish tailoring criteria and guidelines for the SSC Pacific OSSP.
Process tailoring is defined in reference (a) as making, altering or adapting a process description for a
particular end. Tailoring scales the rigorous application of the processes to an appropriate level based on
the needs and life cycle stages of projects (Systems Engineering Handbook, reference (x)). The purpose
of tailoring the OSSP for a specific project is to ensure that enough systems engineering effort is devoted
to appropriate process activities to reduce risk to an acceptable level while at the same time making cost-
effective use of project/engineering resources. The idea is to strike a balance between enough flexibility
to accommodate project context differences and enough standardization and consistency to yield the
associated benefits and organizational efficiencies.
Requirements are listed below:
      a. Describe how the OSSP and related process assets are used to create the defined process of
         organizational units including projects.
      b. Describe the sub-set of organizational processes and related process assets that are essential for
         the defined processes of any organizational unit including projects.
      c. Describe procedures that must be followed in performing and documenting the tailoring of
         organizational processes.
      d. Describe options applicable to organizational units and projects and criteria applicable to the
         options.
      e. Describe how organizational units tailor life cycle models. Note that this description is in Section
         2.5.
      f.    Avoid the “tailoring traps” described in reference (x) and summarized below:
            1. Reuse of a tailored baseline from another project without repeating the tailoring process. It is
               fallacious to assume that previously-tailored baselines are appropriate for all projects. Prior
               successes are not a guarantee of future success. There is something unique in each project.
            2. Using all processes and activities, “just to be safe”. The trap is that the each process carries
               an overhead cost. If this approach is taken, the quality of the product may actually degrade
               because of application of an inappropriate process. It can not be called tailoring if there is not
               a clear justification for the inclusion of every process in the plan.
            3. Using a pre-established tailored baseline. Enterprise shortcuts to create templates of
               baselines that can be taken off the shelf and applied to work based on arbitrary
               categorizations such as high, medium, and low risk projects can be counter-productive. They
               carry the same hazards as traps #1 and #2 above. Tailoring is important because the emphasis
               is placed on the project and products and only processes that support attainment of the
               objective in terms of quality and performance should be retained.
            4. Failure to include relevant stakeholders. The tailoring process itself can become a unifying
               activity that establishes shared visions and understanding of the objectives.




                                                       22
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09


4.2     THE OSSP AND DEFINED PROCESSES OF ORGANIZATIONAL UNITS
The OSSP is the defined set of standard processes for SSC Pacific. Departments may establish a
Departmental Set of Standard Processes (DSSP) which is the defined sub-set of the OSSP which satisfies
all projects within the business domains of the department. Most departments are made up of projects
from more than one of the project types even though the department may focus on one business domain.
The standard project types for purposes of standard sub-set definition are listed below:
      a. Development: The primary tasking of projects in this category requires the design, development,
         testing, production, installation, and life cycle support of a new system for the fleet.
      b. Acquisition: The primary tasking of projects in this category requires the establishment of
         contracts to buy materials to be delivered and/or installed by other projects or customers.
      c. Integration: The primary tasking of projects in this category requires the integration of
         Commercial-Off-The-Shelf (COTS) and Non-Developmental Items (NDI) into an integrated
         system or sub-system. The tasking may also include design of interfaces for the COTS/NDI
         components and integration testing.
      d. Services: The primary tasking of projects in this category is to provide a specific service or set of
         services to another project or to the Fleet. Examples of services can include performing a study
         or experiment, establishing a laboratory and performing product testing, establishing a help desk
         to answer technical questions from system users and other customers, performing as the In-
         Service Engineering Agent (ISEA) to monitor installed system performance and provide technical
         support to Fleet customers. Also included in this category is the assembly or production of
         systems to be installed in ship or shore sites, and the actual installation of the systems or
         equipments. Also included in the ISEA set of services is the configuration management functions
         for in-service systems. Some of the engineering changes become development project in scope.
The key element in defining a project in any domain category is the Primary Tasking. Projects of one
project type regularly task other projects of another project type for specific products and services.
Departments often have various numbers of projects in several types.

4.3     THE ESSENTIAL SUB-SET OF PROCESSES
Each organizational unit and each project is expected to select and tailor processes from the OSSP or
DSSP based on two factors: 1) How much engineering, and therefore how much of the OSSP is enough to
control the risk associated with system, products and services, and 2) The funding condition of the
project. Balancing these two factors is addressed in the Process Tailoring Process, reference (y).
There are three groupings of the OSSP with respect to essentiality. These groupings are different from
the four categories mentioned in Section 3.4.
      a. Group 1 includes the core processes that are expected to apply to all projects regardless of the
         project type. These may change as organizational needs change, so the list is defined in the
         reference (g). The processes listed below are expected to be in Group 1:
          1. Project Initiation
          2. Project Planning/Documentation
          3. Requirements Management
          4. Project Monitoring and Control
          5. Measurement and Analysis
          6. Senior Management Project Reviews


                                                    23
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09


          7. Process Tailoring Process
          8. Quality Assurance
          9. Configuration Management
          10. Project Closeout
      b. Group 2 includes the additional essential processes that are expected to apply to specific project
         types. Refer to the reference (g), for current specific processes by project type. These essential
         sub-sets are listed below:
          1. Services Projects:
          a)      Core Processes
          b)      Assigned additional processes
          c)     Optional additional processes
          2. Integration Projects:
          a)      Core Processes
          b)      Assigned additional processes
          c)      Optional additional processes
          3. Acquisition Projects:
          a)      Core Processes
          b)      Assigned additional processes
          c)    Optional additional processes
          4. Development Projects:
          a)      Core Processes
          b)      Assigned additional processes
          c)      Optional additional processes
      c. Group 3 includes the additional essential processes that are expected to apply at the SSC Pacific
         and Department level, but not the project level. The SSC Pacific OSSP and departments DSSPs
         are to contain all of the processes necessary to serve the needs of all of the projects in the
         department. In addition, each DSSP is to contain at least three of the OSSP process management
         processes as listed below:
          1. Organizational Process Definition
          2. Organizational Process Focus
          3. Organizational Training

4.4     DEPARTMENT AND PROJECT TAILORING ACTIVITIES
Two levels of tailoring activities apply to departments and projects. The first is called the Macro Level
where processes are selected from the appropriate set of standard processes and the second is called the
Micro Level where components of processes are modified. The activities are listed in Figure 4-1 and
described more fully in reference (g).
Process tailoring at the Macro Level is supported by the Process Implementation Strategy Planning
Process, reference (z) and tailoring activities at the Micro Level is supported by reference (y).
Implementation of these processes is discussed in the reference (g).


                                                   24
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09



                          Macro Level – Select Applicable Processes
                          Departments:
                             • Identify Department Project Types – Department Profile
                             • Identify OSSP processes included in DSSP
                             • Select or create process implementation assets
                             • Prepare process declaration and deviation request forms as applicable

                          Projects:
                             • Identify Project Type – Project Profile
                             • Identify OSSP or DSSP processes included in project defined process
                             • Select or create process implementation assets
                             • Prepare process declaration and deviation request forms as applicable




                          Micro Level – Modify Process Components
                          Departments:
                             • Identify process outputs needed by Project Types in the Department
                             • Identify needs for modification of process components
                             • Modify process components if applicable to all project types and other criteria
                             • Select or create process implementation assets

                          Projects:
                             • Identify process outputs needed by Project
                             • Identify needs for modification of process components based on type and
                               other criteria (size, risk and resource constraints)
                             • Modify process components if applicable to project
                             • Select or create process implementation assets




Figure 4-1. Department and Project Tailoring Activities




                        25
                                                                                     SSC Pacific SPAA Definition
                                                                                                DC-OPD-15 v1.0
                                                                                                        8/25/09



4.5     DOCUMENTATION OF OSSP TAILORING
Five forms or spreadsheets are used to document process tailoring by departments and projects. The five
forms are listed below:
      a. The Department Business Domain Description – Used to describe the primary business domain of
         the department and the current set of domain category projects within the department, which
         provides the rationale for which sub-set of the OSSP is to be included in a DSSP, if a DSSP is
         applicable.
      b. The Project Type/Profile Description – Used to describe project characteristics which provide the
         rationale for domain categorization and therefore process tailoring.
      c. The Department Process Tailoring Declaration Form – Used to document the department’s
         selection and/or modification of OSSP.
      d. The Project Process Tailoring Declaration Form – Used to document the project’s selection
         and/or modification of standard processes as they use reference (y).
      e. The Deviation Request/Approval Form – Used to document the request and approval of
         deviations from tailoring guidelines.
The forms and related templates are included in reference (g).

4.6     OPTIONS AND CRITERIA
Options for considering the needs of individual projects will be offered in addition to the options
described above. The application of reference (y) by individual projects may result in deviations from use
of standard sub-sets of the OSSP. These options are expected and require the use of the deviation request.
The criteria for considering these additional options include the project risk-related characteristics
included on the project type/profile form such as those listed below:
      a. Project size in terms of planned funding over the life of the project
      b. Project size in terms of government and contractor staff-hours per year
      c. The project type/domain category
      d. Project designation as a CMMI candidate, and project maturity level goal.
Refer to reference (g) for additional discussion.




                                                    26
                                                                                    SSC Pacific SPAA Definition
                                                                                               DC-OPD-15 v1.0
                                                                                                       8/25/09




      SECTION 5. ORGANIZATION’S MEASUREMENT REPOSITORIES

5.1     OMR OBJECTIVES AND REQUIREMENTS
The objective is to share measurement data. The SSC Pacific Organization’s Measurement Repository
(OMR) contains both product and process measures that are related to the OSSP. The OMR also contains
documentation needed to understand and interpret the measures and assess them for reasonableness and
applicability.
Requirements for an OMR are listed below:
      a. Definition of the organization’s needs for storing and retrieving measurement information.
      b. Definition of a common set of product and process-related measures.
      c. An operational OMR with content available for use by organizational units and projects.
      d. Procedures for maintenance and revision of the OMR and an improved set of measures as
         organizational needs change.

5.2     REPOSITORY ALLOCATION
The OMR is used to collect and make available measurement data on processes and work products that
may in turn be used to estimate the cost and effort of future work. The OMR contains or references actual
measurement data and related information needed to understand and analyze the measurement data.
For information and guidance on activities in the measurement process in general, refer to the SSC Pacific
Organizational Measurement Guide (OMG), reference (aa).
Several levels of interacting repositories are available. An example of this is illustrated in Figure 5-1. At
the SSC Pacific-level, shown as “Center” level, the OMR is a virtual repository, meaning it is a set of
repositories residing on more than one network server. OMR implementation information is located in
references (g) and (aa).




                                                   27
                                                                             SSC Pacific SPAA Definition
                                                                                        DC-OPD-15 v1.0
                                                                                                8/25/09




                            SSC Pacific
                          Mission & Vision,
                         Goals & Objectives


                                                              SSC Pacific
                                                             Goals Derived
       Center                    SSC Pacific                   Measures
                                Measurement
                                 Repository




  Organizational Unit
                                              Organization                       Measurement,
    (Departments)       Decomposed                                             Analysis, Reviews,
                                               Repository
                        SSC Pacific                                           Process Improvement
                         Measures                                                  Proposals,
                                                                                Lessons Learned,
                                                                                 & Roll Up Data



                           Decomposed                 Organization
Organizational Units       Organization               Repositories
    (Projects)              Measures




                   Figure 5-1. Example Measurement Repository Hierarchy




                                                28
                                                                                      SSC Pacific SPAA Definition
                                                                                                 DC-OPD-15 v1.0
                                                                                                         8/25/09




                         SECTION 6. PROCESS ASSET LIBRARIES

6.1        PAL OBJECTIVES AND REQUIREMENTS
The objective is to share process assets. SSC Pacific has designed, deployed, and maintained a Process
Asset Library (PAL) for well over ten years where process assets and process-related assets are easy to
locate, use and share. The PAL is a library of processes and process-related assets such as policies,
standards, reference materials, training materials, templates, forms, checklists, tools and lessons-learned
documentation.
Requirements for the PAL are listed below:
      a. Design and implement the PAL.
      b. Specify the criteria for including items in the library.
      c. Specify procedures for storing and retrieving PAL assets.
      d. Develop an indexing and cataloging schema for easy location, reference and retrieval of PAL
         assets.
      e. Enter selected assets into the PAL.
      f.    Make PAL assets easily accessible to organizational units to include projects.
      g. Perform periodic reviews of PAL item use to identify improvement opportunities.
      h. Revise the PAL as necessary.
The information in the PAL is considered a key resource for helping SSC Pacific organizations, or the
organization’s administrative entities, reduce the amount of effort necessary to initiate a new project and
educate both management teams and technical staffs in the skills necessary to make a project successful.
These resources are intended to be a focal point for best practices and process improvement knowledge
and training across SSC Pacific.

6.2        ORGANIZATIONAL PROCESS ASSET LIBRARY RELATIONSHIPS
Several libraries of SSC Pacific and organization-level process assets are maintained by SEPO and
organizational units within SSC Pacific as shown in Figure 6-1. These resources are used by projects to
produce consistently high quality products and services, and by SSC Pacific to establish an environment
of continuous process improvement.
PAL implementation is located in reference (g).




                                                      29
                                                                 SSC Pacific SPAA Definition
                                                                            DC-OPD-15 v1.0
                                                                                    8/25/09




                         SSC Pacific
                       Mission & Vision,
                      Goals & Objectives




                                  SSC Pacific
    Center                 Process Asset Library (PAL)




                     Tailored              Org X.                   Lessons Learned
  Organization                              PAL
                     From Center                                         & PAL
                     Assets                                          Contributions




                                                     Defined
                          Tailored                  (Tailored)
Intra-Organization        From Org                  Processes
   Work Efforts           Assets




                            Figure 6-1. PAL Relationships




                                           30
                                                                                   SSC Pacific SPAA Definition
                                                                                              DC-OPD-15 v1.0
                                                                                                      8/25/09




                 SECTION 7. WORK ENVIRONMENT STANDARDS

7.1     WORK ENVIRONMENT STANDARDS OBJECTIVES AND REQUIREMENTS
The objective of establishing and maintaining work environment standards is to allow the organization
and projects to benefit from enterprise resources and services. A common approach and sharing of
workplace standard items is expected to be focused on safety, productivity and cost optimization.
Requirements for the establishment of work environment standards are listed below:
      a. Gather information on existing work environment standards
      b. Implement appropriate work environment standards that balance efficiency and cost
      c. Evaluate commercial standards for adoption by the organization
      d. Recommend or develop new standards based on evolving organizational needs.
Key activities related to work environment standards are listed below:
      a. Evaluate SSC Pacific and commercially-available work environment standards appropriate for the
         organization.
      b. Adopt existing work environment standards and develop new ones to fill any gaps based on the
         needs and objectives of the organization.
      c. Make provisions for projects to tailor or obtain deviations from standards-based work
         environment requirements where justified by specific project needs.

7.2     PURPOSE OF STANDARDS FOR THE WORK ENVIRONMENT
Reference (q) defines the work environment simply as “a set of conditions under which a person operates
[or works]”. Standard-related information is listed below:
      a. A standard is an established, consistent guideline that defines expectations and acceptable
         performance.
      b. The work environment standards are intended to allow organizational elements, including
         projects to benefit from standardized enterprise resources and services to include such items as
         common facilities, laboratories, tools, training, information technology resources, along with
         standard guidance on such topics as safety, and security.
      c. An important objective of a standards-based work environment is to reap cost savings of shared
         resources, economies of volume purchases, and compliance with public law and policy on
         specific areas as security, safety, and environmental concerns.
      d. Work environment standards should address the needs of all stakeholders and consider such
         issues as productivity, cost, availability, security, workplace health, safety, and ergonomic
         factors.
      e. Examples of work environment standardization areas are listed below:
          1. Standard operating procedures for operation, safety, and security of the work environment
          2. Standard workplace computer hardware and software
          3. Standard software applications



                                                   31
                                                                                SSC Pacific SPAA Definition
                                                                                           DC-OPD-15 v1.0
                                                                                                   8/25/09


       4. Standard equipment in production facilities, and laboratories to include calibration standards
       5. Office equipment and supplies
       6. Communication tools, facilities, and resources
       7. Support staff and/or resources.
Work environment standards implementation is located in reference (g).




                                                32
                                                                   SSC Pacific SPAA Definition
                                                                              DC-OPD-15 v1.0
                                                                                  Appendix A
                                                                                      8/25/09



         APPENDIX A. ABBREVIATIONS AND ACRONYMS

CM         Configuration Management
CMMI       Capability Maturity Model Integration
COTS       Commercial Off-The-Shelf
C4ISR      Command, Control, Communication, Computers, Intelligence, Surveillance and
           Reconnaissance
DAR        Decision Analysis and Resolution
DCR        Document Change Request
DEV        Development
DoD        Department of Defense
DODI       Department of Defense Instruction
DSSP       Department Set of Standard Processes
EIA        Electronics Industries Association/Alliance
IEC        International Electro-technical Commission
IEEE       Institute of Electrical and Electronic Engineers
INCOSE     International Council on Systems Engineering
IPM        Integrated Project Management
IPPD       Integrated Product and Process Development
ISEA       In-Service Engineering Agent
ISO        International Organization for Standardization
NDI        Non-Developmental Item
NSEG       Naval Systems Engineering Guide
OID        Organizational Innovation and Deployment
OMG        Organizational Measurement Guide
OMR        Organization Measurement Repository
OPD        Organizational Process Definition
OPF        Organizational Process Focus
OPP        Organizational Process Performance
OSSP       Organizational Set of Standard Processes
OT         Organizational Training
PAL        Process Asset Library
PMBOK      Program Management Body of Knowledge
PMG        Project Management Guide
RD         Requirements Development
REQM       Requirements Management
RM         Requirements Management
RSKM       Risk Management
SAM        Supplier Agreement Management


                                     A-1
                                                   SSC Pacific SPAA Definition
                                                              DC-OPD-15 v1.0
                                                                  Appendix A
                                                                      8/25/09

SE       Systems Engineering
SEI      Software Engineering Institute
SEM      Systems/Software Engineering Management
SEPO     Systems Engineering Process Office
SPAA     Standard Process Asset Architecture
SPAWAR   Space and Naval Warfare
SSC      SPAWAR Systems Center




                                  A-2
                                                                              SSC Pacific SPAA Definition
                                                                                         DC-OPD-15 v1.0
                                                                                             Appendix B
                                                                                                 8/25/09



                              APPENDIX B. REFERENCES

The documents listed below are references critical to the content of this document:
a. Capability Maturity Model Integration for Development, V1.2, Carnegie Mellon University
    (CMU)/Software Engineering Institute (SEI)-2006-TR-008, ESC-TR-2006-008, Aug 2006
b. Systems Engineering – System life cycle processes, International Organization for Standardization
    (ISO)/International Electrotechnical Commission (IEC) 15288, ISO/IEC 15288, Feb 2008
c. A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management
    Institute
d. SSC San Diego Project Management Guide, PR-OPD-29, SSC San Diego
e. Operation of the Defense Acquisition System, DODI 5000.2, Dec 2008
f. Software Life Cycle Processes, Institute of Electrical and Electronics Engineers (IEEE)/Electronic
    Industries Association (EIA) 12207, Feb 2008
g. SSC Pacific SPAA Implementation Handbook, DC-OPD-16, SSC Pacific
h. Processes For Engineering a System, Electronic Industries Alliance, EIA 632, Jan 1999
i. Management of the Systems Engineering Process, Institute Of Electronics and Electronics Engineers,
    IEEE-1220, Dec 1998
j. Defense Acquisition Guidebook, Version 1.6, Jul 2006
k. Systems/Software Engineering Management Policy, SSC San Diego Instruction 5234.2, SSC San
    Diego, Jun 2006
l. Naval Systems Engineering Guide (NSEG), Naval Systems Engineering Steering Group (SESG), Oct
    2004
m. Systems and Software Engineering Policy, SPAWARINST 5400, Draft, Jun 2008
n. DoD Architecture Framework, V1.5, Apr 2007
o. C4ISR Architecture Framework, V2.0, Dec 1997
p. Process Architecture: The key to Systematic Process Tailoring and Reuse on Systems Engineering
    Projects, Manary and Madni, Jun 2006
q. Quality Management Systems-Fundamentals and Vocabulary, ISO 9000-2000, Apr 2000
r. Software Process Framework Handbook, CMU/SEI-94-HB-01. Sep 1994
s. Defining Short and Usable Processes, Timothy G. Olson, CrossTalk Journal, Jun 2006
t. Software and Systems Engineering – Life Cycle Management-Guidelines for Process Description,
    ISO/IEC TR 24774, Sep 2007
u. Peer Review Process for SSC Pacific, PR-VER-01, SSC Pacific
v. Systems Engineering Process Office Configuration Management Procedure, PR-OPD-32, SSC San
    Diego
w. PAL Update Procedure, PR-OPD-52, SSC Pacific
x. INCOSE Systems Engineering Handbook, Jul 2000
y. Process Tailoring Process, PR-PP-03, SSC Pacific
z. Process Implementation Strategy Process, PR-PP-05, SSC Pacific
aa. SSC Pacific Organizational Measurement Guide (OMG), PR-QPM-02, SSC Pacific




                                               B-1
                                                                                SSC Pacific SPAA Definition
                                                                                           DC-OPD-15 v1.0
                                                                                               Appendix C
                                                                                                   8/25/09



APPENDIX C. SSC PACIFIC STANDARD PROCESS ASSETS CATALOG

Table C-1 is the format for the SSC Pacific Standard Process Assets Catalog which includes processes,
forms, checklists, guides, and templates, etc. using the numbering system shown in Figure 2-2. The
version of this catalog on the SSC Pacific PAL includes hyperlinks to the actual asset.
               TABLE C-1. SSC PACIFIC STANDARD PROCESS ASSET CATALOG
 Index #                   Document Title               Configuration                          Status
                                                        Identification

1.1.0        Strategic Focus
PR 1.1.1
PR 1.1.2
1.2.0        Process innovation
PR 1.2.1
PR 1.2.2
1.3.0        Process definition
PR 1.3.1
PR 1.3.2
1.4.0        Process Improvement
PR 1.4.1
PR 1.4.2
1.5.0        Quality Assurance
PR 1.5.1
PR 1.5.2
1.6.0        Integrated Teams
PR 1.6.1
PR 1.6.2
1.7.0        Performance Measurement & Analysis
PR 1.7.1
PR 1.7.2
1.8.0        Project Oversight & Control
PR 1.8.1
PR 1.8.2
2.1.0        Requirements Analysis & Proposal
PR 2.1.1
PR 2.1.2
2.2.0        Analysis
PR 2.2.1
PR 2.2.2
2.3.0        Project planning
PR 2.3.1
PR 2.3.2
2.4.0        Design
PR 2.4.1
PR 2.4.2
2.5.0        Production


                                                C-1
                                                                   SSC Pacific SPAA Definition
                                                                              DC-OPD-15 v1.0
                                                                                  Appendix C
                                                                                      8/25/09

 Index #                      Document Title              Configuration           Status
                                                          Identification
PR 2.5.1
PR 2.5.2
2.6.0      Verification
PR 2.6.1
PR 2.6.2
2.7.0      Operations
PR 2.7.1
PR 2.7.2
2.8.0      Support
PR 2.8.1
PR 2.8.2
2.9.0      Retirement
PR 2.9.1
PR 2.9.2
3.1.0      Configuration Management
PR 3.1.1
PR 3.1.2
3.2.0      Risk Management
PR 3.2.1
PR 3.2.2
3.3.0      Decision Support
PR 3.3.1
PR 3.3.2
3.4.0      Management - Other
PR 3.4.1
PR 3.4.2
3.5.0      Contract Management
PR 3.5.1
PR 3.5.2
3.6.0      Material Procurement
PR 3.6.1
PR 3.6.2
3.7.0      Information Management
PR 3.7.1
PR 3.7.2
3.8.0      Training
PR 3.8.1
PR 3.8.2
POL        Policy Documents
POL 01
POL 02
GD         Guide books, standards, references and plans
GD 001
GD 002
CL         Checklists
CL 001


                                               C-2
                                                       SSC Pacific SPAA Definition
                                                                  DC-OPD-15 v1.0
                                                                      Appendix C
                                                                          8/25/09

 Index #               Document Title         Configuration           Status
                                              Identification
CL 002
FM         Forms
FM 001
FM 002
TM         Templates
TM 001
TM 002
LX         Lexicons
LX 1.0.1
LX 1.0.2




                                        C-3
                             DOCUMENT CHANGE REQUEST (DCR)
Document Title: SSC Pacific Standard Process Assets Architecture              Tracking Number:
Definition

Name of Submitting Organization:


Organization Contact:                                                         Phone:


Mailing Address:


DCR Description:                                                              Date:


Change Location:
(use section #, figure #, table #, etc.)
Proposed change:




Rationale for Change:




Note: For the Systems Engineering Process Office (SEPO) to take appropriate action on a change request, please
provide a clear description of the recommended change along with supporting rationale.
Send to: Commanding Officer, Space and Naval Warfare Systems Center, Code 842, 53560 Hull Street, San
Diego, CA 92152-5001
Fax: (619) 553-6249
Email: sepo@spawar.navy.mil
Submit online: http://sepo.spawar.navy.mil/
                                                                                        DCR Form 8/2009