2.3.2016 - 10 הדברים שלמדתי בפרויקט ממוחשב מרובה ממשקים
נכתב ע"י לוי דביש, מהנדס מערכת בפנדה-טק
לאחרונה סיימנו בהצלחה פיתוח של תוכנת מחשב בדיקות לצורכי תחזוקה. מחשב זה הינו לב ליבה של מערכת מרובת ממשקים שאת הממשקים שלה אמור המחשב לבדוק. לצוות פנדה-טק היה תפקיד מכריע בכל שלבי הפרויקט החל מהגדרת דרישות המערכת, דרך עיצוב הממשקים, הגדרת דרישות לתתי המערכת, השתתפות בקידוד התוכנה, בדיקות התוכנה ובדיקות ברמת מערכת.
הייתה זו הזדמנות מצוינת להוביל פרויקט תוכנה לאורך כל שלביו ולהיות חלק משמעותי בדרך ניהול הפיתוח.
מהניסיון שנלמד בפרויקט הזה ניסיתי לתמצת עשרה נושאים מן הבולטים ביותר בעשייה אליה השתייכנו בתקופה האחרונה:
1. הבנת צרכי הלקוח
חשוב להבין לעומק מהם הצרכים האמיתיים של הלקוח כפי שבאים לידי ביטוי בדרכים הבאות :
- שיחות פורמאליות עם נציגים בכיריo
- שיחות לא פורמאליות עם מפעילים / טכנאים / מהנדסיo
- סריקת מסמכי אפיון של פרויקטים שנעשו בעבר עבור הלקוח
2. מעורבות גדולה ככל האפשר של הלקוח בכל שלבי הפיתוח
- הצגת תכניות האפיון של המערכת, שיתוף נציגים בדילמות לבנייה יעילה של ה-HMI
- מתן אפשרות ללקוח לבצע בדיקות כבר בעמדת הפיתוח לפני שלב הבדיקות הפורמליות על מנת שאפשר יהיה לתקן On the fly ליקויים שנוצרו בתרגום לא מתאים מהאפיון לקידוד/
- שילוב נציגי הלקוח בבדיקות ההנדסיות – הלקוח משתמש במערכת בדרך ייחודית ורק כך ניתן לזהות ליקויים שנוצרו עקב חוסר ידע בתפעול יומיומי של המערכת. ללא מעורבות זו, יתגלו הליקויים בבדיקות הפורמאליות ויגררו פתיחה מיותרת של גרסאות התוכנה ועיכובים יקרים במסירת הפרויקט.
3. פיתוח סביב יישום אחד לניהול הפיתוח
לכל קבוצה ארגונית בפרויקט יש יישום חביב ומועדף לשימוש, אבל כאשר מנהלת הפרויקט מחליטה על יישום אחד ומחייבת את כל גורמי הפרויקט להשתמש אך ורק בו, נוצרת לאחר תקופה קצרה של למידה מערכת של ניהול מידע ארגוני הכולל :
- ניהול דרישות לקוח + ועדות שינויים
- ארגון דרישות מערכת ותת מערכת
- ריכוז דרישות תוכנה לפי תתי מערכות
- כיסוי בדיקתי מלא הכולל בדיקות פיתוח, בדיקות מערכת ובדיקות עצמאיות (IV&V)
4. הגדרה מדויקת ככל האפשר של חבילת הכיסוי הבדיקתי
חשוב מאוד להבין שלא ניתן לבדוק 100% של התכונות והמאפיינים של המוצר אותו אמור לספק הפרויקט. אי לכך, על
צוות הבודקים להגדיר את חבילת הבדיקות המקיפה ביותר האפשרית במסגרת הזמן שהוקצב לכך ואז לנתח ולתחם את
הכיסוי הבדיקתי עם רשימת נושאים שלא ייבדקו במסגרת חבילת הבדיקות המוצעת. כמובן שרשימה זו תידון במסגרת
הדיונים עם הלקוח.
5. שילוב סימולטורים לדימוי ממשקים לגילוי מוקדם של באגים בשלב הקידוד.
לא תמיד ניתן לבצע בדיקות באתר פרוש (צוואר בקבוק ידוע) ולא תמיד קיימת היכולת לבצע בדיקות מעמיקות באתר פרוש ולכן, שילוב סימולטור לבדיקות מפתח המדמה את הסביבה הממשקית עשוי לשפר משמעותית את הבשלות של התוכנה המיועדת לשילוב במערכת מרובת ממשקים
6. חשיבות אתר פרוש לגילוי מוקדם של תקלות עוד בשלב הפיתוח המוקדם
לאחר שהגדרנו את האתר הפרוש כאחד מצווארי הבקבוק בניהול הפרויקט, הגיע הזמן להבין את חשיבותו בביצוע בדיקות ברמת מערכת בנוסף ליכולות לבדיקות ייחודיות באמצעות מדמים, מכשירי מדידה, ותוכנות לניטור ואיסוף מידע.
7. ריכוז מאמץ בהגדרת בדיקות בשיטות מגוונות
היכולת החשובה ביותר של אתר פרוש היא לאפשר ביצוע בדיקות שליליות במתארים ובתרחישים מורכבים הניתנים לבדיקה רק ברמת מערכת ורק באתר פרוש מאובטח למניעת נזק לציוד. שימוש בציוד הקיים באתר עשוי לספק יכולות מגוונות לביצוע בדיקות כגון :
- דימוי תקלות בממשק (חיוט / מתחים / אותות)
- שיבוש / ניתוק תקשורת.
- הזרקת אותות בשלבי ריצה שונים.
- בדיקות HMI קפדניות
8. הקפאת דרישות כתנאי הכרחי לעמידה בלוחות זמנים\תכנון טוב של פרויקט מגדיר מועדים מדויקים להקפאת דרישות וכן תהליך התכנסות אל המועדים שהוגדרו. זהו אחד התהליכים היותר מורכבים ומאתגרים שיש בכל שלבי הפרויקט שכן, כל הצדדים ובכלל זה - מנהלת הפרויקט, הנדסת מערכת, תוכנה, כולם רוצים עוד זמן כדי להספיק כמה שיותר. להוסיף עוד דרישה חשובה שנכנסה ממש בסוף, להגדיר טוב יותר את דרישות תתי המערכת ולשפר ממש עוד קצת את רשימת הבדיקות. אבל אי הקפדה על עיקרון הקפאת הדרישות עלול לגרום למחול שדים של דחיות חוזרות ונשנות, לאי עמידה בלו"ז הפרויקט ולתשלום קנסות על פיגורים.
9. האויב של הטוב מאוד הוא המצוין
בדומה לצורך בהקפאת דרישות, ישנו זמן שבו יש להפסיק לפתח את המוצר, לעצור ולאפשר לצוות הבדיקות לבצע את חבילת הבדיקות במלואה מבלי להכניס עוד גרסה ועוד אחת. הצורך לתקן באג שהתגלה ממש בבדיקה האחרונה הוא כמעט בלתי נשלט אבל לעיתים תיקון של באג אחד עלול לגרום להוספת עשרה באגים חבויים שיתעוררו להם בדיוק בשלב הבדיקות הפורמאליות.
10. אווירת עבודה תקינה ותקשורת פתוחה כמפתח לפתרון יעיל של בעיות
זהו למעשה האלמנט הקשה ביותר לביצוע היות שמדובר בבני אדם, לעיתים עם אינטרסים שונים ודרכים שונות להגיע אל מטרה משותפת. ישנם מאבקי כח סמויים שנראים לכאורה ענייניים אבל תמיד תמיד הם אישיים. אז איך גורמים לתקשורתבריאה וחיובית? הנה דוגמה : צוות הבדיקות הוא זה שאמור להצביע על ליקויים ולדווח על כשלים בתכנון, במחשבה, בביצוע והדרך להציג ליקויים אלה היא חשובה ביותר. הדוגמה שאני לוקח היא מצוות הבדיקות שלנו שכמעט תמיד מציג ראשית את הדברים הטובים שבדק, נותן מילה טובה על הברקה בביצוע או על עיצוב משובח ורק לאחר מכן מאיר בלשון עניינית ומדויקת את הדרוש תיקון. כך קל יותר לקבל את הבאג האומלל ביותר שכולם זיהו אותו מיד חוץ ממך.
לסיכום:
פיתוח פרויקט תוכנה הינו תהליך מורכב ותובעני ולכן חשוב לנהוג בו בצורה מושכלת. העצות שהבאתי כאן, כולם פרי ניסיון והתבוננות על תהליך מיוחד שהייתה לי הזכות להיות חלק ממנו. יישומן עשוי לתרום לכל פרויקט להצליח ולהביא לסיומו בזמן שנקבע ובאווירה חיובית ותורמת.
