Smartlogic

Menu

תגית: ולידציה מה זה

ולידציה – ספציפיקציה פונקציונלית

Posted on by אביב צברי

ולידציה – ספציפיקציה פונקציונלית (Functional Specification)

ספציפיקציה פונקציונלית (Functional Specification) (שנקראת לפעמים ספציפיקציות פונקציונליות) היא מסמך פורמלי שמשמש לתיאור מדויק, עבור מפתחי התוכנה, את היכולות, המראה והאינטראקציה עם המשתמשים הנדרשים מהמוצר. הספציפיקציה הפונקציונלית היא סוג של קו מנחה ובהמשך נקודת יחוס עבור המפתחים שכותבים את קוד התוכנה. (לפחות קבוצת פיתוח אחת של מוצר עיקרי השתמשה בגישה "התחל מכתיבת המדריך". לפני  קיום המוצר, המפתחים כתבו מדריך למשתמש עבור מערכת עיבוד האות, ואח"כ הצהירו שמדריך זה היה הספציפיקציה פונקציונלית.  המפתחים אותגרו לפתח מוצר שיתאים לתיאורים שהופיעו במדריך למשתמש). בצורה אופיינית, הספציפיקציה הפונקציונלית לתוכנית אפליקציה עם סדרה של חלונות אינטראקטיביות ודיאלוגים עם המשתמש אמורה להראות את הצורה הוויזואלית של ממשק המשתמש, ולתאר כ"א מפעילויות הכניסה האפשריות של המשתמש ופעילויות התגובה של התוכנית. הספציפיקציה הפונקציונלית יכולה גם לכלול תיאורים פורמליים של מטלות המשתמש, תלות במוצרים אחרים, וקריטריונים לשימוש. לחברות רבות יש מדריך למפתחים שמתאר איזה נושאים צריכים להיכלל  בספציפיקציה הפונקציונלית של כל מוצר.

כדי להמחיש את הצורה שבה הספציפיקציה הפונקציונלית משתלבת בתהליך הפיתוח, להלן סדרה אופיינית של צעדים שצריכים להיכלל בפיתוח מוצר תוכנה:

  • דרישות: זו הצהרה פורמלית של מה שמתכנני המוצר, לפי ידיעתם על המצב בשוק ומידע ספציפי על של לקוחות קיימים או פוטנציאליים, מאמינים לגבי התכונות הנדרשות למוצר חדש או לוורסיה חדשה של מוצר קיים. דרישות אלו מוצגות בד"כ באופן יחסית כללי.
  • מטרות: המטרות כתובות ע"י מתכנני המוצר בתגובה לדרישות. הן מתארות באופן יותר ספציפי את תכונות המוצר. המטרות יכולות לתאר את האדריכלות, פרוטוקולים וסטנדרטים שאליהם המוצר חייב להתאים.  מטרות שניתנות למדידה הן אלו שקובעות קריטריונים שלפיהם ניתן להעריך את המוצר הסופי.  אפשרות למדידה ניתנת לביטוי במונחי אינדקס של שביעות רצון הלקוח או במונחים של יכולות וזמני ביצוע. לצורך עמידה במטרות, חייבים לקחת בחשבון את מגבלות הזמן והמשאבים. לו"ז הפיתוח הוא בד"כ חלק או מסקנות מהמטרות.
  • ספציפיקציה פונקציונלית: ספציפיקציה פונקציונלית היא התגובה הפורמלית למטרות. היא מתארת את כל ממשקי המשתמש החיצוני והתוכנה שבהם המוצר חייב לתמוך.
  • בקשות לשינוי עיצוב: במשך תהליך הפיתוח, כאשר מופיע צורך לשינוי הספציפיקציה הפונקציונלית , שינוי פורמלי מתואר בבקשה לשינוי עיצוב.
  • ספציפיקציה לוגית: מבנה התוכנה (לדוגמה, קבוצות עיקריות של מודולי קוד שתומכים בפונקציה דומה), מודולי קוד אינדיבידואלים והיחס ביניהם, ופרמטרים של נתונים שהם מעבירים ביניהם ניתנים לתיאור במסמך פורמלי שנקרא ספציפיקציה לוגית. מסמך זה מתאר את הממשקים הפנימיים, ומשתמשים בו רק המפתחים, בקרים, ובהמשך, במידה מסוימת, המתכנתים שעוסקים במוצר ומספקים תיקוני קוד לשדות.
  • תיעוד למשתמש: באופן כללי, כל המסמכים הקודמים (חוץ מהספציפיקציה הלוגית) משמשים כחומר מקור עבור המדריכים הטכניים והמידע המקוון (online) (כגון דפי עזר) שמכינים עבור המשתמשים במוצר.
  • תכנית בדיקה: לרוב קבוצות הפיתוח יש תכנית בדיקה פורמלית שמתארת דוגמאות בדיקה לצורך תרגול עם התוכנה שנכתבה. הבדיקה נערכת ברמת מודול (או יחידה), ברמת רכיב, וברמת מערכת בהקשר עם מוצרים אחרים. ניתן להתייחס לבדיקה כזו כ לבדיקת alpha. התכנית יכולה לאפשר גם בדיקת beta. חברות מסוימות מספקות וורסיה מוקדמת של המוצר לקבוצה נבחרת של לקוחות לצורך בדיקה "בעולם האמיתי".
  • המוצר הסופי: באופן אידאלי, המוצר הסופי הוד יישום מלא של הספציפיקציה הפונקציונלית והבקשות לשינוי עיצוב, שחלקם יכולות לנבוע מבדיקה פורמלית ובדיקת beta.

סדרת צעדים זו יכולה לחזור על עצמה בוורסיה הבאה של המוצר, החל מהצהרת הדרישות, שבאופן אידאלי מתייחסת למשוב חוזר מהלקוחות לגבי המוצר בשימוש, להחלטה על הצורך או רצון הלקוחות בהמשך.

רוב כותבי התוכנה דבקים לתהליך פיתוח פורמלי דומה לזה המתואר מעל. תהליך פיתוח החומרה דומה, אך מכיל שיקולים נוספים לביצוע מיקור חוץ ווידוא לתהליך היצור עצמו.

לפירוט נוסף בנושא  תוכנה מומלץ לקרוא גם את ולידציה – הבטחת איכות תוכנה – QA

 

 

 

ולידציה – GAMP – Test Environments – Test Data Sets

Posted on by אביב צברי

ולידציה  Good Automated Manufacturing Practice – GAMP – Test Environments – Test Data Sets

Test data sets are often use where the test environment does no permit the use of real data for reasons of availability or confidentiality, or where the real data are not generic enough to cover certain test types (e.g., challenge testing at boundary conditions or stress testing).

                          Representative Test Environment

Test data should represent as close as possible the actual data to be operated on, in terms of volume and range of possible values (including invalid entries, to check that they can be correctly handled).

Differences between the proposed test data and the expected actual data should be detailed on the Test Specification or Protocol, and subject to impact assessment. If necessary, additional tests should be planned for the production environment in order to cover identified risk scenarios.

                         Control of Test Environment

Test data sets should be placed under configuration management and the version in use recorded.

For automatically generated data it may also be appropriate to control the utility used for generating the data, as well as the test data set

                         Removal from Production Environment

If the test data SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

If the production environment includes automatic audit trailing, then it should be recognized that all audit trail entries from the testing process will remain.

                              Test User Accounts

Test user accounts are often used to permit testers to access the system at different levels, and ensure that activities carried out during testing are easily identified within any resulting audit trail.

                          Representative Test Environment

Where test user accounts are often used, these should be set up to represent each group of users within the system, including the corresponding authorizations. For multi-lingual system, test user accounts using foreign character sets should be included. Similarly, if existing individual accounts are used for testing, representatives from each group should be included.

                         Control of Test Environment

If test user accounts are used, then the setup of the accounts should be retained as part of the test documentation. Where there are issues of data confidentiality, controls should be exercised to ensure that the use of test accounts does not cause breaches of confidentiality.

                        Removal from Production Environment

If the test user accounts are added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well.

                            Test Documentation

The test environment includes documentation used during testing. This should always include the test documentation (Test Plans and Strategies, Protocols and Test Specifications, Test Cases and Test Scripts) and the controlling Design Specifications. It may also include operating procedures such as SOPs.

The test documentation should be controlled and recorded to a level of detail that would allow it to be retrieved as part of later review of the test results. This control would, at minimum, include the recording of current document version levels.

ולידציה – GAMP – Hardware & Software Test Environments

Posted on by אביב צברי

ולידציה –  GAMP – Hardware & Software  Test Environments

Good Automated Manufacturing Practice (GAMP) Hardware (HW) Environment Test

HW can be categorized according to both GAMP 4 HW category (standard or custom) and its function within the test environment. It can be one o f these three things

 Part of the system under test, i.e., part of the production HW

 Test HW representing part of the production environment, which may be needed because it is not feasible to include a certain element of the production system in the test environment

A separate test system, which may be used to represent an external system

          Representative Test Environment

As started previously, the HW environment should represent as close as possible the production environment

For example, if the test environment uses a standard network hub of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, the network cabling in the test environment is uses short patch cables, whilst the real environment has cable runs close to the maximum recommended length, there is clearly a possibility of different network behavior, and additional tests on site may be needed to prove proper network performance

                    Control of Test Environment

For standard HW (per GAMP 4 HW Category 1), the manufacturer's reference and serial numbers should be recorded.

For custom HW (per GAMP 4 HW Category 2), the version of the item and its controlling specification should also be recorded.

For all test HW, any applicable calibration status should be recorded in the context of the specific

                         Removal from Production Environment

If the test HW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

Good Automated Manufacturing Practice (GAMP)  Software (SW) Environment Test

Test SW can also be categorized according to both GAMP 4 SW category and its function within the test environment:

Part of the system under test, i.e., part of the production HW

Test SW representing part of the production environment

A separate test system

              Representative Test Environment

The SW environment should represent as close as possible the production environment

For example, if the test environment uses a process controller of the same type as the production environment, then the substitution probable introduces low probability if invalid test results in the production environment. If, however, a particular interface is simulated in the test environment, a possibility remains that different timing factors or process dynamics could affect the operation in the production environment, and additional tests on the production interface may be appropriate

                        Control of Test Environment

For standard SW (per GAMP 4 SW Category 1, 2 or 3), the manufacturer's reference and version numbers (including installed patch cables) should be recorded. Any configuration or setup parameters should be controlled

For configured or custom SW (per GAMP 4 SW Category 4 or 5), the item should be placed under configuration management and the version in use recorded

              Removal from Production Environment

If the test SW is added in the way that it may appear in the production environment, then, this should be documented a temporary modification to the production system. Removal of the temporary modification should be documented as well

ולידציה –  GAMP – Hardware & Software  Test Environments

ולידציה – Introduction to GAMP Test Environments

Posted on by אביב צברי

ולידציה – Introduction to Good Automated Manufacturing Practice (GAMP) Test Environments

The environment in which testing is conducted should be determined based on the life cycle output of the risk assessment. The following general principles apply:

  • The proposed test environment should represent as close as possible the production environment. The differences between the two should be detailed in the Test Specification or Protocol, and should be subject to impact assessment.
  • The test environment should be controlled and recorded to a level of detail that would allow it to be reconstructed if necessary. Such control includes:
  • System hardware (HW) and software (SW) components
  • Test HW (versions, serial numbers, as appropriate)
  • Test SW (version control of any simulations)
  • Test data (version control of any test data sets, test recipes, etc.)
  • Test user accounts
  • Where test HW/SW/data/user accounts are applied as they may appear in the production environment, controls should be available to ensure that they can either be removed cleanly or isolated from use (either logically or in time).
  • Where the test environment is required to undergo a temporary change to facilitate the execution of specific tests, both the change and its removal must be formally documented.

 GAMP Test Environments

In many circumstances it is undesirable to conduct all testing on the final production environment. Common examples include:

  • Non-availability of infrastructure at the point in the project life cycle when testing is carried out.
  • Non-availability of certain interfaces.
  • Requirement to test changes outside of the production environment prior to installation.
  • Requirement to carry out tests which may be destructive to the production environment.

 

The progression of SW build from a development environment through production environment depends on the risk priority associated with the system being installed or the change being made, and on factors such as the ease of possible modification removal from the system.

A change to a custom data processing module in a large business system may require progression from a development environment to a test environment, to a validation environment, and then to the production environment. This may be required because the change is a high risk priority, and, even if the if the original module could be restored easily, the test data may remain in the production environment.

Some tests, e.g., Performance Qualification (PQ), or part of it, may need to be conducted in the production environment.

 

 

ולידציה – Design Specification – DS

Posted on by אביב צברי

ולידציה – Design Specification – DS

The Design Specification -DS is part of the validation documentation that provides information necessary to complete the design of the project. This document covers only the DCS side and integration with ELT-GHS-150-T3 Gas Heater skid

DS Content

The DS is usually structured in a relatively standard fashion, with predetermined chapters and sections, where the final contents are tailored according to the type and size of the system under validation.

:The main chapters and sections of this DS are

Hardware Specification

Wiring and Electrical Cabinet Drawing

Communication and Network Design

Other Documentation

ProfiBus Monitoring Values List

Running Logic

Alarms List

Alarm Response

Disaster Recovery

Programming Design

Appendixes

Hardware Specification

.This section defines the required I/O allocation, according to the wiring diagram document No. P09204-020 Rev2, and 35800SIS0-N0

8 digital inputs

1 digital outputs

ProfiBus connection

Wiring and Electrical Cabinet Drawing

:This section lists the following design information

New Electrical drawing is not needed

:All I/O should be named in a standard fashion, i.e., XXXX-YYY-ZZZ, where

XXXX – 4 prefix letters which indicates the containing system; in this case, the system is PRMS

.YYY – indicates the instrument type according to Siemens naming standard – document no

ZZZ – indicates the serial continuing number

.Siemens Engineering file update is needed in Chapters18C 18D 18E. Other chapters should be examine and discussed in the FRS

.BOP PLC must be stopped during the wiring and ProfiBus module installation. Dalkia should be supply with time table

Communication and Network Design

:This section lists the following design information

.The communication used in this project is Profibus

.The Profibus communication protocol and wiring design will be provided by Siemens

.Siemens Engineering file update is needed. All communication and network chapters should be updated

Communication and Network Design

Siemens Engineering file "stand alone skids and instruments" chapter should be update; all Heater manuals and instructions should be attached to this chapter.

ProfiBus Monitoring Values List

tSP Target Setpoint – Setpoint differential CT15/14 – CT15/13

All  Operator.MAIN items – To be later configured

All Operator. SYSTEM.StatusWords.Output) – To be later configured

Man Manual/Auto Mode 76 AUTO (0) – +VFD manual percents

Running Logic

start conditions

Heater valve V101 is open. – GS101 HEATER INDICATION.

Heater valve position V102 is open.

Heater bypass valve V103 is closed.

DCS 10EKA01CF001>1500m3h (indicating that at list one of the gas turbines is on).

DCS 25Barg<10EKA001CP001<45Barg (Gas pressure operation range).

All Heater trips are acknowledged and cleared.

Operator pressed "Start" from DCS.

Alarms List

All alarms from profibus

Alarm Response

Holding/Restart Logic

No alarm response from the DCS.

Disaster Recovery

Perform stop operations as in paragraph

  1. Power shut down
  2. Compressed air supply shut down

 Programming Design

AS (Automation system – PLC) that will be programmed in this integration will be BOP.

The synoptic screen will be programmed and be added to the PRMS screen, as described in Appendix 1 – Synoptic Screen.

All instruments, EG valves and transmitters, will be created according to Siemens standards.

All instruments will be set to READ ONLY, except the START and STOP buttons.

Appendixes

The DS appendixes present examples of design drawings.

Appendix 1 – Synoptic Programming Design.

Appendix 2 – Chapter 18E BOP Example of Electrical Drawing (to be updated)

Appendix 3 – Example of Network Drawing (to be updated)

 

תיקי ולידציה – מושגים כלליים

Posted on by אביב צברי

ולידציה –  מושגים כללים ועקרונות הכנת תיקי ולידציה

משתמשים במונח ולידציה  לתיאור פעילות הכוללת הכנת הוכחה מתועדת, שמעניקה מידה גבוהה של ביטחון, שתהליך ספציפי יפיק באופן קונסיסטנטי תוצאה שעומדת בספציפיקציות ותכונות איכות מוגדרות מראש

ולידציה מקושרת בד"כ עם מתקן יצור של מוצר שאיכותו עשויה להשפיע על בריאות הציבור, ולכן היא מיועדת לצמצם למינימום את אפשרויות הסיכון הפוטנציאליות שעלולות להשפיע לרעה על איכות המוצר
תהליך הולידציה חייב לעמוד בתקנים של המנהל האמריקאי FDA. התקנים הרלוונטיים ביותר לתהליך הולידציה הם:
• Good Manufacturing Practice   –  GMP
• Current Good Manufacturing Practice –  cGMP
• Good Automated Manufacturing Practice  –  AMP.
במונח GxP משתמשים יותר בחופשיות בז'רגון הולידציה בהתייחסות לאוסף כללים מנחים.
cGMP הוא הדוגמה הנפוצה ביותר של GxP. עמידה בתקני cGMP מבטיחה אחידות, עוצמה, איכות וטוהר של מוצרים רפואיים ע"י דרישות מיצרני התרופות לבקרה הולמת על תהליכי היצור שלהם.
תקנים נוספים של ה- FDA הרלוונטיים לתהליך הולידציה הם:
• Good Laboratory Practice –  GLP.
• Good Clinical Practice –  GCP.
תהליך ולידציה כולל תכנון, התקנת והפעלת מערכת ניטור ובקרה במתקו יצור, וכמו כן, תכנון וביצוע תהליכי בדיקה כדי לוודא שמערכת הניטור והבקרה עומדת בסטנדרטים של ה- FDA.
תיעוד ולידציה הינו חלק של תהליך הולידציה שמכיל רישומים כתובים ו/או אלקטרוניים ביחס להתקנה והפעלת מערכת הניטור והבקרה, וביחס לבדיקות המתאימות של אותה מערכת.
הרישומים האלקטרוניים נדרשים בד"כ לעמוד בדרישות FDA שמתייחסות להיקף וישום של התקן
Part 11 of Title 21 of the Code of Federal Regulations; Electronic Records; Electronic Signatures – 21 CFR Part 11.
רישומים אלקטרוניים –  Electronic Records יכולים להכיל כל שילוב של מלל, גרפיקה, אודיו, צילומים, או כל מידע אחר המוצג באופן אלקטרוני, כאשר אלו מיוצרים, משתנים, מתוחזקים, מתויקים, מוחזרים ומופצים ע"י מערכת מחשבים.
חתימות אלקטרוניות – Electronic Signatures יכולות להכיל אוסף של כל סמל או סדרת סמלים מבוצעים, מאומצים או מאושרים ע"י גורם שמחויב חוקית באופן שווה ערך לחתימתו בכתב.
משתמשים ברישומים וחתימות אלקטרוניים בד"כ במערכות סגורות, בהן הגישה למערכת מבוקרת ע"י צוות אחראי על התכנים של הרישומים האלקטרוניים.

  תכולת תיקי ולידציה – ולידציה –  מושגים כללים

תיקי ולידציה מכילים באופן כללי שני סוגי מסמכים:
• מסמכים קשורים לתכנון, התקנת והפעלת מערכת הניטור והבקרה:
– ספציפיקציה נדרשת ע"י המשתמש  User Requirements Specification  – URS
– ספציפיקציה של דרישות פונקציונאליות  Functional Requirements Specification -FRS
– ספציפיקציה של תכנון פונקציונאלי  Functional Design Specification – FDS
– ספציפיקציה של תכנון חומרה  Hardware Design Specification – HDS
– ספציפיקציה של תכנון תוכנה  Software Design Specification – SDS
– שרטוט צנרת ומכשור  Piping and Instrument Drawing – P&ID
– רשימת כניסות/יציאות  Input/Output (I/O) List

• מסמכים שכוללים את תהליכי הבדיקות:
– פרוטוקול קווליפיקצית התקנה  Installation Qualification (IQ) Protocol
– פרוטוקול קווליפיקצית פעולה  Operation Qualification (OQ) Protocol
– פרוטוקול קווליפיקצית ביצוע  Performance Qualification (PQ) Protocol

האחריות לכתיבת ואישור המסמכים משותפת בפועל למשתמש, שמפעיל את מתקן היצור, והספק, שמספק את מערכת הניטור והבקרה להבטחת הפעולה הנכונה של המתקן.
תיקי ולידציה כולל בנוסף חוברות הדרכה / חוברות נתונים / ברושורים של רכיבי המערכת העיקריים לתמיכת משימות הפעולה והתחזוקה של המשתמש.