Диаграмма потоков данных системы. Методология DFD: AS - IS

 

Для упрощения анализа функционального состава системы были использованы диаграммы потоков данных (DFD), которые позволяют отражать функции обработки информации, объекты (документы, сотрудники и проч.), участвующие в обработке информации, внешние ссылки, которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы и таблицы для хранения данных. [2]

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

Модель AS – IS. Описание разработки DFD:

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

Рассмотрение объекта автоматизации как «черного ящика» системы «AS - IS», приведено в диаграмме потоков данных(см. приложение B рисунок B.1.) с использованием методологии DFD. В данной диаграмме:

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

2) Конкретная функция системы или процесс – система проведения турниров.

3) Источник/приемник данных от системы (внешняя сущность) – секретарь, преподаватель, жюри, участники турнира и т.д.

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

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

Дерево процессов диаграмм потоков данных по методологии DFD («AS - IS») представлено на рисунке 2:

.

Рисунок 2. Диаграмма потоков данных DFD (AS-IS)

 

В приложении B на рисунке B2 приведена диаграмма DFD (AS-IS), представляющая декомпозицию первого уровня модели «чёрного ящика» - «Система проведения турниров», включающая в свой состав шесть функциональных блоков: «Подготовка турнира», «Подготовка места для проведения турнира», «Создание списка участников турнира», «Проведение турнира», «Анализ проведенного турнира», «Создание и публикация отчетов» и как показано на рисунке 2:

1. Функциональный блок «Подготовка турнира» включает в свой состав три функциональных блока (см. приложение B рисунок B3):

- Сбор необходимых ресурсов для разработки задач турнира;

- Формирование пакета задач;

- Формирование папки бланков ответов и заданий турнира.

2. Функциональный блок «Подготовка места для проведения турнира» включает в свой состав два функциональных блока (см. приложение B рисунок B4):

- Поиск необходимого места для проведения турнира;

- Подготовка территории для проведения турнира.

3. Функциональный блок «Создание списка участников» включает в свой состав три функциональных блока (см. приложение B рисунок B5):

- Ознакомление с правилами;

- Принятие решения об участии в турнире;

- Формировании списка участников турнира;

4. Функциональный блок «Проведение турнира» включает в свой состав четыре функциональных блока (см. приложение B рисунок B6):

- Запуск турнира;

- Выдача заданий турнира;

- Написание ответов на вопросы турнира;

- Проверка решений;

5. Функциональный блок «Анализ проведенного турнира» включает в свой состав четыре функциональных блока (см. приложение B рисунок B7):

- Предварительный подсчет;

- Рассмотрение жалоб;

- Перерасчет результатов;

- Формирование окончательных результатов;

6. Функциональный блок «Создание и публикация отчетов» включает в свой состав четыре функциональных блока (см. приложение B рисунок B8):

- Принятие решения о закрытии турнира;

- Формирование отчета о прошедшем турнире;

- Публикация и информирование о результатах турнира;

- Анализ окончательных результатов;

 

Итак, для примера можно прокомментировать диаграмму декомпозиции функционального блока «Подготовка турнира»(см. приложение B рисунок B3.):

В процесс сбора необходимых ресурсов для разработки задач турнира поступает поток данных, представляющий собой ресурсы для создания турнира. После этого необходимые ресурсы для формирования задач турнира поступают в процесс формирования пакета задач, куда так же поступает поток данных, представляющий собой информацию о формировании пакета задач. В данном процессе пакет задач формируется и поступает в процесс формирования папки бланков ответов и заданий турнира, которая в свою очередь, сохраняется в хранилище (накопителе данных) «Список вопросов и ответов турнира».

 

1.4 Оценка затрат и предварительный расчет ожидаемой эффективности АСОИУ. Методология DFD: AS - IS

 

FP (Functional Points) – это методология оценивания функционального размера для оценки ожидаемой эффективности, проектируемой ИС, которая заключается в единообразном измерении всех возможностей приложения и выражении размера приложения в виде одного числа. Затем это число можно использовать для оценки числа строк кода, стоимости и сроков проекта. [2]

Для вычисления функционального размера необходимо определить ранг для каждой информационной характеристики (вычисление производится от внешних хранилищ данных). Информационные характеристики и их ранг представлены в таблице 2.

 

Таблица 2. Информационные характеристики и их ранг

Хранилища	Информационная характеристика	Ссылки	Элементы данных	Ранг
Текущий турнир	Внут. лог. файл			Средний (10)
Текущий турнир	Внешний ввод			Высокий (6)
Текущий турнир	Внешний вывод			Средний (5)
Текущий турнир	Внешний запрос			Средний (4)
Место для турнира	Внут. лог. файл			Низкий (7)
Место для турнира	Внешний ввод			Низкий (3)
Место для турнира	Внешний вывод			Низкий (4)
Участники турнира	Внут. лог. файл			Низкий (7)
Участники турнира	Внешний ввод			Низкий (3)
Участники турнира	Внешний вывод			Низкий (4)
Список вопросов, ответов турнира	Внут. лог. файл			Низкий (7)
Список вопросов, ответов турнира	Внешний ввод			Средний (4)
Список вопросов, ответов турнира	Внешний вывод			Средний (5)
Отчеты	Внут. лог. файл			Низкий (7)
Отчеты	Внешний ввод			Низкий (3)
Отчеты	Внешний вывод			Средний (5)

 

Где:

1. Внешний ввод – элементарный процесс, перемещающий данные из внешней среды в приложение.

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

3. Внешний запрос – элементарный процесс, работающий как с вводимыми, так и с выводимыми данными. Его результат – данные, возвращаемые из внутренних логических файлов и внешних интерфейсных файлов.

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

Перейдем к расчету метрики — количества функциональных указателей FP. В таблицу 3 заносятся количественное значение характеристики каждого вида (по всем уровням сложности). Полученные в каждой характеристике значения суммируются, после чего формируется общее количество информационных характеристик. [2]

 

Таблица 3. Исходные данные для расчета FP – метрик

Имя характеристики	Количество
Низкий	Средний	Высокий	Итого
Внешние вводы	3 * 3 = 9	1 * 4 = 4	1 * 6 = 6
Внешние выводы	2 * 4 = 8	3 * 5 = 15	0 * 7 = 0
Внешние запросы	0 * 3 = 0	1 * 4 = 4	0 * 6 = 0
Внутренние логические файлы	4 * 7 = 28	1 * 10 = 10	0 * 15 = 0
Внешние интерфейсные файлы	0 * 5 = 0	0 * 7 = 0	0 * 10 = 0
Общее количество:

 

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

FP = Общее количество × (0, 65+ 0, 01 × ), (1)

где Fi – коэффициенты сложности. Каждый коэффициент может принимать следующие значения: 0 – нет влияния, 1 – случайное, 2 – небольшое, 3 – среднее, 4 – важное, 5 – основное.

Значение каждого – ого коэффициента определяется эмпирически в результате ответа на 14 вопросов, которые характеризуют системные параметры приложения (см. таблицу 4).

 

Таблица 4. Определение системных параметров приложения

№	Системный параметр	Значение
	Передача данных
	Распределенная обработка данных
	Производительность
	Распространенность используемой конфигурации
	Скорость транзакций
	Оперативный ввод данных
	Эффективность работы конечного пользователя
	Оперативное обновление
	Сложность обработки
	Повторная используемость
	Легкость инсталляции
	Легкость эксплуатации
	Разнообразные условия размещения
	Гибкость
Итого:

 

Подставив значения из таблицы 3 в формулу 1, получим количество функциональных указателей:

FP = 84 × (0, 65+ 0, 01 × 43) = 90, 72, (2)

После вычисления функционального размера FP формируются метрики производительности, качества и т. д. Для этого с помощью стандартных таблиц по функциональному размеру вычисляют количество строк кода (см. таблицу 5). [2]

 

Таблица 5. Языки программирования и количество их операторов на один FP

Язык программирования	Количество операторов (LOC) на один FP
Ассемблер
С
Паскаль
С++
Java/С#
Visual C++
Visual Basic
Delphi Pascal
Perl

 

FP – оценки легко пересчитать в LOC – оценки, а результаты пересчета зависят от языка программирования, используемого для реализации ПО. Подсчитаем количество строк для языка C#. Для этого количество функциональных указателей умножим на количество операторов языка C# на один FP, которое равно 53.

(3)

Причины выбора данного языка обусловлены тем, что С# - это очень удобный и мощный язык среды разработки ПО Microsoft Visual Studio 2010 (которая в свою очередь не требует установки дополнительного ПО) и в сочетании с технологией.Net – это лучший подход для написания ПО под Windows на сегодняшний день. Так же «приятным» плюсом данного языка является то, что к нему предоставляется полная и подробная документация на русском языке.

Для оценивания затрат труда и продолжительности проекта необходимо использовать конструктивную модель стоимости СОСОМО Барри Боэма. [2]

COCOMO состоит из иерархии трех последовательно детализируемых и уточняемых форм. Первый уровень – базовый (COCOMO Model 1: Basic), подходит для быстрых, ранних оценок стоимости разработки ПО и обладает неточностью вследствие некоторых факторов, которые невозможно учесть на ранних стадиях разработки. Средний уровень (COCOMO Model 2: Intermediate) учитывает эти факторы, тогда как детальный уровень (COCOMO Model 3: Advanced/Detailed) дополнительно учитывает влияние отдельных фаз проекта на его общую стоимость.

Подмодели СОСОМО могут применяться к трем типам программных проектов. По терминологии Боэма, их образуют:

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

2. Полунезависимый тип – средний по размеру проект, выполняется группой разработчиков с разным опытом, устанавливаются как мягкие, так и жесткие требования к проекту;

3. Встроенный тип – программный проект разрабатывается в условиях жестких аппаратных, программных и вычислительных ограничений.

В нашем случае ведётся разработка распространённого типа программного проекта. Уравнения базовой подмодели COCOMO имеют вид:

Е = [чел - мес]; (4)

D = [мес], (5)

где Е – затраты в человеко - месяцах, D – время разработки, KLOC – количество тысяч строк в программном продукте.

Коэффициенты а, b, с, d определяются по таблице 6.

 

Таблица 6 – Коэффициенты для базовой подмодели COCOMO

Тип проекта	а	b	c	d
Распространенный	2, 4	1, 05	2, 5	0, 38
Полунезависимый	3, 0	1, 12	2, 5	0, 35
Встроенный	3, 6	1, 20	2, 5	0, 32

 

Подставив коэффициенты a, b, c и d для распространенного типа проекта в формулы 4 и 5 получим:

[чел/мес]

[мес] 6 месяцев и 15 дней

Полученные оценки позволят скорректировать сроки выполнения проекта.

 

⇐ Предыдущая12345Следующая ⇒

Поделиться: