Software Product Engineering
a key process area for level 3: Defined
The purpose of Software Product Engineering is to consistently perform a
well-defined engineering process that integrates all the software engineering
activities to produce correct, consistent software products effectively and
efficiently.
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
The software engineering tasks are defined, integrated, and consistently
performed to produce the software.
Goal 2
Software work products are kept consistent with each other.
Commitment to perform
Commitment 1 -- The project follows a written organizational policy for
performing the software engineering activities.
This policy typically specifies that:
- 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.
- Appropriate methods and tools are used to build and maintain the software
products.
- 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.
- Skilled individuals are available to perform the different software
engineering tasks, including:
- software requirements analysis,
- software design,
- coding,
- testing, and
- software maintenance.
- 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.
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; and
- 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.
Refer to the Training Program key process area.
Ability 3 -- Members of the software engineering technical staff receive
orientation in related software engineering disciplines.
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.
Ability 4 -- The project manager and all software managers receive
orientation in the technical aspects of the software project.
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.
Activities performed
Activity 1 -- Appropriate software engineering methods and tools are
integrated into 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.
- The software engineering tasks are integrated according to the project's
defined software process.
- 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.
- 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.
- 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.
- 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).
- 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.
- The results of the requirements analysis and the rationale for the
selected alternative are documented.
- 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.
- The software requirements are documented.
- The group responsible for system and acceptance testing of the software
analyzes each software requirement to verify it can be tested.
- 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.
- The software requirements document undergoes peer review before it is
considered complete.
Refer to the Peer Reviews key process area.
- 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.
- 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.
- 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.
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.
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.
- The individuals involved in the software design review the software
requirements to ensure that issues affecting the software design are identified
and resolved.
- 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.
- 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.
- 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.
- The software architecture is reviewed to ensure that architecture issues
affecting the software detailed design are identified and resolved.
- The software detailed design is developed based on the software architecture.
- 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).
- The software design document undergoes peer review before the design is
considered complete.
Refer to the Peer Reviews key process area.
- The software design document is placed under configuration management.
Refer to the Software Configuration Management key process area.
- 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.
- 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.
- 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.
- Each code unit undergoes peer review and is unit tested before the unit is
considered complete.
Refer to the Peer Reviews key process area.
- The code is placed under configuration management.
Refer to the Software Configuration Management key process area.
- 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.
- Testing criteria are developed and reviewed with the customer and the end
users, as appropriate.
- Effective methods are used to test the software.
- 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.
- 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.
- Regression testing is performed, as appropriate, at each test level
whenever the software being tested or its environment changes.
- 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.
- 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.
- 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.
- The plans for integration testing are documented and based on
the software development plan.
- The integration test cases and test procedures are reviewed with the
individuals responsible for the software requirements, software design, and
system and acceptance testing.
- 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.
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.
- 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.
- 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.
- The test cases and test procedures are planned and prepared by a test
group that is independent of the software developers.
- The test cases are documented and are reviewed with, and approved by, the
customer and end users, as appropriate, before the testing begins.
- Testing of the software is performed against baselined software and the
baselined documentation of the allocated requirements and the software
requirements.
- 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.
- Test results are documented and used as the basis for determining whether
the software satisfies its requirements.
- 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.
- Appropriate methods and tools are used to develop the documentation.
Examples of methods and tools include:
- word processing,
- case studies, and
- documentation reuse.
- Documentation specialists actively participate in planning, developing,
and maintaining documentation.
- 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.
- Final versions of the documentation are verified against the software
baselined for software acceptance testing.
- The documentation undergoes peer review.
Refer to the Peer Reviews key process area.
- The documentation is managed and controlled.
- 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.
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.
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.
- Software work products are documented, and the documentation is readily
available.
- 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.
- The documentation tracing the allocated requirements through the software
requirements, design, code, and test cases is managed and controlled.
- 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.
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.
Measurement 2 -- Measurements are made and used to determine the status
of the software product engineering activities.
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.
Verifying implementation
Verification 1 -- The activities for software product engineering are
reviewed with senior management on a periodic basis.
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.
Verification 2 -- The activities for software product engineering are
reviewed with the project manager on both a periodic and event-driven basis.
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.
Verification 3 -- The software quality assurance group reviews and/or
audits the activities and work products for software product engineering and
reports the results.
Refer to the Software Quality Assurance key process area.
At a minimum, the reviews and/or audits verify that:
- The software requirements are reviewed to ensure that they are:
- complete,
- correct,
- consistent,
- feasible, and
- testable.
- Readiness and completion criteria for each software engineering task are
satisfied.
- Software products comply with the standards and requirements specified for
them.
- Required testing is performed.
- System and acceptance testing of the software are performed according to
documented plans and procedures.
- Tests satisfy their acceptance criteria, as documented in the software
test plan.
- Tests are satisfactorily completed and recorded.
| |
|