מה ההבדל בין הסמכת תפעול (OQ) לבין הסמכת ביצועים (PQ)?


תשובה 1:

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

התיקוף של מתקנים, מערכות או ציוד חדשים מתבצע בדרך כלל באמצעות תהליך של ארבעה שלבים של הסמכת תכנון (DQ), הסמכת התקנה (IQ), הכשרה תפעולית (OQ) והסמכת ביצועים (PQ).

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

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

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

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

ומתקני ISO 13485: מדריך מלא לניהול איכות בענף המכשור הרפואי: 9781439866115: ספרי מדעי הבריאות והבריאות @ Amazon.com עמודים 224 ו- 230:

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

• התוצאות מתקבלות בתנאי הייצור המתאימים.

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

• ההערכה מספקת עמידה בדרישות ובמפרטים.

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


תשובה 2:

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

ה- OQ מקיף כדי "להוכיח" שהתוכנה המותקנת פועלת על פי "התכנון המיועד" שלה על ידי מפתחי התוכנה, על פי "השימוש המיועד של המשתמשים". זה חייב לכלול בדיקת מתח בפרמטרים מקסימלים ומינימום, כולל עומס עבודה מקסימלי המיועד. בערך רביעית, אך לא יותר משליש, של ה- OQ אמורה לאמת שהתוכנה חוסמת ערכים לא חוקיים. דוגמאות: להוכיח ש"סיסמה ישנה "של משתמש לא תאפשר למשתמש לפתוח את התוכנה; להוכיח ששדה המיועד לקבל ספרות בלבד יחסום את המשתמש בכניסה או שמירה של אותיות בשדה. בדיקות אלה כוללות אימות כאשר מופיעה הודעת שגיאה. אם הודעת השגיאה אמורה לציין מהי השגיאה, בדוק גם זאת. זהירות: אינך צריך לאמת את המילים או המשפט המדויקים, מכיוון שדיוק המידע המועבר הוא הגורם החשוב. ה- OQ הוא בדרך כלל גדול מאוד ונדרש מספר ימים (או שבועות) להשלמתו. בדיקות ה- OQ עשויות להתבצע על ידי אחד או יותר מהאנשים המיומנים של חברת המשתמש - היו צריכים להיות מאומנים רשמית בתוכנה - או על ידי משתמשים ייעודיים / מיועדים, או על ידי איש IT, או שניתן למקם מיקור חוץ למקבלן שהועבר רשמית. הוכשר על התוכנה. ה- OQ חייב לכלול בדיקות אבטחה יסודיות לפי 21 CFR חלק 11 של ה- FDA ו / או לפי הוראות האיודרלקס של האיחוד האירופי בנספח 11. דרישות האבטחה הללו חלות על סביבות GLP, GMP ו- GCP. חשיבות היא שמבחני ה- OQ חייבים להדגים שהתוכנה פועלת באופן עקבי, מדויק, מהימן ושחזור. אם התוכנה נוצרת על ידי חברת תוכנה שמוכרת את התוכנה כ- COTS (מסחרית מהמדף), על OQ לבדוק רק את הדרישות התפקודיות בהן מתכוונת חברת המשתמש להשתמש.

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

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

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

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

ה- DQ משמש לשני מצבים. ראשית, עבור תוכנה שפותחה "פנימית", כלומר מדובר בתוכנה קניינית שנוצרה על ידי החברה שמתכוונת להשתמש בתוכנה. לגבי smplicity אני אקרא לזה חברת המשתמש. המצב השני הוא כאשר חברה מוסדרת יוצרת גיליון אלקטרוני (למשל באמצעות Microsoft Excel). הכנסת הפונקציות המתוכנתות של אקסל הן סוג של תכנות תוכנה, שתוכנן גיליון אלקטרוני לייבוא ​​נתונים או טקסט, לחישוב, וכי טקסט קבוע (כגון כותרות) הם כולם סוג של "תכנות", הדורש אימות מלא עם כל מסמכי אימות (DQ, בדיקות יחידה, IQ, OQ, PQ, דוחות סיכום, SOPs, הוראות למשתמש וכו '). אני לא מודע לתוכנה המפתחת חברות המייצרות גיליונות אלקטרוניים עבור לקוחותיהם / חברות המשתמש שלהם, אך חלק מהמפתחים עשויים לעשות זאת כעת. אז ה- DQ הוא תמיד מסמך מוסדר המבוסס על רשימת יוצר התוכנה של הפונקציות ה"נתפסות "הנחוצות והמבוקשות על ידי המשתמשים.

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

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

כאשר OQ ו- PQ חופפים הרבה, מקובל לייצר מסמך OQ / PQ משולב אחד.

מטריצת העקביות צריכה להתחקות אחר 'הדרישות' של כל חברת משתמש ל- IQ, OQ, PQ ו / או SOP העומדים בדרישה. יתכנו מספר שלבי בדיקה הנדרשים כדי לעמוד בדרישה "מלאה" אחת.

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

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

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

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


תשובה 3:

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

ה- OQ מקיף כדי "להוכיח" שהתוכנה המותקנת פועלת על פי "התכנון המיועד" שלה על ידי מפתחי התוכנה, על פי "השימוש המיועד של המשתמשים". זה חייב לכלול בדיקת מתח בפרמטרים מקסימלים ומינימום, כולל עומס עבודה מקסימלי המיועד. בערך רביעית, אך לא יותר משליש, של ה- OQ אמורה לאמת שהתוכנה חוסמת ערכים לא חוקיים. דוגמאות: להוכיח ש"סיסמה ישנה "של משתמש לא תאפשר למשתמש לפתוח את התוכנה; להוכיח ששדה המיועד לקבל ספרות בלבד יחסום את המשתמש בכניסה או שמירה של אותיות בשדה. בדיקות אלה כוללות אימות כאשר מופיעה הודעת שגיאה. אם הודעת השגיאה אמורה לציין מהי השגיאה, בדוק גם זאת. זהירות: אינך צריך לאמת את המילים או המשפט המדויקים, מכיוון שדיוק המידע המועבר הוא הגורם החשוב. ה- OQ הוא בדרך כלל גדול מאוד ונדרש מספר ימים (או שבועות) להשלמתו. בדיקות ה- OQ עשויות להתבצע על ידי אחד או יותר מהאנשים המיומנים של חברת המשתמש - היו צריכים להיות מאומנים רשמית בתוכנה - או על ידי משתמשים ייעודיים / מיועדים, או על ידי איש IT, או שניתן למקם מיקור חוץ למקבלן שהועבר רשמית. הוכשר על התוכנה. ה- OQ חייב לכלול בדיקות אבטחה יסודיות לפי 21 CFR חלק 11 של ה- FDA ו / או לפי הוראות האיודרלקס של האיחוד האירופי בנספח 11. דרישות האבטחה הללו חלות על סביבות GLP, GMP ו- GCP. חשיבות היא שמבחני ה- OQ חייבים להדגים שהתוכנה פועלת באופן עקבי, מדויק, מהימן ושחזור. אם התוכנה נוצרת על ידי חברת תוכנה שמוכרת את התוכנה כ- COTS (מסחרית מהמדף), על OQ לבדוק רק את הדרישות התפקודיות בהן מתכוונת חברת המשתמש להשתמש.

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

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

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

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

ה- DQ משמש לשני מצבים. ראשית, עבור תוכנה שפותחה "פנימית", כלומר מדובר בתוכנה קניינית שנוצרה על ידי החברה שמתכוונת להשתמש בתוכנה. לגבי smplicity אני אקרא לזה חברת המשתמש. המצב השני הוא כאשר חברה מוסדרת יוצרת גיליון אלקטרוני (למשל באמצעות Microsoft Excel). הכנסת הפונקציות המתוכנתות של אקסל הן סוג של תכנות תוכנה, שתוכנן גיליון אלקטרוני לייבוא ​​נתונים או טקסט, לחישוב, וכי טקסט קבוע (כגון כותרות) הם כולם סוג של "תכנות", הדורש אימות מלא עם כל מסמכי אימות (DQ, בדיקות יחידה, IQ, OQ, PQ, דוחות סיכום, SOPs, הוראות למשתמש וכו '). אני לא מודע לתוכנה המפתחת חברות המייצרות גיליונות אלקטרוניים עבור לקוחותיהם / חברות המשתמש שלהם, אך חלק מהמפתחים עשויים לעשות זאת כעת. אז ה- DQ הוא תמיד מסמך מוסדר המבוסס על רשימת יוצר התוכנה של הפונקציות ה"נתפסות "הנחוצות והמבוקשות על ידי המשתמשים.

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

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

כאשר OQ ו- PQ חופפים הרבה, מקובל לייצר מסמך OQ / PQ משולב אחד.

מטריצת העקביות צריכה להתחקות אחר 'הדרישות' של כל חברת משתמש ל- IQ, OQ, PQ ו / או SOP העומדים בדרישה. יתכנו מספר שלבי בדיקה הנדרשים כדי לעמוד בדרישה "מלאה" אחת.

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

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

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

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


תשובה 4:

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

ה- OQ מקיף כדי "להוכיח" שהתוכנה המותקנת פועלת על פי "התכנון המיועד" שלה על ידי מפתחי התוכנה, על פי "השימוש המיועד של המשתמשים". זה חייב לכלול בדיקת מתח בפרמטרים מקסימלים ומינימום, כולל עומס עבודה מקסימלי המיועד. בערך רביעית, אך לא יותר משליש, של ה- OQ אמורה לאמת שהתוכנה חוסמת ערכים לא חוקיים. דוגמאות: להוכיח ש"סיסמה ישנה "של משתמש לא תאפשר למשתמש לפתוח את התוכנה; להוכיח ששדה המיועד לקבל ספרות בלבד יחסום את המשתמש בכניסה או שמירה של אותיות בשדה. בדיקות אלה כוללות אימות כאשר מופיעה הודעת שגיאה. אם הודעת השגיאה אמורה לציין מהי השגיאה, בדוק גם זאת. זהירות: אינך צריך לאמת את המילים או המשפט המדויקים, מכיוון שדיוק המידע המועבר הוא הגורם החשוב. ה- OQ הוא בדרך כלל גדול מאוד ונדרש מספר ימים (או שבועות) להשלמתו. בדיקות ה- OQ עשויות להתבצע על ידי אחד או יותר מהאנשים המיומנים של חברת המשתמש - היו צריכים להיות מאומנים רשמית בתוכנה - או על ידי משתמשים ייעודיים / מיועדים, או על ידי איש IT, או שניתן למקם מיקור חוץ למקבלן שהועבר רשמית. הוכשר על התוכנה. ה- OQ חייב לכלול בדיקות אבטחה יסודיות לפי 21 CFR חלק 11 של ה- FDA ו / או לפי הוראות האיודרלקס של האיחוד האירופי בנספח 11. דרישות האבטחה הללו חלות על סביבות GLP, GMP ו- GCP. חשיבות היא שמבחני ה- OQ חייבים להדגים שהתוכנה פועלת באופן עקבי, מדויק, מהימן ושחזור. אם התוכנה נוצרת על ידי חברת תוכנה שמוכרת את התוכנה כ- COTS (מסחרית מהמדף), על OQ לבדוק רק את הדרישות התפקודיות בהן מתכוונת חברת המשתמש להשתמש.

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

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

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

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

ה- DQ משמש לשני מצבים. ראשית, עבור תוכנה שפותחה "פנימית", כלומר מדובר בתוכנה קניינית שנוצרה על ידי החברה שמתכוונת להשתמש בתוכנה. לגבי smplicity אני אקרא לזה חברת המשתמש. המצב השני הוא כאשר חברה מוסדרת יוצרת גיליון אלקטרוני (למשל באמצעות Microsoft Excel). הכנסת הפונקציות המתוכנתות של אקסל הן סוג של תכנות תוכנה, שתוכנן גיליון אלקטרוני לייבוא ​​נתונים או טקסט, לחישוב, וכי טקסט קבוע (כגון כותרות) הם כולם סוג של "תכנות", הדורש אימות מלא עם כל מסמכי אימות (DQ, בדיקות יחידה, IQ, OQ, PQ, דוחות סיכום, SOPs, הוראות למשתמש וכו '). אני לא מודע לתוכנה המפתחת חברות המייצרות גיליונות אלקטרוניים עבור לקוחותיהם / חברות המשתמש שלהם, אך חלק מהמפתחים עשויים לעשות זאת כעת. אז ה- DQ הוא תמיד מסמך מוסדר המבוסס על רשימת יוצר התוכנה של הפונקציות ה"נתפסות "הנחוצות והמבוקשות על ידי המשתמשים.

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

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

כאשר OQ ו- PQ חופפים הרבה, מקובל לייצר מסמך OQ / PQ משולב אחד.

מטריצת העקביות צריכה להתחקות אחר 'הדרישות' של כל חברת משתמש ל- IQ, OQ, PQ ו / או SOP העומדים בדרישה. יתכנו מספר שלבי בדיקה הנדרשים כדי לעמוד בדרישה "מלאה" אחת.

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

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

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

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