Стоимостной анализ (Activity Based Costing)

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

Рекомендации по построению IDEF0-диаграммы:

1. Диагональное расположение работ.

2. Максимальное расстояние между стрелками на одной грани работы.

3. Максимальное расстояние между работами, поворотами и пересечениями стрелок.

4. Объединение похожих информационных стрелок.

Создание отчетов в BPWin’e

Отчеты:

1. Modal Report – отчет по модели. Наиболее общий отчет.

2. Diagram report – отчет по конкретной диаграмме.

3. Diagram Object – отчет об объектов модели. Он содержит список всех объектов системы. (В лабе).

4. Activity Cost Report – отчет о результатах стоимостного анализа.

5. Arrow Report - Отчет о стрелках.

6. Date Usage Report – отчет о результатах связывания модели процессов и модели данных.

7. Modal Consistency Report – Отчет об ошибках модели. (В лабе).

Типы ошибок:

1. Синтаксические. Не обнаруживаются.

2. Принципиальные. Не допускаются.

3. Обнаруживаемые.

   1. Безымянные работы и стрелки.

   2. Не связанные граничные стрелки.

   3. Не разрешенные стрелки. Туннелированные

   4. Работы без выхода или управления.

Диаграммы потоков данных

Date Flow Diagram – методология структурного анализа, описывающая внешнее по отношению к системе источники и приемники данных, логические функции, потоки данных и хранилища данных.

Основные элементы

Описание самого элемента	Йордан Де Марка	Гейн - Сарсон
Внешняя сущность – материальный объект или физическое лицо, выступающее в качестве источника или приемника информации.
Процесс (работа, система, подсистема) – осуществляет обработку входных потоков данных.
Поток данных – процесс передачи информации от источника к приемнику.
Хранилище или накопитель данных – абстрактные устройства для хранения данных. Тип устройства, способы размещения, извлечения данных для него не детализируют.

Пример

Этапы построения ДВД диаграмм:

1. Построение контекстной диаграммы. Действия:

   1. Классификация множество требований и организация их в основные функциональные группы - процессы.

   2. Идентификация внешних объектов – внешних сущностей, с которыми система взаимодействует.

   3. Идентификация основных видов информации – потоков данных, циркулирующих между системой и внешними объектами.

   4. Построение контекстной диаграммы путем объединения всех процессов в один и группирование потоков.

2. Формирование иерархии детализирующих диаграмм. Действия:

   1. Проверка и изучение основных требований по анализируемой или детализируемой диаграмме.

   2. Декомпозиция процессов текущей диаграммы с помощью детализирующих диаграмм.

   3. Ревизия модели с целью проверки ее на корректность и для улучшения наглядности.

Условия завершения детализации процесса

1. Процесс взаимодействует с двумя – тремя потоками данных

2. Возможно описание процесса последовательным алгоритмам.

3. Процесс выполняет единственную логическую функцию преобразования входных данных.

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

М оделирование управляющих процессов с помощью диаграмм потоков данных.

Основные элементы диаграммы управляющих потоков

1. Управляющие \\данными//

2. Управляющий поток данных.

3. Хранилище управляющих данных.

Управляющий процесс получает с помощью управляющих потоков информацию о состоянии системы и генерирует новые управляющие потоки для инициализации процессов.

Типы управляющих потоков:

1. Т – поток (триггерный поток). Поток, который может переключать управляемый процесс.

2. А – поток (активирующий поток). Поток, который только включает процесс.

3. Enable/Disable – поток имеющий две линии по линии E он может включать, по линии D выключать процесс.

Узел изменения - позволяет получать управляющие потоки из потока данных.

Моделирование данных.

Цель моделирования: разработка концептуальных схем данных в форме модели, которые может быть отображены в любую СУБД.

Нотация Бартена

Основные элементы:

1. Сущность – множество объектов предметной области, обладающие одинаковыми свойствами.

2. Атрибут

3. Связь

Требования к сущности:

1. Н аличие уникального имени.

2. Н аличие атрибутов.

3. Наличие идентификаторов.

Виды сущностей:

1. Независимая. Представляет независимые данные, которые всегда присутствуют в системе. Она может быть как связана, так и не связана с другими с сущностями.

2. Зависимая. Представляет данные, зависящие от других сущностей. Она всегда связана с другими сущностями.

Типы зависимых сущностей:

1. Характеристическая. Зависимая дочерняя сущность, которая связана с одной родительской и хранит информацию о ее характеристиках.

2. Ассоциативная – представляет данные, описывающие отношения между сущностями.

3. Именующая – частный случай ассоциативной сущности, не имеющий собственных атрибутов.

Для сущностей определены понятия супертип и подтип.

Супертип – сущность, обобщающая группу других сущностей, характеризуемых общими атрибутами и связями.

Подтип – обобщаемая сущность (категориальная сущность)

Атрибут – значимая характеристика или свойства сущности.

Типы атрибутов:

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

   1. Уникальность.

   2. Компактность.

2. Описательные. Это неключевые атрибуты, которые могут быть не определены, т.е. обязательные(обозначается * ) и необязательные(обозначатся о ).

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

Виды связей:

1. Обязательная. В связи должна участвовать хотя бы одна сущность (ненулевая кратность)

2. Необязательная.

3. Взаимоисключающая. Экземпляр сущности может одновременно участвовать только в одной связи из некоторой группы связи.

4. Рекурсивная. Сущность может быть связана сама с собой.

5. Н еперемещаемая. Экземпляр сущности не может быть перенесен из одной связи в другую.

Уровни логической модели

1. Модель «сущность – связь». Модель концептуального уровня.

2. Модель, основанная на ключах. Включает описание первичных ключей.

3. Полная атрибутивная модель. Детальное представление структуры данных. Отображаются все сущности и атрибуты.

Объектный подход

Объектная декомпозиция представления разрабатываемые ПО ввиду совокупности

U ML (Unitied modeling language)

Модели объектного подхода:

1. Модель использования – описание функциональности программного обеспечения с точки зрения пользователя

2. Логическая описывает ключевые абстракции программного обеспечения обеспечивающие функциональность.

3. Модель процессов описывает организацию вычислений (понятия процессы Unity)

4. Модели реализации определяет реальную организацию программных модулей программного обеспечения.

5. Модели развертывания отображает особенности размещения программных модулей на конкретном оборудовании.

Диаграммы Uml

1. Варианты использования (Диаграммы прецедентов)

2. Классов

3. Деятельностей (Activity)

4. Пакетов

5. Последовательностей действий

6. Коопераций

7. Состояний

8. Компонентов

9. Размещение