ML20203K647

Rev 1 to RMS Software Quality Assurance Plan

ML20203K647
Person / Time
Site:	San Onofre
Issue date:	07/24/1995
From:	Edelman M, Piquemal P, Purpura G SOUTHERN CALIFORNIA EDISON CO.
To:
Shared Package
ML20203K553	List: ML20203K550 ML20203K647 ML20203K697 ML20203K713 ML20203K737 ML20203K759 ML20203K802 ML20203K846 ML20203K894 ML20203K914 ML20203L016 ML20203L026 ML20203L035 ML20203L687 ML20266F659
References
S0123-606-1-8-1, S123-606-1-8-1, NUDOCS 9803050172
Download: ML20203K647 (49)

Text

.

?-

1 1

2 1

i t

ENCLOSUREl RADIATION MONITORING SYSTEM QUALITY ASSURANCE PLAN j

(Also: DCN ABG-11507) 9803050172 990302 PDR ADOCK 05000361 88-

'P PDR 1.,..

m 3, y, 3_1,yg,7

$ I wnovso ~txNas Ncnso -m. %A PGD-00054 0 8 E maov50 - Ca"*a W==*a* b mww. Nm B to md b PGD0054A. DOC Revision 1 0 4. nara" names occumam-w.,m.n n ony July 23,1995 SOUTHERN MUFORNIA EWSON COMPANY

[ yg M

• *"*%;% M it 1 M #P

%'?A M @%% d.M "I

• • smo -'M-6 8L e L

=

=

Chemy CW Ret. Doc. No, JdW b4-444

• 8 **

, = -

un ou.cmen.

woswu m,.

ace va n,.

_,m

.,u.

RMS SOFTWARE QUALITY ASSURANCE PLAN S0/33 - 606 - /- N Reviewed by:

Reviewed by:

Reviewed by:

Name Pascal Piquemal Mike Edelman George Purpura Date f

f,8f ff 7 ) of-1E Signature h(f [

@w y Dr.

,+

=

adnec.

9 MGP

=

INSTRUMENTS Suite 150 5000 H!ghlands Parkway Smyma, GA 30082 i

MUlN W# ?'

M

PGD40054 / RDllSION 1 m ooc REVISION LOG:

Revision #

Date Revised Pages Comments 0

3/31/95 N/A Originalissue 1

7/20/95 All l

!1 C'

t l

l l

Page -ii-

PGD 00054 I REVISION 1 Poooos4A.coe TABLE OF CONTENTS Page 1.0 Attachment A: Software Quality Assurance Plan, MGPl Doc M5203GA....1

.s e

e e

./

Page -lii-

)

CD '

33 00 00 00 CD MCP ICSTRUMENTS' CA -

OS-07-D1 13:50 C3 OT E v-P3 SMlP Radiati6n Monitoring System

)

+

a gu 3

7w w:=

3

.;W I

Software Qual!ity Assurance Plan Written by:

L. Chapelot Date: 16.11.93 Signature:

Checked by:

A. Pommler Date: 16.11.93 Signature:

Approved by:

X.Duquesne _ Date: 1 s.11.s3 signaturc:

i IN HOUSE CIRCLILATION EXTERNAL CIRCULATION

]

L. Chapelot F. Schulcz MGP instruments Inc.

F. Chlosta G.Ruaro J.Nadaud B. Laisne j

A. Pommler J.P. Gulliemot i

Number of pages: 41 ar

'r GA 20/07/95 SCE Comments

...:. 4h. <C

[

\\

FA 02.05.95 MGPl inc comments t

' mot A-

a. uaur=

J.A 16.03.95 MGPi inc comments

/

/

/

DA 28.02.95 reviewed on 1995/02/20,

/

/

/

CA 28.11.94 SCE comments

/

/

/

BA 01.03.94 MGP Predston

/

/

/

AA 16.11.93 First issue i

W nte Check Approve Rev Date Name-No.& description of change M.F.

SIGNATURES I

ii

)

h- ~. -

w p r 9,,,,,; - ~ ~ % = "A %

~ l45203 GA F i-l I

l.

)

S,lenneensMGP Radiation Monitorir c 3, stem Sonware Quality Assurance Plan p2 Update Tables Rev. Index /Date Modified Pages Ongin and designation of the Written by modifk:stions M /16.11.93 Onginal version J.Nadaud L Mosley BA / 01.03.94 678101113-1416-19323747 Minor predslon L MESLAY 18-29-3043 Detailed design and component tests Precision 0A /28.11.94 All pops Reorganized SQAP outhne L Chapelot according to IEEE 730-1969 and SCE comments DA /28.02.95 4 pages Intomal and extemal comments (cf review report on 20.02.95)

EA /16.03.95 Pages 1 to 6 MGPlInc. comments (1ax 95.03.15) reviewed on 1995.03.16 FA /02.05.95 MGPl Inc. comments ( audit Anding n' 3 )

GA/17/07/95 M pages SCE Comments from S. Hetrick

& = M '=== 7 M E 7 S. ~

7= 5 E ~

m 45203 GA j

gllg,P Redulon Mordtoring System soeware ouemy Assurwe Men p3 Table ofContents 1 i ntroduction........................................................................................................... s 1.1. Purpose.................................................................................................5 1.2. Scope and Application............................................................................ s 1.2.1. Scope.......................................................................................s 1.2.2. Application............................................................................... 6 1.2. 3. Definition.................................................................................. 7 1.2.4 Abbreviations.......................................................................... 8 1.2.5. Acronymes & Notations........................................................... 9

2. Reference Documents.......................................................................................... 9 2.1. Customer's documents.......................................................................... 9 2.2. MGPl's documents................................................................................. 10

3. M anage ment........................................,............................................................... 1 1 3.1 Organization.......................................................................................... 1 1 3.2. Tasks.....................................................................................................12 3.2.1. Standard software.................................................................... 12 3.2.2. Safety related software............................................................ 12 3.2.2.1. Model Development Cycle......................................... 13 3.2.2.2. Product Development Cycle...................................... 14 3.2.3. Description of Phases..............................................................,14 3.2.3.1. Requirements Specification Phase............................15 3.2.3.2. Desip Phase............................................................ 16 3.2.3.3. Implememation Phase............................................... 16 3.2.3.4. Test Phase................................................................ 17 3.3.. Responsabilities..................................................................................... 19

4. Documentation..................................................................................................... 21 4.1. Purpose.................................................................................................21 4.2. Minimum documentation........................................................................ 21 4.2.1. Software Requirements Specification...................................... 21 4.2.2. Software Design Descriptions.................................................. 21 4.2.3. Software Vertfication and Validation Pire................................. 22 4.2.4. Software Vprtfication and Validation Final Report.................... 22 4.2.5. User documentation............................................................... 22 4.2.6. Test documentation............................................................... 22 4.2.6.1. Standard software..................................................... 22 4.2.6.2. Safety related software.............................................. 22 4.3. Other documentation............................................................................. 23 4.3.1. Software Development Plan.................................................... 23 4.3.2, Management documentation................................................... 23 4.4. Documentation Quality.......................................................................... 23 4.4.1. Application of Standards........................................................ 23 4.4.2. Review..................................................................................... 2 4 4.4.3. Document Control.................................................................... 24 4.4.4. Circulation................................................................................ 2 5 4.4. 5. Responsabilities....................................................................... 25

5. Standards, practises, conventions........................................................................ 27 5.1. Applicable standards for standard software........................................... 27 ne Pdesem%

n.

e e

e,.

,.. n.

e.

e n

45203 GA masmun et gepreeseen teases eu WeEAD de se Gumanere more rgewoumenere W and _

Ames to fus Sevues.

nodinon MonN&u _ tem sw seaware Quemy Assurance P6.,

p4 5.2. Applicable standards for safety related software.................................... 27 5.2.1. Documentation standards........................................................ 27 5.2.2. Design standards..................................................................... 27 5.2.3. Coding standards..................................................................... 27 5.2.4. Testing standards.................................................................... 27 5.2.5. Code operation / Maintenance standards.................................. 28 Ss Reviews and audits.............................................................................................. 28 6.1. Purpose.................................................................................................28 6.2. Document Reviews................................................................................ 2 8 6.2.1. Management............................................................................ 28 6.2.2. Software Development Plan review......................................... 29 6.2.3. Software Vertfication and Validation Plan review..................... 29 6.2.4. Software Configuration Management Plan review................... 29 6.2.5. Software Requirements Specification review........................... 30 6.2.6. Software Design Des 4%ns review....................................... 30 6.2.7. Component test review............................................................ 31 6.2.8. Integration review.................................................................... 31 6.2.9. Software test review................................................................ 31 6.2.10. System Integration test review................................................ 32 6.3 Audits..............................................................................................33 6.4. Quality Follow-up Documentation.....................................;..................... 33

7. Software Configuration Manac9 ment Plan........................................................... 33

8. Problem reporting and correchve action............................................................... 34 8.1 development phase................................................................................ 34 8.2. Mainte nance phase.............................................................................. 36

9. Tools, te"hniques, and methodologies................................................................. 38 9.1. Tools......................................................................................................23 9.1.1. Program Development Environment........................................ 38 9.1.2. Test Environment..................................................................... 39 9.1.3. Text Editing and Data Management......................................... 39 9.2.Rulos......................................................................................................39

10. Code control.................................................................................................... 39 10.1. Purpose................................................................................................. 39 10.2. Configuration items.'............................................................................ 39 10.3.1dentifiontion of items..................................................................... 40 10.4. identification and Configuration Conformance Procedures..................... 40 1 1. Media control................................................................................................ 4 0 1 1.1. Saving and Filing.................................................................................... 40 11.2. Software Reproduction........................................................................... 41 11.3. Software Access Control........................................................................ 41

12. S upplier control.............................................................................................. 41

13. Records collection, maintenance and retention.................................................. 41

14. Training..............................................................................................................41

15. Risk manage ment.....................................................t.......................................... 41 The pwalummers rerumum er repreammerg eeur peur er unsey, et sie -_ _, e run aamsee somna er eveen sensors, hAAEEher(1pthshuul et 45BenskER GERIAD R* PErtBGB GB SB dBehfREst SOrW MpRnf4tamugr4 WWErGREB, Gad adAMBEggm 4EFGD dB REE $$RWRE ggn

,m W

W

d l%.P MG nassson mm system

(_

sonware Quemy Assurance Plan p5

1. Introduction 1.1. Purpose The Software Quality Assurance Plan describes the policies and procedures established and practiced by MGPl employees to assure the quality of the software product it manufactures for Radiation Monitoring Systems projects. The intent of the SQAP is to establish a program of planned and systematic activities designed to schleve the required software qualities. These' actions assure that software products conform to the established technical requirements and that they perform satisfactorily. The essence of this SQAP is to prevent problems, to remove defects as they are found, to contribute to the usability and maintainability of the software, and to ensure that quality is built into the

~

product as it is being developped.

The Software Quality Assurance Manager of the project is responsible for writing the Software Quality Assurance Plan and ensuring that it is updateel whenever necessary.

The Project Manager of the project checks the Software Quality Assurance Plan.

The Quality Assurance department Manager approve the Software Quality Assurance Plan.

The Software Quality Assurance Plan identifies the documentation to be prepared during the development, verification and validation, use, and maintenance of software product.

The SOAP describes the organizational elements responsible for the origination, verification and validation, maintenance, and control of the required documentation. It also identifies the specific reviews, audits, and the associated criteria required for each document. The SQAP specifies the tools, techniques, and methodolog!es to be followed during quality audits : checks and other functions that ensure the integrity of the software products, required documentation, management structure and methodology to be employed.

The content of this Software Quality Assurance Plan complies with standard ANSl/IEEE Std 730-1989.

1.2. Scope and Application 1.2.1. Scope The Software Quality Assurance Plan is applicable to quality affecting software prooucts supplied by MGPl for the Radiation Monitoring System projects.

L""'l"b" "O"17O.YJ"Li=

,0*"_*'""%

m 45203 GA

~

RIRP Eama Roew Monkwma system sonwm ouemy Assurance men p6 1.2.2. Application This equipment is made up of six units :

D LPU/IC D LPU/10 0 LPU / Si D LPU / PlPS D LPU / SAS D DU Two software packages are installed on each unit. A base software that contains system funct;ons (one for the LPU, ano one for the DU), and an application software that is specific to each kind of unit.

There are two tvoen of analifv affecting sofhuare ?

l aafety related eOftware N'562 LPU-Base Local Process 5g Unit base software N' 563 LPU-Si Local Processing Unit for Silicon Detector (area monitor and NGX)

N'568 LPU-IC Local Processing Unit for Ionization Chamber (area monitor)

-N'564 LPU-PIPSLocal Processing Unit for Passivated implanted Planar Silicon (ABPM and NGM)

N'565 LPU-SAS Local Processing Unit for Spectrum Analysis System (IM, leaks and liquid monitor)

N*560 DU-Base Local or Remote Display Monitor base software N'561 DU Appli Local or Remote Display Monitor application software N' 831 LPU 110 ' Local Pror===Mg Unit for analoo and digital inouts interfacing standard software

-N'569 MASS Maintenance And Setup Software The following table lists documents are standards for both types of softwares, types of software Applicable documents R6f6rence documents safety related software SQAP IEEE 730 IEEE 983 SWP IEEE 1012 standard software SQAP IEEE 730 IEEE 983 b" '.". "l'".7 "n M 7.701"".i" ". f.~O *'"'" %

45203 GA

Radiation Monnonino system sonware Quemy Anurance Plan p7 1.2.3. Definition annileetion software. De volandad sofhware which covers most of the functions of an maniament item (meanieltlan. tramtment. ='- ms screen

..)

anomalv. Anythina ahearved in naarmilan of sofhuare that deviates from ernactations hamad on nrevionalv verified sofhuare oradede or ief rence d,=nents.

kaale software. Raeldant sofhuare which has the minimum furd ns of an maid mani item (maintenance mode. serial hnk)

CHRONOSOFT. MGP Instruments'sofhuare mannaement tool. This is the de'sh=ca that is used to record everv sofhuare eenerstad bv MGP instruments RAD Densr' nent. and

~

u to traea any chanos.

comnonent Testina Tantina condedad to verify the lmalamentation of the dealan for one sofhuare element (for avamala function. madula) or a ^^"-dion of sofhuare gjements. This is avnenvmous with the Unit Testina.

concept documentatloct. For avamnie statement of need advance niannino ranart.

orolect initiation memo. avstem dennltlon documentation. nrocedures. nolielaa and 4

customar acceptanco crlieria/ requirements.

g4evelonment team. Team of analified sacir.: s in chame of ann!vina software development life cycle.

dav=!ssar. Member of the devainament tamm.

Indenandant SV&V team. Team of an=Ilfied anoineers in charoe of comolamentarv software vertfication and vahdation tasks.

Intearation testino. An orderly ornar== alan of testina in which sofhuare :!=ments.

hardware elements or both are comt5ined and tested until the entire system has been integrated.

life-evele ohmaa. Any om ad of time durina sofhuare d==ba.nent or may be charmeierized by a nrimarv twee of metivity (eneh as daelan or tantino) that is being condnatad. Thema ohmeme may overlan one another for V&V our

m. no nbmes is concluded until its develeg ment nroducts are fully verified.

acalification. Statament that the avstem (hardware and sofhuare) rr. :ts the cusicrnsr's requirements.

mafety related softwaan. Sofhuare for RMS safety related eouinment.

software comnonent. C lanannae modula (set of functionst software testina. The orocess of testino,_sq intearated hardware and software sub-system (such as a LPU or a LDU) to _venfv that the avstem meets its anecified requirements.

n.-

,.mer

-u.a.m-.

".'.-w 45203 GA

==~,

... -=

.w =

.)

jyMGP i

danmaem Radiation Monnoring System Sor, ware Querity Assurance Plan p8 software verification and validation olan. A ofan for the conduct of software verification and validation.

standard software. Software whichfollows standard MGPl ruiss described in MGPI's manual.

system Intearation testina. An orderly 'oroaression of 19stino in which sub-system elements are combined and tested to verify that the comolete networked system meets its soecdied reautrements, validation. The orocess of evaluatino software at the end of the software develcoment orocess to ensure comoliance with software reautrements.

validator. Member of the SV&V team who carries out validation.

verification. The crocess of determinino whether or not the oroducts of a civen chase of the software develcoment evcie fullfill the reouirements established durino the orevious chase.

verifier. Member of the oroject team who carries out verification.

1.2.4 Abbreviations A.'AS American Nuclear Society ANSI American National Standards institute CTF Component test File DU Duphy UnR IC lonization Chamber IEEE institute of Electrical and Electronics Engineers LDU Local Display Unit LPU Local Processing Unit MASS Maintenance And Setup Software MGPl MGP instruments e

PC PersonalComputer(IBM compatible)

PQS Q.A. specific plan QA Quality Assurance R&D Research and Development RDU Remote Display Unit RMS Radiation Monitoring System SCE Southem Califomia Edison Company SCMP Software configuration management plan SDD Software Design Descriptions SDP Software Development Plan SI Silicon SIF SoLiare Integration File SIR Software Integration Report SITF Software Integration test file SITR Software Integration test report SQAP Software Quality Assurance Plan SRS Software Requirements Specifications STF Software Test Rie STR Software Test Report k"nk'JeTnirma7. m 7ME70.~=O~EUL~.m.

s.,vm.

45203 GA

Rede6on Monnonha system aceware Queety Assurance Plan p9 SWP S*were Verificebon and Validation Plan SWFR Software Verification and Validabon Report SWTP Software Verification and Validanon tool plaa VaV Vertfieston and Validanon 1.2.5. Acronymes & Notations None.

2.

Reference Documents 2.1. Customer's documents ANSI /ANS 10.4-1987 Guidelines for the verification and validation of scientific anti engineering computer programs for the nuclear Industry ANSl/IEEE.ANS-7 4.3.2 AppVMion Criteria for Programmable Digital Computer 1982 Systems in Safety Systems of Nuclear Power Generating -

Stations ANSI /IEEE Std 810.12-Standard Glossary of Software Engineering Terminology 1993-ANSI /IEEE Std 7301989 Standard for Software Quality Assurance Plans.

ANSI /IEEE Std 828-1990 Standard for Software Configuration Management Plans ANSillEEE Std 8291983 Standard for Software test documentation ANSI /IEEE Std 830-1984 Guide to Software Requirements Specifications ANSI /IEEE Std 9831988 Guide for Software Quality Assurance Planning ANSillEEE Std 10121988 Standard for Software Verification and Validation Plans ANSillEEE Std 1016-1987 Recommended Practice for Software Design Description NUREG 4640 Handbook of Quality Assurance Techniques Applicable To The Nuclear Industry, August 1987 10 CFR 50 - Appendix B Title 10, Code of Federal Regulations, Part 50, Appendix-B

"." M"= O"M ~ 7 dO.*.~. O""" '."."O '**' "'O n w 45203 GA

g MGP annmann Radiation Mordtonng System sonware Query Assurance Plan p 10 2.2. MGPI's documents Quality Assurance Maneals (MAQ): the list below indicates which of the procedures desetibing the general measures implemented by MGPl conc = ming the quality assurance of its equipment are applicable:

RMS documents:

4 PQS RMS 46800 Q.A. specific plan Spalltv Contracts favailable in French and Enolish):

CQ 04 02 Produgt Development CQ 04 04 Change Processing CQ 05 01 Documentation Control CQ 06 02 Ordering and Subcontracting a Service CQ 13 01 Identifying and processing non-conformities CQ 14 01 Corrective Action l

CQ 16 02 Filing Methods CQ 17 01 Quality Audits j

Oualltv instructions favailable fn French) lQ 04 01 Development Specification IQ 04 02 Development Plan lQ 04 03 Design File IQ 04 06 Software Production Rules IQ 04 07 Software-related Documents TEC 06 08 Software Design: Changes IQ 16 01 Filing Methods interface Quality Instructions (available in French):

INT 0410 lasuing a Change Request (DEV)

INT 0411 Change Note (BEV)

INT 0412 Change Review (REV)

INT 05 05 Circulation of Documentation INT 06 02 QA Evaluation of Suppliem and Subcontractors.

b" 7.- J,.Lon'==. M T O.~= O "n ~, E %. %

45203 GA

$rgennentsMGP Rada60n Monitoring System Software ouarny Assurance Plan p 11 3.

Management 3.1. Organization The compagny is organized in such a way, that the R&D department wh!ch is in charge of RMS projects and Quality Assurance department are independant.

The organizatiori is described as followed.

MGP instrument: General Manager X DUQUESNE Quakty Department R&D Manager Apphcation Department

- Manager F. SCHUt.cZ Manager X DUQUESNE F. CHLoSTA I

i RfG Project QunBty MS w

Manager g

g Appbcation Department M manager I

,l L

oT

'l I

I.

'l Software Technscal V&V Team l

ll Software Quarity Manager Manager Manager l

M ""W

,e L ggsu y J. NADAUD S.DatANCHE ll; l

l l

l

'l l

l l.

l' V&VTask omoer TechnicalManages j

!I i

'l l

1

!l l

' l RMS Software Project Tsam l

I'.......................................................el l

l RMS Project team

_.._.._.._.._.._.._...._.._.._.._.._.._.._..:.._.._..._.s The Application department is in charge of the relations between MGPl SA and the customer and assure the link between the project team and the coatomer.

The activity and technical managers are in charge of the following :

overall design and development of the equipment units verification and validation activities on thase units

n. r.m

,..r

. r n- --.""etret e fles Servons m 03 GA PIAGEEber\\ WW6AB.n et reprechan.n to.s.e eu petete te se $starhort eart tedress, Gen # Sagrqashen

1. MGP l

2 annuanun Radiation Mon!uing Sntem Sofiware Quality Assurance Plan p 12 Section 3.3 defines the responsabilities of the members of the RMS sc3 ware project team.The Software Verification and Validation Plan describes the details of the Software verification and validation activities.

3.2. Tasks 3.2.1. Standard software This procedure is described in Quality Instruction IQ 04 06 " Software Production Rules" in the MGPl Quality Assurance Manual.

3.2.2. Safety related software,

The soitware development life cycle is part of the system development life cycle in which the software is included.

Software will be developed in two phases:

a development of a model a manufacture of the finished product.

Two development cyclea have been d9veloped in order to maet the objectives of these two phascs.

System Development Software Development System Concept Model velopment cycle Product velopment cycle System integration The system concept phase is not described in this documer.t.

1 i

E A A O M 1 7 0. " M,".*".'O h ~

w e5203 GA l

gl!anmanussMGP Radiation Monitoring System Software Quality Assurance Plan p 13 3.2.2.1, Model Development Cycle This cycle leads to the development of a model and is designed to produce a preliminary software package.

The cycle can be broken down into 3 simplified phases:

Requirements phase sign phase intemal operation phase The activities of the requirements phase are defined in paragraph 3.2.3.1.. All Software Raquirements Specification documents are submitted to a design review as defined in Chaptsr 6.

ActMiles conomming the design chase serve to design and create the functions chosen for the model. A orovisional version of the software design descriotion documents will be drafted Provisional documents are not sublect to a design review. During this chase.

there is no comoonent testino.

Activities conceming the operation phase are intended to:

produce a usable version of the software. This phase does not generate formalized 3

and approved test documentation.

check technical solutions, record test data and note any changes and improvements required.

The observations made conceming the model by the contributers will be classified according to the following criteria to promote the following actions:

- Anomaly preventing utilization: in this case, the software team will provide a new version of the model software for operation after correcting the anomalies concemed.

- Anomaly not preventing utilization of the model: these anomalies will be recorded so that they can be taken into becount during the product development cycle.

- Improvement of certain functions: these observations will be recorded and submitted for acceptance.

These observations are made in some Model Anomaly Reports.

b"hih" ~4 "70.~= O~M ~ L' "'O 45203 GA l

1p.)\\enm~GP M

ms Radiation Mordtoring System Software Quality Assurance Plan p 14 3.2.2.2.

Product Develonment Cycle The seconti evele is indeoendant of the brevious one althouah based on the documents generated durina the first evele.

This approach encompasses all the phases of the software life cycle:

Requirements specification phase sign phase implementation phase Test phase 3.2.3. Description of Phases This paragraph gives a precise and detailed description of each phase in terms of; actMties included in the pheme Input items. These are the documents required to carry out the activities of the phase in full output items. These are the documents resulting from toe activities of the phase conditions to be fulfilled before proceeding to the next phase. This is a list of checks to be made to ensure that the prnducts of the phase satisfy the imposed quality requirements!

C h. A C M "0 7.#,0. ~ O ~ E ~ L ~

45203 GA

kdistion Morworire system sonwere ouemy Assurance Plan p 16 3.2.3.1, Requirements Specification Phase Phase activities The purposes of this phase are to:

identify functions that are common to both types of unit (LPU, DU).

provide an scoount of the operation of functions common to both units.

provide an account for each unit of the processing operations performed by its specific functions identify requirements and imposed performance characteristics e

draw up a Software Quality Assurance Plan (SQAP) draw up a Software Development Plan (SDP) draw up a Software Verification and Validation Plan (SWP).

e draw up a Software Configuration and Management Plan (SCMP).

These studies will be conducted on the basis of needs expressed by the customer.They produce certain documentation made up of spe#sen documents that are common to both types of unit as well as specification documents specific to each type of unit.

During this phase, software requirements specification are evaluated and a test phase must be prepared. These activities are detailed in the software verification and validation plan.

Products required forthe phase draft Software Quality Assurance Plan.

e draft Software Verification and Validation Plan draft Software Configuration and Management Plan RMS General Requirements Specificat: ens Phase products Project manat,ement documents

~

Software Quality Assurance Plan Software Verification and Vahdation Plan Software Verification and Vahdation Summary Report Software Configuration and Management Plan Technical documents Software Requirements Specification common to all units, Software Requirements Specsen specific to the units, Conditions to be fulfilled uefore proceeding to next phase Specification documents must be written, checked and approved.

All specification documents must be submitted to Application Depa tment.

b " '."""" ~i M " 7 IO.*=" O"""".".'. ~ O " " ~

45203 GA

l Redakm Monnonna system sonware ouehty Assurme Man p 16 3.2.3.2.

Dealen Phase Phase activities The following must be defined for each software:

software data structure, software architecture; breakdown of the software into organized modums, e

module execution scheduling, e

During this phase, design documents are evaluated and test phase must be prepared.

These activities are detailed in the Software Verification and Validation Plan.

Products required for the phase '

Software Requirements Spedikeuen common to all units Software Requirement Specification specific to the units Software Quality Assurance Plan Software Verification and Validaticn Plan Software Configuration and Management Plan Pnase products Software Design Descriptions Software Verification and Validation Su'amary Report Conditions to be fulfilled before proceeding to next phase The Design documents must be written, checi i and approved.

3.2.3.3.

Irnplementation Phase r

Phase activities The purpose of this phase is to gradually break down the modules and sub-modules into oftware components.

This phase involves:

implementing the means required to generate the code.

writing the software component in C language.

During this phase, softwam components and code are evaluated and test phase must be prepared. These activities are detailed in the software verification and validation plan.

'M "".""'" P= M ~ 7O =*"'O"*'"*.".*"""""'"'l?

45203 GA

gu ananannMGP Radstion Monitoring System Software Quality Assurance Plan p 17 Products required for the phase Software Design Descriptions Software Quality Assurance Plan Software Verification and Validation Plan Software Configuration and Manageaent Plan Phase products Draft of Manufacturing and Programming files for the software.( One document per unit)

Software Verification and Validation Summary Report i

Conditions to be fulfilled before proceeding to next phase Software component encoding is completed when it has been entered on the development system and it has been compiled or assembled without error.

Software Verification and Validation Summary Report 3.2.3.4.

Test Phase Phase activities This phase can be broken down into four steps.ns defined below :

g...-

phase prw >

i

!, Product We cy*

j

- r 2:: r:: :: ::

::= - r-r r k

l I

Ireersu= Tat

• l l

i i

g l

sere.T.st l

{ T= come l

.._......_.._.._.._.._......._...._.._...._.._..__.._s 4

The component tests are built and executed in the implementation phase. Their goal is to ensure that the encoded software components comply with all their specifications.

This phase produces to Component Test File documents.

The integration tests are built in design phase and executed in test phase. Their goal is to verify the assembly of all the software components for each unit and for each n

w.w.r

,.. -.n.--==n

""."n"a'..n s -

45203 GA m

- n w w.n

' MM P Radiation Mottoring System SoRware Quaay Assurance Man p 18 software package. This phase produces to Software Integation File and Software I

Integration report documents.

i

}

The software tests are built in the reouirements soecifiution chase and are eveeuted in l

the test chase Their coal is to check that the inteorated software comolien with

==.-5=&

s. This Ware Test File and Software Test Resort i

documents.

l

'the System integration Tests are built and executed dprino the test ohnse. Their coal is -

l to verifv that system comolies with the RMS oeneral system reautrements These tests danaribed in the System Integi ;;cn Tart file are executed neing all software and.

hardware alaments.This chase oradoeme a Svstem laiegistlon Test Reoort.

Ta=+= activities. de:mer.:e:hns and renorts. are detailed in the Software Verification and Validation Plan.

j Products required for the phase t

Software Requirements Specification l

Software Design Descriptions j

Software Quality Assursnce Plan Sr.,ftware Verification and Validation Plan i

Software Configuration and Management Plan Phase products Software Verification and Validation reports j

Software Vertfication and Validation Summary Report i

End of-phase conditions For the purpose o(jhig.prolact the test chase is the last stage in the develonment evele

]

of the orolect software. This phase is considered completed when*

- the tasts have been successfully completed and the test results have been i

recorded in the Software Verification and Validation Reports.

the Software Manufacturing and Programming Files have been updated where necessary and are available.

e the List of Software Documents has been comelled.

l the validation of the software has been declared during a software test review.

e 4

4 b" T7,.J M " 70.*="".".Z'"O"."'."". "L""1.

45203 GA

~

Redebon Monnodre System sonwee ouemy Assurta Plan p 19 3.3. Responsabilities This paragraph defines the responsabilities of the members of the RMS software project team.

r V&V activities are realized by each project team member.For safety related software, a software V&V team is in charge of complementary software V8V tasks. All these activities and responsabilities are described in the SWP.

The Project Manager aupervise the project as a whole (hardware and software) and is responsible for the following:

tee nical relations with Application Departement technical coordination between the software project, design and hardware manufacturing planning and project progress monitoring e

coordination of work within MGPl implementing the means required for the sLm%I completion of the project the quality of the products in his project.

The RMS Project Quelity Manager and The Software Quality -Manager are responsible for the quality support of the software project end:

ensures that the special rules applicai,le to the project are known and observed ensures that these rules are suited to ttwir purpose liaises with the Quality Assurance Department of MGPl e

ensures that the special rules and methods concoming the scftware project remain consistent with the rules and methods of the department when the project En.vare Quality Assurance Plan is drawn up advises the members of the software team concoming their responsibilities in the field of quality is responsible for changes in the Software Quality Assurance Plan of the RMS project and for waivers that may be granted during the development phase.

The Software Technical Manager leads the software team and is responsible for the following:

writing up the Verification and Validation Plan for RMS project software technical relations with Application Department in the software field e

setting up, organizing and monitoring the progress of the software project coordination and technical supervision of software teams.

quality and management of software and associated documentation produced by his team.

b " 7," T 7 M " 7 0. ~= O T '.*.*

• L ~

m 45203 GA

l AP Redtakon Mord\\oriro System sonwere ouemy Assurance Plan p 20 Each software Developer is responsible for.

the quality of the software developed by him j

the organization of the sutHroject assigned planning and progress monitoring technical supervision of his sub project l

Items produced by him circulation of information in his possession that is common to the project as a whole.

l validating the software of which he is in charge if it is a standard software package.

1 The Verification and Validation Manager is responsible for the verification and validation of safety related software. He/she coordinates a team of verification agents and plans and monitors the progress of verification and validation work. He/she is also responsible for the quality of his/her team's work and shares the following tasks with this team:

j t

checidng the documentation associated with Safety Related software preparing software test and vandation files checking software components l

creating and imple'menting test sets for the validation of:

- software components

- the complete software package.

I t

p.

i i

k j

1 I

i M=":'.".:

,="?.4.::."."."'.".:2 %.

4s2o3 GA i

a f

g

-,n---

r 1

MGP no6enon:.:w n #g s, =

sonwwe ouemy Amewence Men p 21

4. Documentation 4.1. Purpose Documentation issued during a software development project is essent! ally the only means by which progress through the software ;ife cycle can be measured.This chapter idewJies the documents. tion goveming the development, vertfication and validation of the software.

The follon.f3ptzoumanta shall ha available in English' Sofhwara RacQppta Specifloationg

._ saftwwa omaien am.>

aufhuaia DumlNv Aoumnae Plan Software Verdication and Validation Plan Software Verification and Validation Final Rr,'ggi Sofhware Teat.Elias Sofhware Tant Runotta

[

See prograph 5 for applicable standard to these documents.

4.2, Minimum documentation 4.2.1 Software Requiremente Specification The Software Requirements Specifications documents describe each ~%are requiremen' (function, performance, design constraints, and attributes of the sortivaro and extemalinterfaces).

The Software Requirements Speelfications documents are written in easily understandable language by the differer:t persons involved and, if noosssary, completed by more speOfic descriptijns using formalized structures (data flows, algorithnis, etc.).

4.2.2. Software Design Descriptions The design is (top down) and modular. Following the procedure adopted during the design phase, results in the specifloation of software comp ats, elementary functions.

Software Design DeswW,6 document defines fu es:

dtware:

cofture data structure, e

software archNecture: breakdown of the softwr into organized modules, module execution scheduling,

""X,,/,",,,",, '"h*,7,,lll2;L'".*,;,1%.*.*"4""'""" ".*."., O h"""

45203 GA

Medleuon Monwina system seawwe ouemy Aeswance Plan p 22 Then for each identined module:

list the soRware fundions fulfilled by the module, describe the data exchanged with the other modules, e

where applicable, t$reak down the module into sutsnodules, 4.2.3. Software Verification and Vall'dation Plan The Software Verthcotion and Validation Plan describes the following for each phase of safety related raftware life cycle:

the vertRo#Aion and validation task; e

tools, tectniques, methods and criteria; e

inputs and outputs; e

e ressources; risks and assumptions; e

roles and responsabilMy for accomplishing verification and validation of the safety related scitware.

The SWP identines all the test documentation that is to be prepared and executed during the life cycle.

The detailed methods umi to verify and validate software are described in the SWTP.

4.2.4. Software Verification ai.d Validation Final Report The Software Vert 6 cation and Validation Final report describes the results of the execution of the SWP. This includes the results of all reviews, audit, and tests required by the SQAP. The SWFR summarizes the status of the software as a result of the execution of the SWP. It doccribes any major deficiences found and recommends whether or not the software is ready for operational uses.

4.2.5. User documentation included as part of the product user's guide provided by MGP instruments.

7 4.2.6. Test documentation v

4.2.6.1.

Standard software Test actMties and documentation are described in Quality instruction IQ 04 06 " Software Production Rules" in the MGPl Quality Assurance Manual.

4.2.6.2.

Safety related software Paragraph 3.2.3.4 gives a summary of the test actMties.

Software Ve65cetion and Validation Plan defines test actMties,documentations and vertfication actMties for all iffe cycle phases.

E E'7, M M ". 7. #,.U.*=** O**""". " O L ~.a..

45203 GA

=

..._____. ~.

7,GP nedeuon Manorina system aonwere ouemy Amourance Men p 23 i

j 4.3. Other documentation 4.3.1. Software Development Plan The Software Development Plan describes the RMS project:

ha origins, terms and conditions, the software team organization, e

the team members responsability, e

I the task schedule, the cost and lead time follow up, 4.3.2 Management documentation

\\

4.3.3.1. Ust of SONwere Dc umenk Contains the list of all documents that are related directly or indirectly to a software. This I

is done according to the IQ R/D 04 07.

4.3.3.2. Programming file The programming file as defined by the IQ R/D 04 07 is replaced by the following documents :

SoNware Change ControlRio e

l l

This is the software version. management flie that lists changes that are made from one version to another. Evoktion as well as consequence analysis are stored in this file.

i Programming Mle e

l-This file gathers the source code listing for a software, as well as programmer notes.

Additional information on a sofware like cross references, function list, can be added to this file.

(

SONwere manutkaturing Rio e

"n!s file explains how to generate a complete software executable file, 4.4. Documentation Quality 4.4.1. Application of Standards-The special rules applicable to documentation management are described in quality contract CQ 05 01, entitled " Documentation Control" and in quality instruction IQ 04 07 entitied softwaronisted Documente.

" " T h ~s3 EL'"M.",,,ZL E.U'*'"~

m 45203 GA

-e.

,.,_,..,..n.-

,.n

~....,

,,, +,,, -. -.,.

3 l

MiiP Reseuen Monnonna sntem j

sonwm ouemy Anwonae men p 24 i

4.4.2. Review l

All documents are reviewed. They are submitted for checking and approval :

The naman reenaa=Na for d= 1:..a the denment anawan that the document l

pomplian with contractual raquirements and applicable rules within MGPl.

The person resF.onsible for approving the document must be complete!y j

e i

independent of the software team. He/she ensures that the document complies with contractual requirements and it is in accordance with um Quality Assurance r

organization described for the project.

l A design review report provides a record of the observations made concoming the document and the decisions taken with respect to each of these observations.

l l

The writer of the document must:

l forward the completed document on to the persons responsible for checking and approving it and to any other person in a position to make constructive comments on the document, plan and take part in the document design review, e

j

. integrate the decisions made during the design review.

1 The person responsible for checking the document must:

. check that the document meets the required objectives, before the design review,

. record his/her comments on the software document check sheets, take part in _the-design review to take into account decisions made conooming i

e comments fmm other reade,s, j

. _ check that the writer has integrated decisions made during the design review into the official version of the document and sign this version.

For safety related software, checking activities and responsabilities are described in the S W P.

The person responsible for approving the document must:

. ensure that the docurnent complies with the rules applicable to the projecti

. - record his/her commerds on the software document check sheets, prepare and write up the report of the document design review, e

. approve the official version of the document once the various corrections and modifications have been made and checked.

l 4.4.3. Document Control a

in the design phase, documents are updated whenever a written request is made and events are such that the documents concemed require changes. The document is processed directly by the writer. He/s,w integrates the observations made concoming the previous version of the document and proceeds as described in the above paragraph. He/she enters the change' on the page of the document provided for this purpose.

6",,0",',"l',"," ",,,,,,02ll " 74,*.4""'*"." "**'O L"".".'

45203 GA i

. _ - _. ~. _... - -,. _ _. _ _ _ _, _ _ _ _

Redis60n MonMoring System sonwm QueWy Anurance Plan p 25 Once the software has been qualified, the procedure to be followed is that described in quality instruction TEC 06 08.

4.4.4. Circulation Documents are distributed to the persons listed on the front page of each document.

4.4.5. Responsabilitica The following tables define MGPl IJaponsabilities of writing, checking and approving software project documents.

The status of the document provides the customer with information as to the action to be taken on receiving the document.

There are three types of document:

project management documents technloal documents e

verification and validation documents e

Project management Documenta name of document abbreviation written by checked by approved by Software Quality SQAP Software Quality Project manager Quality department Anurance Plan Assurance manager Manager Software SDP Software Software Quality Project Manager Development Plan Tochalcal Manager Anurance Manager Software SVVP Software

' VAV Manager Software Quality Verification TechnicalManager Assurance and Validation Plan SVVFR Manager and Repon Software SCMP' Softwars VAV Manager Software Quality Configuration and Tehate=1 Manager Assurance Management Plan Manager Software SVVTP VAV Manager Software Software Quality Vorification and TechnicalManager Assurance Validition Tool Manager Plan List of Software Softwars Software Software Quality Documents Developer TechnicalManager Assurance Manager Software Change Software Software Project Manager ControlFile Developer Technical Manager Review and Audit Writer of repon not applicable not applicable Reports SQAP,SWP,SWFR are sent to Application Department for comments.

~

45203 GA E """".'LL

l. M E 7aIO. T= JO. ~.= E O L "

Jg,lMGP annuness Radiation Monitoring System Soltware Quahty Assuranos Plan' p 26 Technical Documents name of docussent abbreviation written by ebec6 ed by approved by Schware SRS Software Project Schware Quality Raquirements Techalcal Manager Manager Assurance Specl6cadons or or Manager Software Software Developer Techalcal Manager Software Design SDD Software m a.w a-- r Software Quality Desalptions Developer Software Assurance TechnicalManager Manager m.m.mr VAV Manager Sonware SPF Software m 4 w a-- r Software Quality Programming File Developer Software Assurance Technical Manager Manager l

a.m.ama r

i V&V Mmqu l

Software SMF Software Software Software Quality j

Manufacturing File Developer TechnicalMarager Assurance Manager SRS and SDD are sent to Application Department for comments.

i Others documents are available on request.

Verification and Validation Documents l

l name of document abbreviation written by checked by approved by l

Component test File CTF Software Software Software Quality developer TechnicalManager Assurance Manager Sonware S!F Software Software Software Quality integration File developer TechnicalManager Assurance SIR or Manager Software Software Integration Reports developer Software Test File STF am.awage --r Softwar*

Software Quality Software TechnicalManager Assurance Software Test STR developer Manager Reports s.a. mr Veri 5 cation and Validation Manager Sptem integration SITF Software project manager project quality Test File TechnicalManager manager i,

SITR System 1ntegration Test Reports These documents are described in the Software verification and validation tool plan.

SIF,STR,SITF and SITR are available on request, b"4""",.'7,6. MM 7.74.'.'". ""' " *"O"" L~

45203 GA

SrLISP Rediabion Mordoring System soAware ouemy Assurance Plan p 27

6. Standards, practises, conventions 5.1. Appilcable standards for standard software This procedure is described in Quality Instruction IQ 04 06 " Software Production Rules" in the MGPl Quality Assurance Manual.

5.2. Applicable standards for safety related software 5.2.1. Documentation standard, The following table gives the list of studards for document writting during software development cycle.

Documer t standard Software Requirements Specification IEEE Std 8301984.

Software Design Descriptions IEEE Std 10161987.

Software Vertfication and Validation Plan IEEE Std 10121986.

Software Test documents Software Verification and Validation Plan IEEE Std 829-1983 User documentation Intemal rules (Doc-To-Help Tool)

Software Development Plan Merlin Gerin PLI recommandations Software Configuration Management Plan IEEE Std 828-1990 Software Integration None 5.2.2. Design standards None 5.2.3. Coding standards Languages used:

Microtech C language (ANSI compatible) submitted to presentation, structured encoding and comment standards (see paragraph 9.1).

5.2.4. Testing standards b " 7 h..i. h " ; 2 7 4 ~ # C L " O 45203 GA

45kgenunenMGP Q

Radiation Monitoring System Sokware Quainy Assurance Plan p 28 See Software Verification and Validation Plan.

6.2.5. Code operation / Maintenance standarda if a change is made to software once a version has been accepted, a new production life cycle will start ogaln.

For safety related software, this new production will start with a verification and validation life cycle.

6.

Reviews and audits 6.1. Purpose Software quality is constructed and monitored continuously throughout development.

The efficiency and consistency of quality actions are partly conditioned by the independence of the Quality Assurance department with respect to the development and follow-up services.

Quality actions are designed to check that the results of development phases are consistent with expected results and the results of previous phases and that they comply with the Software Quality Assurance Plan.

6.2. Document Reviews 6.2.1, Management A design review is held after the document has been passed on to participants for analysis and comment.( See software verification and validation plan ) The participants prepare the meeting by making written observations. During the review, these observations are examined and decisions are taken regarding any modifications to the document required.

The design review also provides the opportunity to make a list of the technical problems er. countered and any solutions found and applied. If any unsolved problems remain, corrective action is decided upon and tasks and responsibilities are assigned.

A design review report is written and addressed to:

the Software Quality Assurance Manager.

review members.

any persons to whom a task or responsibility has been assigned.

any persons liable to be concemed by the information contained in the report (e.g.

Project Manager).

b"6.h~;.MEM.", ilLii 701"'O n

s.,,,,

45203 GA

MSP

_ mm,_

sonwere ouemy Amewance Plan p 29 1-The Software Quality Assurance Manager, acting on behalf of the review members, l

approves the document once it has been updated on the basis of the conclusions of the i

report.

j 8.2.2. Software Development Plan review l

The Software Development Plan review constitutes an evaluation of a complete Software Development Plan.

j Person in charpe:

Software Technical Manager.

I Participanfs: Participants are invited by the writer of the document. Review members are:

[

Software Technical Manager.

Software Quality Assurance Manager of the project.

I Projed Manager.

I l

The revisiv report is written and circulated by the Coftware Quality Assurance Manager of the project.

6.2.3. Software Verification and Validation Plan review The Software Verification and Validation Plan review constitutes an evaluation of a complete Software Vertfication and Validation Plan.

1 Person in charps:

Software Technical Manager, j

Participants:

Participants are invited by the writer of the document. Review members are:

Software TechnicalManager.

Software Verification and Validation Manager, Software buslity Assurance Manager of the project.

j Project Manager.

The review report is written and circulated by the Software Quality Assurance Manager j-of the project.

l 8.2.4. Software Configuration Management Plan review The Software Configuration Management Plan review constitutes an evaluation of a i

complete Configuration Management Plan.

4 Person in charge:

Software Technical Manager.

4 Participants-Participants are invited by the writer of the document. Review members are:

b" *.".*"hMS E7.fE.", Z""".*."O I'"""

45203 GA

~

. ~...

g*MGP ammers Radiation Monitoring System Software Quakty Anurance Plan p 30 Software Technical Manager.

Software Vertfication and Validation Manager.

Software Quality Assurance Manager of the project.

Project Manager.

The review report is wrttien and circulated by the Softwarn Quality Assurance Manager of the project.

6.2.5. Software Requirements Specification review The Software requirements review (SRR) takes place at the end of the requirements specification life cycle phase. The SRR constitutes an evaluation of the Software Requirements Specification document.

Person In chame:

Software Technical Manager.

4 Particleanft Participanta are invited by the writer of the document. Review members are:

Software Technical Manager.

writer and his/her Software developer Software Quality Assurance Manager of the project.

Project Manager.

the person responsible for verification (verification / validation team) for safety related software.

The review report is written and circulated by the Software Quality Assurance Manager of the project.

6.2.6. Software Design Descriptions review The Software Design Descriptions review (SDDR) takes place at the end of the Design life cycle phase. The SDDR evaluates the technical adequacy of the design as a prelude to the implementation phase. The reviews checks the Software Design Description document is in accordance with the requirements.

Person in chame:

Software developer.

Parfieleanft Participants are invited by the wrtter of the document. Review members are:

Software Technical Manager.

writer and his/her Software Developer.

the person responsible for vertfication (verification / validation team) for safety related software.

The review report is written and circulated by:

the Software Developer in the case of standard software.

the person responsible for verification (verification / validation team) for safety related software, b"77."n M170.~=n ll"a E"L""O.

no.%

45203 GA

Redie6on Monnonna system t

sonwere ouemy Aneurance Plan p 31 6.2.7. Component test review This review conoems Component test File. It takes place at the end of the implementation life cycle phase.

Person b chame:

Software Developer.

Participanfs:

Participants are invited by the writer of the document. Review members are:

writer and, in some cases, hismer Software Developer.

the person responsible for rereading in the case of standard software.

the person responsible for verification (verificationNalidation team) for safety related software.

The review report is written and circEdsted by:

the Software Develop 6r in the case of standard software.

the person responsible for vertfication (verificationNalidation team) for safety related software.

6.2.8. Integration review This review concoms Software Integration File and Software Integration Report.

Petaanin chame:

Software Developer.

Particinants:

Participants are invited by the writer of the document. Review members are:

Software Technical Manager.

Software Developer.

Software Quality Assurance Manager of the project.

At end of integration Software Integration File and Software Integration Report -

documents are reviewed.*

A report is written and circulated by the Software Quality Assurance Manager of the P@

6.2.9. Software test review The Software Test gives rise to two reviews:

The first review is held to check that the tests provided for in the Software Test File can be used to ensure that the software produced will comply with its requirements.

A report is written at the end of this review.

The second review is held to check that the test results recorded in the Software Test Report comply with those specified. A report is also written at the end of this review.

b"1""? T O.lll2;L'".*f Z1"O"""O""1"""

w 45203 GA

gAlesnuarsMGP Radiation Monitodng System Sonware Quelty Assurance Plan p 32 Egtson in chame:

Verification and Validation Manager for safety related software.

Software Development Manager in the case of standard software.

Eatficipants:

Participants are invited by the writer of the document. Review members are:

Software Technical Manager.

Software Development Manager.

Software Quality Assurance Manager of the project.

the f arson responsible for vertfication (verification / validation team) for safety related software.

Both reports are written and circulated by the Software Quality Assurance Manager of the project.

6.2.10. System Integration test review The System integration test give rise to two reviews:

The first review is held to check that the tests provided for in the System integration Test File can be used to ensure that the software produced will comply with the general requirements. A report is written at the end of this review.

The cacond review is held to check that the test results recorded in the System integration Test Report comply with those specified. A report is also written at the end of this review, Person in chame:

i Technical manager Software Team Manager Particleants:

Participants are inyt'ad by the writer of the document. Review members are:

Software Team Manager.

Technical Manager.

RMS Project Manager.

RMS Project Quality Manager.

Both reports are written and circultted by the Software Quality Assurance Manager of the project.

""""**'*' L""O.

45203 GA

"" 7h""""b" " M E"# ~O""

go al1i4GP neun Radiation Monitodng System Software Ouahty Assurance Plan p 33 6.3. Audits Awh are performed by the MGP instruments Quality Assurance department or by the

customer, in both cases, these audits are announced and planned with the project team.

Two types of audit are possible:

the Quality Aud/t is launched when an unexplained problem arises. The purpose of this type of audit is to check that a given situat!on complies with predefined measures.

the in process Audit is a methodical examination performed during different development phases to check the real progress status of project.against its declared status (documents, organization, methods, tools, etc.).

6.4. Quality Follow-up Documentation Design reviews and audits produce types of report. These reports are kept for five years.

These documents are intended for in-house use but are available to the customer for consultation purposes.

7. Software Configuration Management Plan The Software Configuration Management Plan addresses the identification, control, status accounting and methods needed to develop, produce, support and test the software throughout his life cycle.

• " 7 h 'i 7 # AE 7 0 L'*"" "" ~ M O L "

45203 GA

jfMGP annneen Redistbn MonMoring Syst.m Sofhvare Quakty Asturance Plan p 34 8.

Problem reporting and corrective action The procou of reporting and anomaly handling is different with respect to the development or maintenance phases.

8.1 development phase Each significant problem detected by any people in the design team is documented in an anomaly report ( a standani form is used,see annex

)

it consists of 3 parts:

The first, filled by the user, describes the anomally. It contains the fohowing information:

1. Name & version of the product being evaluated

2. Name of the user

3. Environment description or test number (based on a plan)

4. Test date S. Apomally origin & severity

6. Anomallydescription MGP Instruments Software AnomalyRepotf N'

paw,o ;m unw:n ;(1) Anomaly description from user:

^3 %

e; Project: Radiation Monitoring System (RMS)

Unft

- Name :

Version :

User's Name:

Environnement/ Test Number:

g,g,.

Orfein:

O proto.op.r. tion O cod. Analysi.

O compon.ntT une O tra.or tionT iins D varie. tion swfousnearO Jemming O NonJ mming O impnament o ortpuoerobi.m:

To the extent that that the modifications performed make reference to the file above, they need to be identified uniquely by use of a number. It is the approvers duty to identify & provide numeration to the file, that will be stored in a cabinet containing all the anomaly reports.

b " A. M i M " 7 4.*.*.* O*'" ".*" ~ L~

45203 GA

$' AanmaarsMGP Radiation Monitoring System Software Quahty Assurance Plan p 35 The second part, filled by the concemed software deyelopment responsible person, proposes a solution to correct the problem. This solution is validated or not by the approver function (software technical responsible engineer or project manager) that takes the decision to resolve or not resolve the anomaly. This document contains the following info:

1. Software responsible person - Name

2. Anomaly treatment date

3. Solution description

4. Anomaly treatment decision (accepted, not applicable, immediate attention, deferred 43ntion)

5., eprovers name, function, date & signature (2) Software Responsible Person Treatment tlName Date:

/

/199 Accepted sowon :

Anomaly:

O Accepted O WA CorroeflCn:

O immediete O oevermd To:

(3) Approved sy :

O nTt O cp i

sies signatur.

The third part, filled by the software development responsible engineer, verified by the concemed verifier, provides the impact analysis, it contains the following information:

1. What development phases the modifications affect

2. The eventual reiterations needed

3. The list of modified files / documents

4. The list of software with index numbers, fixing the problem

5. Verifiers name, function, date & signature. When the file is signed, we consider that a verification has been made to assure the proper treatment of the anomaly.

wM)Imhact Analysis from Software Developer? e :

&Jm *

- n Modfrication of:

O n.auimment. O oesien O code O oe.r:

Reiteration on :

U Recuirements U oesign O Coding C ComponentTest 0 ini.graisen O veneetion Modded Funeornnes.cocuments/Sonwere:

New softwarss (N' + Verslor\\):

(5) Checked by :

O not O vav on i

rios vis.

When the change request occurs during development, the software version index does not change, but 1 sub-version index is managed by the software configuration tool.

When it occurs siter acceptance of a version, the software version index is incremented.

M A.,.L L ".n 0 %%".!" O'~~""'.".OL~

45203 GA

iykMGP antmanen Redation Mordoring System p 36 sonware ouemy Anurance Plan 8.2. Maintenance phase Any system defects detected by the customers or by MGPl are reported in a non conformance report (QA form 43738) accordingly with QA procedure CQ 13 01

• identifying and processing non conformities" and in a change request (QA form 27094) accordinglywith QA procedure CQ 04 04 " change prooc4 sing".

If software concerned, the problem is documented in an anomaly report which describe the corrective actions to be taken.

A change request regarding a versi,on results in the following processing with respect to the SV&Vlife cycle:

- analysis of the impact of the change (ident}fication of items involved and the degree of modification)

- repetition of the V&V cycle on items which change in order to check that the modifications have been taken into account in versions n+1.

l After tn,atment, the documentation concemed is reviewed in the change review.

E A7 h '74E70.T""="'*'"*'L"""

45203 GA 5

RedeSon Mordorim System sonwere Que% Assurance Plan p 37 All hems concemed by this procedure are recordad in a Software Follow-up File under the responsibility of the Software Developer. The updated documents are then circulated I

with the change note informing the persons concemed of the new configuration.

• r******

Non eenluneenos mped

]

or=wn mee memet

.,o4 Hoenn mene eenw n many presseeing p+- - N dI erswaeew =*=

8. Change management is described in general procedure CQ 04 04 of the MGPl Quality Assurance Manual.

The change procedure is applied:

During development in the case of change requests.

i e

Any anomalies detected which have no effect on Software Requirements Specification are processed by the software team (in conjunction with the V&V team for software for safety related software) and recorded in test files and in the component history.

After software validation for any in-house or customer change or revision request.

b"77 L. NOM"70."O"OOL~e 45203 GA

__,m.,.

y__

,__.m.,

_. ~ __

MGP Mediation MoMciir,g System sonwere ouemy Amewance Han p 34 Pmcedure 1.

Change request 2.

Analysis (file, document, non regression) 3.

Processing 4.

vertrication

9. Tools, techniques, and methodologies 9.1. Tools A detailed list of tool versions used is given in the Software Developmen' F jan for the Proket.

9.1.1. Program Development Environment Hardware Networked PC-DOS with WINDOWS for Workoroun (M32) 88000 emulator REPROM oroorammar.

Prqlect Sothwarms e

Micromott Word for Windows veralen 2.0 or later (#833) e Shaneware VISIO for Windows (s834) e WarTech Doc-To-Hale for user's manual (#850)

Development chain Ibr 88000 micropmcassar Microtee ASM88K 88000 annambler and linker (M39) e e

Mlerntec MCrMAK C* ANSI comallar (?440)

Micratec XHS88K almulator (#835) e Microtec XHM88K amulator (8838)

Development environment Ibr MASS software Borland C++ (M50) l Sonware vernlon manaoement ski e

Starbama Versions (s851) l CHRONOSOFT

'M = L""l" M'74EM."MMO1~

m 45203 GA

g,I1P, Radiation MonMoring system sonwere Quemy Assurance Plan p 39 9.1.2. Test Environment l

Sathvare corricanent val ldallon aid Microtech C simulator with source debugger.

9.1.3. Text Editing and Data Management j

on PC/ DOS under WINDOWS for Workarnnn Microsoft Word for Windows text editor l

WarTach Doc-To Hala for amar's dementation e

VISIO graphics editor EXCEL spreadsheet Microsoft project management system i

9.2. Rules Rules are designed to simplify software development, implementation and use.

Iryhouse Instmellons of the MGPI Sotheare RLD Dent Software production rules IQ 04 06 Software-related documents IQ 04 07 TechnicalInstructions soecific to the RMS orofect C language programming rules 45 880

10. Code control 10.1.

Purpose Configuration management serves the following purposes:

check the consistency ci the items produced at various stages of development.

e These items include: software products, associated documents and development means.

Identify the following items: those required for change management, those to be delivered and those required for the utilization and maintenance of software.

10.2.

Configuration items Application source files.

Software construction files (compilation files, link editing, etc.).

Development chains used.

Software documents used.

Vs'idation means.

45203 GA M A "" b " M E M. ~=, Zl "a O O O""J.

-._ _ _ _ _.m 1

l 4I t

noneson Manwkw sem sekam ouemy Assurance Men p 40 s

m 10.3.

Identification of Hems The source Ses sad software construction files am identiflod extemally (file name) ard intomally (comment block specifying among other thin 0s the equipment, 4

i software, name, retion index and history of the software component).

Gottware documents are identified by as number and an alphabetical index.

]

Test and validation m3W.m are iderdfled by a name related to the name of the e

comeac%1o 'ao testird.

+

l i

10.4.

Identification and Configuration Conformance Procedures l

Cannpuralkus annibrmance Maandura!

l The 4t of software documents is updated at the end of each phase. It conoems the nome created and those which have changed during the phase.

l

}

jdentMcallan and canthwtalian aankumance data Software components are identified as soon as they are produced.

Documents are configured at the end of the phase during which they were written. Each software component is configured at the end of the Component tests.

The software is configuesd at the end of the software integration phase. This applies to l

both the model and the product.

4 BaaponaMk:

The Software Developer is responsible far implementing the identification and configuretion conformance procedures, if the drafting of this documentation is delegated

- to another member of the design team, it nonetheless remains under the responsibility of the Software Developer.

i

11. Media control i

11.1.

Saving and Filing Every 2 or 3 days software is saved on magnetic tapes for a period of 10 days. After this i

period the tapes are roused. The first tapes of month are kept for 12 months in a firoproof cabinet.

Each version of the software is stored on information storage media. Diskettes, disks, msgnetic tapes, cassettes or other magnetic media are kept in duplicate for each version in accordance with the rules and regulations of the MGPl research and j

development laboratory. One copy is kept in a fireproof cabinet in the omoes of MGPl.

b " h i E T M E M.*. ". '1 1""I ~ O '*' "

45203 GA

v g pnamenGP RedieUon MonModng System sonware QuaWy Assurers Plan p 41 The other copy is kept in an ordinary cabinet in the archives of MGPl.

The Software Developer is responsible for the management of Inform: tion storage media kept at MGPl.

The department issuing a document or a file being compiled is responsible for its safeguard as long as that document or file is in that department's possession.

11.2.

Software Reproduction Copies of the software (object files) in REPROM or EEPROM memory or on magnetic media (disk, diskette) are made using copy tools guaranteeing the validity of the copy.

The Software Manufacturing Filg provides instructions conceming the copying procedure to be followed.

11.3.

Software Access Control Accean to software source code and documentation la controlled bv network administration.

12. SuppIler control This procedure is described in Quality Contract CQ 06 02 entitled " Ordering and Subcontracting a Service" and in Interface Quality Instruction INT 06 02 entitled "QA Evaluation of Suppliers and Subcontractors"in the MGPl Quality Assurance Manual.

13. Records collection, maintenance and retention This procedure is described in Quality Contract CQ 16 02 entitled " Filing" and in Quality Instruction IQ R/D 16 01 " Filing Methods" in the MGPl Quality Assurance Manual.

14. Training This procedure is described in Quality Contract CQ 18 01 entitled " Training",

16. Risk management Risk management is described in the Software Development Plan.

Lh.b" 4"7OWh"M.",L*"'O.

45203 GA

Page i

Df 4

(For IDCNs Ordy)

CONTROL ROOM ING DCP No.

Rev.

Page YES C NO IDCN NO.

DCN TRACKING NO.

DCN NO.

DOCUMENT REV.

Southem CaMomia Edson Compwy S.

ABG 11507 l

f DOCUMENT NO.

%[5' SHEET NO.

REV.

UNIT (S) 0-CLASS DOC. Q CLASS EQUIP SO1234001 B N/A 1

2&3 11 l

N/A peeeg DOCUMENTTITLE SOFTWARE QUALITY ASSURANCE PLAN DE' SIGN CHANGE NOTICE (DCN)

R

^

COVER SHEET B.E. MARTIN P^*

D^*

82019 07/i7/97 STATION SYSTEM DEClONATOR SPA

1. DESCRIPTION OF CHANGE

[eEFORE AFTER

}Sf0VND

@D

[lNTERIM

{ilNFORMATION ONLY As part Of the SCE DRMS Software Eva!Uation Project, (Software Evaluation Report, SCE No. 90400), defiClenClos in some existing DRMS software documents were identified and documented in DRMS Software Evaluation Anomaly Reports (SEARS). This DCN Corrects deficienCles in the subject document that were identified in the following SEARS:

• Open item 29 RECEIG ODM AUG 2 s 1997 SITE FILECOPY INmATING DOCUMENT (NCR SPR,other) DRMS SOFTWARE EVALUATION REPORT SCE NO. 90400

2. OTHER AFFECTED DOCUMENTS (FOR DCNs ONLY)l O YES $ NO OTHER AFFECTED DOCUMENTS EXIST AND ARE LISTED ON FORM 26 603. THE SOURCE DOCUMENT 18 IDENTFIED AS O

m SDCN: OR O THEroLtOWmmCuuENT:

O YES S NO mES mS oCN.APACT SffE PROGRAMS OR PROCEDURES? F YES. LIST AR NUMBER.

O YES $ NO DOES m8 NON A 6t$MNMMN ? F HS, FORM 26-64MS BEEN MMDE THE SOURCE DCR F APPLICABLE, LIST TECmlCAL JUSTFICAT10N SOURCE DOCUMENT NUMBER O YES # NO FIRE PROTECTIONISSUES APPLY (DOCUMENTED ON FORM 26 292 AND INCLUDED WITH THE SOURCE DOCUMENT O YES $ NO ENVIRONMENTAL QUALFICATION ISSUES APPLY (DOCUMENTED ON FORM 26 403 AND INCLUDED WITH SO O YES $ NO OTHER REFERENCE DOCUMENTATION (celculetons, eIt) ?

O YES $ NO AS FOUND CONDm0N CONFIRMATION FIELD WALKDOWN REQUIREDt WALKDOWN PERFORMED BY t DATE

3. SCE DESIGN APPROVALS:

6 7

)

ORIGl ATE OTHER DATE W

au Y

Y7 W_ e'IEWENOINEERRe A.Babs 8HD REV DATE OTHER DATE FIRST UNE SUPERVISOR dATE OTHER DATE SECOND UNE SUPERVISOR DATE OTHER DATE

4. CONVERSION:

v CONVERSION TO DCN DATE i

6Dd40NGS OR CDM-ENGINEERING SUPPORT

'C'**-""

"v ' ***

Vv iutn g g g g rg gry g

PAGE o-0V u

(For10CNs ouy)

DCP NO REV PAGE Southern Califemte Edioen Company 10CN NO.

DCN TRACKING NO.

I DCN NO.

DOCUMENT REV, 8-ABG 11507 j

i DesmN CHAN OTICE (DCN)

O IHEET NO.

REV.

S01234061 l

SUPPLIMENTAL PAGE DESCRIPTION OF CHANGE @sEFORE [AFTER DAs#0VND CADD

[ INTERIM

[INFORET10N ONLY The following information is from Software Quality Assurano Plan, pagt 34:

8. Problem reporting and corrective action The prooss: of reporting and enomaly handling is entforent with respect to the development or maintenance phases.

l 8.1 development pheme Each signinonnt problem detected by any people in the design team is documorded in an anomaly report ( e standard fann is used,see annex

)

k consists of 3 parts:

The Arzt. Alled by the user, desorbes the anomally. R contains the following informetlen:

1. Name & version of the product being evaluated

2. Name of the user

3. Environment description or test number (based on a plaai

4. Test date

s. Anomally origin a severtty S. Anomallydescription 9

1 SCE MW may a em i vgTrosenosusepggr g

o

,c

m 3

OF 4

PAGE (For IDCNs Only)

DCP NO MEy pagg southwn Califomia Edison Comny IDCN NO.

DCN TRACKING NO.

DCN NO.

DOCUMENT REV.

S.

ABG.11607

/

D CUMENT No.

SHEET NO.

REV.

DESIGN CHAN OTICE (DCN)

SUPPLEMENTAL PAoE S01256 5 1 1

DESCRIPTION OF CHANGE CE! FORE @ AFTER(~ r; 'oVNo O^oo O 'NTEniu C Nronmososty This change will be refieded on page 34:

i 8.

Problem reporting and corrective action The proooss of reporting and anomaly handling is different with respect to the development or maintenance phases.

3.1 development phase Each significant problem detected by any people in th sign team is documented in an anomaly report ( a standard form is used,see anne A 1t consists of 3 parts:

The first, filled by the user, describes the anomally.

It contains the following information:

1. Name & version of the product being evaluated

2. Name of the user

3. Enviror:mont description or test number (based on a plan)

4. Test date

5. Anomally origin & severity

6. Anomally description iano.wo=6 e g,g.ge g..,cg g

• ""8"*

4 OF 4

PAGE (For IDCNs Ordy)

DCP NO REV PAGE Southem Califomia Edson Company IDCN NO.

DCN TRACKING NO.

DCN NO.

DOCUMENT REV.

S*

ABG 11507

)

}

N N i.'

tHEET NO.

REV.

DES:CN CHAN OTICE (DCN)

SO N S14 1

SUPPLEMENTAL PAGE DESCRIPTION OF CHANGE CBEFDRE C AFTER

[AS-FOUND

@. ADD

[ INTERIM

]lNFORIAATION ONLY W' ? *k* 'L Y *Q*d?*'V* R OQ R DCNQ-

,,, =v,v,2

=-

b ANNEX A l

f J

MGP instruments Software Anomely Report N'

i L

-(t) Anomely descriptkut from user

• +-

~u n.

Project: Radiation Monitoring System (RMS)

[

Unit Name:

U**f'* N * * *;

}

~ Version :

Environnement / Test Number:

page:

P orfeln.

O proio. Operation O case Anaw.

O componersT shng O ireogratenTeatr$ 0 veienten sedouanese O. mming C NorWemmirg O Wro,enent

{

DeecrptorvProblem Y

L

(

f

-v tt) Software Mosconsible Person Treetment lName Dete:

/

/199 lh Accepted Soluton I

f l

)

h Anomely:

O Acompted O R'A correction :

O inwnedste O D*nedTo:

(3) Approved By O RTL 0 cP i

itse signature c,,,s.y) prymnart Arselysis from Softwart DeVeklper y.:... e v e

o mesasson er:

O R.,**m.t. O Du,n O Cod.

O ow.

Menoretion on:

O Ree.**merts O Dwign O cochng O cernpon.tTut O treograticn O validaten l

Weled FunctersfiletCocumerts'SoRware:

i h

I I4ew Sotheoree W + Verolon):

(5) Checked by i O RDL OV&V On i

1199 Vies

_ v e _. e

% u s_m sta anM6a mav s **s 1vtnMosae4oo ogeegtogg. cgpg