Перейти к содержимому
Главная страница » Модели

Модели

Prototüüpimine(прототипирование)

История модели

Модель прототипирования в различных формах была разработана и развивается в течении многих лет. Однако одним из знаменитых ранних методов прототипирования была методика «Waterfall Model» (модель водопада), предложенная Уинстоном Ройсом в 1970 году. С течением времени появились и другие методики прототипирования, такие как «Spiral Model» (спиральная модель) и «Agile» (гибкие методологии), разработанные позднее.

Этапы

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

Схемы

Плюсы

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

Минусы

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

V-mudell(V-модель)

История модели

Концепция V-образной модели была разработана Германией и США в конце 1980-х годов независимо друг от друга:

  • Немецкая V-модель была разработана аэрокосмической компанией IABG в Оттобрунне рядом с Мюнхеном в содействии с Федеральным департаментом по закупке вооружений в Кобленце, для Министерства обороны Германии. Модель была принята немецкой федеральной администрацией для гражданских нужд летом 1992.
  • Американская V-Model (VEE) была разработана национальным советом по системной инженерии (международным — с 1995 года) для спутниковых систем, включая оборудование, программное обеспечение и взаимодействие с пользователями.

Этапы

  • Анализ требований — этап включает общение с заказчиком с целью выделить его требования и ожидания от проекта. Другое название этого этапа — сбор требований.
  • Проектирование системы — этап включает проектирование системы и настройку оборудования и коммуникаций для разработки продукта.
  • Архитектурный дизайн — системный дизайн, разбивка на модули, выполняющие различные функции. Передача данных и связь между внутренними модулями и с другими системами.
  • Разработка модулей- система разбивает на небольшие модули. Определяется детальный дизайн модулей, также известный как Low-Level Design (LLD).

Схемы

Плюсы

  • В модели особое значение придается планированию, направленному на верификацию и аттестацию разрабатываемого продукта на ранних стадиях его разработки. Фаза модульного тестирования подтверждает правильность детализированного проектирования. Фазы интеграции и тестирования реализуют архитектурное проектирование или проектирование на высшем уровне. Фаза тестирования системы подтверждает правильность выполнения этапа требований к продукту и его спецификации.
  • В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта.
  • В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов.
  • Модель определяет продукты, которые должны быть получены в результате процесса разработки, причём каждые полученные данные должны подвергаться тестированию.
  • Благодаря модели менеджеры проекта могут отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой.

Минусы

  • Модель не предусматривает работу с параллельными событиями.
  • В модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла.
  • Тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно внести изменения, не повлияв при этом на график выполнения проекта.
  • В модель не входят действия, направленные на анализ рисков.
  • Некоторый результат можно посмотреть только при достижении низа буквы V.
[googleapps domain=»docs» dir=»forms/d/e/1FAIpQLSek2EK21Re17_ZrSgDZAYRPthpJQFfLYwOoXjj1TQ76EV1-Og/viewform» query=»embedded=true» width=»640″ height=»606″ /]