مدیریت پروژه نرم افزاری, مقاله

چک لیست شکست در RUP (آر یو پی)

۱ 144

این مقاله در وبلاگ Jeff Sutherland در سال ۲۰۰۲ به نقل از  کریج لارمن نوشته شده که خوندنش خالی از لطف نیست. این پست در تکمیل پست قبلیم هست تا بعضی از دوستان بدونن که تا چه حد RUP (آر یو پی) رو اشتباه فهمیدن و اشتباه اجرا میکنن.

اگر شما هم مثل ۱۱ مورد زیر در مورد RUP (آر یو پی) فکر می کنید حتماً باید آگاهیتون رو درباره RUP (آر یو پی) بیشتر کنید:

  • وقتی فکر می کنیم  inception=requirements و elaboration=design و construction=implementation
  • وقتی فکر می کنیم هدف از elaboration اینه که مدل ها باید بصورت کامل و با دقت تعریف بشن و لزوماً فقط همین مدل ها هستن که در فاز construction تبدیل به کد خواهند شد.
  • وقتی فکر می کنیم در فاز elaboration فقط پروتوتایپ ها باید ساخته بشن. در واقع هسته کیفی المان های مهم معماری باید در این فاز تبیین بشن.
  • وقتی سعی می کنیم اغلب نیازمندی ها قبل از شروع مرحله طراحی یا پیاده سازی تعریف بشن.
  • وقتی سعی می کنیم اغلب امور مربوط به طراحی رو قبل از شروع پیاده سازی تمام کنیم.
  • وقتی قبل از شروع کدنویسی زمان زیادی رو صرف تکمیل نیازمندی ها و امور طراحی می کنیم.
  • وقتی فکر می کنیم مدت مناسب هر iteration یا تکرار باید بر حسب ماه باشه نه بر حسب هفته.
  • وقتی فکر می کنیم در مرحله رسم نمودارهای UML و انجام فعالیت های مربوط به طراحی، زمان زیادی باید صرف شه تا حتماً پیش نویس کدها به درستی و بصورت کامل آماده شه تا در مرحله کدنویسی این خروجی ها به سادگی به کدهای اصلی تبدیل شن.
  • وقتی سعی می کنیم در ابتدای کار، کل پروژه رو از آغاز تا پایان برنامه ریزی کنیم بطوریکه جزئیات و رویدادهای هر تکرار از همون ابتدا پیش بینی بشه.
  • وقتی سازمان از شما میخواد قبل از ورود به فاز elaboration، برنامه قابل قبول و پیش بینی های اصلی پروژه رو آماده کنید.
  • وقتی سازمان شما فکر میکنه پذیرفتن RUP (آر یو پی) به این معنی هست که خیلی از فعالیت های اختیاری رو باید بطور کامل انجام بدیم و در هر مرحله باید داکیومنت کاملی رو تولید کنیم و همچنین فکر میکنه تجربه موفق در RUP (آر یو پی) مثل یک فرآیند معمولی میمونه که لزوماً با گذروندن خیلی از مراحل از پیش تعیین شده محقق میشه.

موفق باشید.

Share

در باره نویسنده / 

حمیدرضا متقیان

مدیر محصول نرم افزار. علاقه مند به دنیای وب و ارزش آفرینی در کسب و کار.

ارسال پاسخ

ایمیل شما نمایش داده نمی‌شود. موارد مورد نیاز علامتگذاری شده است *

نوشته های تصادفی

  • ۵ افسانه چابکی

    بی شک برای استفاده از هر روش جدیدی دلایلی وجود دارد.  یکی از این دلایل می تواند برتری نقاط قوت روش جدید نسبت به روش فعلی باشد. اما آیا همیشه اینطور است؟ اگر شما به یکی از دلایل ذیل می خواهید به اجایل مهاجرت کنید باید بدانید که دچار افسانه زدگی Agile شده اید! 🙂…

  • تقابل آریوپی و اجایل

    این پست (تقابل آریوپی و اجایل) یکی از پست های مهم این وبلاگ هست. لازم به ذکر است علاوه بر نظرات فنی کمی نظرات شخصی هم درش وجود داره… در دنیای نرم افزار، تولیدِ موفق محصول کمی با محیط های دیگه متفاوت هست. نرم افزار یه موجود داینامیک هست بطوری که  پروسه تولید یه محصول…

پربازدید ترین ها

  • بندهای حیاتی یک قرارداد تولید نرم افزار

    یک قرارداد نرم افزار محکم از اساسی ترین ملزومات موفق انجام شدن یک پروژه نرم افزاری هست. خیلی از اختلافات بین کارفرما و مجری با استناد به قرارداد رفع میشه و مهمتر از هر چیز بحث ضرر و زیان پروژه هست که برای طرفین مهم هست. بعنوان یک اصل کلی، کلیات و جزئیات قرارداد رو…

  • بایدها و نبایدها در ارائه پروپوزال نرم افزار Proposal

    در اسفند ۸۸ در وب سایت بزرگ برنامه نویس به موجب سوال یکی از دوستان در مورد “شیوه ارائه طرح پیشنهادی نرم افزار” یا پروپوزال نرم افزار (Proposal) پیرو جزئیات RFP  دریافت شده از مشتری، توضیحاتی هر چند مجمل دادم که خوندنش خالی از لطف نیست: Proposal یا پروپوزال نرم افزار رو باید بر اساس…

  • آینده در دستان اینترنت اشیا (IoT)

    Internet Of Things یا اینترنت اشیا تحولی در آینده اینترنت است که مسلماً کسب و کار نرم افزار رو بسیار پر رونق تر و در عین حال فراگیرتر می کند.  فرض کنید به خرید رفتید و خیلی راحت از یخچال خونتون استعلام می کنید که چه چیزهایی رو باید خریداری کنید؛ نیم ساعت قبل از…

عضویت در خبرنامه

بایگانی

شبکه های اجتماعی

آخرین Tweet ها