WWW.KNIGA.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА - Книги, пособия, учебники, издания, публикации

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНДУСТРИАЛЬНЫЙ УНИВЕРСИТЕТ»

(ФГБОУ ВПО «МГИУ»)

Кафедра информационных систем и технологий

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

по направлению 230100 «Информатика и вычислительная техника»

на тему «Разработка информационной системы учета протоколов заседаний кафедры в рамках единой ERP системы ФГБОУ ВПО «МГИУ»»

Студент /Орленко Н.И./ Руководитель работы зав.каф., доцент, к.ф.-м.н. /Роганов Е.А./

ДОПУСКАЕТСЯ К ЗАЩИТЕ

Зав. каф. 36, доцент, к.ф.-м.н. /Роганов Е.А./ Москва Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Московский государственный индустриальный университет (ФГБОУ ВПО «МГИУ») Кафедра: Информационные системы и технологии Зав. Кафедрой / Роганов Е.А. / « » 20 г.

ЗАДАНИЕ

на выпускную квалификационную работу по направлению «Информационные системы и технологии»

1. Тема работы: «Разработка информационной системы учёта протоколов заседаний кафедры в рамках единой ERP системы ФГБОУ ВПО «МГИУ»

2. Сроки начала работы: 04.06.2012, защиты 21.06. 3. Руководитель дипломной работы: Роганов Евгений Александрович зав.каф., к.ф.-м.н., доцент 4. Задание дипломной работы:

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

Содержание дипломной работы:

1) Аннотация.

2) Введение.

3) Литературный обзор.

4) Структура системы.

5) Описание интерфейсной части.

6) Заключение.

7) Приложения.

8) Список литературы.

Используемые технологии: Ruby on Rails, Apache, jQuery, PostgreSQL, LaTeX.

Практическая реализация: данная работа может найти применение в МГИУ на кафедре информационных систем и технологий.

Графическая часть:

1) Диаграмма классов 2) Диаграмма вариантов использования 3) Форма авторизации 4) Сообщение о неправильном логине или пароле 5) Список протоколов 6) Действия, доступные обычному пользователю 7) Группировка по годам 8) Поиск протоколов 9) Основная часть формы протокола 10) Создание темы повестки дня из существующей 11) Просмотр протокола в формате HTML 12) Пример вывода протокола в формате PDF 13) Управление шаблонами протоколов 14) Форма создания шаблона 15) Протоколы с выбранным шаблоном 16) Добавление сотрудника 17) Управление пользователями системы Оглавление Введение




Глава 2. Структура системы

2.1. Общее описание структуры

2.2. Управление составом кафедры

2.3. Ролевая система

2.4. Управление протоколами

2.5. Управление шаблонами протоколов

Глава 3. Описание интерфейсной части

3.1. Авторизация

3.2. Интерфейс для работы с протоколами

3.2.1. Список протоколов

3.2.2. Поиск протоколов

3.2.2. Создание, изменение протокола

3.2.2. Просмотр в формате HTML, подписание, создание выписки........ 3.2.3. Вывод протокола в формате PDF

3.3. Интерфейс для управления шаблонами

3.4. Интерфейс для управления составом кафедры

3.5. Интерфейс для управления пользователями

Заключение

Приложение A

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

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

Работа содержит 50 страниц, 18 иллюстраций, 1 приложение.

Ключевые слова: информационная система, протокол, заседание кафедры, Ruby, Ruby on Rails.

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

Поэтому автоматизация документооборота организации является актуальной задачей.

В ФГБОУ ВПО МГИУ на кафедре информационных систем и технологий одним из важных процессов, связанных с деятельностью кафедры, является документирование заседаний. Ранее протоколы составлялись на бумаге от руки, что значительно тормозило процесс их составления. Но с появлением компьютеров и текстовых редакторов, а в дальнейшем и офисных пакетов, этот процесс стал более быстрым и удобным. Технологии не стоят на месте и на сегодняшний день существует большое количество средств, таких как базы данных и СУБД [1], а так же различные web-технологии, с помощью которых можно было бы создать целую информационную систему для управления и документирования заседаний кафедры. Новая система учета протоколов заседаний кафедры должна значительно повысить эффективность документооборота заседаний кафедры университета, а так же создаст единый стиль оформления принимаемых решений. Размещение в сети даты, времени и места проведения очередных заседаний, а так же уведомление всех членов кафедры, позволит сделать заседания более открытыми. Такой информационной системой будут пользоваться все сотрудники, принимавшие участие в деятельности кафедры.





Глава 1. Литературный обзор 1.1. Обзор существующих решений По мере развития деятельности вузов возрастает документооборот и возникает необходимость в интенсификации делопроизводственных процессов. В настоящее время вопросу автоматизации делопроизводства уделяется довольно большое время. Использование систем делопроизводства и документооборота позволяет реализовать новые возможности управления документооборотом, оперативно выполнять информационно-справочную, аналитическую работу, а также улучшить взаимодействие структурных подразделений и достичь более высокой оперативности в работе.

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

Существует множество различных решений для автоматизации делопроизводства учебных заведений при помощи систем электронного документооборота (СЭДО) [3]. На сегодняшний день существует огромное количество таких систем, но все они разрабатываются с единой целью – создать единый механизм по работе с документами, представленными в делопроизводства» [4]. Однако создание универсального инструмента, который удовлетворил бы требования всех современных организаций, является довольно важной и нетривиальной задачей. Ниже представлен обзор одних из наиболее популярных на российском рынке систем электронного документооборота.

«1С: Документооборот»

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

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

• отсутствие развитой системы поиска документов в БД;

• громоздкий графический интерфейс. Освоение системы и обучение персонала требует большое количество времени и материальных • ограниченное представление информации, находящейся в БД;

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

«DIRECTUM: Управление совещаниями и заседаниями»

«DIRECTUM» [6] — система электронного документооборота и управления взаимодействием, нацеленная на повышение эффективности работы всех сотрудников организации в разных областях их совместной деятельности. Система «DIRECTUM» относится к классу ECM-систем (Enterprise Content Management) [7] и поддерживает полный жизненный цикл управления документами, при этом традиционное «бумажное»

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

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

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

• высокая стоимость;

• зависимость от платформ Microsoft;

• стоимость автоматизации складывается не только из стоимости программного обеспечения, но и из услуг по внедрению;

• стоимость услуг по внедрению определяется в зависимости от потребности Заказчика и может быть как равна нулю (приобретение коробочного решения), так и достигать значительных сумм при автоматизации не типовых задач;

• если при внедрении требуется изменение разработки на системном уровне, то потребуются дополнительные материальные, временные и трудозатраты при обновлении до новой версии.

Текущая ситуация В настоящее время в московском государственном индустриальном университете (ФГБОУ ВПО «МГИУ» [8]) на кафедре информационных технологий для работы с документами используются различные инструменты для работы с текстовой информацией. Например, составление протокола заседания и создание выписки осуществляется с помощью популярных офисных пакетов, таких как OpenOffice [9] и Microsoft Office [10]. Сами протоколы хранятся в виде большого набора файлов, каждый из которых лежит в директории с именем номера года. Такой подход сильно устарел и несет в себе массу недостатков. Например, для того, чтобы найти протокол по известной теме или по её содержательной части, необходимо открывать каждый файл отдельно и искать нужный текст, что довольно долго и неудобно. При составлении протокола часто бывает, что темы могут совпадать. В таком случае нужно либо писать текст заново вручную, либо опять же искать протокол и копировать из него необходимый материал. Кроме всего перечисленного имеется множество других недостатков, но особого внимания заслуживает проблема, связанная с шаблонами. Примерно каждый год меняются требования к оформлению протоколов. Однако информация о замене шаблона часто доходит до кафедры спустя несколько месяцев и приходится редактировать шаблон созданных протоколов вручную, а это довольно трудоёмкая работа.

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

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

• создание, редактирование протоколов, с возможностью подгружать темы из других протоколов;

• создание, изменение, применение шаблонов;

• создание выписки из протокола;

• создание протокола на основе существующего;

• быстрый просмотр протокола;

• просмотр, сохранение в печатном формате (PDF [11]);

• сортировку по дате, номеру протокола;

• поиск протокола по его содержимому;

• быструю навигацию по содержательной части протокола;

• визирование протокола (электронная подпись);

• возможность подгружать данные из другой системы (например, список сотрудников);

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

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

• шапка;

• номер протокола;

• дата проведения заседания;

• название кафедры;

• фамилия и инициалы председателя, секретаря;

• фамилия и инициалы присутствующих на заседании;

• повестка дня (список обсуждаемых вопросов, что слушали, кто выступал, что постановили);

• фамилия и инициалы заведующего кафедры.

•В системе предлагается выделить следующие функциональные подсистемы:

• подсистема обработки и загрузки данных, которая предназначена для реализации процессов сбора данных, приведения указанных данных к виду, необходимому для передачи в подсистему хранения данных;

• подсистема формирования и визуализации протоколов и выписок.

• Предусмотрены следующие роли:

• заведующий кафедрой;

• секретарь;

• обычный пользователь.

Заведующий кафедрой имеет практически полный доступ к системе.

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

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

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

Все пользователи смогут осуществлять поиск протоколов по его содержимому, для дальнейшего просмотра, редактирования или визирования.

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

1.3. Используемые технологии Ruby on Rails При разработке информационной системы будет использоваться интегрированная среда разработки Ruby on Rails [12] (сокращенно RoR). RoR — это ориентированное на создание веб-приложений сочетание двух элементов: языка программирования Ruby [13] и программного окружения (иными словами, «программного каркаса»). Ruby – это интерпретируемый язык сценариев для быстрого и лёгкого объектно-ориентированного программирования. RoR – полноценный, многоуровневый фреймворк для построения веб-приложений, использующих базы данных, основанный на архитектуре «Модель-Представление-Контроллер» (Model-View-Controller, сокращённо MVC) [14]. MVC является схемой-паттерном для создания гибких и легко расширяемых приложений с пользовательским интерфейсом.

Эта схема была разработана создателями языка Smalltalk-80 ещё 25 лет назад, однако остаётся чрезвычайно актуальной и по сей день. Модель MVC представляет собой сочетание трёх важных компонентов:

• Представление – модуль вывода информации на экран. Простыми словами это то, что видит пользователь, когда открывает сайт в браузере. Обычно представляет собой шаблон, написанный на какомлибо языке разметки (среди популярных, ERB [15], HAML [16], HTML [17]), который дает возможность вставлять пользовательский (JavaScript) и серверный код в шаблон для создания динамической страницы. Но в конечном итоге всё преобразовывается в HTML страницу, понятную браузеру;

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

Полученный результат отправляется в контроллер для последующей обработки и передачи в представление;

• Контроллер – отвечает за управление вводом и выводом данных.

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

Особенность RoR состоит в том, что данный инструментарий и на уровне языковых конструкций, и на уровне «программных каркасов»

позволяет быстрее и эффективнее справляться с задачами, иногда сводя их решение к паре строк исходного кода. Среда RoR постоянно развивается.

Разработчики ядра вносят изменения, добавляют новые свойства, устраняют ошибки, что позволяет фреймворку «идти в ногу со временем» и не отставать от новых технологий. За месяцы, прошедшие с момента с начального выпуска, RoR прошла путь от малоизвестной забавной технологии до феномена мирового масштаба. Она удостоилась наград, но, что более важно, стала именно той средой разработки, которую стали выбирать для создания широкого круга веб-приложений. И это не только модное веяние среди утонченных знатоков: RoR используется для создания веб-приложений многими интернациональными компаниями. Именно поэтому RoR был выбран в качестве основного инструмента для разработки информационной системы. Средствами RoR можно быстро и без особых «накладных расходов»

создавать интерактивные сайты, а так же интерфейсы к уже существующим веб-сервисам или создавать новые. Динамичный AJAX-интерфейс, обработка запросов и выдача данных в контроллерах, предметная область, отраженная в базе данных, — для всего этого RoR предоставляет однородную среду разработки. Все, что необходимо для начала — база данных и веб-сервер.

Веб-сервер Так как информационная система будет работать на платформе Ruby on Rails, следует уделить внимание выбору правильного веб-сервера.

Существует большое количество серверов, предназначенных для развертывания веб-приложений. Например, Mongrel [18] (c англ. пестрый) является HTTP-сервером и библиотекой, написанной на Ruby, которая предназначена для хостинга разнообразных веб-приложений, написанных на языке программирования Ruby, используя HTTP протокол [19]. Mongrel способен самостоятельно обслуживать Ruby on Rails приложения, без использования сторонних веб-серверов, однако является однопоточным приложением и не пригоден к большим нагрузкам. Самый очевидный недостаток Mongrel заключается в том, что каждый из серверов в силу своей автономности будет загружать в память собственную копию кода rails, кода приложения и всех необходимых библиотек. При среднем проекте каждый mongrel запросто потребляет около 100Мб оперативной памяти. И если запускать на сайт по три сервера mongrel, то память будет потребляться в очень больших количествах. Ещё одной слабой стороной сервера является то, что он обязательно занимает один порт. Это создает возможность для различных коллизий и трудно отслеживаемых ошибок.

В качестве рабочего веб-сервера для информационной системы рекомендуется использовать Apache [20] – самый популярный веб-сервер по данным Netcraft. Он применяется почти на 400 млн сайтов, или на 65% от общего их количества. Apache имеет ряд преимуществ, по сравнению с другими серверами, такие как высокая производительность, доступность, безопасность, меньший объем потребляемой памяти. Apache пользуется большой популярностью у таких известных компаний как Google, Microsoft и др.

PostgreSQL PostgreSQL [21] – это объектно-реляционная система управления базами данных, работающая как клиент-серверная система. PostgreSQL соответствует базовой спецификации SQL99 и поддерживает большое число возможностей, описанных стандартом SQL92 [22]. PostgreSQL имеет мощные и надёжные механизмы транзакции, обладает высокой производительностью, отказоустойчивостью, а так же позволяет создавать БД практически неограниченного размера. Поэтому для работы информационной системы, в качестве СУБД был выбран именно PostgreSQL.

JQuery Jquery [23] – это одна из самых мощных кроссбраузерных, свободнораспространяемых библиотек, написанная на языке JavaScript [24], созданная с целью упростить создание интерактивных и динамических веб-страниц.

Преимущества jQuery:

• маленький размер исходного кода библиотеки;

• высокая скорость разработки;

• богатый выбор расширений;

• понятная и полная документация;

• принцип «пиши меньше, делай больше» («write less, do more»).

JQuery позволяет с лёгкостью добавлять на страницы веб-сайта красивые эффекты, делая веб-сайт интерактивным и приятным в использовании. Кроме того, благодаря наличию плагинов, базовая функциональность jQuery может быть легко расширена. Библиотека постоянно развивается. Релиз версии 1. состоялся в январе 2010 года. jQuery 1.4 получила много новых функций, расширений и имеет значительно лучшую производительность.

LaTeX Для вывода документов в формате PDF будет использоваться пакет компьютерной верстки LaTeX [25]. Пакет позволяет автоматизировать многие задачи набора текста и подготовки статей, включая набор текста на нескольких языках. Среди основных преимуществ LaTeX – принадлежность к классу свободного программного обеспечения, высокое полиграфическое качество продукта, гибкость издательских настроек при подготовке многостраничных документов, специальные средства для набора математических конструкций и др.

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

• управление составом кафедры;

• управление пользователями (ролевая система);

• управление протоколами;

• управление шаблонами протоколов.

Диаграмма классов, а так же диаграмма вариантов использования системы представлены на рисунках 2 и 3:

Рис. 3 Диаграмма вариантов использования 2.2. Управление составом кафедры Подсистема управления составом кафедры представляет собой взаимосвязь следующих компонентов:

• сотрудник;

• должность;

• учёная степень.

Основной моделью для управления составом кафедры является модель «Employee» (сотрудник). У сотрудника имеются следующие поля:

• фамилия (f);

• имя (i);

• отчество (o);

• должность (post_id);

• флаг удаления (deleted).

Фамилия, имя, отчество (ФИО) имеет строковый тип (string), ограниченный 256 символами. На каждое поле ФИО накладываются следующие требования:

• обязательно для заполнения;

• длина строки должна быть не менее двух символов и не более 30;

• должна начинаться с заглавной буквы и состоять только из латинских букв или кириллицы.

Так как сотрудник может быть задействован в протоколах, то при увольнении сотрудника (или временном прибываний на кафедре) удалять из системы его нельзя. Достаточно пометить его как удалённый, для чего и служит флаг deleted, который имеет логический тип и может содержать значения true или false.

Каждый сотрудник, работающий на кафедре занимают определённую должность, такую как, например: заведующий кафедры, доцент, преподаватель, старший преподаватель, ассистент и др. За обработку информации о занимаемой должности сотрудника отвечает модель «Post», которая имеет всего лишь одно поле name (название должности). Сотрудник может занимать только одну должность, поэтому между моделью «Post» и «Employee» существует связь один ко многим.

Сотрудники кафедры вуза, как правило, могут иметь учёную степень, например: бакалавр, магистр, профессор, доктор наук, кандидат наук и др.

Для обработки этой информации служит модель «Degree», которая имеет одно поле name (название). Сотрудник может иметь несколько учёных степеней, поэтому между моделями «Degree» и «Employee» имеется связь один ко многим.

2.3. Ролевая система Часть системы, отвечающая за работы с пользователями системы (авторизация, раздача прав) называется ролевой системой и представляет собой взаимосвязь следующих компонентов:

• пользователь;

• электронная почта;

Модель User является основным компонентом ролевой системы. Она отвечает за управление пользователями и имеет следующие поля:

• логин (login);

• пароль (password);

• роль (role);

• сотрудник, привязанный к пользователю (employee_id).

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

• поле обязательно для заполнения;

• длина строки не менее 4-х символов;

• строка должна состоять из латинских букв, но может содержать цифры, при этом первой должна быть именно буква;

• значение поля должно быть уникальным в системе.

Поле password представляет собой собственный пароль пользователя и так же служит для авторизации в системе. Ограничения совпадают с ограничениями поля login, кроме того, что длина пароля должна быть не менее 6-ти символов и пароль не является уникальным для каждого пользователя.

Ролевая система представляет собой некоторый набор пользователей, которые можно разделить на:

• привилегированные пользователи;

• непривилегированные (обычные пользователи);

• не авторизованные пользователи.

Привилегированные пользователи:

• заведующий кафедрой;

• секретарь.

В зависимости от роли, пользователь имеет определённые права на доступ к системе. Например, заведующего кафедрой можно условно назвать администратором, так как он имеет практически полный доступ, а именно обладает следующими правами:

• регистрация пользователей;

• раздача прав пользователям;

• изменение состава кафедры (добавление/удаление сотрудников);

• создание, изменение протоколов;

• управление шаблонами протоколов;

• визирование протоколов;

• полный доступ на чтение.

Доступ на чтение подразумевает следующие возможности:

• просмотр списка протоколов;

• просмотр в печатном формате (PDF) или в виде HTML;

• создание выписки из протокола.

Секретарь так же является привилегированным пользователем и имеет следующие права:

• создание и рассылка повестки дня предстоящего заседания;

• создание, изменение протоколов (до того как он будет подписан);

• управление шаблонами;

• доступ на чтение.

Непривилегированные пользователи – это обычные сотрудники кафедры, зарегистрированные в системе. Такой пользователь имеет доступ только на чтение.

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

Для управления правами пользователей служит поле role модели «User». Оно имеет целочисленный тип и может иметь следующие значения:

• 0 – заведующий кафедрой;

• 1 – секретарь;

• 2 – авторизованный пользователь.

В зависимости от значения данного поля определяются права пользователя и предоставляются определённые возможности.

В ролевой системе каждый авторизованный пользователь привязан к сотруднику кафедры. Для этого у модели «User» присутствует поле employee_id, привязывающее пользователя к конкретному сотруднику.

Сотрудник может иметь несколько пользователей, поэтому между моделями «Employee» и «User» существует связь один ко многим.

У каждого пользователя кроме логина и пароля может присутствовать адрес электронной почты. Так как пользователь может иметь несколько адресов, за обработку этой информации отвечает модель «Email». Модель имеет всего лишь одно поле email строкового типа, а так же следующие ограничения:

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

• длина строки не менее 6 символов (включая символы «@», «.», название и домен почтового сервера);

• формат строки должен соответствовать формату обычной электронной почты: лат. символы + цифры (или без) + «@» + название почтового сервера + «.» + домен.

2.4. Управление протоколами Документ протокола с точки зрения системы представляет собой совокупность следующих компонентов:

• протокол;

• тема;

• элемент темы;

• аудитория.

Модель «Protocol» (протокол) является основным звеном подсистемы управления протоколами из которого строится полный документ. Сама модель представляет собой совокупность таких данных, как:

• номер протокола в году (number);

• аудитория (auditory_id);

• председатель (chairman_id);

• секретарь (secretary_id);

• дата и время заседания (date);

• шаблон протокола (template_id);

• подпись (signed);

• количество тем (count_themes).

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

• число должно быть положительным и отличным от нуля;

• не должно совпадать с номером в данном году протокола, а инкрементироваться в соответствии с предыдущими номерами в году.

Обычно заседание кафедры проходит в каком-то определённом месте, в частности, в аудитории. Для хранения этой информации служит поле auditory_id, которое является внешним ключом модели «Auditory». Модель «Auditory» имеет одно поле number строкового типа и обозначает номер аудитории в которой будет (или прошло) заседание.

Заседание обычно организовывает один выделенный сотрудник, который является председателем. Секретарь создает повестку дня для заседания, а так же составляет сам протокол. Так как все они задействованы в протоколе, в модели «Protocol» имеются поля chairman_id и secretary_id.

Поле chairman_id служит для хранения информации о председателе и представляет собой внешний ключ модели «Employee», так как председателем может быть только сотрудник кафедры. Для хранения информации о секретаре в протоколе присутствует поле secretary_id, которое так же является внешним ключом модели «Employee».

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

• год/месяц/день часы:минуты.

Электронная подпись протокола представляет собой поле signed, которое имеет логический тип и может принимать два значения: true (подписан) и false (не подписан).

Информация о тех, кто был на заседании, отражается в протоколе в виде списка присутствующих. Присутствующими могут быть как обычные сотрудники данной кафедры, так и приглашённые с других кафедр. Для хранения этой информации между моделями «Employee» и «Protocol»

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

Повестка дня заседания представляет собой список тем, которые будут обсуждаться на заседании. Модель «Theme» служит для представления этой информации в системе. Тема заседания содержит в себе следующие данные:

• название темы;

• постановление.

Для хранения данной информации, в модели «Theme» присутствуют поля description и decided, которые имеют специальный тип, предназначенный для хранения большого объёма информации (текста).

Каждая тема присутствует только в определённом протоколе.

Следовательно, между моделями «Protocol» и «Theme» существует связь один ко многим. Для этого в модели «Theme» есть поле protocol_id, которое представляет собой внешний ключ модели «Protocol».

Если посмотреть на пример протокола, то после списка тем идет содержание повестки дня, которое представляет собой элементы темы, имеющие следующие названия:

• слушали;

• выступили.

Для представления этой информации, в системе присутствует модель «ThemeMessage», которая состоит из таких полей как:

• тело сообщения (message);

• тип элемента (element_type);

• тема, к которой относится сообщение (theme_id).

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

• 0 – слушали;

• 1 – выступили.

Так как тема может содержать несколько сообщений, между моделями «Theme» и «ThemeMessage» существует связь один ко многим.

Во время операций по управлению протоколом, все рассмотренные элементы объединяются в один целый протокол.

2.5. Управление шаблонами протоколов Для того, чтобы документ соответствовал определённым требованиям, каждый протокол имеет некоторый шаблон, который применяется, в определённый срок. Для представления шаблонов протоколов, в системе предусмотрена модель «Template», которая имеет следующие поля:

• название (name);

• тело шаблона (body);

• дата начала применения (apply_from);

• дата конца применения (apply_to).

Поле name обозначает имя шаблона, которое представляет собой строку, на которую наложены следующие ограничения:

• длина не менее 3-х символов, может содержать цифры, но только в • название шаблона должно быть уникальным.

Поле body представляет собой тело шаблона и имеет строковый тип, предназначенный для хранения большого объёма символов. Может содержать любые символы.

Поля apply_from и apply_to предназначены для хранения информации о том, для каких протоколов будет применён данный шаблон. Имеют формат, предназначенный для хранения даты.

Таким образом структура информационной системы полностью описана.

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

• Интерфейс авторизации пользователей:

• Интерфейс для работы с протоколами:

вывод списка протоколов;

создание, изменение протокола;

вывод протокола в виде веб-страницы;

создание выписки из протокола;

визирование протокола (электронная подпись);

вывод протокола в печатном формате PDF;

создание протокола на основе существующего;

создание содержательной части протокола на основе уже существующих (повестка дня);

сортировка по различным ключам в списке протоколов;

быстрая навигация по содержательной части протокола;

поиск протоколов по любой его составной части.

• Интерфейс для работы с шаблонами протоколов:

создание, изменение шаблона;

просмотр шаблона в печатном формате PDF;

просмотр протоколов прикрепленных к шаблону;

установка шаблона.

• Интерфейс для управления составом кафедры:

добавление нового члена кафедры, изменение старых;

блокирование доступа сотрудника.

• Интерфейс для управления пользователями системы:

регистрация пользователей;

управление правами доступа.

Перейдем к более детальному рассмотрению вышеперечисленных интерфейсов.

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

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

Рис. 5. Сообщение о неправильном логине или пароле Система авторизации пользователей представляет собой совокупность следующих компонентов:

• пользователь;

• сессия.

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

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

На форме авторизации, так же присутствует галочка «Запомнить меня».

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

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

• номер протокола в учебном году;

• дата и время заседания;

• доступные действия над протоколом;

• информация об электронной подписи;

• количество тем в повестке дня;

• фамилия и инициалы председателя и секретаря;

• номер аудитории;

• состояние заседания;

• шаблон, примененный к конкретному протоколу;

Графический интерфейс списка протоколов:

В столбце «Действия» по умолчанию представлены три колонки, содержащие следующие ссылки:

• просмотр в HTML формате, подписание, создание выписки;

• просмотр в формате PDF;

• редактирование протокола.

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

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

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

На главной странице так же имеется возможность поменять тип отображения списка протоколов. Существует два типа:

• обычный список (по умолчанию);

• группировка по учебным годам.

При выборе типа «группировка по годам» протоколы группируются, по учебном году:

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

• Основная часть:

номер протокола, год создания, аудитория;

председатель и секретарь.

• Содержательная часть (повестка дня):

название темы протокола;

постановление;

кого слушали, кто выступал.

• Дополнительные параметры:

подписанные/не подписанные;

не заполненные;

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

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

3.2.2. Создание, изменение протокола Рассмотрим интерфейс для создания протокола. Он представляет собой форму, в которую заносятся данные о протоколе. Форма состоит из основной и содержательной части. Основная часть состоит из:

• ФИО председателя, секретаря;

• номер аудитории;

• дата и время заседания;

• список присутствующих на заседании;

Графический интерфейс основной части:

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

• название темы;

• слушали;

• выступали;

• постановили.

При создании повестки дня в системе имеется возможность создавать темы из уже существующих. Для этого на форме повестки предусмотрен элемент select, в котором отображается список тем из предыдущих протоколов. Выбирая одну из тем, система подгружает данные о ней и дает возможность добавить эту тему в форму протокола.  Рис. 11. Создание темы повестки из существующей При создании таких элементов темы протокола, как слушали и выступали имеется возможность вставлять в поле обычные HTML теги, такие как:

• жирный шрифт b;

• курсив i;

• нумерованный список ol;

• маркированный список ul.

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

3.2.2. Просмотр в формате HTML, подписание, создание выписки На главной странице в списке протоколов можно выбрать в столбце «Действия» ссылку для перехода на страницу быстрого просмотра протокола. Она представляет собой пример вывода протокола в виде вебстраницы. На странице просмотра можно переключаться между протоколами с помощью навигационных стрелок.

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

Для создания выписки из протокола на странице HTML просмотра предусмотрена форма для создания выписки. Выбирая определенные темы в протоколе, можно создавать выписку. Если не выбрана ни одна тема, система скажет об этом пользователю с помощью соответствующего сообщения.

Графический интерфейс просмотра протокола в формате HTML:

Рис. 12. Просмотр протокола в формате HTML 3.2.3. Вывод протокола в формате PDF Для вывода протокола в формате PDF на странице списка протоколов предусмотрена специальная ссылка, которая находится в столбце «Действия»

второй по счету после просмотра в формате HTML.

Перед тем, как вывести протокол в печатном формате система собирает все необходимые данные о выбранном протоколе и объединяет их в один целый протокол.

Вывод в формат PDF осуществляется с помощью подключаемого модуля rails­latex. После сбора данные подставляются в шаблон протокола. Затем с помощью модуля rails­latex, код протокола преобразовывается в код языка компьютерной верстки LaTeX и в конце концов конвертируется в печатный формат PDF. Пример вывода протокола в формате PDF:

Рис. 13. Пример вывода протокола в формате PDF 3.3. Интерфейс для управления шаблонами На главной странице отображается кнопка для перехода на страницу для управления шаблонами. Она представляет собой список шаблонов в виде таблицы со следующими столбцами:

• название шаблона;

• действия;

• применение шаблона;

• просмотр протоколов с данным шаблоном.

В столбце «Действия» доступны такие ссылки как:

• просмотр шаблона в формате PDF;

• редактирование шаблона.

Вывод шаблона в формате PDF аналогичен просмотру протокола и работает по следующему принципу. Берется первый протокол с данным шаблоном и выводится в формате PDF. Если такого протокола нет, выводится соответствующее сообщение. Графический интерфейс страницы управления шаблонами:

Рис. 14. Управление шаблонами протоколов.

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

Шаблон представляет собой некоторый код на языке LaTeX. При создании шаблона указывается его имя и вставляется код. Графический интерфейс формы шаблона:

Просмотр протоколов с шаблоном представляет собой список тех протоколов, к которым применен данный шаблон. При нажатии на ссылку «Показать» в столбце «Протоколы» на странице списка шаблонов осуществляется поиск протоколов с выбранным шаблоном. Затем найденные протоколы выводятся прямо этой же на странице. Пример вывода списка протоколов с данным шаблоном:

3.4. Интерфейс для управления составом кафедры Управление составом кафедры подразумевает следующие действия:

• добавление нового сотрудника, изменение старых;

• блокирование доступа.

Страница управления составом кафедры представляет собой список сотрудников в виде таблицы со следующими столбцами:

• ФИО;

• должность;

• ученое звание;

• ученые степени;

• действия.

• роль с системе.

Добавление сотрудника осуществляется с помощью заполнения специальной формы:

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

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

• логин;

• адрес электронной почты;

• сотрудник;

• роль в системе.

Управление пользователями подразумевает такие действия как:

• регистрация новых пользователей, либо удаление старых;

• изменение прав доступа к системе.

Графический интерфейс управления пользователями системы:

Рис. 18. Управление пользователями системы Таким образом интерфейсная часть проекта полностью описана.

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

В ближайшем будущем планируется дальнейшее развитие системы:

• интеграция с другими ИС университета;

• разработка модуля для оповещений сотрудников по почте или SMS;

• разработка модуля для учёта ошибок при составлении протокола;

• переход на новую версию Ruby on Rails 3.2.6 (текущая версия 3.1.1);

• разработка версий для мобильных устройств (iPhone, Android и др.).

Приложение A Схема данных системы ActiveRecord::Schema.define(:version =    create_table "academic_titles", :force = true do |t|     t.string   "name"     t.string   "short_name"     t.datetime "created_at"     t.datetime "updated_at"   end   create_table "auditories", :force = true do |t|     t.string "number"   end   create_table "degrees", :force = true do |t|     t.string  "name"     t.integer "employee_id"   end   add_index "degrees", ["employee_id"], :name =    "index_degrees_on_employee_id"   create_table "degrees_employees",    :force = true do |t|     t.integer "degree_id"     t.integer "employee_id"   end   create_table "dictionaries", :force = true do |t|     t.string   "word"     t.datetime "created_at"     t.datetime "updated_at"   end   create_table "emails", :force = true do |t|     t.string  "email"     t.integer "user_id"   end   add_index "emails", ["user_id"], :name =    "index_emails_on_user_id"   create_table "employees", :force = true do |t|     t.string   "f"     t.string   "i"     t.string   "o"     t.integer  "post_id"     t.datetime "created_at"     t.datetime "updated_at"     t.boolean  "deleted", :default = false     t.integer  "academic_title_id"     t.integer  "user_id"   end   add_index "employees", ["academic_title_id"],     :name = "index_employees_on_academic_title_id"   add_index "employees", ["post_id"],     :name = "index_employees_on_post_id"   add_index "employees", ["user_id"],     :name = "index_employees_on_user_id"   create_table "employees_protocols",    :id = false, :force = true do |t|     t.integer "protocol_id"     t.integer "employee_id"   end   create_table "participants",    :force = true do |t|     t.integer  "theme_id"     t.integer  "employee_id"     t.text     "message"     t.integer  "party_type"     t.datetime "created_at"     t.datetime "updated_at"   end   create_table "posts", :force = true do |t|     t.string "name"     t.string "short_name"   end   create_table "protocol_templates",    :force = true do |t|     t.text      "body"     t.datetime  "created_at"     t.datetime  "updated_at"     t.string    "name",            :default = "Template"     t.timestamp "apply_from",      :default = '2012­04­26 15:24:30'     t.timestamp "apply_to",        :default = '2012­04­26 15:24:30'   end   create_table "protocols",    :force = true do |t|     t.integer  "chairman_id"     t.integer  "secretary_id"     t.integer  "protocol_template_id"     t.integer  "auditory_id"     t.datetime "date"     t.integer  "state"     t.datetime "created_at"     t.datetime "updated_at"     t.boolean  "signed",                    :default = false     t.boolean  "is_fill",                   :default = false     t.integer  "number",                    :default =      t.integer  "count_themes",              :default =      t.text     "invited"   end   add_index "protocols", ["auditory_id"],    :name = "index_protocols_on_auditory_id"   add_index "protocols", ["protocol_template_id"],    :name = "index_protocols_on_protocol_template_id"   create_table "searches", :force = true do |t|     t.integer  "year"     t.integer  "number"     t.datetime "created_at"     t.datetime "updated_at"   end   create_table "themes", :force = true do |t|     t.integer  "protocol_id"     t.text     "description"     t.text     "decided"     t.datetime "created_at"     t.datetime "updated_at"   end   add_index "themes", ["protocol_id"],    :name = "index_themes_on_protocol_id"   create_table "users", :force = true do |t|     t.string   "login", :limit =      t.string   "name",  :limit = 100, :default = ""     t.string   "crypted_password", :limit =      t.string   "salt",  :limit =      t.datetime "created_at"     t.datetime "updated_at"     t.string   "remember_token", :limit =      t.datetime "remember_token_expires_at"     t.integer  "role", :default =      t.integer  "employee_id"   end   add_index "users", ["employee_id"],     :name = "index_users_on_employee_id"   add_index "users", ["login"],    :name = "index_users_on_login", :unique = true   create_table "versions", :force = true do |t|     t.string   "item_type",  :null = false     t.integer  "item_id",    :null = false     t.string   "event",      :null = false     t.string   "whodunnit"     t.text     "object"     t.datetime "created_at"   end   add_index "versions", ["item_type", "item_id"],    :name = "index_versions_on_item_type_and_item_id" end Список литературы [1] В.Ю. Радыгин. «Базы данных и СУБД» — М.: МГИУ, 2011.

[2] Ирена Гваева, Сергей Собалевский. «Делопроизводство» — ТетраСистемс, 2011.

[3] В. Н. Чернов. «Системы электронного документооборота» — РАГС, [4] Статья о безбумажном делопроизводстве http://www.hrportal.ru/article/bezbumazhnoe-deloproizvodstvo.

[5] 1С:Документооборот http://ru.wikipedia.org/wiki/1С:Документооборот.

[6] Directum http://ru.wikipedia.org/wiki/Directum.

[7] Enterprise Content Management http://en.wikipedia.org/wiki/Enterprise_content_management.

[8] Официальный сайт МГИУ www.msiu.ru.

[9] OpenOffice http://en.wikipedia.org/wiki/OpenOffice.

[10] Microsoft Office http://en.wikipedia.org/wiki/Microsoft_office.

[11] Portable Document Format http://en.wikipedia.org/wiki/Portable_Document_Format.

[12] Д. Томас, Д.Х. Хэнсон «Гибкая разработка веб-приложений в среде Rails» — СПб.: Питер, 2008.

[13] Е. А. Роганов, Н. А. Роганова. «Программирование на языке Ruby» — М.: МГИУ, 2008.

[14] MVC http://msdn.microsoft.com/en-us/library/ff649643.aspx.

[15] ERB http://en.wikipedia.org/wiki/ERuby.

[16] HAML http://en.wikipedia.org/wiki/Haml.

[17] HTML http://en.wikipedia.org/wiki/HTML.

[18] Mongrel http://en.wikipedia.org/wiki/Mongrel_(web_server).

[19] HTTP http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol.

[20] Статья «почему Apache?» http://av5.com/journals-magazinesonline/1/28/218.

[21] PostgreSQL — первые шаги http://www.opennet.ru/base/dev/postgresql_first.txt.html.

[22] SQL92 http://en.wikipedia.org/wiki/SQL-92.

[23] Самков Г. «jQuery. Сборник рецептов». — СПб.: БХВ-Петербург, 2010.

[24] Дэвид Флэнаган «JavaScript. Подробное руководство»

[25] Дональд Кнут «Всё про TeX». — М.: Вильямс, 2003.



Похожие работы:

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

«РОССИЙСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ МЕДИЦИНСКИЙ УНИВЕРСИТЕТ ИМЕНИ Н. И. ПИРОГОВА НАУЧНАЯ БИБЛИОТЕКА БЮЛЛЕТЕНЬ НОВЫХ ПОСТУПЛЕНИЙ Выпуск третий Москва, 2013 СОДЕРЖАНИЕ ПРАВО СОЦИОЛОГИЯ СОЦИАЛЬНАЯ РАБОТА ФИЛОСОФИЯ БИОЭТИКА ИСТОРИЯ МЕДИЦИНЫ ИНОСТРАННЫЙ ЯЗЫК ИНФОРМАТИКА ВЫСШАЯ МАТЕМАТИКА ФИЗИКА БИОФИЗИКА ХИМИЯ БИОХИМИЯ БИОТЕХНОЛОГИЯ НАНОБИОТЕХНОЛОГИИ РАДИОБИОЛОГИЯ БИОЛОГИЯ БИОМЕДИЦИНА ГИСТОЛОГИЯ, ЭМБРИОЛОГИЯ И ЦИТОЛОГИЯ АНАТОМИЯ ФИЗИОЛОГИЯ ФАРМАКОЛОГИЯ МОЛЕКУЛЯРНАЯ ФАРМАКОЛОГИЯ КЛИНИЧЕСКАЯ...»

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ им. М.В.ЛОМОНОСОВА ФАКУЛЬТЕТ ВЫЧИСЛИТЕЛЬНОЙ МАТЕМАТИКИ И КИБЕРНЕТИКИ А.М. ДЕНИСОВ, А.В. РАЗГУЛИН ОБЫКНОВЕННЫЕ ДИФФЕРЕНЦИАЛЬНЫЕ УРАВНЕНИЯ Часть 2 МОСКВА 2009 г. Пособие отражает содержание второй части лекционного курса Обыкновенные дифференциальные уравнения, читаемого студентам факультета вычислительной математики и кибернетики МГУ им. М.В. Ломоносова в соответствии с программой по специальности Прикладная математика и информатика. c Факультет...»

«Информатика. 11 класс. Вариант ИНФ10101 2 Инструкция по выполнению работы Тренировочная работа № 1 На выполнение работы по информатике и ИКТ отводится 235 минут. Работа состоит из 3 частей, содержащих 32 задания. Рекомендуем не более по ИНФОРМАТИКЕ 1,5 часов (90 минут) отвести на выполнение заданий частей 1 и 2, а остальное время – на часть 3. 8 октября 2013 года Часть 1 содержит 13 заданий (А1–А13). К каждому заданию даётся четыре варианта ответа, из которых только один правильный 11 класс...»

«М И Р программирования р. ХАГГАРТИ Дискретная математика для программистов Перевод с английского под редакцией С. А. Кулешова с дополнением А. А. Ковалева Допущено УМО вузов РФ по образованию в области прикладной математики в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки Прикладная математика ТЕХНОСФЕРА Москва 2003 p. Хаггарти Дискретная математика для программистов Москва: Техносфера, 2003. - 320с. ISBN 5-94836-016-4 Элементарное...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФГБОУ ВПО Кемеровский государственный университет Новокузнецкий институт (филиал) Факультет информационных технологий РАБОЧАЯ ПРОГРАММА ДИСЦИПЛИНЫ ОПД.Ф.3 Базы данных для специальности 080801.65 Прикладная информатика в экономике Новокузнецк 2013 1 Сведения о разработке и утверждении рабочей программы дисциплины Рабочая программа дисциплины по выбору студента ОПД.Ф.3 Базы данных федерального компонента цикла ОПД составлена в соответствии с...»

«Министерство сельского хозяйства Российской Федерации С-27 Светлов Н.М. Практикум по теории систем и системному анализу ФГОУ ВПО РГАУ–МСХА имени К.А. Тимирязева для студентов бакалавриата по направлениям Прикладная информатика в Кафедра экономической кибернетики экономике и Математические методы в экономике / Издательство ФГОУ ВПО РГАУ–МСХА имени К.А. Тимирязева. М., 2009. – 75 c. Рецензенты: профессор Е.В. Худякова (МГАУ имени В.П. Горячкина); профессор А.А. Землянский (РГАУ-МСХА имени К.А....»

«Издание четвертое – пересмотренное и дополненное Книга выходит далеко за рамки описания личного кризиса Френца. Она описывает гораздо более серьезный кризис, с которым столкнулись Свидетели Иеговы во всем мире. (Christianity Today) Откровенное и необыкновенно информативное описание структуры власти и внутренней жизни религиозной организации Свидетелей Иеговы. Эта книга — проницательное изложение, подтверждающее ценность „свободы совести“ и предлагающее по-новому взглянуть на классическую...»

«До И ин ст ссл те ф иж ед ме ле ор е ова ж ко ма ни ни ду мм ти я е на у за в с ро ни ци фе дн ка и ре ой ци и бе й в зо ко па н сн тек ос с т ти е 33 asdf Организация Объединенных Наций РАЗОРУЖЕНИЕ Управление по вопросам разоружения Доклад Группы правительственных экспертов по достижениям в сфере информатизации и телекоммуникаций в контексте международной безопасности asdf Организация Объединенных Наций Нью-Йорк, 2012 год Руководство для пользователей Настоящее издание, имеющееся на всех...»

«РОССИЙСКАЯ ФЕДЕРАЦИЯ МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ УТВЕРЖДАЮ: Первый проректор по учебной работе _ /Л. М. Волосникова/ _ 2013 г. МАТЕМАТИЧЕСКОЕ МОДЕЛИРОВАНИЕ ЭКОНОМИЧЕСКИХ ПРОЦЕССОВ И СИСТЕМ Учебно-методический комплекс. Рабочая программа для студентов направления 230700.68 Прикладная информатика магистерская программа Прикладная информатика в экономике...»

«Серия ЕстЕствЕнныЕ науки № 1 (5) Издается с 2008 года Выходит 2 раза в год Москва 2010 Scientific Journal natural ScienceS № 1 (5) Published since 2008 Appears Twice a Year Moscow 2010 редакционный совет: Рябов В.В. ректор МГПУ, доктор исторических наук, профессор Председатель Атанасян С.Л. проректор по учебной работе МГПУ, кандидат физико-математических наук, профессор Геворкян Е.Н. проректор по научной работе МГПУ, доктор экономических наук, профессор Русецкая М.Н. проректор по инновационной...»

«Научные исследования подавателей факультета I математики и информатики 70-летию университета посвящается УДК 517.977 Е.А. Наумович ОСНОВНЫЕ РЕЗУЛЬТАТЫ ДЕЯТЕЛЬНОСТИ КАФЕДРЫ ДИФФЕРЕНЦИАЛЬНЫХ УРАВНЕНИЙ И ОПТИМАЛЬНОГО УПРАВЛЕНИЯ (1979-2009 гг.) В статье приводятся краткие сведения из истории создания и развития кафедры дифференциальных уравнений и оптимального управления. Сформулированы основные научные направления и наиболее важные результаты, полученные сотрудниками кафедры. Приведена информации...»

«УДК 37 ББК 74 М57 Автор: Витторио Мидоро (Институт образовательных технологий Национального исследовательского совета, Италия) Консультант: Нил Батчер (эксперт ЮНЕСКО, ЮАР) Научный редактор: Александр Хорошилов (ИИТО ЮНЕСКО) Руководство по адаптации Рамочных рекомендаций ЮНЕСКО по структуре ИКТ-компетентности М57 учителей (методологический подход к локализации UNESCO ICT-CFT). –М.: ИИЦ Статистика России– 2013. – 72 с. ISBN 978-5-4269-0043-1 Предлагаемое Руководство содержит описание...»

«Тесты по темам программы предмета Прикладная информатика Тема Основные устройства ПК. Их назначение Вопросы, соответствующие низкому уровню 1. Что из перечисленного не является носителем информации? а) Книга б) Географическая карта в) Дискета с играми г) Звуковая плата 2. Какое имя соответствует жесткому диску? а) А: б) B: в) С: г) Я: 3. Что необходимо делать в перерывах при работе за ЭВМ? а) Почитать книгу б) Посмотреть телевидение в) Гимнастику для глаз 4. Какое устройство оказывает вредное...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Амурский государственный университет Кафедра общей математики и информатики УЧЕБНО-МЕТОДИЧЕСКИЙ КОМПЛЕКС ДИСЦИПЛИНЫ МАТЕМАТИКА Основной образовательной программы по направлению подготовки 080500.62 – Менеджмент 2012 г. УМКД разработан старшим преподавателем кафедры ОМиИ Гришкиной Татьяной Евгеньевной Рассмотрен на заседании кафедры ОМиИ...»

«Правительство Российской Федерации Федеральное государственное автономное образовательное учреждение высшего профессионального образования Национальный исследовательский университет Высшая школа экономики Факультет бизнес-информатики Программа дисциплины Математический анализ для направления 080500.62 Бизнес-информатика подготовки бакалавра Авторы программы: А.П. Иванов, к.ф.-м.н., ординарный профессор, IvanovAP@hse.perm.ru Е.Г. Плотникова, д.п.н., профессор, PlotnikovaEG@hse.perm.ru А.В....»

«Бiологiчний вiсник 64 УДК 631.618:633.2.031 А. В. Жуков, Г. А. Задорожная, Е. В. Андрусевич ОПТИМАЛЬНАЯ СТРАТЕГИЯ ОТБОРА ПОЧВЕННЫХ ОБРАЗЦОВ НА ОСНОВАНИИ ДАННЫХ ОБ ЭЛЕКТРИЧЕСКОЙ ПРОВОДИМОСТИ ТЕХНОЗЕМОВ Днепропетровский государственный аграрный университет Показана возможность оценки пространственной изменчивости эдафических свойств техноземов методом кригинга по 20 точкам, положение которых установлено по алгоритму spatial response surface sampling (SRSS) на основании данных электропроводности...»

«Министерство образования и науки РФ Новокузнецкий институт (филиал) федерального государственного бюджетного образовательного учреждения высшего профессионального образования Кемеровский государственный университет Факультет информационных технологий Кафедра математики и математического моделирования УТВЕРЖДАЮ Декан факультета информационных технологий Каледин В.О. _ _20_ г. Рабочая программа дисциплины (модуля) Б2.Б.5 Физика (Наименование дисциплины (модуля) Направление подготовки 010400....»

«Международный консорциум Электронный университет Московский государственный университет экономики, статистики и информатики Евразийский открытый институт С.А. Орехов В.А. Селезнев Теория корпоративного управления Учебно-методический комплекс (издание 4-е, переработанное и дополненное) Москва 2008 1 УДК 65 ББК 65.290-2 О 654 Орехов С.А., Селезнев В.А. ТЕОРИЯ КОРПОРАТИВНОГО УПРАВЛЕНИЯ: Учебно-методический комплекс. – М.: Изд. центр ЕАОИ, 2008. – 216 с. ISBN 978-5-374-00139-6 © Орехов С.А., 2008 ©...»

«ПРАВИТЕЛЬСТВО МОСКВЫ КОМИТЕТ ПО АРХИТЕКТУРЕ И ГРАДОСТРОИТЕЛЬСТВУ УКАЗАНИЕ от 20 февраля 1998 г. N 7 ОБ УТВЕРЖДЕНИИ ПОСОБИЯ К МГСН 2.02-97 ПРОЕКТИРОВАНИЕ ПРОТИВОРАДОНОВОЙ ЗАЩИТЫ ЖИЛЫХ И ОБЩЕСТВЕННЫХ ЗДАНИЙ 1. Утвердить и ввести в действие для использования проектными организациями, осуществляющими проектирование жилых и общественных зданий для строительства в г. Москве и лесопарковом защитном поясе, разработанное НИИ строительной физики РААСН по заказу Москомархитектуры пособие к МГСН 2.02-97...»





Загрузка...



 
© 2014 www.kniga.seluk.ru - «Бесплатная электронная библиотека - Книги, пособия, учебники, издания, публикации»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.