למה קושחה היא הצוואר של המוצר הכשר
במוצר מכני אפשר להראות לבודק את המנגנון והוא רואה במו עיניו מה קורה. בקושחה אין מה לראות — יש התנהגות, ויש הבטחה. מכאן שכל המשקל עובר לשאלה אחת: איך מוכיחים שהמוצר עושה בדיוק את מה שנטען שהוא עושה, ולא משהו אחר בתנאי קצה כלשהו. זהו בדיוק אותו אתגר שקיים ברגולציה של מכשור רפואי, והכלים דומים במידה מפתיעה.
שרשרת העקיבות
הלב של השיטה הוא טבלה שמקשרת בין ארבע רמות:
- הדרישה ההלכתית כפי שנוסחה עם הפוסק — למשל: "פתיחת דלת לא תגרום להפעלת מדחס".
- דרישת המערכת שנגזרת ממנה — "במצב שבת, מצב מתג הדלת אינו נכנס לחישוב החלטת המדחס".
- המימוש — קובץ, פונקציה ומספר שורה שבהם הדרישה ממומשת.
- הבדיקה — מספר מקרה בדיקה, שיטת מדידה, ותוצאה מתועדת.
טבלה כזו נבנית תוך כדי פיתוח, לא בסופו, ובדיוק בגלל זה היא עובדת. היא מייצרת גם תופעת לוואי מבורכת: כשמנסחים דרישה כך שאפשר לבדוק אותה, מגלים מוקדם שהניסוח ההלכתי המקורי היה עמום — וחוזרים לשאול. תהליך השאלה מפורט בעבודה מול פוסק בצוות פיתוח.
שלוש שכבות בדיקה
בדיקות יחידה
ברמת הפונקציה: האם שכבת הפלט חוסמת כל קריאה כשהמצב פעיל. הבדיקות האלה רצות אוטומטית בכל בנייה, והן הדבר היחיד שמונע רגרסיה כשמישהו מוסיף תכונה חודשיים אחר כך.
בדיקות מערכת
על החומרה עצמה, עם מדידה חיצונית: מדידת זרם, מיקרופון, מצלמה, לוגר. העיקרון החשוב הוא שהבדיקה מודדת מבחוץ ולא מדווחת מבפנים — מוצר שמדווח על עצמו "אני במצב שבת" אינו ראיה.
בדיקת ממושכת
הרצה של יממה ומעלה תחת פעילות משתמש, כמפורט באמינות והפעלה רציפה במוצרי שבת. זו הבדיקה שמגלה את מה שאף סקירת קוד לא תמצא.
מה נכנס לתיק התיעוד
- מסמך הדרישות ההלכתיות החתום, עם שם הגורם המאשר ותאריך.
- תיאור ארכיטקטורה שמראה את הפרדת המסלולים ואת שכבת הפלט האחת.
- טבלת העקיבות המלאה.
- דוחות בדיקה עם נתונים גולמיים, לא רק סיכומים.
- גיבוב הגרסה שנבדקה, ורשימת כל הרכיבים שנכללו בה.
- ניתוח מה קורה בכל אחד ממצבי הכשל האפשריים.
התיק הזה הוא חלק מתיק המוצר ומתיק הייצור, והוא מה שמאפשר לגשת לבדיקה במכון הלכתי בסבב אחד במקום בשלושה.
ניהול גרסאות אחרי אישור
כאן נמצאת המלכודת הגדולה. מוצר מקבל אישור על גרסת קושחה מסוימת, ואז מגיע עדכון: תיקון באג, תמיכה ברכיב חדש, שיפור ביצועים. שלוש כללים שאנחנו עובדים לפיהם:
ראשית, כל גרסה מקבלת מספר וגיבוב, ואף גרסה לא יוצאת ללקוח בלי שהיא נמצאת בטבלה. שנית, כל שינוי מסווג מראש — האם הוא נוגע בהתנהגות מצב השבת או לא. שינוי שנוגע מחייב סבב אישור חוזר; שינוי שאינו נוגע דורש ראיה לכך, לא הצהרה. שלישית, עדכון מרחוק דורש מדיניות מפורשת: לעולם לא בשבת, ורק אחרי אישור מפורש של המשתמש. ההיבטים הטכניים של עדכון כזה מפורטים בעדכוני תוכנה מרחוק במוצר, ותהליך ניהול השינוי הכללי — בניהול שינויים הנדסי.
העלות האמיתית
יזמים שואלים כמה זה מוסיף לפרויקט. התשובה הכנה: בין עשרה לעשרים אחוז מזמן הפיתוח, רובו בשלב הראשון של ניסוח הדרישות. בתמורה מקבלים מוצר שעובר אישור בסבב אחד, שאפשר לתחזק אותו שנים בלי לשבור את מה שאושר, ושאפשר להראות אותו ללקוח מוסדי בלי להסמיק. בשוק שמתואר בשוק המוצרים הכשרים לשבת, האמון הזה הוא הנכס העיקרי.
רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.
