|
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 softwa ff4 re 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, 19e
- 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.
Exam e66 ples 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 co 19d nfiguration 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 ff7 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:
19d
- 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 ff7 .
- 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, 196 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 fda 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, 19b 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 re fe8 view.
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. 197
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 P fd1 roject 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.
Problems and defects detected are documented, tracked, and addressed.
Tracing of the allocated requirements through the software requirements,
design, code, and test cases is performed.
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.
|
|