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

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

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

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

שלב הגדרת הדרישות

1. הגדרת הדרישות תתבצע על ידי צוות עובדים יחד עם לקוח הקצה (אשר גם הוא עשוי להיות מורכב ממספר אנשים) כאשר הצוות כולל מנתח מערכות ואת התוכניתן אשר יפתח (לפחות חלק מ) המערכת העתידית כמו גם אחראי אבטחת מידע בארגון (רצוי בעל ידע בפיתוח). צוות זה יוביל את הפרויקט ויהיה אחראי בכל שלבי הפרויקט על הגמשת התוצר הסופי והפיכתו לגנרי ככל הניתן תוך שמירה על עמידה ביעדי המערכת.
2. בשלב זה המטרה היא לאתר כמה שיותר דרישות ולזהות בהן את נקודות הגמישות הנחוצות. זהו הנושא הקריטי ביותר בשלב הזה. נקודות הגמישות הנחוצות שיאותרו בשלב זה יאפשרו תוכנית שהתאמתה לחיים בארגון תהיה קלה ככל הניתן. את נקודות הגמישות ניתן לאתר על ידי ערכים, תהליכים, חוקים ושינויים טכנולוגיים שאירעו בעבר. נקודות גמישות אלו יצויינו במסמך הדרישות.
3. בשלב זה יש לעודד את לקוח הקצה להגדיר את הדרישות ללא כל התחשבות בעלויות או באילוצים כלשהם. המוטו הוא שלתכניתן אין מנדט (למעט מקרים בודדים) לומר שלא ניתן לבצע משימה כלשהי. באופן כללי כל משימת פיתוח היא ברת ביצוע אלא שהיא (אולי) כרוכה בעלויות מסוימות שמהווים חסם לביצועה.
4. כבר בשלב מוקדם זה יש לזהות יחד עם לקוח הקצה את התקלות שעלולות להופיע במערכת העתידית, אם על ידי הפניה לתקלות שאירעו במערכת שאותה משדרגים (במידה ומדובר בשדרוג) ואם על ידי נסיון לנתח את התקלות שעשויות להופיע לפי דרישות הלקוח. תקלות פוטנציאליות אלו יצוינו במסמך הדרישות.
5. כבר בשלב זה יש לזהות יחד עם לקוח הקצה את סט הבדיקות שישמשו לביצוע בדיקות הקבלה של המוצר הסופי. הבדיקות צריכות להיות מנוסחות באופן מדיד, ברור, ישים, מתוזמן (הגדרת זמני תגובה לכל בדיקה) ומציאותי.

שלב חלוקה למודולים שירותיים

1. שלב זה יבוצע באופן סנכרוני לשאר השלבים (כלומר לא במקביל) ובו תוגדר המערכת כאוסף של שירותים בדגש על שירותים גנריים ככל הניתן תוך התעלמות מאופן מימושם (SOAP WS, JSON, COBRA וכו'). החשיבה לגבי השירות צריכה להיעשות במושגים עסקיים בלבד.
2. לאחר חלוקת המערכת לאוסף של שירותים תוגדר, בשיתוף הדוק של צוות הרשת בארגון עם צוות ההיגוי של הפרויקט מפת השירותים המרכיבים את המערכת אשר תכלול את מיקומם הפיזי ואת אופן מימושם בהתאם לצפי העסקי של הנתונים המועברים בשירותים השונים ובתדירות הפעלתם.
3. כל הפיתוחים בהמשך, ובכלל זה גם פיתוח האבטיפוס יבוצע לפי מיפוי שירותים זה.

שלב פיתוח POC (אבטיפוס)

1. במקרים של פרוייקט אשר לפי הערכת הצוות המפתח, בדגש על הערכתו של התוכניתן אשר ליווה את שלב הגדרת הדרישות, עולה על שני ימי עבודה לפיתוח המוצר, מומלץ לפתח אבטיפוס אשר ידגים חלק מיכולות המערכת. זאת במקביל להמשך האפיון המפורט על ידי צוות ההיגוי של הפרויקט (שתואר לעיל).
2. אבטיפוס כזה אסור שיהיה מפותח כ-Quick & Dirty שכן במקרים כאלו בדרך כלל קיימת נטייה לאמץ אותו כבסיס לשלב הבא בפרוייקט ובשל ליקויי אבטחת מידע הנוצרים בפיתוח Quick & Dirty כמו גם בעיות ביצועים, ובמיוחד ליקויי רישום פעילויות (הסבר בהמשך) המוצר העתידי המתבסס על האבטיפוס עשוי במרבית המקרים לסבול מאותם ליקויים.
3. פיתוח האבטיפוס יבוצע לפי עקרונות הפיתוח הרגילים המופיעים בהמשך, אלא שהוא יכיל רק חלק מהמרכיבים של הפתרון. במהלך הפיתוח, לאחר כל אבן דרך שהוגדרה בפרויקט, ייבחן האבטיפוס על ידי לקוח הקצה ומסמך הדרישות יותאם לשינויים הרגולטוריים, טכנולוגיים וארגוניים שאירעו מאז תחילת הפרויקט. כך למעשה תישמר מעורבותו הצמודה של לקוח הקצה בפיתוח והתוצר הסופי יותאם לדרישות הלקוח כל העת תוך כדי הפיתוח.
4. במידת הצורך יעודכן מיפוי המודולים השירותיים תוך כדי פיתוח האבטיפוס לפי ראות עיניו של צוות ההיגוי של הפרויקט. כמובן שבמקרה כזה תוגדר נקודת גמישות נוספת למוצר.

שלב האפיון המפורט

1. שלב זה יבוצע במקביל לפיתוח האבטיפוס ויוזן ויעודכן כל העת לפי הערות הצוות המוביל את הפרויקט ולפי הערותיו של הצוות המפתח את האבטיפוס.
2. האפיון המפורט יכלול את מיפוי המודולים השירותיים ויהווה הרחבה שלו ויכיל את הפירוט של הממשקים המקשרים את המודולים השירותיים הללו זה לזה (כשלב ראשון) ואת ההשלכות של פיתוח המודולים הללו מבחינת קישוריות למסד הנתונים ואת מודל הנתונים המפורט, Class diagram, היבטי UI, תהליכי עבודה מול המערכת, אבטחת מידע (אותנטיקציה ואותוריזציה יוגדרו כפועל יוצא של הדרישות (רק מי שהוגדר בדרישות שנחוץ לאפשר לו לבצע פעולה מסוימת במערכת אכן יוכל לבצע אותה), פירוט נקודות הגמישות הדרושות שאותרו עד כה בפרויקט, פירוט עלויות הפרויקט ואנשי הקשר בפרויקט.
3. בנוסף, האפיון יכלול הגדרת מבנה רישום פעילויות (פירוט מבנים טיפוסיים מומלצים בהמשך) וצמתי החלטה בהם חשוב לדאוג לרישום הפעילויות. (ראה הסבר נוסף  כאן)
4. במהלך האפיון יש לשים לב במיוחד לאפיון טכניקת הגיבוי במקרים שמדובר על סביבה וירטואלית. (ראה הסבר נוסף  כאן)
5. אבטחת המידע צריכה להיות מוגדרת כפועל יוצא של דרישות הלקוח ולא כנושא טכנולוגי בלבד. (ראה הסבר נוסף כאן)

שלב הפיתוח

1. שלב זה יבוצע במקביל לשלב פיתוח האבטיפוס ולשלב האפיון המפורט כך שכל מודול שעבר אפיון מפורט יתחיל להיות מפותח תוך כדי ביצוע אפיון מפורט לשאר המודולים.
2. בשלב זה חשוב להוסיף כאפשרות קונפיגורטיבית רישום של נתוני Trace בכל צומת החלטה שזוהתה בשלב הקודם. הרישום ל-Trace  יבוצע בתהליך (Process/Thread) נפרד בעדיפות נמוכה בכדי למנוע עומסים כתוצאה מהטיפול ברישום נתוני ה-Trace, כמקובל במרבית השפות החדשות, יהיה ניתן לשלוט ברמת הפירוט של ה-Trace באופן שאינו מערב פיתוח (על ידי הגדרות קונפיגורטיביות) כאשר יש להשתדל ככל הניתן להשתמש בקונפיגורציה סטנדרטית (לדוגמה System.Web.Trace/System.Diagnostics.Trace בשפות dot Net) זאת על מנת לאפשר הגדרת תצורה בקלות יחסית ובאופן שאינו תלוי אפליקציה.
3. בשלב הפיתוח, כפי שהובהר קודם לכן, יש לפתח ולבדוק כל מודול שירותי באופן נפרד בבדיקת Black box מלאה ככל הניתן בכדי לוודא שהוא אכן ממלא את תפקידו כראוי. רק לאחר מכן יש לקשר את המודולים זה לזה ולבדוק את האינטראקציה ביניהם.
4. כל מודול שמפותח יבצע בדיקת קלט מחמירה לכל אחד מהקלטים המתקבלים ולא "יבנה" על זה שהקלטים תמיד יגיעו מהמודול שכרגע מתוכנן לתקשר עימו, זאת על מנת לאפשר שימוש במודול הזה במערכות אחרות כסוג של API, לכן גם מומלץ לבצע בדיקות Load test לכל אחד מהמודולים ולוודא שהם נבנו כך שכל מערכת תוכל לתקשר איתם. ככלל, החשיבה  בפיתוח המודול צריכה להיות גנרית ככל הניתן. כך למעשה יהיה ניתן לחסוך פיתוחים כפולים/דומים בארגון.

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

 

השאר תגובה