33
Отладка «на лету»
+
+
Подсветка
синтаксиса с
интеллектуальным
подбором
-
+
Механизмы доступа
к БД
BDE,ADO, Express,
dbExpress
ADO .NET
Наличие визуальных
и не визуальных
компонент для
работы с БД
+
+
Поддержка
технологии Rapid
Application
Development
+
+
Средства поддержки
транзакций
Управление транзакциями
на уровне компонента
Database
Механизм
управления
транзакциями
34
Продолжение таблицы 3
1
2
3
Сложность или
простота работы с
инструментальным
средством
Среда позволяет быстро и
удобно разрабатывать
эффективные приложения.
Среда ориентирована на
быструю разработку
качественных приложений
На основе проведенного анализа средств разработки приложений в
качестве средства для реализации клиентской части подсистемы регистрации
заявок могут использовать оба рассмотренных варианта. Тем не менее, в
качестве средства разработки была выбрана среда Microsoft Visual Studio в
связи с наличием большего опыта разработки автора дипломного проекта.
1.3.3. Обоснование проектных решений по техническому обеспечению
Под техническим (аппаратным) обеспечением информационной системы
понимается весь комплекс электронных, электрических и механических
устройств, входящих в состав системы и/или сети, исключая программное
обеспечение и хранимую информацию. В этот комплекс входят: компьютеры,
периферийные устройства ввода/вывода и хранения информации, а также
сетевое оборудование различных типов и энергетическое оборудование
(батареи и аккумуляторы) [2]. Для печати документов необходимо наличие
принтер и сканера, или МФУ (многофункционального устройства).
Требования к техническому обеспечению формировались исходя из
аппаратных требований используемого программного обеспечения, и
представлены в таблице 4.
Таблица 4
Аппаратные требования информационной системы
Устройство
Сервер
Клиент
Процессор
2,0 ГГц (с архитектурой x64)
1,6 ГГц
ОЗУ
2 ГБ
512 МБ
Видеокарта и монитор
монитор SVGA (1024х768 точек)
Жесткий диск
120 Гб
100 МБ
ЛВС
Пропускная способность 100 Мбит/с
35
ГЛАВА 2. ПРАКТИЧЕСКАЯ ЧАСТЬ
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл
информационной системы представляет собой непрерывный процесс,
начинающийся с момента принятия решения о создании информационной
системы и заканчивается в момент полного изъятия ее из эксплуатации [7].
Среди наиболее известных стандартов можно выделить следующие
стандарты, представленные на рисунке 2.1 [4].
Рисунок 2.1 – Стандарты этапов жизненного цикла
Жизненный цикл информационной системы охватывает все стадии и
этапы ее создания, сопровождения и развития [7]:
исследование предметной области;
проектирование системы;
разработку системы;
тестирование информационной системы;
эксплуатацию системы и ее сопровождение;
36
развитие системы.
Жизненный цикл протекает в соответствии с выбранной моделью ЖЦ.
Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в
некоторых случаях и процессы разработки.
В настоящее время существует две основные модели жизненного цикла
– это каскадная и спиральная модели (рисунок 2.2) [6].
Рисунок 2.2 - Каскадная схема разработки ПО
В каскадной модели процесс разработки идет поэтапно, шаг за шагом.
Переход к следующему этапу происходит только после завершения
предыдущего. В спиральной модели разработка проходит по нарастающей. На
начальном этапе разрабатывается система с высоким уровнем абстракции, а на
последующих витках эта разработка все больше и больше конкретизируется.
Для жизненного цикла текущего проекта была выбрана каскадная
модель, так как для разрабатываемой системы больше подходит поэтапная
разработка. Переход к следующему этапу происходит только после завершения
всех работ на предыдущем этапе, включая подготовку полного пакета
документации, достаточной для того, чтобы разработка могла быть продолжена
37
другой группой разработчиков и есть возможность планирования сроков
завершения работ и затрат на их выполнение.
Состав каждого этапа определяется сложностью и функциональностью
каждой разрабатываемой системы. Часто несколько этапов объединяются в
один более масштабный.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Управление рисками проекта (Project Risk Management). Под процессами
управления рисками проекта понимается планирование управления рисками,
идентификация и анализ рисков, выработке методов реагирования на риски,
контроль, мониторинг и управление рисками в ходе реализации проекта.
Посредством процессов управления рисками проекта, Руководители проектов
добиваются повышения вероятности возникновения и воздействия (влияния)
благоприятных рисков (событий) на проект и снижают вероятность
возникновения и воздействия (влияния) неблагоприятных рисков (событий) на
проект в момент исполнения этого проекта. Схема процессов управления
рисками проекта включает в себя планирование управления рисками,
идентификацию рисков, качественный анализ рисков, количественный анализ
рисков, планирование реагирования на известные риски, мониторинг и
управление рисками [14].
Главная таблица рисков представлена в таблице 5.
Таблица 5
Главная таблица рисков
Прио-
ритет
Формули-
ровка риска
Последствие
Вероят-
ность
Угроза
Ожида-
емая
величина
1
2
3
4
5
6
1
Отсутствие
согласованны
х требований
к ИС
Презентация
незавершенн
ого проекта
30%
3
0,9
38
Продолжение таблицы 5
1
2
3
4
5
6
2
Недостаточный
уровень знаний
персонала
Выпуск ИС с
ограниченной
функционально
стью
50%
2
1
3
Отключение
электроэнергии
Простой работы
сотрудников
администрации
10%
5
0,9
4
Выход из строя
жесткого диска
Потеря данных
о деятельности
компании
10%
5
1
5
Один из членов
команды
заболеет
Некоторые
требования не
будут
реализованы
30%
1
0,4
Для снижения вероятности возникновения риска «Отсутствие
согласованных требований к ИС» необходимо на стадии постановки задачи как
можно подробнее уточнить требования у заказчика с предоставлением макетов
входных и выходных форм. Также не необходимо помимо директора магазина
иметь возможность консультации с другим уполномоченным
заинтересованным лицом.
Для предотвращения возникновения риска «Недостаточный уровень
знаний персонала» следует предусмотреть проведение полного курса обучения
пользователей после разработки информационной системы, кроме того на этапе
создания интерфейса системы предусмотреть защиту от некорректных
действий пользователя и максимально простой и понятный визуальный
интерфейс без лишней функциональности.
Риск «Отключение электричества» является неуправляемым, поэтому
при разработке технического задания в требованиях следует указать наличие
стационарной точки подачи электроэнергии во избежание остановки работы
сотрудников администрации по приему заявок.
Для защиты от выхода из строя жесткого диска, на котором находится
база данных – внести требования об обязательном резервном копировании
данных на схемные носители, либо жесткий диск, который установлен на
другом компьютере. Резервное копирование должно быть настроено в
39
соответствии с разработанной политикой безопасности компании во избежание
несанкционированного доступа к данным посторонними лицами.
Риск «Один из членов команды заболеет» должен быть нейтрализован с
уточнение в техническом задании возможности продления срока выполнения
заказа до 1 месяца.
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и ее описание
Информационная модель представляет собой схему движения входных,
промежуточных и результативных потоков и функций предметной области.
Кроме того, она объясняет, на основе каких входных документов и какой
нормативно-справочной информации происходит выполнение функций по
обработке данных и формирование конкретных выходных документов [4].
Информационная модель системы управления заявками представлена на
рисунке 2.3.
При необходимости, оператором системы, запрашивается у системы
отчет, содержащий необходимую информацию, в том числе формируется
отчетность: статистика приема и обработки заявок, сведения о заявителях,
сведения о заявках и результатах их выполнения за выбранный промежуток
времени и т.д.
В качестве входных документов выделены:
– cведения об отделах и подразделениях;
– cведения о заявителях и их статусах;
– сведения о заявках и результатах их рассмотрения.
40
Рисунок 2.3 – Информационная модель задачи
В качестве данных, которые будут сохранены в базе данных
информационной системы выделены:
– отделы;
– подразделения;
– сотрудники администрации;
– статусы заявителей;
– категории заявок;
– виды заявок по подразделениям и категориям;
– заявители;
– заявки;
– результаты обработки заявок;
– способы получения заявок.
На рисунке 2.4 представлена IDEF0-модель TO-BE («КАК ДОЛЖНО
БЫТЬ»), отражающая основные бизнес-процессы по регистрации заявок после
внедрения информационной системы регистрации заявок в общем отделе
администрации г.п. Советский.
Относительно модели AS-IS, рассмотренной ранее, был добавлен
механизм управления – ИС, отражающий информацию о том, какие действия
по регистрации заявок будут возложены на информационную систему.
41
Рисунок 2.4 – Контекстная диаграмма TO-BE
На рисунке 2.5 представлена декомпозиция контекстной диаграммы.
Рисунок 2.5 – Декомпозиция контекстной диаграммы
42
Как видно из представленной схемы, информационная система будет
участвовать во всех бизнес-процессах.
На рисунке 2.6 представлена декомпозиция блока «Учет и обработка
заявок».
Рисунок 2.6 - Декомпозиция блока «Учет и обработка заявок»
Сотрудники будут учувствовать в процессах вноса информации о
заявителе и заявке. Отправка заявки исполнителю будет выполнена
информационной системой автоматически.
На рисунке 2.7 представлена декомпозиция блока «Учет результатов
обработки заявок».
Информационная система позволит автоматически отправлять запрос
исполнителю заявки запрос на получение сведений о результатах выполнения
заявки, которые будут внесены в БД сотрудниками общего отдела.