Notice that two major items, eliminating rework and building simpler products, have underlying techniques in common. One point that Boehm makes is that improved process models and rapid prototyping techniques aid software engineers and developers in eliminating rework during the development life cycle. Rework may be reduced or eliminated by using a process model to force project managers to focus on difficult issues during requirements and design, rather than on delivery of some required documentation. Prototyping helps to eliminate rework by insuring that requirements are validated prior to software design, code and unit test. In addition, Boehm suggests that rapid prototyping helps developers to develop simpler products by eliminating those features which are not valid user requirements, and which contribute to software "gold-plating". Further support can be found for the general view that improved process models and rapid prototyping techniques help to improve software productivity.
|Published (Last):||18 July 2016|
|PDF File Size:||10.41 Mb|
|ePub File Size:||20.46 Mb|
|Price:||Free* [*Free Regsitration Required]|
The title page shall contain the information identified below in the indicated format: This specification shall contain a table of contents listing the title and page number of each titled paragraph and subparagraph.
The table of contents shall then list the title and page number of each figure, table, and appendix, in that order. This section shall be numbered 1 and shall be divided into the following paragraphs. This paragraph shall be numbered 1.
This paragraph shall identify the higher-level specification s containing the requirements from which the design of this CSCI was derived. This section shall be numbered 2 and shall list by document number and title all documents referenced in the SDD. This section shall also identify the source for all documents not available through normal Government stocking activities. This section shall be numbered 3 and shall be divided into the following paragraphs to describe the preliminary design of the CSCI.
This paragraph shall be numbered 3. The overview shall identify and state the purpose of each external interface of the CSCI. A system architecture diagram may be used to show the relationships between this CSCI and the other CIs in the system.
The relationships amount the CSCs shall be described. The relationship description shall identify and state the purpose of each CSC-to-CSC interface and shall summarize the data transmitted via the interface. This paragraph shall identify any non-developmental software to be incorporated into the CSCI. The CSCI top-level architecture may be illustrated graphically. In addition, this paragraph shall describe the general flow of both execution control and data between CSCs while operating in the different states and modes.
A flow diagram s may by used to illustrate the execution control and data flow in each state and mode. This section shall be numbered 3. This subparagraph shall be numbered 3. X beginning with 3. This subparagraph shall provide the following information: Identify the requirements allocated to the CSC from the applicable requirements specification s. Describe the preliminary design of the CSC in terms of execution control and data flow. This information may be referenced rather than duplicated for each sub-level CSC.
Y beginning with 3. This subparagraph does not apply if there are no sub-level CSCs. If this CSC is also composed of sub-level CSCs, each sub-level CSC shall be identified by name and project unique identifier and the information required by a through c shall be provided in a separate subparagraph for each sub-level CSC.
This section shall be numbered 4 and shall be divided into the following paragraphs and subparagraphs to describe the detailed design of each CSC. This paragraph shall be numbered 4. X beginning with 4. This subparagraph shall be numbered 4. Y beginning with 4. This subparagraph shall be divided into the following subparagraphs to provide the design information for the CSU. This subparagraph shall identify the requirements allocated to the CSC that are to be satisfied or partially satisfied by the CSU and shall identify any constraints on the design of the CSU.
The design requirements addressed in this subparagraph shall include design requirements for the man-machine interface, as applicable. If the CSU is to be coded in a programming language other than the specified CSCI language, the programming language shall be identified and the rationale for its use shall be provided. If the CSU resides in a library, this subparagraph shall identify the library by name and project unique identifier, and the design document in which the library description can be found.
The detailed design information identified below shall be provided for the CSU, as applicable. This information may be provided by automated tools or other techniques, such as a program design language, flowcharts, or other design representations.
Identify and state the purpose of each input and output data element to the CSU. The design information for data elements shall be provided in section 5. Local data elements. This information may be provided in a CSU local data definition table. Interrupts and signals. Identify and describe the interrupts and signals handled by the CSU. Identify for each interrupt and signal, as appropriate, its source, purpose, priority, expected response and response time, and minimum, maximum, and probable frequency of occurrence.
Identify, state the purpose, and describe in detail the algorithms to be incorporated into the execution of the CSU. The algorithms shall be describe in terms of the manipulation and input and local data elements and the generation of output data elements. Error handling. Identify and describe the error detection and recovery features of the CSU, including handling of erroneous input data and other conditions that affect the execution of the CSU.
Data conversion. Use of other elements. Shared data stored in a global memory, e. Input and output buffers, including message buffers. Logic flow. Describe the logic flow of the CSU in terms of the above items. Describe the conditions under which CSU execution is initiated and, if applicable, communication interface features are invoked, and the conditions under which control is passed to other CSUs, as applicable. Data structures. Local data files or database.
If a data file s or a database are part of the local data of a CSU, state the purpose of each file or database, the structure of each file or database in terms of records, fields, etc. Describe any limitations or unusual features that restrict the performance of the CSU.
This section shall be numbered 5 and shall describe the global data elements within the CSCI. For ease in readability and maintenance, the information required below be provided in one or more tables. The following information shall be provided for each data element, as applicable: For data elements internal to the CSCI: Name of the data element A brief description The units of measure, such as knots, seconds, meters, feet, etc.
When applicable, each source shall be identified by its project unique identifier. This section shall be numbered 6 and shall be divided into the following paragraphs to describe each of the shared data files of the CSCI.
This paragraph shall be numbered 6. This subparagraph shall be numbered 6. X beginning with 6. This paragraph shall state the purpose of the data file, identify the maximum size of the file, and describe the file access method, such as random or sequential. This paragraph shall provide a description of the structure and size of the records contained within the file. This paragraph shall also provide a description of the data that is to reside in the file. This information may be provided in a file definition table.
This section shall be numbered 7 and shall provide traceability of the requirements allocated down to the CSU level of each CSC back to the requirements of the Software Requirements Specification and Interface Requirements Specification. The traceability may be shown graphically. This section shall be numbered 8 and shall contain any general information that aids in understanding this document e. This section shall including an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document.
Appendixes may be used to provide information published separately for convenience in document maintenance e. As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease of handling. Appendixes shall be lettered alphabetically A, B, etc , and the paragraphs within each appendix be numbered as multiples of 10 e.
Pages within each appendix shall be numbered alpha-numerically as follows: Appendix A pages shall be numbered A-1, A-2, A-3, etc. Appendix B pages shall be numbered B-1, B-2, B-3, etc.
Jump to: navigation , search This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. November This article includes a list of references, related reading or external links, but its sources remain unclear because it lacks inline citations. Please improve this article by introducing more precise citations where appropriate. This document established "uniform requirements for the software development that are applicable throughout the system life cycle.
DoD-Std-2167A and methodologies
This appendix contains requirements for a category and priority classification scheme to be applied to all problems detected in the deliverable software or its documentation that has been placed under contractor configuration control. The requirements specified in this appendix are a mandatory part of this standard. Problems detected during software operation shall be classified by category as follows: Software problem. The software does not operate according to supporting documentation and the documentation is correct. Documentation problem. The software does not operate according to supporting documentation but the software operation is correct.
Figure 17. Mapping of MIL-STD-498 DIDs to DOD-STD-2167A and DOD-STD-7935A DIDs
Data Item Description