Методологии разработки программного обеспечения

В этом посте мы рассмотрим различные методологии разработки программного обеспечения, а также их преимущества и недостатки, а также когда использовать каждую модель.

Итерационная модель

Итеративная модель жизненного цикла не пытается начать с полной спецификации требований. Вместо этого разработка начинается с определения и реализации только части программного обеспечения, которая затем может быть проанализирована для определения дальнейших требований. Затем этот процесс повторяется, создавая новую версию программного обеспечения для каждого цикла модели.

Рассмотрим итеративную модель жизненного цикла, которая состоит из последовательного повторения следующих четырех фаз:

Фаза требований, в котором собраны и проанализированы требования к программному обеспечению. Итерация должна в конечном итоге привести к фазе требований, которая дает полную и окончательную спецификацию требований.

Фаза дизайна, в котором разработано программное решение, отвечающее требованиям. Это может быть новый дизайн или расширение более раннего дизайна.

Этап внедрения и тестирования, когда программное обеспечение закодировано, интегрировано и протестировано.

Фаза обзора, в котором оценивается программное обеспечение, рассматриваются текущие требования и предлагаются изменения и дополнения к требованиям.

Для каждого цикла модели необходимо принять решение о том, будет ли программное обеспечение, созданное в ходе цикла, отбраковано или сохранено в качестве отправной точки для следующего цикла (иногда называемого инкрементным прототипированием.

В конце концов, наступит момент, когда все требования выполнены и программное обеспечение может быть поставлено, или станет невозможным усовершенствовать программное обеспечение по мере необходимости, и придется начинать все сначала.

Итеративную модель жизненного цикла можно сравнить с производством программного обеспечения путем последовательного приближения. Проведя аналогию с математическими методами, которые используют последовательное приближение для получения окончательного решения, польза от таких методов зависит от того, насколько быстро они сходятся к решению.

Ключом к успешному использованию итеративного жизненного цикла разработки программного обеспечения является тщательная проверка требований и проверка (включая тестирование) каждой версии программного обеспечения на соответствие этим требованиям в рамках каждого цикла модели.

Преимущества итеративной модели

• Быстро и на ранних этапах жизненного цикла программного обеспечения генерирует работающее программное обеспечение.
• Более гибкий - менее затратный для изменения объема и требований.
• Легче тестировать и отлаживать во время меньшей итерации.
• Легче управлять рисками, потому что рискованные элементы выявляются и обрабатываются во время итерации.
• Каждая итерация - это легко управляемая веха.

Недостатки итеративной модели

• Каждая фаза итерации жесткая и не перекрывает друг друга.
• Проблемы могут возникнуть в отношении архитектуры системы, потому что не все требования собраны заранее для всего жизненного цикла программного обеспечения.

Инкрементальная модель

Модель инкрементальной сборки - это метод разработки программного обеспечения, при котором модель проектируется, реализуется и тестируется постепенно (каждый раз добавляется немного больше), пока продукт не будет готов. Он включает в себя как разработку, так и поддержку. Продукт считается готовым, если он удовлетворяет всем его требованиям. Эта модель сочетает в себе элементы модели водопада с итеративной философией прототипирования.

Продукт разбит на несколько компонентов, каждый из которых разработан и построен отдельно (называемых сборками). После завершения каждый компонент доставляется клиенту. Это позволяет частично использовать продукт и позволяет избежать длительного времени на разработку. Это также приводит к значительным начальным капитальным затратам, что позволяет избежать длительного ожидания. Эта модель развития также помогает облегчить травмирующий эффект от одновременного внедрения совершенно новой системы.

Есть некоторые проблемы с этой моделью. Во-первых, каждая новая сборка должна быть интегрирована с предыдущими сборками и любыми существующими системами. Задача разложения продукта на сборки тоже нетривиальная. Если сборок слишком мало и каждая сборка вырождается, это превращается в модель сборки и исправления. Однако, если сборок слишком много, то из каждой сборки добавляется мало полезных функций.

Преимущества инкрементальной модели

• Быстро и на ранних этапах жизненного цикла программного обеспечения генерирует работающее программное обеспечение.
• Более гибкий - менее затратный для изменения объема и требований.
• Легче тестировать и отлаживать во время меньшей итерации.
• Легче управлять рисками, потому что рискованные элементы выявляются и обрабатываются во время итерации.
• Каждая итерация - это легко управляемая веха.

Недостатки инкрементальной модели

• Каждая фаза итерации жесткая и не перекрывает друг друга.
• Проблемы могут возникнуть в отношении архитектуры системы, потому что не все требования собраны заранее для всего жизненного цикла программного обеспечения.

Когда использовать инкрементную модель

• Такие модели используются там, где требования ясны и могут быть реализованы поэтапно. Из рисунка видно, что требования ® делятся на R1, R2 ……… .Rn и доставляются соответственно.
• В основном такая модель используется в веб-приложениях и продуктовых компаниях.

Гибкая модель

Гибкая модель представляет собой комбинацию как итерационной, так и инкрементной модели, путем разбиения продукта на компоненты, где на каждом цикле или итерации доставляется рабочая модель компонента.

Модель производит текущие выпуски (итеративно), каждый раз добавляя небольшие изменения к предыдущему выпуску (итеративно). Во время каждой итерации по мере создания продукта он также тестируется, чтобы гарантировать, что в конце итерации продукт можно отгрузить.

Модель Agile делает упор на сотрудничество, поскольку заказчики, разработчики и тестировщики работают вместе на протяжении всего проекта.

Преимущество модели Agile заключается в том, что она быстро создает рабочий продукт и считается очень реалистичным подходом к разработке.

Одним из недостатков этой модели является то, что, поскольку она сильно зависит от взаимодействия с клиентом, проект может пойти неверным путем, если заказчик не знает требований или направления, в котором он хочет двигаться.

Модель V

Модель V - это расширенная версия классической модели водопада, в которой каждый уровень жизненного цикла разработки проверяется перед переходом на следующий уровень. В этой модели тестирование программного обеспечения явно начинается с самого начала, то есть сразу после написания требований.

Здесь под тестированием мы подразумеваем проверку посредством обзоров и инспекций, то есть статическое тестирование. Это помогает выявлять ошибки на очень ранних этапах жизненного цикла и сводит к минимуму потенциальные будущие дефекты, появляющиеся в коде на более поздних этапах жизненного цикла.

Каждому уровню жизненного цикла разработки соответствует план тестирования. то есть по мере проработки каждого этапа разрабатывается план тестирования для подготовки к тестированию продуктов этого этапа. Разрабатывая планы тестирования, мы также можем определить ожидаемые результаты тестирования продуктов для этого уровня, а также определить критерии входа и выхода для каждого уровня.

Как и в Waterfall, каждый этап начинается только после завершения предыдущего. Эта модель полезна, когда нет неизвестных требований, поскольку все еще сложно вернуться и внести изменения.

Модель V - Преимущества

• На каждом этапе есть конкретные результаты.
• Более высокий шанс на успех по сравнению с водопадной моделью благодаря разработке планов тестирования на ранних этапах жизненного цикла.
• Учет времени по сравнению с водопадной моделью невысокий, можно сказать, на 50% меньше.
• Хорошо подходит для небольших проектов, где требования легко понять.
• Полезность ресурсов высокая.

Модель V - Недостатки

• Довольно жесткая, как у водопада.
• Небольшая гибкость и регулировка прицела - дело сложное и дорогое.
• Программное обеспечение разрабатывается на этапе внедрения, поэтому первые прототипы программного обеспечения не создаются.
• Модель V не дает четкого пути к проблемам, обнаруженным на этапах тестирования.

Когда использовать модель V

• Насколько мне известно, я лично думаю / чувствую, когда время и стоимость являются ограничениями проекта, тогда мы можем использовать такие модели для быстрой и рентабельной доставки.
• По сравнению с моделью водопада модель V более или менее аналогична, но тестирование начинается очень рано, что сокращает время и стоимость проекта.

Модель водопада

Модель водопада - самая старая и самая простая из структурированных методологий SDLC. Есть строгие этапы, и каждый этап должен быть завершен, прежде чем переходить к следующему этапу. Назад дороги нет.

Каждый этап основан на информации с предыдущего этапа и имеет собственный план проекта.

Водопад прост для понимания и управления. Тем не менее, это обычно связано с задержками, так как каждый этап должен быть рассмотрен и полностью подписан, прежде чем можно будет начать следующий этап.

Кроме того, поскольку после завершения этапа остается мало места для исправлений, проблемы не могут быть устранены, пока вы не дойдете до этапа обслуживания.

Эта модель работает лучше всего, когда известны все требования, не требуется гибкости и у проекта есть фиксированные сроки.

Преимущества модели водопада

• На каждом этапе есть конкретные результаты и процесс проверки.
• Фазы обрабатываются и завершаются по очереди.
• Хорошо работает для небольших проектов, где требования очень хорошо понятны.
• Он усиливает понятия «определить, прежде чем проектировать» и «проектировать, прежде чем код».

Недостатки модели водопада

• Изменение объема в течение жизненного цикла может убить проект
• Работающее программное обеспечение не производится до конца жизненного цикла.
• Высокий риск и неопределенность.
• Плохая модель для сложных и объектно-ориентированных проектов.
• Плохая модель для длительных и текущих проектов.
• Плохая модель, в которой риск изменения требований от умеренного до высокого.

Когда использовать модель водопада

• Такая модель широко используется там, где требования ясны и не будет изменений во времени разработки. Мы можем найти такие сценарии в оборонных проектах, где требования будут ясны, так как прежде, чем они напишут требования, они будут хорошо проанализированы.
• Мы также можем назвать такую ​​модель жизненного цикла для проектов миграции, где требования будут такими же, только платформа или языки могут отличаться / меняться.
• Также можно использовать для проектов, где спонсоры сами будут проводить тестирование, так как до завершения кодирования мы не доставим проект.