בעיות בתהליך פיתוח מערכת תוכנה ופתרונן 

תיאור הבעיה הקיימת

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

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

כאשר מנסים למצוא את הסיבות לבעיות אלה נתקלים בעובדות הבאות:

1. בפרויקטים הללו יש כמות מלל אין סופית במסמכי הפיתוח.
מה נגרם כתוצאה מכך?

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

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

2.      בעיה של עקיבות (עקיבות= היכולת לוודא שכל שלב בתהליך מכסה את הדרישות של השלב הקודם)

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

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

ג. גם אם מיידעים אותנו על שינוי בדרישות - יש לנסות ולנחש היכן אותו שינוי משפיע במערכת.

ד. פיתוח מערכת הוא עניין דינאמי - יש שינויים כל הזמן באפיונים.

3.      מה קורה כאשר מגלים תקלה במערכת (במסגרת בדיקות)?

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

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

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

1.מתודולוגיה מערכתית שאינה עושה שימוש במסמכי Word לניהול הפיתוח, אלא במודלים ויזואליים

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

3. מהו מודל? מודל הוא שילוב של מידע ויזואלי-ציורי ומידע טסקטואלי המשלים את המידע הויזואלי.

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

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

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

מודל 1- מודל דרישות מערכת

מודל זה נבנה ע"י מהנדס/ מאפיין המערכת ומאפשר את התנעת הפרויקט. מודל זה מכיל את כלל דרישות המערכת (דרישות פונקציונאליות, דרישות לא-פונקציונאליות).

מודל 2 - מודל תהליכים הנדסיים ותפעוליים

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

מודל 3- מודל יכולות תוכנה

כל ר"צ תוכנה מקבל נתח מתוך דרישות המערכת שעליו לממש. מודל זה משמש לפירוט נוסף (טכני יותר) של דרישות המערכת כפי שהועברו ממהנדס המערכת.

מודל 4- מודל עיצוב תוכנה

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

מודל 5- מודל בדיקות

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

מודל 6 - מודל תחזוקה

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

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