Добавил:

Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Инженерно-технологическая академия ЮФУ

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

ТРПО_материалы / Материалы / se02.pps

Скачиваний:

Добавлен:

01.06.2015

Размер:

1.64 Mб

Скачать

☆

<<< < Предыдущая 1 2 3 4 56 / 66

Аттестация требований.

Методы.

1.Обзор требований. Требования системно анализируются рецензентами.

2.Прототипирование. На этом этапе прототип системы демонстрируется конечным пользователям и заказчику. Они могут экспериментировать с этим прототипом, чтобы убедиться, что он отвечает их потребностям.

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

4.Автоматизированный анализ непротиворечивости. Если требования представлены в виде структурных или формальных системных моделей, можно использовать инструментальные CASE-средства (см. следующий слайд). Необходимо построить базу данных требований и затем проверить все требования в этой базе данных. Анализатор требований готовит отчет обо всех обнаруженных противоречиях.

Аттестация требований. Методы.

Автоматический анализ непротиворечивости

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

(Software engineering)

Учебный курс

очного обучения по специальностям 230105 «Программное обеспечение вычислительной техники и автоматизированных систем»

010503 «Математическое обеспечение и администрирование информационных систем»

Л Е К Ц И Я

2.3

кафедры МОП ЭВМ

8 семестр

Управление

требованиями.

В.В.Хашковский, к.т.н., доц. каф. МОП ЭВМ ТРТУ

Д.П.Калачев, доц., к.т.н., доц. каф. МОП ЭВМ

ТРТУ

Управление требованиями. Что это и зачем ?

Управление требованиями - это

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

Requirements are inevitably incomplete and inconsistent

New requirements emerge during the process as business needs change and a better understanding of the system is developed

Different viewpoints have different requirements and these are often contradictory

Управление требованиями. Что это и зачем ?

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

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

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

Управление требованиями. Эволюция требований

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

2.Изменяемые требования. Эти требования отображают изменения,

сделанные во время разработки системы или после ввода ее в

эксплуатацию.

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

обнаружение, организация и документирование начальных требований

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

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

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

Планирование

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

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

2.Управление процессом внесения изменений. Это ряд операций, которые оценивают воздействие на систему вносимых изменений, а также стоимость изменений.

3.Стратегия оперативного контроля. Определяет

отношения между требованиями, а также между

требованиями и проектированием системы.

4.Поддержка CASE-средств. Управление требованиями

предполагает обработку большого объема информации о

требованиях.

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

Управление изменениями

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

2.Анализ изменений. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.

3.Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде.

Если требуется срочно внести изменения в требования, всегда существует соблазн сделать сначала изменения в системе, а затем задним числом изменить спецификацию. Это почти неизбежно приводит к тому, что готовая система не будет согласована с требованиями.