V-образная модель жизненного цикла ПО: описание, преимущества и недостатки, критерии применения

↑

▷ Содержание

⇐ ПредыдущаяСтр 3 из 7Следующая ⇒

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

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

Анализ требований к продукту и его спецификации – анализ существующей проблемы с ПО, завершается полной спецификацией создаваемой программной системы;

Архитектура или проектирование на высшем уровне – каким образом функции ПО должны применяться при реализации проекта;

Детализированная разработка проекта – обосновывает алгоритмы для каждого компонента, который был определен на фазе построения архитектуры.

Разработка программного кода – выполняется преобразование алгоритмов, определенных на этапе детализированного проектирования, в готовое ПО;

Модульное тестирование – проверка каждого закодированного модуля на наличие ошибок;

Интеграция и тестирование – установка взаимосвязей между группами модулей;

Системное и приемочное тестирование – проверка функционирования системы в целом;

Производство, эксплуатация и сопровождение – ПО запускается в производство;

Приемочные испытания ( на рисунке нет) – позволяет пользователю протестировать функциональные возможности системы на соответствие исходным требованиям.

Преимущества:

- особое значение придается планированию, направленному на верификацию и аттестацию;

- предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;

- определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов;

- можно отслеживать ход процесса разработ­ки - завершение фазы является контрольной точкой;

- модель проста в использовании.

Недостатки:

- непросто справиться с параллельными событиями;

- не предусмотрено внесение динамических изменений на разных этапах жизненного цикла;

- тестирование требований в жизненном цикле происходит слишком поздно;

- в модель не входят действия, направленные на анализ рисков.

Критерии применения:

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

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

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

8. Процесс макетирования ПО: его содержание, преимущества и недостатки,

Критерии применения

Макетирование (прототипирование) – это процесс создания модели разрабатываемого программного продукта. Модель может принимать один из трех видов:

1) бумажный макет или «электронный» макет, который представляет GUI;

2) работающий макет (выполняет только часть требуемых функций);

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

Макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик, как это показано.

Преимущества:

- пользователь может "увидеть" системные требования в процессе их сбора командой разработчиков;

- снижается возможность возникновения путаницы, искажения информации при определении системных требований;

- в процесс можно внести новые требования пользо­вателя;

-

НАЧАЛО

Сбор и уточнение требований

Быстрое проектирование

Построение макета

Оценка макета заказчиком

Уточнение макета

Конструирование продукта

КОНЕЦ

Продолжать

Да

Нет

образуются постоянные, видимые признаки прогресса;

- качество продукта определяется при активном участии пользователя в процесс разработки;

- благодаря меньшему объему доработок уменьшаются затраты на разработку;

- обеспечивается управление рисками;

Недостатки:

- разработанные "на скорую руку" прототипы страдают от неадекватной или недостающей документации;

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

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

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

- если выполнение проекта завершается досрочно, у ко­нечного пользователя останется лишь частичная система;

- вызывает зависимость и может продолжаться слишком долго;

Критерии применения:

- требования не известны заранее, не постоянны или могут быть неудачно сформулированы;

- существует потребность в разработке пользовательских интерфейсов;

- осуществляются временные демонстрации;

- выполняется новая, не имеющая аналогов разработка;

- разработчики не уверены в том, какую оптимальную архитектуру или алгоритмы следует применять;

- алгоритмы или системные интерфейсы усложнены;

- разрабатывается ПО, когда проявляется средняя и высокая степень риска;

Познавательные статьи:



Техника нижней прямой подачи мяча

Комплекс физических упражнений для развития мышц плечевого пояса

Стандарт Порядок надевания противочумного костюма

Общеразвивающие упражнения без предметов