دالیل شکست پروژه های نرم افزاری

Transcription

1 دانشگاه آزاد اسالمی مشهد دالیل شکست پروژه های نرم افزاری استاد راهنما: جناب آقای دکتر احمدی تهیه کننده: حامد زجاجی بهمن 5831

2 مقدمه داشتن اطالعاتی در مورد دالیل تأثیرگذار بر روی مؤفقیت شکست و Challenged شدن پروژه ها می تواند توان مدیریت در پروژه های نرم افزار را توسعه بخشد. بر اساس آمار گروه تحقیقاتی StandishGroup تنها %83 از پروژه های نرم افزاری به اتمام رسیده اند. تقریبا %88 از آنها لغو شده اند و باقیمانده آنها یا در ارائه تأخیر داشته اند و یا بیشتر از حد تخمین زده شده هزینه بر بوده اند. وضعیت پروژه های نرم افزاری بر اساس آمار Engineering News-Record %49 از خریداران پروژه های ساختمانی از نتیجه پروژه شان راضی بوده اند که این موضوع نشان می دهد پروژه های ساختمانی نرخ خطای پایین تری را نسبت به پروژه های نرم افزاری دارا می باشند. پروژه های نرم افزاری را به می توان به دو نوع Comercial و Non-Comercial تقسیم نمود. پروژه های Comercial با اهداف تجاری توسط شرکت ها تولید می شوند مانن نرم افزار هایی که به صورت خاص برای مشتریان نوشته می شوند. مانند یک سیستم Billing و یا نرم افزار هایی که به صورت Off-The-. Microsoft Word انبوه( تولید می گردند مانند )تولید Shelf پروژه های Non-Comercial اغلب Open Source می باشند. کاربران چگونگی عملکرد آنها را پیدا می کنند و خطا های آنها را برطرف می سازند و ویژگی های جدید دلخواه خود را به آن اضافه می کنند. 5. بررسی آماری وضعیت مؤفقیت و شکست پروژه های نرم افزاری در شرکت ها Standish Group شرکت ها را به سه دستة بزرگ متوسط و کوچک تقسیم می کند :

3 بزرگ : با در آمدی بیش از 155 میلیون دالر در سال متوسط : با در آمدی بین 855 تا 155 میلیون دالر در سال كوچك : با در آمدی بین 555 تا 855 میلیون دالر در سال Fail Challenged Succeded % 8.75 % 5571 بزرگ % 4 % 8471 % 957. متوسط % 5578 % 8575 % 1579 کوچک % 83 یکی از دالیل سربار شدن زمان و هزینة پروژه ها شروع مجدد )Restart( آنها می باشد. برای هر صد پروژه ای که شروع می گردد 49 شروع مجدد وجود دارد. این بدان معنا نیست که 49 پروژه از هر 555 پروژه یکبار شروع مجدد دارند بلکه ممکن است یک پروژه چندین شروع مجدد داشته باشد. : میانگین سربار هزینه نسبت به هزینة اولیه تحمین زده شده برای تمام سربار هزینه Overruns( )Cost شرکت ها %534 می باشد. سربار هزینه بزرگ % 5.3 متوسط % 538 کوچک % 859 : میانگین سربار زمانی نسبت به زمان اولیه تحمین زده شده برای تمام سربار زمانی Overruns( )Time شرکت ها %888 می باشد.

4 سربار هزینه بزرگ % 885 متوسط % 858 کوچک % 884 %55 به طور میانگین در پروژه هایی که Challenged می شوند تنها از مشخصه هایی که قرار بوده است در سیستم باشند در پروژه نهایی وجود دارد. درصد وجود مشخصه ها در پروژة نهایی % 58 بزرگ % 51 متوسط %.9 کوچک 8. بررسی دالیل مؤفقیت و شکست پروژه های نرم افزاری Standish Group عوامل تأثیر گذار در موفقیت Challenge و شکست پروژه های به صورت زیر تعریف کرده است. در جدول زیر عوامل تأثیر گذار در مؤفقیت پروژه های نرم افزاری بیان شده است. % پاسخ عوامل موفقيت پروژه ها % 5174 درگیر شدن کاربر در پروژه. 5 % 5874 پشتیبانی مدیرت اجرایی. 8 % 5875 وضوح احتیاجات. 8 % 475 برنامه ریزی مناسب. 9

5 % انتظارات واقع بینانه. 5 Milestone ها کوچک تر در پروژه.7.% %.78.. شایستگی کارمندان % مالکیت % وضوح دید و اهداف. 55 سخت کوشی و تمرکز کارمندان % 879 % 5874 دیگر عوامل در جدول زیر عوامل تأثیر گذار در Challenged شدن پروژه های نرم افزاری بیان شده است. % پاسخ عوامل Challenged شدن پروژه ها % عدم دسترسی به کاربران. 8 مشخصه ها و نیازمند های ناقص % بروز تغییرات در مشخصه ها و % 5573 نیازمندی ها. 9 عدم وجود پشتیبانی اجرایی 71.% % ناتوانی فنآوری مورد استفاده % عدم وجود منابع % انتظارات غیر واقع بینانه % اهداف مبهم. 4 برنامه زیری های زمانی غیر واقعی % 978 % فنآوری های جدید % 8875 دیگر عوامل

6 در جدول زیر عوامل تأثیر گذار شکست پروژه های نرم افزاری بیان شده است. % پاسخ عوامل شكست پروژه ها % نیازمندی های ناقص. 8 عدم درگیری کاربر در پروژه % 5879 % عدم وجود منابع % انتظارات غیر واقع بینانه % عدم وجود پشتیبانی اجرایی. 5 بروز تغییرات در مشخصه ها و.37 % نیازمندی ها % عدم برنامه ریزی %.71 Didn t Need It Any Longer. 3 % عدم وجود مدیریت IT % ناتوانی فنآوری مورد استفاده % 474 دیگر عوامل 8. عوامل شکست پروژه های نرم افزاری بر اساس مقاله ای در IEEE عوامل مشترك در شکست پروژه های نرم افزاری بر اساس مقاله ای در IEEE به صورت زیر فهرست شده است. اهداف غیر واقعی 5. تخمین نادرست منابع مورد نیاز 8. گزارش نادرست از وضعیت پروژه 8. ریسک های مدیریت نشده 9. ارتباطات ضعیف بین مشتریان توسعه دهندگان و کاربران 1. استفاده از فنآوری ناکارآمد 5. ناتوانی در مدیریت پیچیدگی های پروژه.. روش های توسعة نادرست 3.

7 4. مدیریت ضعیف پروژه 55. سیاست های نگهداری 55. فشار های مالی 9. دالیل متفاوت بودن نرم افزار در شکل زیر دالیل دوازده گانة تفاوت پروژه های نرم افزاری با سایر پروژه ها و همچنین روابط و وابستگی بین آنها آورده شده است. در ادامه به بررسی هر کدام از این دالیل می پردازیم نرم افزار پیچیده است. با تفکیک قسمت های مختلف سیستم و شکستن آن به قطعه های کوچک )به نام )Object یا حتی قطعه های بزرگ )به نام )Component این جنبه از پیچیدگی کاهش می یابد. شکل زیر به خوبی این وضعیت را نشان می دهد. در شکل زیر تعداد 55 رابطه به 53 رابطه کاهش پیدا می کند.

8 تعداد خطوط زیاد برنامه ها سبب پیچیده تر شده آنها می شود. به همین علت توسعه دهندگان سعی می کنند با ایجاد قسمت های مختلف در سیستم این جنبه از پیچیدگی را کا هش دهند. این تکنیک Encapsulation نامیده می شود و کلید اصلی برنامه سازی شی گرا می باشد. به عنوان یک هدف باید باین کرد که : "کاهش پیچیدگی قلب توسعه نرم افزار است." نکته : نرم افزار از نظر پیچیدگی منحصر بفرد است نرم افزار انتزاعی است. نرم افزار های به صورت فیزیکی قابل لمس نمی باشند. نرم افزار روحی است که می تواند از یک پروژه با کمی سختی به پروژه دیگر منتقل شود. درك این مطلب مهم است که هر معماری یا نمودار که برای پروژه ایجاد می کنیم در اصل ناکافی است. اگر ما هر جزئیاتی را نمایش دهیم در حقیقت نرم افزار را از شکلی به شکل دیگر درآورده ایم و زمان و تالشمان به هدر رفته است نکته : نرم افزار ها انتزاعی ترین محصوالتی هستند که در یک پروژه می توانند ایجاد شوند نیازمندی ها ناقص می باشند. ترسیم مجموعة کاملی از نیازمندی ها در سیستم قبل از اینکه سیستم به نوعی تکمیل گردد غیر ممکن است. کاربران در زمان کار با سیستم دیدگاه جدیدی نسبت به نیازمندی هایشان پیدا می کنند. تمام تصوراتی که بر این مبناست که شما باید مجموعة دستیافتنی و نهایی از نیازمندی ها را داشته باشید و یا حتی می توانید داشته باشید خود فریبی است. درسترین پاسخی که یک کاربر می تواند بدهد اینست که : "من می دانم چه می خواهم اگر آن را ببینم."

9 است. Standish Group در سال 8555 در مقاله ای تحت عنوان Factors Project Challenged اعالم کرد که مسئله مربوط به نیازمندی ها و خصوصیات بیشترین اهمیت را برای %98 از پروژه های نرم افزاری دارد. نکته : تعریف یک مجموعة کامل از نیازمندی ها برای نرم افزار قبل از توسعه به طور منحصر بفردی مشکل 979. فنآوری ها به سرعت تغییر می کنند. امروزه تقریبا تمام نرم افزار های جدید و مهم بر روی Enterprise Application Framework ها نظیر J2EE و.NET ساخته می شوند. تکنولوژی هایی از این قبیل به طور وسیعی افق توسعة نرم افزار را تعیین می کنند. نکته : فناوری توسعة نرم افزار سریعتر از فناوری های ساخت دیگر تغییر می کند بهترین روش های توسعة نرم افزار هنوز کامل نشده اند. نکته : اغلب فنآوری های توسعة نرم افزار به اندازه ای کامل نشده اند تا بتوانیم مجموعه ای از بهترین روش های آزمایش شده را در اختیار داشته باشیم فنآوری حوزة بسیار وسیعی دارد. وجود Framework ها و Web Service ها و... نشان دهندة دامنة وسیع فنآوری توسعة نرم افزار می باشد. این دامنة وسیع از فناوری ها معموال در پروژه های دیگر به چشم نمی خورد..97. تجربة فناوری کامل نیست. فنآوری ها به سرعت در حال تغییر هستند. نسخه های جدید هر فنآوری به طور اساسی عملکرد و استفاده از فناوری ها را تغییر می دهند و این تغییرات الزم و گریز ناپذیر است. در پروژه ها از مؤلفه هایی استفاده می شود. اما به ندرت از این مؤلفه ها می توان در پروژه های بعدی استفاده نمود زیرا پروژها و نسخه های بعدی ممکن است به صورت کامال متفاوتی مؤلفه ها را مورد استفاده قرار دهند. نکته : تجارب کار با فنآوری های توسعة نرم افزار خیلی سریع منسوخ می شوند و بنابراین بیشترین مهارت ها در حین کار بدست می آیند توسعه نرم افزار یک مسئلة پژوهشی است. از آنجا که مشتریان افراد متخصصی در نرم افزار نمی باشند همیشه قادر نخواهند بود تمایزی بین آنجه که ممکن است با آنچه که غیر ممکن است قائل شوند. بنابراین به یک توسعه دهنده جهت تشخیص آن نیاز است. این بدان معناست که فرآیند توسعه یک فرآیند یافتن صفات دقیق نرم افزار است به طوریکه منطبق با نیاز های

10 کاربر باشد. ارائه نسخه های مختلف به کاربران از جمله نسخة 575 یا نسخة بتا به کاربر کمک می کند تا نیازمندی های خود را بهتر درك کند و همچنین به توسعه دهنده کمک می کند تا خطاهای سیستم را توسط کاربران کشف نماید. همچنین توسعة نرم افزار فرآیندی است که در آن مشخص می گردد چه فناوری جهت اجرای آنجه که درخواست شده است باید انتخاب گردد. نکته : توسعه نرم افزار تنها فرآیند ساخت نرم افزار نیست بلکه فرآیند یادگیری چگونگی ایجاد نرم افزار به طوریکه بهترین نتیجه حاصل شود نیز می باشد کارهای تکراری اتوماتیک می شوند. ابزارهایی از قبیل Framework ها و Web Service ها در حقیقت نتیجه ای از تالش برای خودکار سازی در توسعة نرم افزار باشند. نکته : خودکار سازی در توسعة نرم افزار نسبت به پروژه های دیگر با درجة باالتری انجام می گیرد طراحی واقعی مرحلة ساخت )Construction( است. به عنوان مثال در فرآیند ساخت یک جاده بعد از تکمیل طراحی و نقشه عملیات ساخت می تواند آغاز شود. اما در فرآیند توسعة نرم افزار هیچ طرح و نقشة قطعی را نمی توان ارائه نمود بروز تغییرات امری است که به سادگی بوجود می آید. بر خالف پروژه های عمرانی که تغییرات در آنها به سختی انجام می شود و به همین دلیل از انجام تغییرات بعد از ساخت صرف نظر می گردد پروژه های نرم افزاری در هر زمانی قابل تغییر می باشند. نکته : نرم افزارها به سرعت تغییر داده می شوند و این اجتناب ناپذیر است. اما بهتر است این تغییرات بدرستی انجام گردد تغییرات اجتناب ناپذیر است. مشتریان وقتی می بینند نرم افزارها به راحتی تغییر می کنند انتظار دارند ذهنیت هایشان را از هر نظری در مورد نرم افزار تغییر دهند. در یک مطالعه که بر روی 3555 پروژه نرم افزاری شده بود به این نتیجه رسیدند که تقریبا %95 از نیازمندی های پروژه بعد از مدت زیادی از آغاز پروژه مطرح شده است. تغییرات اجتناب ناپذیر است و اگر قطعه ای از نرم افزار به صورتی که قابل تغییر باشد ساخته نشود قطعا بعد از مدتی باید کنار گذاشته شود. کیفیت نرم افزار زمانی نمایان می شود که نرم افزار نیاز به توسعه و تغییر پیدا

11 کند. چنانچه تغییرات بدرستی انجام نشود سبب ایجاد کاستی و خطا در سیستم می گردد و کد را تبدیل به fragile code می کند و اشکال زدایی آن را مشکل می سازد. نکته : هیچ نرم افزاری کامل نمی باشد. همة نرم افزارها جهت کارآیی بهتر همیشه نیازمند تغییرات می باشند.

12 Software project secrets : Software project fails George Stepanek CHAOS Chronicles 1994 Why Software Fails - By Robert N. Charette - IEEE 2005 مراجع