1      Goals

1. 1Goal 1

 

The software engineering tasks are defined, integrated, and consistently performed to produce the software.

 

1. 1.1Goal 1 Satisfied

<text here>

1. 1.2Goal 1 Deficiency

<text here>

 

1. 2Goal 2

 

Software work products are kept consistent with each other.

 

1. 2.1Goal 2 Satisfied

<text here>

1. 2.2Goal 2 Deficiency

<text here>

 

 

2      Commitment to perform

1. 1Commitment 1

 

The project follows a written organizational policy for performing the software engineering activities.

 

This policy typically specifies that:

1. The software engineering tasks are performed in accordance with the project's defined software process. (Refer to Activities 1 and 2 of the Integrated Software Management key process area for practices covering the project's defined software process.)
2. Appropriate methods and tools are used to build and maintain the software products.
3. The software plans, tasks, and products are traceable to the system requirements allocated to software.

1. 1.1Commitment 1 Satisfied

<text here>

1. 1.2Commitment 1 Deficiency

<text here>

 

 

3      Ability to perform

1. 1Ability 1

 

Adequate resources and funding are provided for performing the software engineering tasks.

 

1. 1.1Ability 1 Satisfied

<text here>

1. 1.2Ability 1 Deficiency

<text here>

 

1. Skilled individuals are available to perform the different software

• engineering tasks, including:
• software requirements analysis,
• software design,
• coding,
• testing, and
• software maintenance.

1. Tools to support the software engineering tasks are made available.

Examples of general support tools include:

• workstations,
• database management systems,
• on-line help aids,
• graphics tools,
• interactive documentation tools, and
• word processing systems.

 

 

Examples of support tools for software requirements analysis

include:

• requirements tracking tools,
• specification tools,
• prototyping tools,
• modeling tools, and
• simulation tools.

Examples of support tools for software design include:

• specification tools,
• prototyping tools,
• simulation tools, and
• program design languages.

Examples of support tools for coding include:

• editors,
• compilers,
• cross-reference generators, and
• pretty printers.

Examples of support tools for software testing include:

• test management tools,
• test generators,
• test drivers,
• test profilers,
• symbolic debuggers, and
• test coverage analyzers.

 

 

 

1. 2Ability 2

 

Members of the software engineering technical staff receive required training to perform their technical assignments.

 

1. 2.1Ability 2 Satisfied

<text here>

1. 2.2Ability 2 Deficiency

<text here>

 

The members of the software engineering technical staff should

receive training in the application domain.

Examples of training in software requirements analysis include:

• principles of analyzing software requirements;
• the existing software requirements for any existing software to be maintained;
• skills to interview end users and application domain experts in order to    establish the software requirements (i.e., requirements elicitation); and
• the use of the tools, methods, conventions, and standards
• selected by the project for analyzing software requirements.

Examples of training in software design include:

• design concepts;
• the existing design for any existing software to be maintained;
• use of the tools, methods, conventions, and standards selected by the project for designing software.

Examples of training in coding include:

• the selected programming language(s);
• reviewing the existing source code for any existing code to be maintained;
• use of the tools, methods, conventions, and standards selected by the project for programming; and
• unit testing techniques.

 

Examples of training in software testing and other verification techniques include:

• verification methods (analysis, demonstration, and inspection as well as test);
• test planning;
• use of the tools, methods, conventions, and standards selected by the project for testing and verifying the software;
• criteria for test readiness and completion; and
• measuring test coverage.

 

1. 3Ability 3

Members of the software engineering technical staff receive orientation in related software engineering disciplines.

 

1. 3.1Ability 3 Satisfied

<text here>

1. 3.2Ability 3 Deficiency

<text here>

 

 

Examples of related software engineering disciplines include:

• software requirements analysis,
• software design,
• coding,
• testing,
• software configuration management, and
• software quality assurance.

Refer to the Training Program key process area.

 

1. 4Ability 4

 

The project manager and all software managers receive orientation in the technical aspects of the software project.

 

1. 4.1Ability 4 Satisfied

<text here>

1. 4.2Ability 4 Deficiency

<text here>

 

 

Examples of orientation include:

• software engineering methods and tools,
• the application domain,
• deliverable and nondeliverable software and associated work products, and
• guidelines on how to manage the project using the chosen methods and tools.

Refer to the Training Program key process area.

4      Activities performed

1. 1Activity 1

 

Appropriate software engineering methods and tools are integrated into the project's defined software process.

 

1. 1.1Activity 1 Satisfied

<text here>

1. 1.2Activity 1 Deficiency

<text here>

 

 

 

Refer to Activities 1 and 2 of the Integrated Software Management key process area for practices covering the project's defined software process.

1. The software engineering tasks are integrated according to the project's defined software process.
2. Methods and tools appropriate for use on the software project are selected.

Candidate methods and tools are selected based on their applicability to the organization's standards, the project's defined software process, the existing skill base, availability of training, contractual requirements, power, ease of use, and support services.

The rationale for selecting a particular tool or method is documented.

1. Configuration management models appropriate to the software project are selected and used.

Examples of configuration management models include:

• check-out/check-in models,
• composition models,
• transaction models, and
• change set models.

1. The tools used to develop and maintain the software products are placed under configuration management.

Refer to the Software Configuration Management key process area.

 

1. 2Activity 2

 

The software requirements are developed, maintained, documented, and verified by systematically analyzing the allocated requirements according to the project's defined software process.

 

1. 2.1Activity 2 Satisfied

<text here>

1. 2.2Activity 2 Deficiency

<text here>

 

 

 

1. The individuals involved in developing the software requirements review the allocated requirements to ensure that issues affecting the software requirements analysis are identified and resolved. Software requirements cover the software functions and performance, the interfaces to both hardware and software, and other system components (e.g., humans).

1. Effective methods for requirements analysis are used to identify and derive the software requirements.

Examples of methods for requirements analysis include:

• functional decomposition,
• object-oriented decomposition,
• tradeoff studies,
• simulations,
• modeling,
• prototyping, and
• scenario generation.

1. The results of the requirements analysis and the rationale for the selected alternative are documented.
2. The software requirements are analyzed to ensure they are feasible and appropriate to implement in software, clearly stated, consistent with each other, testable, and complete (when considered as a set). Problems with the software requirements are identified and reviewed with the group responsible for the system requirements; appropriate changes are made to the allocated requirements and to the software requirements.

Refer to the Requirements Management key process area.

1. The software requirements are documented.
2. The group responsible for system and acceptance testing of the software analyzes each software requirement to verify it can be tested.
3. The methods for verifying and validating that each software requirement is satisfied are identified and documented.

Examples of verification and validation methods include:

• demonstration,
• system testing,
• acceptance testing,
• analysis, and
• inspection.

1. The software requirements document undergoes peer review before it is considered complete. Refer to the Peer Reviews key process area.
2. The software requirements document is reviewed and approved.

Examples of individuals who review and approve the software requirements document include:

• the project manager,
• the system engineering manager,
• the project software manager, and
• the software test manager.

1. The software requirements document is reviewed with the customer and end users, as appropriate. The end users referred to in these practices are the customer Designated end users or representatives of the end users.

1. The software requirements document is placed under configuration management. Refer to the Software Configuration Management key process area. The software requirements are appropriately changed whenever the allocated requirements change. Refer to the Requirements Management key process area.

 

1. 3Activity 3

 

The software design is developed, maintained, documented, and verified, according to the project's defined software process, to accommodate the software requirements and to form the framework for coding.

 

1. 3.1Activity 3 Satisfied

<text here>

1. 3.2Activity 3 Deficiency

<text here>

 

 

1. The software design consists of the software architecture and the detailed software design. Design criteria are developed and reviewed.

Examples of design criteria include:

• verifiability,
• adherence to design standards,
• ease of construction,
• simplicity, and
• ease of planning.

1. The individuals involved in the software design review the software requirements to ensure that issues affecting the software design are identified and resolved.
2. Application standards are used where appropriate.

Examples of application standards include:

• standards for operating system interfaces,
• standards for computer-human interfaces, and
• standards for networking interfaces.

1. Effective methods are used to design the software.

Examples of software design methods include:

• prototyping,
• structural models,
• design reuse,
• object-oriented design, and
• essential systems analysis.

1. The software architecture is developed early, within the constraints of the software life cycle and technology being used. The software architecture establishes the top-level software framework with well-defined internal and external interfaces.
2. The software architecture is reviewed to ensure that architecture issues affecting the software detailed design are identified and resolved.
3. The software detailed design is developed based on the software architecture.
4. The software design (i.e., the software architecture and detailed design) is documented.The documentation of the software design covers the software components; the internal interfaces between software components; and the software interfaces to other software systems, to hardware, and to other system components (e.g., humans).
5. The software design document undergoes peer review before the design is considered complete. Refer to the Peer Reviews key process area.
6. The software design document is placed under configuration management. Refer to the Software Configuration Management key process area.
7. The software design document is appropriately changed whenever the software requirements change.

 

1. 4Activity 4

 

The software code is developed, maintained, documented, and verified, according to the project's defined software process, to implement the software requirements and software design.

 

1. 4.1Activity 4 Satisfied

<text here>

1. 4.2Activity 4 Deficiency

<text here>

 

1. The individuals involved in coding review the software requirements and software design to ensure that issues affecting the coding are identified and resolved. Effective programming methods are used to code the software.

Examples of programming methods include:

• structured programming, and
• code reuse.

1. The sequence in which code units are developed is based on a plan that accounts for factors such as criticality, difficulty, integration and test issues, and needs of the customer and end users, as appropriate.
2. Each code unit undergoes peer review and is unit tested before the unit is considered complete. Refer to the Peer Reviews key process area.
3. The code is placed under configuration management. Refer to the Software Configuration Management key process area.
4. The code is appropriately changed whenever the software requirements or software design changes.

 

 

1. 5Activity 5

 

Software testing is performed according to the project's defined software process.

 

1. 5.1Activity 5 Satisfied

<text here>

1. 5.2Activity 5 Deficiency

<text here>

 

 

 

 

1. Testing criteria are developed and reviewed with the customer and the end users, as appropriate.
2. Effective methods are used to test the software.
3. The adequacy of testing is determined based onthe level of testing performed,

Examples of levels of testing include:

• unit testing,
• integration testing,
• system testing, and
• acceptance testing.
• the test strategy selected, and

Examples of test strategies include:

1. functional (black-box),
2. structural (white-box), and
3. statistical.

• the test coverage to be achieved.

Examples of test coverage approaches include:

1. statement coverage,
2. path coverage,
3. branch coverage, and
4. usage profile.

4. For each level of software testing, test readiness criteria are established and used.

Examples of criteria to determine test readiness include:

• software units have successfully completed a code peer review and unit testing before they enter integration testing,
• the software has successfully completed integration testing before it enters system testing, and
• a test readiness review is held before the software enters acceptance testing.

1. Regression testing is performed, as appropriate, at each test level whenever the software being tested or its environment changes.
2. The test plan, test procedures, and test cases undergo peer review before they are considered ready for use. Refer to the Peer Reviews key process area.
3. The test plans, test procedures, and test cases are managed and controlled. "Managed and controlled" implies that the version of the work product in use at a given time (past or resent) must be known, and changes must be incorporated in a controlled manner. If a greater degree of formality than is implied by "managed and controlled" is desired, the work product can be placed under configuration management, as is described in the Software Configuration Management key process area.
4. Test plans, test procedures, and test cases are appropriately changed whenever the allocated requirements, software requirements, software design, or code being tested changes.

 

1. 6Activity 6

 

Integration testing of the software is planned and performed according to the project's defined software process.

 

1. 6.1Activity 6 Satisfied

<text here>

1. 6.2Activity 6 Deficiency

<text here>

 

 

 

1. The plans for integration testing are documented and based on the software development plan.
2. The integration test cases and test procedures are reviewed with the individuals responsible for the software requirements, software design, and system and acceptance testing.
3. Integration testing of the software is performed against the designated version of the software requirements document and the software design document.

 

1. 7Activity 7

 

System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its requirements.

 

1. 7.1Activity 7 Satisfied

<text here>

1. 7.2Activity 7 Deficiency

<text here>

 

 

 

System testing is performed to ensure the software satisfies the software requirements. Acceptance testing is performed to demonstrate to the customer and end users that the software satisfies the allocated requirements.

1. Resources for testing the software are assigned early enough to provide for adequate test preparation.

Examples of activities required to prepare for testing include:

• preparing testing documentation,
• scheduling testing resources,
• developing test drivers, and
• developing simulators.

1. System and acceptance testing are documented in a test plan, which is reviewed with, and approved by, the customer and end users, as appropriate. The test plan covers:

• the overall testing and verification approach;
• responsibilities of the developing organization, subcontractors, customer, and end users, as appropriate;
• test facility, test equipment, and test support requirements; and
• acceptance criteria.

1. The test cases and test procedures are planned and prepared by a test group that is independent of the software developers.
2. The test cases are documented and are reviewed with, and approved by, the customer and end users, as appropriate, before the testing begins.
3. Testing of the software is performed against baselined software and the baselined documentation of the allocated requirements and the software requirements.
4. Problems identified during testing are documented and tracked to closure. Refer to Activity 9 of the Software Project Tracking and Oversight key process area and Activity 5 of the Software Configuration Management key process area for practices covering documenting and tracking problems.
5. Test results are documented and used as the basis for determining whether the software satisfies its requirements.
6. The test results are managed and controlled.

 

1. 8Activity 8

 

The documentation that will be used to operate and maintain the software is developed and maintained according to the project's defined software process.

 

1. 8.1Activity 8 Satisfied

<text here>

1. 8.2Activity 8 Deficiency

<text here>

 

 

 

1. Appropriate methods and tools are used to develop the documentation.

 

Examples of methods and tools include:

• word processing,
• case studies, and
• documentation reuse.

1. Documentation specialists actively participate in planning, developing, and maintaining documentation.
2. Preliminary versions of the documentation are developed and made available early in the software life cycle for the customer, end users, and software maintainers, as appropriate, to review and provide feedback.

Examples of documentation include:

• raining documentation,
• on-line documentation,
• the user's manual,
• the operator's manual, and
• the maintenance manual.

1. Final versions of the documentation are verified against the software baselined for software acceptance testing.
2. The documentation undergoes peer review. Refer to the Peer Reviews key process area.
3. The documentation is managed and controlled.
4. The final documentation is reviewed and approved by the customer, end users, and software maintainers, as appropriate.

 

1. 9Activity 9

 

Data on defects identified in peer reviews and testing are collected and analyzed according to the project's defined software process.

 

1. 9.1Activity 9 Satisfied

<text here>

1. 9.2Activity 9 Deficiency

<text here>

 

 

 

Examples of the kinds of data to be collected and analyzed include:

• defect description,
• defect category,
• severity of the defect,
• units containing the defect,
• units affected by the defect,
• activity where the defect was introduced,
• peer review or test cases that identified the defect,
• description of the scenario being run that identified the defect, and
• expected result and actual results that identified the defect.

 

1. 10Activity 10

Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures.

 

1. 10.1Activity 10 Satisfied

<text here>

1. 10.2Activity 10 Deficiency

<text here>

 

 

 

 

1. Software work products are documented, and the documentation is readily available.
2. The software requirements, design, code, and test cases are traced to the source from which they were derived and to the products of the subsequent software engineering activities.
3. The documentation tracing the allocated requirements through the software requirements, design, code, and test cases is managed and controlled.
4. As understanding of the software improves, changes to the software
5. work products, plans, process descriptions, and activities are proposed, analyzed, and incorporated as appropriate.

 

• The project determines the impact of the change before the change is made.
• Where changes to the allocated requirements are needed, they are approved and incorporated before any software work products or activities are changed.
• Changes to all software products, plans, process descriptions, and activities are coordinated.
• Changes are negotiated with and communicated to the affected groups.

Examples of affected groups include:

1. software engineering,
2. software estimating,
3. system test,
4. software quality assurance,
5. software configuration management,
6. contract management, and
7. documentation support.
8. Changes are tracked to completion.

5      Measurement and Analysis

1. 1Measurement 1

 

Measurements are made and used to determine the functionality and quality of the software products.

 

1. 1.1Measurement 1 Satisfied

<text here>

1. 1.2Measurement 1 Deficiency

<text here>

 

 

 

Examples of measurements include:

• numbers, types, and severity of defects identified in the software products tracked cumulatively and by stage; and
• allocated requirements summarized by category (e.g., security, system configuration, performance, and reliability), and traced to the software requirements and system test cases.

 

1. 2Measurement 2

 

Measurements are made and used to determine the status of the software product engineering activities.

 

1. 2.1Measurement 2 Satisfied

<text here>

1. 2.2Measurement 2 Deficiency

<text here>

 

 

 

Examples of measurements include:

• status of each allocated requirement throughout the life of the project;
• problem reports by severity and length of time they are open;
• change activity for the allocated requirements;
• effort to analyze proposed changes for each proposed change and cumulative totals;
• number of changes incorporated into the software baseline by category (e.g., interface, security, system configuration, performance, and usability); and
• size and cost to implement and test incorporated changes, including initial estimate and actual size and cost.

6      Verifying implementation

1. 1Verification 1

 

The activities for software product engineering are reviewed with senior management on a periodic basis.

 

1. 1.1Verification 1 Satisfied

<text here>

1. 1.2Verification 1 Deficiency

<text here>

 

 

 

Refer to Verification 1 of the Software Project Tracking and Oversight key process area for practices covering the typical content of senior management oversight reviews.

 

 

 

 

1. 2Verification 2

 

The activities for software product engineering are reviewed with the project manager on both a periodic and event-driven basis.

 

1. 2.1Verification 2 Satisfied

<text here>

1. 2.2Verification 2 Deficiency

<text here>

 

Refer to Verification 2 of the Software Project Tracking and Oversight key process area for practices covering the typical content of project management oversight reviews.

 

 

1. 3Verification 3

 

The software quality assurance group reviews and/or audits the activities and work products for software product engineering and reports the results.

 

1. 3.1Verification 3 Satisfied

<text here>

1. 3.2Verification 3 Deficiency

<text here>

 

 

Refer to the Software Quality Assurance key process area.

At a minimum, the reviews and/or audits verify that:

1. The software requirements are reviewed to ensure that they are:

• complete,
• correct,
• consistent,
• feasible, and
• testable.

1. Readiness and completion criteria for each software engineering task are satisfied.
2. Software products comply with the standards and requirements specified for them.
3. Required testing is performed.
4. System and acceptance testing of the software are performed according to documented plans and procedures.
5. Tests satisfy their acceptance criteria, as documented in the software test plan.
6. Tests are satisfactorily completed and recorded.
7. Problems and defects detected are documented, tracked, and addressed.
8. Tracing of the allocated requirements through the software requirements, design, code, and test cases is performed.
9. The documentation used to operate and maintain the software is verified against the software baseline and any applicable allocated requirements before the software product is released to the customer or end users.