This appendix interprets MIL-STD-498 when applied to the incorporation of reusable software products. This appendix is a mandatory part of this standard, subject to tailoring by the acquirer.
This section is not applicable to this appendix.
The developer shall specify in the software development plan the criteria to be used for evaluating reusable software products for use in fulfilling the requirements of the contract. General criteria shall be the software product's ability to meet specified requirements and to be cost-effective over the life of the system. Non-mandatory examples of specific criteria include, but are not limited to:
a. Ability to provide required capabilities and meet required constraints
b. Ability to provide required safety, security, and privacy
c. Reliability/maturity, as evidenced by established track record
d. Testability
e. Interoperability with other system and system-external elements
f. Fielding issues, including:
1) Restrictions on copying/distributing the software or documentation
2) License or other fees applicable to each copy
g. Maintainability, including:
1) Likelihood the software product will need to be changed
2) Feasibility of accomplishing that change
3) Availability and quality of documentation and source files
4) Likelihood that the current version will continue to be supported by the supplier
5) Impact on the system if the current version is not supported
6) The acquirer's data rights to the software product
7) Warranties available
h. Short- and long-term cost impacts of using the software product
i. Technical, cost, and schedule risks and tradeoffs in using the software product
The following rules apply in interpreting this standard:
a. Any requirement that calls for development of a software product may be met by a reusable software product that fulfills the requirement and meets the criteria established in the software development plan. The reusable software product may be used as-is or modified and may be used to satisfy part or all of the requirement. For example, a requirement may be met by using an existing plan, specification, or design.
b. When the reusable software product to be incorporated is the software itself, some of the requirements in this standard require special interpretation. Figure 3 provides this interpretation. Key issues are whether the software will be modified, whether unmodified software constitutes an entire CSCI or only one or more software units, and whether unmodified software has a positive performance record (no firm criteria exist for making this determination). The figure is presented in a conditional manner: If an activity in the left column is required for a given type of software, the figure tells how to interpret the activity for reusable software of that type.
Translator: Simon Wright simon@pogner.demon.co.uk
Last updated: 22.iii.99