סיבות לכישלון הפרויקט

admin

רוב פרויקטי התוכנה נכשלים לחלוטין או חלקית, כי מספר קטן של פרויקטים לענות על כל הדרישות שלהם. דרישות אלה יכולות להיות עלויות, לוח זמנים, איכות או דרישות. על פי מחקרים רבים, שיעור הכישלון של פרויקטים תוכנה נע בין 50% ל 80%. מאמר זה הוא אוסף של הסיבות לכישלון של פרויקטים בפיתוח תוכנה; מאמר זה מסכם מספר תחומים הממלאים תפקיד חשוב בכשלים בפרויקטי תוכנה.

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

אחת הטענות החמורות ביותר על כישלון תוכנה היא חוסר יכולת

אמידה עם דיוק מקובל של עלויות, משאבים ולוח זמנים

עבור פרוייקט תוכנה. שיטות הערכה קונבנציונאלי תמיד נוצרו

תוצאות חיוביות שתורמות לעלויות ידועות מדי של התפשטות

מחליקה את לוח הזמנים.

במהלך 20 השנים האחרונות, אומצו עלויות רבות וטכניקות תזמון

עם תחושה מעורבת בשל מגבלות של מודלים הערכה. The main

הערכות מסוימות יכולות לנבוע מחוסר הבנה

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

תכנון, תזמון והערכות מחיר.

ניתוח של כשלים

להלן כמה מן המקרים לנתח כי ינותחו להורדה

הסיבות העיקריות לכישלון של מערכת התוכנה.

אוניברסיטת Northumbria פיתחה תוכנה לניהול חשבונות כדי לנהל את ענייני היומיום

עסק. הפרויקט לא הצליח להשיג את התוצאות הרצויות ונכשל

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

הנהלים לא נעשו. מקרה זה מופיע במאמר זה ב

נקודות שונות אם יש צורך. [1]

תאילנדי סניף (SMTL) של חברה רב לאומית המבוססת בהונג קונג (SMHK)

מעורב בייצור של ציוד אלקטרוני. מיושם

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

הגורמים קשורים בעיקר להנהלה. כגון התאמה עסקית גרועה

הנחות תהליך רשום בתוכנות תוכנה ועסקים SMTL,

מנהיגות חלשה ברמות שונות, הבדלים תרבותיים וארגוניים

סביבה וניהול לקוי של משאבי אנוש.

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

סיעודי, הכוללים ניתוח כללי וכללי. כל אלה

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

ואת השירותים הטיפוליים כי הם באתר. כמו בית החולים לתיירים הראשי

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

מספר עבודות הגיוס הלא רשום.

ניהול תוכנה ומנהיגות

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

העובדים גם הרגישו כי ניהול רק לעתים רחוקות "הקשיב" לחששותיהם

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

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

חברה.

תכנון פרויקטים ותכנון

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

בדרך כלל, תהליך עמוד השדרה פועל בתהליך פיתוח התוכנה

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

לא ניתן להשלים את הפרויקט בהצלחה בשלב התכנון

בשלב היישום.

חלוקת התפקידים והאחריות חייבת להיות מוגדרת בבירור, וזאת

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

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

שגיאת פרוייקט.

תכנון נכון נדרש גם לפני תחילת הפרויקט. זה

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

עליהם לתכנן ולתכנן. הם פשוט אומרים למתכנת מה לעשות

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

הפיתוח הועבר למשרד חדש, והמשרד לא היה מלא

מצויד בתשתית המתאימה. כי הזמן הוא גם גורם חשוב להצלחה

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

לקראת כישלון הפרויקט. התשתית לא תוכננה במלואה

צוות הניהול לא ידע היכן וכיצד יפותח הפרויקט

זה התחיל.

הסוד החשוב ביותר של פרויקט תכנות מנצח הוא שליטה

להגדיל את איכות ולהקטין את הסיכון. תוכנית החירום היא גם חלק מהתכנון.

אם משהו השתבש, אז תוכנית זו יכולה לשמש כדי להקטין את ההשפעה

כישלון הפרויקט. כנ"ל לגבי תוכנת הנהלת האוניברסיטה.

לצוות ההנהלה לא הייתה תוכנית חירום כזו, וכן לא העריכו את הסיכון

המעורבים בפיתוח המערכת החדשה. אז זה גרם יותר צרות בלי

מערכת גיבוי או תוכנית גיבוי.

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

הערכת עלויות

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

הערכות עלות צריכות להתבצע הרבה לפני תחילת הפרויקט

פיתוח. אי תקצוב הפרויקט עלויות עלויות

אסון מוחלט. כאמור, עלות התשתית, כלי התכנות

ראשית, אתה צריך להעריך את העלות והמחיר של הציוד.

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

רכשה מערכת חדשה וללא כל עלות רצינית

מקורות הכנסה.

להלן אנו נותנים את הסיבות לאמוד שגוי של עלויות.

מתודולוגיית אמידה לא נאותה

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

"הצעה טובה היא כי יותר מתודולוגיה אחת להערכת עלויות התוכנה

צריך לשמש לאמידה מדויקת ".

כלי הערכת עלויות

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

כלי הערכת תוכנה טובה לא תמיד מבטיחים תוכנה אמינה

מעריך. מבוא שגוי של גודל התוכנה יגרום לאמידה שגויה.

תוכנת האמידה צריכה להיות מותאמת גם לצרכים הספציפיים שלך

ארגון. התאמות אלה מחייבות נתונים מפרויקטים קודמים

נתוני קלט עבור כלי האמידה.

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

בחירת כלי הערכה נכונה

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

קלות ההתאמה האישית

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

קל לשימוש וללמוד

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

הערכה מדויקת

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

ניהול סיכונים

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

זיהוי סיכונים

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

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

מנהלי פרויקטים חייבים לזהות תחומים בהם קיימים סיכונים וכיצד זה קורה

יכול להשפיע על הפיתוח של הפרויקט. הסיכון עשוי להיות טכני או

nontechnical. מנהלי הפרויקטים חייבים להיות מודעים לסיכונים. רוב

מנהלי פרויקטים אינם טובים באף אחד מהצדדים. מנהל טוב מ

כישורי התכנות יכולים להיות טובים בזיהוי סיכונים טכניים, אך לא בתוכם

– סיכון טכני.

הערכת סיכונים

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

סיכוני עדיפות

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

הימנעות מהסיכון

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

בקרת סיכונים

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

יישום

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

תכנון ותכנון מגיע קודם, תכנון טוב עושה תכנון

בסיס חזק לתכנון תוכנה. תכנון הפרויקט מורכב

בניית משימות שונות, מועדים ונתיבים בסיסיים, כולל גנט

תרשימי PERT וגרפים ותוכניות כתובות שונות למצבים שונים. אם

גורמים אלה אינם נלקחים בחשבון, ולאחר מכן התוכנה עשויה להיתקל בבעיות

במהלך הפיתוח ואת המוצר הסופי יהיה כישלון.

הערכת העלות תלויה בתקציב הפרויקט, סוג הלקוח ו

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

במהלך מחזור חיי הפרויקט. זה משפיע על הפרויקט במובנים רבים, רע

הערכת כישלון מוחלט, משפיעה על טובת הארגון, אם

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

ניהול סיכונים הוא גישה מעשית לצמצום העמימות

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

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

הם מועילים או ממוקדים סיכונים (סיכון שלילי) אם התוצאות שלהם

שלילי.

Leave a Reply