Software Product Engineering

a key process area for level 3: Defined

Software Product Engineering involves performing the engineering tasks to build and maintain the software using the project's defined software process (which is described in the Integrated Software Management key process area) and appropriate methods and tools.

The software engineering tasks include analyzing the system requirements allocated to software (these system requirements are described in the Requirements Management key process area), developing the software requirements, developing the software architecture, designing the software, implementing the software in the code, integrating the software components, and testing the software to verify that it satisfies the specified requirements (i.e., the system requirements allocated to software and the software requirements).

Documentation needed to perform the software engineering tasks (e.g., software requirements document, software design document, test plan, and test procedures) is developed and reviewed to ensure that each task addresses the results of predecessor tasks and the results produced are appropriate for the subsequent tasks (including the tasks of operating and maintaining the software). When changes are approved, affected software work products, plans, commitments, processes, and activities are revised to reflect the approved changes.

Goals

Goal 1

Goal 2

Commitment to perform

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

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.

   ---

   The system requirements allocated to the software are referred to as "allocated requirements" in these practices.

   Refer to the Requirements Management key process area for practices covering the system requirements allocated to software.

   ---

Ability to perform

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

1. Skilled individuals are available to perform the different software engineering tasks, including:
   • software requirements analysis,
   • software design,
   • coding,
   • testing, and
   • software maintenance.
2. 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.

   ---

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

• 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.

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

• 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.

• 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.

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

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

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

• 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.

Activities performed

Activity 1 -- Appropriate software engineering methods and tools are integrated into 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.
3. 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.

   ---

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

   ---

   Refer to the Software Configuration Management key process area.

   ---

Activity 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. 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).

   ---

2. 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.

   ---

3. The results of the requirements analysis and the rationale for the selected alternative are documented.
4. 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.

   ---

5. The software requirements are documented.
6. The group responsible for system and acceptance testing of the software analyzes each software requirement to verify it can be tested.
7. 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.

   ---

8. The software requirements document undergoes peer review before it is considered complete.

   ---

   Refer to the Peer Reviews key process area.

   ---

9. 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.

   ---

10. 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.

    ---

11. The software requirements document is placed under configuration management.

    ---

    Refer to the Software Configuration Management key process area.

    ---

12. The software requirements are appropriately changed whenever the allocated requirements change.

    ---

    Refer to the Requirements Management key process area.

    ---

Activity 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. Design criteria are developed and reviewed.

   ---

   Examples of design criteria include:
   • verifiability,
   • adherence to design standards,
   • ease of construction,
   • simplicity, and
   • ease of planning.

   ---

2. The individuals involved in the software design review the software requirements to ensure that issues affecting the software design are identified and resolved.
3. 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.

   ---

4. 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.

   ---

5. 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.

   ---

6. The software architecture is reviewed to ensure that architecture issues affecting the software detailed design are identified and resolved.
7. The software detailed design is developed based on the software architecture.
8. 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).
9. The software design document undergoes peer review before the design is considered complete.

   ---

   Refer to the Peer Reviews key process area.

   ---

10. The software design document is placed under configuration management.

    ---

    Refer to the Software Configuration Management key process area.

    ---

11. The software design document is appropriately changed whenever the software requirements change.

Activity 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. The individuals involved in coding review the software requirements and software design to ensure that issues affecting the coding are identified and resolved.
2. Effective programming methods are used to code the software.

   ---

   Examples of programming methods include:
   • structured programming, and
   • code reuse.

   ---

3. 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.
4. Each code unit undergoes peer review and is unit tested before the unit is considered complete.

   ---

   Refer to the Peer Reviews key process area.

   ---

5. The code is placed under configuration management.

   ---

   Refer to the Software Configuration Management key process area.

   ---

6. The code is appropriately changed whenever the software requirements or software design changes.

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

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 on:
   • the 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:
     • functional (black-box),
     • structural (white-box), and
     • statistical.

     ---

   • the test coverage to be achieved.

     ---

     Examples of test coverage approaches include:
     • statement coverage,
     • path coverage,
     • branch coverage, and
     • 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.

   ---

5. Regression testing is performed, as appropriate, at each test level whenever the software being tested or its environment changes.
6. 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.

   ---

7. 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 present) 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.

   ---

8. Test plans, test procedures, and test cases are appropriately changed whenever the allocated requirements, software requirements, software design, or code being tested changes.

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

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.

Activity 7 -- System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its 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.

   ---

2. 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.
3. The test cases and test procedures are planned and prepared by a test group that is independent of the software developers.
4. The test cases are documented and are reviewed with, and approved by, the customer and end users, as appropriate, before the testing begins.
5. Testing of the software is performed against baselined software and the baselined documentation of the allocated requirements and the software requirements.
6. 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.

   ---

7. Test results are documented and used as the basis for determining whether the software satisfies its requirements.
8. The test results are managed and controlled.

Activity 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. Appropriate methods and tools are used to develop the documentation.

   ---

   Examples of methods and tools include:
   • word processing,
   • case studies, and
   • documentation reuse.

   ---

2. Documentation specialists actively participate in planning, developing, and maintaining documentation.
3. 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:
   • training documentation,
   • on-line documentation,
   • the user's manual,
   • the operator's manual, and
   • the maintenance manual.

   ---

4. Final versions of the documentation are verified against the software baselined for software acceptance testing.
5. The documentation undergoes peer review.

   ---

   Refer to the Peer Reviews key process area.

   ---

6. The documentation is managed and controlled.
7. The final documentation is reviewed and approved by the customer, end users, and software maintainers, as appropriate.

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

• 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.

Activity 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. 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 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:
     • software engineering,
     • software estimating,
     • system test,
     • software quality assurance,
     • software configuration management,
     • contract management, and
     • documentation support.

     ---

   • Changes are tracked to completion.

Measurement and analysis

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

• 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.

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

• 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.

Verifying implementation

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

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

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

1. The software requirements are reviewed to ensure that they are:
   • complete,
   • correct,
   • consistent,
   • feasible, and
   • testable.
2. Readiness and completion criteria for each software engineering task are satisfied.
3. Software products comply with the standards and requirements specified for them.
4. Required testing is performed.
5. System and acceptance testing of the software are performed according to documented plans and procedures.
6. Tests satisfy their acceptance criteria, as documented in the software test plan.
7. Tests are satisfactorily completed and recorded.