Федеральное государственное автономное

образовательное учреждение высшего профессионального образования

«Волгоградский государственный университет»
институт Математики и информационных технологий
кафедра Информационных систем и компьютерного моделирования

Примаченко Светлана Владимировна

Разработка планирования и моделей IDEF0, DFD для проекта
«Создание плагина для системы управления сайтом»
на основе лабораторного практикума
Курсовая работа по дисциплине «Проектирование информационных систем»

Студентка Примаченко Светлана Владимировна ______________

(Дата, подпись)

Специальность Информатика и вычислительная техника

Группа ИВТ-161

Проверил к.т.н., доцент каф. ИСКМ Полубояров В.В.______________

(Дата, подпись)

Волгоград 2018
Содержание
Введение 3

1 Создание проекта по проектированию, разработке и внедрению научно-

исследовательской работы на тему «Создание плагина для системы
управления сайтом» в приложении Serena OpenProj 4

2 Моделирование процессов установки плагина в системе управления

сайтом Wordpress в приложении Ramus Educational в виде модели IDEF0 10

2.1 Методология функционального моделирования IDEF0 10

2.2 Общие сведения 11

2.2.1 Объект автоматизации 11

2.2.2 Плановые сроки 11

2.2.3 Область применения 11

2.3 Назначение и цели разработки 11

2.3.1 Цели разработки 11

2.4 Визуализация модели 11

3 Моделирование использования Wordpress в приложении Ramus Educational

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

Заключение 20

Список литературы 22

2
Введение

Информационные системы (ИС) в современном понимании – это

основанные на средствах вычислительной техники автоматизированные
системы, предназначенные для сбора, хранения, обработки, передачи и
отображения информации в некоторой предметной области. ИС относятся к
классу так называемых сложных систем и их проектирование – это
трудоемкий и слабо формализуемый процесс [3].
Эффективность разработки ИС в решающей степени зависит от
соблюдения определенной системы принципов и методик, образующих
методологию проектирования ИС [5]. Составной частью методологии
является использование моделей для формализации и фиксации информации
о предметной области ИС, ее функциях, структуре и составе
информационных объектов, которые должны быть представлены в ИС [1].
Под проектированием информационных систем понимается процесс
разработки технической документации, связанный с организацией системы,
получения и преобразования исходной информации в результативную
информацию [13].
Актуальность данной темы заключается в том, что для эффективного
использования этого инструмента необходимо достаточно четко
представлять себе цели, которые предполагается достичь за счет
планирования.
Для эффективного управления проектами система должна быть хорошо
структурирована. Суть структуризации сводится к разбивке проекта и
системы его управления на подсистемы и компоненты, которыми можно
управлять.

3
 1 Создание проекта по проектированию, разработке и внедрению
научно-исследовательской работы на тему «Создание плагина для
системы управления сайтом» в приложении Serena OpenProj

Проектированием программного обеспечения является процесс

создания проекта программного обеспечения (ПО), кроме того, под
проектированием ПО понимают дисциплину, изучающую методы
проектирования [14].
Проектирование программного обеспечения представляет собой
частный случай проектирования процессов и продуктов.
Цель проектирования подразумевает определение внутренних свойств
системы и детализацию ее внешних (видимых) свойств в соответствии с
выданными заказчиком требованиями к программному обеспечению
(исходными условиями задачи), которые, в свою очередь, подвергаются
анализу.
Ход процесса проектирования ПО и его результаты будут зависеть не
только от состава требований, но и от опыта проектировщика (разработчика)
и от выбранной модели процесса проектирования [2].
После определения требований к программному обеспечению
разработчиком будут получены согласованный четкий план действий, график
сроков и оплат. В то же время разработчик может сократить время
разработки и повысить ее качество, а также позволяет предусмотреть любые
другие нюансы разработки, к примеру, юридические (передача авторских
прав на проектируемое программное обеспечение) [3].
При проектировании ПО заранее разработчик имеет возможность:
1) ценить время разработки и стоимость программного продукта;
2) исключить потери материальных затрат и времени на вынужденные
доработки, ненужные действия, длительное согласование;
3) избежать неудовлетворенности и разногласий между заказчиком и
исполнителем [9].
4
 Порядок разработки программного обеспечения в зависимости от
особенностей проекта может отличаться, но в общем виде он состоит из
следующих этапов:
1) Подготовки;
2) Проектирования;
3) Создания, включающего дизайн, кодирование, тестирование,
документирование;
4) Поддержки, включающей внедрение и сопровождение [12].
В процессе подготовки к проектированию должны быть решены
организационные вопросы:
1) Необходимо определить состав работ, а для этого требуется узнать,
что может предоставить заказчик (техническое задание, дизайн,
макеты), достаточны ли исходники и насколько, какие этапы они
закрывают;
2) Определиться с бюджетом и сроками: на основании имеющихся
материалов утверждают примерную стоимость, общий срок всего
проекта, а также срок и точную стоимость ближайшего этапа.
После решения организационных вопросов подписывают контракт,
получают предоплату и необходимые для работы материалы.
Удобным инструментом для планирования, управления задачами
является диаграмма Ганта. На диаграмме видны не только сами задачи, но и
их последовательность. Это позволяет ни о чём не забыть и делать всё
своевременно [11].
Для того, чтобы построить диаграмму, сначала необходимо
определить полный список всех задач проекта и время, необходимое на
выполнение каждой из них [11].
В начале своей работы я определила самые основные задачи для
написания научно-исследовательской работы, такие как:
1) Разработка заявки;
2) Разработка концепции научно-исследовательской работы;
5
 3) Разработка пояснительной записки;
4) Разработка практической части;
5) Разработка документации к допуску защиты научно-
исследовательской работы;
6) Защита научно-исследовательской работы.
На рисунке 1 представлен перечень задач и их длительность.

Рисунок 1 – Перечень задач и длительность

При создании нового проекта первой включенной в него задаче

назначается первый уровень в иерархии. Все последующие задачи по
умолчанию наследуют уровень, который имеет первая задача проекта [4].
Операции по формированию или изменению иерархической структуры
проекта наиболее удобно выполнять в представлении «Диаграмма Ганта»,
которое позволяет совместить таблицу задач с календарным графиком [11].
Перечень и длительность задач и подзадач показаны на рисунке 2.

6
 Рисунок 2 – Перечень и длительность задач и подзадач

Между задачами существуют следующие типы связей:

1) Окончание-начало. Последующая задача не может быть начата до
тех пор, пока не будут завершены все ее предшественники;
2) Начало-начало. Последующая задача не может быть начата до тех
пор, пока не будут начаты все ее предшественники;
3) Окончание-окончание. Последующая задача не может быть
завершена до тех пор, пока не будут завершены все ее
предшественники;
4) Начало-окончание. Последующая задача не может быть завершена
до тех пор, пока не будут начаты все ее предшественники [11].

В моей работе задачи верхнего уровня связываются типом «окончание-

начало».
Описание типов зависимостей между подзадачами внутри суммарных
задач и распределение ресурсов показаны на Рисунке 3.

7
 Рисунок 3 – Распределение связей между подзадачами

В основе планирования проекта лежит составление структурированного

перечня работ, реализация которых позволяет достигнуть целей проекта. Для
этого применяется диаграмма Work Breakdown Structure (или WBS-структура),
представляющая собой схему описания иерархической структуры проекта. Для
ее отображения служит кнопка WBS на вертикальной панели инструментов [6].
На рисунке 4 изображена диаграмма WBS.

8
Рисунок 4 – Диаграмма WBS

9
 2 Моделирование процессов установки плагина в системе
управления сайтом Wordpress в приложении Ramus Educational в виде
модели IDEF0

2.1 Методология функционального моделирования IDEF0

Моделирование как средство представления системы или понятия

(идеи) в некоторой форме, отличной от формы их реального существования,
обычно имеет целью объяснить и понять существо рассматриваемых
объектов. Это философское определение модели [2].
С прагматической точки зрения, модель есть инструмент, позволяющий
спрогнозировать последствия альтернативных действий с целью их
сравнения и выбора наилучшего [12].
IDEF0 – методология функционального моделирования (англ. function
modeling) и графическая нотация, предназначенная для формализации и
описания бизнес-процессов [10]. Отличительной особенностью IDEF0
является её акцент на соподчинённость объектов. В IDEF0 рассматриваются
логические отношения между работами, а не их временная
последовательность (поток работ) [7].
IDEF0 используется для создания функциональной модели, то есть
результатом применения методологии IDEF0 к системе есть функциональная
модель IDEF0 [2].
Функциональная модель – это структурное представление функций,
деятельности или процессов в пределах моделируемой системы или
предметной области [11].
Методология IDEF0 может быть использована для моделирования
широкого спектра как автоматизированных, так и неавтоматизированных
систем [8].
В основе методологии лежат четыре основных понятия:
1) функциональный блок;
2) интерфейсная дуга;
10
 3) декомпозиция;
4) глоссарий.

2.2 Общие сведения

2.2.1 Объект автоматизации

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

управления сайтом Wordpress.
Наименование разработчика: Примаченко Светлана Владимировна.
Наименование заказчика: кафедра ИСКМ.

2.2.2 Плановые сроки

Начало работ: 17.09.2018г.

Окончание работ: 20.12.2018г.

2.2.3 Область применения

Модель предназначена для установки и настройке плагина в системе

управления сайтом Wordpress.

2.3 Назначение и цели разработки

2.3.1 Цели разработки

Разработка и создание плагина для системы управления сайтом

Wordpress для последующего его использования.

2.4 Визуализация модели

Родительская и дочерняя диаграммы изображены на рисунках 5, 6.

11
Рисунок 5 – Родительская модель

12
Рисунок 6 – Дочерняя диаграмма

13
 3 Моделирование использования Wordpress в приложении Ramus
Educational при помощи диаграмм потоков данных

Диаграмма потоков данных – это инструмент моделирования,

позволяющий получить иллюстрацию системы в виде сети функциональных
процессов, соединенных один с другим стрелками данных [14].
Диаграммы потоков данных являются основным средством
моделирования функциональных требований к проектируемой системе.
Главная цель DFD – показать, как каждая работа преобразует свои
входные данные в выходные, а также выявить отношения между этими
работами [8].
Диаграммы потоков данных (Data Flow Diagrams – DFD) используются
для описания движения документов и обработки информации как
дополнение к IDEF0. В отличие от IDEF0, где система рассматривается как
взаимосвязанные работы, стрелки в DFD показывают лишь то, как объекты
(включая данные) движутся от одной работы к другой [11].
Нотация DFD – удобное средство для формирования контекстной
диаграммы, то есть диаграммы, показывающей разрабатываемую АИС в
коммуникации с внешней средой [4]. Это – диаграмма верхнего уровня в
иерархии диаграмм DFD. Ее назначение – ограничить рамки системы,
определить, где заканчивается разрабатываемая система и начинается среда.
Другие нотации, часто используемые при формировании контекстной
диаграммы – диаграмма SADT, диаграмма Диаграмма вариантов
использования [6].
Для решения задачи функционального моделирования на базе
структурного анализа традиционно применяются два типа моделей: IDEF0-
диаграммы и диаграммы потоков данных [3].
Методология разработки процессных диаграмм обычно применяется
при проведении обследований предприятий в рамках проектов
управленческого консалтинга, а также в проектах автоматизации крупных
14
 объектов при экспресс-обследовании (обычно для составления
развернутого плана работ) [6].
Нотация диаграмм потоков данных позволяет отображать на диаграмме
как шаги бизнес-процесса, так и поток документов и управления (в основном,
управления, поскольку на верхнем уровне описания процессных областей
значение имеет передача управления). Также на диаграмме можно
отображать средства автоматизации шагов бизнес-процессов. Обычно
используется для отображения третьего и ниже уровня декомпозиции бизнес-
процессов (первым уровнем считается идентифицированный перечень
бизнес-процессов, а вторым – функции, выполняемые в рамках бизнес-
процессов) [8].
Диаграммы потоков данных (Data flow diagramming, DFD):
1) являются основным средством моделирования функциональных
требований к проектируемой системе;
2) создаются для моделирования существующего процесса движения
информации;
3) используются для описания документооборота, обработки
информации;
4) применяются как дополнение к модели IDEFO для более
наглядного отображения текущих операций документооборота
(обмена информацией);
5) обеспечивают проведение анализа и определения основных
направлений реинжиниринга ИС.
Диаграммы DFD могут дополнить то, что уже отражено в модели
IDEF0, поскольку они описывают потоки данных, позволяя проследить,
каким образом происходит обмен информацией как внутри системы между
бизнес-функциями, так и системы в целом с внешней информационной
средой [9].
Диаграмма потоков данных содержит:
1) процессы, которые преобразуют данные;
15
 2) потоки данных, переносящие данные;
3) активные объекты, которые производят и потребляют данные;
4) хранилища данных, которые пассивно хранят данные.

Диаграмма DFD показывает внешние по отношению к системе

источники и приемники данных, идентифицирует логические функции
(процессы) и группы элементов данных, связывающие одну функцию с
другой (потоки), а также идентифицирует накопители (хранилища) данных, к
которым осуществляется доступ [11]. Структуры потоков данных и
определения их компонентов хранятся и анализируются в словаре данных.
Каждая логическая функция (процесс) может быть детализирована с
помощью DFD нижнего уровня; когда дальнейшая детализация перестает
быть полезной, переходят к выражению логики функции при помощи
спецификации процесса нижнего уровня (мини-спецификации). Содержимое
каждого накопителя также сохраняют в словаре данных, модель данных
накопителя раскрывается с помощью ERD. В случае построения
поведенческой модели DFD дополняется средствами описания, зависящего
от времени поведения системы, раскрывающегося с помощью STD.[4]
Назначение процесса состоит в продуцировании выходных потоков из
входных в соответствии с действием, задаваемым именем процесса. Это имя
должно содержать глагол в неопределенной форме с последующим
дополнением (например, Выставить счет) или отглагольное существительное
(например, Выставление счета) [1]. Кроме того, каждый процесс должен
иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер
может использоваться совместно с номером диаграммы для получения
уникального индекса процесса во всей модели. Процессы (работы) DFD
преобразуют значения данных и изображается в виде эллипса, внутри
которого помещается имя процесса. Они имеют входы и выходы, но не
поддерживают управления

16
и механизмы, как IDEF0. Все стороны работы равнозначны. В каждую
работу может входить и выходить по несколько стрелок [1].
Поток данных является механизмом, использующимся для
моделирования передачи информации (или даже физических компонентов)
из одной части системы в другую. Потоки на диаграммах обычно
изображаются именованными стрелками (при этом имя потока отражает его
содержимое), ориентация которых указывает направление движения
информации [11].
Поток данных соединяет выход объекта (или процесса) с входом
другого объекта (или процесса). Потоки данных могут разветвляться или
сливаться, что означает соответственно разделение потока данных на части
либо слияние объектов [13].
Потоки данных описывают движение объектов из одной части системы
в другую (отсюда следует, что диаграмма DFD не может иметь граничных
стрелок). Поскольку все стороны работы в DFD равнозначны, стрелки могут
начинаться и заканчиваться на любой стороне процесса, хранилища данных,
внешней сущности. Стрелки могут быть двунаправлены.
Хранилище данных (накопитель) – это пассивный объект в составе
DFD, в котором данные сохраняются вне процессов для последующего
доступа [11].
Активным объектом (внешней сущностью) является объект, который
обеспечивает движение данных, поставляя или потребляя их.
Важную специфическую роль в модели играет специальный вид DFD –
контекстная диаграмма, моделирующая систему наиболее общим образом.
Контекстная диаграмма отражает интерфейс системы с внешним миром, а
именно информационные потоки между системой и внешними сущностями,
с которыми она должна быть связана [11]. Она идентифицирует эти внешние
сущности, а также, как правило, единственный процесс, отражающий
главную цель или природу системы, насколько это возможно. И хотя

17
контекстная диаграмма выглядит тривиальной, несомненная ее полезность
заключается в том, что она устанавливает границы анализируемой системы.
Готовая модель использования системы управления сайтом Wordpress
показаны на рисунках 7, 8.

Рисунок 7 – Родительская диаграмма

18
Рисунок 8 – Дочерняя диаграмма

19
 Заключение

Итак, планирование проекта – определение внутренних свойств

системы и детализацию ее внешних (видимых) свойств в соответствии с
выданными заказчиком требованиями к программному обеспечению
(исходными условиями задачи), которые, в свою очередь, подвергаются
анализу [5]. В ходе планирования составляется программный документ,
программа осуществления бизнес-операций, действий фирмы, содержащая
сведения о фирме, товаре, его производстве, рынках сбыта, маркетинге,
организации операций и их эффективности. Является очень важным этапом
проектирования [9].

На диаграммах IDEF0 не делается акцент на том, какие потоки там

обрабатываются, поэтому диаграммы IDEF0 позволяют представить работу
системы с позиции обработки любого вида потоков. Таким образом,
диаграммы IDEF0 позволяют рассматривать системы с позиции различных
функциональных областей. В частном случае, на них можно представить и
информационные потоки. Особого отличия в обозначениях информационных
и других потоков в модели IDEF0 нет [10]. Поэтому, модель IDEF0 можно
считать универсальной моделью, применимой для описания систем с разных
точек зрения. Возможность декомпозиции процессов на диаграммах
позволяет представить функции через операции.

Модель на основе диаграмм потоков данных (DFD) позволяет

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

20
также можно считать информационным потоком, который содержит
управляющую информацию [10]. Если поток данных содержит какую-либо
информацию о материальном потоке (например, его количественное и
качественное описание), то поток управления содержит информацию,
определяющую, какие манипуляции должны быть произведены с
информационным потоком.

В ходе выполнения курсовой работы был создан план создания

выполнения научно-исследовательской работы «Создание плагина для
системы управления сайтом». Смоделированы процессы установки плагина в
системе управления сайтом Wordpress в приложении Ramus Educational в
виде моделей IDEFO и DFD.

21
 Список литературы

1. Белов В. В. Проектирование информационных систем: учебник для

студ.учреждений высш. проф. образования / В. В. Белов, В. И.
Чистякова ; под ред. В. В. Белова [Текст]. – М. : Издательский центр
«Академия», 2013. – 352 с.;
2. Волкова В.Н. Моделирование систем и процессов : учебник для
академического бакалавриата / В. Н. Волкова, Г. В. Горелова, В. Н.
Козлов [Текст].– М. : Издательство Юрайт, 2015. – 449 с.;
3. Гвоздева Т.В. Проектирование информационных систем/ Т.В. Гвоздева,
Б.А. Баллод [Текст]. – Феникс, 2009. – 508 с.;
4. Грекул В.И. Проектирование информационных систем. Курс лекций.
Учебное пособие/ В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина
[Текст]. – М.: Интернет-университет информационных технологий,
2005. – 304 с.;
5. Дубенецкий, Б.Я. Проектирование информационных систем. / Б.Я.
Дубенецкий. – Л.: ЛЭТИ, 2008 г. – 675 с.;
6. Жданов С.А. Информационные системы/ С. А. Жданов [Текст]. –
Прометей, 2015. – 227 с.;
7. Замятина О. М. Моделирование систем: Учебное пособие/ О.М.
Замятина [Текст].– Томск:Изд-во ТПУ, 2009. – 204 с.;
8. Избачков Ю.С. Информационные системы/ Ю.С. Избачков, В.Н.
Петров [Текст]. – СПб.: 2011. – 544 с;
9. Коцюба И.Ю. Основы проектирования информационных систем/ И. Ю.
Коцюба, А. В. Чунаев, А. Н. Шиков [Текст]. – СПб.: Питер, 2015. – 256
с.;
10. Петров А.В. Моделирование процессов и систем: Учебное пособие/
А.В. Петров [Текст]. – Лань, 2015. – 288 с;
11. Проектирование информационных систем – лабораторный практикум;

22
12. Сафонов, В.И. Компьютерное моделирование: учебное пособие / В.И.
Сафонов[Текст]. – Мордов. гос. пед. ин-т. – Саранск, 2009. – 92 с.;
13. Соловьев И.В. Проектирование информационных систем.
Фундаментальный курс. Учебное пособие для высшей школы/ И.В.
Соловьев, А.А. Майоров [Текст]. – Академический проект, 2009. – 398
с;
14. Чистова Д.В. Проектирование информационных систем: учебник и
практикум для академического бакалавриата/ Д.В. Чистова [Текст]. –
М. : Юрайт, 2017. – 258 с.;

23
24