תחזוקת תוכנה לפי עלות ולוח זמנים

admin

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

1. מבוא אחד האתגרים הגדולים ביותר בפני מהנדסי תוכנה הוא ניהול בקרת שינוי. ההערכה היא כי עלות בקרת השינויים יכולה לנוע בין 40% ל -70% מעלויות מחזור החיים. מהנדסי תוכנה מקווים ששפות חדשות והתהליך החדש יפחיתו משמעותית את המספרים הללו; אבל זה לא קרה. ביסודו של דבר, זה בגלל התוכנה הוא עדיין נמסר עם מספר גדול של disadvantages. קפרס ג 'ונס מעריך כי היו כ 5 שגיאות בשלב הפיתוח בנקודת הפיתוח. ווטס האמפרי הצהיר כי "אפילו מהנדסי תוכנה מנוסים בדרך כלל מזריקים 100 ליקויים או יותר על KSLOC". Capers Jones אומר: "התוכנה צפיפות פגם סדרת הבדיקה משתנה בין 49.5 ל 94.5 שגיאות לאלף שורות קוד." מאמר זה צריך קודם לסקור את היסודות של תחזוקת תוכנה ולספק גישות חלופיות להערכת תחזוקת תוכנה. מרכיב מרכזי שיש לציין הוא כי החלטות עיצוב וניהול נלקחה במהלך תהליך העיצוב יכול להשפיע באופן משמעותי על עלויות הפיתוח ועלויות התחזוקה הקשורים.

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

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

ניתן להשתמש ברשימה הבאה לבדיקת הריאליזם והדיוק של דרישות התחזוקה.

o אילו חלקים של התוכנה ישמרו?

o כמה זמן יש לשמור על המערכת?

o האם אתה מדרג את כל בעיית התחזוקה או פשוט מעלה את התחזוקה?

o איזו רמת תחזוקה נדרשת?

האם מה שמכונה תחזוקה באמת פרוייקט פיתוח חדש?

o מי יבצע תחזוקה? האם זה ייעשה באופן אורגני על ידי המתכנת המקורי? האם יהיה צוות נפרד? האם יהיה ארגון נפרד?

o האם המתחילים ישתמשו באותם כלים המשמשים ליצירת? האם יש כלים קנייניים הדרושים לתחזוקה?

o מהו כמות המדף המסחרי (COTS)? כמה ממשקים מחוברים?

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

o האם הפעילות באמת משתפרת?

o האם שברים בריאים מהקוד המקורי משוכפלים או משתנים?

האם צוות נוסף יבוצע לעדכון?

o האם לוח הזמנים של עבודות תחזוקה קבוע ו שטוח למדי, או האם זה מכיל humps העובד שנראים כמו פרויקטים חדשים?

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

אנו משקיעים כ 2 עד 3 פעמים מאמץ נוסף כדי לשמור ולשפר את התוכנה כאשר אנו מבלים על יצירת תוכנה חדשה.

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

o אפוטרופוס אחד יכול לטפל בסביבות 10,000 קווים בשנה.

o המאמץ הכולל במחזור החיים הוא בדרך כלל 40% פיתוח ותחזוקה של 60%.

o העלות הממוצעת של החיים היא שישית מעלות הפיתוח השנתיות.

o מערכות מוצלחות נשמרים בדרך כלל במשך 10 עד 20 שנים.

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

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

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

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

5.3 גורם שינוי בתחזוקה הערכת עלויות תוכנה עם COCOMO II (Boehm 2000) מציעה מתודולוגיה פשוטה אך מטעה מאוד לקביעת תחזוקה שנתית. תחזוקה היא אחת מאפשרויות התפריט בשורת התפריטים. תחזוקת ה – COCOMO II כוללת את תהליך שינוי התוכנה התפעולית הקיימת, ובכך משאירים את תפקידיה הבסיסיים ללא פגע. תהליך זה אינו כולל:

o עיצוב מחדש רציני ופיתוח מחדש (מעל 50% של הקוד החדש) של תוכנה חדשה עם למעשה את אותן פונקציות.

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

o עיבוד נתונים במערכת פעולות, הזנת נתונים ושינוי ערכים במסד הנתונים.

חישובי התחזוקה מבוססים במידה רבה על גורם השינוי הפעיל (MCF) ועל גורם ההתאמה לתחזוקה (MAF). MCF דומה לתנועת השינוי השנתית ב- COCOMO81, פרט לתקופות תחזוקה שאינן שנה אחת. הנוסחה המתקבלת להערכת עבודת התחזוקה זהה למודל הפיתוח של PostC Architecture COCOMO II.

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

מאמץ תחזוקה שנתית = (שינוי שנתי) * (מאמץ מקורי לפיתוח תוכנה)

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

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

5.4 אחזקה של עלויות תחזוקת תוכנה על ידי טכניקות פיתוח והחלטות ניהול במהלך הפיתוח

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

לויד האף וג'ורג 'נובאק מ"לוקהיד מרטין אווירונאוטיקס "במאמר" לוקהיד מרטין אווירונאוטיקה המבוססת על ביצועים לסביבת ה- F-35 ברקים II "מציעים שורה של החלטות פיתוח וניהול שנועדו להשפיע על עלות השמירה והפחתת התוכנה. הם מציעים תהליך בן שמונה שלבים של אמידה ושליטה על תחזוקת התוכנה. הצעדים המוצעים הם:

1. מטרת הקהילה

2. החלת שיטות הנדסה תעשייתית על תוכנה

3. לעסוק

4. ליישם גישה הוליסטית לפיתוח בר קיימא

5. לפתח מערכות מתוחכמות ותוכנות

6. נהל את התוכנה מדף

7. תוכנית בלתי צפויה

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

5.5 הערכה פרמטרית של תחזוקת תוכנה

מודלים פרמטריים, כגון SEER for Software, מאפשרים הדמיית תחזוקה באחת משתי דרכים:

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

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

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

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

6. יישום מסקנות סעיף זה הן כדלקמן:

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

o החלטות ניהול במהלך תהליך הפיתוח יכול להשפיע באופן משמעותי על עלויות תחזוקת התוכנה.

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

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

הפניות [1] מושגים ותחזוקת תוכנה (מהדורה שנייה) מאת פני גראב וארמסטרונג טקנג, World Scientific, 2005.

[2] הערכת מערכות תוכנה אינטנסיביות; ריצ'רד סטוזקה, 2005, אדיסון-וסלי.

[3] לויד האף, ג'ורג 'נובק; לוקהיד מרטין אווירונאוטיקה; לוקהיד מרטין אווירונאוטיקה ביצועים תוכנה עבור F-35 ברקים II.

[4] G. Edward Bryan, "CP-6: איכות וביצועים במחזור חיים של מערכת הפעלה של 15 שנה", Dziennik Jakości Jakościowania 2, 129-144, June 1993.

[5] מימדים, אמידה וניהול סיכונים בתוכנה; דניאל ד. גלוראת, מייקל וו. אוונס, 2006, פרסומי אוירבך.

Leave a Reply