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

ФИО студента

Название работы

Руководитель

Факультет

Программа

Год защиты

В данной работе описывается проектирование и разработка информационной системы, которая позволяет осуществлять сбор статистических данных количества поисковых запросов пользователей в поисковых системах с 2004 года по дату проведения анализа; автоматически структурировать полученные данные; производить анализ статистики и вычислять прогнозируемый показатель количества поисковых запросов на следующий месяц посредством статистических методов, в том числе временных рядов, а также с помощью нейросетевых технологий.Целью работы является проектирование и разработка аналитической информационной системы, которая обеспечит возможность прогнозирования конкретных пользовательских поисковых запросов.Задачи исследования включают в себя:- анализ специальной литературы, сбор, систематизация и обобщение; инструктивных и нормативных материалов, анализ предметной области;- анализ методологий сбора и анализа данных;- анализ информационных технологий для разработки системы;- разработка информационно-аналитической системы;- тестирование и отладка разработанной информационной системы.Объектом исследования являются поисковые запросы пользователей.Предметом исследования являются средства анализа и прогнозирование изменений количества поисковых запросов в сети Интернет.В выпускную квалификационную работу входит введение, 3 главы, заключение и 3 приложения.Во введении кратко описывается актуальность выпускной квалификационной работы, описываются цели и задачи информационной системы, а также описываются основные целевые группы пользователей, для которых предназначена разрабатываемая информационная система.В первой главе проводится обзор предметной области, анализ ключевых понятий, анализ бизнес-процессов, а также анализ существующих решений. Выделяются основные необходимые пользовательские функции разрабатываемой информационной системы, определяются рамки информационной системы, а также производится обоснование адекватности использования методов прогнозирования для поставленных задач.Во второй главе описывается обоснование выбора инструментов разработки информационной системы, описывается процесс разработки и тестирования информационной системы прогнозирования поисковых запросов. Описывается процесс проектирования и создания базы данных, экранных форм и логики работы информационной системы.В третей главе проводится экономическое обоснование, обоснование эффективности использования разработанной информационной системы для целевых групп – пользователей разработанной информационной системы.Заключение посвящено описанию результатов, полученных при выполнении выпускной квалификационной работы, а именно соответствие заявленных целей и задач результатам, краткое описание выводов и оценок относительно прогностических возможностей разработанной информационной системы.Работа предназначена для всех, кто интересуется методами прогнозирования, отслеживанием изменений количества тех или иных поисковых запросов в сети Интернет.

Выпускные квалификационные работы (ВКР) в НИУ ВШЭ выполняют все студенты в соответствии с университетским и Правилами, определенными каждой образовательной программой.

Аннотации всех ВКР в обязательном порядке публикуются в свободном доступе на корпоративном портале НИУ ВШЭ.

Полный текст ВКР размещается в свободном доступе на портале НИУ ВШЭ только при наличии согласия студента – автора (правообладателя) работы либо, в случае выполнения работы коллективом студентов, при наличии согласия всех соавторов (правообладателей) работы. ВКР после размещения на портале НИУ ВШЭ приобретает статус электронной публикации.

В случае использования ВКР, в том числе путем цитирования, указание имени автора и источника заимствования обязательно.

Предлагается следующее содержание идеальной ВКР по

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

• 1. Аннотация по ГОСТ 7-86-2004.
• 2. Введение. Предметная область.
• 2.1. Описание предметной области.
• 2.2. Примененные методы исследования и системного анализа предметной области.
• 2.3. Критерий качества предметной области, на основании которого производится поиск существующей проблемы.
• 2.4. Результат исследования и анализа: обнаруженная проблема, решением которой является ВКР.
• 2.5. Актуальность и практическая значимость решения обнаруженной проблемы.
• 2.6. Существующие средства решения проблемы, готовые средства, системы или программные продукты. Краткая характеристика современного состояния разрабатываемого вопроса в России и за рубежом.
• 2.7. Обоснование непригодности существующих средств и необходимости создания (или существенной корректировки, доработки, дополнения существующей) информационной системы (ИС).
• 2.8. Экономическая, экологическая, социальная или другая оценка целесообразности создания ИС для решения проблемы.
• 3. Информационная система.
• 3.1. Цели, стоящие перед создаваемой ИС.
• 3.2. Задачи, которые надо решить для достижения целей.
• 3.3. Определение требований к ИС и выбор метода определения требований: управляемая пользователем разработка, контролируемая пользователем разработка, независимая от пользователя разработка.
• 3.4. Разработка спецификации качества ИС. Можно использовать примитивы качества:
• 3.4.1. Завершенность (completeness).
• 3.4.2. Точность (accuracy).
• 3.4.3. Автономность (self-containedness).
• 3.4.4. Устойчивость (robustness).
• 3.4.5. Защищенность (defensiveness).
• 3.4.6. Документированность (documentation).
• 3.4.7. Информативность (accountability).
• 3.4.8. Коммуникабельность (communicativeness).
• 3.4.9. Временная эффективность (time efficiency).
• 3.4.10. Эффективность по ресурсам (resource efficiency).
• 3.4.11. Эффективность по устройствам (device efficiency).
• 3.4.12. Понятность (understandability).
• 3.4.13. Структурированность (structuredness).
• 3.4.14. Удобочитаемость (readability).
• 3.4.15. Расширяемость (augmentability).
• 3.4.16. Модифицируемость (modifiability).
• 3.4.17. Модульность (modularity).
• 3.4.18. Независимость от устройств (device independence).
• 3.4.19. Другие примитивы качества.
• 4. Функциональное моделирование предметной области.
• 4.1. Выбор типа функциональной модели предметной области (SADT, DFD, IDEF3) на каждом уровне.
• 4.2. Выбор средства функционального моделирования предметной области.
• 4.3. Создание модели AS IS.
• 4.4. Анализ модели, обнаружение недостатков.
• 4.5. Оптимизация и реинжиниринг функциональной модели предметной области. Применение методов математического моделирования или теории принятия решений для оптимизации предметной области.
• 4.6. Создание модели ТО BE (результат оптимизации).
• 4.7. Анализ последствий реинжиниринга.
• 4.8. Выбор процессов, подлежащих автоматизации.
• 4.9. Анализ внешних связей модели, т.е. входящих и исходящих потоков данных и событий.
• 5. Составление функциональной спецификации ИС.
• 5.1. Описание внешней информационной среды, к которой должны применяться программы разрабатываемой ИС.
• 5.2. Формулирование функций ИС, определенных на множестве состояний конкретной информационной среды (внешних функций ИС).
• 5.3. Описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ИС, и реакций на эти ситуации, которые должны обеспечить соответствующие программы.
• 6. Информационное моделирование предметной области.
• 6.1. Выбор средства создания информационной модели.
• 6.2. Информационная модель предметной области (ERD).
• 6.3. Нормализация данных в ERD. Рациональная денормализация.
• 6.4. Проектирование индексов.
• 7. Проектирование ИС.
• 7.1. Выбор архитектуры программных средств (ПС) ИС.
• 7.1.1. Выбор и обоснование основного архитектурного подхода.
• 7.1.1.1. Цельная программа;
• 7.1.1.2. Комплекс автономно выполняемых программ;
• 7.1.1.3. Слоистая (многоуровневая) программная система;
• 7.1.1.4. Коллектив параллельно выполняемых программ.
• 7.1.2. Выбор серверной архитектуры: файл-сервер, SQL, терминальный сервер и т.п.
• 7.1.3. Выбор клиентской архитектуры: монолитное ПС, клиент- серверное (двухзвенное) ПС, трехзвенное ПС (клиент - сервер приложений - сервер баз данных) и т.п.
• 7.1.4. Выбор архитектуры ИС с позиции разделения на автоматизированные рабочие места (АРМ), на которых реализуются функции ИС.
• 7.2. Выбор архитектуры технических средств ИС (средства связи и телекоммуникации, архитектура hardware и т.п.). Расчеты пропускной способности вычислительной сети, времени отклика и т.п.
• 7.3. Выбор ОС для всех частей ПС ИС.
• 7.4. Выбор модели жизненного цикла ПС (водопадный подход, исследовательское программирование, прототипирование, спиральный подход или другая модель).
• 7.5. Обоснование и выбор системы управления базами данных (СУБД).
• 7.6. Выбор ПС для реализации частей ПС (клиентской части, серверной части, «тонкого» или «толстого» клиента, WEB- интерфейса и т.п.).
• 7.7. Выбор и обоснование выбора применяемых технологий программирования в рамках выбранных программных средств реализации ИС.
• 7.8. Разделение ПС на части (модули).
• 7.9. Эргономический анализ создаваемых частей ПС.
• 7.10. Разработка ПС или модулей. Внимание следует уделять (и отражать в записке) следующим моментам:
• 7.10.1. Особенности и тонкости реализации ПС.
• 7.10.2. Указания по компиляции.
• 7.10.3. Указания по размещению файлов.
• 7.10.4. Выбор и использование средств создания объектов и т.п.
• 8. Выбор технологии реализации ИС и методов управления разработкой.
• 9. Разработка рекомендаций по выбору аппаратной части ИС.
• 10. Разработка мероприятий по обеспечению надежности ИС (резервирование, зеркалирование, архивирование и т.п.).
• 11. Разработка мероприятий по защите информации при работе ИС.
• 11.1. Административные меры.
• 11.2. Программные средства.
• 11.3. Аппаратные средства.
• 12. Разработка средств связи ИС с внешними хранилищами данных или информационными источниками (потоками).
• 13. Тестирование ИС.
• 14. Инсталляция ИС на территории заказчика. Порядок действий, описание настроек ИС и окружения.
• 15. Рекомендации к внедрению ИС.
• 15.1. Действия по подготовке заказчика к внедрению.
• 15.2. Порядок внедрения конкретных АРМ ИС и компонентов ИС.
• 15.3. Порядок и программа обучения пользователей АРМ ИС.
• 15.4. Описание работы ИС параллельно с существующими ИС.
• 16. Разработка документации к ИС.
• 16.1. Определение возможности и перспективности совмещения некоторых функций пользователя, администратора и программиста ИС.
• 16.2. Порядок действий пользователя при осуществлении функций ИС (руководство пользователя).
• 16.3. Порядок и периодичность действий администратора при обслуживании СУБД, проверке целостности таблиц, адекватности индексов, сохранности данных, настройке компонентов ИС, оптимизации окружения для улучшения работы ИС и т.п. Перечень возможных сбоев и действий по их устранению (руководство администратора).
• 16.4. Действия при модернизации ИС, например, при разработке дополнительных экранных и печатных форм (руководство разработчика).
• 16.5. Перечень возможных вопросов и проблем пользователей и ответов (разъяснений) или действий администратора (Frequency Asked Questions).
• 17. Возможности дальнейшей доработки или развития ИС.
• 18. Выводы, заключение (включая научную новизну, актуальность, практическую ценность и личный вклад разработчика).
• 19. Список использованных источников по ГОСТ 7-1-2003.
• 20. Приложения. В приложения следует включать вспомогательные материалы, чтобы они не загружали текст пояснительной записки. Это могут быть промежуточные математические выкладки и расчеты, протоколы испытаний, описание приборов и вычислительных средств, программные документы, распечатки текстов программ, экранные формы разработанных программ и др.

Приведенный перечень является существенно расширенным по

сравнению с объемом типичной ВКР. Предполагается, что в соответствии с особенностями конкретной создаваемой ИС студент выберет из

него только те позиции, которые подходят к его задаче.

Введение

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

1 Понятие «Электронный журнал»

2 Обзор современных программных средств для решения задачи ведения электронного журнала

Постановка задачи

1 Назначение, цели создания информационной системы

2 Требования к информационной системе

Функционально-ориентированное проектирование информационной системы

1 Основные элементы модели

2 Построение контекстной диаграммы

3 Построение диаграмм декомпозиции IDEF0

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

1 Информационный анализ предметной области и выделение информационных объектов

2 Построение логической модели данных

Проектирование реляционной базы данных

1 Описание реляционной модели

2. Описание таблиц базы данных

3 Выбор СУБД

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

1 Технология «клиент-сервер»

2 Средства программирования разрабатываемого приложения

3 Программная реализация модуля «Преподаватель»

4 Программная реализация модуля «Руководитель группы»

5 Программная реализация модуля «Администратор заведения»

6 Программная реализация модуля «Родитель»

7 Программная реализация модуля «Технический администратор системы»

Технико-экономическое обоснование проекта

1 Цель работы

2 Определение состава работ

3 Определение трудоемкости разработки

4 Расчёт сметной стоимости модуля

5 Оценка качества системы учета нагрузки преподавателей

Заключение

Список использованных источников

Приложение А. Итоги рубежного контроля

Приложение Б. Журнал учебных занятий

Приложение В. Ведомость учета посещаемости

Приложение Г.Установление функциональных зависимостей

Приложение Д. Экономическая часть

ВВЕДЕНИЕ

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

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

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

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

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

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

Целью данной работы является построение модели информационной системы «Электронный журнал» и разработка web-приложения для автоматизации процесса ведения журнала успеваемости и посещаемости.

Основными задачами проекта являются:

Разработка функциональной модели системы;

Разработка логической модели системы;

Разработка физической модели системы;

Разработка базы данных;

Разработка приложения для работы с БД.

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

.1 Понятие «Электронный журнал»

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

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

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

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

.2 Обзор современных программных средств для решения задачи ведения электронного журнала

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

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

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

Наиболее удачные реализации системы «Электронный журнал» в России являются:

·www.antcol.ru/jur - Журнал успеваемости студентов Международного Колледжа Туризма (рис. 1.2.1).

Рис. 1.2.1 - Журнал успеваемости студентов Международного Колледжа Туризма

·www.emsy.org - Независимый онлайн-cервис электронных журналов успеваемости, ориентированный на образовательные учреждения стран СНГ - школы, дошкольные учреждения, лицеи, колледжи, техникумы, институты, центры сертификации и другие. Основная функция сервиса - организация и ведение журналов оценок в сети Интернет (рис. 1.2.2).

·www.dnevnik.ru - Всероссийская бесплатная школьная образовательная сеть (рис. 1.2.3).

Рис. 1.2.2 - Независимый онлайн-cервис электронных журналов www.emsy.org

Рис. 1.2.3 - Всероссийская бесплатная школьная образовательная сеть www.dnevnik.ru

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

2. Постановка задачи

.1 Назначение, цели создания информационной системы

Разрабатываемая информационная система должна вести автоматизированный учет успеваемости и посещаемости студентов.

Информационная система «Электронный журнал» предназначена для комплексного информационно-аналитического обеспечения процессов учебного заведения, в части исполнения следующих функций:

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

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

ввод и редактирование списка студентов, списка групп и списка специальностей;

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

вывод успеваемости по заданным параметрам;

вывод посещаемости.

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

Основными целями создания информационной системы являются:

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

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

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

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

.2 Требования к информационной системе

Ключевыми требованиями к создаваемой системе являются:

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

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

Кроссплатформенность, способность работать на различных устройствах, операционных системах, серверах;

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

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

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

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

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

Студент закреплен за одной из групп, а группа, в свою очередь, закреплена за одной из специальностей;

Каждая дисциплина закреплена за одной из групп, а также за одним из преподавателей;

Код студента является уникальным и неизменным;

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

3. Функционально-ориентированное проектирование информационной системы

.1 Основные элементы модели

В таблице 3.1.1 приведены основные элементы модели информационной системы.

Таблица 3.1.1

Основные элементы модели предметной области

Название проекта:Проектирование информационной системы для ведения учета успеваемости и посещаемости студентовЦель проекта:Подготовить рабочую модель бизнес процесса ведения учета успеваемости и посещаемости студентовТехнология моделирования:Метод функционального моделирования IDEF0.Инструментарий:Программный продукт BPWin 4.0Список данных:Список специальностей; Список групп; Список дисциплин; Список студентов; Успеваемость; Посещаемость.Перечень функций:А0. Ведение электронного журнала успеваемости и посещаемости А1. Ввод и редактирование данных А1.1. Ввод специальностей А1.2. Ввод групп А1.3. Ввод дисциплин А1.4. Ввод студентов А1.5. Ввод успеваемости А1.6. Ввод посещаемости А2. Обработка запроса пользователя А2.1. Выбор параметров запроса А2.2. Обработка запроса

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

Таблица 3.1.2

Описание функциональных блоков

Наименование блокаОписание решаемых задачА1. Ввод и редактирование данныхДанный блок включает в себя все этапы ввода и редактирования данныхА2. Обработка запроса пользователяДанный блок содержит все этапы обработки запроса пользователя

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

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

Контекстная диаграмма A-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения, приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Формулировка цели выражает причину создания модели, т.е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. Наиболее важные свойства объекта обычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнего уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая подфункция, в свою очередь, декомпозируется на элементы следующего уровня, и так происходит до тех пор, пока не будет получена релевантная структура, позволяющая ответить на вопросы, сформулированные в цели моделирования. Каждая подфункция моделируется отдельным блоком. Каждый родительский блок подробно описывается дочерней диаграммой на более низком уровне. Все дочерние диаграммы должны быть в пределах области контекстной диаграммы верхнего уровня.

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

Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют некоторую информацию и именуются существительными. Различают 4 вида стрелок:

Входные. Они ставятся с левой стороны и описывают материал или информацию, которая преобразуется в данной работе;

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

Управление - правила, процедуры или стандарты, нормативные акты, на основе которых должна осуществляться данная работа (также должна присутствовать хотя бы одна стрелка);

Ресурсы или механизмы (материальные, трудовые, финансовые ресурсы).

На рис. 3.2.1 представлена контекстная диаграмма «Ведение электронного журнала и посещаемости».

Рис. 3.2.1 - Контекстная диаграмма «Ведение электронного журнала успеваемости и посещаемости»

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

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

Диаграммы декомпозиции содержат схожие работы, т.е. дочерние работы, имеющие единую родительскую работу. При разработке диаграммы декомпозиции надлежит указать нотацию новой диаграммы и численность работ на ней. Возможный перерыв количества работ - 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с численностью работ больше 8 получаются сверх насыщенными и некорректно читаются. Для обеспечения наглядности и лучшего осмысливания имитируемых процессов рекомендовано применять от 3-х до 6 блоков на одной диаграмме. Если как оказалось, что количество работ недостаточно, то работу разрешено добавить в диаграмму, щелкнув поначалу по кнопочке на палитре инструментов, а потом по свободному месту на диаграмме.

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

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

Рис. 3.3.1 - Декомпозиция первого уровня для процесса «Ведение электронного журнала успеваемости и посещаемости»

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

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

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

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

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

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

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

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов;

Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей.

Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

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

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

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т.д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т.е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле.

4. Проектирование информационного обеспечения системы

.1 Информационный анализ предметной области и выделение информационных объектов

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

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

Формы данных документов предметной области рассмотрены в приложениях (см. приложения А, Б, В).

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

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

Информацию, полученную в ходе выполнения данного шага, представим в виде следующей таблицы (см. приложение Г).

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

Для анализа реквизитов составим таблицу (табл. 4.1.1).

Таблица 4.1.1

Определение типов реквизитов

ДокументОписательный реквизитКлючевой реквизитВид ключаИмя информационного объектаСписок студентовname_student n_group passwordn_zbookП, УСтудентыСписок преподавателейname_teacher login passwordn_teacherП, УПреподавателиСписок специальностейname_speciality term_study abbreviationn_specialityП, УСпециальностиСписок группn_spciality name_group n_teachern_groupП, УГруппыСписок дисциплинn_group name_discipline n_teacher sem_start sem_endn_disciplineП, УДисциплиныРубежная успеваемостьmarkn_zbook n_discipline monС, УУспеваемостьСеместровая успеваемостьmarkn_zbook n_discipline n_semС, УУспеваемостьРубежная посещаемостьno_reazon totaln_zbook monС, УПосещаемостьСеместровая посещаемостьno_reazon totaln_zbook n_semС, УПосещаемость

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

Для анализа реквизитов составим таблицу (табл. 4.1.2).

Таблица 4.1.2

Описание информационных объектов

Реквизиты ИОПризнак ключаИмя ИОСемантикаn_zbook name_student n_group passwordП, УСтудентыСведения о студентахn_teacher name_teacher login passwordП, УПреподавателиСведения о преподавателяхn_speciality name_speciality term_study abbreviationП, УСпециальностиСведения о специальностяхn_group n_spciality name_group n_teacherП, УГруппыСведения о группахn_discipline n_group name_discipline n_teacher sem_start sem_endП, УДисциплиныСведения о дисциплинахn_zbook, n_discipline, mon, markС, УУспеваемостьСведения о рубежной успеваемости студентовn_zbook, n_discipline, n_sem markС, УУспеваемостьСведения о семестровой успеваемости студентовn_zbook, mon no_reazon, totalС, УПосещаемостьСведения о рубежной посещаемости студентовn_zbook, n_sem no_reazon, totalС, УПосещаемостьСведения о семестровой посещаемости студентовИнформационные объекты должны отвечать всем требованиям нормализации:

Информационный объект должен содержать уникальный идентификатор;

Все остальные описательные реквизиты должны быть взаимно независимы;

Все реквизиты, входящие в составной ключ должны быть взаимно независимы;

Каждый описательный реквизит должен функционально-полно зависеть от ключа информационного объекта;

При составном ключе описательные реквизиты должны полностью зависеть от реквизитов составляющих ключ;

Каждый описательный реквизит не может зависеть от ключа транзитивно.

Согласно требованиям нормализации между информационными объектами допускаются связи 1:1 и 1:М. Определим тип связи между информационными объектами (табл. 4.1.3).

Таблица 4.1.3

Определение типов связей

Номер связи отношенияГлавный ИОПодчиненный ИОТип отношения1СпециальностиГруппы1:М2ГруппыСтуденты1:М3ПреподавателиГруппы1:14ПреподавателиДисциплины1:М

При составлении информационно-логической модели информационные объекты должны быть упорядочены по уровням (рис. 4.1.1).

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

Рис. 4.1.1 - Уровни информационных объектов

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

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

4.2 Построение логической модели данных

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

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

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

Рис. 4.2.1 - Информационно-логическая модель «Электронный журнал успеваемости»

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

Все связи в полученной информационно-логической модели предметной области «Электронный журнал» характеризуются отношением типа 1:М.

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

5. Проектирование реляционной базы данных

.1 Описание реляционной модели

В основе реляционных систем лежит реляционная модель данных. Принципы реляционной модели были заложены в 1969-1970 гг. американским ученым Е.Ф. Коддом (E.F. Codd), в то время работавшим в корпорации IBM. Будучи математиком по образованию, он привнес в область управления базами данных строгие математические принципы и точность, которых не хватало ранним системам. Хотя реляционный подход утвердился не сразу, можно отметить, что почти все созданные с конца 70-х гг. продукты баз данных основаны именно на реляционном подходе. Подавляющее большинство научных исследований в области баз данных в течение последних 35 лет также проводилось именно в этом направлении.

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

·структуры данных,

·операции, которые можно выполнять над данными, и

·ограничения, связанные с обеспечением целостности данных.

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

.2 Описание таблиц базы данных

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

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

Таблица 5.2.1

Таблица «Список студентов»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаIdАвтоматическое полеПервичный (Primary)Числовой (Long Integer)8name_studentФИО студентТекстовый (Text)250n_groupНомер группыЧисловой (Long Integer)8passwordПарольТекстовый (Text)32

Таблица 5.2.2

Таблица «Список преподавателей»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_teacherНомер преподавателяПервичный (Primary)Числовой (Long Integer)8name_teacherФИО преподавателяТекстовый (Text)250loginИмя пользователяТекстовый (Text)10passwordПарольТекстовый (Text)32Таблица 5.2.3

Таблица «Список специальностей»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_specialityНомер специальностиПервичный (Primary)Числовой (Long Integer)8name_specialityНазвание специальностиТекстовый (Text)250term_studyВремя обученияЧисловой (Long Integer)8abbreviationАббревиатураЧисловой (Long Integer)10

Таблица 5.2.4

Таблица «Список групп»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_groupНомер группыПервичный (Primary)Числовой (Long Integer)8n_spcialityНомер специальностиЧисловой (Long Integer)8name_groupНазвание группыТекстовый (Text)250n_teacherКлассный руководительЧисловой (Long Integer)8

Таблица 5.2.5

Таблица «Список дисциплин»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_disciplineНомер дисциплиныПервичный (Primary)Числовой (Long Integer)8n_groupНомер группыЧисловой (Long Integer)8name_disciplineНазвание дисциплиныТекстовый (Text)250n_teacherНомер преподавателяЧисловой (Long Integer)8sem_startСеместр начала обуч.Числовой (Long Integer)2sem_endСеместр конца обуч.Числовой (Long Integer)2

Таблица 5.2.6

Таблица «Рубежная успеваемость»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_zbookНомер зачетной книжкиЧисловой (Long Integer)8n_disciplineНомер дисциплиныЧисловой (Long Integer)8monМесяцЧисловой (Long Integer)2markОценкаЧисловой (Long Integer)1

Таблица 5.2.7

Таблица «Семестровая успеваемость»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_zbookНомер зачетной книжкиЧисловой (Long Integer)8n_disciplineНомер дисциплиныЧисловой (Long Integer)8n_semСеместрЧисловой (Long Integer)2markОценкаЧисловой (Long Integer)1

Таблица 5.2.8

Таблица «Рубежная посещаемость»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_zbookНомер зачетной книжкиЧисловой (Long Integer)8monМесяцЧисловой (Long Integer)2no_reazonБез ув. причиныЧисловой (Long Integer)5totalВсегоЧисловой (Long Integer)5

Таблица 5.2.9

Таблица «Семестровая посещаемость»

АтрибутПризнак ключаФормат поляИмяНазваниеТипДлинаn_zbookНомер зачетной книжкиЧисловой (Long Integer)8n_semСеместрЧисловой (Long Integer)2no_reazonБез ув. причиныЧисловой (Long Integer)5totalВсегоЧисловой (Long Integer)5

.3 Выбор СУБД

Для принятия решения о выборе СУБД можно проанализировать наиболее популярные: Postgre, MySQL и MSSQL Server. Эти системы будут анализироваться по ряду признаков. На основе анализа результатов будет решен вопрос о приоритетности каждой конкретной СУБД для выбранной предметной области.

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

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

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

В MySQL в отличии от Microsoft SQL Server и Postgre нет триггеров и процедур, это считается недочетом. Из-за этого приходится организовывать все задачи в приложении, не использовать стандартные средства, тем самым усложняется создание приложения.

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

В таблице 5.3.2 приведены достоинства и недостатки СУБД

Таблица 5.3.1

Поддерживаемые операционные системы

СУБДОперационные системыPostgreWindows, Linux, UnixMS SQL ServerWindowsMySQLLinux, Unix, Windows

Таблица 5.3.2

Достоинства и недостатки СУБД

СУБДПлюсыМинусыPostgreВысоко функциональная и бесплатная СУБД с открытым кодом, хорошая поддержка со стороны сообщества разработчиковМестами низкая производительность при обработки больших объёмов информации, малая популярность продуктаMS SQLВысоко функциональная, удобна при использовании среды WindowsПлатная, сложна в администрировании, не кроссплатформеннаяMySQLБесплатная СУБД, имеет открытый код, занимает мало места, лёгкое администрирование mysql с набором всего необходимого функционала, большое сообщество разработчиков, работает на множестве платформнезащищённость от потери данных, поддержка только малых баз данных

Итак, рассмотренные СУБД имеют свои достоинства и недостатки, сопоставив их, было принято решение в пользу выбора MySQL.

база данный учебный электронный журнал

6. Разработка клиент-серверного приложения для работы с базой данных

.1 Технология «клиент-сервер»

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

активная сторона;

пассивная сторона.

Взаимодействие «клиент - сервер» в сети осуществляется в соответствии с определенным протоколом.

В концепции «клиент-сервер» подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом, порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL (Structured Query Language) .

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

Клиент запрашивает данные.

Запрос транслируется в SQL.

SQL-запрос передается по сети на сервер.

Сервер базы данных осуществляет поиск.

Требуемые записи возвращаются клиенту.

Данные предъявляются пользователю.

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

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

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

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

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

.2 Средства программирования разрабатываемого приложения

Для создания приложения основным средством разработки являлся язык программирования python 2.5 , .

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

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

В области программирования для Сети python - один из популярнейших скриптовых языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов.

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

Автоматическое извлечение POST и GET-параметров, а также переменных окружения web-сервера в предопределенные массивы;

Файловые функции успешно обрабатывают как локальные, так и удаленные файлы;

Автоматическая отправка HTTP-заголовков;

Работа с cookies и сессиями;

Обработка файлов, загружаемых на сервер;

Работа с XForms;

Работа с удаленными файлами и сокетами.

В настоящее время python используется разработчиками для высоконагруженных проектов. Согласно рейтингу Tiobe, базирующемся на данных поисковых систем, в декабре 2009 года python находится на 3 месте среди языков программирования (уступая Java и C), поднявшись за год на две позиции.

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

В 1994 году датский программист Расмус Лердорф создал набор скриптов на Perl/CGI для вывода и учёта посетителей его онлайн-резюме, обрабатывающий шаблоны HTML-документов. Лердорф назвал набор Personal Home Page (Личная Домашняя Страница). Вскоре функциональности и быстроты Perl - интерпретатора скриптов - перестало хватать, и Лердорф разработал с использованием языка C новый интерпретатор шаблонов PHP/FI.

.3 Программная реализация модуля «Преподаватель»

Для работы с автоматизированной информационной системой «Электронный журнал» необходимо ввести URL в адресную строку браузера. После загрузки данных в окне браузера появится страница с которой начинается работа в информационной системе - это страница аутентификации пользователя в системе (рис. 6.3.1).

Рис. 6.3.1 - Страница аутентификации пользователя

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

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

Рис. 6.3.2 - Страница выбора отображения информации

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

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

Рис. 6.3.3 - Страница текущей успеваемости студента

Для выставления отметок, необходимо просто выбрать ячейку и поставить туда отметку, либо «Н», если студент отсутствовал на уроке.

.4 Программная реализация модуля «Руководитель группы»

Работа с системой для руководителя группы также начинается со страницы аутентификации (рис. 6.4.1).

Рис. 6.4.1 - Страница аутентификации руководителя

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

Рис. 6.4.2 - Страница составления отчета успеваемости

Рис. 6.4.3 - Страница управления студентами

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

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

На рис. 6.4.5 изображена страница редактирования связей.

Рис. 6.4.5 - Страница редактирования связей

6.5 Программная реализация модуля «Администратор заведения»

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

Рис. 6.5.1 - Страница управления заведением

После выбора нужного пункта меню откроется соответствующая страница.

На рисунке 6.5.2 изображено управление группами учебного заведения

Разработка автоматизированной информационной системы Электронный журнал

Рис. 6.5.2 - Страница управления группами

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

Рис. 6.5.3 - Страница управления преподавателями

Аналогично предыдущему пункту осуществляется управление предметами учебного заведения. (Рис. 6.5.4)

Рис. 6.5.4 - Страница управления преподавателями

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

Рис. 6.5.5 - Страница управления расписанием

6.6 Программная реализация модуля «Родитель»

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

Рис. 6.6.1 - Главная страница модуля «Родитель»

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

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

Рис. 6.6.2 - Просмотр успеваемости ребенка

Рис. 6.6.3 - Просмотр успеваемости ребенка

Так же имеется возможность просмотра расписания на всю неделю. А текущий день выделяется другим цветом. (Рис. 6.6.4)

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

Рис. 6.6.4 - Просмотр успеваемости ребенка

.7 Программная реализация модуля «Технический администратор системы»

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

Данный модуль имеет все те же функции, что и администратор заведения, для управления конкретным учебным заведением, но так же может добавлять и новые. (Рис. 6.7.1)

Рис. 6.7.1 - Управление учебными заведениями и добавление филиалов

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

Рис. 6.7.2- Настройки системы

Рис. 6.7.3 - Управление пользователями и ролями

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

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

Рис. 6.7.4- Отчетность о заполнении системы

7. Технико-экономическое обоснование проекта

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

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

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

.1 Цель работы

Разработка организационно-экономической части ВКР, сбор исходных данных, определение трудоемкости разработки, расчет сметной стоимости, оценка качества разрабатываемой системы.

.2 Определение состава работ

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

Подготовительный этап;

Проектирование;

Программирование;

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

Составление документации;

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

.3 Определение трудоемкости разработки

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

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

На решение поставленной задачи заданы ограничения следующие ограничения:

Время выполнение поставленной задачи - 4 мес.

Число человек, работающих над проектом - 2 чел.

Расчет трудоемкости разработки производится по формуле (7.1).

где ti - трудоемкость работ по стадиям проектирования,- количество стадий проектирования.

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

(7.2)

Затраты времени на каждую стадию разработки проекта представлены в таблице 7.1.

Таблица 7.1

Затраты времени по стадиям разработки проекта

Стадия разработкиtmin, чел. Дниtmax, чел. дниОжидаемые затраты времени, чел. дниПодготовительный этап3108Проектирование153028Программирование305032Этап отладки и тестирования5108Составление документации101511Итого:6311578

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

Таблица 7.2

Распределение объемов работы

Этапы разработкиТрудоемкость чел-дн.ИсполнителиДоля участия, %Фонд времени, дн.Подготовительный8Руководитель202Программист806Проектирование28Руководитель5014Программист5014Программирование32Программист10032Этап отладки и тестирования8Руководитель202Программист806Составление документации11Руководитель253Программист758Итого:87Таким образом, суммарный объем всех выполняемых работ составляет 87 чел. дн.

7.4 Расчёт сметной стоимости модуля

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

Определение затрат на материалы

Затраты на материалы определяются на основе расчета их потребления в процессе разработки. Транспортно-заготовительные расходы принимаются на уровне 10% от цены на материалы. Расчеты затрат на материалы приведены в таблице 7.3.

Таблица 7.3

Расчет затрат на материалы

МатериалыЕд. измеренияКол-воЦена, руб.Стоимость, руб.1. Бумага A4Пачка11701702. Авторучкашт.115153. Краска для принтерашт.1350350Итого:535

Расчет заработной платы

Затраты на основную заработную плату персонала определяются исходя из продолжительности их работы, а также ставок оплаты труда (7.3).

ЗП = (7.3)

Где Д р.мес. - среднее количество рабочих дней в месяце = 22;

Т рi - трудоемкость выполняемых работ;

Зп - среднемесячная заработная плата.

Для руководителя:

ЗП = = 9090,81 руб.;

Для программиста:

ЗП = = 18272,73 руб.

Затраты на доплаты, надбавки, премии составляют 80 % от заработной платы (7.4).

ЗПнадб = 0,8 ЗП (7.4)

Для руководителя:

ЗПнадб = = 7272,73 руб.;

Для программиста:

ЗПнадб = = 14618,18руб.

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

ЗПосн = (ЗП + ЗПнадб) 1,15 (7.5)

Результаты расчета представлены в таблице 7.4.

Таблица 7.4

Расчет основной заработной платы

Категория персоналаКоличество, чел.Трудоемкость, чел/днейОклад, руб.Величина ЗПосн, руб.Руководитель проекта1201000016363,64Программист167600032890,91Итого:28749254,55

Расчет отчислений на социальные нужды

Отчисления на социальные нужды составляют 30,2% от общего фонда заработной платы (12.6). Из них:

% - в пенсионный фонд;

1% - на медицинское страхование;

9% - на социальное страхование;

2% - на страховку от несчастного случая.

Зсоц=0,302 ЗПосн (7.6)

Зсоц = 0,302 49254,55 = 14874,87 руб.

Расчет капитальных вложений

Для производства любого программного продукта необходимы аппаратные и инструментальные средства. В качестве аппаратных средств возьмем 1 рабочую станцию и 1 принтер. Разработка системы производится с использованием инструментов веб разработчика: дистрибутив Apache XAMPP, программа NotePad++, программа Composer, браузер Google Chrome.

Расчет капитальных вложений Кв в оборудование и программное обеспечение производится по формуле (7.7).

Кв = Ка + Кпо (7.7)

Где Ка - стоимость аппаратных средств;

Кпо - стоимость программного обеспечения.

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

Таблица 7.5

Капитальные вложения

КоличествоЦена за ед., рубСтоимость, руб.Аппаратные средства:Рабочая станция (ноутбук)1 шт.1800018000Принтер1 шт.25002500Ка = 24000Программное обеспечение:Дистрибутив Apache XAMPP000Программа NotePad++000Программа Composer000Браузер Google Chrome000Кпо = 0Итого:20500

Все используемое программное обеспечение является бесплатным поэтому

Кв = Ка = 20500 руб.

Затраты на амортизацию

Размер амортизационных отчислений оборудования и программного обеспечения определяется по формуле (7.8).

За = (7.8)

где КВ - стоимость аппаратных и программных средств,

tр - время работы (87 дней),

Tр - число дней в году (365 день),

На - норма отчислений на амортизацию.

По вычислительной технике и оргтехнике годовая норма амортизации установлена в размере 12%, таким образом, сумма амортизационных отчислений за год составит:

За = = 586,36 руб.

Расчет затрат на накладные расходы

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

Зн = 0,3 ЗПосн (7.9)

Зн = 0,3 49254,55 = 14776,36 руб.

Расчет затрат на прочие расходы

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

Затраты на прочие расходы составляют 3% от суммы всех предыдущих расходов (12.10).

Зпроч = 0,03 (Зм + ЗПосн + Зсоц + За + Зн) (7.10)

Зпроч = 0,03(535 + 49254,55+ 14874,87 + 586,36 + 14776,36) =

1954,57 руб.

8. Сметная калькуляция затрат

Сметная калькуляция затрат представляет собой плановую себестоимость производства программного изделия и составляется на всем объеме работ. Сметная калькуляция затрат на рассматриваемый проект представлена в таблице 7.6.

Таблица 7.6

Сметная калькуляция затрат на создание ПО учет ресурсов на предприятии

Статья затратВсего затрат на проект, руб.Материалы535Заработная плата49254,55Отчисления на социальные нужды14874,87Расходы на амортизацию586,36Накладные расходы14776,36Прочие расходы1954,57Всего81981,71

Таким образом, сметная стоимость продукта составит 81981,71 руб.

7.5 Оценка качества системы учета нагрузки преподавателей

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

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

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

В качестве метода оценки был применен метод начисления баллов по каждой характеристике, после чего по среднему баллу можно было судить о качестве разрабатываемого программного продукта. Для определения уровня ранжирования воспользовались 10-балльной системой. Всё это определяет ГОСТ Р ИСО/МЭК 9126-93 "Информационная технология. Оценка программного продукта. Характеристики качества и руководство по их применению".

Данная веб система как программное обеспечение может быть оценено следующими характеристиками:

Функциональные возможности

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

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

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

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

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

Способность к взаимодействию - атрибут ПО, относящийся к способности его взаимодействовать с конкретными системами. Способность к взаимодействию - 5 баллов.

Надежность

Оценим надежность программы с помощью следующих критериев.

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

Устойчивость к ошибке - атрибут программного обеспечения, относящийся к его способности поддерживать определенный уровень качества функционирования в случаях программных ошибок или нарушения определенного интерфейса. В программе предусмотрен контроль вводимой информации. Оценка устойчивости к ошибке - 6.

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

Практичность

Оценим практичность программы с помощью следующих критериев.

Понятность - атрибут программного обеспечения, относящийся к усилиям пользователя по пониманию общей логической концепции и ее применяемости. Оценка понятности - 10 баллов.

Обучаемость - атрибут программного обеспечения, относящийся к усилиям пользователя по обучению его применению.. Обучаемость - 8 баллов.

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

Эффективность

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

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

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

Сопровождаемость

Оценим сопровождаемость программы с помощью следующих критериев.

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

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

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

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

Мобильность

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

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

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

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

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

Результаты экспертной оценки занесены в таблице 7.7.

Таблица 7.7

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

АтрибутБаллПригодность10Правильность10Согласованность10Защищенность9Способность к взаимодействию8Стабильность7Устойчивость к ошибке5Восстанавливаемость10Понятность10Обучаемость8Простота в использовании10Характер изменения во времени9Характер изменения ресурсов9Изменяемость7Устойчивость8Анализируемость9Тестируемость10Адаптируемость9Простота внедрения10Взаимозаменяемость8Соответствие10Средний балл8,9

ЗАКЛЮЧЕНИЕ

В дипломном проекте нами построена модель информационной системы «Электронный журнал» и разработано web-приложение для автоматизации процесса ведения журнала успеваемости и посещаемости.

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

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

База данных реализована в СУБД MySQL. Для разработки программного обеспечения использован язык программирования Python и Web framework Django.

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

Разработанная информационная система находится на опытной эксплуатации в учебной части НОУ СПО Вологодский институт бизнеса.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Котеров Д.В. Python 5 В Подлиннике - 2-е изд. / Д.В. Котеров, А. Ф. Костарев. - СПб.: БХВ-Петербург, 2011. - 1104 с.

2. Гагарина Л.Г. Разработка и эксплуатация автоматизированных информационных систем / Л.Г. Гагарина, Д.В. Киселев, Е.Л. Федотова; Ред. Л.Г. Гагарина. - М. : ФОРУМ: ИНФРА-М, 2013. - 384 с.

3. Веллинг Л. Разработка Web-приложений с помощью PHP и MySQL - 3-е изд. / Л. Веллинг, Л. Томсон; под ред. Ю.Н. Артеменко; пер. с англ. - М.: Издательский дом «Вильямс», 2010. - 880 с.

4. Компания МySQL AB. MySQL. Справочник по языку / под редакцией Ю.Н. Артеменко; пер. с англ. - М.: Издательский дом «Вильямс», 2005. - 432 с.

5. Емельянова Н.З. Основы построения автоматизированных информационных систем: учеб. пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: ФОРУМ: ИНФРА-М, 2005. - 416 с.

6. Диго С.М. Базы данных: проектирование и использование / С.. Диго. - М.: Финансы и статистика, 2005. - 592 с.

.Голицына О.Л. Основы алгоритмизации и программирования/О.Л. Голицына, И.И. Попов. - М.: ФОРУМ: ИНФРА-М, 2005. - 432 с.

.Гвоздева В.А. Введение в специальность программиста / В.А. Гвоздева. - М.: ФОРУМ: ИНФРА-М, 2005. - 208 с.

9. Шлосснейгл Д. Профессиональное программирование на Python/ Д. Шлосснейгл; пер. с англ. - М.: Издательский дом «Вильямс», 2009 - 624 с.

10. Таненбаум Э.М. ван Стеен. Распределенные системы. Принципы и парадигмы / Э.М. ван Стен. Таненбаум; пер. с англ. - М.: Издательский дом «Питер», 2013. - 877 с.

11. Попова О.Г. Методические указания по выполнению дипломного проекта для студентов очного отделения специальности 230103 «Автоматизированные системы обработки информации и управления» / О.Г. Попова, А.А. Дроздова. - Вологда: ВКТ, 2008. - 28 с.

12. Скакун К.К. Методические указания к выполнению экономической части дипломного проекта для студентов по специальности 230103-51 «Автоматизированные системы обработки информации и управления» / К.К. Скакун. - Вологда: НОУ СПО ВКТ, 2007 - 36 с.

13. ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств/ Введ. 01.07.2000

14. ГОСТ 19.102-77 Единая система программной документации. Стадии разработки.

15. ГОСТ 19.105-78 Единая система программной документации. Общие требования к программным документам.

ПРИЛОЖЕНИЕ А

Итоги рубежного контроля

ПРИЛОЖЕНИЕ Б

Журнал учебных занятий

ПРИЛОЖЕНИЕ В

Ведомость учета посещаемости

ПРИЛОЖЕНИЕ Г

Установление функциональных зависимостей

ДокументНаименование реквизитаИмя реквизитаФункциональная зависимостьСписок студентовНомер зач. книжки ФИО студента Номер группы Парольn_zbook name_student n_group passwordСписок преподавателейНомер преподавателя ФИО преподавателя Имя пользователя Парольn_teacher name_teacher login passwordСписок специальностейНомер специальности Назв. специальности Время обучения Аббревиатураn_speciality name_speciality term_study abbreviationСписок группНомер группы Номер специальности Название группы Классный руководительn_group n_spciality name_group n_teacherСписок дисциплинНомер дисциплины Номер группы Название дисциплины Номер преподавателя Семестр начала обуч. Семестр конца обуч.n_discipline n_group name_discipline n_teacher sem_start sem_endРубежная успеваемостьНомер зач. книжки Номер дисциплины Месяц Оценкаn_zbook n_discipline mon markСеместровая успеваемостьНомер зач. книжки Номер дисциплины Семестр Оценкаn_zbook n_discipline n_sem markРубежная посещаемостьНомер зач. книжки Месяц Без ув. причины Всегоn_zbook mon no_reazon totalПРИЛОЖЕНИЕ Д

Экономическая часть

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и наук Российской Федерации

Кафедра информационных технологий и автоматизированных систем Электротехнического факультета

Направление: 230100.62

Зав. Кафедрой: д.э.н., проф.

Файзрахманов Р.А.

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

На соискание академической степени бакалавра

Студент ___________________________ (Пешков К.А.)

Состав ВКР:

1. Пояснительная записка на 107 стр.;

2. Графический материал на 12 листах;

3. Электронный носитель с материалами ВКР.

Руководитель ВКР: ________________________ (Подгорных П.А.)

Консультант: _______________________________ (Чепелева И.М.)

Нормоконтролер: ____________________________ (Елисеева Е.Н.)

Пермь - 2012

Министерство образования и науки Российской Федерации

Пермский национальный исследовательский политехнический университет

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

Электротехнического факультета

«УТВЕРЖДАЮ»

Зав. кафедрой (Р.А. Файзрахманов)

«____»___________2010г.

на выполнение выпускной работы бакалавра

Фамилия, И.О. Пешков Кирилл Александрович

Факультет ЭТФ Группа АСУзу-08-2

Начало выполнения работы 25.12.2011

Контрольные сроки просмотра работы кафедрой 10 .01.2012 , 20.01.2012, 2 4 .01.2012

Сроки представления на рецензию 2 4 .01.2012

Защита работы на заседании ГЭК 2 6 .01.2012

1. Наименование темы «Разработка автоматизированной системы упр авления кадрами на предприятии»

2. Исходные данные к работе. Документы строгой отчетности отдела кадров компании ООО «ИВЦ»

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

б) специальная часть: составление модели, реализация модели

Перечень графического материала: функциональная модель, модель БД, реализация системы

Основная литература Маклаков С.В. Erwin и BPwin . CASE - средства разработки информационных систем, Вендров А.М. CASE технологии. Современные методы и средства проектирования информационных систем

Руководитель выпускной квалификационной работы бакалавра

старший преподаватель кафедры ИТАС (Подгорных П.А. )

Консультант начальник отдела проектирования (Чепелева И.М. )

Задание получил 25.12.2011 (Пешков К.А. )

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

	Объем этапа в %	Выполнения	Примечание
Анализ исходных данных, выбор схемы и основных параметров
Разработка основной части
Разработка графической части
Оформление пояснительной записки писки
Представление работы на проверку и отзыв руководителя квалификационной работы квалификационной работы
Представление работы заведующему кафедрой
Защита на заседании ГЭК

Руководитель работы (Подгорных П.А. )

«____» 2011 г.

Обозначения и сокращения

Введение

1. Постановка задачи

2. Анализ известных подходов к решению проблемы

2.1. Обзор и выбор стандартов и профилей

3. Описание функциональной модели бизнес-процесса «AS-IS»

3.1. Описание объекта автоматизации и информационных потоков

4. Разработка функциональной модели системы «TO-BE»

4.1. Основные функции системы

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

5. Разработка инфологической модели системы

5.1. Разработка инфологической модели данных

5.2. Разработка даталогической модели данных

6. Описание архитектуры системы

6.1. Подсистема хранения данных

6.2. Подсистема обмена данными

6.3. Подсистема приложения

Заключение

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

РЕФЕРАТ

Отчет 91 страница, 3 рисунка, 1 таблица, 8 источников, 12 приложений

ОТДЕЛ КАДРОВ, УЧЁТ КАДРОВ, ДОКУМЕНТОБОРОТ, ВХОДНЫЕ ДОКУМЕНТЫ, ВЫХОДНЫЕ ДОКУМЕНТЫ, АВТОМАТИЗИРОВАННАЯ СИСТЕМА

Объектом исследования является документооборот отдела кадров предприятия ООО «ИВЦ».

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

В процессе работы проводились экспериментальные исследования отдельных составляющих документооборота отдела кадров.

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

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

ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ

	Автоматизированная система
	Автоматизированная система управления
	База данных
	Выпускная квалификационная работа
	Высшее учебное заведение
	Государственный стандарт
	Единая тарифная сетка
	Жизненный цикл
	Информационная система
	Информационные технологии и автоматизированные системы
	Научно-исследовательская работа
	Программное обеспечение
	Программная система
	Система управления базами данных
	Техническое задание
	Электронная вычислительная машина
CASE (Computer Aided Software/ System Engineering)	Автоматизированная разработка программного обеспечения
DFD (Data Flow Diagrams)	Диаграммы потоков данных
ERD (Entity-Relationship Diagrams)	Диаграммы "сущность-связь"
ERP (Enterprise Resource Planning)	Системы управления предприятием
IDEF0 (Icam DEFinition)	Методология функционального моделирования
IDEF1X (Icam DEFinition1 Extended)	Методология построения реляционных структур
IEC (International Electrotechnical Commission)	Международная комиссия по электротехнике
ISO (International Organization for Standardization)	Международная организация по стандартизации
ODBC (Open Date Base Connect)	Открытые технологии для связи с БД
RAD (Rapid Application Development)	Методология быстрой разработки приложений
SADT (Structured Analysis and Design Technique)	Методология структурного Анализа
SQL (Structured Query Language)	Структурированный язык запросов

ВВЕДЕНИЕ

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

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

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

· необходимость соответствия нормативным требованиям российского документооборота;

· широкие возможности автоматизированной системы для обеспечения учета и контроля кадров;

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

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

· около 80% своего рабочего времени начальник тратит на работу с информацией.

· порядка 30% рабочего времени сотрудников уходит на создание, поиск, согласование и отправку документов,

· каждый внутренний документ копируется, в среднем, до 20 раз

· существуют также оценки, что на работу с документами приходится тратить до 40% трудовых ресурсов и до 15% корпоративных доходов.

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

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

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

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

Целью данной дипломной работы является Разработка автоматизированной системы управления кадрами на предприятии. В качестве объекта автоматизации выступает документооборот отдела кадров на предприятии ООО «ИВЦ».

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

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

· разработка моделей деятельности “как есть”, анализ недостатков;

· разработка моделей деятельности “как должно быть”;

· разработка информационной модели данных;

· разработка технического задания на разработку информационной системы.

Разрабатываемая информационная система позволит:

· автоматизировать процесс регистрации, учета, обработки документов;

· оптимизировать хранение документов;

· сэкономить ресурсы, расходуемые на подготовку новых документов;

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

· сократить затраты времени руководителей и сотрудников на рутинные операции с документами (создание, поиск, согласование и т.д.)

· исключить несанкционированный доступ к документам;

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

· для моделирования бизнес-процессов будет использован IDEF0;

· для моделирования информационных потоков используется IDEF3;

· информационные модели будут представлены в нотации IDEF1X;

· техническое задание будет оформлен в соответствии с ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»

1. П ОСТАНОВКА ЗАДАЧИ

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

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

Целью данно й дипломной работы является разработка автоматизированной системы управления кадрами на предприятии ООО «ИВЦ» «Учёт кадров».

Система должна обеспечивать решение следующих задач:

1. улучшение исполнительской дисциплины и снижение влияния личных качеств персонала на выполнение процессов обработки документов;

2. уменьшение времени разработки документов;

3. повышение оперативности обмена информацией между подразделениями.

4. повышение надежности хранения документов, минимизация временных затрат на поиск и анализ необходимых документов.

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

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

· методическое единство, т.е. разработка различных подсистем на основе единых принципов, и обеспечение взаимосвязи различных подсистем, входящих в состав системы (показатели, формы документов);

2. АНАЛИЗ ИЗВЕСТНЫХ ПОДХОДОВ К РЕШЕНИЮ ПРОБЛЕМЫ

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

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

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

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

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

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

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

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

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

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

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

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

понимаемы непрофессионалами. Примерами объектно-ориентированных CASE-средств являются: Rational Rose фирмы Rational Software и Paradigm Plus фирмы Computer Associates, предназначенные для автоматизации этапов анализа и проектирования ПО.

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

развитыми CASE-средствами: Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; ERwin+BPwin; S-Designor; CASE.Аналитик.

ERwin -- современное средство проектирования баз данных. Отличительной чертой ERwin/ERX является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений. ERwin поддерживает все наиболее популярные реляционные СУБД, включая Oracle; Sybase; Informix; Microsoft SQL Server; FoxPro; InterBase; Paradox; Access и др. Одна и та же модель может быть использована для создания нескольких баз данных или для переноса приложения с платформы одной СУБД на другую. ERwin можно использовать совместно со многими популярными средствами разработки приложений: Delphi, PowerBuilder, Visual Basic, Oracle Designer/2000 и др.

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

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

Для моделирования бизнес-процессов Отдела кадров было выбрано CASE-средство BPwin 4.0. Проектирование базы данных создаваемой подсистемы решено производить с помощью CASE-средства ERwin 4.0, поскольку оно достаточно простое в изучении и использовании.

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

2 .1 Обзор и выбор стандартов и профилей

Согласно ГОСТ 34.003 жизненный цикл АС: совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС от формирования исходных требований к ней до окончания эксплуатации и утилизации комплекса средств автоматизации АС. Понятие ЖЦ ПО является одним из базовых в программной инженерии. Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207:1995 «Information Technology - Software Life Cycle Processes». Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО.

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

· ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»;

· ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;

· ГОСТ 34.603-92 «Информационная технология. Виды испытаний автоматизированных систем».

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

ГОСТ 34.602-89 распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа “Техническое задание на создание (развитие или модернизацию) системы” (далее - ТЗ на АС).

Общие положения ГОСТ 34.602-89:

· ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

· ТЗ на АС разрабатывают на систему в целом, предназначенную для работы самостоятельно или в составе другой системы.

· Дополнительно могут быть разработаны ТЗ на части АС: на подсистемы АС, комплексы задач АС и т. п. в соответствии с требованиями настоящего стандарта; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные 1 средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АС.

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

· ТЗ на АС разрабатывают на основании исходных данных в том числе содержащихся в итоговой документации стадии “Исследование и обоснование создания АС”, установленной ГОСТ 24.601.

· В ТЗ на АС включают только те требования, которые дополняют требования к системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в действующих НТД, и определяются спецификой конкретного объекта, для которого создается система.

· Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом. Дополнение или указанный протокол являются неотъемлемой частью ТЗ на АС. На титульном листе ТЗ на АС должна быть запись “Действует с... ”.

ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

1. общие сведения;

2. назначение и цели создания системы;

3. характеристика объектов автоматизации;

4. требования к системе;

5. состав и содержание работ по созданию системы;

6. порядок контроля и приемки системы;

7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

8. требования к документированию;

9. источники разработки. (ГОСТ 34.602-89)

3. ОПИСАНИЕ ФУНКЦИОНАЛЬНОЙ МОДЕЛИ БИЗНЕС-ПРОЦЕССА « AS - IS »

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии, так называемая модель «AS-IS» (как есть) и идеального положения вещей - того, к чему нужно стремиться - модель «TO-BE».

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

· Приказы о приеме на работу

· Приказы о переводе

· Приказы об увольнении

· Служебный контракт

· Трудовой договор

· Сведения о датах назначения надбавок за выслугу лет

· Справка об установленном стаже

· Приказы о предоставлении отпусков

· Сведения в бухгалтерию

· Личная карточка Т2 (Т2ГС)

· Общая справка

· Сведения об изменениях

· Сведения о составе работников

· Штатное расписание

3.1 Описание объекта автоматизации и информационных потоков

Отдел кадров является самостоятельным подразделением компании. Его структура представлена на рисунке 1.

«Рисунок 1 - Структура отдела кадров»

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

· организация отбора, набора и найма персонала, необходимой квалификации и в требуемом объеме;

· создание эффективной системы штатных сотрудников;

· разработка карьерных планов сотрудников;

· разработка кадровых технологий;

· организации труда;

· обучения, продвижения квалификации и переквалификации персонала;

· исследование социально-психологического климата;

· материальное стимулирование и мотивация персонала;

· планирование карьеры и продвижение;

· нормирование труда, оценка резервов и аттестаций;

· охрана и безопасность труда.

Входные/выходные документы

Исходными документами в деятельности отдела кадров (в рамках объекта автоматизации) являются:

· Трудовая книжка;

· Заявление работников об увольнении по собственной инициативе;

· График отпусков;

· Табель учета рабочего времени и расчета оплаты труда;

· Журнал учета мероприятий по контролю;

Выходные документы:

· Приказы о приеме на работу;

· Приказы о переводе;

· Приказы об увольнении;

· Служебный контракт;

· Трудовой договор;

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

· Справка об установленном стаже;

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

· Сведения в бухгалтерию;

· Личная карточка Т2 (Т2ГС);

· Общая справка;

· Реестр;

· Сведения об изменениях;

· Сведения о составе работников;

· Штатное расписание;

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

Функциональная модель «AS-IS контекстная диаграмма A-0» представлена в [Приложении А]. Она включает в себя всю деятельность отдела в области учета кадров. Модель представлена в виде черного ящика. Детализация диаграммы «A0» представлена в [Приложении Б].

Функции модели «AS-IS»

Функция A1

Название:

Алгоритм: Ввод данных о сотрудниках в систему;

Входные данные:

Выходные данные: Приказы о приеме на работу, Приказы о переводе, Приказы об увольнении, Служебный контракт, Трудовой договор;

Управление:

Механизм: Специалисты по подбору персонала;

Функция A2

Название: Управление трудовым процессом;

Алгоритм: Организация контроля и выполнение отчётности;

Входные данные: График отпусков, Табель учета рабочего времени и расчета оплаты труда, Приказы о приеме на работу;

Выходные данные: Сведения о датах назначения надбавок за выслугу лет, Справка об установленном стаже, Приказы о предоставлении отпусков, Сведения в бухгалтерию;

Управление:

Механизм: Специалисты по оценке персонала;

Функция A3

Название: Делопроизводство;

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

Входные данные: Книга учета движения трудовых книжек и вкладышей к ним, Журнал учета мероприятий по контролю, Проект штатного расписания;

Выходные данные: Личная карточка Т2 (Т2ГС), Общая справка, Реестр, Сведения об изменениях, Сведения о составе работников, Штатное расписание;

Управление: Должностные инструкции;

Механизм: Специалисты по делопроизводству;

При изучении модели «AS-IS» были выявлены следующие недостатки:

· бессистемное хранение документации;

· отсутствие справочников;

· долгий поиск карточки сотрудника в бумажном архиве;

Найденные в модели «AS-IS» недостатки можно исправить при создании модели TO-BE (как должно быть). Эта модель интегрирует перспективные предложения руководства и сотрудников предприятия, экспертов и системных аналитиков и позволяет сформировать видение новых рациональных технологий работы компании.

4. РАЗРАБОТКА ФУНКЦИОНАЛЬНОЙ МОДЕЛИ СИСТЕМЫ « TO - BE »

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

Функциональная модель «TO-BE контекстная диаграмма A-0» представлена в [Приложении В]. Она включает в себя всю деятельность отдела в области учета кадров. Модель представлена в виде черного ящика. Детализация диаграммы «A0» представлена в [Приложении Г].

Функции модели « TO - BE »

Функция A1

Название: Организация приёма/увольнения сотрудников;

Алгоритм: Ввод данных о сотрудниках в электронную карточку;

Входные данные: Трудовая книжка, Заявление работника об увольнении по собственной инициативе;

Выходные данные: Приказы о приеме на работу, Приказы о переводе, Приказы об увольнении, Служебный контракт, Трудовой договор, Электронная карточка сотрудника;

Управление: Трудовой кодекс РФ, Должностные инструкции, Положение об оплате труда работников, Политика компании;

Механизм: Специалисты по подбору персонала, Информационная система;

Функция A2

Название: Управление системой;

Алгоритм: Организация контроля и работа с карточками сотрудников. Выполнение процедур по подержанию кадровой информации в актуальном состоянии;

Входные данные: График отпусков, Табель учета рабочего времени и расчета оплаты труда, Журнал учета мероприятий по контролю, Электронная карточка сотрудника;

Выходные данные: Список сотрудников;

Управление: Должностные инструкции, Политика компании, Правила внутреннего трудового распорядка;

Механизм:

Функция A3

Название: Формирование отчётности;

Алгоритм: Вывод и печать необходимой информации в виде отчётов

Входные данные: Список сотрудников;

Выходные данные: Сведения о датах назначения надбавок за выслугу лет, Справка об установленном стаже, Приказы о предоставлении отпусков, Сведения в бухгалтерию, Личная карточка Т2 (Т2ГС), Общая справка, Реестр, Сведения об изменениях, Сведения о составе работников, Штатное расписание;

Механизм: Информационная система;

Для более подробной иллюстрации отличий моделей «TO-BE» от «AS-IS» выполним декомпозицию функции «A2» и представим её в [Приложении Д].

Функции модели « TO - BE детализация диаграммы A 2»

Функция A21

Название: Работа с электронной карточкой;

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

Входные данные: График отпусков, Табель учета рабочего времени и расчета оплаты труда, Журнал учета мероприятий по контролю, Электронная карточка сотрудника, Значение стажа сотрудника, Штатное расписание;

Выходные данные:

Управление: Должностные инструкции, Политика компании, Правила внутреннего трудового распорядка;

Механизм: Специалисты по оценке персонала, Специалисты по делопроизводству, Информационная система;

Функция A22

Название: Формирование штатного расписания;

Алгоритм: Формирование производится на основе данных обо всех отделах и сотрудниках компании;

Входные данные: Табель учета рабочего времени и расчета оплаты труда, Персональные данные сотрудников;

Выходные данные: Штатное расписание;

Управление: Правила внутреннего трудового распорядка;

Механизм: Специалисты по делопроизводству, Информационная система;

Функция A23

Название: Автоматический подсчёт стажа;

Алгоритм: Подсчёт ведётся на протяжении всей трудовой деятельности сотрудника в данном предприятии;

Входные данные: Персональные данные сотрудников;

Выходные данные: Значение стажа сотрудника;

Управление: Должностные инструкции;

Механизм: Информационная система;

Функция A24

Название: Фильтрация;

Алгоритм: Формирование списка сотрудников удовлетворяющих указанным атрибутам;

Входные данные: Персональные данные сотрудников;

Выходные данные: Список сотрудников;

Механизм: Информационная система;

4.1 Основные функции системы

· Хранение структурированной информации о сотруднике в виде карточки с необходимыми реквизитами;

· Ведение справочников предприятий, типов должностей, регионов и различных служебных справочников;

· Поиск карточек по атрибутам;

· Фильтрация карточек по реквизитам и тексту (атрибутивная и полнотекстовая);

· Автоматический подсчёт стажа сотрудника;

· Экспорт необходимой информации в другие распространенные программные средства (Microsoft Excel);

· Вывод всевозможных отчетов.

Вкратце принцип работы системы может быть представлен следующим образом:

· Основными информационными объектами системы являются Карточки сотрудников, хранящие структурированную информацию о соответствующем объекте.

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

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

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

В качестве основных направлений при создании системы можно выделить следующие:

· Сближение механизмов работы с бумажными и электронными документами так, чтобы было возможно обеспечить «бесшовный» документооборот на базе удобной, легкой в освоении, быстрой системы с простым и дружественным пользовательским интерфейсом.

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

· Облегчение процесса занесения документов в систему вне зависимости от способа и формы, в котором они поступили в организацию (бумага, факс, электронная почта и др.).

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

· Упрощение управления бизнес-процессами, предназначенных как для обработки документов, так и для задач, не связанных с документами.

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

· Снижение риска потери информации и технологии при уходе ключевых сотрудников.

· В электронном документообороте необходимые документы всегда под рукой: слабая зависимость от персоналий, результативный поиск документов;

· Повышение эффективности управления;

· Рост производительности труда;

· Сотрудники обеспечиваются актуальной информацией;

· Снижение рисков;

· Обеспечение безопасности хранения коммерческой информации.

5. РАЗРАБОТКА ИНФОЛОГИЧЕСКОЙ МОДЕЛИ СИСТЕМЫ

5.1 Разработка инфологической модели данных

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

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

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

· Сотрудник

· Образование

· Дополнительное образование

· Трудовая книжка

· Медицинский полис

· Военный билет

· Награды

· Родственники

· Надбавки

· Пособия

· Назначения перемещения

· Командировки

· Выходные пособия

· Материальная помощь

· Аттестации

· Отпуска

· Больничные листы

· Предприятия

· Виды образования

· Регионы

· Учебные заведения

· Тип должности

· Тип стажа

Связь «Образование» принадлежит

Связь «Доп. образование» принадлежит «Сотрудник» является связью типа M:1;

Связь «Награды» принадлежит «Сотрудник» является связью типа M:1;

Связь «Родственники» принадлежит «Сотрудник» является связью типа M:1;

Связь «Надбавки» принадлежит «Сотрудник» является связью типа M:1;

Связь «Пособия» принадлежит «Сотрудник» является связью типа M:1;

Связь «Назначения перемещения» принадлежит «Сотрудник» является связью типа M:1;

Связь «Командировки» принадлежит «Сотрудник» является связью типа M:1;

Связь «Выходные пособия» принадлежит «Сотрудник» является связью типа M:1;

Связь «Материальная помощь» принадлежит «Сотрудник» является связью типа M:1;

Связь «Аттестации» принадлежит «Сотрудник» является связью типа M:1;

Связь «Отпуска» принадлежит «Сотрудник» является связью типа M:1;

Связь «Больничные листы» принадлежит «Сотрудник» является связью типа M:1;

Связь «Резерв» принадлежит

Связь «Тип должности» принадлежит «Резерв» является связью типа 1:М;

Связь «Трудовая книжка» принадлежит «Сотрудник» является связью типа 1:1;

Связь «Медицинский поли» принадлежит «Сотрудник» является связью типа 1:1;

Связь «Военный билет» принадлежит «Сотрудник» является связью типа 1:1;

Связь «Предприятия» принадлежит

Связь «Виды образования» принадлежит «Сотрудник» является связью типа 1:М;

Связь «Стаж» принадлежит «Сотрудник» является связью типа М:М;

Связь «Тип стажа» принадлежит «Стаж» является связью типа 1:М;

5.2 Разработка даталогической модели данных

Инфологическая модель должна быть отображена в компьютерно-ориентированную - даталогическую модель. Даталогическая модель обеспечивает независимость данных на двух уровнях - логическом и физическом.

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

Логическая модель системы представлена в [Приложении Л] и в [Графическом материале 11].

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

6 . ОПИСАНИЕ АРХИТЕКТУРЫ СИСТЕМЫ

В автоматизированной информационной системе «Учёт кадров» используется трехзвенная архитектура клиент-сервер (рисунок 2).

«Рисунок 2 - Архитектура системы «Учёт кадров»

Автоматизированная информационная система «Учёт кадров» условно разделена на три подсистемы:

1. Подсистема хранения данных.

2. Подсистема обмена данными.

3. Подсистема приложения.

6 .1 Подсистема хранения данных

В роли подсистемы хранения данных выступает СУБД MS SQL. СУБД работает с базой данных, в которой структурировано хранятся все персональные данные сотрудников.

Эту информацию используют при работе все подсистемы, эффективно обмениваясь ею в процессе работы.

6 .2 Подсистема обмена данными

Подсистема обмена данными представляет собой Веб-сервис, который предназначен для обмена информации между клиентскими приложениями (подсистема приложения) и базой данных. Веб-сервис разрабатывается по технологии Windows Communication Foundation, это унифицированная модель программирования распределенных приложений на платформе Microsoft. Она инкорпорирует предшествующие технологии - ASMX,.NET Remoting, DCOM и MSMQ - и предоставляет расширяемый API, отвечающий разнообразным требованиям, которые возникают при создании распределенных систем.

Веб-сервис обменивается данными с клиентскими приложениями по протоколу HTTP, а также поддерживает дуплексный обмен данными (одновременный обмен в обе стороны).

6 .3 Подсистема приложения

Подсистема приложения представляет собой клиентское приложение, которое обменивается данными с веб-сервисом. Клиентское приложение разработано в интегрированной среде разработки Delphi.

Delphi - императивный, структурированный, объектно-ориентированный язык программирования, диалект Object Pascal. Начиная со среды разработки Delphi 7.0, в официальных документах Borland стала использовать название Delphi для обозначения языка Object Pascal. Начиная с 2007 года уже язык Delphi (производный от Object Pascal) начал жить своей самостоятельной жизнью и претерпевал различные изменения связанные с современными тенденциями (например, с развитием платформы.NET) развития языков программирования: появились class helpers, перегрузки операторов и другое.

Описание функций приложения

Пользователь системы работает непосредственно с клиентским приложением. В главном окне приложения [Приложение Е] отображается список всех сотрудников компании, которых можно отсортировать и найти по различным атрибутам. Для того чтобы ввести в систему нового сотрудника необходимо создать «Карточку физического лица» [Приложение Ж] и заполнить её персональными данными сотрудника. Прежде всего, необходимо заполнить поле «Пенс №» т.к. оно является ключевым.

Для того что бы назначить человека на какую либо должность необходимо зайти в карточку «Дополнительные сведения» [Приложение З], в которой заполняются дополнительные атрибуты в том числе «Назначения и перемещения». При добавлении нового назначения открывается окно «Приём на работу и перевод на другую работу» [Приложение И], в котором указывается всё о текущей должности сотрудника. После заполнения всех атрибутов у сотрудника автоматически начинает подсчитываться стаж.

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

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

З АКЛЮЧЕНИЕ

Данная дипломная работа посвящена автоматизации документооборота в рамках работы отдела кадров компании ООО «ИВЦ».

Целью данной дипломной работы является создание проекта «Учёт кадров».

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

· Выполнен анализ информационных потоков;

· Разработаны модели деятельности “как должно быть” с использованием стандарта IDEF0;

· Разработаны информационные модели данных в нотации IDEF1X;

· Разработано техническое задание на информационную систему кафедры на основе ГОСТ 34/602-89, которое приведено в [Приложении M].

С ПИСОК ЛИТЕРАТУРЫ

1. ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;

2. ГОСТ 34.602-89 «Правила оформления технического задания». - URL: http://url5.ru/hej (дата посещения 25.11.2011);

3. Трудовой кодекс Российской федерации. - Редакция 2011-2012

4. Вендров А.М. «Проектирование программного обеспечения экономических информационных систем»: Финансы и Статистика. - 2002;

5. Кибанова А.Я. «Управление персоналом организации»: ИНФРА-М. - 2005;

6. Маклаков С.В. «BPwin и Erwin. CASE-средства разработки информационных систем»: ДИАЛОГ-МИФИ. - 2000;

7. Маклаков С.В. «Моделирование бизнес-процессов с BPwin 4.0»: ДИАЛОГ-МИФИ. - 2002 - 224c.;

8. Квалификационный справочник должностей руководителей, специалистов и служащих: ИНФРА-М. - 2003 - 96с.

Размещено на Allbest.ru

...

Подобные документы

Обоснование необходимости разработки АОС "Информационная безопасность". Построение модели деятельности "Как есть" (AS-IS) и "Как должно быть" (TO-BE). Анализ программных продуктов. Создание модели предметной области. Разработка информационной системы.

отчет по практике , добавлен 31.05.2015


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

курсовая работа , добавлен 20.12.2013


Понятие автоматизированной информационной системы. Построение функционально-ориентированных моделей "как есть" (as-is) и "как должно быть" (to-be). Описание базы данных, разработка приложения, руководство пользователя. Счет-фактура, платежное поручение.

дипломная работа , добавлен 23.04.2013


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

курсовая работа , добавлен 25.12.2014


Изучение существующей технологии почтовых отправлений. Составление модели технологической операции в формате "как есть". Разработка модели автоматизированной технологической операции в формате "как надо" (TO-BE). Разработка технического задания на АРМ.

контрольная работа , добавлен 20.12.2010


Стенограмма интервью с руководителем МБОУ "Центр образования с. Марково". Должностные инструкции, деятельность отдела по работе с клиентами. Построение модели деятельности "как есть" и "как должно быть". Создание автоматизированной информационной системы.

курсовая работа , добавлен 25.04.2013


Построение моделей деятельности "как есть" (AS–IS) и "как должно быть" (TO–BE) для повышения эффективности учета товаров на складе ООО "ТНТ Трейдинг". Формирование технического задания на создание автоматизированной информационной системы для предприятия.

курсовая работа , добавлен 12.04.2012


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

курсовая работа , добавлен 15.07.2012


Комплексное исследование объекта информатизации - ООО "УралПромСнаб". Разработка модели бизнес-процессов AS-IS и анализ "узких" мест. Разработка технического задания на покупку и внедрение готовой автоматизированной системы учета "Галактика ERP 9.1".

курсовая работа , добавлен 12.12.2013


Определение класса защищённости АС. Разработка модели угроз. Выбор механизмов и средств защиты информационных ресурсов от несанкционированного доступа. Создание структуры каталогов для заданного количества пользователей автоматизированной системы.

• Казаков Дмитрий Игоревич , студент
• Рыбанов Александр Александрович , кандидат наук, доцент, заведующий кафедрой
• Волжский политехнический институт (филиал) Волгоградский государственный технический университет

• КОНТРОЛЬ
• ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
• ПОДДЕРЖКА
• МОНИТОРИНГ

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

• Автоматизация процесса оценки выпускных квалификационных работ на основе компетентностного подхода
• Разработка web-ориентированной и мобильного приложения системы учета и анализа взаимодействия ВУЗа с потенциальными абитуриентами
• Оптимизация процесса составления расписания для движения городского общественного транспорта
• Разработка информационной системы учета результатов профориентационной деятельности высших учебных заведений

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

Существующие информационные системы в различных ВУЗах обеспечивают крайне малый процент информационной поддержки процесса выполнения ВКР.

Оптимальным решением в сложившейся ситуации будет создание Web-ориентированной информационной системы (web-ИС), функционал которой будет включать:

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

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

1. Проверка стиля текста;
2. Проверка списка литературы;
3. Проверка на соответствие названия главы ее содержимому.

Целью работы является повышение эффективности процесса контроля и мониторинга выполнения выпускных работ.

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

1. Разработка математического описания web-ИС поддержки процесса выполнения выпускных квалификационных работ;
2. Разработка алгоритмов и программная реализация web-ИС поддержки выполнения выпускных квалификационных работ;
3. Экспериментальная оценка качества программного продукта.

Рассмотрим математическую модель web-ИС. Существует несколько способов определения принадлежности текста к тому или иному стилю. Одним из таковых является Худломер - метод автоматической классификации функционального стиля текста на основе спектров длин слов. Разработчиком Худломера явлется Леонид Делицын. Существует упрощенный алгоритм Худломера - стиль текста определяется на основании средней длины слова. В зависимости от вычисленного параметра текст относится к одному из четырех стилей: разговорная речь (средняя длина слова 4.9), публицистический стиль (средняя длина слова 5.9), газетная статья (средняя длина слова 6.9) и научная статья (средняя длина слова больше 6.9). Отношение к тому или иному стилю определяется наибольшей близостью к одному из четырех стилей. Точность определения стиля такого подхода составляет примерно 70%;

Математическое описание определения соответствия содержимого названию главы заключается в определении ключевых слов из главы и подглав для последующего сопоставления с названием главы. Ключевые слова определяются в зависимости от их встречаемости в тексте, для анализа выбираются первые 24 наиболее встречаемых слова. Процедура сопоставления ключевых слов с названием главы подразумевает определение количества ключевых слов в названии в процентном соотношении. Полученный процентный результат переводится в словесную форму с четырьмя возможными ответами: отличное совпадение (более 80%), хорошее совпадение (65-79 %), удовлетворительное совпадение (50-64 %) и плохое совпадение (менее 50 %). За основу была взята шкала балло-рейтинговая система ВПИ (ф) ВолгГТУ с небольшим смещением;

Математическое описание определения правильности оформления библиографического списка студента заключается в проверке правильности оформления источника согласно ГОСТ Р 7.0.5-2008 "Библиографическая ссылка". Помимо правильности оформлении источника, проверяется год издания, который не должен быть старше 5 лет. Проверка списка использованных источников осуществляется путем поиска совпадений регулярными выражениями. Разработаны регулярные выражения для различных типов источников, таких как печатные источники, статья в журнале, монографии, тезисы докладов, ссылки на электронные ресурсы и другие. Проверка на соответствие года источника осуществляется путем получения года из полученных источников. При правильном оформлении источника и правильности использования года источника, он заносится в базу данных. Для занесения в базу данных используются следующие характеристики источника: авторы, год, название, издательство, страницы.

Теперь поговорим о реализации. Web-ориентированная информационная система «Бакалавр» представляет собой приложение типа клиент-сервер, где клиентом является пользователь, зарегистрированный в системе, взаимодействующий через браузер посредством Интернет соединения, а сервером, в свою очередь, является комплекс программного обеспечения AMP, включающего: Apache, MySQL, php.

Общая структурная схема web-ИС «Бакалавр» представлена на рис. 1.

Рисунок 1. Общая структура.

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

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

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

Модуль проверки библиографического списка разработан для частичной проверки списка использованных источников на корректность оформления и на соответствие годовым меркам использования. На вход подается TeX файл библиографического списка, из файла извлекается текст и проходит проверку регулярными выражениями. Каждое совпадение проверяется на правильность использования годовым меркам источника (источник должен быть не старше пяти лет). Проверка на соответствие года источника осуществляется путем получения года из полученных источников. Источники проверяются по регулярным выражениям, составленным согласно ГОСТ Р 7.0.5-2008 "Библиографическая ссылка". При правильном оформлении источника и правильности использования года источника, он заносится в базу данных. Для занесения в базу данных используются следующие характеристики источника: авторы, год, название, издательство, страницы. На выходе пользователю выводятся все полученные совпадения из регулярных выражений по категориям с указанием количества. Источники старше пяти лет выводятся красным цветом, остальные зеленым.

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

Рисунок 2. Физическая схема базы данных.

Для оценки эффективности реализованной web-ориентированной информационной системы было проведено три эксперимента:

• Оценка эффективности способов хранения текста пояснительной записки;
• Оценка пользовательского интерфейса;
• Экспертное сравнение разработанной программы с программами аналогами.

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

Таблица 1. Результаты эксперимента по оценке способов хранения текста пояснительной записки.

Рисунок 3. Результаты эксперимента по оценке способов хранения текста пояснительной записки.

Оценка пользовательского интерфейса проводилась при помощи инструмента CogTool. Для каждого из пользователей была выбрана задача, которую необходимо проделать для работы с web-ИС «Бакалавр». CogTool может предсказывать время, необходимо на решение задачи. С его помощью спрогнозированы решения поставленных задач для каждого пользователя, зафиксировано время.

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

Таблица 2. Общий результат эксперимента

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

Экспертная оценка программных продуктов позволяет выявить лучший среди сравниваемых, отметить положительные и отрицательные стороны каждого продукта по отношению к выбранным критериям. Для сравнения существующих программных обеспечений были выбраны GS-ведомости, интегрированная система управления высшим учебным заведением (ИСУ ВУЗ), web-ИС «Бакалавр», Университет (Redlab) и Электронный Университет. В качестве критериев для сравнительного анализа программных продуктов были выбраны: контроль и мониторинг выполнения этапов ВКР, генерация отчетов по главам, учет публикаций студента, поддержка выполнения ВКР, контроль тематики ВКР, ведение базы данных бакалаврских работ.

Для определения весов критериев использовалась аналитическая иерархическая процедура Саати. Матрица парных сравнений, средние геометрические и веса критериев представлены в таблице 3.

Диаграмма весовых коэффициентов для критериев представлена на рис. 4.

Таблица 3. Матрица парных сравнений, суммы и веса критериев

								Веса критериев

Рисунок 4. Весовые коэффициенты критериев качества.

Определенные (по введенной шкале) количественные значения функциональных возможностей Xij представлены в таблице 4.

Таблица 4. Интегральные показатели качества.

Критерии	Весовые коэффи-циенты	Программные продукты					Базовые значения
					Универ-ситет	Бакалавр
контроль и мониторинг выполнения этапов ВКР
генерация отчетов по главам
учет публикаций студента
поддержка выполнения ВКР
контроль тематики ВКР
ведение БД бакалаврских работ
Интегральный показатель качества Q

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

Рисунок 5. Лепестковая диаграмма значений функциональных характеристик.

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

Разработанная web-ориентированная информационная система позволила повысить эффективность процесса контроля, мониторинга и поддержки выполнения выпускных квалификационных работ.

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

1. 1С: Университет - https://solutions.1c.ru/catalog/university/features
2. Дрейзис Ю.И., Калинина М.В., Зиновьев П.С. The Comparative Analy-sis of the Market of Information Systems for Automation of Activity of Uni-versity. // European Journal of Computer Science, №1, Vol. (2), 2016, pp. 26-37.
3. Интегрированная система управления ВУЗом URL: http://isu.tisbi.ru/ (дата обращения: 10.12.2017).
4. Рыбанов, А.А. Технология повышения эффективности информацион-ной поддержки, мониторинга и контроля за процессом выполнения вы-пускных квалификационных работ / Рыбанов А.А., Макушкина Л.А., Фа-деева М.В. // Актуальные вопросы профессионального образования. - 2013. - № 10 (т. 10). - C. 122-125.
5. Оруджова, Л.Ш., Рыбанов А.А. Программная реализация web-ориентированной информационной системы контроля и мониторинга вы-полнения выпускной квалификационной работы [Электронный ресурс] : статья / Оруджова Л.Ш., Рыбанов А.А. // Студенческий научный форум 2013: V междунар. студ. электрон. науч. конф., 15 февр. – 31 марта 2013 г. Направл. "Технические науки" / Рос. акад. естествознания. – М., 2013. – С. 1-5. – Режим доступа: http://www.scienceforum.ru/2013/pdf/5243.pdf
6. Морозов М.С., Чернова Г.А.. 2016. Т.2. № 47. С. 26-35.