Downloaded from https://www.everyspec.com Table 4–3 Software materiel release determination criteria Criteria Description Notes: 1 Must be approved by the DCS, G–3/5/7 in accordance with HQDA software blocking policy. e. Software releases are upgrades of software with less restrictive release procedures. SRs are changes to software that do not meet the criteria outlined in table 4–3. SR will be processed and approved by the MRA software engineering center (SEC). Software releases will be classified as full, conditional, database/dataset, or urgent, as delineated below. (1) Full software release.
Full software release (FSR) is authorized when the software has been fully tested, evaluated, and meets established quality, performance, reliability, maintainability, safety, suitability, environmental, interoperability, software supportability and configuration management requirements. (2) Conditional software release. Conditional software release (CSR) may be authorized when one or more of the criteria for FSR have not been met. (a) A CSR will be followed by a FSR when the conditions associated with the CSR have been corrected. (b) A get-well plan is established that addresses each condition of release and plans for achieving a FSR.
The PM must obtain GC acceptance of the established get-well plan and manage all residual risks as part of the CSR. The get- well plan is a listing of each condition, the interim workaround, the date the condition is expected to be corrected, the proponent that will correct the condition and the funding status to correct the condition. All get-well plans will be documented by the supporting software engineering center (see para 4–8 for further guidance). (c) In cases where it is determined that conditions prohibiting the conversion of a CSR to a FSR can not be corrected, a request for a change to a FSR may be made to the supporting SEC (normally LCMC). (3) Database/dataset software release.
A database/dataset software release (DDSR) is the release of software in the form of a database/dataset to update currently fielded system software. A DDSR will be approved only after critical issues such as safety, availability of spare/repair parts, technical documentation, responsibility for maintenance support; interoperability, IA controls and other conditions that limit the use of the materiel have been adequately resolved. (4) Urgent software release. Urgent software release (USR) procedures may be authorized if there is an urgent request from the GC (colonel or equivalent) due to a safety problem or a mission-essential function.
This GC request will contain a required delivery date, specify the urgency of need, and clearly define the safety problem or mission essential function that is required. When a USR is requested, the SEC will ensure that a response is fielded, if possible, within 72 hours of the request. A USR will be followed within 18 months by a FSR incorporating the functionality of the USR. Urgent software releases are restricted to specific quantity(ies), location(s), or application(s). 4–8. Materiel release conditions and conditional materiel release actions a.
Materiel release conditions are materiel shortfalls that affect safety, suitability, and supportability and require a materiel fix (modification, engineering change proposal, and so on) and in certain cases testing and/or fixes to correct. All MR conditions will be raised to decision makers for consideration prior to release approval. b. When a CMR is determined, the PM will take the following actions: (1) Establish an MR get-well plan (see para 4–13 d ) and correct the conditions. Achieve FMR for the materiel within 3 years of CMR approval. 20 AR 700–142 • 26 March 2008 Interface change Any software change that has the potential of adding or deleting an external interface to a system.
Source lines of code (SLOC) change An incremental update consisting of a software change of more than 25 percent of SLOC or 25 per- cent cumulative equivalent SLOC changes not having required release approval since the last SMR. These criteria may be tightened at the discretion of the PM on the basis of criticality of the software changes. Functional capabilities change Any software change that affects form, fit, or functions as defined by the capabilities documents. Architectural change Any software change that has a significant and substantial impact on the architecture of the system.
Degradation in capability change Any software change that adversely affects the suitability, supportability, maintainability, reliability, or safety of the system. Translational change An incremental update consisting of a software translation of 25 percent equivalent SLOC to a differ- ent computer programming language (for example, assembly speed up). New test equipment or program of instruction change Software changes that require new user level test equipment and/or that impact 25 percent or more of the trainer program of instruction.
Backward compatibility change Software changes that result in a new version that is not backward compatible with the inter- operability capabilities of the previous version(s) released to the field. BC/tactical network software Any software that affects BC systems, or major releases of tactical network software.1