Вопрос 19 (Области знаний пи)

Описание областей знаний в SWEBOK построено по иерархическому принципу, как результат структурной декомпозиции. Такое иерархическое построение обычно насчитывает два-три уровня детализации, принятых для идентификации тех или иных общепризнанных аспектов программной инженерии. При этом, структура декомпозиции областей знаний детализирована только до того уровня, который необходим для понимания природы соответствующих тем и возможности нахождения источников компетенции и других справочных данных и материалов. В принципе, считается, что как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом руководстве (SWEBOK), а в первоисточниках Выделяют 10 областей знаний, но самых важных только 5.

Основные области SWEBOK:

• Software requirements – требования к ПО

• Software design – проектирование ПО

• Software construction – конструирование ПО

• Software testing – тестирование ПО

• Software maintenance – сопровождение ПО

• Software configuration management – конфигурационное управление ПО

• Software engineering management – управление в ПИ

• Software engineering process – процессы ПИ

• Software engineering tools and methods – инструменты и методы ПИ

• Software quality – качество ПО

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

• Computer engineering – разработка PC

• Computer science – информатика

• Management – общий менеджмент

• Mathematics – математика

• Project management – управление проектами

• Quality management – управление качеством

• Systems engineering – сист. проетир.

Вопрос 20 (Анализ и хар-ка областей знаний: Требования к по)

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

• Требование к продукту и процессу

• Функциональные требования

• Не функциональные требования

• Системные требования

Требование 1 опр.:

1. Условия функционирования и режимы работы ПО в определенной среде

2. Ограничения на структуру и память компьютера

3. Ограничения на принцип взаимодействия программ и PC

Требование 2 опр.:

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

Требование 3 опр.:

1. Это условия выполнения ПО

2. Возможность взаимодействия создаваемой системы с другими системами.

Требование 4 опр.:

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

Требования могут быть:

• количественные

• качественные

Раздел состоит из:

1. Инженерия требований

2. Выявление требований

3. Анализ требований

4. Спецификация требований

5. Волидация требований

6. Управление требованиями

Итак 1.1: Это дисциплина анализа и документирований к ПО. Она заключается в преобразовании предложенных заказчиком требований в системе к описанию требований к ПО.

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

Итак 1.3: Это процесс изучения потребностей и целей пользователей, классификация и преобразование их к требованиям, к системе, аппаратуре и требований ПО, разрешению конфликтов между требованиями, определению приоритетов и принципов взаимодействия со средой функционирования.

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

Итак 1.5: Это проверка изложенных спецификаций требований. Заказчик и разработчик проводят экспертизу сформированного варианта требований, с тем чтобы разработчик мог далее проводить проектирование ПО. Веравикация – процесс проверки правильности специальных требований на:

• соответствие

• не противоречивость

• полноту

• выполнимость

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

Итак 1.6: Это руководство процессом формирования требований. Возникает после того, как ПО начало работу в заданной среде и обнаружились ошибки трактовки требований, либо не выполнение требований. Для исправления некоторых требований или добавления нового составляется план, который согласуется с заказчиком.