Существующие методологии ПО очень разнообразны и часто вызывают споры в своем отличии. Потому что в большинстве своем методологии программного обеспечения индивидуальны для каждой разработки. Однако никто не оспаривает, что при любой разработке есть определенные этапы, через которые проходит продукт. А также во всем многообразии методологий выделяется несколько основных и похожих, которые можно объединить в определенные виды.
Основные этапы, которые проходит продукт, невзирая на методологии разработки ПО
Независимо от выбранной методологии разработки ПО, любой продукт проходит обозначенные ниже этапы. Каждый этап может быть дополнен собственными подэтапами или перемещен в другой последовательности или еще как-либо изменен, или может просто называться по-другому, но смысл от этого не меняется.
Этапы разработки:
Подготовка. На этом этапе проходит сбор сведений о будущем продукте и функциональности, о возможном трафике.
Проектирование. На этом этапе проходит обсуждение будущей архитектуры продукта непосредственно с разработчиками.
Создание, которое может включать: дизайн, кодирование, тестирование, документирование. На этом этапе происходит сам кодинг продукта, отрисовка дизайна и составление прочей документации.
Поддержка, которая может включать внедрение, сопровождение. На этом этапе происходит боевое крещение продукта, он публикуется на боевых серверах, и запускается первый трафик, также в дальнейшем происходит коррекция и поддержка продукта с опорой на обратную связь от клиентов.
Разница между этапами и методологией есть. Этапы разработки включают в себя стадии, через которые должен пройти продукт: от этапа идеи и до его публикации.
Методологии разработки ПО — это совокупность методов для управления эффективной разработкой.
Методологии разработки ПО
Как мы уже писали, методологии разработки программного обеспечения очень разнообразны, но можно выделить несколько моделей:
Waterfall или метод «водопад». Все этапы проходят друг за другом. Сначала выполняется один этап и только потом следующий.
V-образный метод. Этот метод чем-то похож на предыдущий, но отличается тем, что требования и описания к этапам разработки и тестированию прописываются одновременно.
Инкрементная модель. Это модель, при которой продукт разрабатывается не комплексно, а отдельно по рабочим частям. Каждая отдельная часть разработки — это самостоятельный рабочий продукт. То есть делается часть продукта — выкатывается на рынок. Если все «ок», то разрабатывается другая часть и т. д.
Итеративная модель. Эта модель предполагает, что заказчик продукта может даже не понимать, что получится в итоге, и, соответственно, не способен прописать подробное техническое задание. При такой модели делается часть продукта — согласовывается с заказчиком, потом следующая часть продукта — опять все согласовывается. И так, пока продукт разработки не будет закончен.
Спиральная модель. Данная модель делает упор на анализ рисков продукта. Сам же продукт разрабатывается поэтапно. Но в конце каждого этапа проводится анализ и принимается решение, будет ли продолжаться разработка или нет.
Гибкая модель. Данная модель подразумевает ведение разработки под постоянным контролем заказчика, когда он может часто лицезреть результат, чтобы понимать, устраивает его продукт или нет. Также эта модель может характеризоваться ежедневными короткими спринт-встречами для постановки задач разработчикам.
RAD-модель. Данная модель может характеризоваться параллельной разработкой частей одного проекта разными командами. По сути получается, что один большой проект разбивается на несколько маленьких, которые выполняют разные специалисты. Потом все части объединяются в одну, и получается готовый продукт. Такая модель свойственна ограниченной по времени разработке, когда проект нужно окончить в экстремально сжатые сроки.
Подытожим
Часто можно услышать вопрос: «А зачем нужны модели разработки ПО?». В первую очередь модели нужны, чтобы качественно наладить структуру разработки продукта и взаимоотношения между разработчиками и заказчиком. Модели позволяют создать продукт вовремя и, самое главное, таким, каким он должен быть.
Нет конкретной методологии разработки ПО под конкретную задачу. Каждая разработка индивидуальна, и поэтому часто даже вышеописанные методы изменяются и перемешиваются между собой. Но в любом случае в больших проектах они очень применимы, так как позволяют сделать разработку эффективней.
Другое