SM-21 - ORGANIZATION PROCESS FOCUS AND DEFINITION POLICY - D R A F T
Purpose. This Financial Systems Organization (FSO) Process Focus and Definition policy establishes organizational responsibility for software process activities that improve the FSO’s overall software process capability. This policy also identifies the following scenarios as the FSO’s standard software processes: System Development Scenario (for development), System Modification Scenario (for modification), System Operations Scenario (for emergency modification), and Software Subcontract Management Scenario (for subcontract management).
Scope. The FSO is defined as FSO Headquarters and all Financial Systems Activities and Directorates for Software Engineering. This policy applies to all components of the organization engaged in software development, modification, or maintenance.
Goals.
1. Continuous software process improvement is supported by a cost-effective infrastructure.
2. A tailorable standard software process which improves effectiveness and efficiency in delivery of software services is established and maintained.
3. A process asset library which promotes sharing and reuse of process assets is established and maintained.
4. A software process metrics database which collects and makes available data on the software processes and resulting software work products is established and maintained.
Policy Statements.
1. FSO Headquarters (HQ) shall establish and support a Corporate Software Engineering Process Group (SEPG). This group shall have responsibility for:
a. Developing and maintaining the organization’s standard software processes based on required changes forcompliance with DOD and DFAS policy, to support other FSO policies and standards, to support new technology, and to incorporate improvements recommended by FSAs/DSEs and AIS Managers. Attachment 2 to this policy outlines procedures for developing and maintaining these standard processes. The primary purposes of a standard software process are to maximize the sharing of process assets and experiences across the projects and to provide the ability to define and aggregate a standard set of process measurements from the projects.
b. Maintaining a process asset library (PAL) which will contain the standard software processes and a usable set of software process assets which improve process performance, improve software products delivered to customers, and provide a basis for cumulative, long-term benefits to the organization. Attachment 3 contains procedures for developing and maintaining the PAL.
c. Maintaining and reviewing a software process database of measurement data and related information. Data shall be provided from project and FSA/DSE levels and the database shall be available at all levels for those who have a need to enter, change, review, analyze, and extract data. This data shall be reviewed by all appropriate levels of management to ensure its integrity.
d. Coordinating software process improvement activities with individual FSAs/DSEs.
e. Developing and maintaining an organizational training program plan. This plan shall contain skills and knowledge needed for each software management and technical role and the vehicles for obtaining these skills and knowledges. The organizational training plan shall contain requirements identified for all FSAs/DSEs and projects.
2. FSO HQ software quality assurance personnel shall be responsible for reviewing and/or auditing the organization’s activities and work products for developing and maintaining the organization’s standard software process and related process assets and reporting the results to FSO management personnel.
3. The Director, Systems Management at FSO HQ shall oversee development, maintenance and publication of the standard software processes and related process assets. In addition, the Director, Systems Management shall review and approve AIS’s defined software processes, which are tailored versions of the standard software process, for the project’s use and for inclusion in the organization’s PAL. As necessary, the Director, Systems Management shall establish additional work groups to address specific requirements.
4. Each FSA/DSE shall establish a local SEPG capability to coordinate process improvement activities with individual AISs. Each SEPG resource shall be assigned to one or more AISs.
5. FSA/DSE Directors and AIS Managers shall be responsible for tailoring the standard software processes to meet unique customer, development, and execution environment requirements. The tailored processes must be documented in accordance with the process definition standard (see Attachment 4) and tailoring guidelines (see Attachment 5). FSA/DSE Directors shall submit tailored processes to FSO HQ for review and approval.
6. FSA/DSE Directors and AIS Managers shall be responsible for ensuring that these approved tailored processes are implemented. The project’s approved defined software processes, as well as its tools, methods, templates, process and product measurements, lessons learned, and any other useful process-related information shall be provided to the Corporate SEPG who shall make them available to other projects through the PAL. The Corporate SEPG shall review the collected information for possible improvement to the scenarios.
7. FSA/DSE Directors and AIS Managers shall be responsible for capturing applicable SPI measurement data in the appropriate software process database. This data shall be used for planning and managing software projects.
8. FSA/DSE Directors shall develop an FSA/DSE Training Program Plan which outlines training needed to achieve required skills and knowledges for their site. AIS Managers shall develop a project training plan and submit it the their FSA/DSE Director for consolidation into the FSA/DSE training plan. The FSA/DSE Training Program Plan shall be submitted to FSO HQ for inclusion in the FSO Training Program Plan.
9. A CMM appraisal process has been established by FSO HQ and is incorporated into FSO Policy SM-08, Software Process Improvement Strategic Action Plan. FSA/DSE Directors shall schedule and conduct appraisals in accordance with the appraisal strategy. AISs, in coordination with their FSA/DSE Directors, shall prepare action plans for future improvement based on these appraisals. These action plans shall be submitted to FSO HQ for tracking improvement progress and planning CMM appraisals.
10. A Corporate Steering Committee (CSC) shall exist consisting of the Director of Systems Management, FSA Directors, Directors for Software Engineering, and the Chairman of the SPI Work Team. The CSC provides management guidance for the SPI program and advises the FSO Director in SPI organizational matters. The CSC will review and recommend approval for changes to the standard software processes.
11.The SPI Work Team, composed of a member from each FSA/DSE and a representative from the Corporate SEPG, shall provide recommended actions and priorities to the Corporate SEPG and the Corporate Steering Committee for consideration and approval. The SPI Work Team shall facilitate the communication and sharing of information on each project’s process, method, and tools. The SPI Work Team shall be responsible for coordinating corporate software process improvement activities at their FSA/DSE and with their projects.
12. Roles and responsibilities are further detailed in FSO Policy SM-08.
13. As necessary, the Director, Systems Management shall establish additional work groups to address specific requirements.
References.
1. SEI Capability Maturity Model
2. DFAS FSO Policy SM-08, Software Process Improvement Strategic Action Plan
3. DFAS 8000.1-R, Part E, Chapter 6, Software Process Improvement
4. Corporate Software Engineering Process Group Charter
5. Corporate Steering Committee Charter
6. FSO SPI Work Team Charter
7. FSO Measurement Guide (TO BE DEVELOPED)
8. FSO Training Program Plan (TO BE DEVELOPED)
Point of Contact.The Director, Systems Management and members of the Corporate SEPG may be contacted regarding this policy. They may be reached at DSN 699-5927 or commercial 317-510-5927.
5 Attachments
1. SPI Organization Structure (no longer valid)
2. Procedures for Development and Maintenance of FSO’s Standard Software
Processes (revised - see Procedures)
3. Procedures for Process Asset Library Maintenance (revised - see
PAL Procedure)
4. FSO’s Standard Software Process Definition Standard (see Definition
Standards)
5. FSO’s Standard Software Process Tailoring Guidelines
(revised - see Tailoring
Process)
NO LONGER A VALID STRUCTURE
These procedures have been revised - see Procedures
PROCEDURES FOR DEVELOPMENT AND MAINTENANCE OF
FINANCIAL SYSTEMS ORGANIZATION’S
STANDARD SOFTWARE PROCESS FOR MODIFICATION
The Financial Systems Organization’s (FSO’s) standard software processes are developed and maintained by the Corporate Software Engineering Process Group (SEPG) in coordination with any virtual teams which may be chartered to assist in this definition and modification. These standard software processes, or life cycles, contain tasks that satisfy the Software Engineering Institute’s Capability Maturity Model (CMM) key process areas (KPAs). The scenarios that are currently included in the FSO’s standard software processes are the System Development Scenario (or development life cycle), the System Modification Scenario (or life cycle for modification/maintenance), the System Operations Scenario (which currently addresses emergency system modification), and the Software Subcontract Management Scenario (which deals with managing subcontracts). Scenarios shall be developed and maintained in accordance with the Standard Software Process Definition Standard (see Attachment 4). A standard software process glossary shall also be developed and maintained to clarify terminology used within the scenarios. Once a scenario is defined, it will be reviewed by the Corporate Steering Committee (CSC) for approval. When the scenario is approved, FSAs/DSEs are notified that it is being released for implementation (in electronic (email or internet) or hard copy form). Problems or proposed changes identified by project or other FSA/DSE personnel will be submitted to their FSA/DSE Director for review. FSA/DSE Directors will submit these proposals to the Corporate SEPG for consolidation. If necessary, these changes may require a crosswalk to the common features of the CMM to verify compliance. On a periodic basis, the proposed changes are presented to the CSC for review. The CSC will prioritize and approve changes for incorporation into the applicable scenario(s). The Corporate SEPG will make the approved changes and release the revised scenario(s) for implementation. When a new release of a scenario is approved, FSAs/DSEs are notified of the changes that have been made and that it is available for implementation (in electronic (email or internet) or hard copy form).
These procedures have been revised - see PAL Procedure
PROCEDURES FOR DEVELOPMENT AND MAINTENANCE OF
FINANCIAL SYSTEMS ORGANIZATION’S
PROCESS ASSET LIBRARY
The Financial Systems Organization’s (FSO’s) Process Asset Library will be maintained in several parts. The corporate level information will be maintained by the Corporate Software Engineering Process Group (SEPG) and will be updated periodically as required. At a minimum, the Corporate PAL will contain key process area information for all levels of the CMM, the organization's standard software processes, policies, procedures and guidelines for standard tools and requirements, and periodic newsletters. A designated representative at each Financial Systems Activity will maintain a PAL segment containing site- and project-specific information which will be available through the Corporate PAL. At a minimum, the FSA PAL shall contain each project's tailored software process, its defined software process, and its artifacts. Additional FSA and project specific information may be stored, as well, for easy reference. All segments of the PAL will follow the standard style for the FSO Infoweb. The standard header will use the server side include (SSI) file i&thdr.txt. The standard FSO Infoweb information includes links back to the Top of the Page, the FSO Infoweb home page, the FSO Systems page and the Corporate PAL home page. Additional links may be added for a site, as appropriate.
Problems or proposed changes identified by project or other FSA/DSE personnel will be submitted to their FSA/DSE Director for review. FSA/DSE Directors will submit these proposals to the Corporate SEPG for consolidation. On a periodic basis, the proposed changes are presented to the CSC for review. The CSC will prioritize and approve changes for incorporation into the applicable parts of the PAL. The Corporate SEPG will make the approved changes. When a new release of the PAL is approved, FSAs/DSEs are notified of the changes via electronic mail.
See revised Definition Standards
STANDARD SOFTWARE PROCESS DEFINITION STANDARD
for SYSTEM MODIFICATION SCENARIO
Purpose
This standard specifies the content and format requirements for all process definitions that will be contained in the FSO’s standard software processes.
Goals
To provide a common framework for process definition.
To aid in the standardization efforts of the FSO.
To allow for tailoring by the individual Automated Information Systems (AISs) to adapt organizational process to unique requirements.
Benefits
The use of a common organizational process definition standard will support greater predictability, consistency and uniformity in the process definitions created by the FSO.
Approval Procedures:
The FSO Director approves this standard and any changes to it.
Definition of Elements:
Component - A component represents the highest level of a scenario. Each component contains a logically grouped set of tasks that perform a software development function. All components are considered to be core (required) to the software development process. Within the component, the ordering of the tasks and the exclusion of optional tasks are the only tailorable aspects. Components will include a brief narrative purpose, a list of inputs, a list of outputs, a list of metrics, and a list of associated tasks. The preferred task ordering will be shown along with task descriptions.
Task - A task represents a particular activity or set of activities that occur within one or more components. Tasks will be defined as core or optional within the scenario. Core tasks are required for software development. Optional tasks may apply only to certain projects because of customer requirements. The order in which tasks are performed may be tailored by individual projects. Tasks contain an EPVX model showing the Entrance criteria, Procedures, Verification activities, and eXit criteria.
Structure of Standard Software Process Scenarios:
The scenarios will be broken down into 3 major parts: 1) a high-level structure showing the components, 2) a lower-level structure showing the EPVX model for each task, and, 3) a section containing the applicable documentation standards and templates. The project tailored version contains the detailed procedures to be used by project personnel.
1. The high-level scenario is made up of the high-level building blocks of the standard software process, called components. These components can be assembled to build a life cycle model. Each component definition will contain:
A brief narrative description of the component.
A summary of component inputs and outputs.
A list of all tasks related to the component with a brief narrative description of each task and a list referring to the EPVX model and any templates or documentation standards used by it. The description will identify the task as core or optional.
2. The lower level or task level of the scenario contains the EPVX model for each task. This model will include:
Task Number: The numbering for Tasks begins with "T" followed by a abbreviated component name and a three- digit number (Example: T-TD-003) is the third task described within the Technical Design component in the System Modification Scenario.
Component: This provides a reference to the component using the task.
Task Name: The name of the task is identified.
Purpose: A brief description explaining why the task is performed is provided.
Roles: This identifies the various resources within the project organization that are required to carry out the task and the responsibilities involved in completing the task
Entrance Criteria: This section contains:
- any documents, data, or other products that are required for or used during this task
- those tasks or procedures that must be executed prior to this task
- the conditions that must apply to any documents, data, or other products needed to complete the task
- any process or product standards that must be adhered to in completing the task
Procedures: This section specifies the major steps that make up the task. These steps focus on what needs to be accomplished, and not how it will be accomplished.
Verification Activities: This section identifies the activities required to validate that the task has been completed and has fulfilled the necessary exit criteria. While this primarily involves SQA reviews of processes and audits of products, senior management and customers are included when appropriate.
Exit Criteria: This section contains:
- any documents, data, or other products produced by the task
- the conditions that must apply to any documents, data, or other products produced by the task
- the identification of any reviews that must be successfully completed during this task.
Metrics: This section contains any measures that identify the data collected as a part of this task.
3. The documentation standards section of the scenario contains the documentation standards which define the objects produced or used by tasks within the components of the scenario . The documentation standards define the minimal essential data to be included in the product generated by executing the tasks. The documentation standards do not represent a required format, but may be used as a template. The numbering for documentation standards begin with "S" followed by an abbreviated category name and a three-digit number. The category abbreviations used are as follows:
PM - Project Management
SE - Software Engineering
CM - Configuration Management
Tailoring Guidelines
Any variation from the scenario must be written in accordance with the FSO Standard Software Process Tailoring Guidelines, which are contained in Attachment 5 of this policy, or must have a formal waiver signed by FSO’s Director of Systems Management.
Procedure Standards
Procedures are identified in scenario tasks. The procedures for an AIS’s Defined Process may vary from those identified in the scenario depending on agreements with the customer, sequence of the tasks, and other local restrictions. Each AIS’s or FSA’s/DSE’s defined process must include the references from that procedure to the document that has the detailed description for the procedure.
Procedures may be collected in a separate manual so long as references are to specific procedure descriptions in sections or paragraphs. Procedures may be in text format or in the EPVX format outlined in the scenario tasks. Procedures should also be identified as DFAS standard, FSO standard, FSO best-practice, FSA standard, or project-unique procedures. The FSO HQ will identify FSO standard procedures and best practices in the PAL. Projects shall use FSO standard procedures when identified. If FSO standard procedures are not available, FSA/DSE Directors may identify FSA standard procedures for their projects and for inclusion in the PAL. Best practice procedures are those that appear to provide the most effective and efficient steps to accomplish specific procedures. If FSA/DSE or FSO Directors feel that certain FSA standard or project-unique procedures would provide significant effectiveness or economy for the entire organization, they may nominate such procedures for best-practice status to the Corporate SEPG. The Corporate SEPG will consolidate such proposals and submit them to the Corporate Steering Committee. The Corporate Steering Committee will review these procedures to determine if they would be effective for all projects. If these procedures are approved as best-practice procedures, FSO HQ will make them available through the PAL with that annotation.
These guidelines have been revised - see Tailoring Process
FINANCIAL SYSTEMS ORGANIZATION’S
STANDARD SOFTWARE PROCESS
TAILORING GUIDELINES
1. Background. The FSO standard software processes are influenced by customer demands and unique business requirements. All components defined in the standard software processes (or scenarios) are required for an Automated Information System (AIS). However, FSAs/DSEs may not perform all of these components, based on the roles and responsibilities agreed to by the customer. Tasks within the components may also require tailoring due to unique divisions of responsibilities, tools, operating environments, or platforms. These tailoring guidelines facilitate the FSA/DSE in defining an AIS Tailored Software Process and an AIS Defined Process.
2. Deviations. All tasks within components are considered core (required) and must be included unless annotated as "optional" or approved for deviation. Deviations are defined as core tasks that are not performed by the FSA/DSE. These deviations must be documented and approved. Customers may perform some of the tasks outlined in the scenario. The FSA/DSE must request approval for not performing a core task within the scenario. The final approval for all deviations is granted by the FSO’s Director of Systems Management using the approval procedure outlined in paragraph 4.
3. AIS Tailored Software Process. The scenario contains all of the components used in the modification of software. The order in which the tasks within the components are executed may vary because of individual AIS or customer requirements. The AIS may include any optional tasks or new tasks that suit its business practices, as agreed to by their customers. Using a copy of the scenario, the AISs should arrange the tasks to best suit the customer and business needs, mark through any tasks that are not performed, note any changes to the ordering of tasks, and add any AIS-specific tasks. The Documentation Standards Section of the scenario represents the minimum essential data to be included in the products. The documentation standards do not represent a required format, but may be used as a template. This marked version of the scenario becomes the AIS Tailored Software Process.
4. Approval Procedures. The documented AIS Tailored Software Process is submitted to the FSO using these Approval Procedures.
The local SQA staff reviews the Tailored Software Process document to ensure it is in accordance with these guidelines and in compliance with site standards.
The FSA/DSE Director reviews and approves the AIS Tailored Software Process.
The document is forwarded to the FSO Director of System Management.
• The FSO Director of Systems Management reviews and approves the AIS Tailored Software Process by examining the proposed document and granting any waivers. Tailoring is allowed as follows:
a. To continue use of current development tools other than specified in FSO organizational policies.
b. To develop software for current unique operating environments or target platforms.
c. To accommodate unique customer requirements or agreements.
5. AIS Defined Process. The AIS Defined Process is derived from the approved AIS tailored software process. The AIS Defined Process contains the roles, criteria, timeframes, and procedures for how the tasks are completed in the AIS's day-to-day operations. The procedures may vary from those identified in the scenario depending on agreements with the customer, sequence of the tasks, and other local restrictions. The procedures identified in scenario Tasks must contain references to particular parts of a local document, i.e., the AIS Defined Process, or be defined by a set of detailed procedures. The detailed procedures definition may be narrative or may use the EPVX model outlined in the scenario tasks. The AIS Defined Process will be forwarded to the FSO for inclusion in the Process Asset Library (PAL). Procedures will be annotated as project-unique, FSA standard, FSO standard, DFAS standard, or FSO best practice. Procedure documentation or descriptions must include the name of the procedure as documented in the scenario task.
Please direct questions/comments about this page to the DFAS PAL Administrator at pal.admin@dfas.mil, DFAS-TA/IN
| 
