متدولوژی ها و فرایندهای مختلف توسعه نرم افزار

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

متدولوژی توسعه نرم افزار چیست؟

متدولوژی های توسعه نرم افزار در حوزه رویکردهای سیستماتیک شکل گرفته و گسترش یافته اند. در این رویکرد، فعالیت های تولید و توسعه نرم افزار در قالب سه فرایند اصلی انجام می گیرند:

1- برنامه ریزی (نیازسنجی، امکان سنجی، تامین منابع)
2- توسعه (طراحی، پیاده سازی، تست، مستندسازی)
3- استقرار و نگهداری (نصب، آموزش کاربری، پشتیبانی)

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

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

انتخاب متدولوژی برای تیم توسعه، امری حیاتی است. اما شرایط پروژه، منابع در اختیار، خصوصیات تیم توسعه و ویژگی های مشتری؛ تعیین می کند که کدام متد می تواند مناسب تر باشد. هر روش توانمندی ها و محدودیت هایی را ایجاد می کند که باید برای انتخاب مورد توجه قرار گیرد.

بیشتر بخوانید: توسعه نرم‌افزار چیست و انواع نرم‌افزار کدامند؟

متدولوژی های حوزه توسعه نرم افزار را از منظر فلسفه شکل گیری می توان به سه گروه آبشاری، تکاملی و پیوسته دسته بندی نمود.

1- متدولوژی های آبشاری:

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

مدل آبشاری

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

مزایای مدل آبشاری:

• ساختار، خطی و قابل فهم است.
• تمام ویژگی ها و قابلیت ها قبل از شروع کدنویسی، مشخص است.
• با تعریف دقیق هر مرحله، خطای ارتباطی به حداقل می رسد.

معایب مدل آبشاری:

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

مدل V

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

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

2- متدولوژی های تکاملی:

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

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

بیشتر بخوانید: متدولوژی چابک (agile) در توسعه نرم افزار

مدل اسکرام

اسکرام از محبوب ترین مدل های توسعه نرم افزار در متدولوژی چابک است. در مدل اسکرام سه نقش کلیدی حضور دارند: مالک محصول، اسکرام مستر و تیم توسعه.

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

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

مزایای مدل اسکرام

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

معایب مدل اسکرام

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

اسکرام برای پروژه هایی مناسب است که الزامات و نیازهای مبهمی دارد و در عین حال باید با تغییرات مکرر انطباق یابد.

مدل توسعه ویژگی محور

مدل توسعه ویژگی محور یا FDD نیز بر اساس فلسفه Agile توسعه یافته است. هدایت کننده ساده ای دارد: «از سردرگمی که باعث دوباره کاری های پرهزینه می شود؛ اجتناب کن!» در این مدل، پروژه به فهرستی از ویژگی ها یا فیچرها شکسته می شود. برای هر ویژگی یک حلقه برنامه ریزی- طراحی- ساخت شکل می گیرد. به طور کلی تولید هر ویژگی نباید بیشتر از دو هفته طول بکشد.

خروجی توسعه ویژگی محور، سریع و موثر خواهد بود. FDD برای تیم های بزرگ مناسب است و اطلاعات از طریق مستندات دقیق منتقل می شود.

مزایای مدل FDD

• با شکست فعالیت های پیچیده به تسک های کوچک، کارایی افزایش می یابد.
• تیم های بزرگ را قادر می سازد تا به طور همزمان روی چندین فعالیت کار کنند.
• براساس الگوهای موفق و استانداردهای ازپیش تعریف شده کار می کند که موفقیت را قابل پیش بینی می سازد.

معایب مدل FDD

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

مدل توسعه سیستم های پویا

Dynamic Systems Model بسیاری از اصول خود را از از مدل توسعه سریع نرم افزار یا RAD به ارث برده و کارکرد آن را ارتقا داده است. هدف در مدل توسعه سیستم های پویا تحویل سریع و همسوسازی اهداف پروژه با نیاز کسب و کار است. این مدل شامل چهار حلقه تکرارشونده 1- امکان سنجی و مطالعه کسب و کار، 2- مدل عملیاتی، 3- طراحی و ساخت و 4- پیاده سازی است.

کاربر نهایی با کل فرایند کاملا درگیر شده و بازخوردها به کار گرفته می شود. مشارکت کاربر نهایی، ریسک گم شدن اهداف و الزامات پروژه در مسیر توسعه نرم افزار را به شدت کاهش می دهد. در این مدل برخلاف سایر مدل ها در فلسفه Agile، مستندات دقیقی تولید می شود.

مزایای توسعه سیستم های پویا

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

معایب توسعه سیستم های پویا

• روند اجرایی پرهزینه ای دارد و بودجه زیادی صرف آموزش کاربران و برنامه نویسان می شود.
• پیاده سازی این مدل برای تیم های کوچک بسیار وقت گیر خواهد بود
• مفهوم و همچنین پیاده سازی مدل بسیار پیچیده است.

استفاده از این مدل برای سازمان های کوچک قطعاً مقرون به صرفه نیست. اما می تواند برای سازمان های بزرگی که درگیر خط کشی ها و گلوگاه های کاری است، کمک کننده باشد. مدل؛ فرایندهای سفت و سخت را به بخش های کوچکتر تکرارپذیر تبدیل کرده و ارتباط بین تیم ها را ساده می کند.

3- متدولوژی های پیوسته:

این متدها بر کاهش وقفه بین فازهای مختلف تولید تمرکز دارند. اولویت در این رویکرد جلوگیری از اتلاف منابع و ارتقای کارایی در روند توسعه نرم افزار است.

کاربردی ترین مدل در این گروه، مدل توسعه ناب است که از سیستم توسعه محصول تویوتا الهام گرفته است.

مدل توسعه ناب

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

در Lean Development موظفند که گلوگاه ها را قبل از آنکه در روند کار اختلال ایجاد کند، شناسایی کنند. هدف ایجاد یک سیستم کارآمد است که بدون نقص کار کند. این مدل همچنین جایگاه ویژه ای برای افراد قائل است و ارتباطات را کلیدی برای تقویت همکاری تیمی می داند.

مزایای مدل توسعه ناب

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

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