نیازمندیهای چابک

شما در این سایت با مفاهیم نیازمندیهای نرم افزار چابک آشنا می شوید

۲ مطلب با کلمه‌ی کلیدی «تغییر نیازمندی ها» ثبت شده است

نیازمندی ها در مدل آبشاری: مثلث آهنین


فاز نیازمندی ها در مدل آبشاری

البته به طور یقین نمی توانیم بگوییم که استفاده از فرایند نیازمندی های مبتنی بر مدل آبشاری بدون انعطاف علت اصلی شکست پروژه ها بوده است، اما واضح است که عدم درک درست و تغییر نیازمندی ها تاثیر به سزایی بر روی موفقیت پروژه ها داشته است و مدل آبشاری مدل فرایند حاکم و تاثیر گذار در آن زمان بوده است. به علاوه، به طور فریبنده ای «جعبه نیازمندی های» نشان داده شده در مدل آبشاری به مجموعه ای از نیازمندی هایی اشاره می کند که می توانند به صورت زود هنگام تعیین  شوند و به عنوان مبنایی برای تخمین زمان بندی و بودجه پروژه ها مورد استفاده قرار بگیرند. همان طوری که شکل ذیل نشان می دهد.


هنگامی که نیازمندی ها شناخته شده باشند می توانید هزینه و زمانبندی را تخمین بزنید

(هنگامی که نیازمندی ها شناخته شده باشند می توانید هزینه و زمانبندی را تخمین بزنید)


احتمالا در مثلث آهنین زمانبندی و بودجه نیز ثابت بودند(از همه گذشته، چه کسب و کاری می تواند منابع و هزینه پروژه به شدت متغیر را برنامه ریزی کند؟). بنابراین از یک دیدگاه واقع بینانه تر، این موضوع ما را به سوی تله «مثلث آهنین» هدایت می کند. همان طوری که شکل ذیل نشان می دهد.

در حقیقت، فرض « ثابت بودن محدوده نیازمندی ها» علت اصلی شکست پروژه است. به عنوان نمونه، یک مطالعه مهم انجام شده بر روی 1027 پروژه تکنولوژی اطلاعات در انگلیس [Thomas 2001] بیان می کند که: «مدیریت محدوده وابسته به تجربه های مدل آبشاری بزرگ ترین معیار مشارکت کننده برای شکست پروژه بود است». نتیجه مطالعه به شرح ذیل است:


رهیافتی که در آن کل نیازمندی ها تعریف شوند و سپس به دنبال آن یک گپ طولانی مدت قبل از تحویل نیازمندی ها ایجاد گردد، دیگر مناسب نیست. رتبه بالای تغییر نیازمندی های کسب و کار به این موضوع اشاره دارد که وجود یک تغییر با اهمیت کوچک بر روی نیازمندی هایی که مستندسازی شده اند یک نقص بنیادی و اساسی است.

تله مثلث آهنینِ مدل آبشاری

(تله مثلث آهنینِ مدل آبشاری)

۰ نظر
علیرضا قاقالو

مشکلات مربوط به مدل آبشاری

همانطوری که احتمالا رویس پیش بینی کرده بود، مدل آبشاری برای پروژه های نرم افزاری بزرگ به خوبی کار نمی کرد و ما برای توسعه نرم افزار، زیر بار این مدل سخت تقلا می کردیم. نتایج آمارها در طول یک یا دو دهه گذشته خیلی خوب نبودند. به عنوان نمونه، استندیش گروپ در گزارش [Standish 1994] به موارد ذیل اشاره کرده است: 

  • 31 درصد از پروژه ها قبل از اینکه به اتمام برسند، کنسل شده اند.
  • 53 درصد از پروژه ها بیش از 189 درصد از تخمین شان، هزینه صرف کرده اند.
  • تنها 16 درصد از پروژه ها در زمان مقرر و با بودجه مصوب به پایان رسیده اند.
  • پروژه های تکمیل شده در شرکت های بزرگ تر تنها 42 درصد از ویژگی ها و کارکردهای اصلی خود را تحویل داده اند.

به علاوه، این آمارها نشان می دهند که برخورد غیر موثر با نیازمندی ها علت اصلی شکست پروژه ها بوده است، به دلیل اینکه سه فاکتور بسیار رایج ذیل باعث به وجود آمدن چالش در پروژه ها بوده اند. 

  • فقدان ورودی کاربر: 13 درصد از کل پروژه ها
  • نیازمندی ها و مشخصات ناقص: 12 درصد از کل پروژه ها 
  • تغییر نیازمندی ها و مشخصات: 12 درصد از کل پروژه ها
۰ نظر
علیرضا قاقالو