رویکردهای مدرن برای توسعه نرم افزار شامل مجموعه متنوعی از فرآیندها است. درک این فرآیندها اولین قدم مهم است با توسعه نرم افزار شروع کنید. آنها راهنمایی دقیق و قابل تکرار برای اجرای یک پروژه نرم افزاری و حفظ آن پس از اجرا ارائه می کنند.
برای درک هفت مرحله از SDLCتوسعه دهندگان باید درک محکمی از آنچه هر مرحله مستلزم آن است، چرایی اهمیت آن و معیارهای حرکت به مرحله بعدی داشته باشند.
7 مرحله SDLC
تنوع کمی در تعداد مراحل وجود دارد. برخی استدلال می کنند که به سادگی وجود دارد پنج یا شش برای مثال مراحل اساسی در SDLC. همچنین اصطلاحات مختلفی در مورد اینکه هر مرحله چه نامیده می شود وجود دارد.
با این حال، توافق عمومی این است که هفت مرحله اصلی در SDLC وجود دارد.
مرحله 1. برنامه ریزی
مرحله اول SDLC در فرآیند برنامه ریزی است. هدف این مرحله ایجاد یک برنامه اساسی از آنچه یک برنامه کاربردی باید بر اساس الزامات تجاری انجام دهد، است.
تیم های توسعه در این مرحله برنامه های سطح بالا را تدوین می کنند. آنها دقیقاً نحوه پیاده سازی ویژگی ها یا عملکردهای خاص یا زبان های برنامه نویسی را مشخص نمی کنند.
در عوض، تیم‌ها اهداف اصلی را برای ویژگی‌های برنامه تعیین می‌کنند و چالش‌های تجاری را که ویژگی‌ها در آن مرحله برطرف می‌کنند، ترسیم می‌کنند. همچنین برنامه ریزی زمانی برای شناسایی اهداف غیرواقعی است که باید کنار گذاشته شوند. به عنوان مثال، برنامه ای را در نظر بگیرید که به دلیل منابع ناکافی نمی تواند نیازهای تجاری را برآورده کند. تیم‌های توسعه باید این موضوع را در این مرحله به اشتراک بگذارند، نه اینکه در مرحله بعدی وقت خود را در تلاش برای پیاده‌سازی ویژگی‌ای که در نهایت رها می‌کنند، تلف کنند.
از آنجایی که همسویی اهداف فنی با اولویت‌های کسب‌وکار تمرکز اصلی مرحله برنامه‌ریزی است، توانایی توسعه‌دهندگان ارتباط موثر با ذینفعان کسب و کار در طول برنامه ریزی ضروری است.
هنگامی که تیم های توسعه درک روشنی از هدف برنامه و ویژگی های مورد نیاز برای خدمت به آن هدف داشته باشند، مرحله برنامه ریزی کامل می شود.
مرحله 2. تجزیه و تحلیل
مرحله تجزیه و تحلیل SDLC جایی است که تیم های توسعه برنامه ها و اهداف سطح بالا را به ایده های عملی تبدیل می کنند. برای انجام این کار، تیم‌ها یک تحلیل فنی از طرح‌هایی که در مرحله قبل توسعه داده‌اند انجام می‌دهند و نحوه اجرای بهترین آنها را تعیین می‌کنند.
به عنوان مثال، اگر هدف یک تیم اولویت بندی امنیت برنامه باشد، از مرحله تجزیه و تحلیل استفاده می کند تا تصمیم بگیرد که کدام معماری برنامه و زبان برنامه نویسی به بهترین وجه آن هدف را برآورده می کند. تیم‌ها همچنین می‌توانند درباره ویژگی‌هایی که قصد پیاده‌سازی آنها را دارند تحقیق کنند و بر اساس آن تحلیل تصمیم بگیرند که آیا هر ویژگی را به‌عنوان خاص خود پیاده‌سازی کنند یا خیر میکروسرویس یا از معماری یکپارچه استفاده کنید.
هدف نهایی مرحله تحلیل، داشتن یک طرح فنی است که تیم ها بتوانند اجرای آن را آغاز کنند. جزئیات خط به خط در مورد نحوه استقرار کد ضروری نیست، اما تیم ها باید دقیقا بدانند که از چه ابزارها و فرآیندهایی در هنگام ساخت برنامه استفاده خواهند کرد.
مرحله 3. طراحی
مرحله طراحی بر تصمیم گیری درباره نحوه رفتار و ظاهر برنامه از دیدگاه کاربر تمرکز دارد. به عنوان مثال، اگر برنامه دارای رابط کاربری گرافیکی باشد، تیم ها باید شکل ظاهری آن رابط را در این مرحله ترسیم کنند. تیم‌ها همچنین باید بررسی کنند که آیا کاربران برای استفاده از برنامه باید حساب‌هایی را ثبت کنند یا خیر، و در این صورت، آیا انواع مختلفی از حساب‌ها مانند حساب‌های سرپرست و غیرمجاز برای کاربران مختلف وجود دارد یا خیر.
مرحله طراحی بر اساس مشخصات فنی برای برنامه ای است که تیم ها در مرحله تجزیه و تحلیل ایجاد کردند. در واقع، برخی از توصیفات مراحل SDLC، تجزیه و تحلیل و طراحی را به عنوان یک فاز در نظر می گیرند. با این حال، از آنجایی که تجزیه و تحلیل بیشتر بر الزامات فنی تمرکز دارد در حالی که طراحی روی آن تمرکز دارد UXتوسعه دهندگان باید این فرآیندها را به دو مرحله تقسیم کنند.
مرحله طراحی زمانی کامل می شود که تیم ها درک روشنی از نحوه تعامل کاربران با برنامه داشته باشند.
مرحله 4. اجرا
مرحله اجرا – همچنین گاهی اوقات نامیده می شود توسعه یا مرحله کدگذاری — جایی است که تیم ها کد واقعی را می نویسند. اگر کدهای پیچیده زیادی برای نوشتن وجود داشته باشد، این می تواند طولانی ترین مرحله SDLC باشد. اما همچنین می تواند نسبتاً کوتاه باشد، به خصوص اگر تیم ها با استفاده از کد، استقرار کد را تسریع کنند متدولوژی هایی مانند کم کد/بدون کد یا توسعه با کمک هوش مصنوعی.
در هر صورت، ایجاد فرآیندهای واضح برای مدیریت کد در زمانی که توسعه دهندگان آن را در حین استقرار می نویسند، مهم است، به خصوص اگر چندین توسعه دهنده به طور همزمان کار می کنند. تیم ها اغلب از الف استفاده می کنند CI سروری که کدهای جدید نوشته شده را در یک پایگاه کد مشترک ادغام می کند و کمک می کند تا اطمینان حاصل شود که کد مستقر شده توسط یک توسعه دهنده با کدهای نوشته شده توسط دیگران تضاد ندارد.
علاوه بر این، تیم ها باید انتظارات روشنی در مورد سبک کدنویسی و قراردادها داشته باشند تا اطمینان حاصل کنند که همه کدها سازگار هستند. همچنین توانایی توسعه‌دهندگان را برای حفظ یا به‌روزرسانی کدهایی که خودشان ننوشته‌اند، بهبود می‌بخشد، که اگر تیم‌ها برنامه‌ریزی کنند تا در طول سال‌هایی از برنامه استفاده کنند که در طی آن توسعه‌دهندگان اصلی ممکن است سازمان را ترک کنند، توجه مهمی است.
پیاده سازی زمانی کامل می شود که تیم ها تمام کدهای لازم برای دستیابی به عملکرد مورد نظر برنامه را نوشته باشند. با این حال، توجه داشته باشید که تیم‌ها ممکن است بر اساس نتایج آزمایش‌های انجام‌شده در مرحله بعد، نیاز داشته باشند به عقب برگردند و بعداً کدی را اصلاح کنند.
برای آزمایش موثر در مقیاس… تیم ها باید تا حد امکان تست های زیادی را با استفاده از چارچوب های اتوماسیون آزمایشی مانند سلنیوم و خیار خودکار کنند.
مرحله 5. آزمایش
پس از اینکه تیم ها کد نوشتند، آماده آزمایش آن هستند. تست نرم افزار ارزیابی می کند که یک برنامه کاربردی چقدر به اهدافی مانند موارد زیر دست پیدا می کند:
بهره وریاین بدان معناست که برنامه چقدر پاسخگو است.
بارگذاری تاکه به توانایی برنامه برای کار در طول نوسانات تقاضا اشاره دارد.
امنیتکه شامل شناسایی آسیب پذیری های امنیتی است که ممکن است در برنامه وجود داشته باشد.
قابلیت استفادهکه تضمین می کند که برنامه یک UX قابل قبول ارائه می دهد.
تیم ها باید تست هایی را طراحی کنند که با اهداف تعیین شده در سه مرحله اول SDLC سازگار باشد. پس از طراحی تست ها، تیم ها باید تست ها را اجرا کنند و نتایجی را که انتظارات را برآورده نمی کند شناسایی کنند. اگر برنامه‌ای در تمام تست‌ها شکست بخورد، ممکن است تیم‌ها برای رفع مشکل نیاز به به‌روزرسانی بخشی از کدهای مرحله قبل داشته باشند و سپس دوباره آزمایش‌ها را اجرا کنند.
تیم ها می توانند نرم افزار را به صورت دستی تست کنند. برای مثال، تیم‌ها می‌توانند تست‌های عملکرد دستی را با بررسی سرعت پاسخ یک برنامه کاربردی به یک درخواست داده شده انجام دهند. با این حال، برای آزمایش مؤثر در مقیاس، تیم‌ها باید تا حد امکان آزمایش را با استفاده از خودکار انجام دهند تست چارچوب های اتوماسیون مانند سلنیوم و خیار
هنگامی که برنامه همه تست ها را با موفقیت پشت سر گذاشت، مرحله آزمایش کامل می شود.
مرحله 6. استقرار
استقرار مرحله ای است که در آن برنامه به یک محیط تولید منتقل می شود که در آن در دسترس کاربران نهایی باشد.
اگر برنامه با استفاده از مدل SaaS میزبانی شود، تیم ها برنامه را در محیط میزبانی تولید مستقر می کنند و سپس فایروال های شبکه یا پیکربندی می شوند. متعادل کننده های بار به طوری که تمام درخواست های برنامه به این محیط هدایت می شود.
اگر برنامه به صورت محلی بر روی دستگاه‌های کاربران اجرا شود، استقرار شامل بسته‌بندی آن و توزیع بسته‌ها به کاربران از طریق کانال‌هایی مانند فروشگاه برنامه است که در آن آنها می‌توانند برنامه‌ها را جستجو و دانلود کنند.
برای کاهش خطر فشار برنامه های کاربردی با خطاهای تولید، تیم ها باید روش هایی مانند قرارگیری آبی/سبزکه به حرکت به نسخه جدید یک برنامه به صورت تدریجی، سیستماتیک و انتشار قناری کمک می‌کند، که نسخه‌های جدید یک برنامه را قبل از دیگران به برخی از کاربران می‌فرستد تا باگ‌ها را قبل از اینکه بر کل پایگاه کاربر تأثیر بگذارند شناسایی کنند.
برنامه های کاربردی کانتینری نیز می توانند به کاهش خطرات استقرار کمک کنند. کانتینرها بدون توجه به جایی که مستقر شده اند، محیط های میزبانی تقریباً یکسانی را ارائه می دهند. اگر برنامه ای در مرحله آزمایش با موفقیت در یک کانتینر اجرا شود، تیم ها می توانند انتظار داشته باشند که در طول استقرار نیز به درستی اجرا شود.
هنگامی که تیم ها برنامه را برای همه کاربران نهایی هدف منتشر کردند، استقرار کامل می شود.
مرحله 7. تعمیر و نگهداری
مرحله آخر SDLC تعمیر و نگهداری است. هدف اصلی از تعمیر و نگهداری، نظارت مداوم بر برنامه برای شناسایی مشکلاتی است که پس از تولید آن رخ می دهد. به عنوان مثال، اگر یک نوع درخواست خاص خطایی را ایجاد کند، تیم های توسعه باید این را یادداشت کنند تا بتوانند مشکل را برطرف کنند.
بعلاوه تیم های بازخورد در مرحله پشتیبانی جمع آوری می کنند می تواند به راهنمایی به روز رسانی برنامه های آینده کمک کند. ممکن است تیم‌ها متوجه شوند که یک ویژگی به‌طور مثال به‌طور غیربهینه کار می‌کند و به این نتیجه برسند که باید در به‌روزرسانی بعدی برنامه دوباره از این ویژگی بازدید کنند. از این نظر، تعمیر و نگهداری کمک می کند تا SDLC یک فرآیند تکرار شونده است که در آن هر نسخه برنامه، مجموعه جدیدی از به روز رسانی های برنامه را هدایت می کند، که هر یک از آنها تکرار خود را از SDLC انجام می دهد.
SDLC فرآیندی است که توسط توسعه دهندگان برای ایجاد نرم افزار ایمن و با کیفیت استفاده می شود.
برخلاف سایر مراحل SDLC، تعمیر و نگهداری همیشه پایان روشنی ندارد. تا زمانی که افراد استفاده از برنامه را متوقف کنند یا تا زمانی که نسخه جدیدی از برنامه جایگزین نسخه قبلی شود، به طور نامحدود ادامه می یابد – در این صورت تیم ها به پشتیبانی از نسخه جدیدتر برنامه تغییر می کنند.
مدل های توسعه SDLC
تیم‌ها می‌توانند هفت مرحله SDLC را با استفاده از مدل‌های مختلف توسعه نرم‌افزار پیاده‌سازی کنند – به معنای استراتژی‌های طراحی که پیاده‌سازی را هدایت می‌کنند و هر مجموعه از تغییرات برنامه را هماهنگ می‌کنند.
در گذشته، محبوب‌ترین مدل توسعه، مدل Waterfall بود که شامل اعمال تغییرات در برنامه‌ها در تکرارهای بزرگ و نادر بود. امروز، Waterfall تا حد زیادی جای خود را به توسعه نرم افزار Agile داده است، که تیم ها را تشویق می کند تا به روز رسانی های برنامه را به تکه های کوچکی از کار تقسیم کنند و آنها را از طریق سرعت های کوتاه مدیریت کنند. Agile اغلب برای توسعه دهندگان موثرتر است زیرا به آنها اجازه می دهد اهداف کوچک و قابل مدیریتی را تعیین کنند. همچنین می‌تواند برای کاربرانی مفید باشد که مرتباً به‌روزرسانی‌ها را دریافت می‌کنند و مجبور نیستند با تغییرات اساسی برنامه‌ها که به یکباره به آنها برخورد می‌کند، دست و پنجه نرم کنند.
روش های دیگری نیز وجود دارد که برخی از عناصر Waterfall و Agile را ترکیب می کند. به عنوان مثال، توسعه تدریجی شبیه به Agile است که اهداف توسعه برنامه را به واحدهای مجزا تقسیم می کند، اما مانند Waterfall، این مدل لزوماً بر تغییرات مکرر برنامه تأکید نمی کند.
همچنین رویکردهای افراطی تری برای Agile و Waterfall وجود دارد. برای مثال، توسعه سریع اپلیکیشن یا RAD، کار توسعه را به پروژه های کوچک تقسیم می کند. این شبیه به Agile است، اما تهاجمی تر است و به طور کلی برای تیم های کوچک بهترین کار را دارد.
بهترین مدل توسعه برای یک پروژه معین به عواملی مانند سرعت تیم ها برای اعمال تغییرات و تعداد توسعه دهندگان در یک تیم بستگی دارد. برای مثال، Waterfall می‌تواند برای توسعه ویژگی‌های جدید برای یک برنامه قدیمی که در آن نوآوری سریع در اولویت نیست، به خوبی کار کند، در حالی که Agile می‌تواند به تیم‌های بزرگ کمک کند تا با تقسیم کار به مجموعه‌های نسبتاً کوچک و به راحتی قابل مدیریت، به طور مؤثرتری با یکدیگر همکاری کنند.
کریس توزی نویسنده آزاد، مشاور دانشگاهی و استاد فناوری اطلاعات و جامعه است که قبلا به عنوان روزنامه نگار و مدیر سیستم لینوکس کار می کرد.
