- Главная
- Информатика
- Проблемный анализ объекта автоматизации
Содержание
- 2. Проблемный анализ объекта автоматизации 3 Первый этап проекта – формулирование концептуального Видения системы – что будет
- 3. Проблемный анализ объекта автоматизации 3 Для документирования концепции ИС на основании формально представленной бизнес-метамодели в виде
- 4. Документирование концепции 3 Документ О1.Образ продукта Документ Г1. Границы проекта. Продукт
- 5. 3 Документ Г1.1 Границы проекта. Заинтересованные лица Документ Г1.2 Границы проекта. Основные функции Документирование концепции
- 6. 3 Документ Г 1.3 Границы проекта. Масштабы и ограничения Объектно-ориентированный анализ и проектирование 2.1 Проблемный анализ
- 7. Основные понятия 3 артефакт (artifact) – диаграмма, документ, модель, и т.д., иначе – нечто, описывающее определенное
- 8. Артефакты проекта 3 Концептуальная модель описывает систему в терминах реальных или предполагаемых сущностей из предметной области,
- 10. Скачать презентацию
Слайд 2Проблемный анализ объекта автоматизации
3
Первый этап проекта – формулирование концептуального Видения системы –
Проблемный анализ объекта автоматизации
3
Первый этап проекта – формулирование концептуального Видения системы –
Четко осознать, сформулировать генеральную линию проекта. Как правило, в его основе лежат материалы практики и в курсовом проекте требуется только представить более четкие выводы, применяя основные положения системного анализа и современные принципы управления проектами.
Следует проанализировать предметную область, определенную в соответствии с темой проекта, с целью выявление бизнес-требований на основе анализа бизнес-метамодели и осуществить документирование результатов, то есть раздел должен содержать:
построение концептуальной модели ИС (концептуальная диаграмма ИС) с целью уточнения бизнес-требований, а именно: потребности (Needs) бизнеса, бизнес-требования (Business Requirements), бизнес-цель проекта;
построение бизнес-метамодели предметной области с целью выявления высокоуровневых требований с использованием нотаций IDEF;
графическое представление бизнес-целей программного проекта в виде ориентированного графа – дерева целей (tree of the purposes);
документирование концепции ИС в документе «Видение» (Visio document)»: определение Образа продукта (Product vision) в соответствии с таблицей 1; определение Границ проекта (Project scope) в соответствии с таблицами.
Слайд 3Проблемный анализ объекта автоматизации
3
Для документирования концепции ИС на основании формально представленной бизнес-метамодели
Проблемный анализ объекта автоматизации
3
Для документирования концепции ИС на основании формально представленной бизнес-метамодели
потребности бизнеса (Needs) – учитывают, прежде всего, интересы Заказчика и определяют цель и подцели проекта;
бизнес-требования (Business Requirements) – основаны на выявленных Потребностях (Needs) бизнеса, составляют высший уровень абстракции в цепи требований: они определяют образ и границы всего продукта ;
бизнес-цели проекта – учитывают, прежде всего, интересы Разработчика и заключаются в том, чтобы получить признание в качестве наиболее защищенного продукта на рынке;
образ продукта (Product vision) – выстраивает работу всех заинтересованных лиц в одном направлении, содержит концепцию ИС, в процессе изменяется медленно в зависимости от изменения стратегии системы или развития Бизнес-целей.
Слайд 4Документирование концепции
3
Документ О1.Образ продукта
Документ Г1. Границы проекта. Продукт
Документирование концепции
3
Документ О1.Образ продукта
Документ Г1. Границы проекта. Продукт
Слайд 53
Документ Г1.1 Границы проекта. Заинтересованные лица
Документ Г1.2 Границы проекта. Основные функции
Документирование концепции
3
Документ Г1.1 Границы проекта. Заинтересованные лица
Документ Г1.2 Границы проекта. Основные функции
Документирование концепции
Слайд 63
Документ Г 1.3 Границы проекта. Масштабы и ограничения
Объектно-ориентированный анализ и проектирование
2.1
3
Документ Г 1.3 Границы проекта. Масштабы и ограничения
Объектно-ориентированный анализ и проектирование
2.1
2.1.1 Модель предметной области.
2.1.2 Модель бизнес-прецедентов.
2.1.3 Модель бизнес-процессов (при необходимости).
2.1.4 Документирование концепции программного проекта в табличном представлении.
2.2 Выявление функциональных требований на основе проектных моделей.
Документирование концепции
Слайд 7Основные понятия
3
артефакт (artifact) – диаграмма, документ, модель, и т.д., иначе – нечто,
Основные понятия
3
артефакт (artifact) – диаграмма, документ, модель, и т.д., иначе – нечто,
модель (model) – самый важный вид артефактов в RUP. Имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы:
модель бизнес-процессов – формализует абстракцию организации;
модель предметной области – формализует контекст системы;
модель прецедентов, иначе вариантов использования – формализует функциональные требования к системе;
проектная модель – формализует словарь предметной области и области решения;
аналитическая модель (необязательная) – формализует идею проекта;
модель процессов (необязательная) – формализует механизмы параллелизма и синхронизации в системе;
модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;
модель реализации – описывает части, из которых собирается система;
модель тестирования – формализует способы проверки и приемки системы.
вид (view) – одна из проекций модели, а именно: с точки прения проектирования, процессов, развертывания, реализации и прецедентов.
другие артефакты:
группа требований – описывает, что система должна делать;
группа проектирования – описывает, как система должна быть построена;
группа реализации – описывает сборку разработанных программных компонентов;
группа развертывания – содержит все данные, необходимые для конфигурирования предоставленной системы.
Слайд 8Артефакты проекта
3
Концептуальная модель описывает систему в терминах реальных или предполагаемых сущностей из
Артефакты проекта
3
Концептуальная модель описывает систему в терминах реальных или предполагаемых сущностей из
Логическая модель системы использует понятия, вошедшие в концептуальную модель, а также устанавливает существование и смысл основных абстракций и механизмов, определяющих архитектуру системы и весь проект.
Физическая модель системы описывает конкретное программное и аппаратное обеспечение, необходимое для реализации системы. Очевидно, что физическая модель сильно зависит от технологической специфики.
Со временем проект эволюционирует от концептуальной к логической и физической моделям.
Концептуальная, логическая и физическая модели выражают результаты анализа и проектирования.
Модель предметной области описывает важные понятия предметной области и их связи между собой. Нельзя путать модель предметной области с логической и физической моделями системы. Модель предметной области описывает только объекты предметной области, но не показывает, как программная система будет с ними работать. Данная модель также позволяет составить глоссарий системы для лучшего ее понимания пользователями и разработчиками.
Бизнес-модель описывает процессы (существующие или будущие), которые должна поддерживать система. Бизнес-модель можно представить, как подмножество модели предметной области. Кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности, и действия, которые они должны выполнять.