מדריך זה סוקר שיטות פיתוח, מתודולוגיות ומחזורי חיים דינמיים לניהול פרויקטי תוכנה. המדריך מציג את התפיסה של מפת"ח בכל הקשור לשיטות ניהול פרויקט מודרניות המתבססות על שימוש במחזורי חיים דינמיים, שיטות וטכניקות פיתוח מגוונות לפי הנדרש בכל פרויקט.
מרכיב מרכזי ביותר בניהול פרויקטי תוכנה (כמו גם פרויקטים בתחומים אחרים) הוא הגדרה מסודרת של מחזור חיי הפרויקט. פרויקט הוא שרשרת של צעדים (שלבים) שתחילתה בייזום וסופה בהתקנה ומסירה ללקוח. באמצע מצויים: אפיון מסודר, פנייה לספקים (אופציונאלי), עיצוב, בנייה, טסטים וכו'. שרשרת זו מכונה מחזור חיי הפרויקט או בקיצור מחזור חיים ובאנגלית, SLC או SDLC שפירושו System [Development] Life Cycle. כל מתודולוגיה מכובדת לניהול פרויקט מציגה את מחזור החיים שלה, אך אם נתעלם מהבדלי מנוחים וטרמינולוגיה, כולם מדברים, פחות או יותר, על אותו מחזור חיים, או לפחות על אותם מרכיבים בסיסיים שלו.
במשך שנים שלטה בכיפה השיטה הסדרתית. לפי שיטה זו שלבי מחזור החיים מתבצעים באופן רציף ועוקב אחד אחרי השני. בעיקרון, כל פתיחה של שלב חדש בפרויקט מותנית בסגירה מסודרת של השלב הקודם, כולל כל האישורים המקצועיים והניהוליים. מאז עלתה על הבימה בשנות השמונים של המאה העשרים, שוכללה שיטה זו בהדרגה ונוספו לה מרכיבים חשובים כמו התייחסות מתודית לשלב התפעול והתחזוקה (שלב מוזנח בדרך כלל), טיפול בצורך בהרחבות ופיתוחים נוספים (מהדורות חדשות), הבחנה בין סוגי מערכות וגדלי פרויקטים ועוד. אך ביסודה, נשארה השיטה הסדרתית, או כפי שהיא גם מכונה לפעמים: מודל "מפל המים", בצורתה הבסיסית.
ענף טכנולוגיית המידע עבר, כידוע, פיתוח מואץ ושינויים מפליגים, בשנים האחרונות. זאת, הן בשל התפתחויות טכנולוגיות פנימיות מרשימות בכל שלושת היסודות המרכזיים שלו חומרה, תוכנה ותקשורת, והן בשל התפתחויות עסקיות חיצוניות, היינו דרישות הולכות וגוברות של הלקוחות לספק מערכות מידע בקצב מהיר ומשתנה ללא הרף. שם המשחק, בשני המישורים, הוא Time to market. לאור זאת, ברור שמחזור חיים סדרתי, עם כל יתרונותיו הברורים והשכלולים שעבר במרוצת הזמן, אינו מספק ויש צורך לעבור לשיטות מתקדמות יותר.
בשנות התשעים החלה להופיע שיטת הפיתוח בסבבים, או בשמה האחר, השיטה המדורגת (Iterative/Incremental Development). המייצג המרכזי של שיטה זו הוא המודל הספירלי של פרופסור Boehm. לפי שיטה זו, פיתוח המערכת מבוצע בסבבים הולכים ומתרחבים דמויי ספירלה. בכל סבב עוברת המערכת שלב נוסף של פיתוח, אשר נחלק לארבע מקטעים (תת-סבבים) ברורים: תכנון, חקר ישימות, בנייה ובחינה והערכה. למרות ששיטה זו הוצגה, משך תקופה לא קצרה, כאנטיתזה לשיטה הסדרתית, מתברר היום שיש בין שתי השיטות יותר השלמה מאשר ניגוד או עימות. השיטה הספירלית מתמקדת ב"ליבה" של מחזור החיים, בחלק בו המערכת מאופיינת לפרטים, מעוצבת, נבנית, משולבת ונבדקת בהדרגה. השיטה הסדרתית "עוטפת" את השיטה הספירלית ומגדירה את מכלול הפעולות שיש לבצע לפני ואחרי הליבה שהן מטבען פעילויות סדרתיות.
אך אין זה הכל. במקביל לשיטה הסדרתית והספירלית, הלכה והתפתחה מעין שיטה שלישית של פיתוח מרובה יחידות מסירה. הדגש כאן הוא על חלוקת המערכת לתת-מערכות וכתוצאה מכך חלוקת הפרויקט לתת-פרויקטים. שיטה זו מבוססת על הרעיון המקובל בכלל התעשייה של בניית מוצר במהדורות שונות. שיטה זו התפתחה "מלמטה למעלה", יותר בפרקטיקה ופחות באקדמיה, כתוצאה מצורך ברור של השטח לספק פתרונות מהירים ולהיענות לשינויים ודרישות חדשים לבקרים. מה שתרם לשיטה זו, בין השאר, הוא מעורבות גוברת והולכת של הדרג הבכיר בנושאי המחשוב בארגון, עבודה משותפת וצמודה של מומחי המחשוב עם נציגות הלקוח וצוותי משתמשים (תוך שימוש בטכניקות שונות כגון JAD, Groupwareועוד) ומוכנות הלקוח לקבל פתרונות בשלבים.
שלוש השיטות, הסדרתית, הספירלית ופיתוח מרובה יחידות מסירה הן חלופיות אך לא סותרות. יש ביניהן השלמה ברורה ואנו זקוקים לשלושתן. שיטות אלה מעמידות בפני מנהל הפרויקט מגוון אפשרויות הן ברמה הניהולית (ניהול הפרויקט) והן ברמה ההנדסית\טכנית (ניתוח המערכת והנדסת תוכנה). כמנהל, הוא צריך לבחון ולהחליט באיזו שיטת ניהול הוא בוחר: יחידת מסירה אחת או ריבוי יחידות מסירה. או שמא מדובר בכלל בפרויקט של הוספת יחידת מסירה למערכת קיימת. ואולי מדובר במקרי קצה מיוחדים כמו פרויקטים גדולים מאד מצד אחד או ההפך, פרויקטים קטנים מאד וקצרי מועד באופן בולט. כאיש מקצוע, הוא צריך לבחור את שיטת הפיתוח המתאימה: הסדרתית או הספירלית. את זאת הוא יעשה יחד עם אנשי המקצוע הבכירים בפרויקט, בהתאמה לשיטת הניהול שנבחרה.
מתודולוגיה זריזה (באנגלית Agile) לפיתוח תוכנה היא מתודולוגיה איטרטיבית שהותאמה לפיתוח תוכנה בצוותים קטנים תוך שימת דגש על יעילות, זריזות ואיכות. בשיטה זו שינויים במפרטי התוכנה הם מקובלים, וההתייחסות לפיתוח היא כאל משחק של שיתוף פעולה מוכוון-מטרה. המתודולוגיות במשפחה זו שמות דגש רב על סביבת עבודה מתאימה, זרימת מידע אוסמוטית בין חברי הצוות, ותקורה פורמלית־טקסית נמוכה. עקרונות היסוד של משפחה זו נקבעו במשותף על ידי רבים מהמובילים בחקר וביישום מערכות תוכנה, ופורסמו ברבים במנשר לפיתוח תוכנה זריז (Agile Manifesto).
ראה קיט פיתוח זריז Agile בכרך ניהול/ניהול פרויקט
השיטה הקלאסית לפיתוח מערכות ממוחשבות (ופרויקטים בתחומים אחרים) התבססה על מודל רציף לפיו מבוצעים שלבי מחזור החיים באופן סדרתי אחד אחרי השני. בעיקרון, כל פתיחה של שלב חדש בפרויקט מותנית ב"סגירה מסודרת" של השלב הקודם, כולל כל האישורים המקצועיים והניהוליים. איור 1 מציג את מחזור החיים הסדרתי כפי שהוא מוגדר בנוהל מפת"ח (בנהלים ומתודולוגיות אחרים יש שוני בצורת ההצגה ובשמות השלבים, אבל בעקרון זה אותו מודל).
.jpg)
מודל זה נקרא גם מפל המים (Waterfall) משום שנהוג היה לצייר את שלבי מחזור החיים משמאל לימין כמדרגות יורדות.
איור 2: מודל מפל המים
.jpg)
הוא נקרא לעתים גם מודל ה- V. מחזור החיים חולק בגדול לשניים כאשר ה"אמצע", שלב הקידוד הוא הבסיס הצר של האות V. הצלע השמאלית היורדת משמאל לימין מכילה את כל הפעולות מהייזום עד לקידוד. הכיוון הכללי שלה הוא מהכלל אל הפרט - פירוק המערכת וירידה לפרטים. הצלע הימנית, לעומת זאת, העולה משמאל לימין מכילה את כל הפעולות מהקידוד עד לתפעול ותחזוקה, בראשן בדיקות ושילוב הדרגתי של המערכת, והכיוון שלה הוא מהפרט אל הכלל. אם לוקחים בחשבון גם פיתוח מוקדם של אבטיפוס (דגם וכו') שיש לו פירוק ושילוב משלו, אז אפשר גם לדבר על מודל ה- W. ה-"V" השמאלי (הקטן) הוא מיני פרויקט של פיתוח האבטיפוס ואילו ה-"V" השמאלי (הגדול) הוא הפרויקט הראשי.
לשיטה הסדרתית יש יתרונות ברורים של מבניות, סדר ויכולת שליטה ובקרה על הפרויקט, אבל גם חסרונות בולטים, בפרט בעולם העסקי הדינמי של ימינו בו שם המשחק הוא Time to market והדבר הוודאי ביותר שניתן לומר הוא שאנו חיים בעולם משתנה ובלתי ודאי. אך לפני שנעבור לשיטות ומחזורי חיים דינמיים ומתקדמים יותר, כדאי לזכור שהמודל הסדרתי (אשר בדרך כלל "מושמץ" כשיטה ארכאית) התפתח גם הוא בשנים האחרונות. כבר מזמן לא מדובר באותו מודל ראשוני של שנות השבעים והשמונים. השינויים העיקריים שעבר המודל הסדרתי ואשר תרמו רבות ליכולתו לשרוד עד ימינו (וגם כנראה בעתיד), מוצגים בקצרה להלן.
בעולם התוכנה יש משמעות עצומה לגודל (היקף) המערכת. אינה דומה מערכת "פרטית" המפותחת עבור משתמש בודד במחולל יישומים פשוט או אולי אפילו גיליון אלקטרוני וצפוי להשקיע בה עד חודשיים עבודה, למערכת משאבי אנוש ושכר (רק כדוגמה) של מפעל המעסיק אלפי עובדים שההשקעה בה מוערכת במאות שנות אדם. אבחנה זו בין גדלי מערכת (אשר מקובלת מאד במפת"ח) משמשת בסיס לקיצורי דרך הן במחזור החיים והן בתוצרים הנדרשים במהלך פיתוח המערכת. במערכות קטנות ניתן לאחד למשל את שלב הייזום עם שלב האפיון, ניתן להבנות את שלב הבדיקות בתוך שלב עיצוב ובנייה ועוד. במערכות גדולות, מן העבר השני, מחולקת המערכת לתת מערכות ברורות שכל אחת מהן מתנהלת לפי מחזור חיים משלה, תוך דגש על ממשקים ותיאום אבני דרך בתהליכי הפיתוח של תת המערכות השונות. שכלול ראשון של המודל הסדרתי הוא אפוא התאמה לגודל (היקף) המערכת.
בעיה מרכזית ברעיון של הבחנה בין היקפי מערכות שונים היא המימוש, היינו, מציאת הגדרה אובייקטיבית ומוסכמת של פרמטרים מעשיים ומדידים הקובעים את גדלי המערכת השונות. זו אולי הסיבה שבתקן ISO9000 אין הבחנה כזו ודרישותיו מפרויקט קטן, בינוני וגדול הן אחידות. באופן מעשי, עם כל הקושי שבדבר, ארגונים מוצאים את ההגדרות וההבחנות המתאימות ויודעים שבעולם התוכנה, בניגוד לעולם החוק והמשפט למשל, "אין דין פרוטה כדין מעה". ראה ההגדרות והפרמטרים שנוהל מפת"ח מציע בנושא זה (לאורך כל הקיטים של מחזור החיים ובקיט מדדים שבכרך איכות). באופן מעשי אגב, בודקים ומסמיכים מנוסים של תקן ISO9000 יודעים לעשות את ההבדל.
במודל הסדרתי המקורי לא הייתה התייחסות רצינית לשלב התחזוקה. ההנחה (התמימה) הייתה שאם רק נבנה את המערכת "כמו שצריך", שלב התחזוקה יהיה פשוט וקל יותר. כל הדרישות או לפחות רובן הוגדרו בשלב האפיון ויושמו במערכת בשלב העיצוב והבנייה. במודלים מאוחרים יותר (דוגמת מפת"ח), התווסף שלב התחזוקה למחזור החיים כבן חוקי ומלא, כולל טכניקות חשובות לניהול שינויים ובקרת תצורה (Configuration & change management). אבן הנגף העיקרית היא ההפרדה בין תיקוני שגיאות ובין שינויים ושיפורים. הדבר דורש קשר רצוף והדוק עם הלקוח ומשמעת ניהולית ומקצועית גבוהה, אבל הוא אפשרי. אם נדקדק בדבר, נראה ששלב התחזוקה נחלק לארבעה:
· טיפול בתקלות (באגים),
· שו"ש (שינויים ושיפורים),
· שדרוגים,
· מניעה (תחזוקה מונעת).
מה שחשוב לענייננו הוא ההבחנה בין פעילויות שאכן מקומן הטבעי הוא בתחזוקה (תקלות ומניעה) ובין אלה שמקומן בהמשך הפיתוח (שו"ש ושדרוגים).
יש כאן מעגל קסמים שצריך לפרוץ אותו. אם הלקוח רואה שבמקביל לצוות התחזוקה, צוות הפיתוח ממשיך לתפקד ובנוי להכניס את כל השו"ש בצורה מסודרת ע"י מהדורות חדשות עם לוחות זמנים ברורים – הוא יקנה את זה ואפילו יהיה מליץ יושר ויסייע בכך. שכלול זה של שלב התחזוקה הוא בסיס לתורה המתקדמת המוצגת להלן של פתוח ביחידות מסירה.
שכלול נוסף הוא שלב הערכת המערכת (System Assessment) - ראה איור 1 - שמטרתו לאתר תקלות ובעיות, כמו גם נקודות חיוביות, אשר אירעו במהלך פיתוח המערכת, כולל התקנתה והעברתה לייצור שוטף ותחזוקה, על מנת להפיק מסקנות ולקחים, הן לפרויקט עצמו והן לפרויקטים אחרים בארגון בהווה ובעתיד. בדומה לתחזוקה, גם שלב מאוחר זה תרם להבנתנו שהפיתוח לא מסתיים בקו סדרתי רציף ושהפרויקט מבוסס על סבבי פיתוח.
הרעיון הבסיסי כאן הוא להתמקד במערכות בעלות אופי מיוחד המיועדות למגזר עסקי מסוים ולעתים מושתתות גם על טכנולוגיה או מתודולוגיה מיוחדים. הכוונה למערכות כגון: לוגיסטיקה וכספים כולל מערכות ERP, מחסן נתונים ומידע למנהלים (Business Intelligence), מערכות מידע גיאוגרפי (GIS), מערכות ארכיב (Optical Archiving), מערכות שליטה ובקרה (CCC) וכו'. רעיון זה זכה בשעתו לכינוי Vertical Software Engineering משום שיש כאן מיקוד של תורת הנדסת תוכנה הכללית בסקטור עסקי אנכי. ברגע שהמודל הכללי של פיתוח המערכת מותאם לסוג המערכת, הוא נעשה פשוט וברור יותר וכתוצאה מכך גם דינמי וגמיש יותר. הפשטות והגמישות נובעות משימוש במינוח, נורמות של הענף ותקנים (חוסך אפיון), משימוש בחבילות תוכנה מוכנות (חוסך עיצוב ובנייה) ועוד. נושא מערכות מתמחות היה ונשאר נכון גם בימינו ואין ספק שהוא אבן בנין יסודית של כל שיטה וכל מתודולוגיה גם בעתיד.
נוהל מפת"ח פותח בראשית שנות התשעים בשיתוף עם ממשלת ישראל, משרד האוצר. מחזור החיים של מפת"ח מבוסס על השיטה הסדרתית, יחד עם כל השכלולים שהוצגו לעיל:
· הבחנה ברורה בין גדלי מערכת שונים,
· דגש על שלב התחזוקה כולל ההפרדה בין תקלות ושו"ש,
· הוספת שלב הערכת מערכת
· דגש על מערכות מתמחות (הנדסת תוכנה אנכית).
בנוסף, הביא אתו נוהל מפת"ח חידוש מרכזי בדמות מושג עץ המערכת ומודל המטריצה, אשר מכתיבים אחידות מלאה של כל התוצרים לאורך מחזור החיים של הפרויקט. למעשה מדובר בתוצר מרכזי אחד מתגלגל. אחידות זו מאפשרת, מעצם טבעה, קיצורי דרך רבים וגורמת לכך שגם כאשר סוטים ממחזור החיים הסדרתי ועובדים במודל סבבים זה או אחר, תמיד אפשר "למצוא את הידיים ואת הרגלים". בכל נקודת זמן ובכל מצב, ניתן לוודא מה תכולת עץ המערכת נכון לרגע זה, מהו קו ההתחלה ()Baseline של המערכת ומהו הקו המנחה (Guideline) של הפרויקט.
שני האיורים הבאים, איור 3 ואיור 4 מציגים את מודל מפת"ח. האחד מנקודת הזווית של עץ המערכת, כיצד הוא מתגלגל לאורך חיי הפרויקט והשני מנקודת הזווית של מחזור החיים (עץ הפרויקט), כיצד הוא מתגלגל משלב לשלב.
איור 3: מודל מפת"ח – גישת המטריצה, סרגל אחד לאורך מחזור החיים
.jpg)
הציר הדומיננטי באיור 3 הוא עץ המערכת. הזרימה היא משמאל לימין. החצים האופקיים (הכהים) היוצאים מציר עץ המערכת שמאלה, מציגים את אופן התקדמות תכני המערכת לאורך מחזור החיים. החצים האנכיים (הלבנים) היוצאים מציר מחזור החיים כלפי מעלה, מציינים את נקודות הבקרה ואבני הדרך של הפרויקט.
באיור 3, לעומת זאת, הציר הדומיננטי הוא מחזור החיים. כיצד מתגלגל הפרויקט משלב לשלב, כולל סבבים וחזרות למיניהם. בצד שמאל של האיור, ניתנת לנו תזכורת של עץ המערכת המלווה את הפרויקט לכל אורכו. איור 3 הוא הרחבה ברורה של איור 1 לעיל.
איור 4: מודל מפת"ח – פיתוח בסבבים מלווה בסרגל תוצרים אחד לאורך מחזור החיים
.jpg)
איורים 2 ו- 3 מדגישים שני שכלולים חשובים ביותר שהם תרומת מפת"ח:
מודל המטריצה, שפירושו סרגל תוצרים אחד לאורך כל מחזור החיים.
אפשרות לחזרות וסבבים. סבבים אלה הם משלושה סוגים:
· בתוך השלב - טיוטות, דגמים, סבבי פיתוח ובדיקות, התקנות וכו', בהתאם לשלב.
· בין השלבים - התורה הסדרתית מרשה, בעיקרון, חזרה לשלב הקודם בלבד. חזרה מעבר לכך, היינו שני שלבים ומעלה, מחייבת אישורים מיוחדים ונחשבת, בתפישה הסדרתית, לפתיחת הפרויקט או לפרויקט חדש. בפועל, כל פרויקט ינהג, כמובן, בהתאם למדיניות הארגון והנחיות ועדת ההיגוי שלו.
· מהדורות נוספות - חזרה על מחזור החיים כולו או רובו לצורך הוצאת מהדורה או גרסא חדשה. מקור מרכזי להגדרת מהדורות וגרסאות חדשות הוא שלב התחזוקה, בו חייבת להתבצע הפרדה בין תיקוני באגים ותקלות (ושינויים באמת קלים ופשוטים) ובין שו"ש שמקומם בתהליך פיתוח מסודר של מהדורה חדשה.
הנה כי כן, השיטה הסדרתית איננה כל כך רדודה ומיושנת כפי שמקובל לחשוב. היא התפתחה באופן משמעותי בשנים האחרונות וכבר מזמן איננה השיטה הישנה של "מודל מפל המים" משנות השמונים. עם זאת, גם אחרי כל השכלולים האלה, ברור ששיטה זו איננה מספקת ועל מנת לענות על הדרישות לפיתוח מערכות ממוחשבות בעידן העסקי והטכנולוגי של ימינו, יש צורך בשילוב שיטות חדישות ומודלים מתקדמים יותר.
בשנות התשעים החלה להופיע השיטה הספירלית שאביה ומחוללה הוא פרופסור Boehm. שיטה זו מוצגת באיור 5:
איור 5: השיטה הספירלית
.jpg)
בכל סבב עוברת המערכת שלב נוסף של פיתוח. כל סבב נחלק לארבעה חלקים (תת-סבבים) שהם:
· תכנון (הסבב),
· ניתוח חלופות והערכת סיכונים (בדיקת ישימות),
· אפיון-מפורט-עיצוב-בנייה
· בחינה והערכה של תוצאות הסבב כולל החלטה לגבי סבב נוסף.
מודלים מתקדמים יותר של השיטה הספירלית מדברים על חלוקה לשישה מקטעים, כדלהלן:
· תקשורת עם הלקוח,
· תכנון,
· חקר ישימות,
· הנדסה,
· בנייה
· מהדורות והערכה.
מדובר בסבב פיתוח פנימי בו מופק דגם נוסף של המערכת ולא בסבב שנגמר במסירת תוצר (יחידת מסירה) ללקוח. הצידוק המרכזי לשיטה זו הוא פיתוח בתנאי אי ודאות בהם לא ניתן לאפיין את המערכת לפרטיה מראש. הדרישות הפונקציונליות, הטכנולוגיה הנדרשת וישימות המערכת בכללותה, הולכים ומתבהרים תוך כדי ביצוע הסבבים והעמדת הדגמים לבחינה והערכה.
המודל הספירלי מתמקד בליבּה של תהליך הפיתוח, היינו באפיון המפורט, העיצוב והבנייה. ומטבע הדברים גם בכל הבדיקות שניתן לבצע בתוך כל סבב, היינו בעיקר בדיקות יחידה (Unit tests). ראה תת הסבב הרביעי (האחרון) הנקרא "בחינה והערכה". ברור שליבה זו איננה כל הפרויקט. לפניה ולאחריה יש פעולות חשובות שבלעדיהן אין פרויקט. לפניה, כל הפעולות שנעשות עוד לפני הכניסה לסבב הראשון: ייזום הפרויקט, אפיון ראשוני, מכרז (אם הוחלט על פיתוח חיצוני) ופעילויות התארגנות נוספות. ולאחריה, כל הפעולות שנעשות לאחר סיום סבב הפיתוח האחרון, כחלק מהשלמת המערכת ומסירתה ללקוח: בדיקות מערכת מלאות, התקנה והרצה (כולל בדיקות מוכנות) וכו'. במילים אחרות, את המודל הספירלי יש "לעטוף" במחזור חיים כולל יותר, כמוצג באיור 6.
איור 6: שילוב המודל הספירלי במחזור החיים הכולל של הפרויקט
.jpg)
שילוב המודל הספירלי במחזור החיים הכולל של הפרויקט יוצר חלוקת-על של מחזור החיים של הפרויקט לשלושה שלבים מרכזיים:
· שלב התכנון
· שלב הפיתוח
· שלב האינטגרציה וההשמה
שלב התכנון
כולל את ייזום הפרויקט, אפיון כללי (אפיון על) ובקשה להצעות (אם מבקשים פתרון חיצוני). החידוש העיקרי כאן, מול המודל הסדרתי, הוא תת השלב המכונה "אפיון על". יש להגדיר היטב תת שלב זה ולהנחות את צוות האפיון מה בדיוק נדרש, לא פחות מדי ולא יותר מדי.
שלב הפיתוח
כולל את האפיון המפורט, העיצוב (הכולל והמפורט), הבנייה ובדיקות יחידה ושילוב, כפי שכבר הוצג באיור 5 לעיל. התוספת של איור 6 לעומת איור 5 היא הדגש על שימוש מוגבר בסקרים (reviews) ותיאום בין צוותים העובדים במקביל.
שלב האינטגרציה וההשמה
בשלב זה מבוצעות בדיקות מערכת כוללות, השלמות ופעילויות נוספות הקשורות בהעברת המערכת לתפעול ותחזוקה שוטפים בדומה למודל הסדרתי לעיל.
שילוב זה של המודל הספירלי עם המודל הסדרתי, מוכיח שוב עד כמה העולם הטכנולוגי בכלל, וטכנולוגיית המידע בפרט, מתפתחים בסופו של דבר בשיטת האבולוציה ולא בשיטת המהפכות. המודל הספירלי אשר הוצג משך תקופה לא קצרה כמהפכה לעומת המודל הסדרתי וכמנוגד לו בתכלית, משתלב היטב עם המודל הסדרתי ויוצר, יחד אתו, מודל משולב מעניין.
כבר בסקירת המודל הסדרתי לעיל, ראינו את החשיבות העצומה של ניהול נכון של שלב התחזוקה ע"י הפרדה בין תיקוני שגיאות ובין שו"ש, בין תיקונים שיש להכניס כחלק משלב התחזוקה ובין שיפורים שאפשר וצריך לרכז ולבצע אותם כהמשך פיתוח המערכת. כל מי שהיה מעורב בניהול פרויקט לאורך תקופה ארוכה, בפרט ניהול פיתוח של מוצר לשוק המסחרי, התנסה מקרוב ברעיון של מהדורות ויחידות מסירה ומכיר היטב את המשמעות ההנדסית, הניהולית והעסקית של פיתוח פרויקט בשלבים. שיטת ניהול הפיתוח במספר יחידות מסירה (MDU - Multiple Delivery Units) מוצגת באיור הבא:
איור 7: פיתוח מערכת במספר יחידות מסירה
מה שבוצע בעבר בדיעבד ונבע משלב התחזוקה, נעשה כעת מלכתחילה כחלק בלתי נפרד משלב הפיתוח. איור 7 ממחיש מספר נקודות חשובות במודל ה- MDU.
· חשיבות יחידת המסירה הראשונה - הקמת המערכת. יחידה זו חייבת להניח את התשתיות לשאר יחידות המסירה וגם לספק תכנים ופונקציונליות ראשונים אשר יצדיקו את ההשקעה הראשונית וייצרו גירוי מספיק להמשך פיתוח המערכת בדמות יחידות מסירה נוספות.
· ניהול התחזוקה במקביל להמשך הפיתוח. זה המחיר העיקרי של שיטת ה- MDU. יש לתאם באופן שוטף בין צוותי התחזוקה והפיתוח ולמנוע כפילויות וחורים. זאת ועוד, מהקוביה "תפעול ותחזוקה" יוצאים כעת שלושה חצים! יש לנתב לא רק בין תיקוני באגים והמשך פיתוח (שו"ש), אלא גם לשקול מתי מגיע צורך בשכתוב (Reengineering) של המערכת.
· ניהול שלב הבקשה להצעות. בקשה להצעות במודל זה שונה מבקשה להצעות מסורתית של בניית מערכת בשיטת מחיר קבוע (fixed price או Turnkey). הבקשה צריכה להיות כוללת עם צפייה מרבית קדימה, אך עם אפשרויות מימוש והתקשרויות נפרדות לכל יחידת מסירה. ההתקשרות במחיר קבוע יכולה להיות עבור יחידת המסירה הראשונה והשנייה, לכל היותר. נושא זה עשוי לחייב התאמות מיוחדות ושינוי דפוסי עבודה ונהלים מקובלים בארגון. כיצד לכתוב מפרט מסוג זה? כיצד לבחון ולדרג את ההצעות? איך תבוצענה ההתקשרויות? מה קורה אם רוצים להחליף את הספק בין יחידת מסירה אחת לאחרת? ועוד. יש פה הקבלה מעניינת עם נושא מיקור חוץ (Outsourcing).
איור 7, עם כל פשטותו, הוא פריצת דרך. אם אפשר להגיע להסכמה בין כל המעורבים בפרויקט, לא רק אנשי המקצוע והלקוח אלא גם אנשי מנהלה, יעוץ משפטי תקציבים וכו', על פיתוח בשיטה זו, לאורך זמן, זהו הישג לא מבוטל. זאת ועוד, היום אנו מבינים שחלק ניכר מהביקורת על המודל הסדרתי, כפי שהוא מוצג באיור 1 למשל, היה בעצם ביקורת על שיטת הפיתוח של יחידת מסירה אחת. גם השכלול המוצג באיור 4 אינו פותר את הבעיה, שכן עדיין הגישה "לכתחילה" היא של יחידת מסירה (מערכת) אחת.
האם כל זה אומר ששיטת הפיתוח ביחידת מסירה אחת נעלמה? לא ולא. פיתוח ביחידת מסירה אחת (SDU – Single Delivery Unit) הוא מקרה פרטי של פיתוח במספר יחידות מסירה (MDU). מגוון רחב של פרויקטים, בפרט פרויקטים קטנים ואפילו בינוניים, יכול וצריך עדיין להתנהל כיחידת מסירה אחת. מה גם שניתן לשלב בשיטה זו את המודל הספירלי כמוצג באיור 6 לעיל.
איור 8 מציג מודל השוואתי של לוחות זמנים לפיתוח מערכת, בין השיטה של יחידת מסירה אחת (SDU) ובין זו של מספר יחידות מסירה (MDU).
איור 8: השוואה בין פיתוח מרובה יחידות מסירה ובין פיתוח עם יחידת מסירה אחת
ממודל זה נראה שפיתוח המערכת בסבבים של 4 יחידות מסירה יימשך 17 יחידות זמן, לעומת 12 יחידות זמן בפיתוח ברצף של יחידת מסירה אחת. יש כאן תוספת של 41% בלו"ז (וסביר שלפחות כך גם בעלויות!) אז איפה כאן הרווח?
יש שלוש תשובות לשאלה זו.
· הרווח הוא בכך ששתי יחידות מסירה ראשונות נמסרו מוקדם יותר. גם השלישית הגיעה פחות או יותר לאותו קו הגמר. הארגון קיבל כבר שני מוצרים בזמן שבשיטת ה- SDU היו רק מתחילים בבדיקות. יש כאן לא רק החזר השקעה מוקדם יותר, אלא גם הפקת לקחים ומשוב חיוניים מהשטח.
· נתמקד בהשוואה שבין סוף יחידת המסירה השלישית (13 יחידות זמן) מול סיום הפיתוח של יחידת מסירה אחת (12 יחידות זמן). לאחר יחידת המסירה השלישית המערכת כבר עברה מספר רב של שינויים לעומת האפיון הראשון, כך שזו כבר לא אותה המערכת עליה דובר בהתחלה. ההשוואה פשוט איננה תקפה.
· והתשובה השלישית: איור 8 צודק! לעתים אכן השיטה הסדרתית עדיפה!
בשנים האחרונות מוזכר יותר ויותר המונח פיתוח בסבבים, ID - Iterative Development, או בשמו האחר: פיתוח מדורג - Incremental Development. למה בדיוק הכוונה? יש שמבינים מונח זה כשם נרדף למודל הספירלי. אחרים מבינים אותו בהקשר עם מודל ה- MDU, היינו, פיתוח של מספר יחידות מסירה, ויש כאלה שמזהים אותו עם המונח RAD - Rapid Application Development, כשם כולל למכלול השיטות לפיתוח מהיר ומתקדם. אז כדאי שנעשה כאן קצת סדר.
ממה שראינו עד כה, עולה בברור שלפנינו שני סוגים של סבבים:
· סבב חיצוני שמתבטא במוצר או במערכת הנמסרים ללקוח. סבב זה הוא הבסיס לשיטה של פיתוח במספר יחידות מסירה שהוסבר בפרק הקודם.
· סבב פנימי שהוא הניהול הפנימי של פיתוח יחידת מסירה אחת (או המערכת כולה, במקרה של יחידת מסירה אחת). סבב מסוג זה הוא המודל הספירלי הנ"ל.
אין בהכרח קשר בין סבב חיצוני ובין סבב פנימי. פיתוח יחידת מסירה אחת יכול להיעשות בשיטה הסדרתית (איור 1) או בשיטה הספירלית (איור 6). כך גם עבור השיטה של ריבוי יחידות מסירה. כל ארבע האפשרויות קיימות כמוצג בטבלה הבאה:
|
|
|
מספר יחידות מסירה |
|
|
|
|
אחת – SDU |
רבות – MDU |
|
שיטת הפיתוח |
סדרתית |
V |
V |
|
ספירלית |
V |
V |
|
איור 9 מציג את הקוביה השמאלית התחתונה, היינו, את השילוב של פיתוח במספר יחידות מסירה יחד עם השיטה הספירלית.
איור 9: פיתוח מערכת במספר יחידות מסירה בשיטה הספירלית
איור 9 הוא שילוב והרחבה הן של איור 6 והן של איור 7 לעיל. תרומתו של איור 9 היא בהבלטת ההבדלים בין יחידת המסירה הראשונה והיחידות הבאות, כגון: בדיקות רגרסיה, אפיון כללי מול אפיון על ועוד. רבים וטובים רואים, בצדק מסוים, את המקרה הזה, כמקרה המעניין והמתקדם ביותר - המודל הספירלי בתוך פיתוח של מספר יחידות מסירה. מנגד, האפשרות המוצגת בקובייה הימנית העליונה: שיטת פיתוח סדרתית ביחידת מסירה אחת, נראית כשיטה המיושנת והארכאית ביותר (כבר ראינו בסעיף השיטה הסדרתית לעיל שמצב זה לא קיים למעשה). בכל מקרה, כל ארבעת הצירופים המוצגים בטבלה 1 מקובלים.
נסכם את המונחים העיקריים שהוזכרו עד כאן ושבשימוש כאשר מדובר במחזורי חיים דינמיים ונראה כיצד הם מוגדרים בנוהל מפת"ח.
ID - בשמו המלא Iterative/Incremental Development, מתייחס לסבב פנימי. זהו שם כללי לכל השיטות המתמקדות בסבבי פיתוח פנימיים. מקרה קונקרטי הוא המודל הספירלי.
RAD - הוא שם כללי למגוון רחב של שיטות לפיתוח מהיר של מערכת, לא מתודולוגיה מסוימת. לפי גישתנו, RAD פירושו Rapid Application Delivery כלומר מסירה מהירה של המערכת ללקוח, בדרך זו או אחרת. (בהתאם להגדרה זו, מדריך זה כולו עוסק ב- RAD). תחת מושג זה מקובל לכלול גם טכניקות מגוונות נוספות, חלקן מוזכרות בסעיף פיתוחים נוספים בהנדסת תוכנה, להלן בסוף המדריך.
את ארבע הקוביות של טבלה 1 נכנה פשוט:
· SDU/Serial
· SDU/Iterative (Spiral)
· MDU/Serial
· MDU/Iterative (Spiral)
אז מה היה לנו? מודל סדרתי, מודל ספירלי, פיתוח ביחידת מסירה אחת, פיתוח מרובה יחידות מסירה, פיתוח בסבבים, פיתוח מדורג וכו'. איור 10 מציג סיכום של המושגים והשיטות האלה.
איור 10: המודל המסכם, פיתוח בסבבים בגישת מפת"ח
איור 10 מציג את "מודל שלוש השכבות" של ניהול הפרויקט בגישת מפת"ח.
· הקומה הראשונה מכילה את אבני הבניין היסודיות, שלבי מחזור החיים,
· הקומה השנייה את שיטות הפיתוח שהן בעיקרן שתיים: הסדרתית והספירלית
· הקומה השלישית את השיטות לניהול הפרויקט.
זה המבט מלמטה למעלה. השימוש המעשי בתרשים הוא בכיוון ההפוך, מלמעלה למטה. מנהל הפרויקט צריך לבחור את שיטת הניהול שהוא מאמץ ואת שיטת פיתוח המתאימה לה, בהתאם לאופי וסוג הפרויקט שלפניו. שתי קומות עליונות אלה המייצגות את שיטת הניהול והפיתוח, מפעילות את שלבי מחזור החיים, את הקומה התחתונה, בדרך המתאימה להן.
המסר של מפת"ח הוא אפוא, לא עוד מחזור חיים אחד או שיטה אחת, אלא מגוון אפשרויות ושיטות הלקוחות הן מעולם הנדסת תוכנה וניתוח מערכות (הקומה הראשונה והשנייה) והן מעולם ניהול פרויקטים (הקומה העליונה).
מפת"ח מעמיד לפני מנהל הפרויקט את האפשרויות הבאות:
פיתוח כל הפרויקט כיחידת מסירה אחת. שיטה זו מתאימה לפרויקטים של עד שנה וחצי ושעלותם הכוללת היא עד 100,000$. (מדדים אלה הם המלצת מפת"ח ותואמים את ההגדרה של גודל ג1. כל ארגון יאמץ לו את ההגדרות הנראות לו). הפיתוח עצמו יכול להיות בסבבים (SDU/spiral) או בשיטה הסדרתית (SDU/serial).
פיתוח הפרויקט במספר יחידות מסירה. שיטה זו מתאימה לפרויקטים שנמשכים למעלה משנה וחצי, או שעלותם הכוללת היא מעל 100,000$, או פרויקטים שיש בהם רמת סיכון או אי ודאות מיוחדים, כגון: יישום חדש, שימוש בטכנולוגיה חדישה, קהל משתמשים בלתי מוכר וכו'. הפיתוח הפנימי, בכל יחידת מסירה יכול להיות בסבבים (MDU/spiral) או בשיטה הסדרתית (MDU/serial).
הוספת יחידת מסירה למערכת קיימת. תדירות הוספה כזו לא תעלה על אחת לרבעון. סביר שהפיתוח יהיה בשיטה הסדרתית (ADU/serial).
לשלוש אפשרויות בסיסיות אלה, מתווספות שיטות ניהול נוספות עבור מקרים מיוחדים. לכל אחת משיטות אלה קיים קיט מיוחד בנוהל מפת"ח אשר מנחה את המשתמש, כיצד בדיוק לנהל פרויקט מסוג זה.
· LSS – Large Scale Systems – טיפול בפרויקטים גדולים במיוחד (ראה קיט מערכות גדולות בכרך ניהול/ניהול הפרויקט).
· VSS- Very Small Systems – טיפול בפרויקטים קטנים במיוחד (ראה קיט מערכות קטנות בכרך ניהול/ניהול הפרויקט).
· חבילות תוכנה – ניהול פרויקט של התאמת תוכנה קיימת (ראה קיט חבילות תוכנה בכרך נושאים תומכים).
· מערכות מתמחות – ראה הסבר בסעיף השיטה הסדרתית לעיל (ראה הקיטים בכרך התמחויות/מערכות מידע).
הכול הולך וחוזר אל מנהל הפרויקט אשר היה ונשאר הדמות המרכזית. והשאלה הבלתי נמנעת היא: האם כעת משימתו קלה יותר או קשה יותר? התשובה היא, כצפוי, גם וגם. קלה יותר, משום שכעת עומד לפניו מגוון רחב של אפשרויות. אין הוא כבול למחזור חיים אחד קשיח בבחינת "כזה ראה וקדש". הוא יכול לבחור את מחזור החיים ואת שיטת הפיתוח המתאימים לו והוא יכול אפילו לתמרן ביניהם, לשנות את השיטה במהלך חיי הפרויקט ו"לקפוץ מעגלה לעגלה" תוך כדי תנועה. הקלה נוספת הייתה ונשארה שיטת מפת"ח, לפיה כל התיעוד הנדרש הוא תמיד לפי אותו סרגל! לא חשוב היכן אתה נמצא בדיוק במחזור החיים ומה השיטה המדויקת לפיה אתה מתנהל כרגע, עץ המערכת תמיד נשאר אותו אחד.
הקושי הוא כמובן בעצם הבחירה והתמרון. מנהל הפרויקט צריך להפנים את מגוון השיטות ומחזורי החיים האפשריים ולדעת לבחור נכון, עד כמה שאפשר, בהתחלת הפרויקט ולבצע שיפורים ושינויים בהמשך לפי הצורך. הוא יכול למשל, להתחיל את הפרויקט כסדרתי עם יחידת מסירה אחת (SDU\Serial), לשנות בהמשך לפיתוח של מספר יחידות מסירה עדיין בשיטה הסדרתית (MDU\Serial), או אפילו לעבור ישירות לשיטה הספירלית עם מספר יחידות מסירה (MDU\Spiral). ויש כמובן הרבה דוגמאות אחרות. מנהל הפרויקט חייב להכיר שיטות אלה ברמה שתאפשר לו להקרין מגוון זה ומשמעויותיו גם על הגורמים המנהלים (ועדת ההיגוי) מחד גיסא ועל צוותי הפיתוח ושאר העושים במלאכה מאידך גיסא. הוא זה שיוביל לא רק את ההחלטה המקורית באיזו שיטה לבחור, אלא גם כל שינוי שיידרש במהלך ניהול הפרויקט.
גישת המטריצה של מפת"ח, האומרת שלאורך כל הפרויקט יש עץ תוצרים מרכזי אחד, מקבלת כעת חיזוק נוסף. הראייה הדו-ממדית הפשטנית-מה שבאיור 3, מתחלפת בראייה המוצגת באיורים 3, 5, 6 ו- 8. דווקא במודלים דינמיים חשוב לשמור על עץ תוצרים אחד לאורך מחזור החיים – עץ המערכת!
מדריך זה התמקד במחזורי חיים ושיטות לפיתוח וניהול תוכנה אשר ביחד מגדירים את "מחזור החיים הכולל" של הפרויקט. אך אלה רק חלק מהכלים העומדים לרשות מנהל הפרויקט וצוותי הפיתוח. התורה הרחבה יותר של הנדסת תוכנה וניהול תוכנה כוללת מגוון רחב של טכניקות ושיטות אשר הלכו והתפתחו בשנים האחרונות. מגוון רחב זה כולל נושאים חשובים כמו:
· פיתוח בגישת האובייקטים (OO/UML)
· הגברת מעורבות המשתמש, כגון שיטת JAD (Joint Application Development)
· הנדסה מקבילית ועבודה בצוותים מקבילים בשיטת Extreme Programming; Scrum; Agile
· כלי CASE לסוגיהם השונים:
· כלים להגדרת דרישות ולביצוע אפיון ועיצוב המערכת
· כלים לניהול תצורה ומעקב שינויים
· אומדן עלויות, כלים לביצוע וניהול בדיקות ועוד.
· כלים מגוונים החל ממעבדי תמלילים וניהול מסמכים, דרך גיליונות אלקטרוניים וכלה בדואר אלקטרוני, שיתוף מידע, תקשורת, ייעול זמן, מעקב החלטות וכו'
· גם לרשת האינטרנט עצמה, למאגרי הידע הנפוצים בה ולרשתות האינטראנט הפנים-ארגוניות יש תרומה רבה.
כלים וטכניקות אלה משתלבים בכל אחת משיטות הניהול ומחזורי החיים שהוצגו לעיל ואין בעצם השימוש בהם משום הצבעה על שיטת ניהול זו או אחרת. השיטה הכללית נקבעת משיקולים עסקיים וניהוליים הקשורים במהות המערכת. זו מצידה, מכתיבה את השימוש במגוון הטכניקות והכלים להנדסת תוכנה באופן המתאים לה. האופן בו משתלבת גישת האובייקטים וכלי פיתוח התומכים בסטנדרט UML, יחד עם שיטת הפיתוח בסבבים וביחידות מסירה, הוא דוגמא אחת.