32
Продолжение таблицы 1.6
1
2
3
4
Многопользовательский
режим
Да
Да
Да
Перенос БД между
различными СУБД
ODBC
Нет
Oracle Data
Migration
Сертифицированная среда
администрирования БД
MS SQL
Management
Studio
MySQL-Front
Oracle Data
Manipulation
Стоимость платной лицензии
(по данным на момент
написания работы)
от 48 250 руб.
0 руб.
от 9 500 $
Рассмотрим современные интегрированные среды IDE, которые могут
использоваться для разработки визуального интерфейса базы данных розничного
магазина:
CodeBlocks;
Microsoft Visual Studio;
Embarcadero RAD Studio.
В таблице 1.7 представлена сравнительная характеристика IDE сред
разработки.
Таблица 1.7
Сравнительная характеристика IDE сред разработки
Параметр
CodeBlocks
Microsoft Visual
Studio
Embarcadero RAD
Studio
Год выпуска
последней версии
2015
2016
2015
Сайт
codeblocks.org
visualstudio.com
visualstudio.com
Язык
программирования
C++
C#, VB.Net. F#
Object Pascal
Поддержка объектно-
ориентированного
программирования
+
+
+
Возможность
разработки плагинов
+
+
+
Поддержка
модульного
программирования
+
+
+
Поддержка
Intellessense
+
+
+
Рефакторинг
+
+
+
Стоимость лицензии
Бесплатная IDE
356 000 руб.
896 000 руб.
33
Для разработки информационной системы планирования и учета учебно-
методических материалов кафедры информационных технологий АУ МВД
России выбрана среда разработки Microsoft Visual Studio, так как эта IDE
предлагает мощные инструменты и большой набор функционала, элементов
управления.
1.4.3. Обоснование проектных решений по техническому обеспечению
Техническое обеспечение включает [1]:
компьютеры;
периферийные устройства ввода/вывода и хранения информации;
сетевое оборудование различных типов;
энергетическое оборудование (батареи и аккумуляторы).
Информационная система автоматизации планирования и учета учебно-
методических материалов кафедры информационных технологий АУ МВД
России должна быть реализована с архитектурой «клиент-сервер».
Минимальные требования к аппаратному обеспечению сервера:
– процессор не менее CPU Intel® Pentium® 4, RAM от 6 Гб;
– не менее 2 Гб дискового пространства.
Минимальные требования к аппаратному обеспечению клиента:
– процессор не менее CPU Intel® Pentium® 4, RAM от 4 Гб;
– не менее 10 Гб дискового пространства.
Требования к каналам связи: локальная сеть Ethernet 10 Мбит/сек.
34
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) проекта автоматизации – период с момента
создания технического задания проекта автоматизации до ее внедрения и
эксплуатации [25].
Существует несколько наиболее распространенных стандартов жизненного
цикла проекта автоматизации, представленных на рисунке 2.1.
Рисунок 2.1 - Стандарты жизненного цикла
В настоящей работе будет использована модель жизненного цикла проекта
ГОСТ Р ИСО/МЭК 12207-2010.
На рисунке 2.2 представлены основные этапы создания программного
обеспечения [25].
Жизненный цикл любого проекта автоматизации включает основные
стадии: предпроектную, проектировочную, внедрение, функционирование.
35
Рисунок 2.2 - Основные этапы создания программного обеспечения
От качества проектировочных работ зависит эффективность
функционирования системы, поэтому каждая стадия разделяется на ряд этапов и
предусматривает составление документации, отражающей результаты работ.
Наиболее популярными моделями жизненного цикла являются спиральная
и каскадная модель жизненного цикла. Существует также итерационная модель
ЖЦ с поэтапным выполнением работ, но она используется все реже.
На рисунке 2.3 представлена спиральная модель ЖЦ.
Рисунок 2.3 - Спиральная модель жизненного цикла
Преимущества спиральной модели жизненного цикла:
36
быстрое получение готового продукта
при изменении требований к программному обеспечению риски по
сдаче некачественного продукта снижаются;
низкий процент проблем в процессе доработки программного
обеспечения.
Недостатком спиральной модели является отсутствие четких границ
каждой стадии разработки программного обеспечения.
Каскадная модель жизненного цикла предполагает поэтапное выполнение
работ на каждом этапе.
На рисунке 2.4 представлена каскадная модель ЖЦ ПО.
Итерационная модель жизненного цикла предполагает поэтапное
выполнение каждого этапа разработки с возможностью возврата на предыдущий
этап. Но в этом случае пройденные этапы необходимо закончить снова.
Управление проектом проводится на основе ключевых функциональных
требований заказчика. Все силы разработчиков направлены на выполнение всех
требований заказчика в конечной версии программы.
Рисунок 2.4 - Каскадная модель жизненного цикла
По мере необходимости вносятся коррективы в техническое задание в
соответствии с замечаниями и требованиями. Разработка проекта в руках
архитекторов (рисунок 2.5).
37
Рисунок 2.5 - Итерационная модель жизненного цикла
В настоящей выпускной квалификационной работе будет использована
каскадная модель жизненного цикла программного обеспечения.
В таблице 2.1 представлены основные работы, которые будут выполнены в
процессе разработки проекта.
Таблица 2.1
Основные этапы работы над проектом с использованием каскадной
модели жизненного цикла
Этап
Выполняемые работы
Выработка системных
требований
Разработка требований к информационной системе, выбор
аппаратного и программного обеспечения
Анализ
Разработка функциональных требований к информационной
системе, выбор способов реализации системы
Проектирование
Разработка структура БД, функциональной схемы системы,
характеристика входные и выходные данные, математическая
модель решения задачи.
Кодирование
Разработка кода информационной системы.
Тестирование
Разработка контрольных наборов тестов, тестирование
информационной системы, составление протокола
тестирования, отладка программы
Эксплуатация
Установка программного обеспечения на рабочих местах
сотрудников, обучение пользователей
Существуют несколько стратегий внедрения системы, представленных на
рисунке 2.6 [25].
38
Рисунок 2.6 – Стратегии внедрения информационной системы
При внедрении данного проекта будет использована стратегия «Пилотный
проект», как наиболее оптимальная стратегия в данной ситуации.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Управление рисками, связанными с разработкой ПО, представляет собой
формальный процесс, позволяющий систематически идентифицировать,
оценивать и смягчать факторы возможного риска. В процессе управления
проектом основное внимание уделяется вопросам идентификации рисков в
проекте, имеющих как внутренние, так и внутренние причины [17].
Во время разработки информационной системы возможно появление
рисков, которые представлены в таблице 2.2.
Таблица 2.2
Риски на этапах жизненного цикла и способы их предотвращения
Этап
Риски
Способы предотвращения
1
2
3
Предпроектная
стадия
Недостаточный анализ
требований заказчика
Собеседование с заказчиком
должен провести профессионал,
который имеет большой опыт
работы в качестве архитектора
информационных систем
Ошибки и неточности в
техническом задании
39
Продолжение таблицы 2.2
1
2
3
Этап разработки
Потеря данных
Внедрение системы резервного
копирования данных
Низкий уровень
квалификации
сотрудников
Прием на работу только
специалистов с опытом работы
Сложность
последующего
обновления системы
Разработка алгоритма
обновления системы удаленно
Потеря исправлений
специалистов во время
сборки проекта
Внедрение системы управления
версиями проекта (например,
SVN)
Этап внедрения
Выход из команды
одного из специалистов
Несоответствие
продукта требованиям
заказчика
Несоответствие
продукта техническим
характеристикам ПК
заказчика
Создание резервных алгоритмов
внедрения (например, онлайн-
консультации ведущего
специалиста на этапе внедрения)
Тщательное изучение
характеристик ПК на этапе
создания технического задания
Несоответствие
политике
информационной
безопасности
предприятия
Аутентификация доступа,
использование Windows-
аутентификации, защита
информации обеспечивается
путём подписания каждым
пользователем обязательства о
неразглашении коммерческой
тайны
Этап функциониро-
вания
Ошибки в логике работы
программы
Доработка функционала системы
с помощью механизма
удаленного обновления системы
Потеря данных по вине
разработчика
Настройка резервного
копирования данных на стороне
заказчика
Потеря данных по вине
пользователя.
Необходимость
доработки системы под
новые требования
заказчика
Доработка функционала системы
с помощью механизма
удаленного обновления системы
40
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения информационной безопасности и защиты информации в
информационной системе планирования и учета учебно-методических
материалов АУ МВД России используются средства, рассмотренные в пункте
1.2.4.
Для реализации защиты от внутренних угроз в информационной системе
администратор системы должен определить группы пользователей перед ее
эксплуатацией на компьютерах организации.
Для этого крайне необходимо определить группы пользователей
разрабатываемой системы по планирования и учета учебно-методических
материалов и назначить им соответствующие права доступа к папкам и модулям
системы, определить требования к паролям и частоте их смены, а также другие
параметры использования информационной системы.
Следует выделить следующие роли:
сотрудник учебно-методического отдела;
проректор по учебной работе;
педагог кафедры.
Права доступа к данным для выбранный ролей пользователей
представлены в таблице 2.3.
Таблица 2.3
Разграничение прав пользователей
Группы
пользователей
Загрузка
нормативных
документов
Загрузка
УММ
Просмотр
УММ
Редактирование
статуса УММ
Формирование
отчетности
Сотрудник
учебно-
методического
отдела
Полный
доступ
Полный
доступ
Полный
доступ
Полный доступ
Полный доступ
Проректор по
учебной работе
Полный
доступ
Полный
доступ
Полный
доступ
Полный доступ
Полный доступ
Педагог
кафедры
Запрет
доступа
Запрет
доступа
Чтение
Запрет доступа
Запрет доступа
Каждому сотруднику, который будет иметь доступ к системе следует
назначить одну из выбранных ролей.
41
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Информационная модель — модель объекта, представленная в виде
информации, описывающей существенные для данного рассмотрения параметры
и переменные величины объекта, связи между ними, входы и выходы объекта и
позволяющая путём подачи на модель информации об изменениях входных
величин моделировать возможные состояния объекта [8].
Информационная модель задачи планирования и учета УММ кафедры
информационных технологий АУ МВД России представлена на рисунке 2.7.
Рисунок 2.7 - Информационная модель задачи планирования и учета УММ
кафедры информационных технологий АУ МВД России
В результате исследования предметной области и разработанных
требований к информационной системе планирования и учета методических
материалов кафедры информационных технологий АУ МВД России были
выделены следующие информационные объекты: