Разработка модуля "Планирование учебно-воспитательной работы" на платформе 1С: Предприятие 8

 

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

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

«Волгоградский государственный университет»

институт Математики и информационных технологий

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








Выпускная квалификационная работа специалиста по специальности

Информационные системы и технологии

Разработка модуля «Планирование учебно-воспитательной работы» на платформе 1С: Предприятие 8


ДипломникСвиточев И.О.

Научный руководительПолубояров В.В.

НормоконтролерБутенко М.А.

Рецензент к.ф. - м. н., доц. каф. МАТФ Корольков С.А.








Волгоград 2013

Содержание


Введение

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

.1 Выбор подхода к моделированию предметной области

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

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

.2.2 Методология функционального моделирования IDEF3

.2.3 Методология функционального моделирования DFD

.3 Выбор инструментального средства функционального моделирования

.3.1 Sybase PowerDesigner

.3.2 AllFusion Process Modeller

.3.3 Microsoft Visio

.3.4 Business Studio

.3.5 Ramus Educationa

. Разработка комплекса функциональных моделей предметной области «Планирование и отчетность по УВР ВолГУ»

.1 Создание модели бизнес-процессов «как есть» в нотации IDEF0

.2 Создание диаграммы бизнес-процессов «как будет» в нотации IDEF0

.3 Разработка диаграммы потоков данных

. Разработка конфигурации на платформе «1С: Предприятие 8» и ее тестирование

.1 Анализ видов информационных структур системы «1С: Предприятие 8»

.1.1 Объект конфигурации «Справочник»

.1.2 Объект конфигурации «Документ»

.1.4 Объект конфигурации «Отчет»

.2 Генерация информационных структур для модуля

.2.1 Справочник «ТипыМероприятия»

.2.2 Справочник «Мероприятия»

.2.3 Справочник «УчебныеГоды»

.2.4 Справочник «Сотрудники»

.2.5 Справочник «ФизЛица»

.2.6 Справочник «Должности»

.2.7 Перечисление «ВидыЗанятости»

.2.8 Перечисление «ТипДолжностей»

.3 Тестирование модуля «Планирование и отчетность учебно-воспитательной работы ППС»

Заключение

Литература


Введение


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

Для решения данных проблем возникает необходимость в разработке модуля по планированию и отчетности учебно-воспитательной работы в автоматизированной системе «Университет». Внедрение этого модуля позволит автоматизировать процесс учета мероприятий учебно-воспитательной работы, в которых принимает участие преподавательских состав ВолГУ, а также ускорит процесс создания отчетов по планируемому и фактическому участию в мероприятиях.

Объектом исследования является деятельность по планированию, отчетности мероприятий по учебно-воспитательной работы профессорско-преподавательского состава ВолГУ.

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

Целью работы является разработка модуля «Планирование и отчетность УВР ППС» автоматизированной системы «Университет» с использованием платформы «1С: Предприятие 8».

Для достижения цели предполагается решить ряд задач:

) Разработка моделей «как есть» и «как будет» бизнес-процессов «Планирование учебно-воспитательной работы» в нотации IDEF0 с использованием среды Ramus Educational.

) Разработка диаграммы потоков данных.

) Документирование существующей структуры данных подсистемы «Планирование и отчетность» конфигурации на платформе «1С: Предприятие 8».

) Модернизация структуры аааданных конфигурации с учетом добавления необходимых объектов конфигурации.

) Разработка модели пользовательского интерфейса.

) Разработка форм и отчетов.

Работа состоит из введения, 3-х глав и заключения.

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

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

В 3-й главе проводится анализ видов информационных структур системы «1С: Предприятие 8.1», генерируются информационные структуры для разрабатываемого модуля, разрабатывается пользовательский интерфейс.


1. Выбор методологии и инструментальных средств проектирования предметной области


.1 Выбор подхода к моделированию предметной области


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

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

Функциональные методологии рассматривают организацию как набор функций, преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенную информацию. Основное отличие от объектно-ориентированной методики определяется в четком отделении функций (методов обработки данных) от самих данных [9].

В моделях (DFD-диаграммах потоков данных, SADT-диаграммах) главными структурными компонентами являются функции (операции, действия, работы), которые на диаграммах связываются между собой потоками объектов

Достоинства:

) Реализация структурного подхода к проектированию АС по принципу «сверху-вниз», когда каждый функциональный блок может быть декомпозирован на множество подфункций и т.д., выполняя, таким образом, модульное проектирование АС. Для функциональных моделей характерны процедурная строгость декомпозиции АС и наглядность представления [29].

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

) Диаграммы, отражающие специфику структурного подхода (диаграммы классов и т.п.) наглядны и хорошо понимаемы непрофессионалами. Поэтому одна из главных целей внедрения САSЕ-технологии, а именно снабжение всех участников проекта (в том числе и заказчика) общим языком для передачи понимания, обеспечивается на сегодняшний день только структурными методами [6].

Недостатки:

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

) Функции, которые могут быть важными при создании информационной системы, могут быть опущены, в следствие того, что они не будут замечены, либо забудься в процессе проектирования. Либо их значение будет трактоваться по-иному.

) Даже при четкой логическо-структурной основе исследования и применении формальных методов оценки альтернатив и поиска наилучших

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

Объектные методики рассматривают моделируемую предметную область как набор взаимодействующих объектов - производственных единиц. Объект определяется как осязаемая реальность - предмет, явление, на которые направлена деятельность; то, что подвергается какому-либо воздействию и имеет свойства. Целью внедрения данной методики является выделение объектов, образующих организацию, и выделение между ними ответственностей по исполняемым действиям [7].

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

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

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

Для объектно-ориентированного метода созданы графические методы моделирования предметной области, обобщенные в языке унифицированного моделирования UML. Но по наглядности представления модели пользователю-заказчику объектно-ориентированные модели сильно уступают функциональным моделям [3].

Достоинства:

) Объектная декомпозиция дает возможность создавать программные системы меньшего размера путем использования общих механизмов, обеспечивающих необходимую экономию выразительных средств. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что в конце концов ведет к созданию среды разработки и переходу к сборочному созданию программного обеспечения. Системы зачастую получаются более компактными, чем их структурные эквиваленты, что означает не только уменьшение объема программного кода, но и удешевление проекта за счет использования предыдущих разработок [30].

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

) Объектная модель вполне естественна, поскольку в первую очередь ориентирована на человеческое восприятие мира, а не на компьютерную реализацию.

) Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования.

К недостаткам объектно-ориентированного подхода относятся:

) Некоторое снижение производительности функционирования ПО.

) Высокие начальные затраты.

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

) Объектно-ориентированный подход не дает немедленной отдачи. Эффект от его применения начинает сказываться после разработки двух-трех проектов и накопления повторно используемых компонентов, отражающих типовые проектные решения в данной области [1].

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

Поскольку задача учета деятельности профессорско-преподавательского состава по учебно-воспитательной работе является строго регламентированной, то для информационного моделирования предметной области лучше подойдет функциональный подход, методологии которого и будут рассмотрены ниже. Также стоить отметить тот факт, что структурный подход даст более понятное представление результатов проектирования, что в дальнейшем ускорит доработку реализуемой в рамках дипломной работе системы.


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


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

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

Ясность графического языка IDEF0 делает модель целиком читаемой и для лиц, которые никак не принимали роли в проекте ее создания, а также успешной для проведения показов и демонстраций. Далее на базе созданной модели могут быть организованы новые проекты, направленные на создание изменений в модели.

Методология IDEF0 может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются [3].

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

Преимущества методологии IDEF0:

) Полнота описания бизнес-процесса (управление, информационные и материальные потоки, обратные связи).

) Комплексность при декомпозиции (мигрирование и туннелирование стрелок); возможность агрегирования и детализации потоков данных и информации (разделение и слияние стрелок).

) Наличие жестких требований методологии, обеспечивающих получение моделей процессов стандартного вида.

) Простота документирования процессов.

) Соответствие подхода к описанию процессов в IDEF0 стандартам ISO 9000:2000.

) Возможность обозначения обратной связи.

) Возможность декомпозиции.

Недостатки:

) Сложность восприятия (большое количество стрелок).

) Большое количество уровней декомпозиции.

) Трудность увязки нескольких процессов, представленных в различных моделях одной и той же организации.

) Невозможность отображения динамики процессов.


.2.2 Методология функционального моделирования IDEF3- методология моделирования и стандарт документирования процессов, происходящих в системе.

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

Достоинства:

) указание временных последовательностей выполнения.

) возможность декомпозиции.

) несколько видов диаграмм.

) возможность реализации ветвлений.

Недостатки:

) Отсутствие обозначения обратной связи.

) Отсутствие обозначения управления, необходимых ресурсов.

) Узкая область применения (применяется для процессов нижних уровней) [5].


.2.3 Методология функционального моделирования DFD

Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram - DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Функцией диаграммы потоков данных - моделирование функциональных требований к проектируемой системе [8].

При разработке диаграммы потоков данных используются четыре главных компонента: потоки данных, процессы (работы) преобразования входных потоков данных в выходные, внешние сущности, накопители данных (хранилища). Помимо основных элементов, в состав DFD входят словари данных и миниспецификации.

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

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

Если же для сложной системы ограничиться единственной контекстной диаграммой, то она будет содержать слишком большое количество источников и приемников информации, которые трудно расположить на листе бумаги нормального формата, и кроме того, единственный главный процесс не раскрывает структуры распределенной системы. Признаками сложности (в смысле контекста) могут быть:

Наличие большого количества внешних сущностей (десять и более).

Распределенная природа системы.

) Многофункциональность системы с уже сложившейся или выявленной группировкой функций в отдельные подсистемы [21].

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

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

К преимуществам нотации DFD относятся:

) Возможность однозначно определить внешние сущности, используя анализ потоков информации внутри и за пределами системы.

) Возможность проектирования сверху вниз, что позволяет ускорить построение модели «как будет».

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

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

Рассмотрев достоинства и недостатки различных нотаций моделирования, была выбрана пара IDEF0, DFD. IDEF3 не была принята в силу того, что для проектирования информационной системы не требуется детализации на низких уровнях, требуется учесть обратную связь процессов, а также не требуется учитывать динамику процессов в силу их статичности.

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


.3 Выбор инструментального средства функционального моделирования


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


.3.1 Sybase PowerDesigner

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

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


.3.2 AllFusion Process ModellerProcess Modeller (ранее - BPwin) обладает интуитивно-понятным графическим интерфейсом, помогает быстро создавать и анализировать модели с целью оптимизации деловых и производственных процессов. Применение универсального графического языка бизнес-моделирования IDEF0 обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Для групповой работы над большими проектами предусмотрено хранение моделей AFPM в репозитарии Model Mart. Оно является хранилищем моделей для AFPM и AFDM и использует реляционные СУБД Oracle, Informix, MS SQLServer, Sybase. В нем предусмотрено администрирование, в том числе разграничение прав доступа до уровня объекта модели, сравнение версий, слияние моделей [16]. Продукт поддерживает моделирование бизнес-процессов с использованием нотаций IDEF0, IDEF3, DFD.

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

.3.3 Microsoft Visio

Визуальное средство MS Visio - это приложение из семейства Microsoft Office. Оно не является специализированным программным обеспечением для описания бизнес-процессов, поэтому его функциональные возможности весьма ограниченны и не позволяют проводить глубокий анализ и оценку моделей, разрабатывать какие-либо регламентирующие документы, а также автоматически вносить изменения в модели. MS Visio представляет собой нетрадиционный и очень гибкий графический редактор, который обеспечивает быстрое наглядное представление небольших по объему и обобщенных по содержанию моделей [17].

К преимуществам системы можно отнести простоту освоения и использования системы, возможность оперативно разрабатывать графическое представление бизнес-процессов и по необходимости вносить в них изменения. Использование системы в учебных целях возможно в рамках программы Microsoft Academic Alliance.

Однако система не позволяет составлять отчеты на основании описанных бизнес-процессов, анализировать стоимость и время выполнения действий и всего бизнес-процесса. Стандартными инструментами MS Visio нельзя разработать иерархическую модель бизнес-процесса, содержащую несколько уровней детализации (от уровня компании до уровня отдельных сотрудников). Соответствующие модели приходится создавать в виде набора отдельных диаграмм.


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

Основные решаемые системой задачи:

) Формализация направления деятельности и её контроль.

) Моделирование и оптимизация бизнес-процессов, организационной структуры и штатного расписания.

) Формирование и распространение регламентирующей документации (регламенты процессов, положения о подразделениях, должностные инструкции, описание документооборота) среди сотрудников.

) Внедрение системы менеджмента качества в соответствии со стандартами ISO.

) Подготовка к автоматизации и формирование Технических заданий на внедрение информационных систем.

Особенностью Business Studio, принципиально отличающей его от других аналогичных программных продуктов, является поддержка четырех нотаций моделирования - IDEF0, Процесс (Basic Flowchart), Процедура (Cross Functional Flowchart), EPC (Event-Driven Process Chain), что обеспечивает возможность создания как комплексной иерархической модели бизнес-процессов, так описания отдельных процессов. Нотацию IDEF0 целесообразно использовать для построения иерархической модели бизнес-процессов верхнего уровня, а нотации Процесс и Процедура - для моделирования процессов нижнего (операционного) уровня. Business Studio позволяет менять нотацию моделирования при переходе с описания процессов верхнего уровня к описанию процессов нижнего уровня [26].

Преимуществами Business Studio является наличие бесплатной академической версии, возможностью построения сложных иерархических диаграмм бизнес-процессов в нотации IDEF0. Однако в этом продукте не поддерживается выбранная нами для описания потоков данных в системе нотация DFD.

.3.5 Ramus EducationalEducational создан с целью стать основным инструментом бизнес-аналитиков в проектах по построению или реорганизации систем управления предприятием. К таковым могут относиться: проекты по реинженирингу бизнес-процессов, проекты внедрения процессного управления, проекты построения системы менеджмента качества, проекты построения системы управления знаниями и т.п.имеет смысл использовать в достаточно больших и сложных организациях, дабы он мог проявить свои преимущества в полной мере.

Основными возможностями Ramus являются:

) Моделирование процессов (согласно методологий IDEF0 и DFD).

) Разработка систем классификации и кодирования предприятия с внутренними перекрёстными связями, которая также тесно увязывается и с моделями процессов.

) Формирование отчётности по моделям и системе классификации, в том числе и отчётности в форме такой регламентирующей документации как должностные инструкции и регламенты процессов.

) Генерация сайта, который призван обеспечить доступ к данным моделей процессов, системы классификации и кодирования а также к разнообразнейшей отчётности через веб-интерфейс.имеет редактор диаграмм IDEF0 и DFD эргономичность которого находится на уровне не ниже чем у аналогичных продуктов имеющих схожие редакторы. Это проявляется в более лёгкой и быстрой навигации по модели, в более «умном» поведении объектов диаграмм, в поддержке шаблонов диаграмм, в возможности быстрого исправления допущенных ошибок, в том числе и в возможности отмены действий.

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

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

Просмотр всей информации проекта может быть осуществлён через веб-браузер [28]. Для этого разработан веб-сервер который выводит информацию Проекта в виде набора HTML страниц, или же, попросту говоря, в виде сайта.

Кроме всего прочего, Ramus поддерживает возможность расширения функциональности с использованием сценариев на языке программирования JavaScript.

Очевидным преимуществом Ramus Educational является бесплатное распространение.

Таким образом, для информационного моделирования предметной области, рациональнее использовать Ramus Educational, по причине того, что это единственное из рассмотренных средств бесплатно распространяется, поддерживает создание моделей IDEF0 и DFD, что позволит сэкономить время ознакомления с интерфейсами средств моделирования, а также позволит сэкономить денежные средства.


2. Разработка комплекса функциональных моделей предметной области «Планирование и отчетность по УВР ВолГУ»


.1 Создание модели бизнес-процессов «как есть» в нотации IDEF0


Далее, в ходе выполнения дипломной работы была создана модель бизнес-процессов, иллюстрирующую текущую деятельность по планированию работы и формированию отчетности управления по учебно-воспитательной работе, без использования автоматизированной системы «Университет». В качестве имени процесса на контекстной диаграмме выбрана «Планирование и отчетность УВР ВолГУ», так как планирование и отчетность преподавательского состава является частью общеуниверситетской системы планирования и отчетности. Данный факт указан в положении о планировании учебной работы ВолГУ. Деятельность по планированию учебно-воспитательной работы регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ. В качестве цели создания модели была определена следующая: «формализовать предметную область для её последующей автоматизации». В данном случае цель необходима для того, чтобы понять какое место в системе занимает отчетность и планирование учебно-воспитательной работы профессорско-преподавательского состава, а также понять в дальнейшем возможность автоматизации данных процессов. В качестве точки зрения был выбран сотрудник, ответственный за функционирование автоматизируемого процесса. Таким сотрудником является начальник управления по учебно-воспитательной работе ВолГУ (рисунок 1).

Для того чтобы определить набор стрелок на контекстной диаграмме, была проведена ее декомпозиция. Была создана диаграмма декомпозиции, на которой в виде процессов были отображены процессы из которых состоит планирование и отчетность учебно-воспитательной работы ВолГУ. В качестве имени создаваемого процесса указали «Планирование и отчетность УВР УУВР».

Также была добавлены на диаграмму декомпозиции А0 процессы «Планирование и отчетность УВР института», «Планирование и отчетность учебно-воспитательной работы профессорско-преподавательского состава кафедры» и «Планирование и отчетность УВР ППС» (рисунок 2).

В качестве механизмов исполнения в диаграмме AS IS выступили преподаватель, заведующий кафедрой, директор института, начальник управления по учебно-воспитательной работе ВолГУ, согласно положению о планировании учебной работы ВолГУ. При переходе от контекстной диаграммы (рисунок 1) к диаграмме декомпозиции (рисунок 2) соответствующая стрелка автоматически перейдет на диаграмму декомпозиции.

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

На данном этапе сформировались стрелки входов, выходов и управления. Планирование и отчетность учебно-воспитательной работы ВолГУ формируется из планов и отчетов профессорско-преподавательского состава, кафедр, институтов и сводных плана и отчета управление по учебно-воспитательной работе ВолГУ. Поэтому на контекстной диаграмме (рисунок 1) были выделены следующие стрелки выходов: «План УВР УУВР университета», «План по УВР института», «План УВР кафедры», «План УВР ППС», «Отчет по УВР кафедры», «Отчет по УВР института», «Отчет ППС по УВР», «Отчет по УВР УУВР» (рисунок 1). На диаграмме декомпозиции появившиеся стрелки были закреплены за процессами в соответствии с их названиями (рисунок 2).

Планирование и отчетность учебно-воспитательной работы ВолГУ включают в себя иерархические процессы.

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

Отчетность учебно-воспитательной работы ВолГУ формируется с отчетов профессорско-преподавательского состава, далее эти отчеты используются для формирования отчетности по кафедрам, отчет кафедр используются при создании отчета институтов, на основании отчетов институтов формируется отчет по учебно-воспитательной работе управления по учебно-воспитательной работе. Таким образом, отчетность по иерархии является обратной процессу планирования. На диаграмме описанную зависимость обозначена в качестве стрелок управления (рисунок 2).

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

Планирование и отчетность учебно-воспитательной работы ВолГУ регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ. Поэтому необходимо указать этот нормативный документ в качестве стрелки управления. Был осуществлен переход к контекстной диаграмме и была добавлена стрелка механизма «Процедура управления и реализации учебно-воспитательной работы ВолГУ» (рисунок 1).

Далее был произведен переход к тому по средствам чего создаются планы и отчеты. На данный момент план и отчеты профессорско-преподавательского состава, институтов, управления по учебно-воспитательной работе создаются в программе MS Word, данный факт отразим добавлением на контекстную диаграмму механизма MS Word (рисунок 1), на диаграмме декомпозиции сделаем данную стрелку механизмом для процессов «Планирование и отчетность УВР УУВР», «Планирование и отчетность УВР института» и «Планирование и отчетность учебно-воспитательной работы ППС» (рисунок 2).

Планирование и отчетность учебно-воспитательной работы кафедр формируется в автоматизированной информационной системе «Университет» на платформе «1С: Предприятие». Данный механизм был обозначен на контекстной диаграмме и добавили его для процессов «Планирование и отчетность УВР кафедры» (рисунок 2).

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

Наши задачи заключаются в том, чтобы увидеть, как на данный момент ведется работа по планированию и отчетности учебно-воспитательной работы профессорско-преподавательского состава, а также её место в системе планирования и отчетности в ВолГУ. Поэтому процессы А1-A3 далее рассмотрены не будут (рисунок 2). Перейдем к декомпозиции процесса A4 (рисунок 3).

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

План и отчет формируются в MS Word, поэтому механизм c одноименным названием разделили на две стрелки и добавили к каждому из процессов. Имеющиеся выходные стрелки «План УВР ППС» и «Отчет по УВР ППС» были закреплены за процессом планирования и отчетности соответственно (рисунок 3). Данные из плана использовали для отчета, поэтому первая из стрелок будет также входной для процесса «Отчетность по УВР ППС». План учебно-воспитательной работы кафедры влияет на план учебно-воспитательной работы профессорско-преподавательского состава, поэтому мы закрепили стрелку управления «План УВР кафедры» за процессом «Планирование УВР ППС» (рисунок 3). Планирование и отчетность регламентируются процедурой управления и реализации учебно-воспитательной работы ВолГУ частями 3 и 5 соответственно, была декомпозирована стрелку управления «Процедура управления и реализации учебно-воспитательной работы ВолГУ» (рисунок 3).

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

Следующим шагом в создании диаграммы являлась декомпозиция процесса «Планирование УВР ППС». Планирование учебно-воспитательной работы профессорско-преподавательского состава делится на планирование мероприятий по cледующим типам:

) Профессионально-правовое воспитание.

) Культурно-нравственное воспитание.

) Гражданско-патриотическое воспитание.

) Спортивно-оздоровительные мероприятия.

) Жилищно-бытовое воспитание.

Отразим данную особенность на диаграмме.

Были добавлены пять процессов:

) Планирование мероприятий профессионально-правового воспитания.

) Планирование мероприятий культурно-нравственного воспитания.

) Планирование мероприятий гражданско-патриотического воспитания.

) Планирование спортивно-оздоровительных мероприятий.

) Планирование мероприятий жилищно-бытового воспитания.

Далее был осуществлен переход к механизмам, исполнителем каждого процесса является преподаватель, поэтому стрелку механизма была разделена на пять и закреплена за каждым процессом. Также для всех процессов были выделены общие механизмы MS Word и Шаблон плана. Были разделены стрелки на пять и добавлены к процессам (рисунок 4). Планирование мероприятий любого типа, это список мероприятий, поэтому входной стрелкой для каждого процесса будет являться мероприятие, была разделена стрелка мероприятие на количество процессов и добавили к ним. Каждый из процессов регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ, поэтому одноименная стрелка управления была разбита на пять и добавлена к каждому процессу (рисунок 4). Из обоснования того, что планирование учебно-воспитательной работы профессорско-преподавательского состава делится на части, следует и то, что каждый процесс является частью одного плана учебно-воспитательной работы профессорско-преподавательского состава, поэтому все выходные стрелки каждого из процессов были соединены с выходной стрелкой «План УВР ППС», далее были заданы названия стрелкам, они были сформированы из слова план и типа мероприятия. Таким образом, были получены следующие выходные стрелки процессов:

) План по мероприятиям профессионально-правового воспитания.

) План по мероприятиям культурно-нравственного воспитания.

) План по мероприятиям гражданско-патриотического воспитания.

) План спортивно-оздоровительных мероприятий.

) План по мероприятиям жилищно-бытового воспитания (рисунок 4).

Была рассмотрена декомпозиция процесса «Планирование мероприятий профессионально-правового воспитания».

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

) Указать название мероприятия.

) Указать планируемые сроки мероприятия.

) Указать роль в мероприятии (рисунок 5).

Входная стрелка «Мероприятие» была декомпозирована на три: «Название мероприятия», «Сроки проведения мероприятия», «Роль в мероприятии» и закрепляется за процессами A4111, A4112, A4113 соответственно (рисунок 5). Каждый из процессов регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ, поэтому одноименную стрелку управления разбили на три и добавили к каждому процессу (рисунок 5). Данные вносимые преподавателем зависят от плана учебно-воспитательной работы кафедры, поэтому стрелка управления «План УВР кафедры» разбивается на три и добавляется к каждому процессу. Каждая имеющаяся стрелка механизма была разделена на три и добавлена к процессам исходя из того, что преподаватель заполняет данные по мероприятию в MS Word, используя шаблон плана (рисунок 5). Результатом процессов будут «Название планируемого мероприятия», «Сроки проведения планируемого мероприятия», «Роль в планируемом мероприятии» для процессов A4111, A4112, A4113 (рисунок 5) соответственно, эти выходные данные в совокупности представляют план по мероприятиям профессионально-правового воспитания преподавателя, поэтому эти стрелки были соединены с выходной стрелкой «План по мероприятиям профессионально-правового воспитания» (рисунок 5).

Процессы A412, A413, A414, A415 (рисунок 4) имеют аналогичную декомпозицию и в тексте дипломной работы рассматриваться не будут.

Следующим шагом в создании диаграммы была декомпозиция процесса «Отчетность УВР ППС» (рисунок 3). Отчетность по учебно-воспитательной работе профессорско-преподавательского состава делится на отчетность по мероприятиям cледующих типов:

) Профессионально-правовое воспитание.

) Культурно-нравственное воспитание.

) Гражданско-патриотическое воспитание.

) Спортивно-оздоровительные мероприятия.

) Жилищно-бытовое воспитание.

Отразим данную особенность на диаграмме.

Добавим пять процессов:

) Отчетность по мероприятиям профессионально-правового воспитания.

) Отчетность по мероприятиям культурно-нравственного воспитания.

) Отчетность по мероприятиям гражданско-патриотического воспитания.

) Отчетность по спортивно-оздоровительных мероприятиям.

) Отчетность по мероприятиям жилищно-бытового воспитания (рисунок 6).

Далее перешли к механизмам, исполнителем каждого процесса является преподаватель, поэтому стрелка механизма была разделена на пять и закреплена за каждым процессом (рисунок 6). Также для всех процессов будут общие механизмы MS Word и Шаблон отчета, были разделены стрелки на пять и добавлены к процессам (рисунок 6). Отчетность мероприятий любого типа, это список мероприятий, поэтому входной стрелкой для каждого процесса будет являться мероприятие, была разделена стрелка мероприятие на количество процессов и добавлена к ним (рисунок 6). Отчет формируется из плана, а значит и каждый процесс имеет на входе также список мероприятий из плана по учебно-воспитательной работе профессорско-преподавательского состава, поэтому стрелку была разбита «План УВР ППС» на пять и добавлена к каждому из процессов (рисунок 6). Каждый из процессов регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ, поэтому одноименная стрелка управления была разбита на пять и добавлена к каждому процессу (рисунок 6). Из обоснования того, что отчетность учебно-воспитательной работы профессорско-преподавательского состава делится на части, следует и то, что каждый процесс является частью одного Отчета учебно-воспитательной работы профессорско-преподавательский состав, а значит все выходные стрелки каждого из процессов соединили с выходной стрелкой «Отчет ППС по УВР» (рисунок 6), далее были заданы названия стрелкам, они были сформированы из слова отчет и типа мероприятия. Таким образом, были получены следующие выходные стрелки процессов:

) Отчет по мероприятиям профессионально-правового воспитания.

) Отчет по мероприятиям культурно-нравственного воспитания.

) Отчет по мероприятиям гражданско-патриотического воспитания.

) Отчет по спортивно-оздоровительным мероприятиям.

) Отчет по мероприятиям жилищно-бытового воспитания (рисунок 6).

Рассмотрим декомпозицию процесса «Отчетность по мероприятиям профессионально-правового воспитания» (рисунок 7).

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

) Указать название мероприятия.

) Указать планируемые сроки мероприятия.

) Указать роль в прошедшем мероприятии (рисунок 7).

Выходные данные по мероприятиям в плане учебно-воспитательной работы профессорско-преподавательского состава являются входными для каждого из процесса, поэтому входная стрелка «План УВР ППС» была разбита на три и добавлена к каждому процессу на диаграмме (рисунок 7). Входная стрелка «Мероприятие» была декомпозирована на три: «Название мероприятия», «Сроки проведения мероприятия», «Роль в мероприятии» и закреплена за процессами A4211, A4212, A4213 соответственно (рисунок 7). Каждый из процессов регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ, поэтому одноименную стрелку управления разбили на три и добавили к каждому процессу (рисунок 7). Каждая имеющаяся стрелка механизма была разделена на три и добавлена к процессам исходя из того, что преподаватель заполняет данные по мероприятию в MS Word, используя шаблон отчета (рисунок 7). Результатом процессов стали «Название отчетного мероприятия», «Сроки проведения выполнения проведенного мероприятия», «Роль в прошедшем мероприятии» для процессов A4211, A4212, A4213 соответственно, эти выходные данные в совокупности представляют отчет по мероприятиям профессионально-правового воспитания, поэтому эти стрелки были соединены с выходной стрелкой «Отчет по мероприятиям профессионально-правового воспитания» (рисунок 7).

Процессы A422, A423, A424, A425 (рисунок 6) имеет аналогичную декомпозицию и в тексте дипломной работы рассматриваться не будут.

Таким образом, бизнес-процесс, автоматизация которого в виде модуля «Планирование и отчетность учебно-воспитательной работы ППС» в автоматизированной системе «Университет» полностью описан в виде IDEF0-диаграммы «как есть». Остальные процессы не подлежат автоматизации в рамках данной дипломной работы, и декомпозироваться не будут.

Следующим этапом проектирования был переход к построению IDEF0-диаграммы «как будет».


.2 Создание диаграммы бизнес-процессов «как будет» в нотации IDEF0


Далее на основе разработанной модели бизнес-процессов «как есть» была создана модель бизнес-процессов «как будет» в нотации IDEF0. Модель описывает функционирование предметной области с применением разрабатываемой автоматизированной системы.

На контекстной диаграмме модели «Как будет» в качестве названия контекстного бизнес-процесса, был выбран «Работать с модулем «Планирование и отчетность УВР в ВолГУ». Изменилась и цель построения модели - «Описание процесса работы пользователей с разрабатываемой АС». Точка зрения сохранилась. Изменился и вид модели - вместо «AS IS» стал «TO BE» (рисунок 8).

Работу в разрабатываемой автоматизированной системе будут вести следующие сотрудники ВолГУ:

) Начальник управления по учебно-воспитательной работе ВолГУ.

) Директора институтов стрелка.

) Заведующие кафедрой.

) Преподаватель.

Поэтому целесообразно добавить на контекстную диаграмму в качестве стрелок механизмов:

) «Начальник управления по УВР ВолГУ».

) «Директор института».

) «Заведующий кафедрой».

) «Преподаватель».

Также была добавлена на контекстную диаграмму сама автоматизированная система «Университет» (рисунок 8).

По сравнению с диаграммой «AS IS» не изменится входная стрелка «Мероприятие», так как в разрабатываемой системе ведется учет мероприятий. Планирование и отчетность учебно-воспитательной работы ВолГУ регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ. Поэтому необходимо указать этот нормативный документ в качестве стрелки управления (рисунок 8).

Перейдем к декомпозиции контекстной диаграммы.

Система по планированию и отчетности будет состоять из четырех модулей, предназначенных для управления по учебно-воспитательной работе, институтов, кафедр и преподавателей. Названия процессов были взяты на аналогичной ветке диаграммы «AS IS» (рисунок 2).

Механизмы, которые описывают сотрудников университета, будут также аналогичны. Механизм «AИС Университет» были декомпозированы на четыре стрелки «Модуль планирования и отчетности УВР УУВР», «Модуль планирования и отчетности УВР ППС», «Модуль планирования и отчетности УВР кафедры», «Модуль планирования и отчетности УВР института» и были закреплены за процессами в соответствии с их наименованием (рисунок 9). Входная стрелка «Мероприятие» будет входом для каждого из процессов, ибо каждый из модулей системы ведет учет мероприятий. Планирование и отчетность учебно-воспитательной работы ВолГУ формируется из планов и отчетов профессорско-преподавательского состава, кафедр, институтов и сводных плана и отчета управления по учебно-воспитательной работе ВолГУ. Поэтому следует учесть эти данные в разрабатываемом модуле, поэтому на контекстной диаграмме выделяются следующие стрелки выходов: «План УВР УУВР университета», «План по УВР института», «План УВР кафедры», «План УВР ППС», «Отчет по УВР кафедры», «Отчет по УВР института», «Отчет ППС по УВР», «Отчет по УВР УУВР» (рисунок 9).

Планирование и отчетность учебно-воспитательной работы ВолГУ регламентируется процедурой управления и реализации учебно-воспитательной работы ВолГУ. Поэтому был указан этот нормативный документ в качестве стрелки управления на контекстной диаграмме (рисунок 9), а далее был произведен переход к диаграмме декомпозиции и добавлена стрелка к каждому из процессов (рисунок 9).

Далее перешли к декомпозиции процесса «План УВР УУВР».

Выделили основные функции, которые выполняются в данном процессе. Во-первых, это функции планирования и отчетности, поэтому на диаграмму добавим процессы «Планирование УВР УУВР», «Отчетность УВР УУВР», во-вторых целесообразно в данном модуле реализовать формирование основных данных, с которыми будут работать в других модулях и в этом модуле также, добавим процесс «Формирование справочников» (рисунок 10). Имеющуюся входную стрелку разбиваем на три и добавляем к каждому процессу, ибо каждый процесс оперирует с мероприятиями (рисунок 10). Очевидно, что результатом планирования является план, а отчетности - отчет, были добавлены выходные стрелки к «План УВР УУВР университета» и «Отчетность УВР УУВР» к процессам 12 и 13 соответственно (рисунок 10). Так как на данном этапе был описан модуль информационной системы, то каждый процесс характеризуется механизмом «АИС Университет». Для выполнения каждого из процессов требуется пользователь системы, в данном случае начальник управления по учебно-воспитательной работе, поэтому одноименная стрелка была разделена на три и добавлена к каждому из процессов (рисунок 10). Процедура управления и реализации учебно-воспитательной работы ВолГУ выступила в качестве стрелки управления для процессов планирования и отчетности (рисунок 10).

Далее был произведен переход к декомпозиции процесса «Формирование справочников», были определены функции, выходные данные и связь этого процесса с процессами на ветке 1 (рисунок 10). Каждое мероприятие характеризуется типом, который будет храниться в справочнике типов мероприятий, данные этого справочника формируются по средствам процесса «Формирование справочника типов мероприятий». Был создан процесс «Формирование справочника мероприятий», который отвечает за наполнение справочника мероприятий (рисунок 11).

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

) Тип мероприятий.

) Учебные годы.

) Мероприятия (рисунок 11).

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

Перешли к декомпозиции процесса «Формирование справочника мероприятий».

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

Очевидно соотношение входных данных и процессов. Выходными данными исходя из названий процессов стали «Наименование внесенного мероприятия» и «Тип внесенного мероприятия», которые в совокупности формируют справочник мероприятия, соединяем выходные стрелки с имеющейся стрелкой «Справочник мероприятий» (рисунок 12).

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

Далее перешли к планированию и отчетности учебно-воспитательной работы профессорско-преподавательского состава. Таким образом, перейдем к декомпозиции процесса 2 (рисунок 9).

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

Как в ходе планирования, так и в ходе отчетности ведется учет мероприятий, поэтому входной стрелкой для указанных процессов будет являться мероприятие, которое предварительно разделим на две. Очевидно, что механизмом для каждого из процессов выступит преподаватель, поэтому одноименная стрелка была разделена на две (рисунок 13).

План и отчет формируются в автоматизированной информационной системе «Университет», поэтому механизм c одноименным названием был разделен на две стрелки и добавлен к каждому из процессов (рисунок 13). Имеющиеся выходные стрелки «План УВР ППС» и «Отчет по УВР ППС» были закреплены за процессами планирования и отчетности соответственно (рисунок 16). Очевидно, что данные из плана влияют на данные для отчета, поэтому первая из стрелок будет также стрелкой управления для процесса «Отчетность по УВР ППС». Планирование и отчетность регламентируются процедурой управления и реализации учебно-воспитательной работы ВолГУ частями 3 и 5 соответственно, декомпозируем стрелку управления «Процедура управления и реализации учебно-воспитательной работы ВолГУ» (рисунок 13).

Далее перешли к декомпозиции процесса «Планирование УВР ППС».

Планирование работы профессорско-преподавательского состава можно будет условно можно разделить на две части:

) Планирование участия в общеуниверситетских мероприятиях. Т.е. Преподаватель должен выбрать мероприятие, из уже запланированных мероприятий.

) Планирование инициативных мероприятий. Преподаватель является инициатором мероприятия, поэтому ему требуется провести процедуру по его созданию.

Таким образом, на диаграмме появляются два одноименных процесса (рисунок 14).

Планирование подразумевает учет мероприятий, поэтому входной стрелкой для указанных процессов будет являться мероприятие, которая была предварительно разделена на две (рисунок 14).

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

Далее произвел переход к процессу «Планирование участия в общеуниверситетских мероприятиях».

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

Далее был произведен переход к декомпозиции процесса «Планирование инициативных мероприятий».

На данном этапе преподаватель создает мероприятие в системе. Процесс разбивается на процессы, в которых будут указываться данные мероприятия:

) Наименование мероприятия.

) Сроки проведения.

) Тип мероприятия.

) Участники мероприятия.

) Ответственный за проведение (в данном случае тот, кто создает мероприятие в системе).

) Учебный год (рисунок 16).

На диаграмме были созданы шесть процессов «Внесение наименования мероприятия», «Выбор сроков проведения», «Выбор типа мероприятия», «Внесение предполагаемых участников мероприятия», «Внесение ответственного за проведение мероприятия», «Выбор учебного года» (рисунок 19). Входная стрелка «Мероприятие» была декомпозирована согласно данным мероприятия, выделенным ранее и была закреплена за процессами (рисунок 19). Тип мероприятия, его учебный год, участники и ответственный за проведение вносят согласно имеющимся данным в справочниках типов мероприятия, учебных годов и сотрудников соответственно, поэтому стрелку управления «Cправочники» была разбита по количеству справочников и добавлена к процессам «Выбор типа мероприятия», «Внесение предполагаемых участников мероприятия», «Внесение ответственного за проведение мероприятия», «Выбор учебного года» (рисунок 16). Преподаватель заполняет все данные в системе, система определяет его в качестве ответственного за проведение мероприятия, данная зависимость была отражена в стрелках механизмов на диаграмме (рисунок 16). Выходными данными соответственно будут «Тип запланированного мероприятия», «Наименование запланированного мероприятия», «Ответственный запланированного мероприятия, «Учебный год мероприятия», «Участники запланированного мероприятия», которые в совокупности образуют «План УВР ППС» (рисунок 16).

Была рассмотрена декомпозиция процесса «Отчетность по УВР ППС». Задача преподавателя выбрать мероприятие из списка прошедших мероприятий. Для этого преподаватель должен указать учебный год, сроки проведения мероприятия, тип мероприятия и наименование мероприятия. Система позволяет осуществить ввод данных и ведет поиск мероприятий преподавателя. Таким образом, следует выделить следующие процессы на диаграмме:

) Выбор мероприятий профессорско-преподавательского состава.

) Выбор учебного года.

) Выбор сроков мероприятия.

) Выбор типа мероприятия.

) Выбор наименования мероприятия (рисунок 17).

Для каждого процесса механизмом будет являться «АИС Университет» (рисунок 17). И для всех кроме первого процесса «Преподаватель» (рисунок 17). Входными данными для процессов являются данные по мероприятию, поэтому следует декомпозировать стрелку мероприятия на следующие: «Текущий пользователь системы», «Учебный год», «Сроки проведения мероприятия», «Тип мероприятия», «Наименование мероприятия» и добавим к процессам в соответствии с их названием (рисунок 17). Тип, наименование мероприятия, его учебный год, вносят согласно имеющимся данным в справочниках типов мероприятия, учебных годов и справочник учебных годов, поэтому стрелка управления «Cправочники» была разбита по количеству справочников и добавлена к процессам «Выбор типа мероприятия», «Выбор наименования мероприятия», «Выбор учебного года» (рисунок 17).

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

Таким образом, на основе модели бизнес-процессов «как есть», описывающей планирование и отчетность по учебно-воспитательной работе ВолГУ была разработана IDEF0-модель «как будет», описывающая выполнение этих функции при помощи модуля в автоматизированной информационной системе «Университет».


.3 Разработка диаграммы потоков данных


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

Названия стрелок между процессом и внешними сущностями были перенесены из IDEF0-диаграммы «как будет» (рисунок 18).

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

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

Далее была проведена декомпозиция компонента «Планирование и отчетность УВР УУВР» (рисунок 20).

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

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

Далее перешли к декомпозиции компонента «Планирование и отчетность учебно-воспитательной работы ППС» (рисунок 22).

На данной ветке, процессы и данные повторяют соответствующий уровень диаграммы «TO BE» (рисунок 13). Перешли к декомпозиции процесса «Планирование УВР ППС».

Дальнейшая декомпозиция позволила выявить хранилище данных «План УВР ППС», где будет храниться информация о планируемых мероприятиях (рисунок 24).

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

Далее был произведен переход к отчетности учебно-воспитательной работы профессорско-преподавательского состава. На данном этапе данные вносимые преподавателем вносятся в хранилище «Отчет УВР ППС» (рисунок 26). Вносимые данные регламентируются хранилищами данных справочников.

Таким образом, в ходе построения диаграммы потоков данных в нотации DFD и с использованием инструментального средства Ramus Educational был определен набор хранилищ данных.


3. Разработка конфигурации на платформе «1С: Предприятие 8» и ее тестирование


Разработка конфигурации на платформе «1С: Предприятие 8» в рамках данной дипломной работы состоит из двух этапов - генерации структур хранения данных и создания пользовательского интерфейса.


.1 Анализ видов информационных структур системы «1С: Предприятие 8»


Для перехода от абстрактных хранилищ данных, выявленных при построении диаграммы потоков данных, к платформенно-зависимым структурам данных необходимо проанализировать их виды. Собственно платформа «1С: Предприятие» представляет собой совокупность механизмов, предназначенных для манипулирования различными типами объектов предметной области. Конкретный набор объектов, структуры информационных массивов, алгоритмы обработки информации определяет конкретная конфигурация. Вместе с конфигурацией система «1С: Предприятие» выступает в качестве уже готового к использованию программного продукта, ориентированного на определенные типы предприятий и классы решаемых задач [24].


.1.1 Объект конфигурации «Справочник»

Справочники - это прикладные объекты конфигурации. Они позволяют хранить в информационной базе данные, имеющие одинаковую структуру и списочный характер [11]. Это может быть, например, перечень выпускаемой продукции, список игроков футбольной команды, перечень валют и т.д. Справочники обеспечивают поддержку иерархических структур, позволяют относить данные к отдельным объектам и их группам, предоставляют ряд других сервисных возможностей. Многоуровневая иерархия, поддерживаемая справочниками, включается простой активизацией соответствующего свойства в метаданных. При этом поддержка иерархии распространяется сразу на все аспекты использования прикладного объекта [8].

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

Кроме реквизитов структура справочника включает в себя табличные части. Они необходимы для того, чтобы установить набор информации одинаковой по структуре и различной по количеству. Так, к примеру, любой элемент справочника «Книга» может содержать более чем одного автора, потому рационально использовать в данной ситуации не атрибут «Авторы», а одноименную табличную часть [15].

В справочниках возможно создание групп, таким образом можно группировать элементы по определенным свойствам, значениям реквизитов. Примером можно привести деление видов спорта на зимние и летние. Для удобства использования элементы справочника могут быть сгруппированы пользователем по какому-либо принципу. Для осуществления группировки требуется определить справочник как «Иерархический», задав одноименное свойство. В этом случае, возможно, создать элемент справочника, который будет представлять собой группу и будет являться родителем для всех элементов и групп, входящих в эту группу. Такой вид иерархии называется иерархией групп и элементов [25].

Родителем может быть не только группа, но и элемент справочника. Таким образом, возможно, реализовать иерархию на уровне элементов. Например, такой вид иерархии можно использовать при создании дерева подчиненности сотрудников, когда один сотрудник является руководителем других сотрудников [18].


.1.2 Объект конфигурации «Документ»

Документы отражают в системе события, происходящие в жизни предприятия: поступление материалов, перечисление денег через банк, прием сотрудника на работу и т.д. [20].

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

Пользователь в течение работы с информационной системой имеет возможность создавать новые объекты данного типа - новые документы. Документ обладает важным свойством, свойством проведения. Событие проведения показывает, что событие, которое он отражает в системе, зафиксировано и повлияло на положение учета. До тех пор, пока документ не проведен, он считается лишь шаблоном, черновиком или заготовкой и никак не воздействует на состояние учета. При проведении документа изменения записываются мгновенно и состояние учета может измениться [13].

Документ всегда характеризуется временем создания. Это свойство позволяет построить в базе данных хронологическую цепочку наступления событий [14].

Документ, хранит некий объем сведения, который раскрывает подробно суть события. Для описания данного набора информации используются реквизиты объекта конфигурации документ, которые являются подчиненными объектами конфигурации. По умолчанию любой документ имеет наименование и код, другие реквизиты добавляются в конфигурацию самостоятельно [19].

Каждый документ, как правило, содержит информацию, которая более подробно описывает этот документ. Набор такой информации является одинаковым для всех документов одного, вида и для описания такого набора используются реквизиты объекта конфигурации Документ, являющиеся подчиненными объектами конфигурации. Большинство реквизитов объекта конфигурации Документ разработчик создает самостоятельно, однако у каждого объекта конфигурации Документ существуют два поля «по умолчанию»: дата и номер документа [27].

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

планирование проектирование модульный

3.1.3 Объект конфигурации «Отчет»

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

3.2 Генерация информационных структур для модуля


Далее в ходе выполнения дальнейшей работы, на основе выполняемого в ходе DFD- моделировании были спроектированы структуры данных конфигурации «1С: Предприятие».


.2.1 Справочник «ТипыМероприятия»

Структура справочника «ТипыМероприятия» (рисунок 27).

Структура справочника состоит из наименования типа строки, в котором хранится тип мероприятия.


.2.2 Справочник «Мероприятия»

Структура справочника «Мероприятия» (рисунок 28).

Структура справочника состоит из наименования типа строки, в котором хранится наименование мероприятия, а также реквизит ссылочного типа «Тип мероприятия».


.2.3 Справочник «УчебныеГоды»

Структура справочника «УчебныеГоды» (рисунок 29).

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


.2.4 Справочник «Сотрудники»

Рассмотрим состав реквизитов справочника «Сотрудники» (рисунок 30). Логически этот справочник служит для хранения информации о сотрудниках ВолГУ. Реквизит «ДатаНачала» хранит дату поступления на работу. «Актуальность», реквизит логического типа, указывает является ли сотрудник действующим или нет. Реквизит «Должность» представляет собой ссылку на элемент справочника «Должности». «Вид занятости» представляет собой ссылку на элемент перечисления «Вид занятости». Реквизит «Физлицо» представляет собой ссылку на элемент справочника «ФизическиеЛица».


.2.5 Справочник «ФизЛица»

Рассмотрим состав реквизитов справочника «ФизЛица» (рисунок 31). Логически этот справочник служит для хранения информации о физических лицах ВолГУ. Каждый из реквизитов является реквизитом строчного типа и хранит информацию согласно его наименованию.


.2.6 Справочник «Должности»

Помимо стандартных атрибутов - кода и названия, в перечень реквизитов были добавлены «НаименованиеКраткое» и «НаименованиеСокращенное», а также реквизит «ТипДолжности», который представляет собой ссылку на элемент перечисления «ТипыДолжностей» (рисунок 32).


.2.7 Перечисление «ВидыЗанятости»

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


.2.8 Перечисление «ТипДолжностей»

Перечисление «ТипДолжностей» (рисунок 34) используется в справочнике «Должности» (рисунок 32). Значениями данного перечисления являются типы должностей, характеризующие принадлежность сотрудника к группе административных должностей.


3.3 Тестирование модуля «Планирование и отчетность учебно-воспитательной работы ППС»


Проведем тестирование разработанного модуля «Планирование и отчетность учебно-воспитательной работы ППС». Рассмотрим внешний вид рабочего пространства в конфигурации «Планирование и отчетность учебно-воспитательной работы ППС» на платформе «1С: Предприятие 8.2».

Работа с конфигурацией начинается с создания документа «План УВР ППС» (рисунок 36).

Однако для заполнения реквизитов документа требуется заполнения справочника «Мероприятия» (рисунок 37).

В свою очередь для заполнения справочника «Мероприятия» требуется заполнить справочник типов мероприятий (рисунок 38).

После проведения документа данные по участникам и ответственным заносятся в регистры сведений «Участники запланированных мероприятий» и «Ответственные запланированных мероприятий».

Для введения информации о прошедших мероприятиях используется документ «Отчет УВР ППС» (рисунок 39).

После проведения документа данные по участникам и ответственным заносятся в регистры сведений «Участники прошедших мероприятий» и «Ответственные прошедших мероприятий».

В системе предусмотрены два вида отчетов «План УВР ППС» (рисунок 41) и «Отчет УВР ППС» (рисунок 40). Они формируются из регистров сведений описанных ранее. В качестве параметров отчетов выступают «Сотрудник» и «Учебный год».

Таким образом, проведенное тестирование показало работоспособность разработанного модуля «Планирование и отчетность учебно-воспитательной работы ППС».


Заключение


В ходе выполнения дипломной работы были решены следующие задачи:

) Разработаны модели «как есть» и «как будет» БП «Планирование учебно-воспитательной работы» в нотации IDEF0 с использованием среды Ramus Educational.

) Разработана диаграмма потоков данных.

) Спроектирована и реализована структура данных подсистемы «Планирование и отчетность» конфигурации на платформе «1С: Предприятие 8».

) Создана и протестирована конфигурация на платформе «1С: Предприятие 8».

Созданная конфигурация может быть использована профессорско-преподавательским составом ВолГУ для учета, планирования и отчетности по учебно-воспитательной работе.

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


Литература


1. Douglas, Christian Modern Designing Information Systems. Bookpress, 2008. - 531 p.

. MacPherson, Colin The nuances of building data flow diagrams Wordpress, 2003. - 200 p.

. Petzold, Charles Idef0 notation. Description. Examples. Apress; December, 2010. - 300 p.

. Schmeichel, Udo, IT Service Management Taschen, 2006. - 821 p.

. Torbernite, Kurt The life cycle of software Letter be, 2007. - 667 p.

. Vieira, Robert The professional approach of the it developer Wiley Publishing, inc 2012. - 552 p.

. Антонов, Ю.Т Современная методология проектирования ИС [Текст]. - CПб.: БХВ-Петербург, 2007. - 413 с.

. Борисов, Б.В. Профессиональная разработка в «1С: Предприятие 8» [Текст]. - Спб: Корона принт, 2008. - 257 с.

. Болтов, С.В. Разработка сложных отчетов в «1С: Предприятие 8.2». Система компоновки данных [Текст]. - Спб: Корона принт, 2012. - 546 с.

. Ваганов, Д.М. 1С: Предприятие 8.2. Практическое пособие. Примеры и типовые приемы [Текст]. - Спб: 1С-Паблишинг, 2011. - 378 с.

. Веснин, К.А. 1С: Предприятие 8.0. Простые примеры разработки [Текст]. - Спб: 1С-Паблишинг, 2006. - 605 с.

. Востряков, М.С. 1С: Предприятие 8.2. Коротко о главном. Новые возможности версии 8.2 [Текст]. - М.: Символ, 2009. - 247 с.

. Горбатов, А.Т Технологии интеграции «1С: Предприятия 8.2» [Текст]. - Спб: 1С-Паблишинг, 2010. - 383 с.

. Гостров, Г.Н. 1С: Предприятие 8. Программирование [Текст]. - Спб: 1С-Паблишинг, 2008. - 570 с.

. Додин, Г.П. 1С: Предприятие: создание конфигураций для всех [Текст]. - М.: Диалог-МИФИ, 2008. - 448 с.

. Долгов, Е.А. Проектирование информационных систем [Текст]. - М.: Символ, 2008. - 753 с.

. Дятлов, И.В. Разработка программных продуктов с использованием современных методологий [Текст]. - М.: Символ-Плюс, 2001. - 811 с.

. Иванов, В.В. 1С: Предприятие. От 8.1 к 8.2 [Текст]. - Спб: 1С-Паблишинг, 2009. - 472 с.

. Ионов, А.В. 1С: Предприятие. Эффективное программирование [Текст]. - М.: Новое знание, 2007. - 559 с.

. Колоколов, С.М. Разработка конфигурации в системе 1С 8.2 для начинающих [Текст]. - CПб.: БХВ-Петербург, 2008. - 716 с.

. Кононов, К.Н. 1С: Предприятие. Комплексная конфигурация. Секрет работы [Текст]. - CПб.: БХВ-Петербург, 2006. - 499 с.

. Маклаков, В.М Создание информационных систем с AllFusion Modelling Suite [Текст]. - М.: Диалог-МИФИ, 2003. - 624 с.

. Николаенко, П.П. Практическое пособие по программированию в системе «1С: Предприятие 8.2» [Текст]. - Спб: 1С-Паблишинг, 2009. - 396 с.

. Орлов, И.Ю. Реализация прикладных задач в системе «1С: Предприятие 8.2» [Текст]. - CПб.: БХВ-Петербург, 2010. - 588 с.

. Павлов, Н.В. Программирование в системе 1С: 8.2 для начинающих [Текст]. - CПб.: БХВ-Петербург, 2010. - 588 с.

. Петушков, В.Е. Конфигурирование в 1с: 8.2 для профессионалов [Текст]. - Спб: 1С-Паблишинг, 2009. - 476 с.

. Пистолетов, А.А. Основы программирования в 1С: Предприятие [Текст]. - Спб: 1С-Паблишинг, 2008. - 779 с.

. Ракитов, С.О. Базовые навыки реализации конфигураций в 1С: Предприятие [Текст]. - Спб: 1С-Паблишинг, 2009. - 402 с.

. Рябцев, Г.Е. Методы проектирования информационных систем [Текст]. - М.: Символ, 2004. - 539 с.

. Самарин, В.И. 1С: Предприятие. Встроенный язык написания конфигурации [Текст]. - Спб: 1С-Паблишинг, 2008. - 306 с.

. Яковлев, П.Р. Проектирование информационных систем [Текст]. - Ростов-на-Дону: Феникс, 2009. - 512 с.



Федеральное государственное автономное образовательное учреждение высшего профессионального образования «Волгоградский государственный университет

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ