متدولوژی به مجموعهای از روشها، اصول، قواعد و مراحل منظم گفته میشود که برای تحلیل، طراحی، پیادهسازی و نگهداری یک سیستم نرمافزاری به کار میرود.
به عبارت ساده، متدولوژی یک نقشه راه یا دستورالعمل گامبهگام است که مشخص میکند:
متدولوژیهای تحلیل و طراحی سیستم بر اساس میزان انعطافپذیری، تمرکز بر ریسک، یا سرعت ساخت نمونه اولیه به چهار دسته اصلی تقسیم میشوند:
همه چیز از قبل برنامهریزی میشود. تغییرات دشوار است.
مثال: آبشاری (Waterfall)
تغییرات در طول پروژه پذیرفته میشود. تحویل تدریجی و بازخورد مداوم.
مثال: اسکرام(scrum)
اصلیترین فاکتور تصمیمگیری در تمام مراحل پروژه، شناسایی، تحلیل و کاهش ریسکها است.
مثال: مارپیچی (Spiral)
به جای اینکه از اول تمام نیازها را مستند کنید، سریعاً یک نمونه اولیه (ماکت) از سیستم میسازید.
مثال: نمونهسازی سریع(Rapid Prototyping)
حالا هر روش را با یک مثال ساده و مشخص توضیح میدهیم.
قدیمیترین و ساختارمندترین متدولوژی. مراحل به صورت خطی و پشت سر هم انجام میشوند. هر مرحله باید کاملاً تمام شود تا مرحله بعد آغاز گردد.
تحلیلگر سیستم با مدیر کتابخانه چند جلسه میگذارد و هر نیاز را با جزئیات مکتوب میکند.
تیم طراحی بر اساس سند نیازها، موارد زیر را آماده میکن.
برنامهنویسان طبق مستند طراحی شروع به کدنویسی میکنند.
یک تیم تستر مستقل، نرمافزار را از زوایای مختلف تست میکند. باگها پیدا شده و به برنامهنویسان برگردانده میشوند. بعد از رفع باگها، تست مجدد انجام میشود.
پس از استقرار، ممکن است مشکلات کوچکی پیدا شود (مثل یک باگ نادر). تیم پشتیبانی آنها را رفع میکند.
برای پروژههای کوچک و با نیازهای کاملاً مشخص و ثابت و تیمهای کمتجربه که به ساختار خطی نیاز دارند.
یک مدل تکرارشونده (Iterative) که بر مدیریت ریسک تمرکز دارد. پروژه در چندین دور (مارپیچ) انجام میشود و هر دور شامل چهار مرحله است:
تعیین اهداف برای آن دور
شناسایی ریسکها
توسعه نمونه اولیه برای کاهش ریسکها
برنامهریزی دور بعد بر اساس بازخورد
توضیح کارکرد: هدف نمایش ضربان قلب و فشار خون.
ریسک: ممکن است دادهها با تأخیر از دستگاهها بیایند.
توضیح کارکرد: هدف اضافه کردن هشدار خودکار.
ریسک: هشدارهای کاذب باعث سردرگمی پرستاران میشود. نمونه اولیه هشدارها را با آستانههای مختلف تست میکند
توضیح کارکرد: هدف اتصال به سیستم نسخهنویزی.
ریسک: امنیت اطلاعات بیماران. نمونه اولیه رمزنگاری تست میشود. هر دور ریسکها را خنثی کرده و سیستم کاملتر میشود.
پروژههای بزرگ و حیاتی که شکست در آنها هزینههای جانی یا مالی هنگفت دارد. جایی که ریسکها در ابتدا قابل شناسایی کامل نیستند
اسکرام یک چارچوب چابک است که کار را به دورههای زمانی کوتاه و منظم به نام اسپرینت (معمولاً ۲ تا ۴ هفته) تقسیم میکند.
1. مالک محصول لیست اولویتدار از نیازها را تهیه میکند.
2. در جلسه برنامهریزی اسپرینت، تیم انتخاب میکند که در اسپرینت بعدی کدام موارد را انجام دهد.
3. اسپرینت به مدت ۲-۴ هفته اجرا میشود. هر روز یک جلسه روزانه ۱۵ دقیقهای (Daily Scrum) برگزار میشود.
4. در پایان اسپرینت، جلسه بازبینی با مشتری برگزار میشود تا خروجی نشان داده شود.
5. جلسه بازاندیشی برای بهبود فرآیند تیم برگزار میشود.
پروژههایی که نیازها مدام تغییر میکنند. جایی که مشتری میتواند به طور مداوم بازخورد دهد
ابتدا یک نمونه اولیه (ماکت) از سیستم ساخته میشود که ظاهر و تعاملات اولیه را نشان میدهد. مشتری با آن کار میکند و بازخورد میدهد. پس از رفع ابهامات، نمونه دور ریخته شده و سیستم واقعی از صفر ساخته میشود.
1. نیازهای اولیه (حتی ناقص) جمعآوری میشود.
2. ساخت سریع نمونه اولیه با ابزارهای طراحی
3. ارائه به مشتری و دریافت بازخورد.
4. اصلاح نمونه بر اساس بازخورد
5. ساخت سیستم نهایی با استفاده از متدولوژی دیگر بر اساس نمونه تأیید شده.
هیچ متدولوژی بهترین مطلق نیست. انتخاب درست، وابسته به نوع پروژه، تیم، بودجه، زمان و فرهنگ سازمانی است.
در دنیای حرفهای امروز، متدولوژیهای چابک (به ویژه اسکرام) محبوبیت بیشتری دارند، اما پروژههای زیرساختی و دولتی همچنان از آبشاری استفاده میکنند.
مهارت یک تحلیلگر سیستم در این است که بتواند با توجه به شرایط، مناسبترین متدولوژی را انتخاب کرده یا ترکیبی از آنها را طراحی کند.
پیشنهاد میشود در پروژههای واقعی، از ترکیب نمونهسازی اولیه + اسکرام استفاده کنید: اول با نمونهسازی نیازها را شفاف کنید، سپس با اسکرام توسعه دهید.