فرایند توسعه نرم افزار به انگلیسی Software Development Process رو در این نوشته مورد بررسی قرار دادم. توضیح دادم که چرا باید یک فرایند برای توسعه نرم افزار داشته باشید و فرایند توسعه در صنعت نرم افزار چی هست و چی نیست. چه انتظاری باید از فرآیند داشته باشید و فرآیند چه کاری رو براتون انجام خواهد داد.
هر قطعه نرم افزاری خوب با یک برنامه و یک فرآیند روشن آغاز میشه. خوشبختانه، بسیاری از مدل های فرآیند توسعه نرم افزار وجود دارن که می‌تونید برای شروع پروژه بعدی خودتون انتخاب کنین. اما کدوم فرآیند توسعه نرم افزار برای شما مناسبه؟
مدل های فرایند توسعه نرم افزار با بیشترین استفاده
درباره SDLC به طور مفصل در نوشته جداگانه ای با عنوان چرخه حیات توسعه نرم افزار به انگلیسی Software Development Lifecycle صحبت کردم. درک تفاوت بین چرخه حیات و مدل فرایند توسعه نرم افزار برای فهم ادامه نوشته حیاتیه. در چرخه حیات شما تعدادی فعالیت دارید که باید انجام بشن. ولی چطوری؟ اول کدوم رو باید انجام بدید؟ با چه ترتیبی؟ آیا هیچدوم رو باید تکرار بکنید یا نه؟ اگه باید تکرار کنید، بعد از کدوم یکی تکرارش میکنید؟ پاسخ این سوالات در مدل فرایند توسعه نرم افزار نهفته است.
با گذشت سالهای زیاد، تعدادی مدل فرایند توسعه نرم افزار برای مواجهه با پروژه های بیشتر و پیچیده تر رسمیت یافتن. اما سوال مهم اینجاست:
باید از مدل فرایندی استفاده کنید که اهداف شما، اندازه پروژه ، اندازه تیم توسعه ، بودجه زمانی و ریالی پروژه و سایر فاکتورها رو به خوبی در نظر گرفته باشه. برای کمک به شما اینجا چند مدل فرآیند توسعه نرم افزار شناخته شده رو با جوانب مثبت و منفی هر کدوم لیست کردم.
مدل فرایند آبشاری Waterfall
مدل فرایند توسعه نرم افزار آبشاری Waterfall که بهش مدل فرایند خطی Linear یا مدل چرخه حیات کلاسیک هم میگن یکی از قدیمی ترین و سنتی ترین مدل های ساخت نرم افزار به حساب میاد. می‌تونید روش آبشاری رو به عنوان تکرار پشت سر هم مراحل SDLC در نظر بگیرید. در اکثر برنامه های کاربردی ، مراحل کمی با هم همپوشانی دارن و بازخورد و اطلاعات بین اونها منتقل میشه.
بعضی‌ها دوست دارن که به این مدل بگن فرایند برنامه محور چون برای اتمام یک پروژه از همون اول باید همه چیزهایی و کارهایی که باید انجام بشه رو برنامه ریزی کنید و از ترتیب و زمان بندی همه مراحل آگاه باشید. دلیل نام گذاری آبشار اینه که یک جریان یک طرفه از هر مرحله فقط به مرحله بعدی وجود داره.
مدل فرایند آبشاری چه فازهایی داره؟
- برنامه ریزی
- خواسته ها
- طراحی سیستم و نرم افزار
- پیاده سازی
- آزمون
- استقرار
- نگهداری و به روز رسانی
مدل فرایند آبشاری برای چه کسانی مناسبه؟
تیم هایی با ساختار صلب و غیر منعطف و نیاز جدی به ایجاد مستندات.
به دلیل ساختار صلب و زمان بندی غیر منعطف با برنامه ریزی اولیه ، مدل فرآیند توسعه نرم افزار آبشاری در شرایطی بهتر عمل می کند که اهداف، الزامات و پشته فناوری به انگلیسی Technology Stack در طی روند توسعه به طور اساسی تغییر نکنن.
در عمل، مدل فرایند آبشاری برای سازمانهای بزرگ مناسبتره چون قبل از شروع پروژه نیاز به کاغذ بازی و تهیه مستندات مدون و جامع در مورد کلیه خواسته ها و مشخصات اسکوپ پروژه دارن.
مدل فرایند آبشاری برای چه کسانی مناسب نیست:
اگه محصول جدیدی رو آزمایش می‌کنین یا به بازخورد کاربر نیاز دارین، یا می‌خواین در روند توسعه پویاتر باشین استفاده از مدل فرآیند آبشاری احتمالاً برای شما مناسب نیست.
این مدل با اینکه خیلی سر راست و ساده است ولی اشکال بزرگی داره و اون اینه که انعطاف پذیر نیست. مثلا شما نمی‌تونید کمینه محصول پذیرفنتی به انگلیسی Minimum Viable Product یا به اختصار MVP ها یا نمونه اولیه به انگلیسی Prototype رو ایجاد و آزمایش کنید و در طول راه توسعه نظر خودتون رو تغییر بدید. به همین دلیل تا زمانی که اسکوپ پروژه به دقت نوشته نشده باشه، ممکنه وارد یک مسیر اشتباه بشید و تا روز لانچ نهایی نرم افزار هم اطلاعی از این انحراف خطرناک نداشته باشید.
مدل فرایند توسعه نرم افزار چابک Agile و اسکرام Scrum
فرآیند توسعه نرم افزار Agile و محبوب ترین روش اون اسکرام Scrum یک رویکرد تکراری و پویا رو برای توسعه انتخاب میکنه.
بر خلاف جریان صلب و متوالی آبشاری در Agile تیم ها در چند اسپرینت به انگلیسی Sprint که هر کدوم از 2 هفته تا 2 ماه طول می‌کشه کار میکنن تا نرم افزار قابل استفاده رو برای بازخورد به مشتریان ارائه کنن.
حوزه اجایل Agile در مورد عکس العمل سریع ، انتشار مکرر نسخه های نرم افزار ، و پاسخ به نیازهای واقعی کاربران هست، حتی اگه بر خلاف مندرجات برنامه ریزی اولیه باشه. معنیش اینه که در فرایند چابک قبل از شروع کار به لیست کاملی از خواسته ها و یک SOW کامل احتیاج ندارید. شما اساساً با این درک که مسیر به تناوب تغییر خواهید کرد، در این راه قدم میذارید.
یک مثال ساده از فرایند چابک در عمل. فرض کنیم شما در حال ایجاد یک ویژگی جدید برای یکی از محصولات نرم افزاری تون هستید. این محصول میتونه دارای ویژگی های X ، Y و Z باشه. به جای گذراندن ماه ها برای ساختن یک محصول کامل و بی نقص، شما یک اسپرینت (۲ تا ۴ هفته) رو صرف ایجاد محصول با حداقل ویژگی‌های ممکن میکنید به شکلی که محصولی که تولید میکنید مفید و قابل استفاده باشه و سپس اون رو برای مشتری منتشر میکنید.
این کار اجازه میده تا حلقه های بازخورد محکم‌تری در طی مراحل توسعه نرم افزار وجود داشته باشه تا بتونید با نیازهای واقعی مشتری سازگار بشید و بهشون واکنش نشون بدید.
مدل فرایند چابک چه فازهایی داره؟
- لیست نیازمندی محصول Product Backlog
- لیست نیازمندی اسپرینت Sprint Backlog
- اسپرینت (طراحی و توسعه)
- انتشار یک نسخه عملیاتی از نرم افزار
- بازخورد و اعتبار سنجی (افزودن به بک لاگ)
- برنامه ریزی اسپرینت بعدی
مدل فرایند چابک برای چه کسانی مناسبه؟
تیم های پویا که به روزرسانی مداوم محصولات رو انجام میدن.
فرایند توسعه نرم افزار چابک Agile به لطف ماهیت پویا و کاربر محورش، مورد حمایت اکثر شرکت‌های نوپا و فناوری محور قرار گرفته تا محصولات جدید رو آزمایش و یا به روز رسانی های مداوم رو برای محصولات در طولانی مدت انجام بدن.
مدل فرایند چابک برای چه کسانی مناسب نیست؟
تیم با بودجه و جدول زمانی بسیار محدود.
طبیعت پویای مدل فرایند چابک Agile به این معنیه که پروژه ها ممکنه به راحتی از زمان یا بودجه اولیه شون تجاوز کنن. ممکنه با معماری موجود به مشکل بخورن یا از کنترل مدیر خارج بشن. معنیش اینه که مدل فرایند توسعه نرم افزار چابک برای تیم هایی که ریسک پذیر نیستن یا مشکل کمبود منابع دارن گزینه مناسبی نیست.
در این نوع مدل فرایند باید اعضای تیم به درک کاملی از فرآیند چابک رسیده باشن و شخصی با عنوان استاد اسکرام یا مدیر اسکرام به انگلیسی Scrum Master هم در تیم داشته باشین تا مطمئن بشین که نقاط عطف به انگلیسی Milestone به درستی سپری میشن و پروژه متوقف نمیشه.
مدل فرایند توسعه نرم افزار افزایشی و تکاملی
مدل فرآیند توسعه نرم افزار افزایشی و مدل فرایند توسعه نرم افزار تکراری یک حد واسط بین ساختار صلب و برنامه ریزی مقدماتی مدل فرآیند آبشاری و انعطاف پذیری مدل فرایند توسعه نرم افزار چابک Agile به حساب میان.
با اینکه هر دوی این مدل ها ایده ایجاد قطعات کوچک نرم افزار و ارائه به منظور دریافت بازخورد کاربر رو دنبال میکنن، اما چیزی در هر نسخه ایجاد میکنید در این دو مدل متفاوته.
در مدل فرآیند توسعه نرم افزار افزایشی ، هر افزایش محصول ، فرم ساده ای از عملکرد یا ویژگی جدید رو به نرم افزار اضافه میکنه. مثلا فرض کنید که با یک برنامه ریزی کلی شروع میکنیم و ساخت یک MVP که فقط قابلیت های اصلی رو داره در افزایش اول ایجاد میشه. در افزایش های بعدی، از کاربر بازخورد میگیریم و ویژگی ها و قابلیت های بیشتری بهش اضافه میکنیم.
در مدل فرآیند توسعه نرم افزار تکاملی ، هر نسخه که منتشر می کنید همه ویژگی های برنامه ریزی شده لازم رو داره ولی ناقص و اولیه. ویژگی ها همه از ابتدا وجود دارن ولی به مرور تکمیل میشن.
مدل فرایند افزایشی چه فازهایی داره؟
- برنامه ریزی افزایش
- مشخصه فنی Specification
- توسعه Development
- اعتبار سنجی Validation
- تکرار برای هر نسخه
مدل فرایند تکاملی چه فازهایی داره؟
- تحلیل Analysis
- طراحی Design
- توسعه Development
- تست Testing
مدل فرایند افزایشی و تکاملی برای چه کسانی مناسب هستن؟
تیم هایی که نیازمندی های شفافی در دست دارند ولی به دنبال انعطاف بیشتری نسبت به مدل فرآیند آبشاری هستن.
هر دوی اینها درجات مشخصی از انعطاف پذیری رو به فرایند توسعه نرم افزار شما میدن بدون اینکه یک طرح و برنامه اولیه رو به کلی انکار کنن. این دو مدل فرایند برای پروژه های بزرگ با اسکوپ و دامنه مشخص و تعریف شده (یا تیم هایی با تحمل ریسک کمتر) ایده آل به نظر می‌رسه.
با مدل فرآیند افزایشی در مورد ویژگی اصلی برنامه خیلی زود بازخورد به دست میارید. یک فیدبک سریع از نرم افزار برای مشخص شدن سمت و سوی کسب و کار حیاتیه.
در مقابل مدل فرایند تکاملی از همون اول یه نگاه و درک کلی از محصول کامل نهایی ارائه میده که میتونه کمک کنه بازخورد دقیق تری از کاربرا دریافت کنید.
در هر دو مورد ، شما در حال صحبت کردن با کاربران در مورد آنچه در واقع می خواهند ، صحبت می کند که می تواند باعث صرفه جویی در وقت ، پول و سردرد شما شود تا اینکه در چرخه توسعه منتظر بمانید.
مدل فرایند افزایشی و تکاملی برای چه کسانی مناسب نیستن؟
تیم هایی که یک برنامه فناوری بلند مدت واضح ندارن.
تلاش برای اضافه کردن ساختار به یک رویکرد انعطاف پذیر مسائل خاص خودش رو داره. ممکنه اهداف، رویه ها یا فناوری های شرکت شما با گذشت زمان تغییر کنن و این باعث بشه که تکرارهای قبلی بی فایده بشن و چاره ای نداشته باشین جز اینکه اونها رو دور بریزین.
هر دو مدل فرایند و خصوصاً رویکرد تکاملی نیاز به برنامه ریزی سنگین و معماری اولیه محکم دارن. این مدل ها برای پروژه های کوچیک یا تیم هایی که هنوز در حال شکل گیری هستن و در تلاشن تا بازاری برای محصول شون پیدا کنن ایده آل نیستن.
تفاوت بین افزایشی و تکاملی و چابک چیست؟
ممکنه در مورد تفاوت بین مدل فرآیند توسعه نرم افزار افزایشی و تکاملی و چابک گیج شده باشید. با اینکه خیلی به هم شبیه هستن ولی چند تفاوت اساسی بین شون وجود داره.
- در مدل فرایند افزایشی ، در هر افزایش یک ویژگی کامل رو ایجاد میکنید
- در مدل فرایند تکاملی ، در هر تکرار ، بخش کوچکی از همه ویژگی ها رو می‌سازید
- در مدل فرایند چابک جنبه های هر دو رویکرد رو با هم ترکیب میکنید. در هر اسپرینت یک بخش کوچک از هر ویژگی رو می‌سازید.
مدل فرایند توسعه نرم افزار وی V شکل V-Shaped
مدل فرایند توسعه نرم افزار V شکل یک برداشت از مدل فرایند سنتی آبشاری هست که بزرگترین عیب اون رو درست میکنه: عدم انجام آزمایش به موقع.
به جای انجام مراحل کار توسعه به صورت متوالی و موکول کردن آزمایش به پایان کار، هر مرحله از فرآیند V شکل با یک مرحله سخت گیرانه اعتبار سنجی به انگلیسی Validation و صحت سنجی و تأیید به انگلیسی Verification دنبال میشه. در اینجا خواسته ها قبل از ادامه کار تست میشن.
مدل فرایند وی شکل چه فازهایی داره؟
- خواسته ها و نیازمندی های نرم افزار Requirements
- مشخصه فنی نرم افزار Specifications
- طراحی سطح بالا High-Level Design
- طراحی سطح پایین Low-Level Design
- توسعه Development
- آزمون واحد Unit Testing
- تست ادغام Integration Testing
- تست سیستم System Testing
- تست قبولی Acceptance Testing
مدل فرایند وی شکل برای چه کسانی مناسبه؟
تیم هایی که روی پروژه های کوچیک با محدوده و اسکوپ مشخص کار میکنن.
اگه یک پروژه کوچیک با نیازمندی ها و دامنه و اسکوپ نسبتاً واضح (و پایدار) داشته باشید، مدل فرایند توسعه نرم افزار V شکل عالیه. به جای اینکه با پیروی از یک برنامه اولیه ریسک پیدا کردن مشکلات در انتهای راه رو قبول کنید، فرصت کافی بهتون میده تا در طول مسیر با انجام تست و آزمون از کیفیت نرم افزار مطمئن بشید.
مدل فرایند توسعه نرم افزار وی شکل برای چه کسانی مناسب نیست؟
تیمهایی که می‌خوان انعطاف پذیری بیشتری داشته باشن و به دنبال ورودی و بازخورد کاربران در اولین زمان ممکن هستن.
به دلیل پیروی از یک ساختار صلب و برنامه آزمایش فشرده و غیر منعطف کنترل کمی روی فرایند وجود داره. همچنین از اونجا که ورودی و بازخورد زودهنگامی از طرف کاربران دریافت نمی‌کنید هنوز خطر ساختن نرم افزار اشتباهی وجود داره.
ضمنا اگه پروژه ساده و کوچیک نباشه، ایجاد یک برنامه توسعه و آزمون جامع از قبل غیرممکنه.
مدل فرایند توسعه نرم افزار حلزونی Spiral
مدل فرایند توسعه نرم افزار پیچشی یا مدل فرایند توسعه نرم افزار حلزونی به انگلیسی Spiral از ترکیب این دو به وجود اومده:
- تمرکز مدل فرآیند توسعه نرم افزار V شکل بر آزمایش و ارزیابی ریسک
- ماهیت افزایشی مدل های فرایند توسعه نرم افزار تکاملی و افزایشی و چابک
وقتی برنامه ریزی مشخصی برای یک تکرار یا نقطه عطف خاص در نظر گرفته شده باشه، مرحله بعدی انجام یک تحلیل ریسک به انگلیسی Risk Analysis برای شناسایی خطاها یا نواحی پر ریسک خواهد بود.
فرض کنید برنامه ریزی یک تکرار اینطوریه که شما قراره یک ویژگی خاص به انتشار بعدی اضافه کنید، ولی مشتری هنوز اون رو اعتبارسنجی نکرده. به جای اینکه این ویژگی رو فقط به نقطه عطف فعلی اضافه کنید، ممکنه یک نمونه اولیه و Prototype رو قبل از فرآیند توسعه برای مشتری ارسال کنید. بعد از اتمام هر نقطه عطف ، دامنه و اسکوپ روی یک مارپیچ بزرگتر میشه و شما با برنامه ریزی و ارزیابی ریسک بعدی ادامه می‌دید.
مدل فرایند توسعه نرم افزار حلزونی چه فازهایی داره؟
- برنامه ریزی Planning
- ارزیابی ریسک Risk Assessment
- توسعه و اعتبار سنجی Development and Validation
- ارزیابی نتایج و برنامه ریزی “حلقه” بعدی Evaluation & Plan Next Loop
مدل فرایند حلزونی برای چه کسانی مناسبه؟
تیم های ریسک گریز که روی پروژه های بزرگ کار میکنن.
مشخصه که هدف اصلی چنین مدل فرایندی کاهش ریسک هست. اگر در حال کار روی یک پروژه بزرگ یا مهم هستید که به سطح بالایی از مستندات و اعتبارسنجی نیاز داره، پیروی از این مدل فرآیند توسعه نرم افزار معقول به نظر می‌رسه.
همچنین اگر مشتری کاملاً از خواسته های نرم افزار مطمئن نباشه و انتظار اعمال ویرایش های عمده در طول فرایند توسعه داشته باشه، این مدل مناسبه.
مدل فرایند حلزونی برای چه کسانی مناسب نیست؟
بیشتر افراد و تیم ها.
مدل حلزونی در تئوری خارق العاده است. ولی چنین رویکر حساب شده‌ای به دلیل سربار زمان و هزینه های زیادش به ندرت در عمل استفاده میشه.
از این مدل فرایند توسعه نرم افزار بیشتر به عنوان نمونه ای برای نقد انواع رویکرد تکراری و افزایشی استفاده میشه.
