Smartlogic

ולידציה – URS and FRS Preparation Overview

ולידציה – URS and FRS Preparation Overview

 This article was written by Iian Shaya, validation,automation and control expert

User Requirements Specification (URS) and Functional Requirements Specification (FRS) are the first and starting points of a validation process and a validation documentation file

  – The validation process must comply with regulations issued by the United States Food and Drug Administration FDA

:The FDA regulations that are most relevant to the validation process are

Good Manufacturing Practice  – GMP.

Current Good Manufacturing Practice – cGMP

Good Automated Manufacturing Practice – GAMP

The validation process includes design, installation and operation of a monitoring and control system for a production facility, as well as planning and execution of test procedures, to verify that a monitoring and control system meets the FDA standards

Validation documentation is part of the validation process that includes written and/or electronic records regarding the installation and operation of the monitoring and control system, and the corresponding test procedures for this system

Electronic records are often required to fulfill regulations set by the FDA. These regulations regard the scope and application of Part 11 of Title 21 of the Code of Federal Regulations; Electronic Records; Electronic Signatures (21 CFR Part 11). Electronic Records may contain any combination of text, graphics, audio, pictures, or other information represented in electronic form, which are created, modified, maintained, archived, retrieved or distributed by a computer system

Electronic Signatures may contain computer data compilation of any symbol or series of symbols executed, adopted or authorized by an individual to be legally binding equivalent of the individual's handwritten signature

Electronic records and signatures are generally used in Closed Systems, in which the system access is controlled by personnel responsible for the contents of the system electronic records

The responsibility for writing and approving the URS and FRS is shared in practice by the user, who operates the production facility, and the supplier or vendor, who provides the monitoring and control system for ensuring the proper operation of the production facility. Usually, the URS is written by the user and the FRS by the supplier

:Note

The final contents of the URS and FRS are tailored according to the type and size of the system under validation. Since the URS and FRS regarded herein are generic, they include requirements that may not be necessary in small or simple systems

 This article was written by Iian Shaya, validation,automation and control expert

ולידציה – GAMP – Test Example – part 2

Good Automated Manufacturing Practice (GAMP) – Test Example

Testing Process Automation Systems

This article cover  the second part of  our  Good Automated Manufacturing Practice (GAMP) test example. This part will cover  the typical test phases for supplier's application SW Module Testing, supplier's Module Integration Testing and the supplier's Integration Testing – cont'd

                     Typical Test Phases

 Typical test phases for a complex process automation system. This example assumes that the system is configured by a Supplier and delivered to site after a FAT. Test system can also be configured by the system integrator or by the User. In this case, the same coverage is required, but the test phasing and location may be different.

The User and Supplier should work together to develop an overall approach to testing that reflects the risk assessment output and ensures adequate test coverage of the functionality, whilst avoiding unnecessary repeated tests.

: Typical Test Phases for Process Automation Systems

 Supplier's Application SW Module Testing

Done at the Supplier's premises after the module has been placed under configuration control and code reviewed. Before system integration. Module testing generally covers: Module data handling

 Interfaces to other modules

 Operator interfaces

 Module functionality Failure paths and response to fault conditions should be included within the tests

Supplier's Module Integration Testing

Done at the Supplier's premises.After individual module have been tested and integrated into a single unit.Before full system integration

Module integration testing generally covers: Correct operation of Interfaces between modules

Failure paths and response to fault conditions should be included within the tests

Supplier's Integration Testing –

Done at the Supplier's premises.After module testing, and before the User is invited to witness the FAT

Integration testing generally covers:

 HW

I/O interfaces

Operator interfaces

Interfaces to other equipment

System functionality

Data handling functions

Failure paths and response to fault conditions should be included within the tests

:HW tests typically include

·      Checking system build against approved HW specifications and drawings

·      Recording system components, version numbers (including SW versions) and capacities

·      Checking electrical supplies and grounding

Supplier's Integration Testing (cont'd) –

Checking correct power up of system components

Checking any self test/diagnostic information

Checking correct communication on standard interfaces

:I/O interface tests typically include

Exercising inputs and outputs to check correct configuration of ranges, alarms, etc.

:Operator interface tests typically include

System displays and navigation

Security and access controls

:Tests for interfaces to other equipment typically include

Checks of communications protocol setup

Checks that the required data can be transferred

Checks of actions in case of communications failure

Tests for system functionality typically include:

Monitoring functions

Alarm strategies

Control functions)control modules, equipment modules, procedural control(

Power failure and recovery

Component failure and redundancy

Performance checks

:Tests for system data handling typically include

Operator data entry

Data formatting and quality checks

Checks of calculated values

Checks of recipes

Checks of access to current process data, alarms and events )displays, alarm summaries, etc.(

Checks of access to historical process data, alarms and events )trends, reports, alarm histories, etc.(

Checks of audit trail functionality

Checks of data capacity and retention times

Checks of archive and restore

Checks of provisions for electronic signatures

Checks of disaster recovery procedures

End of  ולידציה – GAMP – Test Example – part 2

 

 

 

 

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

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

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

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

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

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

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

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