9. Анализ целевых и разработка требований к программным системам.
Анализ требований — это процесс сбора требований к программному обеспечению (ПО), их систематизации, документирования, анализа, выявления противоречий, неполноты, разрешения конфликтов в процессе разработки программного обеспечения. В англоязычной среде также говорят о дисциплине «инженерия требований». В процессе сбора требований важно принимать во внимание возможные противоречия требований различных заинтересованных лиц, таких как заказчики, разработчики или пользователи.
Полнота и качество анализа требований играют ключевую роль в успехе всего проекта. Требования к ПО должны быть документируемые, выполнимые, тестируемые, с уровнем детализации достаточным для проектирования системы. Требования могут быть функциональными и нефункциональными.
Анализ требований включает три типа деятельности:
Сбор требований: общение с клиентами и пользователями, чтобы определить, каковы их требования.
Анализ требований: определение, являются ли собранные требования неясными, неполными, неоднозначными, или противоречащими, и затем решение этих проблем.
Документирование требований: Требования могут быть задокументированы в различных формах, таких как простое описание, сценарии использования, пользовательские истории, или спецификации процессов.
Завершенность - свойство, характеризующее степень обладания ПС всеми необходимыми частями и чертами, требующимися для выполнения своих явных и неявных функций.
Точность - мера, характеризующая приемлемость величины погрешности в выдаваемых программами ПС результатах с точки зрения предполагаемого их использования.
Автономность - свойство, характеризующее способность ПС выполнять предписанные функции без помощи или поддержки других компонент программного обеспечения.
Устойчивость - свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.
Защищенность - свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.
Валидация – это процесс проверки системы и ПО или их компонентов в течение, или в конце цикла разработки с целью определить полноту удовлетворения этой системой и ПО установленным требованиям.
Валидация обычно ассоциируется с проверкой кода продукта с использованием тест кейсов.
Верификация – это процесс проверки системы и ПО или их компонентов с целью определить, удовлетворяет ли продукт на данной стадии разработки условиям принятым в начале этой стадии разработки.
Верификация обычно ассоциируется с такими видами действий как контроль и просмотр перед отчётами о выполнении стадии разработки или поставками продукта.
10. Функциональное моделирование. Стандарты idef0, idef3.
Для любой системы определяющим является ее функциональное содержание, так как оно определяет ее основные свойства. Поэтому в основе функционального моделирования лежит функциональное содержание системы, в качестве отношений между функциями рассматривается информация об объектах, связывающих эти функции
В основе IDEF0-методологии лежат 4 основных понятия:
функциональный блок;
интерфейсная дуга (стрелка);
декомпозиция;
глоссарий.
На одной диаграмме рекомендуется рисовать от 3 до 6 блоков. Иначе диаграмма будет плохо читаемой.
2. Функциональные блоки должны располагаться слева направо сверху вниз в порядке доминирования.
3. Следует избегать излишнего пересечения стрелок.
4.Выход одного блока может являться входом (управлением) для другого. Могут быть и обратные связи по входу и управлению.
5. Стрелки могут быть сливающимися и разветвляющимися
В общем случае, процесс – это упорядоченная последовательность действий.
Следовательно, процессная модель IDEF3 позволяет:
Отразить последовательность процессов
Показать логику взаимодействия элементов системы.
Цель IDEF3 - дать возможность аналитикам описать ситуацию, когда процессы выполняются в определенной последовательности, а также объекты, участвующие совместно в одном процессе.
Основными элементами IDEF3-модели являются:
1) единицы работ;
2) связи;
3) перекрестки;
4) объекты ссылок.
Связи показывают взаимоотношения работ.
Перекрестки (соединения)
Используются для отображения логики взаимодействия стрелок при их слиянии или разветвлении, для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы.