11.2 Construction Integrity

 < Day Day Up > 



11.2.1 Practice 7. Adopt Life Cycle Configuration Management

Practice Essentials

A. All programs, irrespective of size, need to manage information through a preplanned Configuration Management (CM) process.

B. CM has two aspects: (1) formal CM, which manages customerapproved baseline information, and (2) development CM, which manages shared information not yet approved by the customer.

C. Both formal and development CM should uniquely identify managed information, control changes to this information through a structure of boards, provide the status of all information either under control or released from CM, and conduct ongoing reviews and audits to ensure that the information under control is the same as that submitted.

D. The approval for a change to controlled information must be made by the highest-level organization which last approved the information prior to placing it under CM.

E. CM should be implemented in a centralized library supported by an automated tool.

F. CM needs to be a continuous process implemented at the beginning of a program and continuing until product retirement.

Implementation Guidelines

A. CM plans need to be developed by the ACQUIRER and the DEVELOPER to facilitate management control of information they own. The CM procedures of the ACQUIRER serve as the requirements for the CM plan, which describes and documents how the DEVELOPER will implement a single CM process. This plan should control formal baselines and will include engineering information, reports, analysis information, test information, user information, and any other information approved for use or shared within the program. The CM process should include DEVELOPER-controlled and -developed baselines as well as ACQUIRER-controlled baselines. It should also include release procedures for all classes of products under control, means for identification, change control procedures, status of products, and reviews and audits of information under CM control. The CM plan needs to be consistent with other plans and procedures used by the project.

B. The two types of baselines managed by CM are developmental and formal. Developmental baselines include all software, artifacts, documentation, tools, and other products not yet approved for delivery to the ACQUIRER but essential for successful production. Formal baselines are information/products (software, artifacts, or documentation) delivered and accepted by the ACQUIRER. Developmental baselines are owned by the DEVELOPER, while formal baselines are owned by the ACQUIRER.

C. All information placed under CM as a result of meeting task exit criteria needs to be uniquely identified by CM and placed under CM control. This includes software, artifacts, documents, commercial off-the-shelf (COTS), government off-the-shelf (GOTS), operating systems, middleware, database management systems, database information, and any other information necessary to build, release, verify, and/or validate the product.

D. The CM process should be organizationally centered in a project library. This library will be the repository (current and historical) of all controlled products. The ACQUIRER and the DEVELOPER will implement an organizationally specific library. The library(s) will be partitioned according to the level of control of the information.

E. All information managed by CM is subject to change control. Change control consists of the following:

  1. Identification

  2. Reporting

  3. Analysis

  4. Implementation

F. The change control process needs to be implemented through an appropriate change mechanism tied to who owns the information:

  1. Change control boards, which manage formal baseline products

  2. Interface boards, which manage jointly owned information

  3. Engineering review boards, which manage DEVELOPER-controlled information

G. Any information released from the CM library should be described by a Version Description Document (Software Version Description under 498). The version description should consist of any inventory of all components by version identifier, an identification of open problems, closed problems, differences between versions, notes and assumptions, and build instructions. Additionally, each library partition should be described by a current version description that contains the same information.

11.2.2 Practice 8. Manage and Trace Requirements

Practice Essentials

A. Before any design is initiated, requirements for that segment of the software need to be agreed to by all parties.

B. Requirements tracing should be a continuous process providing the means to trace from the user requirement to the lowest-level software component.

C. Tracing shall exist not only to user requirements, but also between products and the test cases used to verify their successful implementation.

D. All products that are used as part of the trace need to be under configuration control.

E. Requirements tracing should use a tool and be kept current as products are approved and placed under CM.

F. Requirements tracing should address system, hardware, and software and the process should be defined in the system engineering management plan and the software development plan.

Implementation Guidelines

A. The program needs to define and implement a requirements management plan that addresses system, hardware, and software requirements. This plan should be linked to the SDP.

B. All requirements need to be documented, reviewed, and entered into a requirements management tool and put under CM. This requirements information should be kept current.

C. The CM plan should describe the process for keeping requirements data internally consistent and consistent with other project data.

D. Requirements traceability needs to be maintained through specification, design, code, and testing.

E. Requirements should be visible to all project participants.

11.2.3 Practice 9. Use System-based Software Design

Practice Essentials

A. All methods used to define system architecture and software design should be documented in the system engineering management plan and software development plan and frequently and regularly evaluated through audits conducted by an independent program organization.

B. Software engineering needs to participate in the definition of system architectures and should provide an acceptance gate before software requirements are defined.

C. The allocation of system architecture to hardware, software, or operational procedures needs to be the result of a predefined engineering process and tracked through traceability and frequent quality evaluations.

D. All agreed-to system architectures, software requirements, and software design decisions should be placed under CM control when they are approved for program implementation.

E. All architecture and design components need to be approved through an inspection prior to release to CM. This inspection should evaluate the process used to develop the product, the form and structure of the product, the technical integrity, and its adequacy to support future applications of the product to program needs.

F. All system architecture decisions should be based on a predefined engineering process and trade studies conducted to evaluate alternatives.

Implementation Guidelines

A. The DEVELOPER should ensure that the system and software architectures are developed and maintained in keeping with standards, methodologies, and external interfaces specified in the system and software development plans.

B. Software engineers need to be an integral part of the team performing systems engineering tasks that influence software.

C. Systems engineering requirements trade studies should include efforts to mitigate software risks.

D. System architecture specifications need to be maintained under CM.

E. The system and software architecture and architecture methods need to be consistent with each other.

F. System requirements, including derived requirements, need to be documented and allocated to hardware components and software components.

G. The requirements for each software component in the system architecture and derived requirements need to be allocated among all components and interfaces of the software component in the system architecture.

11.2.4 Practice 10. Ensure Data and Database Interoperability

Practice Essentials

A. All data and database implementation decisions should considerinteroperability issues, and, as interoperability factors change, these decisions should be revisited.

B. Program standards should exist for database implementation and for the data elements that are included. These standards should include process standards for defining the database and entering information into it and product standards that define the structure, elements, and other essential database factors.

C. All data and databases should be structured in accordance with program requirements to provide interoperability with other systems.

D. All databases shared with the program need to be under CM control and managed through the program change process.

E. Databases and data should be integrated across the program with data redundancy kept to a minimum.

F. When using multiple COTS packages, compatibility of the data/ referential integrity mechanisms needs to be considered to ensure consistency between databases.

Implementation Guidelines

A. The DEVELOPER needs to ensure that data files and databases are developed with standards and methodologies.

B. The DEVELOPER needs to ensure that data entities and data elements are consistent with the DoD data model.

C. All data and databases should be structured in compliance with DII COE to provide interoperability with other systems.

D. Data integrity and referential integrity should be maintained automatically by COTS DBMSs or other COTS software packages. The DEVELOPER should avoid developing its package, if at all possible. Before selecting multiple COTS software packages, the DEVELOPER should study the compatibility of the data/ referential integrity mechanisms of these COTS packages and obtain assurance from the COTS vendors first.

E. Unnecessary data redundancy should be reduced to minimum.

F. Data and databases should be integrated as much as possible. Except data for temporary use or for analysis/report purposes, each data item should be updated only once, and the changes should propagate automatically everywhere.

11.2.5 Practice 11. Define and Control Interfaces

Practice Essentials

A. Before completion of system-level requirements, a complete inventory of all external interfaces needs to be completed.

B. All external interfaces need to be described as to source, format, structure, content, and method of support, and this definition, or interface profile, needs to be placed under CM control.

C. Any changes to this interface profile should require concurrence by the interface owners prior to being made.

D. Internal software interfaces should be defined as part of the design process and managed through CM.

E. Interfaces should be inspected as part of the software inspection process.

F. Each software or system interface needs to be tested individually and a test of interface support should be conducted in a stressed and anomalous test environment.

Implementation Guidelines

A. All internal and external interfaces need to be documented and maintained under CM control.

B. Changes to interfaces require concurrence by the interface owners prior to being made.

C. Milestones related to external interfaces should be tracked in the project activity network. (Keep these milestones off your critical path.)

D. Subsystem interfaces should be controlled at the program level.

11.2.6 Practice 12. Design Twice, Code Once

Practice Essentials

A. All design processes should follow methods documented in the software development plan.

B. All designs need to be subject to verification of characteristics, which are included as part of the design standards for the product produced.

C. All designs should be evaluated through a structured inspection prior to release to CM. This inspection should consider reuse, performance, interoperability, security, safety, reliability, and limitations.

D. Traceability needs to be maintained through the design and verified as part of the inspection process.

E. Critical components should be evaluated through a specific white-box test level step.

F. Design can be incrementally specified when an incremental release or evolution life cycle model is used, provided the CM process is adequate to support control of incremental designs and the inspection process is adapted to this requirement.

Implementation Guidelines

A. When reuse of existing software is planned, the system and software architectures should be designed to facilitate this reuse.

B. When an incremental release life cycle model is planned, the system and software architectures need to be completed in the first release or, at most, extended in releases after the first without changes to the architecture of previous releases.

C. The system and software architectures will be verified using methods specified in the SDP. This verification will be conducted during a structured inspection of the software architecture and will include corroboration that the architecture will support all reuse, performance, interoperability, security, safety, and reliability requirements. The architecture will be under CM.

11.2.7 Practice 13. Assess Reuse Risks and Costs

Practice Essentials

A. The use of reuse components, COTS, GOTS, or any other nondevelopmental items (NDI) should be treated as a risk and managed through risk management.

B. Application of reuse components, COTS, GOTS, or any other NDI will be made only after successful completion of an NDI acceptance inspection. This inspection needs to consider the process used to develop it, how it was documented, number of users, user experience, and compliance with essential program considerations, such as safety or security.

C. Before a decision is made to reuse a product or to acquire COTS, GOTS, or NDI, a complete cost tradeoff should be made considering the full life cycle costs, update requirements, maintenance costs, warranty and licensing costs, and any other considerations that impact use of the product throughout its life cycle.

D. All reuse products, COTS, GOTS, or NDI decisions should be based on architectural and design definitions and be traceable back to an approved user requirement.

E. All reuse components, COTS, and GOTS need to be tested individually first against program requirements and in an integrated software and system configuration prior to release for testing according to the program test plan.

F. Reuse, COTS, GOTS, and NDI decisions will be continuously revisited as program conditions change.

Implementation Guidelines

A. The DEVELOPER will establish a reuse plan for the integration of COTS, GOTS, and in-house software. This plan needs to include discussion and allocation of by whom and by what process reused software code is tested, verified, modified, and maintained.

B. The reuse plan should be in the SDP and document an approach for evaluating and enforcing reused functionality against system requirements.

C. The reuse plan should suggest a system engineering process that identifies software requirements by taking existing, reusable software components into account.

D. The test plan should identify the testing of the integrated reused code.

E. When integrating COTS, GOTS, and in-house software, ensure accurate cost estimation of integrating the reused code into the system. The cost of integrating unmodified reused code is approximately one-third the cost of developing code without reuse.

F. The DEVELOPER and the ACQUIRER need to be able to plan for the estimated costs of obtaining the necessary development and runtime licenses over the system’s life cycle and the maintenance/support critical to the product, including source code availability.



 < Day Day Up > 



Managing Software Deliverables. A Software Development Management Methodology
Managing Software Deliverables: A Software Development Management Methodology
ISBN: 155558313X
EAN: 2147483647
Year: 2003
Pages: 226

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net