SDLC против гибких методологий при разработке ПО
Проектирование, разработка и тестирование высококачественного программного обеспечения, отвечающего требованиям клиента в пределах предполагаемых временных и стоимостных ограничений, является целью жизненного цикла разработки программного обеспечения (SDLC). В качестве альтернативы, как заявил Disque (2021), жизненный цикл гибкой разработки программного обеспечения сочетает в себе итеративный и инкрементный подходы. Его основная цель — максимизировать гибкость процессов и удовлетворенность клиентов за счет своевременной доставки функционального программного решения. Такие методы, как Rapid Application Development (RAD) и Agile, постепенно заменяют старую модель жизненного цикла, представленную жизненным циклом разработки системы, потому что они лучше адаптируются к изменяющимся потребностям бизнеса и могут намного быстрее предоставить компании ощутимые преимущества.
Сравнение жизненного цикла разработки систем с гибкими методологиями разработки
Существует концептуальная модель, известная как жизненный цикл разработки системы (SDLC), которая определяет шаги, которые необходимо предпринять при создании или обновлении системы. Планирование, анализ, проектирование, внедрение и техническое обслуживание — это этапы жизненного цикла разработки систем, которые должны быть завершены, прежде чем новая или пересмотренная информационная система может быть введена в эксплуатацию. Хорошо выполненный SDLC должен дать высококачественную систему, совместимую с существующей и будущей ИТ-инфраструктурой, поставляемую вовремя и в рамках бюджета, а также обеспечивающую отличное взаимодействие с пользователем.
Например, Devadiga (2018) заявил, что система управления полетом (FCS) самолета состоит из поверхностей управления полетом, органов управления кабиной и необходимых механизмов для управления направлением полета самолета; это система управления полетом с высокой степенью риска, которая контролирует все аспекты работы самолета, чтобы обеспечить более безопасный и плавный полет. Система управления полетом является примером приложения с высокими ставками, которое требует более традиционного подхода с такими характеристиками, как оценка риска и всестороннее тестирование или моделирование (стр. 146).
Гибкая разработка
Это подход к жизненному циклу разработки программного обеспечения, при котором несколько кросс-функциональных команд, включая конечных пользователей или клиентов, работают вместе, чтобы предоставить функции и исправления, которые нужны клиенту. Это помогает с мгновенными изменениями и быстрым ростом, а также с непрерывной доставкой результатов проекта, улучшений и прогресса. Девадига (2018), например, заявил в тематическом исследовании бизнес-подразделения Microsoft Office (OBU). Состояние проекта и спрос подробно описаны ниже (стр. 143).
- Стратегия выпуска: Microsoft предпочитала распространять продукт в виде нескольких крошечных кратковременных выпусков.
- Сроки: первый проект должен был быть готов через год.
- Сосредоточьтесь на программировании: усилия Microsoft в то время в значительной степени зависели от программирования или разработки и демонстрации моделей. Им это всегда удавалось.
- Архитектура программного обеспечения и технологические процессы не беспокоили разработчиков и менеджеров.
- Крошечные команды: в среднем команда разработчиков состояла из 10 человек.
- Неизвестные требования к проекту: Microsoft хочет предоставить текстовому процессору как можно больше уникальных функций, не определяя объем проекта.
С учетом этих соображений для проекта OBU предпочтительнее использовать гибкую методологию, такую как экстремальное программирование (XP). Ниже приведены возможные преимущества использования экстремального программирования в этом проекте. Частота выпуска и нехватка времени: главным приоритетом Microsoft было доставить продукт потребителям как можно скорее. С XP это стало бы возможным, если сначала выпустить урезанную версию программы, а затем постепенно расширять ее возможности в последующих обновлениях.
Более того, как заявил Педамкар (nd), сравнение SDLC и Agile можно резюмировать в Таблице 1 ниже (параграф 3):
Таблица 1. Сравнение SDLC и гибкого метода
| Основа для сравнения | SDLC | Agile |
| Определение | Жизненный цикл разработки программного обеспечения (SDLC) представляет собой набор процедур, используемых для эффективного контроля за проектами по разработке программного обеспечения. | В жизненном цикле разработки программного обеспечения (SDLC) используются итеративные подходы и методологии для создания программного обеспечения. |
| Использование | Он применяется для эффективного производства высококачественных продуктов. | Как метод разработки программного обеспечения поэтапно, он доказал свою эффективность в создании надежных программ. |
| Этапы | Процесс разработки включает несколько отдельных фаз. | Метод или модель его создания будет состоять из серии этапов. |
| Платформа | Полезен для создания любого типа продукта или приложения. | Благодаря способности разделяться на инкрементальные сборки, он может обслуживать любой продукт. |
| Размер проекта | Адаптируем к проектам любого масштаба. | Он работает хорошо для маломасштабных начинаний. |
| Изменения | После начальных этапов проекта не допускаются значительные изменения. | Для постоянно развивающихся потребностей он обеспечивает быстрые корректировки после начала проекта или в любое время его выполнения. |
| Подход | Различные используемые методологии дают различные результаты. | Метод его роста основан на реализме. |
| Управление | Все зависит от используемого метода. | В рамках гибкой методологии управление проще. |
| Гибкость | В зависимости от выбранной методологии определяется, насколько хорошо используется водопадная, гибкая или унифицированная модель. | Разработчики и вся команда могут воспользоваться ее адаптируемостью. |
Обратная сторона гибкой разработки программного обеспечения
Фридман (2016) утверждает, что гибкие подходы имеют несколько недостатков (параграф 5).
- Во-первых, более низкая предсказуемость: при создании программного обеспечения разработчики не всегда знают, сколько времени и ресурсов потребуется, особенно в самом начале. Это заставляет людей делать неправильный выбор и вести себя плохо.
- Во-вторых, нам придется уделять больше времени и усилий, потому что Agile поощряет постоянный диалог между заказчиками, программистами и специалистами по обеспечению качества. Разработчики не могут перейти к следующему этапу проекта, не получив отзывов клиентов о предыдущем. На все нужно больше усилий и времени.
- В-третьих, неадекватная документация, поскольку клиенты указывают свои требования на каждом этапе, а разработчики слишком заняты созданием продукта, чтобы документировать тонкости. Когда в проект добавляются новые люди, у них меньше доступа к информации, что может привести к еще большей путанице и проблемам.
Чтобы избежать обреченного проекта, клиенты должны предоставить точные инструкции. Если разработчики не получают адекватной обратной связи, отсутствие отзывов клиентов может привести к неверным предположениям и упущенным возможностям роста.
Заключение
Поскольку использование технологий во всех секторах экономики продолжает расширяться с поразительной скоростью, программные решения стали основой для управления любой компанией. Современный ландшафт программного обеспечения нуждается в руководящем подходе к разработке из-за его масштаба и сложности. Поскольку программное обеспечение можно использовать по-разному, важно рассматривать каждый случай отдельно, чтобы найти наилучший способ.
Ссылка
Диск (2021, 9). Учебное пособие по методологии Agile для начинающих: официальное видео о том, как работает Agile. YouTube.
Девадига, Н (2018) «Пример определения жизненного цикла разработки программного обеспечения и структуры процесса», Международный журнал передовых инженерных исследований и науки, 5 (7), стр. 143–147. Доступно по ссылке: .
Фридман (2016, 6 мая). Огромный недостаток гибкой разработки программного обеспечения. Огромный недостаток гибкой разработки программного обеспечения.
Педамкар, П (nd). SDLC против Agile. SDLC против Agile.
