1 / 1

DoD Software Acquisition Management (SAM) Notional Lifecycle Activity Chart

DR. IPR. FRP IPR. System Engineering Management, Acquisition Management, Funds and Contracting Management and other Lifecycle Activities. 508 Compliant?. Clinger-Cohen Act (CCA) compliance. Info Assurance & Superiority Requirements. DoD CIO IT Registration. Modular Contracting.

phiala
Télécharger la présentation

DoD Software Acquisition Management (SAM) Notional Lifecycle Activity Chart

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DR IPR FRP IPR System Engineering Management, Acquisition Management, Funds and Contracting Management and other Lifecycle Activities 508 Compliant? Clinger-Cohen Act (CCA) compliance Info Assurance & Superiority Requirements DoD CIO IT Registration Modular Contracting Practical SW Measures GIG Compliant? System & Operational Architectures? CPI Risk-Driven IV&V Risk-Driven IV&V Software Support Agencies Software Development (Spiral Development) Software Requirements Initial Software Requirements System Concepts System Concepts SIs SIs SIs Tech Arch Arch Views SDP ORD IERs STrP SIP Evolutionary Sustainment Interop KPP • Acq Approach • Evolutionary? • Single-Step? C4I Support Plan MAIS CCA Certification C4I Support Plan MAIS CCA Certification Mature SW Capability? JOA JTA C4I Support Plan SPS Releases & updates AIS Econ Analysis Software Development (Spiral Development) Software Development (Spiral Development) SDP SDP Vers 7.2 AS OF: 26 July 2001 DoD Software Acquisition Management (SAM) Notional Lifecycle Activity Chart This “SAM Chart” is a teaching tool developed by the DSMC, DAU. The SAM Chart is based on software acquisition management activities outlined in the DoD 5000-series and various “Best Practices”. Because of the broad scope of DoD systems and the flexibility afforded by DoD lifecycle policies, a wide variety of approaches to software lifecycle acquisition management and development is possible. Only one of these is illustrated here. Comments on this chart are welcome. Send them to SAMCHART@dau.mil) CONCEPT & TECHNOLOGY DEVELOPMENT SYSTEMS DEVELOPMENT & DEMO PRODUCTION & DEPLOYMENT OPERATIONS & SUPPORT SYSTEM INTEGRATION SYSTEM DEMONSTRATION LOW-RATE INITIAL PRODUCTION CONCEPT EXPLORATION COMPONENT ADV DEVELOPMENT FULL-RATE PROD & DEPLOYMENT SUSTAINMENT DISPOSAL SW/HW COTS & GOTS Req’ts Computer-Commo Requirements • CCA CIO Certification SSS (draft) SSS • AIS Accreditation • IAW DoDI 5200.40 Computer Resource Utilization Levels • Information Assurance • Acceptability Assessment SW Reuse Criteria Typical Software Acquisition Management Activities • Expert Review(s) SW Quality Criteria MNS • Expert Review(s) • Expert Review(s) • Info Assurance • Strategy ? Software Acquisition Management (SAM): is the process of managing the acquisition of DoD software-intensive systems. These are complex systems with diverse users typically acquired in a buyer-seller arrangement by a separate acquisition organization. While the entire system is not likely to be COTS, the final system typically incorporates a variety of COTS software products. • Expert Review(s) • JITC Interoperability Certification SRS/IRS • SW Maturity Assessment Maintaining, Adapting, Perfecting & Evolving the fielded software • C4I Supportability Certification IT Equipment Disposal via DITMS • Info Assurance • Assessment C4I Support Plan Software-Intensive Systems: are those DoD systems for which software is the largest segment in any of: systems development cost; system development risk; functionality, or system development time Implement SW Support Concept • Info Assurance • Assessment • DCMA MOA for SW Oversight? SOFTWARE SUPPORTABILITY PLANNING Key Definitions: Depending on the category of a system, differing programmatic requirements, including DoD CIO review may be levied on it. These categories (Encl 2 to DoDD 5000.1 and CIO G&PM 11-8450) include: Computer Resource Lifecycle Plans and Planning Computer Resources IPT Computer Resource Lifecycle Plan Updates • Production & Deployment:The purpose is to achieve a capability satisfying mission need. Production requirements of this phase do not apply to a MAIS. Software has to prove its maturity level before deployment. Once proven, the system is baselined & fielded • Usually, a Software Transition Plan (STrP) or its equivalent is generated. The STrP is key to good transition to the ultimate software support environment • SIs undergo Qualification Testing. A Software Test Plan (STP) is typically the basis of developer testing activities. • A Software Product Baseline, typically documented by a Software Product Specification (SPS), is established as part of the system-level baseline • Depending on the system, a number of formal certifications (e.g., CCA, IA, Interop, etc.) before fielding are required. • Types of DoD Info Systems • Mission Critical System: meets the definitions of “info system” and NSS in the Clinger-Cohen Act (CCA), the loss of which stops warfighter operations or direct mission support of warfighter opns. • Mission Essential Info System: meets definition of CCA “info system” + that the acquiring Component Head determines is necessary for the accomplishment of the organizational mission. • Major AIS: $32M (annual) or $126M (program) or $378M (lifecycle). Values in FY00 $. • Types of AIS Acquisition Categories (ACATs): • --ACAT IAM: is a MAIS for which MDA is the DoD CIO • --ACAT IAC: is a MAIS for which the MDA is the service Component Acquisition Exec (CAE) or Component CIO • ACAT II: not used for AISs • ACAT III: all others (less-than major AISs). The MDA is designated by the CAE. • Systems Development & Demo Phase:The purpose of this phase is to develop a system, reduce risk, ensure supportability, producibility, affordability, protection of Critical Program Information (CPI), and demonstrate system integration, interoperability, and utility. Entrance into this phase depends on: technology (including software) maturity, validated requirements, and funding. Generally, the maturity of the technology will determine the specific development approach to be followed. Programs should have a system and operational architecture. Evolutionary acquisition and spiral software development models are strongly emphasized. For many software-intensive systems, outside formal assessments of program fitness by independent expert review teams managed by the DUSD (S&T) are also mandated. • Key SAM activities can include: • Refinement the C4ISP. Key elements include architecture views, information exchange requirements and supportability. • Refinement of the System/Subsystem Specification (SSS). If used, key sections of a typical SSS impacting SAM include: • -- SW/HW COTS/GOTS and Computer-Communications Requirements, are essential inputs into refinements of the System and Operational Architecture • -- Computer Resource Utilization (CRU) Levels, SW Quality Criteria and Reuse Criteria which are key inputs into later determination of appropriate software measures. • Appropriate Software Development Standards (e.g., J-STD-016 or IEEE/EIA 12207) should be selected & tailored for use • Development results in Software Items (SIs) and continued software requirements refinement. SIs may be specified by a Software Requirement Specification (SRS) and Interface Requirement Specification (IRS). In most CM approaches, the SRS/IRS is the Allocated Baseline for a particular SI • DCMA Technical Support should be used. Surveillance and software management technical support tasks, should be defined for possible inclusion into a PMO-DCMA MOA. Concept & Tech Development Phase:examines alternative concepts, including cooperative opportunities and procurement or modification of Allied systems, to meet stated mission needs. The phase ends with selection of a system architecture(s) and the completion of entrance criteria for the next phase. In this phase, key areas that can impact ultimate software requirements are Clinger-Cohen Act (CCA, 40 USC §1401) compliance and certification, mission-critical and mission-essential registration (Pub. Law 106-259), development of an initial C4I Support Plan (C4ISP), GIG compliance IAW OSD G&PM 11-8450, interoperability requirements (DoDD 4630.5, DoDI 4630.8, CJCSI 6212.01B, 3170.01A), info assurance needs and impact of DoD standard architectures [the Joint Operational Architecture (JOA) and the Joint Technical Architecture (JTA)]. Except for National Security Systems (NSS), AISs may require disability access IAW Sec 508 of Pub. Law 105-220. For a MAIS, an economic analysis and formal CCA CIO certification are required. Initiation of planning for software support) starts. Finally, software process maturity is strongly emphasized by current DoD acquisition policies. • Refinement of the system’s Technical and Software Architectures continues. An Open Systems strategy is required. Compliance with the DoD’s Joint Technical Architecture, unless not cost-effective, is required. Architectures must be generated and formatted IAW the C4ISR Architecture Framework methodology. • Information Assurance and Superiority, Critical Program Protection and Anti-Tampering are key DoD concerns. Risk assessments in these areas continue over the life of the project. Derived requirements based on these may influence software architecture and design. Independent Expert Reviews can perform these assessments. • Interoperability remains a Key Performance Parameter (KPP) over the life of the project with formal assessment by the Joint Interoperability Test Center (JITC) required for many programs. • Contractor Selection: it is critical that software developers be selected with: • -- Domain experience in developing comparable software systems, • -- Successful past performance • -- A mature software development capability at least at Level III (or equivalent) on the SEI’s Software Capability Maturity Model (SW-CMM) • -- Evidence of use and adequate training in software methodologies, tools and environments • Generation of a Software Development Plan (SDP) by or its equivalent is typical. The SDP describes the contractor’s overall approach to the planning of software development, testing, risk management and other key activities • Clinger-Cohen Act (CCA) compliance is formally assessed at each decision milestone. • Use of DoD Standard Data is mandatory and an interoperability enabler. Policy on DoD’s Data Admin Program is contained in DoDD 8320.1. • The selection of an appropriate programming language(s) in the context of system and software engineering factors that influence life-cycle costs, risks and interoperability is done. • Reuse of software components from the DII Common Operating Environment (DII/COE) [DISA] • The scope of Data Rights for software products has been expanded. An analysis as part of RFP planning to insure the acquisition of data rights and documentation sufficient to support software under the chosen support strategy should be done • Concurrently with development activities, some level of Independent Verification and Validation (IV&V) may be needed. IV&V is based on an assessment of risks & failure consequences. • Issue-driven software measurement is used to gain visibility into software development activities, quality and maturity. The Practical Software Measures (PSM) approach is strongly encouraged. • COTS-based systems need special management approaches. Life-cycle support, license tracking, product evaluations and commercial buying approaches are key practices to employ. • DoD SQA personnel are charged by DoD policy to carefully evaluate the use by software developers of foreign nationals to code software, COTS included. Use of code-scanning tools for assessing security risks with COTS products is encouraged • Planning for software supportability and transition to support continues over the development lifecycle. • A Software Installation Plan (SIP) may be prepared as part of deployment/fielding planning. • Automated Information System (AIS). An acquisition program that acquires Information Technology (IT), except IT that: involves equipment that is an integral part of a weapons system; or is a tactical communication system. • National Security System (NSS). Defined in the Clinger-Cohen Act, is any telecomm or info system, in which the function, operation, or use involves intelligence or cryptologic activities; or command and control of military forces; or equipment that is an integral part of a weapons system; or, is critical to direct fulfillment of military or intel missions. NSSs do not include routine admin and business applications systems. • Information Technology (IT). Is any equipment, or interconnected system or subsystem, used in automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information. IT includes NSS. • Global Information Grid (GIG). The globally interconnected, end-to-end set of information capabilities, processes, and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers, and support personnel. The GIG includes all owned and leased communications, computing systems, services, software (plus applications), data, security & other services necessary to achieve Information Superiority. It also includes National Security Systems Opns & Support: Software Support, typically via a series of evolutionary releases, is initiated during “maintenance”. Disposal: some excess IT equipment can be redistributed within the DoD via the Defense IT Mgt System (DITMS).

More Related