ОБЪЕКТНО-ОРИЕНТИРОВАННЫЕ CASE- технологии

проекта
Пакетное представление при выборе объектно-ориентированного подхода 
Технологический процесс управления требованиями

системы – что будет достигнуто в результате внедрения ИС, в

какие сроки, и что может помешать достижению цели.

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

Следует проанализировать предметную область, определенную в соответствии с темой проекта, с целью выявление бизнес-требований на основе анализа бизнес-метамодели и осуществить документирование результатов, то есть раздел должен содержать:
построение концептуальной модели ИС (концептуальная диаграмма ИС) с целью уточнения бизнес-требований, а именно: потребности (Needs) бизнеса, бизнес-требования (Business Requirements), бизнес-цель проекта;
построение бизнес-метамодели предметной области с целью выявления высокоуровневых требований с использованием нотаций IDEF;
графическое представление бизнес-целей программного проекта в виде ориентированного графа – дерева целей (tree of the purposes);
документирование концепции ИС в документе «Видение» (Visio document)»: определение Образа продукта (Product vision) в соответствии с таблицей 1; определение Границ проекта (Project scope) в соответствии с таблицами.

представленной бизнес-метамодели в виде диаграмм следует уточнить содержание таблиц 1-5,

в которых следует определить:
потребности бизнеса (Needs) – учитывают, прежде всего, интересы Заказчика и определяют цель и подцели проекта;
бизнес-требования (Business Requirements) – основаны на выявленных Потребностях (Needs) бизнеса, составляют высший уровень абстракции в цепи требований: они определяют образ и границы всего продукта ;
бизнес-цели проекта – учитывают, прежде всего, интересы Разработчика и заключаются в том, чтобы получить признание в качестве наиболее защищенного продукта на рынке;
образ продукта (Product vision) – выстраивает работу всех заинтересованных лиц в одном направлении, содержит концепцию ИС, в процессе изменяется медленно в зависимости от изменения стратегии системы или развития Бизнес-целей.

функции
Документирование концепции

проектирование
2.1 Проблемный анализ объекта автоматизации. Выявление бизнес-требований на основе

анализа бизнес-метамодели.
2.1.1 Модель предметной области.
2.1.2 Модель бизнес-прецедентов.
2.1.3 Модель бизнес-процессов (при необходимости).
2.1.4 Документирование концепции программного проекта в табличном представлении.
2.2 Выявление функциональных требований на основе проектных моделей.

Документирование концепции

– нечто, описывающее определенное понятие предметной области. Артефакты используются как

исходные данные для последующей деятельности, содержат справочные сведения о проекте или выступают в роли поставляемых по контракту составляющих;
модель (model) – самый важный вид артефактов в RUP. Имеется девять моделей, которые совместно охватывают все важнейшие решения относительно визуализации, специфицирования, конструирования и документирования программной системы:
модель бизнес-процессов – формализует абстракцию организации;
модель предметной области – формализует контекст системы;
модель прецедентов, иначе вариантов использования – формализует функциональные требования к системе;
проектная модель – формализует словарь предметной области и области решения;
аналитическая модель (необязательная) – формализует идею проекта;
модель процессов (необязательная) – формализует механизмы параллелизма и синхронизации в системе;
модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;
модель реализации – описывает части, из которых собирается система;
модель тестирования – формализует способы проверки и приемки системы.
вид (view) – одна из проекций модели, а именно: с точки прения проектирования, процессов, развертывания, реализации и прецедентов.
другие артефакты:
группа требований – описывает, что система должна делать;
группа проектирования – описывает, как система должна быть построена;
группа реализации – описывает сборку разработанных программных компонентов;
группа развертывания – содержит все данные, необходимые для конфигурирования предоставленной системы.

сущностей из предметной области, а также отношений между ними. На

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

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

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

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

Модель предметной области описывает важные понятия предметной области и их связи между собой. Нельзя путать модель предметной области с логической и физической моделями системы. Модель предметной области описывает только объекты предметной области, но не показывает, как программная система будет с ними работать. Данная модель также позволяет составить глоссарий системы для лучшего ее понимания пользователями и разработчиками.
Бизнес-модель описывает процессы (существующие или будущие), которые должна поддерживать система. Бизнес-модель можно представить, как подмножество модели предметной области. Кроме определения бизнес-объектов, вовлеченных в процесс, эта модель определяет работников, их обязанности, и действия, которые они должны выполнять.