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

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

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

Маргоскина Алѐна Михайловна

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

Студентка Маргоскина Алѐна Михайловна ______________

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

Специальность Программная инженерия

Группа ПрИ-161

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

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

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

Введение 3

1 Создание проекта по проектированию, разработке и внедрению НИР на

тему «Опыт классификации космоснимка Sentinel-2а» в приложении Serena
OpenProj. 4

2 Моделирование процессов получения космоснимка с помощью

Earthexplorer в приложении Ramus Educational в виде модели IDEFO 9
2.1 Общие сведения 10

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

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

2.3 Назначение классификации космоснимков 11

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

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

Educational при помощи диаграмм потоков данных 13
Заключение 17

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

2
 Введение

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

правовых форм по его созданию. Деятельность во время разработки проекта
без плана есть реакция на совершающиеся события, деятельность на основе
плана – реакция на предвиденные и запланированные явления. Говорят, что
«Человек, который неудачно планирует, планирует неудачу».
Актуальность данной темы заключается в том, что управление проек-
том представляет собой методологию организации, планирования, руковод-
ства, координации человеческих и материальных ресурсов на протяжении
жизненного цикла проекта (говорят также проектного цикла), направленную
на эффективное достижение его целей путем применения системы современ-
ных методов, техники и технологий управления для достижения определен-
ных в проекте результатов по составу и объему работ, стоимости, времени,
качеству.
Для эффективного управления проектами система должна быть хорошо
структурирована. Суть структуризации сводится к разбивке проекта и систе-
мы его управления на подсистемы и компоненты, которыми можно управ-
лять.

3
 1 Создание проекта по проектированию, разработке и внедрению
НИР на тему «Опыт классификации космоснимка Sentinel-2а» в прило-
жении Serena OpenProj.

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

ния проекта программного обеспечения (ПО), кроме того, под проектирова-
нием ПО понимают дисциплину, изучающую методы проектирования.
Проектирование программного обеспечения представляет собой част-
ный случай проектирования процессов и продуктов.
Цель проектирования подразумевает определение внутренних свойств
системы и детализацию ее внешних (видимых) свойств в соответствии с вы-
данными заказчиком требованиями к программному обеспечению (исходны-
ми условиями задачи), которые, в свою очередь, подвергаются анализу.
Ход процесса проектирования ПО и его результаты будут зависеть не
только от состава требований, но и от опыта проектировщика (разработчика)
и от выбранной модели процесса проектирования.[2]
После определения требований к программному обеспечению разра-
ботчиком будут получены согласованный четкий план действий, график сро-
ков и оплат. В то же время разработчик может сократить время разработки и
повысить ее качество, а также позволяет предусмотреть любые другие нюан-
сы разработки, к примеру, юридические (передача авторских прав на проек-
тируемое программное обеспечение).[3]
При проектировании ПО заранее разработчик имеет возможность:
 оценить время разработки и стоимость программного продукта;
 исключить потери материальных затрат и времени на вынужденные
доработки, ненужные действия, длительное согласование;
 избежать неудовлетворенности и разногласий между заказчиком и ис-
полнителем.

4
 Порядок разработки программного обеспечения в зависимости от особен-
ностей проекта может отличаться, но в общем виде он состоит из следующих
этапов:
1. Подготовки.
2. Проектирования.
3. Создания, включающего дизайн, кодирование, тестирование, докумен-
тирование.
4. Поддержки, включающей внедрение и сопровождение.
В процессе подготовки к проектированию должны быть решены органи-
зационные вопросы:
1. Необходимо определить состав работ, а для этого требуется узнать, что
может предоставить заказчик (техническое задание, дизайн, макеты),
достаточны ли исходники и насколько, какие этапы они закрывают.
2. Определиться с бюджетом и сроками: на основании имеющихся мате-
риалов утверждают примерную стоимость, общий срок всего проекта, а
также срок и точную стоимость ближайшего этапа.[3]
При описании взаимосвязи и иерархии задач проекта представляется
наиболее рациональной такая последовательность действий:
1. Описание состава наиболее важных мероприятий и их взаимосвязи в
виде сетевого графика (в окне представления Диаграмма Ганта).
В начале своей работы я определила самые основные задачи для написа-
ния НИР, такие как:
a) Разработка заявки
b) Разработка концепции НИР
c) Разработка пояснительной записки
d) Разработка практической части
e) Разработка документации к допуску защиты НИР
f) Защита НИР
Длительность и перечень всех задач показаны на Рисунке 1.

5
 Рисунок 1 - Перечень основных задач

2. Уточнение типа связи между задачами верхнего уровня.

В своей работе задачи верхнего уровня связываются типом «окончание-
начало»
3. Разбиение некоторых задач верхнего уровня на подзадачи.
Перечень и длительность задач показаны на Рисунке 2.

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

4. Описание типа зависимости между подзадачами внутри суммарных за-

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

Рисунок 3 - Распределение связей

7
 Существует удобный инструмент для визуальной оценки стоимости
отдельных работ в составе проекта – диаграмма WBS (Work breakdown
structure — структура декомпозиции работ), представляющая собой схему
описания иерархической структуры проекта. Для ее отображения служит
кнопка WBS на вертикальной панели инструментов (Рисунок 4).[1]

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

8
 2 Моделирование процессов получения космоснимка с помощью
Earthexplorer в приложении Ramus Educational в виде модели IDEFO

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

тически во всех областях знаний. Особенно это относится к вопросам управ-
ления сложными системами различной физической природы, где основными
являются процессы принятия решений на основе получаемой информации.
Так существующие и проектируемые системы поддаются эффективному ис-
следованию с помощью математических моделей, реализуемых на современ-
ных компьютерах, которые в этом случае играют роль инструмента экспери-
ментатора в работе с моделью системы.[4]
IDEF0 - Function Modeling - методология функционального моделиро-
вания и графическая нотация, предназначенная для формализации и описа-
ния бизнес-процессов. Отличительной особенностью IDEF0 является еѐ ак-
цент на соподчинѐнность объектов.
Средства IDEF0 облегчают передачу информации от одного участника
разработки модели (отдельного разработчика или рабочей группы) к друго-
му.
Исходная информация для IDEF0-модели поступает к разработчику из
разных источников: от людей и от документов. Люди, являющиеся источни-
ками информации, обладают конкретными знаниями о частных свойствах
объекта моделирования, управлении или ходе бизнес–процесса и их участие в
моделировании может быть ограничено несколькими минутами опроса.
Однако именно эти источники обеспечивают основу для моделирова-
ния.[5]
Информация, предоставляемая ими, используется для создания модели,
а восприятие этой информации обеспечивает разработчику понимание, необ-
ходимое для построения точной модели.[4]

9
 Процесс моделирования в IDEF0 включает в себя:
 сбор информации об исследуемом объекте;
 документирование полученной информации и представление ее в виде
модели;
 уточнение модели посредством итеративного рецензирования.
Наглядность графического языка IDEF0 делает модель вполне читаемой и
для лиц, которые не принимали участия в проекте ее создания, а также эф-
фективной для проведения показов и презентаций. В дальнейшем на базе по-
строенной модели могут быть организованы новые проекты, нацеленные на
производство изменений в модели.[6]

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

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

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

Наименование разработчика: Маргоскина Алена.
Наименование заказчика: кафедра ИСКМ.

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

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

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

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

Модель предназначена для получения космоснимков с помощью Earthex-

plorer. [1]

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

2.2.1. Цели разработки

Получение снимков для дольнейшей их классификации для целей авто-

матизированного дешифрирования видов земель.

2.3 Назначение классификации космоснимков

Распознавание степени вегетации (развития) растений и различного вида

фитопатологий.

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

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

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

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

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

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

ляющий получить иллюстрацию системы в виде сети функциональных про-
цессов, соединенных один с другим стрелками данных.[1]
Диаграммы потоков данных являются основным средством моделиро-
вания функциональных требований к проектируемой системе.
Главная цель DFD - показать, как каждая работа преобразует свои
входные данные в выходные, а также выявить отношения между этими рабо-
тами. Диаграммы потоков данных (Data Flow Diagrams - DFD) используются
для описания движения документов и обработки информации как дополне-
ние к IDEF0. В отличие от IDEF0, где система рассматривается как взаимо-
связанные работы, стрелки в DFD показывают лишь то, как объекты (вклю-
чая данные) движутся от одной работы к другой.[1]
Диаграмма DFD показывает внешние по отношению к системе источ-
ники и приемники данных, идентифицирует логические функции (процессы)
и группы элементов данных, связывающие одну функцию с другой (потоки),
а также идентифицирует накопители (хранилища) данных, к которым осу-
ществляется доступ. Структуры потоков данных и определения их компонен-
тов хранятся и анализируются в словаре данных. Каждая логическая функция
(процесс) может быть детализирована с помощью DFD нижнего уровня; ко-
гда дальнейшая детализация перестает быть полезной, переходят к выраже-
нию логики функции при помощи спецификации процесса нижнего уровня
(мини-спецификации). Содержимое каждого накопителя также сохраняют в
словаре данных, модель данных накопителя раскрывается с помощью ERD. В
случае построения поведенческой модели DFD дополняется средствами опи-
сания, зависящего от времени поведения системы, раскрывающегося с по-
мощью STD.[4]

13
 Назначение процесса состоит в продуцировании выходных потоков из
входных в соответствии с действием, задаваемым именем процесса. Это имя
должно содержать глагол в неопределенной форме с последующим дополне-
нием (например, Выставить счет) или отглагольное существительное (напри-
мер, Выставление счета). Кроме того, каждый процесс должен иметь уни-
кальный номер для ссылок на него внутри диаграммы. Этот номер может ис-
пользоваться совместно с номером диаграммы для получения уникального
индекса процесса во всей модели. Процессы (работы) DFD преобразуют зна-
чения данных и изображается в виде эллипса, внутри которого помещается
имя процесса. Они имеют входы и выходы, но не поддерживают управления
и механизмы, как IDEF0. Все стороны работы равнозначны. В каждую работу
может входить и выходить по несколько стрелок.[1]
Поток данных является механизмом, использующимся для моделиро-
вания передачи информации (или даже физических компонентов) из одной
части системы в другую. Потоки на диаграммах обычно изображаются име-
нованными стрелками (при этом имя потока отражает его содержимое), ори-
ентация которых указывает направление движения информации. Поток дан-
ных соединяет выход объекта (или процесса) с входом другого объекта (или
процесса). Потоки данных могут разветвляться или сливаться, что означает
соответственно разделение потока данных на части либо слияние объектов.
Потоки данных описывают движение объектов из одной части системы в
другую (отсюда следует, что диаграмма DFD не может иметь граничных
стрелок). Поскольку все стороны работы в DFD равнозначны, стрелки могут
начинаться и заканчиваться на любой стороне процесса, хранилища данных,
внешней сущности. Стрелки могут быть двунаправлены.[6]
Хранилище данных (накопитель) - это пассивный объект в составе
DFD, в котором данные сохраняются вне процессов для последующего до-
ступа. Фактически накопитель представляет «срезы» потоков данных во вре-
мени. Информация, которую он содержит, может использоваться в любое
время после ее определения, при этом данные могут выбираться в любом по-
14
рядке. Имя накопителя должно идентифицировать его содержимое и быть
существительным во множественном числе. Когда процесс сохраняет дан-
ные, то стрелка потока данных направлена в накопитель данных, и, наоборот,
когда доступ к накопителю данных осуществляется для чтения, стрелка по-
тока данных направлена в процесс. Хранилище данных - это абстрактное
устройство для хранения информации, которую можно в любой момент по-
местить в накопитель и через некоторое время извлечь, причем способы по-
мещения и извлечения могут быть любыми.[5]
Активным объектом (внешней сущностью) является объект, который
обеспечивает движение данных, поставляя или потребляя их. Внешняя сущ-
ность представляет сущность вне контекста системы, являющуюся источни-
ком или приемником системных данных, например Заказчик, Поставщик,
Склад товаров. Определение некоторого объекта в качестве внешней сущно-
сти указывает на то, что он находится за пределами анализируемой системы.
Предполагается, что такие объекты не должны участвовать ни в какой обра-
ботке.
Внешние сущности изображают входы в систему и/или выходы из нее.
Одна внешняя сущность может одновременно предоставлять входы (функци-
онируя как поставщик) и принимать выходы (функционируя как получатель).
Внешняя сущность представляет собой материальный объект, например за-
казчики, персонал, поставщики, клиенты, склад. В качестве внешней сущно-
сти может выступать другая информационная система, с которой проектиру-
емая система обменивается данными.
Определение некоторого объекта или системы в качестве внешней
сущности указывает на то, что они находятся за пределами границ анализи-
руемой системы. Внешние сущности изображаются в виде прямоугольника с
тенью и обычно располагаются по краям диаграммы.[1]

15
Готовая модель использования сервера показаны на Рисунках 7, 8.

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

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

16
 Заключение
Итак, планирование проекта - это определение целей и путей их дости-
жения, посредством каких-либо намеченных и разработанных программ дей-
ствий, которые в процессе реализации могут корректироваться в соответ-
ствии с изменившимися обстоятельствами. В ходе планирования составляет-
ся программный документ, программа осуществления бизнес-операций, дей-
ствий фирмы, содержащая сведения о фирме, товаре, его производстве, рын-
ках сбыта, маркетинге, организации операций и их эффективности. Является
очень важным этапом проектирования.
Выгоды использования IDEF0 и DFD:

 Самая первая выгода очевидна – это наглядность. Вы сами начинаете по-

нимать, как работает та или иная система, и можете также наглядно пояс-
нить, где в этой системе «тонкие места» и как ваши решения помогут из-
бавиться от них.
 Взаимопонимание и отсутствие разночтений. При обсуждении работы
компании с использованием функциональной модели у вас имеются
наглядные и понятные интуитивно блоки задач с управляющими элемен-
тами. Кроме того, функциональное моделирование предполагает созда-
ние в случае необходимости глоссария, в котором раскрываются услов-
ные обозначения и термины. В результате вы с клиентом, руководителем,
другими сотрудниками при обсуждении проблемы говорите на одном
языке.
 Простота и высокая скорость создания модели. Конечно, научиться моде-
лированию не так просто, как кажется. Ведь схема — это, по сути, сверх-
плотная подача информации, что очень хорошо для понимания, но для
реализации такой подачи требуется особый подход. Мозг аналитика вы-
ступает в данном случае как очень мощный пресс с одной стороны, и
фильтр – с другой. Но с опытом этот процесс становится очень быстрым.
В результате вы получаете инструмент, который поможет и самому разо-

17
 браться, что же происходит в той или иной системе, и при помощи со-
зданного в сжатые сроки наглядного пособия проиллюстрировать важные
моменты коллегам или заказчикам.
 Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие
рамки и правила. Такой подход дисциплинирует, а привычка действовать
в рамках стандарта помогает избежать ошибок по невнимательности.
Любые нарушения стандарта становятся сразу заметными.
В ходе выполнения курсовой работы был создан план создания по выполне-
нию НИР «Классификация и получение космоснимков», структура которого
представлена на рисунке 1 и 2. Смоделированы процесс получения космо-
снимка с помощью Earthexplorer в приложении Ramus Educational в виде мо-
дели IDEFO и DFD.

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

1. Проектирование информационных систем – лабораторный практикум.

2. Проектирование информационных систем : учебник и практикум для ака-
демического бакалавриата / под ред. Д. В. Чистова. — М. : Издательство
Юрайт, 20176 - 258 с. — Серия : Бакалавр. Академический курс.
3. Белов В. В. Проектирование информационных систем : учебник для студ.
учреждений высш. проф. образования / В. В. Белов, В. И. Чистякова ; под ред.
В. В. Белова — М. : Издательский центр «Академия», 2013. — 352 с. — (Сер.
Бакалавриат).
4. Моделирование систем и процессов : учебник для академического бака-
лавриата / В. Н. Волкова, Г. В. Горелова, В. Н. Козлов [и др.] ; под ред. В. Н.
Волковой, В. Н. Козлова. — М. : Издательство Юрайт, 2015. — 449 с. — Се-
рия : Бакалавр. Академический курс.
5. Замятина О. М. М 34 Моделирование систем: Учебное пособие. – Томск:
Изд-во ТПУ, 2009. – 204 с.
6. Сафонов, В.И. Компьютерное моделирование: учебное пособие / В.И. Са-
фонов; Мордов. гос. пед. ин-т. – Саранск, 2009. – 92 с.

19