14. Содержание V-модели

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

Эта модель отображает системную разработку в терминах уровней по ЖЦ проекта.

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

- максимально увеличить число ТПР;

- управлять стадными продуктами;

- использовать программное управление для согласования действий;

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

При реализации проекта возникает необходимость изменения требований (техническая проблема связанная с деталями технического проектирования), или заказчик настаивает на корректировке цели, что влияет на стоимость, качество и график работ.

Поэтому необходимо выполнить следующее:

- принять или отклонить изменения;

- согласовать стоимость изменения;

- организовать работы по переделке.

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

Хорошо сформулированные требования на каждом уровне дают возможность руководителю проекта иметь правильное представление о ходе выполнения проекта.

Использование связей позволяет получить следующие преимущества:

- возможность оценить влияние изменений;

- получить большую уверенность в достижении целей;

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

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

- возможность сопоставлять затраты и выгоду.

Программные средства поддержки работы с требованиями позволяют создавать связи путем перетаскивания одного раздела на другой (рис.2).

Существует три метода анализа связей между требованиями:

1) анализ влияния даёт возможность оценить, на какие другие элементы проекта нижнего уровня повлияет внесение изменения в данный конкретный элемент.

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

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

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

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

15. Назначение и виды требований к ис.

Определение требований к ИС является наиболее этапом ее разработки.

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

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

Значимость требований определяется их ролью в формировании ФСИС и ОКИС, процессами выполняемых работ на всех стадиях ЖЦ ИС.

Одной из основных проблем, связанных с процессом проектирования АС, является отсутствие методик реализации 1-ых стадий проектирования, прежде всего, определения требований.

Существуют разные технологии определения требований.

Британская технология SSADM предусматривает согласование проектных работ, ориентированных на применение САПР. Эта технология формирования требований позволяет разумно сочетать возможности формирования требований как заказчиком, так и разработчиком. Ее преимуществом является глубокий анализ варианта разрабатываемой системы с тщательной ее увязкой с общесистемным программным обеспечением и обеспечивающим комплексом в целом.

По сравнению с ГОСТ 34.601-90 методика SSADM является более гибкой, предусматривающей выявление общих требований к системе пользователем и в частности к ее функциональным назначениям. Кроме того она позволяет представлять требования для принятия конкретных решений.

Несмотря на то, что данная технология слабо формализована, она представляет возможность разработать 13 дополнительных методик, для разработки элементов АС.

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

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

Все требования подразделяются на:

- функциональные,

- нефункциональные.

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

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

В процессе проектирования нефункциональные требования должны регулярно пересматриваться по мере добавления функций каждым пользователем. Это позволяет использовать КТ как на макро-, так и на микро- уровне проектирования.

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

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

1. Меры безопасности, хранения данных предусматривают каким данным необходима защита, резервирование.

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

3. Качество реализации функций определяется вычислительным комплексом и соответствующими обеспечениями в виде оценок. Естественно на I этапе устанавливаются грубые оценки, которые уточняются на этапе микропроектирования. Например:

а) производительность – это суммарный объем работы, выполняемый в ед. времени (продолжительность реализации функции),

б) надежность – наработка на отказ,

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

г) длительность функционирования системы.

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

5. Прочие требования.

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