Диаграмма данных процесса - Process-data diagram
А диаграмма данных процесса (PDD), также известный как диаграмма результатов процесса это диаграмма это описывает процессы и данные которые действуют как результат этих процессов. С левой стороны модель метапроцесса можно просмотреть, а справа модель метаданных можно посмотреть.[1]
Диаграмму данных процесса можно рассматривать как комбинацию модель бизнес-процесса и модель данных.
Обзор
Диаграмма данных процесса, изображенная справа, дает обзор всех этих действий / процессов и результатов. Четыре серых прямоугольника обозначают четыре основных выполнение фазы, каждая из которых содержит несколько процессов, которые в данном случае являются последовательными. В полях справа показаны все результаты /концепции которые являются результатом процессов. Коробки без тени не имеют дополнительных понятий. Прямоугольники с черной тенью изображают сложные закрытые концепции, поэтому концепции, имеющие подконцепции, которые, однако, не будут описываться более подробно. Блоки с белой тенью (прямоугольник за ним) изображают открытые закрытые концепции, где суб-концепции раскрываются более подробно. Линии с ромбами показывают взаимосвязь между концепциями.
В Внедрение SAP Процесс состоит из четырех основных этапов: подготовка проекта, на которой создается видение будущего состояния решения SAP, этап определения размеров и проектирования, на котором программный стек приобретается и обучение персонала выполняется этап функциональной разработки и, наконец, заключительный этап подготовки, когда последний тесты исполняются перед фактическим запуском. Для каждого этапа рассматриваются жизненно важные действия и Практические результаты /товары объяснены.
Строительные блоки схемы данных процесса
Последовательные действия
Последовательные действия - это действия, которые необходимо выполнять в заранее определенном порядке. Действия отмечены стрелкой, что означает, что они должны выполняться в указанной последовательности. И действия, и поддеятельности можно смоделировать последовательно. На рисунке 1 показана диаграмма действий с одним действием и двумя последовательными подвидами деятельности. Особым видом последовательных действий являются состояния запуска и остановки, которые также показаны на рисунке 1.
На рисунке 2 проиллюстрирован практический пример. Пример взят из рабочего процесса регистрации требований в веб-инженерии на основе UML. Основное действие, моделирование пользователей и домена, состоит из трех действий, которые необходимо выполнять в заранее определенном порядке.
1: Последовательные действия
2: Пример
3: неупорядоченные действия
4: Пример
Неупорядоченные действия
Неупорядоченные действия используются, когда под-действиям действия нет заранее определенной последовательности, в которой они должны выполняться. Неупорядочивать можно только под-действия. Неупорядоченные действия представлены как вспомогательные действия без переходов внутри действия, как показано на рисунке 3.
Иногда действие состоит как из последовательных, так и неупорядоченных вспомогательных действий. Решение этой проблемы моделирования - разделить основную деятельность на разные части. На рисунке 4 проиллюстрирован пример, который поясняет необходимость моделирования неупорядоченных действий. Пример взят из рабочего процесса анализа требований унифицированного процесса. Основное задание «Опишите требования к кандидатам» разделено на две части. Первая часть - это последовательная деятельность. Вторая часть состоит из четырех действий, для правильного выполнения которых не требуется никакой последовательности.
Параллельная деятельность
Действия могут происходить одновременно. Это делается с помощью разветвления и соединения. Нарисовав действия параллельно на диаграмме, связанные с полосой синхронизации, можно разделить несколько действий. Позже к этим одновременным действиям можно снова присоединиться, используя ту же полосу синхронизации. И действия, и поддеятельности могут выполняться одновременно. В примере, показанном на рисунке 5, действие 2 и действие 3 являются одновременными действиями.
На рисунке 6 изображен фрагмент процесса сбора требований. Одновременно выполняются два действия: определение участников и определение вариантов использования. Причина одновременного выполнения этих действий заключается в том, что определение акторов сильно влияет на варианты использования, и наоборот.
5. Параллельные действия
6: Пример
7. Условные действия
8: Пример
Условные действия
Условные действия - это действия, которые выполняются только при выполнении заранее определенного условия. Это графически представлено с помощью ветки. Ветви показаны ромбиком и могут иметь входящие и исходящие переходы. Каждый исходящий переход имеет охранное выражение - условие. Это охранное выражение на самом деле является логическим выражением, используемым для выбора направления движения. И действия, и поддеятельности можно смоделировать как условные. На рисунке 7 показаны два условных действия.
На рисунке 8 проиллюстрирован практический пример. Анализ требований начинается с изучения материала. На основе этого исследования принимается решение о проведении расширенного сеанса выявления требований. Условие невыполнения этого сеанса требований представлено слева от ветви, а именно [требования ясны]. Если это условие не выполняется, [else], используется другая стрелка.
Интеграция обоих типов диаграмм довольно проста. Каждое действие или действие приводит к концепции. Они соединены пунктирной стрелкой с произведенными артефактами, как показано на Рисунке 9. Концепции и действия на этом рисунке абстрактны.
В таблице 1 представлена общая таблица с описанием видов деятельности, подвидов деятельности и их отношения к концепциям. В разделе 5 приведены примеры диаграммы данных процесса и таблицы действий.
Мероприятия Под-действие Описание Мероприятие 2 Подвид деятельности 4 Подвид деятельности 4 приводит к СТАНДАРТНОЙ КОНЦЕПЦИИ
- Таблица 1: Таблица активности
Пример диаграммы данных процесса
На рисунке 10 проиллюстрирован пример диаграммы данных процесса. Это касается примера из фазы ориентации сложного проекта в методе WebEngineering.[1]
Примечательно использование открытых и закрытых концепций. Поскольку управление проектами фактически не входит в рамки данного исследования, понятие КОНТРОЛЬНОЕ УПРАВЛЕНИЕ не было расширено. Однако в сложном проекте УПРАВЛЕНИЕ РИСКАМИ имеет большое значение. Поэтому был сделан выбор в пользу расширения концепции УПРАВЛЕНИЯ РИСКАМИ.
В Таблице 2 описаны виды деятельности и подвиды деятельности, а также их отношение к концепциям.
Мероприятия Под-действие Описание Опишите проект Описание проекта осуществляется с точки зрения участников, целей, продуктов, объема и предположений. Эта информация взята из предложения, но с большим упором на вопросы управления проектом. Работа завершается ОПИСАНИЕМ проекта. Построить планирование Опишите фазы проекта ПЛАНИРОВАНИЕ разделено на пять ЭТАПОВ ПРОЕКТА, которые следует кратко описать. Построить планирование Опишите деятельность ДЕЯТЕЛЬНОСТЬ проекта описана и сгруппирована в ЭТАПЫ ПРОЕКТА. Построить планирование Опишите результаты Описываются РЕЗУЛЬТАТЫ ДЕЯТЕЛЬНОСТИ по проекту. Построить планирование Настроить расписание Для каждого ДОСТАВКА устанавливается ДАТА, и для каждой АКТИВНОСТИ оценивается ВРЕМЯ. Контрольный проект В результате управления проектом появляется артефакт УПРАВЛЕНИЯ КОНТРОЛЕМ. Этот артефакт здесь не объясняется, поскольку он касается обычных вопросов управления проектами, таких как управление коммуникациями, управление прогрессом, управление изменениями и управление проблемами, которые выходят за рамки данного исследования. Контроль риска Выявить риски Выявить риски можно с помощью стандартных контрольных списков или организации семинаров по рискам. РИСКИ включены в ПЛАН ПРОЕКТА. Контроль риска Оценить риски Каждому РИСКУ предоставляется ОЦЕНКА; дается описание и оценка сложности или неопределенности проекта. Контроль риска Анализировать влияние Анализируя влияние управления рисками на ВОЗДЕЙСТВИЕ, риск влияет на успех проекта. Значения оценки и риска указываются путем выбора значения: низкого, среднего или высокого. Контроль риска Приоритет рисков Приоритезация рисков осуществляется путем объединения ВЛИЯНИЯ и ОЦЕНКИ в таблицу. Тогда высокий приоритет отдается РИСКАМ с наивысшими баллами. Определите действия для стратегии риска Действия по стратегии риска можно почерпнуть из опыта или из соответствующей литературы. Менеджер проекта адаптирует действия к проекту в СПИСОК ДЕЙСТВИЙ ДЛЯ СТРАТЕГИИ РИСКА. РИСКИ с наивысшим приоритетом находятся в верхней части списка и должны обрабатываться в первую очередь.
- Таблица 2: Действия и вспомогательные мероприятия на этапе комплексной ориентации
Смотрите также
- Начало приобретения (ISPL)
- Управление изменениями (инжиниринг)
- Метод разработки динамических систем
- Управление безопасностью ITIL
- Оценка модели зрелости внедрения
- Управление границами этапов
- Моделирование метаданных
- Методология объектного процесса
- Предварительный просмотр
- Разработка семейства продуктов
- Моделирование структуры продукта
- Модель синхронизации
Рекомендации
- ^ а б И. Ван де Верд, Дж. Соуэр, Дж. Версендал и Сяак Бринкемпер (2005). Разработка ситуационных требований к реализациям управления веб-контентом. SREP2005.
Эта статья нужны дополнительные цитаты для проверка.Ноябрь 2008 г.) (Узнайте, как и когда удалить этот шаблон сообщения) ( |