פתרונות תוכנה למהנדסים

שלוש דרישות, ואיך הן נשברות

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

הגרסה שאושרה לביצוע

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

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

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

יחידות מידה: למה זו לא פדנטיות

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

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

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

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

הבדיקה שמגדירה את היקף העבודה

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

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

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

חיבור לכלי התכן: למה זה נראה קל ואינו

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

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

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

מה לא להחליף

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

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

איך אני עובד על זה

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

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