Smartlogic

ולידציה – תפקידים ואחריות בתכנון וביצוע בדיקות

מבוא

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

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

בהתאם ל- GAMP, ניתן לחלק את התפקידים והאחריות שמוגדרים בהמשך לשתי קבוצות נפרדות:

תפקידים בתוך צוות הבדיקה.

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

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

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

 מחברי קבצי הבדיקות  לא יבחנו בעצמם את הקבצים לפני ביצוע הבדיקות.

 הבודקים לא יבחנו בעצמם את תוצאות הבדיקות ורישומי התוצאות. 

תפקידים בתוך צוות הבדיקה:

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

מנתח הבדיקה -Test Analyst- מחבר קובץ הבדיקה

test script –  מגדיר את קובץ הבדיקה , כולל את ההוראות המפורטות לבדיקת תחום פונקציונאלי ספציפי במסגרת הפרויקט.

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

בוחן קובץ הבדיקה – Test Script Reviewer

מוודא שכל הדרישות מולאו כמוגדר בקבצי הבדיקות.

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

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

בודק -Tester

מבצע את הבדיקות בהתאם לקבצי הבדיקות.

מודיע על כל חריגה למנהל -Incident Manager.

מפיק ומתאים את הוכחה המתועדת לדרישות קבצי הבדיקות.
 

עד בדיקה– Test Witness

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

בוחן תוצאות הבדיקה – Test Result Reviewer

מוודא שכל מהלכי הבדיקות בוצעו כמוגדר בקבצי הבדיקות.

מוודא שכל ההוכחה המתועדת הופקה, נחתמה, תוארכה וקושרה כנדרש בכל שלבי הבדיקות הרלוונטיים.

מוודא שכל החריגות נרשמו.

מאמת את כל תוצאות הבדיקות (מצב עבר/נכשל), בהתבסס על ההוכחות המתועדות.

מנהל הבדיקות – Test Manager

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

מוביל צוות הבדיקות– Test Team Leader

מפקח על התיאום וביצוע של הבדיקות בתחומים מוגדרים בצוותי בדיקה גדולים.

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

צוות תשתיות הבדיקה-Test Infrastructure Team

מספק את החומרה וחיבורי הרשת הנדרשים להפעלת מערך בדיקה בהתאם לאפיונים המוגדרים.

סגל טכני -Technical Staff

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

אדמיניסטראטור של צוות הבדיקות -Test Team Administrator

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

ניהול התיעוד.

עזרה בהקצאת משאבים ופעילויות של רישום זמנים.

רישום פרוטוקולים בפגישות רלוונטיות.

פעילויות אחרות מוקצבות ע"י מנהל הבדיקות.

 

  תפקידים מול צוות הבדיקה:

מפתח תוכנה – Software Developer

עוזר בניתוח מקרים חריגים שקשורים לתוכנה במהלך הבדיקות.

מספק תמיכה לצוות הבדיקה במקרה מספק תמיכה למחבר קובץ הבדיקה בתחילת יישום התכנוןשל שינויי תכנון הנדרשים לפתרון מקרים חריגים שקשורים לתוכנה.

מנהל מקרים חריגים – Exceptions/Incidents Manager

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

עוזר בניתוח מקרים חריגים שקשורים לתוכנה במהלך הבדיקות.

מספק תמיכה לצוות הבדיקה במקרה של שינויי תכנון הנדרשים לפתרון מקרים חריגים שקשורים לתוכנה.
 

אבטחת איכות / בקרת איכות Quality Assurance / Quality Control – QC/QA

תפקיד זה יכול להתבצע ע"י מומחה לוולידציה של מערכות ממוחשבות או איכות טכנולוגית מידע ולמעשה ע"י אנשי אנשי צוות טכני מוסמכים מחוץ למחלקת  QC/QA:

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

מספק תמיכה לצוות הבדיקה במקרה של שינויי תכנון הנדרשים לפתרון מקרים חריגים שקשורים לתוכנה.
 

מנהל הפרויקט – Project Manager

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

אחראי על פתרון בעיות מחריפות עם אימפליקאציות רחבות שמשפיעות לרעה מעבר לצוות הבדיקה.
 

מנהל התוכנית – Program Manager

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

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

 בעל המערכת  System Owner

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

 QA -גורם שבד"כ מקבל את דו"ח הבדיקה לבחינה וחתימה, בעזרת צוות ה.
  

 מבקר פנימיInternal Auditor

גורם מעורב בפעילות פנימית תקופתית כדי לוודא שפעילויות הבדיקה בוצעו בהתאם לפרוצדורות שנקבעו מראש.
 

אדמיניסטראטור המערכת – System Administrator

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

  במידה הצורך, יסייע לצוות הבדיקה במקרים של בעיות במהלך הבדיקה .

מנהל הקונפיגורציה  – Configuration Manager

 . baseline- אחראי על קביעה שורת הבסיס לפריטי הקונפיגורציה של המערכת הנבדקת.

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

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

מנהל את שורת הבסיס עבור תיעוד הבדיקות, בהתאם לתוכנית ניהול התיעוד של הפרויקט.
 

צוות ניהול המידע – Data Management Staff

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

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

בדיקות קבלה – משתמשAcceptance Testing

משתמשי המערכת אחראים בד"כ על הביצוע הסופי של בדיקות הקבלה (Acceptance Testing) ועל הגדרת קבצי הבדיקה (Test Scripts) עבור בדיקות הקבלה.

המשתמשים נתמכים ברוב המקרים ע"י ארגון בדיקה – Test Analysis and Testers.

ספק – Supplier

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

תוצאות הערכת הספק יכולות לשמש כעזר בהגדרת היקף הבדיקות.

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

 

פונקציות בסיסיות בסביבת עבודה של תוכנת Cimplicity

Cimplicity הינה תוכנת בקרה (scada) מבית היוצר של GE-General Electric.

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

דברים בסיסיים:

איך עושים שמסך ההתראות יקפוץ בכל התראה חדשה?

  • מגדירים תג חדש בשם ALARMֹI_IS_ON
  • ב-Event Editor מגדירים Event חדש מסוג: Alarm generate.
  • ב Action של ה Event  : Absolute SP -> Alarm_is_ON=1
  • יוצרים אוביקט במסך Objects.
  • באוביקט שיצרנו עושים תנאי ב- events -> if Alarm_is_on==1 -> OpenScreen Alarm.cim
  • שמים לינק בכל מסך לאוביקט הזה.
  • במסך התראות -> OnScreenOpen -> ALARM_IN_ON=0

תקלות:

לא רואים התראות במסך ההתראות

אפשרות מס' 1: בוצעו שינויים לא במצב דינאמי.

פתרון: יש לעשות stop ו start  לפרויקט.

 

אפשרות מס' 2: הפרוייקט לא מקושר למסך התראות.

פתרון: במסך ההתראות-> כפתור ימני על הOLE -> Add Project.

 

אפשרות מס' 3: אף משתמש לא מקושר להתראה הספציפית.

פתרון: במסך של הנקודה בלשונית Alarm Routing -> העבר את כל השמות שבשדה Available roles לשדה "Configured roles for alarm" (לסמן הכל משמאל ולהעביר לשדה הימני).

תקן 21CFRPart11 – הסבר כללי על קצה המזלג

הסבר כללי על השימוש ב 21CFRPart11

ראשית דבר נרצה לחשוף את הקוראים המבינים יותר והמבינים פחות למושג ה-CFR. מה זה בעצם CFR? תקן 21CFRPart11 הוא קיצור של Code of Federal Regulation, מכיל בתוכו את מערכת החוקים של מדינת ארה"ב ומחולק ל 50 כותרים ( Titles) כדוגמת:

Title 16: Commercial Practices, Title 17: Commodity and Securities Exchanges ,Title 18:   Conservation of Power and Water Resources etc…

בהקשר לעניינו CFR-21 הוא קובץ הנחיות המתייחס לרישומים האלקטרוניים והחתימה האלקטרונית במערכות אוטמציה ובקרה. תעשייני הפארמה מכירים את קובץ הנחיות זה טוב מאוד והוא משמש כמרכיב עיקרי במלאכת הולידציה של מערכות מפוקדות. קיימים מס' חברות בקרה בארץ אשר מספקות שירותי ולידציה אשר מתמחות בסעיף זה, אחת מהמובילות בתחום היא חברת סמארט לוג'יק.

כפי שנאמר קודם 21 CFR PART 11 מכיל חוקים למערכות ממוחשבות בכל הנוגע ל FDA. תפקידו העיקרי- להמנע בשימוש בנייר, על ידי הסתמכות על המערכת הממוחשבת.

למה אנחנו צריכים את זה?

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

חשוב להבין את מהות הואלידציה, המרת המערכת לתמיכה בסעיף 21 CFR 11 לכשעצמה אינה מספיקה. בכדי שהמערכת תהיה בעלת אישור ה-FDA יש לצרף למערכת את תיק הולידציה לאות הוכחה והכרה.

הדרישות הבסיסיות להכרה ב- CFR 11 היא בחירה במערכת ממשק משתמש תומכת, פיתוחה על ידי שימוש בכללים המופיעים בתקן וכאמור ביצוע ואלידציה וצירוף תיק הואלידציה עצמו.

 

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

Sub-Section a – הגדרות כלליות

החלק הראשון מתייחס להגדרות כלליות,  השני לרשומות אלקטרוניות והשלישי לחתימה אלקטרונית.

החלק הראשון מכיל תת סעיפים אשר מפרטים את היקף המסמך ( Scope 11.1) מה דרוש ליישום ( Implementation 11.2) והנחיות והגדרות לשימוש בו ( 11.3 Definitions).

בין הסעיפים העיקריים: מה נחשב לרשומה אלקטרונית ומה נחשב לביומטריה.

רשומה אלקטרונית ( Electronic Record): כל שימוש בטקסט, גרפיקה, נתונים, שמע, או כל ייצוג מידע אחר בצורה דיגיטאלית שנוצר על ידי מערכת מחשב.

חתימה אלקטרונית (Electronic Signature): סימן או רצף של סימנים אשר בעזרתם ניתן לקשור את החותם , ובעזרתה יכולה להחליף חתימה בכתב יד.

חתימה דיגיטלית (Digital Signature): חתימה אלקטרונית המבוססת על שיטת הצפנה ואשר מקיימת את סט החוקים שנקבעו על מנת שתהיה מאושרת בעזרתה ניתן לאמת את החותם ואת אמינות הנתונים.

שתיים מההגדרות הקריטיות המוזכרות בחלק זה אשר רלוונטיות לעמידה בתקן 21CFRPart11 הן הגדרות המערכת הסגורה והפתוחה.

מערכת סגורה: סביבה שבה הגישה אליה מבוקרת באמצעות אדם אשר אחראי לרשומות האלקטרוניות שנמצאים במערכת.

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

Sub-Section B – Electronic Records – רשומות אלקטרוניות

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

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

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

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

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

תת תקנה (e ) מתייחסת למושג מאוד מרכזי בעולם הואלידצה הלוא הוא ה- Audit-trail ,בפירוש חופשי וכללי של מושג זה ניתן להגדירו לפי הדרישה אשר אומרת כי כל רשומה אשר נעשתה במערכת חייבת להיות מעוגנת בתאריך אוטומטי. כל שינוי, עדכון, מחיקה של רשומה על ידי מפעיל חייבת להיות מתועדת. כמו כן יש לוודא ששינויים חדשים לא ימחקו את התיעוד של השינויים הקודמים. סעיף זה הוא קריטי ביותר לואלידציית המערכת במובן הזה שהוא לא משאיר כל מקום לאי ודאות, לכל שינוי ערך או הרמת התראה יש פירוט ואין החסרה של נתונים הן מהמפעילים והן מאיש הביקורת. רק בכדי להדגים את חשיבות התקנה, על מסד הנתונים לאפשר שחזור נתונים של עד 7 שנים אחורה.

מעבר לדרישת הגנת הרשומות, תת חלק 2 מתייחס גם לצורך שהמערכת תגיב אוטומטית על מנת לדאוג שהתפ"מ המורשה יעבוד כמתוכנן. תת תקנה (f) באה לאמר שמעבר לפעילות התקנית של מערכת הבקרה, עליה גם להיות בתאימות מלאה למסמכי התכנון המקדימים (FDS (. בדרך כלל, כאשר מדובר בתעשייה התהליכית תת תקנה (f) משחקת שחקן מרכזי בתיק הואלידציה ובתכנון הבקרה עצמה. מעבר לתאימות למסמכי התכנון, יישום תקנה זו בממשק המשתמש גם באה לידי ביטוי בכך שהמערכת תאכוף החלת סיסמאות לכל שינוי וקביעת גבולות נקודות עבודה ריאליות ביחס ל- FDS.

Sub-Section C – Electronic Signatures

תת חלק זה מתייחס לתקנות הנדרשות על מנת שהמערכת תהיה מאושרת לשימוש בחתימות דיגטליות. מאחר והדרישות לבדיקה ארוכות מאוד 99% מהלקוחות מעדיפות לא להשתמש בחתימות דיגטליות.