This is the Malaysian Standard for Sewerage DesignFull description
workbench plans
Grade 10 Module 4 lessons 1 and 2Full description
Descripción: Como hacer una casa club para niñas y niños
Descripción completa
Proyectos en Madera de YellawoodDescripción completa
Descripción: ship plans
Descripción completa
Lesson plans
Electrical plan sampleFull description
Magic
lesson plans
Ingeniería de softwareDescripción completa
IEEE Std 1228-1994
IEEE Standard for Software Safety Plans
Sponsor
Software Engineering Standards Committee of the IEEE Computer Society ppro!ed "arch 1#$ 1994
IEEE Standards %oard &stract' (he minimum accepta&le re)uirements for the content of a software safety plan are esta&lished* (his standard applies to the software safety plan used for the de!elopment$ procure-ment$ maintenance$ and retirement of safety-critical software* (his standard re)uires that the plan &e prepared within the conte+t of the system safety program* ,nly the safety aspects of the soft-ware are included* (his standard does not contain special pro!isions re)uired for software used in distri&uted systems or in parallel processors* eywords' safety-critical software$ software safety plan$ software safety program$ safety re)uirements
(he Institute of Electrical and and Electronics Electronics Engineers$ Engineers$ Inc* .4/ East East 4#th Street$ 0ew or$ 0 1331#-2.94$ S IS%0 1-//9.#-42/-5 Copyright 6 1994 &y the Institute of Electrical and Electronics Engineers$ Engineers$ Inc* ll rights reser!ed* Pu&lished Pu&lished 1994* Printed Printed in the nited States of merica* Print' IS%0 1-//9.#497-9$ S942// P:' IS%0 3-#.81-3419-1$ 3-#.81- 3419-1$ SS942// 0o part of this pu&lication may &e reproduced in any form$ in an electronic retrie!al retrie!al system or otherwise$ without the prior written permission of the pu&lisher*
IEEE Standards documents are de!eloped within the (echnical Committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards %oard* "em&ers of the committees ser!e !oluntarily and without compensation* (hey are not necessarily mem&ers of the Institute* (he standards de!eloped within IEEE represent a consensus of the &road e+pertise on the su&;ect within the Institute as well as those acti!ities outside of IEEE that ha!e e+pressed an interest in partici-pating in the de!elopment of the standard* se of an IEEE Standard is wholly !oluntary* (he e+istence of an IEEE Standard does not imply that there are no other ways to produce$ test$ measure$ purchase$ mar-et$ or pro!ide other goods and ser!ices related related to the scope of the IEEE Standard* :urthermore$ :urthermore$ the !iewpoint e+pressed e+pressed at the time a standard is appro!ed and issued is su&;ect to change &rought a&out through de!elopments in the state of the art and comments recei!ed from users of the standard* E!ery IEEE Standard is su&;ected to re!iew at least e!ery
!alue$ do not wholly reane P*,* %o+ 1..1 Piscataway$ 0? 388//-1..1 S
IEEE standards documents may in!ol!e the use of patented technology* technology* (heir appro!al appro!al &y the Institute of Electrical and Electronics Engineers does not mean that using such technology for the purpose of conforming to such standards is authori@ed &y the patent owner* owner* It is the o&ligation of the user of such technology to o&tain all necessary permissions*
Introduction A(his introduction is not part of IEEE Std 1228-1994$ IEEE Standard for Software Safety Plans*B
(his standard standard descri&es the minimum accepta&le accepta&le re)uireme re)uirements nts for the content content of a software software safety safety plan* (his standard contains four clauses* Clause 1 discusses the application of the standard* Clause 2 lists references to other standards* Clause . pro!ides a set of de* =right$ Chair nthony ?* Dawilsi$ Vice chair Patricia (rellue$ Configuration manager ic %air ?ohn orch 0orman Schneidewind >eo %eltracchi rady >ee a!id Schult@ "ordechai %en"enachem 0ancy >e!eson nita Shagnea P* * * %hansali Stanley >e!inson Peter Shil ling a!id %urrows %en >i!son Edgar Si&ley %etty Chao * P* "annering "el Smyre ?ohn Cher!ia!sy Scott "athews ?ac Spraul (ony Clar ?ohn "cugh >eslie Stepane (a@ (a@ aughtrey rchi&ald "cinlay * * Sri!asta!a a!id ini %onnie "elhart >eonard (ripp (ripp >* * Egan %ret "ichael Fon aica!si aica!si lwyn oodloe (ammy (ammy Pelni elores =allace er& echt ?ohn Perry Chuc =einstoc =einstoc
(he following indi!iduals also contri&uted contri&uted to the de!elopment de!elopment of the standard standard &y attending one
=hen the IEEE Standards %oard appro!ed this standard on "arch 1#$ 1994$ it had the following mem&ership' illes * %aril onald 0* eirman ?oseph >* oepogothetis ?osK * %errios de la Pa@ ?im Isaa >* %ruce "cClung Clyde F* Camp %en C* ?ohnson "arco =* "igliaro ?ames Costantino Sonny asturi "ary >ou Padgett Stephen >* iamond >orraine C* e!ra rthur * Feilly onald C* :lecenstein E* * lJ iener Fonald * Feimer ?ay :orsterH I!or 0* night ary S* Fo&inson Famiro arcia >eonard >* (ripp
H"em&er Emeritus
lso included are the following non!oting IEEE Standards %oard liaisons' Satish * ggarwal ?ames %eall Fichard %* Engelman a!id E* SoGrin Stanley I* =arshaw
1* ,!er!iew 1*1 Purpose (his standard esta&lishes the minimum accepta&le re)uirements for the content of a Software Safety Plan Aalso referred to as the PlanB to address the processes and acti!ities intended to impro!e the safety of safety-critical software*
1*2 Scope (his standard applies to the Plan used for the de!elopment$ procurement$ maintenance$ and retirement of safety-critical softwareL for e+ample$ software products whose failure could cause loss of life$ serious harm$ or ha!e widespread negati!e social impact* (his standard re)uires that the Plan &e prepared within the con-te+t of the system safety program* (he scope of this standard includes only the safety aspects of the soft-ware* (his standard does not contain special pro!isions re)uired for software used in distri&uted systems or in parallel processors*
1*. pplication (he Plan is prepared under the direction of pro;ect or system safety program management to address the identi
su&topic$ and stipulation descri&ed in clause 4* (he le!el of detail in$ and the resources re)uired &y an software safety plan will &e determined &y factors including the type and le!el of riss associated with the software product$ the comple+ity of the application$ and e+ternal forces such as contractual re)uirements* Software is a portion of a system* ,ther portions of that system include computer hardware$ other de!ices Apossi&ly including mechanical$ electrical$ chemical$ or nuclear de!icesB$ and people* Software alone is not a safety issueL it is only an issue in the conte+t of this larger system* ence$ software safety must &egin with the larger system* Software safety must &e considered in the conte+t of its associated hardware$ en!iron-ment$ and operators* (he Plan needs to address interfaces with these elements* (he e+istence of this standard should not &e construed to discourage or prohi&it the imposition of additional or more stringent re)uirements where the need e+ists* n assessment should &e made for the speci
1*4 isclaimer Preparation of software safety plans according to this standard does not automatically ensure software safety* Compliance with this standard does not a&sol!e the software designer$ producer$ or !endor from any statutory o&ligations*
2* Feferences (his standard shall &e used in con;unction with the following pu&lications*(he latest re!isions shall apply* IEEE Std 713*12-1993$ IEEE Standard lossary of Software Engineering (erminology A0SIB* 1 IEEE Std #.3-1989$ IEEE Standard for Software Muality ssurance Plans A0SIB*IEEE Std 828-1993$ IEEE Standard for Software Con
Software >ife Cycle Processes*
1
IEEE pu&lications are a!aila&le from the Institute of Electrical and Electronics Engineers$ 44/ oes >ane$ P*,* %o+ 1..1$ Piscataway$ 0? 388//-1..1$ S* 2 IEEE Std 98.-1987 has &een withdrawnL howe!er$ copies can &e o&tained from the IEEE Standards epartment$ 44/ oes >ane$ P*,*%o+ 1..1$ Piscataway$ 0? 388//-1..1$ S*
.* e
.*2 &&re!iations (he following appear within the te+t of this standard' P Preliminary a@ards nalysis SP"P Software Pro;ect "anagement Plan SFS Software Fe)uirements Speci
.
Information on references can &e found in clause 2*
4* Contents of a software safety plan In order to &e in compliance with this standard$ the contents of a software safety plan Aalso referred to as the PlanB shall include the sections shown in the following outline* n e+planation of what each section should contain is in the su&clauses following the outline* In a particular plan$ if there is no information pertinent to a section or a re)uired paragraph within a section$ the following shall appear &elow the section or paragraph heading together with the appropriate reason for the e+clusion' This section/paragraph is not applicable to this Plan.
dditional sections may &e added at the end of the Plan as re)uired* If some of the material appears in other documents$ reference to those documents shall &e made in the &ody of the Plan*
1
Purpose
2
e
.* Software safety management
2
.*1 ,rgani@ation and responsi&ilities
3
.*2 Fesources
4
.*. StaG )uali
5
.*4 Software life cycle
6
.*/ ocumentation re)uirements
7
.*7 Software safety program records
8
.*# Software con
9
.*8 Software )uality assurance acti!ities
10 .*9 Software !eri
Plan appro!al
Software safety plan outline
4*1 Purpose ASection 1 of the PlanB (his section of the Plan shall de
that are e+pected to &e achie!ed &y adherence to the Plan* (he accepta&le riss and safety o&;ecti!es speci
4*2 e
4*. Software safety management ASection . of the PlanB (his section of the Plan shall descri&e the organi@ation$ schedule$ resources$ responsi&ilities$ tools$ techni)ues$ and methodologies used in the de!elopment of safety-critical software* 4*.*1 ,rgani@ation and responsi&ilities A.*1 of the PlanB (his section of the Plan shall depict the software safety acti!ities within the o!erall organi@ation and shall descri&e organi@ational and functional relationships pertaining to software safety issues$ lines of communi-cation$ and authority* (he relationship of software safety program tass to system safety program tass$ if present$ shall &e descri&ed* (he relationship &etween other organi@ations ha!ing responsi&ility for tass impacting software safety and the organi@ation managing the software safety program shall &e presented* ,!ersight$ re!iew$ and appro!al authority of software safety program tass shall &e descri&ed in this section of the Plan* (he authority of the software safety program management to enforce compliance with safety re)uirements and practices shall &e descri&ed* (his section of the Plan shall identify one person to &e responsi&le for the o!erall conduct of the software safety program* (his indi!idual and other personnel responsi&le for software safety acti!ities shall ha!e suf-
software safety program implementation* Fesources shall include$ &ut not &e limited to$
e
(his section of the Plan shall de
eBSoftare safety design. escriptions of the software design elements that satisfy the software safety re)uirements shall &e prepared* :urther guidance for this documentation may &e found in IEEE Std 1317-198#* fBSoftare de"elopment methodology# standards# practices# metrics# and con"entions. ppro!ed and controlled practices that are essential to satisfy system and software safety o&;ecti!es and re)uirements shall &e speci
Plan shall de
Software de!elopment tools Pre!iously de!eloped software endor-pro!ided software Su&contractor-de!eloped software
4*.*8 Software )uality assurance acti!ities A.*8 of the PlanB (his section of the Plan shall descri&e the role of software )uality assurance in ensuring proper performance of ey software safety program acti!ities* uidance on planning software )uality assurance and preparing software )uality assurance plans can &e found in IEEE Std #.3-1989 and IEEE Std 98.-1987* (his section of the Plan shall include$ at a minimum$ descriptions of how aB (he Plan is prepared$ appro!ed$ implemented$ changed$ and made consistent with predecessor documents &B
(he technical recommendations resulting from software safety tass are re!iewed$ considered &y change control authority$ and$ where appropriate$ implemented cB (he re!iews and audits will address software safety concerns$ re)uirements$ guidelines$ and process certi
(ool appro!al for use on the pro;ect Installation of upgrades to pre!iously appro!ed tools =ithdrawal of a pre!iously appro!ed tool Identi
(his section of the Plan shall descri&e how the possi&ility of inad!ertent introduction of software ha@ards &y pro;ect tools will &e controlled* 4*.*11 Pre!iously de!eloped or purchased software A.*11 of the PlanB (his section of the Plan shall state the pro!isions for ensuring that pre!iously de!eloped or purchased software meets the re)uirements of the safety-critical application$ shall de
de!eloped or purchased software with respect to the pro;ectOs re)uirements* eB :ollowing an appro!ed test plan$ test the safety-critical features of the pre!iously de!eloped or purchased software independent of the pro;ectOs software* fB :ollowing an appro!ed test plan$ test the safety-critical features of the pre!iously de!eloped or pur-chased software with the pro;ectOs software* gB Perform a ris assessment to determine if the use of the pre!iously de!eloped or purchased software will result in undertaing an unaccepta&le le!el of ris* ,nly pre!iously de!eloped or purchased software that 1B can &e ade)uately tested$ 2B presents accepta&le ris$ or .B remains safe in the conte+t of its planned use shall &e used in safety-critical software products* (he ina&ility to determine the le!el of ris present or the conse)uence of failure shall &e suf
(his section of the Plan shall re)uire that certain software safety-related analyses &e performed as part of the software de!elopment process* See the anne+ for a discussion of software safety analyses* 4*4*1 Software safety analyses preparation A4*1 of the PlanB (his section of the Plan shall de
Preliminary a@ard nalysis APB and any additional ha@ard analyses performed on the entire system or any portion of the system that identi
&B high-le!el system design identifying those functions that will &e performed &y software and specifying the software safety-related actions that will &e re)uired of the software to pre!ent the system from entering a ha@ardous state$ or to mo!e the system from a ha@ardous state to a nonha@ardous state$ or to mitigate the conse)uences of an accident cB (he interfaces &etween the software and the rest of the system 4*4*2 Software safety re)uirements analysis A4*2 of the PlanB (his section of the Plan shall de
cB
(he types of analyses that will &e performed as part of the software safety re)uirements analysis$ and when they will occur ow the results of these analyses will pro!ide 1B n identi
4*4*. Software safety design analysis A4*. of the PlanB (his section of the Plan shall de
ware supports the system safety goals #B "odi
the system
4*/ Post de!elopment ASection / of the PlanB (his section of the Plan shall de
detect unauthori@ed modi
4*7 Plan appro!al ASection 7 of the PlanB (his section of the Plan shall specify the formal re!iew and inspection re)uirements for the Plan itself and the list of indi!iduals who must appro!e the Plan*
nne+ iscussion of software safety analyses Ainformati!eB Section .*4 of the Plan re)uires the speci
*1 Software safety re)uirements analyses (he software safety re)uirements analysis e!aluates software and interface re)uirements and identi
software safety re)uirements analysis* Speci
*2 Software safety design analysis (he software safety design analysis !eri
*. Software safety code analysis (he software safety code analysis !eri
these limitations$ to ensure that the program operates within them$ and to ensure that all interfaces ha!e &een considered for out-of-se)uence and erroneous inputs* eBProgramming style analysis ensures that all portions of the program follow appro!ed programming guidelines* fB*oncritical code analysis e+amines portions of the code that are not considered safety-critical code to ensure that they do not cause ha@ards* s a general rule$ safety-critical code should &e isolated from non-safety-critical code* (he intent of this analysis is to pro!e that this isolation is complete and that interfaces &etween safety-critical code and non-safety-critical code do not create ha@ards* If isolation is not pro!a&le$ the Plan should discuss how to handle the ris* gBTiming and si%ing analysis is further re
*4 Software safety test analysis Software safety test analysis demonstrates that safety re)uirements ha!e &een correctly implemented and the software functions safely within its speci
*/ Software safety change analysis (he starting point of the change analysis is the safety-critical design elements that are aGected directly or indirectly &y the change* (he purpose of software safety change analysis is to show that the change does not create a ha@ard$ does not impact on a pre!iously resol!ed ha@ard$ does not mae a currently e+isting ha@ard more se!ere$ and does not ad!ersely aGect any safety-critical software design element*
