IEEE 1558-2004 en Standard for Software Documentation for Rail Equipment and Systems《轨道设备和系统的软件文件资料》.pdf

1、IEEE Std 1558-20041558TMIEEE Standard for SoftwareDocumentation for Rail Equipmentand Systems3 Park Avenue, New York, NY 10016-5997, USAIEEE Vehicular Technology SocietySponsored by theRail Transit Vehicle Interface Standards Committee23 March 2005Print: SH95279PDF: SS95279Recognized as anAmerican N

2、ational Standard (ANSI)The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2005 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 23 March 2005. Printed in the United States of America.IEEE is a re

3、gistered trademark in the U.S. Patent +1 978 750 8400. Permission to photocopy portions of any individual standard for educationalclassroom use can also be obtained through the Copyright Clearance Center.NOTEAttention is called to the possibility that implementation of this standard may require use

4、of subjectmatter covered by patent rights. By publication of this standard, no position is taken with respect to theexistence or validity of any patent rights in connection therewith. The IEEE shall not be responsible foridentifying patents for which a license may be required by an IEEE standard or

5、for conducting inquiries into thelegal validity or scope of those patents that are brought to its attention.Copyright 2005 IEEE. All rights reserved. iiiIntroductionThis introduction is not part of IEEE Std 1558-2004, IEEE Standard for Software Documentation for Rail Equipmentand Systems.Software is

6、 used in many facets of the rail transit industry, including real-time software control ofelectronics on rail vehicles, wayside control, and centralized operations control centers. Over time, thenumber, complexity, and interconnectivity of these systems have increased, while expectations for trouble

7、-free operation have increased. Systems in this industry require the interaction of many software-basedsubsystems often provided by multiple suppliers.Documentation, developed and contractually required for software-based subsystems, has evolved as well.Variation in the interpretation of the existin

8、g IEEE software standards has occurred within the rail transitindustry. Although similarities in software documentation exist, both from project-to-project and fromsupplier-to-supplier, the differences lead to lack of commonality and increased review time by the acquirer.Also, the application of the

9、 existing IEEE standards within the rail transit industry has led to redundancy ofinformation in the resulting documents. Redundant information has led to inconsistency and ambiguity.This standard is intended to reduce the variation in the interpretation of the referenced software standards.In addit

10、ion, this standard minimizes the duplication of information in the resulting set of documents aswould result if each IEEE standard was implemented in its entirety.This documentation standard establishes a uniform set of documents, consistent terminology, and a uniforminterpretation of the underlying

11、 referenced software standards. Use of this standard will provide acquirersand suppliers with a consistent document set as well as a consistent set of contents.This standard places requirements on the software development process. However, this standard neitherdefines a software development practice

12、 (particularly as it relates to safety critical software or a softwaredevelopment life cycle) nor does it require a particular design methodology or programming language.Notice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.o

13、rg/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata periodically.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementat

14、ion of this standard may require use of subject mattercovered by patent rights. By publication of this standard, no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patentsor patent applications

15、 for which a license may be required to implement an IEEE standard or for conductinginquiries into the legal validity or scope of those patents that are brought to its attention.iv Copyright 2005 IEEE. All rights reserved.ParticipantsThe following is a list of participants in the the Software Docume

16、ntation for Rail Equipment and SystemsWorking Group.Paul E. Jamieson, ChairThe following members of the individual balloting committee voted on this standard. Balloters may havevoted for approval, disapproval, or abstention. When the IEEE-SA Standards Board approved this standard on 23 September 200

17、4, it had the followingmembership:Don Wright, ChairSteve M. Mills, Vice ChairJudith Gorman, Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board liaisons:Satish K. Aggarwal, NRC RepresentativeRichard DeBlasio, DOE RepresentativeAlan Cookson, NIST RepresentativeD

18、on MessinaIEEE Standards Project EditorLinda Sue BoehmerVincent J. CavataioLori J. ColangeloJohn H. CorvinDenise Edgecomb-CopeByron FrankWilliam R. MacArthurBonnie McDonoughShantilal MorarFrancois OuelletteMarilyn M. PhillipsCharles PleckaitisThomas TougasRobert AndersonKarl W. BergerLinda Sue Boehm

19、erRobert J. DiSilvestroJim DietzClaude GabrielHarold C. GillenHarvey GlickensteinJames R. HoelscherPaul E. JamiesonKevin D. JohnsonDon KaneWerner KaterkampWalter R. KeevilJohn LaForceDavid A. MaleThomas J. McGeanJohn McGregorKamel MokhtechHoward MoodyEdwin A. MortlockPatrick MurphyRobert D. PascoeWi

20、lliam PetitDavid R. PhelpsVenkat Rao PindiproluAlan F. RumseyLouis SandersAlexander SinyakThomas J.SullivanArun VirginkarChuck AdamsH. Stephen BergerMark D. BowmanJoseph A. BruderBob DavisRoberto de Marca BoissonJulian Forster*Arnold M. GreenspanMark S. HalpinRaymond HapemanRichard J. HollemanRichar

21、d H. HulettLowell G. JohnsonJoseph L. Koepfinger*Hermann KochThomas J. McGeanDaleep C. MohlaPaul NikolichT. W. OlsenRonald C. PetersenGary S. RobinsonFrank StoneMalcolm V. ThadenDoug ToppingJoe D. WatsonCopyright 2005 IEEE. All rights reserved. vContents1. Overview 11.1 Scope 11.2 Purpose. 11.3 Exis

22、ting applications 12. References 13. Definitions, acronyms, and abbreviations 23.1 Definitions . 23.2 Acronyms and abbreviations . 34. General requirements . 34.1 Software documentation overview 34.2 Deliverables section . 55. Document outlines . 65.1 SPMP . 65.2 SQAP . 65.3 SCMP. 65.4 SVVP . 65.5 S

23、VVR. 75.6 SRS 75.7 SDD . 75.8 ICD. 75.9 DBDD 75.10 SRTM. 75.11 STP. 85.12 STPr . 85.13 STR 85.14 SVD . 85.15 SUM. 86. Document format . 86.1 General requirements. 96.2 Title page . 96.3 Revision sheet 96.4 Table of contents 96.5 List of figures. 96.6 List of tables. 106.7 Body. 106.8 Appendix 10Anne

24、x A (normative) Document contents . 11Annex B (informative) Bibliography. 60Copyright 2005 IEEE. All rights reserved. 1IEEE Standard for Software Documentation for Rail Equipment and Systems1. Overview1.1 ScopeThis standard establishes the minimum requirements for application software documentation

25、throughout thesoftware development life cycle for rail equipment and systems including associated test and maintenanceequipment.1.2 PurposeMany differing requirements for application software documentation are presently being specified forsoftware used in rail equipment and systems and for related a

26、pplications, which has led to a lack ofstandardization in the information provided on equipment and systems incorporating software. Thisstandard, when used by the authority having jurisdiction, car builders, and system/subsystem suppliers, isintended to specify documents that improve the understandi

27、ng of software functionality, facilitate softwarecorrections and upgrades, improve on-time delivery, and lower software acquisition and maintenance costs.1.3 Existing applicationsExisting projects in progress before the effective date of this standard need not comply with the new orrevised requireme

28、nts of this edition, except where specifically required by the authority having jurisdiction.2. ReferencesThis standard shall be used in conjunction with the following publications. EIA/IEEE J-STD-016-1995, Trial-Use Standard for Information Technology Software Life Cycle ProcessSoftware Development

29、 Acquirer-Supplier Agreement (withdrawn).11EIA/TIA publications are available from Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112, USA (http:/ 1558-2004 IEEE STANDARD FOR SOFTWARE DOCUMENTATION2 Copyright 2005 IEEE. All rights reserved.IEEE Std 610.12TM-1990, IEEE Standard

30、Glossary of Software Engineering Terminology.2, 3IEEE Std 730TM-2002, IEEE Standard for Software Quality Assurance Plans.IEEE Std 828TM-1998, IEEE Standard for Software Configuration Management Plans.IEEE Std 829TM-1998, IEEE Standard for Software Test Documentation.IEEE Std 830TM-2002, IEEE Recomme

31、nded Practice for Software Requirements Specifications.IEEE Std 1012TM-1998, IEEE Standard for Software Verification and Validation.IEEE Std 1016TM-1998, IEEE Recommended Practice for Software Design Descriptions.IEEE Std 1058TM-1998, IEEE Standard for Software Project Management Plans.IEEE/EIA Std

32、12207.0TM-1996, IEEE/EIA Standard Industry Implementation of International Standard ISO/IEC 12207: 1995 (ISO/IEC 12207), Standard for Information Technology-Software Life Cycle Processes.IEEE/EIA Std 12207.1TM-1997, Industry Implementation of International Standard ISO/IEC 12207: 1995.(ISO/IEC 12207

33、), Standard for Information Technology-Software Life Cycle Processes-Life Cycle Data.3. Definitions, acronyms, and abbreviations3.1 DefinitionsFor the purposes of this standard, the following terms and definitions apply.The Authoritative Dictionary ofIEEE Standards Terms B1 and IEEE Std 610.12-1990

34、should be referenced for terms not defined in thisclause.4,53.1.1 software integrity level: A denotation of a range of values of a property of an item necessary to main-tain system risks within acceptable limits. For items that perform mitigating functions, the property is thereliability with which

35、the item must perform the mitigating function. For items whose failure can lead to athreat, the property is the limit on the frequency of that failure.2IEEE publications are available from the Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http:/st

36、andards.ieee.org/).3The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.4The numbers in brackets correspond to those of the bibliography in Annex B.5Information on references can be found in Clause 2.IEEEFOR RAIL EQUI

37、PMENT AND SYSTEMS Std 1558-2004Copyright 2005 IEEE. All rights reserved. 33.2 Acronyms and abbreviationsDBDD database design descriptionDBMS database management systemEIA Electronic Industries AssociationICD interface control documentIEEE Institute of Electrical and Electronics Engineers, Inc.SCI(s)

38、 software configuration item(s)SCM software configuration managementSCMP software configuration management planSDD software design descriptionSPMP software project management planSQA software quality assuranceSQAP software quality assurance planSRS software requirements specificationSRTM software re

39、quirements traceability matrixSTP software test planSTPr software test procedureSTR software test reportSUM software users manualSVD software version descriptionSVVP software verification and validation planSVVR software verification and validation reportV it will also sum-marize the history of syst

40、em development, op-eration, and maintenance.4.11.1 Project summaryMandatory 4.1.11.1.1 Purpose, scope, and objectivesMandatory In addition, identify in-tended audience.4.1.1.11.1.1.1 Context diagramMandatory Depict the overall system and shall identify system and elements covered by this plan. A sys

41、tem con-text diagram shows the interface between the sys-tem provided and the external environment with which it interacts.Added1.1.1.2 Functional elementsMandatory Identify and describe each of the SCI(s) developed and its associated software integrity level for per-forming V&V tasks.Added1.1.2 Ass

42、umptions and constraintsMandatory 4.1.1.2IEEEFOR RAIL EQUIPMENT AND SYSTEMS Std 1558-2004Copyright 2005 IEEE. All rights reserved. 131.1.3 Project work productsMandatory List all work products used/produced. The work product list may include work products not identi-fied in this standard. It shall i

43、dentify whether each work product is ei-ther deliverable or nondeliverable to the acquirer. The media used for deliv-ery shall be identified.4.1.1.3 This clause is renamed and expanded to include the identifica-tion of nondeliverable work products as well.1.1.4 Schedule andbudget summaryMandatoryRec

44、ommendedThis plan may be incorpo-rated directly or by citing a reference to other plans. The schedule summary shall also include delivery dates for the project deliv-erables. Dates may be defined as specific dates, or relative to contractual and/or business milestones.A budget summary may be provide

45、d.4.1.1.4 Added delivery dates to deliverables defined in section.Budget information is recommended but not mandatory. The devel-oper may delete this information, especial-ly if the project has a fixed cost.1.2 Evolution of the SPMPMandatory 4.1.22.0 References Mandatory Complete list of all docu-me

46、nts referenced within this document.Omit the last sentence of 4.2, which states that, “Any deviations from the referenced standards or policies shall be identified and justification shall be provided.”4.2 Deviations from refer-enced standards are described in the spe-cific section making the referen

47、ce.3.0 Definitions Mandatory 4.34.0 Project organizationMandatory 4.44.1 External interfacesMandatory 4.4.14.2 Internal structureMandatory 4.4.2Table A.1SPMP: Reference standard IEEE Std 1058-1998 (continued)Document sectionContent list Applicability GuidanceReference standard clauseChanges to refer

48、ence standardIEEEStd 1558-2004 IEEE STANDARD FOR SOFTWARE DOCUMENTATION14 Copyright 2005 IEEE. All rights reserved.4.3 Roles and responsibilitiesMandatory 4.4.35.0 Managerial process plansMandatory This plan may be incorpo-rated directly or by citing a reference to other plans.4.55.1 Project startup

49、 planRecommended 4.5.15.1.1 Estimation plan Recommended This plan may be incorpo-rated directly or by citing a reference to other plans.4.5.1.15.1.2 Staffing plan Recommended This plan may be incorpo-rated directly or by citing a reference to other plans.4.5.1.25.1.3 Resourceacquisition planRecommended 4.5.1.35.1.4 Project stafftraining planRecommended 4.5.1.45.2 Work plan Mandatory This plan may be incorpo-rated directly or by citing a reference to other plans.4.5.25.2.1 Work activities Mandatory This plan may be incorpo-rated directly or by