Разработка информационно-аналитической системы приемной кампании. Модуль учета профориентационных мероприятий
Анализ информационно-аналитической системы приемной кампании. Требования к модулю учета профориентационных мероприятий информационно-аналитической системы приемной кампании. Разработка документации для модуля учета профориентационных мероприятий.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 01.12.2019 |
| Размер файла | 845,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Пермский филиал федерального государственного автономного образовательного учреждение высшего образования «Национальный исследовательский университет «Высшая школа экономики»
Факультет экономики, менеджмента и бизнес-информатики
модуль документация кампания приемный
РАЗРАБОТКА ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЫ ПРИЕМНОЙ КАМПАНИИ. МОДУЛЬ УЧЕТА ПРОФОРИЕНТАЦИОННЫХ МЕРОПРИЯТИЙ
Выпускная квалификационная работа
студента образовательной программы «Программная инженерия»
по направлению подготовки 09.03.04 Программная инженерия
Капгер Галина Игоревна
Пермь, 2019 год
Аннотация
В данной работе описаны этапы разработки модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании.
Работа содержит 37 страниц формата A4 основного текста, включая 3 главы (анализ предметной области информационно-аналитической системы приемной кампании, проектирование информационно-аналитической системы приемной кампании, реализация и тестирование информационно-аналитической системы приемной кампании), и 6 приложений (диаграммы, техническое задание, нормализация отношений, руководство пользователя, руководство программиста и листинг программы).
В основной части содержится 23 таблиц, 13 иллюстраций, включая 5 диаграмм.
В приложениях содержится 13 диаграмм, нормализация отношений (включающая 74 таблицы), техническая документация и листинг программы.
Библиографический список состоит из 11 источников.
Оглавление
Введение
Глава 1. Анализ предметной области информационно-аналитической системы приемной кампании
1.1 Анализ объекта автоматизации
1.2 Анализ систем учета профориентационных мероприятий
1.3 Анализ предыдущей работы
1.4 Требования к модулю учета профориентационных мероприятий информационно-аналитической системы приемной кампании
1.5 Технологии и методы
1.6 Диаграмма прецедентов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
1.7 Техническое задание
Глава 2. Проектирование модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
2.1 Модель поведения модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
2.2 Проектирование базы данных
2.3 Диаграмма классов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
2.4 Проведение технико-экономического обоснования разработки модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
2.5 Проектирование пользовательского интерфейса модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Глава 3. Разработка модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
3.1 Модель реализации модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании30
3.2 Разработка серверной части модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
3.3 Разработка клиентской части модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
3.4 Тестирование модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
3.5 Разработка документации для модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
3.6 Развертывание модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании на учебном сервере
Список сокращений и условных обозначений
Библиографический список
Приложения
Введение
Приемная кампания НИУ ВШЭ - Пермь включает в себя не только прием документов, но и организацию профориентационных мероприятий для привлечения абитуриентов. Поскольку ВУЗ заинтересован в приеме сильных студентов, важно проводить наиболее эффективные мероприятия, для чего необходимо хранить и анализировать информацию за прошлые годы.
Информацию о проведенных мероприятиях тяжело обрабатывать вручную ввиду большого объема. Она включает в себя не только данные о проведении, но и об участниках, организаторах, лекторах, волонтерах, а также информацию об учебных заведениях участников и образовательных программах, которыми они интересуются. Кроме того, эти данные также тяжело собирать, поскольку они могут храниться на разных ресурсах или вовсе быть утерянными. Таким образом, главная проблема заключается в учете данных и принятии решений на их основе.
Разрабатываемая система позволит хранить все данные в одном месте, а также анализировать эффективность проведенных мероприятий, давая возможность принимать решения на основе графиков и отчетов. Следовательно, описанная проблема может быть решена при помощи описанной системы, и данная тема является актуальной.
Разработка системы будет проводиться на примере приемной кампании НИУ ВШЭ - Пермь. Объектом исследования является приемная кампания НИУ ВШЭ - Пермь. Предмет исследования - средства автоматизации учета и анализа профориентационных мероприятий НИУ ВШЭ - Пермь.
Целью работы является разработка модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании.
Для достижения поставленной цели необходимо выполнить следующие задачи:
1. Анализ требований к информационно-аналитической системе приемной кампании.
2. Анализ аналогичных систем.
3. Подготовка технического задания для информационно-аналитической системы приемной кампании.
4. Проектирование информационно-аналитической системы приемной кампании.
5. Проведение технико-экономического обоснования разработки информационно-аналитической системы приемной кампании.
6. Реализация информационно-аналитической системы приемной кампании.
7. Тестирование и отладка информационно-аналитической системы приемной кампании.
8. Развертывание информационно-аналитической системы приемной кампании.
9. Подготовка руководства пользователя и программиста.
Поскольку тема работы узко специализирована, в качестве аналогов будут рассмотрены системы учета и анализа мероприятий в целом: сервис для организации событый «TimePad» [1], а также платформы «123ContactForm» [2], «CrowdCompass» [3] и «EventMobi» [4].
При проведении исследования будут использоваться следующие методы: наблюдение и анализ для описания предметной области, сбор и обработка данных с целью получения дополнительной информации об объекте, сравнение для получения информации о существующих решениях и разработанных системах, моделирование для описания бизнес-процессов.
Глава 1 содержит обзор аналогов, формулировку требований к системе. Здесь представлен анализ существующих систем учета и анализа мероприятий, их области применения. Также в данной главе представлены диаграммы активностей и диаграммы прецедентов, необходимые для разработки системы.
Глава 2 содержит описание процесса проектирования приложения. В данной главе представлены этапы проектирования базы данных, диаграммы классов, диаграммы сотрудничества, технико-экономическое обоснование и этапы проектирования интерфейса.
Глава 3 содержит описание процесса реализации, тестирования и внедрения системы. В данной главе описаны этапы процесса реализации информационно-аналитической системы, представлены этапы тестирования и развертывая на учебном сервере. Также здесь описан процесс подготовки документации: руководства пользователя и программиста.
Глава 1. Анализ предметной области информационно-аналитической системы приемной кампании
Данная глава представляет собой анализ предметной области разрабатываемой системы. Она содержит анализ объекта автоматизации, формулировку требований к системе и обзор аналогов. Также здесь представлен анализ результата курсовой работы за третий курс.
1.1 Анализ объекта автоматизации
В рамках приемной кампании НИУ ВШЭ - Пермь в течение года проводятся мероприятия, нацеленные на привлечение большего числа абитуриентов. Для составления оптимальной кампании на год необходимо иметь понимание, какие мероприятия более эффективны, сколько мероприятий достаточно посетить абитуриенту, чтобы он захотел поступить; и учитывать различные показатели - время года проведения мероприятия, баллы абитуриентов по олимпиадам и другие. Эффективность мероприятия главным образом оценивается соотношением стоимости мероприятия к проценту зачисленных студентов, которые в нем участвовали.
Для принятия решения об эффективности того или иного мероприятия необходимо прежде всего собрать информацию по мероприятиям и абитуриентам за последние годы. Поскольку данные достаточно разрознены, они могут храниться на разных носителях, либо и вовсе быть утерянными. Это не только затрудняет сбор данных, но и может существенно повлиять на оценку эффективности мероприятия. После получения данных необходимо провести их обработку и анализ, просмотрев все полученные файлы (рис. А.1).
Для оповещения абитуриентов о предстоящих мероприятиях используется сайт ВУЗа или электронная почта, регистрация на мероприятия проходит с помощью систем «TimePad» или «Google Формы». При этом отмечать участников, которые реально посетили мероприятие, приходится вручную, поэтому для получения информации о реальных участниках мероприятия, необходимо хранить файлы с записями.
Также необходимо отметить, что при регистрации на любое мероприятие абитуриенту необходимо каждый раз заново указывать основную информацию о себе (рис. А.2).
1.2 Анализ систем учета профориентационных мероприятий
На данном этапе необходимо было провести анализ аналогичных систем. Поскольку тема работы узко специализирована, были рассмотрены системы учета и анализа мероприятий в целом: сервис для организации событий «TimePad», а также платформы «123ContactForm» [2], «CrowdCompass» [3] и «EventMobi» [4].
Основные критерии анализа - возможность составления отчетов о мероприятиях за определенный период, хранение всей необходимой информации об участниках, возможность получения информации о реальных участниках мероприятия, хранение мероприятий в единой базе.
Сервис «TimePad» предоставляет возможность размещать анонсы мероприятий с указанием даты, времени и адреса и получать контактную информацию от участников при регистрации. Анкеты участников настраиваются при создании или изменении события. Статистика по регистрациям доступна в любое время, она включает в себя число участников и информацию о переходах с других сайтов, через почтовые рассылки и прочее. Присутствует возможность отметить реальных участников мероприятия, а также выгружать данные в форматах «.xlsx» и «.csv».
Платформа «123ContactForm» предоставляет возможность создавать формы и анкеты, которые можно использовать, в том числе для регистрации на мероприятия, так как в анкету участников можно включить любые данные. Эффективность мероприятия можно отслеживать через всестороннюю аналитику по участникам и регистрациям. Также есть возможность экспорта данных в форматах «.xlsx» и «.csv».
Платформа «CrowdCompass» позволяет создавать мобильные приложения для различных событий и мероприятий. С помощью шаблонов и конструктора можно хранить любые данные участников. Созданное приложение включает информацию о мероприятии, контактные данные, программу, выступающих, участников и форму обратной связи. Кроме того, платформа позволяет отслеживать и анализировать активность пользователей.
Платформа «EventMobi» предоставляет возможность создавать формы регистрации на мероприятия. Она поддерживает управление несколькими событиями, чтобы участники могли получать доступ к прошедшим, текущим и будущим событиям. Основные функции - создание мероприятия, регистрация, уведомления, опросы и аналитика по регистрациям и посещаемости.
В таблице 1.1 представлен результат проведенного анализа систем учета профориентационных мероприятий.
Таблица 1.1. Результат анализа аналогов
|
Критерии анализа |
TimePad |
123ContactForm |
CrowdCompass |
EventMobi |
|
|
Составление отчетов о мероприятиях за определенный период |
- |
- |
- |
- |
|
|
Хранение всей необходимой информации об участниках |
+ |
+ |
+ |
- |
|
|
Получение информации о реальных участниках мероприятия |
+ |
- |
- |
- |
|
|
Хранение мероприятий в единой базе |
- |
- |
- |
+ |
Таким образом, были проанализированы четыре системы учета профориентационных мероприятий, рассмотрены их возможности. Ни одна система не позволяет составлять отчеты о мероприятиях за определенный период, хотя бы поэтому они уже не подходят для НИУ ВШЭ - Пермь в качестве информационно-аналитической системы приемной кампании, следовательно необходима разработка такой системы.
1.3 Анализ предыдущей работы
В рамках курсовой работы третьего курса была разработана система учета профориентационных мероприятий. Она не предоставляет возможность анализировать эффективность мероприятий и составлять отчеты о мероприятиях за определенный период. Также она имеет ряд недостатков: не был реализован пользовательский интерфейс для участников мероприятий; интерфейс для работников ВУЗа слишком сложен, неудобен, ограничена функциональность при добавлении мероприятий и участников.
Описанные выше недостатки подтверждают необходимость разработки новой системы для учета профориентационных мероприятий НИУ ВШЭ - Пермь
1.4 Требования к модулю учета профориентационных мероприятий информационно-аналитической системы приемной кампании
На данном этапе необходимо формализовать требования к системе.
В системе должны быть реализованы следующие возможности (рис. А.3-А.5):
1. Создание мероприятий.
2. Автоматизация анализа эффективности мероприятий.
3. Упрощенный процесс регистрации на мероприятие с помощью единой учетной записи. Вводить контактные данные и другую информацию необходимо будет только при регистрации в системе. При каждой записи на мероприятие будут использоваться данные аккаунта.
Интерфейс сотрудника ВУЗа должен позволять добавлять, изменять и удалять данные, создавать отчеты и выгружать их в формате «.xlsx».
Интерфейс участника мероприятий должен позволять просматривать информацию о мероприятиях и регистрироваться на них.
Система должна предоставлять возможность хранить следующие данные об абитуриенте:
1. ФИО.
2. Школа (или СПО/НПО) и класс (высчитывается через год предполагаемого окончания).
3. Контактные данные (телефон и email).
Основная информация о школе:
1. Адрес.
2. Тип, номер и полное наименование.
3. Вхождение в Университетский округ (да/нет).
4. Приоритетность школы для НИУ ВШЭ - Пермь (да/нет).
Информация о мероприятии должна содержать:
1. Тип мероприятия (олимпиада, курсы, работа со школами).
2. Даты проведения.
3. Адреса.
4. Организаторов (в том числе подразделения, ответственные за проведение мероприятия), преподавателей, волонтеров.
5. Расходы с указанием закупаемых товаров, предоставляемых услуг.
6. Участников (абитуриентов, учителей, родителей).
Система должна позволять выполнять анализ данных. Для этого необходимо реализовать генерацию следующих отчетов:
1. Зависимость процента зачисленных студентов, которые участвовали в мероприятии, от стоимости мероприятия.
2. Зависимость посещаемости мероприятий от времени года.
3. Зависимость поступления абитуриента от числа мероприятий, в которых он участвовал.
4. Зависимость поступления абитуриента от баллов, которые он набрал по олимпиаде.
5. Число выпускников курсов ЕГЭ и их средние баллы ЕГЭ.
Поскольку регистрация на мероприятие должна быть доступна в любое время, система должна быть реализована с использований web_технологий.
1.5 Технологии и методы
При разработке использованы следующие методы:
1. Извлечение данных - получение структурированных данных из неструктурированных документов.
2. Преобразование данных - подготовка информации к хранению в оптимальной форме для реализации запросов, необходимых для принятия решений.
3. Загрузка данных - помещение данных в хранилище, производится атомарно, путём добавления новых фактов или корректировкой существующих.
4. Анализ данных - сводные отчеты.
5. Представление результатов анализа.
Серверная часть приложения будет реализована на языке C# с использованием ASP.Net Web API, так как он достаточно прост не только для реализации, но и для развертывания на Windows-сервере.
Для реализации клиентской части был выбор между ASP.Net MVC, Angular и React. Сравнение проводилось по следующим критериям:
1. Наличие паттерна MVC.
2. Эффективная работа с памятью.
3. Наличие компонентного подхода - возможности разделения страниц на отдельные компоненты. Это значительно упрощает чтение кода, а также позволяет избежать дублирования.
4. Цельное решение - то есть технология, в которую включены основные функциональные возможности. Такие решения не требуют дополнительного анализа библиотек и их подключения.
ASP.Net MVC - фреймворк для создания веб-приложений, который реализует паттерн MVC. Для изменений состояния на клиентской стороне можно использовать JavaScript, но при любых изменениях DOM будет обновляться все дерево HTML-тегов. Фреймворк включает в себя все возможности для настройки маршрутизации, внедрения зависимостей и пр.
Angular - это JavaScript-фреймворк, основанный на TypeScript. Он поддерживает паттерн MVC, и, так же, как и ASP.Net MVC, является цельным решением. В Angular используется обычный DOM и постоянно обновляется состояние, поэтому работу с памятью нельзя назвать эффективной. Кроме прочего, фрейморк позволяет использовать компонентный подход.
React - это JavaScript-библиотека для создания пользовательских интерфейсов. Она не является цельным решением, поскольку требует настройки необходимых библиотек, принятия решений относительно архитектуры. В React используется виртуальный DOM, который позволяет обновлять требуемую часть страницы, сравнивая различия между предыдущей и текущей версией HTML, это позволяет эффективно использовать память. Так же, как и Angular, React позволяет использовать компонентный подход.
В таблице 1.2 представлен результат сравнения технологий для реализации клиентской части.
Таблица 1.2 Результат сравнения технологий для реализации клиентской части
|
ASP.Net MVC |
Angular |
React |
||
|
Наличие паттерна MVC |
+ |
+ |
- |
|
|
Эффективная работа с памятью |
± |
- |
+ |
|
|
Компонентный подход |
- |
+ |
+ |
|
|
Цельное решение |
+ |
+ |
- |
В итоге для клиентской части был выбран Angular и TypeScript. Стоит отметить, что TypeScript в отличие от JavaScript позволяет использовать объектно-ориентированный подход и более строгую типизацию.
1.6 Диаграмма прецедентов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Требования к системе были формализованы с помощью диаграмм вариантов использования системы с расширенным описанием всех прецедентов. С системой могут взаимодействовать следующие акторы: абитуриент, сотрудник ВУЗа и администратор (рис. А.6). Стоит отметить, что администратор также является сотрудником ВУЗа.
Ниже представлено расширенное описание прецедентов.
Название: «Работа с мероприятиями».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает в меню пункт «Мероприятия». Выполняет работу (добавление или редактирование) над мероприятиями. Список мероприятий обновляется.
Триггер: актор вошел в систему.
Основной поток (табл. 1.3):
Таблица 1.3 Основной поток прецедента «Работа с мероприятиями»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню «Мероприятия». |
2. Система открывает календарь мероприятий. |
|
|
3. Актор производит работу (добавление или редактирование) над мероприятиями. |
4. Система обновляет календарь мероприятий. |
Название: «Добавление мероприятий».
Акторы: сотрудник ВУЗа.
Краткое описание: актор нажимает на кнопку «Добавить», заполняет необходимую информацию, нажимает на кнопку «Сохранить».
Триггер: актор выбрал в меню пункт «Мероприятия».
Основной поток (табл. 1.4):
Таблица 1.4 Основной поток прецедента «Добавление мероприятий»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Добавить». |
2. Система открывает страницу создания мероприятия. |
|
|
3. Актор заполняет необходимую информацию. 4. Актор нажимает на кнопку «Сохранить». Если актор хочет отменить создание мероприятия, выполняется подпоток S1. |
5. Система проверяет, верно ли заполнены все поля (E1). 6. Система сохраняет мероприятие. 7. Система открывает страницу с календарем мероприятий. |
Альтернативные потоки:
E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.
Название: «Импорт мероприятий из MS Excel».
Акторы: сотрудник ВУЗа.
Краткое описание: актор нажимает на кнопку «Импорт», выбирает файл MS Excel, проверяет полученные данные, нажимает на кнопку «Сохранить».
Триггер: актор выбрал в меню пункт «Мероприятия».
Основной поток (табл. 1.5):
Таблица 1.5 Основной поток прецедента «Импорт мероприятий из MS Excel»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Импорт». |
2. Система открывает диалоговое окно для выбора файла MS Excel. |
|
|
3. Актор выбирает файл с локального носителя. |
4. Система проверяет правильность формата данных (E1). 5. Система открывает модальное представление для проверки данных. |
|
|
6. Актор проверяет данные и нажимает на кнопку «Сохранить». Если актор не хочет добавлять мероприятия, то выполняется подпоток S1. |
7. Система сохраняет мероприятия. 8. Система открывает страницу с календарем мероприятий. |
Альтернативные потоки:
E1: Появление предупреждения о неверном формате данных при загрузке документа, если какие-либо данные некорректны или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 8. Прецедент продолжается.
Название: «Редактирование мероприятий».
Акторы: сотрудник ВУЗа.
Краткое описание: актор открывает мероприятие, изменяет необходимую информацию и сохраняет мероприятие.
Триггер: актор выбрал в меню пункт «Мероприятия».
Основной поток (табл. 1.6):
Таблица 1.6 Основной поток прецедента «Редактирование мероприятий»
|
Действия акторов |
Отклик системы |
|
|
1. Актор два раза нажимает на мероприятие. |
2. Система открывает страницу для редактирования мероприятия |
|
|
3. Актор изменяет необходимую информацию. 4. Актор нажимает на кнопку «Сохранить». Если актор хочет отменить изменения, то выполняется подпоток S1. |
5. Система проверяет, верно ли заполнены все поля (E1). 6. Система сохраняет мероприятие. 7. Система открывает страницу с календарем мероприятий. |
Альтернативные потоки:
E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.
Название: «Удаление мероприятий».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает мероприятие и удаляет его.
Триггер: актор выбрал в меню пункт «Мероприятия».
Основной поток (табл. 1.7):
Таблица 1.7 Основной поток прецедента «Удаление мероприятий»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на мероприятие. |
2. Система открывает модальное представление с краткой информацией о мероприятии. |
|
|
3. Актор нажимает на кнопку «Удалить». |
4. Система удаляет мероприятие. 5. Система закрывает модальное представление. |
Название: «Генерация отчетов».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает в меню пункт «Отчеты» и выбирает вид отчета.
Триггер: актор вошел в систему.
Основной поток (табл. 1.8):
Таблица 1.8 Основной поток прецедента «Генерация отчетов»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню пункт «Отчеты». |
2. Система открывает страницу для генерации отчетов. |
|
|
3. Актор выбирает вид отчета. |
4. Система выполняет запрос. 5. Система выводит полученные данные на страницу. |
Название: «Экспорт в MS Excel».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выгружает полученные данные в MS Excel.
Триггер: актор сгенерировал отчет.
Основной поток (табл. 1.9):
Таблица 1.9 Основной поток прецедента «Экспорт в MS Excel»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Экспорт в Excel». |
2. Система создает документ MS Excel, содержащий сгенерированные данные. 3. Система предоставляет документ пользователю. |
Название: «Редактирование справочников».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает пункт меню «Управление». Актор выбирает необходимый справочник, изменяет информацию и сохраняет изменения.
Триггер: актор вошел в систему.
Основной поток (табл. 1.10):
Таблица 1.10 Основной поток прецедента «Редактирование справочников»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню пункт «Управление». |
2. Система открывает список справочников. |
|
|
3. Актор выбирает необходимый справочник. |
4. Система открывает окно для редактирования справочника. |
|
|
5. Актор изменяет необходимую информацию. 6. Актор нажимает на кнопку «Сохранить». Если актор хочет отменить изменения, выполняется подпоток S1. |
7. Система проверяет, верно ли заполнены все поля (E1). 8. Система сохраняет данные. 9. Система открывает страницу со списком справочников. |
Альтернативные потоки:
E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 9. Прецедент продолжается.
Название: «Работа с участниками».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает в меню пункт «Участники». Выполняет работу над участниками. Список участников обновляется.
Триггер: актор вошел в систему.
Основной поток (табл. 1.11):
Таблица 1.11 Основной поток прецедента «Работа с участниками»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню «Участники». |
2. Система открывает список участников (E1). |
|
|
3. Актор производит работу над участниками. |
4. Система обновляет список участников. |
Альтернативные потоки:
E1: Вывод сообщения о том, что по данному запросу не найдено результатов, если участников нет.
Название: «Поиск участников».
Акторы: сотрудник ВУЗа.
Краткое описание: актор вводит ключевые значения в строке поиска и выбирает фильтры в меню слева для получения списка участников.
Триггер: актор выбрал в меню пункт «Участники».
Основной поток (табл. 1.12):
Таблица 1.12 Основной поток прецедента «Поиск участников»
|
Действия акторов |
Отклик системы |
|
|
1. Актор вводит ключевые значения в строке поиска и нажимает на кнопку поиска. Если актор не хочет искать участников по ключу, выполняется подпоток S1. |
2. Система открывает полученный список участников (E1). |
|
|
3. Актор выбирает параметры поиска в меню слева. |
4. Система открывает полученный список участников (E1). |
Альтернативные потоки:
E1: Вывод сообщения о том, что по данному запросу не найдено результатов, если по запросу не найдено ни одного участника.
Подпотоки:
S1: Переход к пункту 3. Прецедент продолжается.
Название: «Редактирование участников».
Акторы: сотрудник ВУЗа.
Краткое описание: актор открывает участника, изменяет необходимую информацию и нажимает на кнопку «Сохранить».
Триггер: актор нашел необходимого участника.
Основной поток (табл. 1.13):
Таблица 1.13 Основной поток прецедента «Редактирование участников»
|
Действия акторов |
Отклик системы |
|
|
1. Актор два раза нажимает на участника. |
2. Система открывает страницу для редактирования участника. |
|
|
3. Актор изменяет необходимую информацию. 4. Актор нажимает на кнопку «Сохранить». Если актор хочет отменить изменения, то выполняется подпоток S1. |
5. Система проверяет, верно ли заполнены все поля (E1). 6. Система сохраняет участника. 7. Система открывает страницу со списком участников. |
Альтернативные потоки:
E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.
Название: «Удаление участников».
Акторы: сотрудник ВУЗа.
Краткое описание: актор выбирает участника и удаляет его.
Триггер: актор нашел необходимого участника.
Основной поток (табл. 1.14):
Таблица 1.14 Основной поток прецедента «Удаление участников»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Удалить». |
2. Система удаляет участника. 3. Система обновляет страницу со списком участников. |
Название: «Регистрация участников на мероприятие».
Акторы: сотрудник ВУЗа.
Краткое описание: актор нажимает кнопку «Зарегистрировать участников», находит необходимого участника, нажимает кнопку «Зарегистрировать».
Триггер: актор нажал на мероприятие.
Основной поток (табл. 1.15):
Таблица 1.15 Основной поток прецедента «Регистрация участников на мероприятие»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Зарегистрировать участников». |
2. Система открывает список участников. |
|
|
3. Актор находит нужного участника. Если такого участника нет в системе, то выполняется подпоток S1. 4. Актор нажимает кнопку «Зарегистрировать». |
5. Система регистрирует участника. |
Подпотоки:
S1: Выполнение прецедента «Добавление участников». Переход к пункту 4. Прецедент продолжается.
Название: «Добавление участников».
Акторы: сотрудник ВУЗа.
Краткое описание: актор нажимает на кнопку «Добавить», заполняет необходимую информацию, нажимает на кнопку «Сохранить».
Триггер: актор выбрал в меню пункт «Участники» или нажал кнопку «Зарегистрировать участников».
Основной поток (табл. 1.16):
Таблица 1.16 Основной поток прецедента «Добавление участников»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Добавить». |
2. Система открывает страницу добавления участника. |
|
|
3. Актор заполняет необходимую информацию. 4. Актор нажимает на кнопку «Сохранить». Если актор хочет отменить добавление участника, то выполняется подпоток S1. |
5. Система проверяет, верно ли заполнены все поля (E1). 6. Система сохраняет участника. 7. Система открывает список участников. |
Альтернативные потоки:
E1: Появление предупреждений у незаполненных или неверно заполненных полей при проверке данных перед сохранением, если какие-либо данные введены некорректно или отсутствуют.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 7. Прецедент продолжается.
Название: «Импорт участников из MS Excel».
Акторы: сотрудник ВУЗа.
Краткое описание: актор нажимает на кнопку «Импорт», выбирает файл MS Excel, проверяет полученные данные, нажимает на кнопку «Сохранить».
Триггер: актор выбрал в меню пункт «Участники».
Основной поток (табл. 1.17):
Таблица 1.17 Основной поток прецедента «Импорт участников из MS Excel»
|
Действия акторов |
Отклик системы |
|
|
1. Актор нажимает на кнопку «Импорт». |
2. Система открывает диалоговое окно для выбора файла MS Excel. |
|
|
3. Актор выбирает файл с локального носителя. |
4. Система проверяет правильность формата данных (E1). 5. Система открывает модальное представление для проверки данных. |
|
|
6. Актор проверяет данные и нажимает на кнопку «Сохранить». Если актор не хочет добавлять участников, то выполняется подпоток S1. |
7. Система сохраняет мероприятия. 8. Система открывает список участников. |
Альтернативные потоки:
E1: Появление предупреждения о неверном формате данных.
Подпотоки:
S1: Актор нажимает на кнопку «Отменить». Переход к пункту 8. Прецедент продолжается.
Название: «Подтверждение роли пользователя».
Акторы: администратор.
Краткое описание: актор выбирает в меню пункт «Пользователи», выбирает нужного пользователя и подтверждает его роль.
Триггер: актор вошел в систему.
Основной поток (табл. 1.18):
Таблица 1.18 Основной поток прецедента «Подтверждение роли пользователя»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню пункт «Пользователи». |
2. Система открывает список пользователей. |
|
|
3. Актор выбирает необходимого пользователя. 4. Актор нажимает на кнопку «Предоставить доступ». |
5. Система подтверждает роль пользователя. 6. Список пользователей обновляется. |
Название: «Регистрация на мероприятие».
Акторы: абитуриент.
Краткое описание: актор выбирает в меню пункт «Мероприятия», выбирает нужное мероприятие и регистрируется.
Триггер: актор вошел в систему.
Основной поток (табл. 1.19):
Таблица 1.19 Основной поток прецедента «Регистрация на мероприятие»
|
Действия акторов |
Отклик системы |
|
|
1. Актор выбирает в меню пункт «Мероприятия». |
2. Система открывает список мероприятий. |
|
|
3. Актор выбирает необходимое мероприятие. 4. Актор нажимает кнопку «Зарегистрироваться». |
5. Система регистрирует актора на мероприятие. |
1.7 Техническое задание
В ходе анализа предметной области было написано техническое задание со всеми необходимыми требованиями к системе. Техническое задание было выполнено в соответствии с требованиями ГОСТ 19.201-78 [6] (прил. B).
Были выявлены требования к программе и программной документации, определены назначение разработки и основание разработки, технико-экономические показатели, стадии и этапы разработки, порядок контроля и приемки, добавлены характеристики области применения программы и наименование программы.
Таким образом, за время анализа предметной области были сформулированы все необходимые требования к разрабатываемой системе, и выявлены основные функции, обязательные для реализации.
Глава 2. Проектирование модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Данная глава представляет собой описание процесса проектирования системы учета мероприятий. Здесь представлены модель поведения системы, описание этапов нормализации отношений базы данных и подробно описанная статическая структура системы. В конце главы содержится описание этапа проектирования интерфейса.
2.1 Модель поведения модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Во время проектирования системы было необходимо построить модель поведения системы, для этого была выбрана нотация диаграмм последовательностей. Все разработанные диаграммы представлены ниже.
Название: «Генерация отчетов» (рис. 2.3).
Обязанности: выбрать пункт меню «Отчеты», выбрать параметры, нажать кнопку «Сгенерировать».
Ссылки: прецедент «Генерация отчетов».
Предусловия: пользователь вошел в систему.
Постусловия: отображение отчета.
Рисунок 2.1 Диаграмма последовательностей «Генерация отчетов»
Название: «Регистрация участников на мероприятие» (рис. 2.2).
Обязанности: выбрать мероприятие, нажать на кнопку «Добавить участников», выбрать участников, нажать на кнопку «Сохранить».
Ссылки: прецедент «Регистрация участников на мероприятие».
Предусловия: пользователь открыл календарь мероприятий.
Постусловия:
1. Добавлена связь между выбранными участниками и мероприятием.
2. Данные сохранены.
Рисунок 2.2 Диаграмма последовательностей «Регистрация участников на мероприятие»
Название: «Добавление мероприятия» (рис. 2.1).
Обязанности: нажать на кнопку «Добавить мероприятие», заполнить информацию, нажать на кнопку «Сохранить».
Ссылки: прецедент «Добавление мероприятий».
Предусловия: пользователь открыл календарь мероприятий.
Постусловия:
1. Создан объект «Мероприятие».
2. Объект добавлен в БД.
Рисунок 2.3 Диаграмма последовательностей «Добавление мероприятия»
2.2 Проектирование базы данных
На данном этапе необходимо было выполнить нормализацию отношений (прил. C). Итоговая база данных содержит 35 таблиц, схема данных представлена в приложении A (рис. A.7-A.9).
2.3 Диаграмма классов модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
В процессе проектирования системы необходимо было разработать статическую структуру системы в нотации диаграмм классов UML.
Классы предметной области были разработаны на основе БД с некоторыми изменениями (рис. A.10-A.12). Были также добавлены перечислимые типы, необходимые для выбора типа мероприятия, типа участника и пола ученика - данные типы не хранятся в БД, так как они должны оставаться неизменными.
Кроме того, были разработаны классы, необходимые для работы приложения с БД и с запросами - NHRepository<T> и контроллеры (рис. A.13).
Таким образом, была спроектирована диаграмма классов системы учета профориентационных мероприятий.
2.4 Проведение технико-экономического обоснования разработки модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
На данном этапе необходимо было провести технико-экономическое обоснование разработки системы.
Для расчета трудоемкости и стоимости работ на создание программного продукта была выбрана методика CETIN.
Первым этапом расчета была оценка функционального размера программного продукта. Показатели были выявлены с помощью построенных диаграмм:
1. Количество вариантов использования (количество прецедентов) - 20.
2. Количество типов объектов (количество классов, относящихся к предметной области) - 31.
3. Количество свойств типов объектов (количество свойств классов, относящихся к предметной области) - 98.
4. Количество взаимодействий между типами объектов (количество связей между классами, относящимися к предметной области) - 33.
5. Количество типов узлов (серверная часть, клиентская часть) - 2.
Таким образом, функциональный размер составляет {20, 31, 98, 33, 2}. Далее необходимо было рассчитать базовую трудоемкость создания программного продукта (табл. 2.1).
Таблица 2.1 Расчет базовой трудоемкости создания программного продукта
|
Наименование процесса |
Функциональная единица измерения |
Итого чел. мес. |
|||||
|
Вариант использования |
Тип объекта |
Свойства типа объекта |
Свойства взаимоотношения между объектами |
Тип узла |
|||
|
Трудоемкость, чел.час |
|||||||
|
Бизнес моделирование |
32,12 |
28,33 |
0 |
14,15 |
0 |
12,05 |
|
|
Управление требованиями |
58,03 |
28,04 |
0 |
20,32 |
0 |
16,37 |
|
|
Проектирование |
45,42 |
61,75 |
31,35 |
37,52 |
24,02 |
43,52 |
|
|
Реализация |
31,57 |
81,51 |
50,72 |
36,11 |
0 |
56,49 |
|
|
Тестирование |
88,96 |
0 |
0 |
0 |
0 |
10,78 |
|
|
Развертывание |
8,69 |
0 |
0 |
0 |
23,74 |
1,34 |
Базовая трудоемкость составляет 140.55 человеко-месяцев.
Следующим этапом необходимо было рассчитать поправочные коэффициенты трудоемкости процессов разработки программного продукта (табл. 2.2).
Таблица 2.2 Расчет базовой трудоемкости создания программного продукта
|
КП1 |
1,12 |
|
|
КП2 |
1,15734528 |
|
|
КП3 |
1,33537276 |
|
|
КП4 |
1,192297107 |
|
|
КП5 |
1,33537276 |
|
|
КП6 |
1,257984 |
Затем необходимо было оценить трудоемкость разработки с учетом поправочных коэффициентов (табл. 2.3).
Таблица 2.3 Расчет базовой трудоемкости создания программного продукта
|
№ |
Наименование процесса |
Итого чел. мес. |
Итого с учетом коэффициентов чел. мес. |
|
|
1 |
Бизнес моделирование |
12,05 |
13,50 |
|
|
2 |
Управление требованиями |
16,37 |
18,95 |
|
|
3 |
Проектирование |
43,52 |
58,12 |
|
|
4 |
Реализация |
56,49 |
67,35 |
|
|
5 |
Тестирование |
10,78 |
14,40 |
|
|
6 |
Развертывание |
1,34 |
1,69 |
Итоговая трудоемкость составляет 173.99 человеко-месяцев. При такой оценке трудоемкости сроки разработки можно оценить в 8 месяцев. Минимум 4 месяца, максимум - 12 (табл. 2.4).
Таблица 2.4 Зависимость срока разработки от трудоемкости
|
Срок разработки |
Трудоемкость чел. мес. |
|
|
1 месяц |
5 - 30 |
|
|
2 месяца |
10 - 80 |
|
|
3 месяца |
17 - 140 |
|
|
4 месяца |
26 - 210 |
|
|
5 месяцев |
37 - 280 |
|
|
6 месяцев |
50 - 340 |
|
|
7 месяцев |
65 - 400 |
|
|
8 месяцев |
80 - 450 |
|
|
9 месяцев |
100 - 500 |
|
|
10 месяцев |
120 - 550 |
|
|
11 месяцев |
140 - 610 |
|
|
12 месяцев |
160 - 670 |
|
|
13 месяцев |
180 - 720 |
При уменьшении сроков разработки с 8 до 4 месяцев произойдет увеличение трудоемкости разработки программного продукта. При условии, что коэффициент эластичности трудоемкости составляет 0.75, а срок уменьшается на 50%, трудоемкость увеличится на 37.5% и составит 239.24 человеко-месяцев.
Далее необходимо было оценить стоимость разработки программного продукта. Среднее количество лет реализации проекта составляет 1 год. Среднемесячная номинальная заработная плата в области информации и связи составляет 67797 рублей по данным от Федеральной службы государственной статистики России за 2018 год [8]. Средняя инфляция за 3 года составляет 4,06%. Средняя стоимость 1 человека-месяца инженера-программиста составляет 225 236,36 рублей.
Таким образом, стоимость работ на создание программного продукта составляет 39 188 874,15 рублей.
Развитие и сопровождение системы не предполагается.
Поскольку разрабатываемая система не предполагает массового использования, окупаемость не рассчитывается.
2.5 Проектирование пользовательского интерфейса модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Последним этапом проектирования системы является проектирование интерфейса. На данном этапе необходимо было создать единый стиль оформления страниц и меню сайта (рис. 2.4). Для этого были использованы корпоративные цвета НИУ ВШЭ - белый (#ffffff) и синий (#003380) [7].
Рисунок 2.4 Меню сайта
Затем необходимо было разработать макет календаря мероприятий (рис. 2.5). Важно было учесть, что мероприятие должны выделяться разными цветами в зависимости от подразделения, которые занимается его организацией. Для выделения мероприятий с несколькими подразделениями был выбран серый цвет (#d8e4e4).
Рисунок 2.5 Календарь мероприятий
При нажатии на мероприятие должна отображаться краткая информация о нем и кнопки удаления и редактирования (рис. 2.6).
Рисунок 2.6. Краткая информация о мероприятии
Также необходимо было разработать макет страницы для редактирования справочников (рис. 2.7). Она должна была включать список возможных справочников со ссылками на них, заголовок текущего справочника, строку поиска, кнопку добавления и таблицу с элементами.
Рисунок 2.7 Страница редактирования справочников
Для редактирования и добавления элементов справочников было решено использовать модальные окна (рис. 2.8). Каждый такой компонент должен включать заголовок, поля ввода (либо селекторы) с названиями для всех свойств, которые есть у данного типа справочника, и кнопки «Сохранить» и «Отмена».
Остальные компоненты были спроектированы во время непосредственной разработки системы на основе представленных макетов с соблюдения общего стиля.
В данной главе были описаны этапы проектирования системы для учета профориентационных мероприятий, была разработана база данных, созданы необходимые диаграммы и основной интерфейс системы.
3. Разработка модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Данная глава представляет собой описание этапов реализации системы: создание модели реализации, выполненной в нотации диаграммы компонентов UML, разработку основных компонентов. Также здесь содержится описание процесса тестирования системы и подготовки документации.
3.1 Модель реализации модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
Перед реализацией информационной системы была построена модель реализации, выполненная в нотации диаграммы компонентов UML.
Диаграмма, описывающая основную структуру серверной части системы, состоит из контроллера «EventController.cs», сервиса «EventService», хранилища «EventStorage.cs», репозиториев «EventRepository.cs» и «NHRepository.cs», библиотеки «NHibernate.dll» (для использования интерфейсов «ISession» и «ISessionFactory»), модели «Event.cs» и базы данных «HSEvents.dbo» (рис 3.3).
Рисунок 3.1 Диаграмма компонентов серверной части системы
Диаграмма, описывающая основную структуру клиентской части системы, состоит из макета «Index.html», который включает в себя иконку «favicon.ico», используемые скрипты («bootstrap.js», «jquery.js») и стили («bootstrap.min.css», «font-awesome.min.css», «styles.css»), а также загрузчик «SystemJS», который обеспечивает работу с Angular. Компоненты Angular состоят из модуля «app.module.ts», роутинга «app-routing.module.ts», самого компонента «app.component.ts», его шаблона «app.component.html» и стилей «app.component.css» (рис. 3.2).
Рисунок 3.2 Диаграмма компонентов клиентской части системы
3.2 Разработка серверной части модуля учета профориентационных мероприятий информационно-аналитической системы приемной кампании
В серверной части системы необходимо было реализовать загрузку компонентов Angular и макета «Index.html» при любом обращении к системе кроме API запросов. Для этого были прописаны правила маршрутизации: запросы API направлялись к соответствующим контроллерам, все остальные уходили в «HomeController», который возвращал пользователю html-страницу.
Для каждой модели был добавлен свой контроллер с методами для создания, получения, обновления, удаления и обработки данных. Каждый контроллер обращается к соответствующему сервису, в котором содержится логика обработки данных. Для работы с базой данных созданы хранилища и репозитории: репозитории взаимодействуют с данными с помощью библиотеки «NHibernate» - открывают сессию и совершают необходимые транзакции; хранилища соз...
Подобные документы
Назначение, создание современной информационно-аналитической системы. Формирование рабочей документации в среде Microsoft Project. Расчет длительности проекта методом Монте-Карло. Моделирование типов связи. Проектирование интерфейсов пользователя.
курсовая работа [4,9 M], добавлен 16.12.2014Принципы разработки программного обеспечения, паттерны проектирования. Прототип информационно-аналитической системы MCControl для поддержки процесса техобслуживания и ремонта оборудования дискретного производства малого производственного предприятия.
курсовая работа [81,7 K], добавлен 10.01.2014Обзор функциональных возможностей продукта "1С:Колледж". Информационно-технологические потоки рабочих мест сотрудников приемной комиссии. Структура связанных баз данных, необходимых для автоматизации их работы. Уровни администрирования и доступа к данным.
дипломная работа [4,2 M], добавлен 19.12.2013Теоретические основы применения информационных компьютерных технологий в управлении образовательным учреждением. Разработка и внедрение варианта управления гимназией на основе адаптации автоматизированной информационно-аналитической системы "АВЕРС".
дипломная работа [106,4 K], добавлен 14.05.2011Реализация информационно-аналитической системы "Зарплата" с помощью MS ACCESS. Способы ввода информации, ее корректировки и обработки. Формы, соответствующие требованиям запроса, предназначенные для вывода данных. Лист "Табель учета рабочего времени".
курсовая работа [7,2 M], добавлен 27.02.2015Проектирование алгоритмов и программных кодов для различных элементов пользовательских форм информационно-аналитической системы. Исследование структуры базы данных. Связь между таблицами. Разработка графического интерфейса программы и справочной системы.
курсовая работа [2,4 M], добавлен 10.01.2015Роль, место, структура прогнозирования и предсказывания в информационно-аналитической работе. Характеристика его методов: имитационного моделирования, морфологического анализа,"дерева целей", неформального прогнозирования. Основные правила их составления.
контрольная работа [90,3 K], добавлен 19.04.2011Анализ задачи создания ИАС для оптимизации работы сотрудников учреждения при обслуживании пациентов. Разработка базы данных и аппаратной подсистемы для обработки сведений о вакцинации населения. Результат реализации информационно-аналитической системы.
дипломная работа [3,8 M], добавлен 27.06.2012Создание информационно-аналитической системы компьютерного салона, организующей операции с продажей компьютеров и комплектующих к ним (принтеров, мониторов и т.д.), на основе справочной информации, содержащейся в четырнадцати взаимосвязанных таблицах.
контрольная работа [4,8 M], добавлен 11.01.2009Создание информационно-аналитической системы (базы данных) "Реализация кондитерских изделий". Использование методов сортировка, добавление абонентов, удаление, изменение, поиск данных, фильтрация, диапазон. Среда разработки - язык программирования Delphi.
курсовая работа [761,7 K], добавлен 10.04.2011Предназначение информационно-справочной системы - ведение учета студентов в деканате, переводя их с курса на курс. Основные функции системы: зачисление, отчисление, начисление стипендии. Нормализация (построение структуры). Главное меню пользователя.
курсовая работа [1,7 M], добавлен 09.01.2013Общая характеристика государственной системы научно-технической информации РФ: структура и виды информационных ресурсов, основной принцип функционирования. Задачи, цели и концепция создания распределенной информационно-аналитической системы (РИАС) ГСНТИ.
презентация [554,3 K], добавлен 14.10.2013Разработка программной системы автоматизации работы приемной комиссии. Выбор CASE-средства проектирования базы данных. Разграничение доступа к записям таблиц. Триггеры и функции БД. Выбор интерфейса программирования. Разработка классов и структур данных.
дипломная работа [1,9 M], добавлен 07.03.2012Главные преимущества использования информационно-аналитической системы "Невод". Характеристика объектов с использованием значений атрибута. Форма ввода данных, их интеграция. Формирование сложного поискового задания. Визуализация семантической сети.
презентация [382,8 K], добавлен 14.10.2013Изучение организационной структуры кожно-венерологического диспансера. Анализ медицинской информационной системы "Квазар". Проектирование системы управления базами данных. Описание программных комплексов "Учет обращений пациентов", "Анализ ИППП".
дипломная работа [1,9 M], добавлен 13.04.2015Теоретические основы проектирования информационно-справочных систем. Значение информационно-справочных компонент в корпоративных информационных системах. Разработка концептуальной и инфологической модели информационно-справочной системы ГОУ НПО ПУ №33.
дипломная работа [645,4 K], добавлен 02.09.2010Этапы разработки объектно-ориентированной модели информационной подсистемы приемной комиссии для учета абитуриентов. Создание диаграмм для моделирования процесса обмена сообщениями между объектами. Порядок генерации программного кода на языке С++.
курсовая работа [429,3 K], добавлен 29.06.2011Проектирование программной системы, предназначенной для работников приемной комиссии вуза. Разработка базы данных в пакете Microsoft Office Access, обеспечивающей хранение сведений об абитуриентах. Создание пользовательских форм, запросов и отчетов.
контрольная работа [2,5 M], добавлен 25.03.2015Описания информационно-аналитической системы Министерства здравоохранения Российской Федерации. Изучение её структуры, назначения и области применения. Уровни криптографической защиты данных. Характеристика средств защиты от несанкционированного доступа.
дипломная работа [59,0 K], добавлен 08.07.2014Информационное обеспечение предприятия. Защита от несанкционированного доступа к информации. Характеристика классификаторов и систем кодирования. Схема пакета дерева вызова процедур и программ. Взаимосвязь программных модулей и информационных файлов.
дипломная работа [258,8 K], добавлен 20.05.2013
