המקום שבו פרויקטים נתקעים

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

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

מה מגדירים בחוזה הממשק

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

ההבדל שמפתחי תוכנה מגלים בקושי

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

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

איפה עובר הגבול בין המוצר לענן

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

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

לעבוד במקביל ולא בטור

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

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

אינטגרציה מוקדמת ומתמשכת

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

חיבור ראשוני – השלב שקובע את הרושם

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

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

למי זה שייך

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

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