ImageVerifierCode 换一换
格式:PDF , 页数:23 ,大小:302.80KB ,
资源ID:1248095      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-1248095.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(IEEE 1228-1994 en Standard for Software Safety Plans (IEEE Computer Society)《计算机软件安全方案》.pdf)为本站会员(proposalcash356)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

IEEE 1228-1994 en Standard for Software Safety Plans (IEEE Computer Society)《计算机软件安全方案》.pdf

1、The Institute of Electrical and Electronics Engineers, Inc.345 East 47th Street, New York, NY 10017-2394, USACopyright 1994 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 1994. Printed in the United States of America.Print: ISBN 1-55937-496-6 SH94255PDF:

2、 ISBN 0-7381-0419-1 SS94255No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.IEEE Std 1228-1994 (R2010)IEEE Standard for SoftwareSafety PlansSponsorSoftware Engineering Standards Committeeo

3、f theIEEE Computer SocietyReaffirmed 25 March 2010Approved 17 March 1994IEEE-SA Standards BoardReaffirmed 18 April 2003Approved 2 September 1994American National Standards InstituteAbstract: The minimum acceptable requirements for the content of a software safety plan areestablished. This standard a

4、pplies to the software safety plan used for the development, procure-ment, maintenance, and retirement of safety-critical software. This standard requires that the planbe prepared within the context of the system safety program. Only the safety aspects of the soft-ware are included. This standard do

5、es not contain special provisions required for software used indistributed systems or in parallel processors.Keywords: safety-critical software, software safety plan, software safety program, safety require-mentsIEEE Standards documents are developed within the IEEE Societies and the Standards Coord

6、inating Committees of theIEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus develop-ment process, approved by the American National Standards Institute, which brings together volunteers representing variedviewpoints and interests to achieve the

7、final product. Volunteers are not necessarily members of the Institute and serve with-out compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus devel-opment process, the IEEE does not independently evaluate, test, or verify the accuracy of an

8、y of the information containedin its standards.Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other dam-age, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resultingfrom the p

9、ublication, use of, or reliance upon this, or any other IEEE Standard document.The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaimsany express or implied warranty, including any implied warranty of merchantability or fitness for a s

10、pecific purpose, or thatthe use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market,or provide other goods and servic

11、es related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at thetime a standard is approved and issued is subject to change brought about through developments in the state of the art andcomments received from users of the standard. Every IEEE Standard is subjected to review

12、at least every five years for revi-sion or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to concludethat its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to checkto determine

13、 that they have the latest edition of any IEEE Standard.In publishing and making this document available, the IEEE is not suggesting or rendering professional or other servicesfor, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person orentit

14、y to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a com-petent professional in determining the exercise of reasonable care in any given circumstances.Interpretations: Occasionally questions may arise regarding the meaning of portions of st

15、andards as they relate to specificapplications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepareappropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that anyinterpretati

16、on has also received the concurrence of a balance of interests. For this reason, IEEE and the members of itssocieties and Standards Coordinating Committees are not able to provide an instant response to interpretation requestsexcept in those cases where the matter has previously received formal cons

17、ideration. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation withIEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriatesupporting comments. Comments on standards and re

18、quests for interpretations should be addressed to:Secretary, IEEE-SA Standards Board445 Hoes LanePiscataway, NJ 08854USAAuthorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute ofElectrical and Electronics Engineers, Inc., provided that

19、the appropriate fee is paid to Copyright Clearance Center. Toarrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educationalclassro

20、om use can also be obtained through the Copyright Clearance Center.Note: Attention is called to the possibility that implementation of this standard may require use of subject mat-ter covered by patent rights. By publication of this standard, no position is taken with respect to the existence orvali

21、dity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patentsfor which a license may be required by an IEEE standard or for conducting inquiries into the legal validity orscope of those patents that are brought to its attention.iiiIntroduction(This intr

22、oduction is not part of IEEE Std 1228-1994, IEEE Standard for Software Safety Plans.)This standard describes the minimum acceptable requirements for the content of a software safety plan. Thisstandard contains four clauses. Clause 1 discusses the application of the standard. Clause 2 lists reference

23、s toother standards. Clause 3 provides a set of denitions and acronyms used in the standard. Clause 4 containsthe required content of a software safety plan. In order to be in compliance with this standard, users of thestandard shall adhere to clause 4. The informative annex discusses software safet

24、y analyses.This standard was written for those who are responsible for dening, planning, implementing, or supportingsoftware safety plans.Participants in the working group were individually supported by their employers with travel expenses andworking days. This support does not constitute or imply a

25、pproval or endorsement of this standard.This standard was developed by the Software Safety Plans Working Group consisting of the followingmembers who attended two or more meetings, provided text, or submitted comments on two or more draftsof the standard.Cynthia L. Wright,ChairAnthony J. Zawilski,Vi

26、ce chairPatricia Trellue,Conguration managerDick Bair John Horch Norman SchneidewindLeo Beltracchi Grady Lee David SchultzMordechai Ben-Menachem Nancy Leveson Anita ShagneaP. V. Bhansali Stanley Levinson Peter ShillingDavid Burrows Ben Livson Edgar SibleyBetty Chao D. P. Mannering Mel SmyreJohn Cher

27、viavsky Scott Mathews Jack SpraulTony Clark John McHugh Leslie StepanekTaz Daughtrey Archibald McKinlay V. K. SrivastavaDavid Dini Bonnie Melhart Leonard TrippL. G. Egan Bret Michael Ron VaickavskiAlwyn Goodloe Tammy Pelnik Delores WallaceHerb Hecht John Perry Chuck WeinstockThe following individual

28、s also contributed to the development of the standard by attending one meeting orproviding comments on one draft:Paul Ammann John Harauz Dave PeercyJordan Anderson Albert Hoheb Dev RahejaRon Berlack Charles Horn Steven RakitinRichard Blauw Frank Houston Juri ReinfeldsThomas Braudt Diane Jachinowski

29、Heinz RogenJ. Brazendale Jon Jacky Art RubinoFletcher Buckley George Kambic Leonard RussoDavid Card Alasdair Kemp Damian SaccochioJames Cardow Phil Keys Hans SchaeferGeoff Cozens Thomas Kurihara Robert ShillatoRon Daly Victor Maggioli Richard ThayerPaul Davis John Matras Jerry ThrasherC. G. Diderich

30、 A. D. McGettrick Dinos TsagoesAudrey Dorofee Rovert Metro David VickersCaroline Evans Judy Moore Jim WidmyerPeter Farrell-Vinay Bahman Mostafazadeh Eugene WilhelmFred Freiburger Melissa Murphy Bill WoodAl Friend Dennis Nickle N. YogaramananDavid Gelperin Mark Oliver Janusz ZalewskiDonna Grush Tunce

31、r Oren Peter ZollivThe following persons were on the balloting committee:William Bates William Heey Dave PeercyMordechai Ben-Menachem Janene Heinzman Tammy PelnikRon Berlack David Heron Juri ReinfeldsSandro Bologna John Horch James RonbackFletcher Buckley Charles Howell Stephen SchachKay Bydalek Lyn

32、n Ihlenfeldt Hans SchaeferDavid Card William Junk Norman SchneidewindBetty Chao George Kambic David SchultzTony Clark Thomas Kurihara Gregory SchumacherGeoff Cozens Robert Lane Robert ShillatoTaz Daughtrey Charles Lavine Edgar SibleyPaul Davis Dennis Lawrence Mel SmyreEinar Dragstedt Nancy Leveson V

33、. K. SrivastavaL. G. Egan Stanley Levinson Richard ThayerCaroline Evans Ben Livson George TiceJohn Fendrich Joseph Maayan Patrica TrellueJoanna Frawley John MacMillan Leonard TrippRoger Fujii Jukka Marijarvi Ron VaickavskiDavid Gelperin Roger Martin David VickersYair Gershkovitch Scott Mathews Udo V

34、ogesJulio Gonzalez-Sanz Ivano Mazza Delores WallaceDavid Gustafson John McHugh Paul WorkJohn Harauz James Michael Cynthia WrightHerb Hecht Dennis Nickle Janusz ZalewskiWhen the IEEE Standards Board approved this standard on March 17, 1994, it had the followingmembership:Wallace S. Read,ChairDonald C

35、. Loughry,Vice ChairAndrew G. Salem,SecretaryGilles A. Baril Donald N. Heirman Joseph L. Koepnger*Bruce B. Barrow Richard J. Holleman D. N. Jim LogothetisJos A. Berrios de la Paz Jim Isaak L. Bruce McClungClyde R. Camp Ben C. Johnson Marco W. MigliaroJames Costantino Sonny Kasturi Mary Lou PadgettSt

36、ephen L. Diamond Lorraine C. Kevra Arthur K. ReillyDonald C. Fleckenstein E. G. Al Kiener Ronald H. ReimerJay Forster* Ivor N. Knight Gary S. RobinsonRamiro Garcia Leonard L. Tripp*Member EmeritusAlso included are the following nonvoting IEEE Standards Board liaisons:Satish K. AggarwalJames BeallRic

37、hard B. EngelmanDavid E. SoffrinStanley I. WarshawRachel A. MeiselIEEE Standards Project EditorvContentsCLAUSE PAGE1. Overview 11.1 Purpose. 11.2 Scope 11.3 Application. 11.4 Disclaimer 22. References 23. Definitions and abbreviations 33.1 Definitions 33.2 Abbreviations. 34. Contents of a software s

38、afety plan. 44.1 Purpose (Section 1 of the Plan) 54.2 Definitions, acronyms and abbreviations, and references (Section 2 of the Plan) 54.3 Software safety management (Section 3 of the Plan) 54.4 Software safety analyses (Section 4 of the Plan). 104.5 Post development (Section 5 of the Plan) 124.6 Pl

39、an approval (Section 6 of the Plan) 14ANNEXDiscussion of software safety analyses (informative) . 15A.1 Software safety requirements analyses 15A.2 Software safety design analysis . 15A.3 Software safety code analysis 16A.4 Software safety test analysis 17A.5 Software safety change analysis 171IEEE

40、Standard for Software Safety Plans1. Overview1.1 PurposeThis standard establishes the minimum acceptable requirements for the content of a Software Safety Plan(also referred to as thePlan) to address the processes and activities intended to improve the safety of safety-critical software.1.2 ScopeThi

41、s standard applies to the Plan used for the development, procurement, maintenance, and retirement ofsafety-critical software; for example, software products whose failure could cause loss of life, serious harm,or have widespread negative social impact. This standard requires that the Plan be prepare

42、d within the con-text of the system safety program. The scope of this standard includes only the safety aspects of the soft-ware. This standard does not contain special provisions required for software used in distributed systems orin parallel processors.1.3 ApplicationThe Plan is prepared under the

43、 direction of project or system safety program management to address theidentied potential software safety risks.Compliance with this standard requires the creation of a written plan that addresses each topic, subtopic, andstipulation described in clause 4. The level of detail in, and the resources

44、required by an software safety planwill be determined by factors including the type and level of risks associated with the software product, thecomplexity of the application, and external forces such as contractual requirements.Software is a portion of a system. Other portions of that system include

45、 computer hardware, other devices(possibly including mechanical, electrical, chemical, or nuclear devices), and people. Software alone is not asafety issue; it is only an issue in the context of this larger system. Hence, software safety must begin withthe larger system. Software safety must be cons

46、idered in the context of its associated hardware, environ-ment, and operators. The Plan needs to address interfaces with these elements.The existence of this standard should not be construed to discourage or prohibit the imposition of additionalor more stringent requirements where the need exists. A

47、n assessment should be made for the specic soft-ware project to ensure adequacy of coverage and safety assurance. Where this standard is invoked for aIEEEStd 1228-1994 IEEE STANDARD FOR 2project engaged in producing several software products, the applicability of the standard should be speciedfor ea

48、ch of the software products encompassed by the project. This standard contains a minimum set ofrequirements for the content of software safety plans. The addition of more stringent requirements shall bethe only acceptable tailoring process for this standard.1.4 DisclaimerPreparation of software safe

49、ty plans according to this standard does not automatically ensure softwaresafety. Compliance with this standard does not absolve the software designer, producer, or vendor from anystatutory obligations.2. ReferencesThis standard shall be used in conjunction with the following publications.The latest revisions shall apply.IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).1IEEE Std 730-1989, IEEE Standard for Software Quality Assurance Plans (ANSI).IEEE Std 828-1990, IEEE Standard for Software Conguration Management Plans (ANSI).IEEE Std 829

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1