مهندسی نرم‌افزار – فرآیند های نرم افزار – ۲ (مدل افزایشی)

با سلام و درود، با قسمت چهارم از مجموعه آموزشی «مهندسی نرم افزار» در خدمت شما هستم. این قسمت ادامه مبحث قبلی پیروامون فرآیند های نرم افزار و معرفی مدل افزایشی (تدریجی می باشد).

مدل افزایشی (تدریجی)

توسعه افزایشی (تدریجی) مبتنی بر ایده توسعه ی یک اجرای اولیه، گرفتن بازخورد از کاربران و دیگران، و تحول نرم افزار از طریق چندین ورژن تا زمانی که سیستم مورد نیاز توسعه داده شود، می باشد. به تصویر ۲.۲ توجه نمایید. مشخصات، توسعه و فعالیت های اعتبارسنجی با استفاده از بازخورد سریع در طول فعالیت ها، بجای آنکه جداگانه باشند، درهم تنیده هستند.

مدل افزایشی - مهندسی نرم افزار

توسعه افزایشی-تدریجی به نوعی در حال حاضر رایج ترین روش برای توسعه سیستم های کاربردی و محصولات نرم افزاری می باشد. این رویکرد می تواند به صورت برنامه‌ریزی شده (plan-driven)، چابک یا معمولتر و ترکیبی از این رویکرد ها باشد. در رویکرد برنامه ریزی شده، افزایش و ترقی سیستم به صورت پیشرفته از قبل مشخص می شود. اگر رویکرد چابک اتخاذ شود، افزایش و ترقی به صورت زودرس تعیین می شود، اما توسعه های تدریجی(increment) بعدی بستگی بر پیشرفت و اولویت های مشتری دارد.

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

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

توسعه تدریجی (افزایشی) سه مزیت اصلی نسبت به مدل آبشاری دارد:

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

از چشم انداز مدیریتی، رویکرد افزایشی دارای دو مشکل است:

  1. فرآیند قابل دیدن نمی باشد. مدیران برای اندازی گیری پیشرفت پروژه، نیاز به تحویل منظم دارند. اگر سیستم به سرعت توسعه داده شود، تولید اسنادی که منعکس کننده هر نسخه از سیستم باشد، مقرون به صرفه نمی باشد.
  2. ساختار سیستم با افزودن ترقی های (increment) جدید، در حال تخریب می شود. تغییر منظم به هر طریق ممکن کدهای زیاد و شلوغی که برای عملکرد جدید اضافه شده اند را هدایت می کند که این افزودن ویژگی های جدید به سیستم را به صورت فزاینده سخت و هزینه بر می کند.  برای کاهش تخریب ساختاری و به همریختگی کدها، متدهای چابک پیشنهاد می دهد که شما باید مرتبا نرم افزار را refactor (بهبود و بازسازی) کنید.

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

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

افکار خود را به اشتراک گذارید