45
Представленная система классификации и кодирования позволяет в
полной мере снизить информационную нагрузку на пользователя
информационной системы и более правильно организовать структуру базы
данных информационной системы.
1.4.2 Обоснование проектных решений по программному обеспечению
Программное обеспечение включает совокупность программ, которые
реализуют функции и задачи информационной системы и обеспечивают
устойчивую работу комплексов технических средств. В состав программного
обеспечения входят общесистемные и специальные программы, а также
инструктивно-методические материалы по применению средств программного
обеспечения.
К общесистемному программному обеспечению можно отнести
программы, которые рассчитаны на широкий круг пользователей и
предназначены для организации вычислительного процесса и выполнения часто
встречающихся вариантов обработки информации. Данные программы
позволяют расширить функциональные возможности ЭВМ, автоматизировать
планирование очередности вычислительных работ, а также автоматизировать
работу программистов. Специальное программное обеспечение представляет
собой совокупность программ, разрабатываемых при создании
информационной технологии конкретного функционального назначения. Оно
включает пакеты прикладных программ, осуществлявших организацию данных
и их обработку при решении функциональных задач информационной
системы [22].
В процессе выбора комплекса технических средств для разработки
системы, одним из важнейших критерием является выбор операционной
системы. Операционная система управляет техническими средствами
компьютера, поддерживает запуск и выполнение тех или иных программ и
46
приложений, обеспечивает защиту данных, выполняет различные сервисные
функции. Каждая программа пользуется средствами, предоставляемыми
операционной системой. Таким образом, выбор операционной системы очень
важен, так как он определяет набор программ и формат исполняемых файлов, а
также их взаимодействие с операционной системой.
Для разработки программного приложения автоматизированной
обработки выбор той или иной операционной системы не повлияет на
функциональность системы по причине того, что при реализации алгоритмов
программного приложения не требуется использования каких-либо
специфических функций операционной системы. Оба типа операционных
систем позволяют разрабатывать программный продукт без потери его
функциональности, по причине наличия программных сред для обоих типов
операционных систем [24].
В качестве операционной среды для разработки и применения программы
была выбрана операционная система семейства Windows, в частности
операционная система Windows 8. Этот выбор обусловлен тем, что на
сегодняшний день Windows 8 является одной из наиболее распространенных
операционных систем. Операционная система Windows 8 обеспечивает
стабильность работы, предоставляя пользователям возможность
сосредоточиться на выполняемой работе.
1.4.3 Обоснование проектных решений по техническому обеспечению
Обеспечение техническое - совокупность технических средств,
компьютерной техники, средств передачи информации, используемых в
автоматизированных системах управления и в информационных системах.
Для функционирования программы потребуются следующие элементы
технического обеспечения:
ПК-пользователя (рабочая станция) – это пользовательский ПК,
посредством которого будет производиться работа с программной,
установленной локально;
47
Средства организации ЛВС – в данный перечень входят активные
(маршрутизатор, коммутатор, шлюз и.тд) и пассивные (сегменты ЛВС,
коммутационные розетки и.тд) компоненты локальной вычислительной сети.
Для каждого элемента мы выберем несколько критериев, наиболее
критичных при осуществлении выбора:
Требования к аппаратному обеспечению рабочей станции следующие:
компьютер, с процессором Intel Pentium G3260, OEM, материнской платой
ASUS H81M-K, и входящими в комплект мышью и клавиатурой Logitech
Desktop MK120. В настоящий момент характеристики компьютеров компании
соответствуют указанным требованиям, поэтому дополнительных технических
решений по внедрению разработанного программного средства, не требуется.
48
2. Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Для описания функциональных требований, предъявляемых к системе, был
использован стандарт ГОСТ 34.602-89 «Техническое задание на создание
автоматизированной системы», в котором раздел «Требования к системе»
состоит из следующих подразделов:
− общие сведения;
− назначение и цели создания (развития) системы;
− характеристика объектов автоматизации;
− требования к системе;
− состав и содержание работ по созданию системы;
− порядок контроля и приемки системы;
− требования к составу и содержанию работ по подготовке объекта
− автоматизации к вводу системы в действие;
− требования к документированию;
− источники разработки.
Требования к структуре и функционированию системы.
В состав системы должны входить следующие модули:
− Модуль «Заявки клиентов»;
Модуль «Заявки клиентов» должен обеспечивать ввод информации о уже
существующих заявках, арендаторах, зарегистрированных в системе.
− Модуль «Администрирование»;
Модуль «Администрирование» должен обеспечивать контроль над всеми
функциями системы: описанием внешнего вида, добавление редактирование
функций, добавление новых модулей, а также настройку работ функций
системы.
В таблице 9 представлено распределение прав доступа.
49
Таблица 9.
Распределение прав доступа
Функциональная
роль
Модуль
Права доступа
Чтение
Изменение
Заявки клиентов
+
+
Администрирование
-
-
Заявки клиентов
+
+
Администрирование
+
+
В целях надежности обучающей системы она должна удовлетворять
следующим требованиям:
− разработанная программа должна обладать средствами защиты от
ошибочных действий пользователей;
− все ошибки должны отображаться с комментариями или
подсказками по их устранению;
− гарантировать сохранность данных при сбоях в работе внешних
устройств.
Для повышения надежности необходимо принять следующие меры:
сконфигурировать аппаратные и программные средства в
соответствии с техническими требованиями;
периодически осуществлять резервное копирование информации;
регулярно проверять целостность базы данных;
поддерживать исправность сетевого оборудования.
Взаимодействие пользователей с системой и модулями, входящим в состав
системы должно осуществляться посредством визуального графического
интерфейса. Интерфейс системы должен быть понятным и удобным, не должен
быть перегружен графическими элементами и должен обеспечивать быстрое
отображение экранных форм. Навигационные элементы должны быть
выполнены в удобной для пользователя форме.
Все надписи экранных форм, а также сообщения, выдаваемые
пользователю (кроме системных сообщений) должны быть на русском языке.
50
Система должна обеспечивать корректную обработку аварийных ситуаций,
вызванных неверными действиями пользователей, неверным форматом или
недопустимыми значениями входных данных. В указанных случаях система
должна выдавать пользователю соответствующие сообщения, после чего
возвращаться в рабочее состояние, предшествовавшее неверной
(недопустимой) команде или некорректному вводу данных.
Экранные формы должны проектироваться с учетом требований
унификации:
− Все экранные формы пользовательского интерфейса должны быть выполнены в
едином графическом дизайне, с одинаковым расположением основных
элементов управления и навигации;
− Все элементы управления и навигации в интерфейсе пользователя должны
соответствовать функциональным задачам;
− При нажатии на любую кнопку, пункт меню, выпадающий список должно
происходить событие, соответствующее задействованному элементу
управления: переход на станицу выбранного раздела, открытие выпадающего
списка;
− В результате создания системы должен быть разработан унифицированный
интерфейс взаимодействия пользователя с компонентами программного
обеспечения при выполнении функций;
− Интерфейс не должен содержать неоднозначных элементов. Все элементы
пользовательского интерфейса должны быть присутствовать обоснованно и
выполнять определенные функции. В интерфейсе должны отсутствовать
пустые кнопки, при нажатии которых происходит либо сомнительное действие
для пользователя, либо ничего не происходит.
Система должна обеспечивать защиту от несанкционированного доступа.
Должны использоваться "слепые" пароли (при наборе пароля его символы не
показываются на экране либо заменяются одним типом символов; количество
символов не соответствует длине пароля).
51
Для сотрудника, который оформляет заявку на проведение работ должны
быть доступны следующие операции:
− возможность авторизации в системе
− возможность составления заявки
− возможность получения отчета по заявке
− просмотр архива заявок
Для администратора доступны следующие операции:
− Просмотр профиля сотрудника
− Просмотр всех заявок (новые, принятые, на исполнении, на
проверке, архивные)
− Проверка заявок на возможность выполнения
− Внесение комментарий по заявке
− Возможность присвоения статуса заявке
В рассматриваемой задаче автоматизации, в ходе которой необходимо
автоматизировать процесс приема и распределения заявок на предприятии в
качестве технического обеспечения используются следующие средства:
− персональные компьютеры;
− сервера;
− соединительные линии локальной вычислительной сети.
Персональные компьютеры оцениваются по следующим основным критериям:
быстродействие процессора;
объем жесткого диска;
объем оперативной памяти;
быстродействие видеокарты.
Так как разрабатываемый модуль будет работать на основе клиент-
серверной технологии, то все вычисления будут производиться на стороне
сервера, следовательно, системные требования к персональным компьютерам
минимальны.
52
Для реализации программного продукта необходимо создать базу данных
для хранения информации компании. Создание базы данных продиктовано
следующими требованиями:
− хранение информации о различных объектах;
− малый объем занимаемого места на носителе при большом
количестве информации;
− структурированность хранимой информации.
Реализация всех пунктов может быть достигнута только при
использовании базы данных. Малый объем занимаемого места на носителе
осуществляется с помощью нормализации базы данных. Любая информация,
хранимая в базе данных, автоматически структурируется. При использовании
базы данных, создание отчетности занимает большого количества времени.
Возможность расширения функциональности программного продукта
достигается путем расширения либо возможностей приложения пользователя,
либо с помощью расширения базы данных, добавления новых таблиц и связей.
Под расширением возможностей приложения пользователя, как правило,
подразумевается создание осуществление дальнейшей автоматизации
процессов, протекающих на предприятии. После реализации приложения
пользователя возможность расширения функций приложения пользователя не
занимает много времени, а иногда даже может быть реализована отдельным
программистом.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
Необходимо учитывать возможные риски после автоматизации:
− проектные риски при создании системы,
− бизнес-риски, связанные с эксплуатацией системы (возникающие, в
конечном счете, из-за технических рисков).
− бизнес-риски, связанные с изменением бизнес-процессов. При этом
потери происходят оттого, что: а) бизнес-процессы надо изменять, а
информационная система не готова к этому, и потери связаны с неоптимальным
53
функционированием бизнеса, и б) оттого, что имеется стоимость модификации
системы,
− технические риски, состоящие в простоях, отказах, потере или
искажении данных и т.п.
Выделим четыре существенных риска практически любого проекта, в том
числе проекта внедрения ИС:
1. риск низкого качества результатов проекта — выполнение работ с
низким уровнем качества и неспособность удовлетворять разумные требования
конечных пользователей;
2. риск срыва сроков проекта — невыполнение работ в установленные
сроки, зависимость выполнения работ от смежных проектов и мероприятий;
3. риск увеличения затрат — недостаток определенных бюджетом
проекта средств, необходимость увеличения бюджета;
4. риск остановки проекта — изменение условий и масштабов
проекта.
Далее следует определить факторы риска. Фактор риска — это
характеристики (события, свойства, факты) проекта, которые существенно
влияют на него и качество его результатов.
Необходимо отметить, что малозначительные риски в совокупности
могут образовать критическую массу, представляющую серьезную угрозу
проекту. Точно так же и маловероятные риски в случае возникновения могут
завести проект в тупик.
После запуска системы в промышленную эксплуатацию, то есть после
завершения проекта по внедрению системы выше перечисленные риски
перестают действовать — зато начинают проявляться другие, долгосрочные
риски, препятствующие дальнейшему развитию системы на предприятии.
Для более детального пониманию момента, когда может возникнуть
проблема, нужно рассмотреть риски разрабатываемого проекта по этапам. Для
разрабатываемого проекта актуальны следующие риски.
54
На этапе проектирования может возникнуть технологический риск. Он
проявляется в виде несоответствия разрабатываемого проекта реальной задаче
по причине некорректного выбора технологии. Этот риск минимизируется
путем тщательного анализа реальных бизнес процессов и их отношений, а
также путем сравнительного выбора используемых технологий.
На этапе разработки возникает риск реализации проекта – риск того, что
организация не сможет реализовать проект в заданные временные и бюджетные
рамки, или риск, что создание работоспособного решения завершится неудачей.
Снижается путем повышения эффективности управления проектной командой.
С другой стороны, этот риск не высок, ввиду отсутствия жесткой временной
границы реализации.
На этапе внедрения может возникнуть организационный риск, который
обусловлен не эффективной работой команды внедрения. Для противодействия
этому риску, необходимо составить план внедрения и организовать команду
внедрения более тщательно.
На этапе эксплуатации может возникнуть риск того, что
эксплуатационные расходы новой системы возрастут до нерентабельного
уровня. Может проявляться, как уличение затрат на обслуживание выбранного
технического обеспечения. В итоге вышеизложенного, таблица 10 наглядно
демонстрирует процентную вероятность определенного риска.
Таблица 10.
Риски проекта
Рисковая ситуация
Меры по предотвращению
Вероятность
Технологический
риск
Необходимо корректно поставить
задачу для разработки проекта
25%
Риск срыва сроков
проекта
Необходим контроль на каждом
этапе разработки и необходимо
увеличить время на реализацию
проекта
15%