- •34. Характеристика процесса анализа требований. Результат анализа.
- •37.Классификация и спецификация требований
- •35. Источники требований. Стратегии выявления требований
- •Прототипирование
- •36.Цели прототипирования. Классификация прототипов
- •41.Этапы проектирования. Стадии и этапы создания (гост 34.601-90)
- •4.1. Разработка предварительных проектных решений по системе и её частям
- •5.1. Разработка проектных решений по системе и её частям
- •Области проектирования
- •40.Документирование требований. (гост 34.602-89 "Техническое задание на создание автоматизированной системы")
- •4.Требования к системе;
- •5.Состав и содержание работ по созданию системы;
- •6.Порядок контроля и приемки системы;
- •7.Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
- •8.Требования к документированию;
34. Характеристика процесса анализа требований. Результат анализа.
Процесс анализа требований (Requirement Process)
Формирование видения; Выявление требований; Классификация и спецификация требований; Расширенный анализ требований (моделирование и прототипирование); Документирование требований; Проверка требований; Управление требованиями; Совершенствование процесса работы с требованиями.
Хорошие требования позволяют:
выработать общее понимание между Заказчиком и Разработчиком; определить рамки проекта; более точно определить финансовые и временные характеристики проекта; обезопасить Заказчика от риска получить продукт, в котором он не сможет работать, обезопасить Разработчика от риска попасть в ситуацию "неконтролируемого размытия границ", которое может привести к непредвиденным затратам ресурсов сверх начальных ожиданий.
Результаты АТ: набор артефактов: текстовые документы, модели UML, либо других языков моделирования, прототипы программного обеспечения.
Цели, преследуемые потоком работ АТ: добиться одинакового понимания с заказчиком и пользователями о том, что должна делать система; дать разработчикам наилучшее понимание требований к системе; определить границы системы; определить интерфейс пользователя и системы.
Кто создает и использует требования:
Специалист по АТ - постановка задачи, определение рамок проекта; Представитель заказчика - постановка задачи, определение рамок проекта, контроль работы исполнителя, приемка результатов работы; Архитектор системы - разработка архитектуры, проектирование подсистем; Программист - разработка программного кода; Тестировщик - составление тест-плана, тестовых сценариев; Менеджер проекта - планирование и контроль исполнения работ.
Анализ требований, бизнес-анализ, анализ проблемной области.
Глоссарий - общее понимание основной терминологии Заказчиком и Разработчиком.
Анализ бизнес-процессов часть анализа проблемной области.
В начале определить цели и задачи бизнес-анализа, как этапа построения КИС
АПО –отразить объект (существующую организационную систему предприятия) в создаваемой модели с требуемой степенью точности.
Анализ требований – направлен на моделирование воображаемого, еще не существующего объекта (АИС).
Анализ предметной области АПО
Требования и архитектура ИС
Представление прецедентов включает в себя : логическое, представление процессов, представление реализации, физическое представление
Анализируя модель проблемной области, в ней можно вычленить
задачи и функции, реализуемые внутри ОС и функции коммуникации ОС и среды,
устройство предметной области (в начале - на уровне концептуальной модели),
требования к информации и ее обработке
Методологии бизнес-анализа
модели, преследующие цель анализа и улучшения организационной системы (например, SWOT , VCM, BPR, CPI/TQM/ISO9000, BSC),
модели общего назначения, такие, как SADT, DFD, IDEF1, IDEF3, IDEF5 и другие,
модели, специально разработанные для использования при автоматизации (например, ISA, BSP, ARIS, RUP).
Рабочие потоки АТ