ورود و ثبت نام
SDLC چیست؟
مفهوم Software Development Life Cycle (SDLC) و یا به عبارتی دیگر چرخه عمر توسعه نرم افزار در دهه 60 قرن بیستم میلادی با مقصود حل مشکلات کمپانی های بزرگی که متحمل هزینه های سنگین به واسطه گران قیمت بودن تکنولوژی های روز خود بودند مطرح شد. شرکت های بزرگ در آن زمان درحال دست و پنچه نرم کردن با مشکلات فراوان و گران در پروژه های عظیم خود بودند. با ظهور SDLC مقدار زیادی از این شکاف ها به همراه عبارت های مانند انعطاف و چابگی تواستند امکان غلبه کردن بر اغلت معضلات را فراهم کرد. توسعه نرم افزار به ترتیب برنامه ریزی، تحلیل و طراحی، پیاده سازی، تست و نگهداری ارکان و پایه های اصلی این مفهوم می باشند. تکرار این موارد در یک چرخه حیات موجب کاهش هزینه های مالی، زمانی و تولید در بحث توسعه نرم افزار و سیستم می شوند.
مفهوم و پیاده سازی SDLC داری متولوژی های مختلفی می باشد. انواع مدل های از جمله Waterfall, V-Shape, RAD, Agile و حتی DevOps که هر یک دارای مکانیزم خاص خود می باشند که، در بازه های زمانی مختلفی معرفی و مورد استفاده قرار گرفته اند.
البته مدل هایی که در این مقاله آورده شده در بر گیرنده تمام مدل های معرفی شده نیستند ولی هر کدام به تنهایی برای خود هویت مستقل همراه با مزایا و معایب مختص خود میباشند، و هر کدام را به صورت مختصر مورد بررسی قرار خواهیم داد.
مدل Waterfall و یا آبشاری یکی از عضو های اولیه این مفهوم حیات بخش می باشد. تیم توسعه در قطعه زمان های مشخص تنها این امکان را دارند تا تمرکز خود را بر روی یک مرحله از این مدل قرار دهند، و در نهایت پس از پایان یک مرحله به مرحله آتی گذر خواهند کرد.
میتوان گفت پس از گذر از یک توفقگاه و بستن آن، شرایط برگشت به آن مرحله بسیار پرهزینه و دشوار خواهد بود. که این امر در پروژه های وسیع و عظیم میتواند هزینه های زمانی تحمل ناپذیری را به پروژه تحمیل کند. بعلاوه مدل Waterfall دارای مرتبه بازخورد و یا Feedback نمی باشد و درنهایت با درنظر گرفتن این موارد میتوان گفت این مدل نمی تواند چابک باشد و به رویداد های پیش آمده واکنشی مناسبی نشان دهد.
به صورت مثال:
اگر یک قانون مالیاتی جدیدی اجرایی شود کمپانی های اقصادی نیاز دارند به خود را با این قوانین خود را همسو کنند و اگر مدل آنها چابک نباشد می تواند پایان کار آن کسب و کار باشد.
مدل V-Shape یک مدل توسعه یافته از پدر خود یعنی مدل Waterfall می باشد، ولی قابل ذکر است این مدل دقیقا در نقطه تضاد مدل آبشاری عمل میکند. به این معنا که برای هر مرحله یک مرحله تست و آزمایش نظیرهم در نظر گرفته شده است. در نهایت میتوان گفت این مدل سعی کرده است Business requirement verification به صورت کامل پوشش دهد.
از معایب این مدل بالا رفتن زمان تحویل پروژه و شفاف نبودن مسیر اتمام پروژه به دلیل تمرکز بیش از حد به مراحل هم نظیر تست می باشد. همچنین عدم امکان سازمان دهی و حفظ نگهداری این مدل یکی دیگر از کاستی های این مدل محسوب می شود.
کلمه RAD مخفف Rapid Application Development می باشد. Rapid application development که آن به صورت کوتاه RAD می گویند یک متدولوژی توسعه نرم‌افزار است که از حداقل برنامه ریزی استفاده می کند و سعی در نمونه سازی سریع نرم افزار دارد. یک نمونه اولیه و یا prototype یک مدل عملیاتی از نرم افزار است که عملیات تقریباً یکسانی را نسبت به محصول نهایی خواهد داشت. در مدل RAD ماژول های عملیاتی به صورت موازی توسعه داده می شوند و سپس برای تکمیل کردن محصول نهایی و تحویل آن به مشتری با یکدیگر یکپارچه و یا اصطلاحاً integrate می گردند. از آنجایی که هیچ برنامه‌ریزی دقیقی وجود ندارد، در نظر گرفتن و لحاظ کردن تغییرات در روند توسعه نرم افزار ساده تر است.
این ساختار نمیتواند به صورت Scrum (Scrum یکی از ابزار های Agile میباشد و در ادامه به آن خواهیم پرداخت) پیاده سازی شود، و باید در بازه زمانی کوتاهی به نتیجه برسد. بهتر است بگوییم این مدل use case یا موارد استفاده خاص خود را پوشش می دهد.
به صورت کلی Scrum توسط یک Scrum master مدیریت می شود. Scrum master پس از دریافت تسک های مختلف با رایزنی با باقی افراد تیم و بستن یک قرار داد زمان بندی شده تسک را داخل بازه های زمانی مشخص تقسیم می کند. کوچکترین واحد زمانی معمولا در Scrum یک تا دو هفته می باشد و به چهار هفته یک Spring می گویند.
مفهوم Kanban اشاره به تقسیم بندی کارها بر روی یک Dock یا Board دارد. به گونه ای که این Board دارای ستون های مختلفی می باشد و با توجه به شرایط پیشرفت تسک ها آنها را دربین ستون ها میتوان جابجا کرد. یکی از معایب Kanban در رابطه با تسک های بیرون تیمی و مربوط به پروژه های بزرگتر میباشد و همچنین این فرایند تحمل پذیری کمی بر روی Ad hack های که در طول پروژه واگذار میشود دارد. انتخاب مدل به Business requirement specification، به نوعی فقط هدف و پارامتر های مورد نیاز هر پروژه در بر خواهد داشت.
جواب بله میباشد، یکی دیگر از تعریف های DevOps میتواند DevOps SDLC باشد. تمام موارد گفته شده در متودولوژی های قبلی همگی در DevOps قرار دارد مضاف بر اینکه، صورت انجام تمام پروژه به شدت افزایش می یابد و همچنین تکرار های پایای این فرهنگ شرایط Plan, build, test, deploy, monitoring را در یک چرخه حیات ناتمام قرار میدهد. یا به عبارتی حرفه ای تر CICD به صورت کاملا چابک انجام می شود.
برای درک بیشتر DevOps میتوانیم آن را با دو نمونه از موارد یاد شده در زمینه ای چابکی در شکل زیر مورد بررسی قرار داد. به نوعی میتوانیم به این دید نگاه توجه داشته باشیم که هر قسمت از فرایند برای خود دارای موارد design, code, test و deploy می باشد.
نمی توان صفت های بد و خوب را به هیچکدام از مدل های SDLC به صورت کلی نسبت داد. هر کدام از این متولوژی ها use case های خاص خود را دارا هستند. به عبارتی دیگر برای کاربرد خاصی مورد استفاده قرار می گیرند. برخی از مدل های که مورد بررسی قرار گرفت دارای
Wall of confusion می باشد، این مفهوم اشاره به ایجاد دیواری دارد که هیچکدام از متخصصان توسعه و سیستم Admin ها از شرایط یک دیگر با خبر نیستند. ایجاد DevOps حکایت از وجود یک تخصص در لبه این تناقض دارد تا بتوانند از هر دو سوی این دیوار راه حل های کاربردی و گفتمانی سالم را استخراج کند.
در بسیاری از پروژه های مطرح شده این امکان موجود میباشد تا از SDLC DevOps استفاده کرد، به نوعی که ویژگی های مثبت این SDLC میتواند در همه موارد کاربردی و چابک باشد.
پس نتیجه میگیریم DevOps خود به تنهایی میتواند یک SDLC نیرومند و چابک نیز باشد.
https://www.wrike.com/scrum-guide/scrum-sprints/
https://aws.amazon.com/what-is/sdlc/
https://aristeksystems.com/blog/sdlc-overview/
https://www.umsl.edu/~hugheyd/is6840/waterfall.html
http://tryqa.com/what-is-v-model-advantages-disadvantages-and-when-to-use-it/
https://www.geeksforgeeks.org/software-engineering-rapid-application-development-model-rad/
