Top.Mail.Ru

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

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

Основные этапы, которые проходит продукт

Независимо от выбранной методологии разработки ПО, любой продукт проходит
обозначенные ниже этапы. Каждый этап может быть дополнен собственными
подэтапами или перемещен в другой последовательности или еще как-либо
изменен, или просто называться по-другому, но смысл от этого не меняется.
Этапы разработки:

  1. Подготовка. На этом этапе проходит сбор сведении о будущем продукте, о
    возможном трафике и будущей функциональности.
  2. Проектирование. На этом этапе проходит обсуждение будущей архитектуры
    продукта непосредственно с разработчиками.
  3. Создание, которое может включать: дизайн, кодирование, тестирование,
    документирование. На этом происходит сам коддинг продукта, отрисовка
    дизайна и составление прочей документации.
  4. Поддержка, которая может включать внедрение ,сопровождение. На этом этапе
    происходит боевое крещение продукта, он публикуется на боевых серверах и
    запускается первый трафик, так же в дальнейшем происходит коррекция и
    поддержка продукта, опираясь на обратную связь от клиентов.

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

Методологии разработки ПО

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

  1. Waterfall или метод «водопад». Каждые этапы проходят друг за другом.
    Сначала выполняется один этап и только потом следующий.
  2. V-образный метод. Этот метод чем-то похож на предыдущий, а отличается
    тем, что требования и описания к этапам разработки и тестирования
    прописываются одновременно.
  3. Инкрементная модель. Эта модель , при которой продукт разрабатывается не
    комплексно, а отдельно по рабочим частям. Каждая отдельная часть
    разработки — это самостоятельный рабочий продукт. То есть, делается часть
    продукта — выкатывается на рынок. Если все «ок», то разрабатывается другая
    часть и т. д.
  4. Итеративная модель. Эта модель предполагает, что заказчик продукта может
    даже не понимать что получится в итоге и соответственно не способен
    прописать подробное техническое задание. При такое модели, делается часть
    продукта — согласовывается с заказчиком, потом следующая часть продукта
    — опять все согласовывается. И так пока продукт разработки не будет
    закончен.
  5. Спиральная модель. Данная модель делает упор на анализ рисков продукта.
    Сам же продукт разрабатывается поэтапно. Но в конце каждого этапа
    проводится анализ и принимается решение будет ли продолжаться разработка
    или нет.
  6. Гибкая модель. Данная модель подразумевает ведение разработки под
    постоянным контролем заказчика, когда он может часто лицезреть результат,
    чтобы понимать устраивает его продукт или нет. Также эта модель может
    характеризоваться ежедневными короткими спринт-встречами, для постановки
    задач разработчикам.
  7. RAD-модель. Данная модель может характеризоваться параллельной
    разработкой частей одного проекта разными командами. По сути получается,
    что один большой проект разбивается на несколько небольших проектов,
    которые выполняют разные специалисты. Потом все части объединяются в
    одну и получается готовый продукт. Такая модель свойственна ограниченной
    по времени разработке, когда проект нудно окончить в экстремально сжатые
    сроки.

Возможно вам будет интересно почитать статью “Бесплатное сканирование сайта на ссылки и ошибки

Подытожим

Часто можно услышать вопрос, а зачем нужны модели разработки ПО. В первую
очередь, модели нужны, чтобы качественно наладить структуру разработки продукта
и наладить взаимоотношения между разработчиками и заказчиком. Модели
позволяют создать продукт во время и самое главное таким каким он должен быть.
Нет конкретной методологии разработки ПО, под конкретную задачу. Каждая
разработка индивидуальна и поэтому часто даже вышеописанные методы
изменяются и перемешиваются между собой. Но в любом случае, в больших
проектах они очень применимы, так как позволят сделать разработку эффективней.

Text.ru - 100.00%
Поделись статьей с друзьями!

Ответить

Ваш адрес email не будет опубликован. Обязательные поля помечены *