מה הכוונה במחזור חיים?

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

למה צריך לתכנן?

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

איך לעשות את זה?

1. בירור צרכים
   השלב הראשון כמובן הוא להגדיר מה צריך. לצורך כך יש לשוחח עם הלקוח ולרשום בצורה מסודרת את דרישותיו. רצוי להתכונן עד כמה שניתן לכך, למשל על ידי ביקור באתרים דומים.
   ברוב המקרים, אחרי שלב זה נדרש לתת הצעת מחיר לביצוע הפרוייקט, כך שרצוי מאוד שנברר את מירב המידע שנדרש לצורך ביצוע הערכה של עלויות. למשל, בכמה דפים מדובר (דינמיים וסטטיים), מספר הטבלאות, תהליכים עיקריים (למשל רישום משתמשים, ניהול מוצרים, נוהל מכירה, בדיקת כרטיסי אשראי וכד'), האם קיימים ממשקים, מי מבצע את העיצוב הגרפי ועוד.
   ככל שתהיו מנוסים יותר תדעו לשאול את השאלות הנכונות בזמן.
   
   
2. אפיון
   עכשיו הכל ברור? בהחלט לא. מטרתו של שלב האפיון הנה לנתח פעם נוספת את הדרישות ולכתוב (כן. כותבים הכל) את מה שיש לבצע. יש להתייחס ל:
   • תהליכים – מי עושה מה ומתי, איזה מידע מעודכן ונוצר, מה מוצג לגולש.
   • מידע – אילו טבלאות קיימות, מהן השדות (בדיוק), מהם הקשרים בין הטבלאות
   • נושאים חשובים נוספים כגון:
   • אם קיימים ממשקים, מהו המבנה והאופי שלהם, כלומר האם הם דו-כיווניים או חד-כיווניים, מתי הם מתעדכנים ואיך.
   • היבטי אבטחת מידע.
   • היבטים טכנולוגיים כגון חומרה, אחסון האתר וכד'.
   • היבטים אנושיים שקשורים ללקוח, לעדכון האתר או גורמים אחרים שיש להתחשב בהם.
   חשוב לשלב סקיצות של מסכים. טוב מראה עיניים…
   
   מאוד מומלץ לאשר את האפיון הזה מול הלקוח. זה יבטיח את רמת הציפיות של שני הצדדים ושאכן ברור מה יש לעשות.
   
   בכל שלב האפיון לא כותבים שם של פונקציה אחת או דף ASP. למעשה, זה אמור להיות שלב לא טכני לחלוטין.
   
   
3. עיצוב טכני
   הנה, מתחילים עם ה-ASP. בשלב הזה לוקחים את האפיון ומתרגמים אותו לשפה הטכנית, אבל עדיין על הנייר. מול כל תהליך, ממשק או תצוגה, רושמים את שמות המודולים שיש לפתח, אם מדובר בדפי ASP, פונקציות, שאילתות, משתנים גלובליים וכד'. בשלב הזה מחליטים לגבי האופן היעיל ביותר למימוש כל פרט באפיון. (על פיתוח נכון ויעיל של קוד – במאמר אחר…) עיצוב גרפי וביצוע גרפי נעשים גם הם בשלב הזה.
   כדי להיות בטוחים כדאי לבדוק שמול כל סעיף באפיון יש סעיף בעיצוב.
   
   שלב זה חיוני במיוחד במידה והפיתוח מבוצע על ידי יותר מתוכניתן אחד. במקרה כזה, חשוב להתייחס בעיצוב גם לחלוקת העבודה ההגיונית.
   
   במקרים מסויימים אפשר לאחד את האפיון והעיצוב. אם לא חייבים – עדיף שלא לאחד אותם.
   
   
4. פיתוח
   מפתחים לפי העיצוב כמובן.
   מה קורה אם תוך כדי הפיתוח מגלים ששכחנו משהו בתכנון? חוזרים לשולחן השרטוט. מתכננים מחדש וזאת כדי להבטיח שהשינוי שאנחנו עושים לא משפיע על מודול או רכיב אחר באתר שלנו. זה גם במקרה שהלקוח נזכר במשהו וגם במקרה שאנחנו פספסנו משהו בעצמנו.
   
   
5. בדיקות
   שלב חיוני ביותר בפרוייקט! הדרך העדיפה לביצוע הבדיקות היא זו:
   • כתיבת תסריטי בדיקות. המהדרין ממש כותבים תסריטים של שלב אחר שלב – מה עושים באתר, מה מצופה שיקרה. אפשר להסתפק בפחות ולהכין גליון excel עם רשימת הפעילויות והדפים באתר. עוד פחות – בודקים מול מסמך האפיון שכתבנו.
   • ביצוע מחזור בדיקות. הכי טוב שמי שיבדוק הוא לא זה שפיתח. אל תתנו ללקוח לבדוק. קחו איזה חבר או קרוב משפחה שאוהב אתכם מספיק כדי לעשות את זה. מה עליו לעשות? לעבור סעיף סעיף בתסריט הבדיקות ולוודא שאכן כך זה עובד. להתעלל באתר שלכם. זכרו תמיד – גולש אקראי תמיד יעשה בדיוק ההיפך ממה שציפית שיעשה.
   • תיקונים. תיקון כל התקלות שנמצאו בבדיקות.
   • חזרה על הבדיקות והתיקונים. עד שהכל נקי ועובד תקין.
   
   
6. מסירה ותחזוקה
   לכאורה סוף הפרוייקט – התקנת המערכת תוך הבטחה שהכל תקין. מומלץ להכין מסמך התקנה עוד בשלב העיצוב הטכני.
   בפועל – זה השלב שבו מתחילים השינויים והתיקונים (שלא לדבר על כל התקלות שלא זיהינו בבדיקות). רצוי בשלב שבו מכינים את הצעת המחיר להתייחס לשלב זה ולאופן התשלום עליו (לפי שעות כמובן).
   כדי לא להסתבך כדי להתייחס לכל שינוי פה כאל מיני פרוייקט ולעשות לו אפיון (גם ביחס ליתר המודולים), עיצוב טכני, פיתוח ובדיקות. בגלל שיש הרבה עבודה מסביב, רצוי שלא לעשות כל פעם שינוי קטן, אלא ליצור מקבצים של שינויים.
   

לסיכום

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

בהצלחה!