52
Анализируя представленную таблицу, можно сделать вывод, что в
модернизации нуждаются только персональные компьютеры сотрудников
отдела.
В соответствии с приведенными требованиями, наиболее подходящими
являются персональные компьютеры со следующими характеристиками:
Процессор: Intel Core i3 3300 MHz (7 290 рублей);
Оперативная память: 4 Gb DDR3 (2 390 рублей);
Жесткий диск: 500 Gb SATA (2 850 рублей) [23].
Стоимость такого комплекта составляет 12530 рублей, для полной
модернизации отдела необходимо 12 комплектов, стоимость которых составит
150360 рублей.
Кроме того, необходимо приобрести мониторы с большим, чему
используемых моделей размером и разрешением – к примеру, Lenovo LI2215sD:
Тип: ЖК;
Диагональ: 21,5";
Разрешение:1920x1080;
Время отклика: 5 мс;
Тип матрицы:TN+film;
Яркость: 200 кд/м2;
Контрастность 600:1
Цена – 5690 рублей.
Поскольку необходимо приобрести 20 мониторов, их стоимость будет
составлять 68280 рублей.
Как многофункциональными устройствами, так и устройствами
бесперебойного питания, рабочие места пользователей уже оборудованы,
поэтому внедрение разрабатываемой системы не требует закупки и установки
дополнительных технических средств.
Итого стоимость оборудования, которое необходимо приобрести составит
218 640 рублей.
53
2. Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) программного средства (ПС) – это период
времени, который начинается с момента принятия решения о необходимости его
создания, и заканчивается в момент его полного изъятия из эксплуатации [4].
Существует целый ряд методологий, описывающих жизненный цикл ПО:
1. ГОСТ Р ИСО/МЭК 12207-2010 – стандарт на процессы и
организацию жизненного цикла заказного ПО [1]. Он определяет структуру
жизненного цикла, содержащую процессы, действия и задачи, которые должны
быть выполнены во время создания ПО. Каждый процесс разделен на набор
действий, каждое действие — на набор задач. Каждый процесс, действие или
задача инициируется и выполняется другим процессом по мере необходимости,
причем не существует заранее определенных последовательностей выполнения.
2. Методология Oracle – технологический материал по разработке
прикладных АИС, детализированный до уровня заготовок проектных
документов в расчете на использование Oracle. Применяется для классической
модели жизненного цикла (предусмотрены все работы, задачи и этапы), а также
для технологий «быстрой разработки» или «облегченного подхода»,
рекомендуемых в случае малых проектов.
3. Методология RUP (RationalUnifiedProcess) – технологический
материал по реализации итеративной модели разработки, включающей 4 фазы:
начало, исследование, построение и внедрение. Каждая фаза разбита на этапы
(итерации), результатами которых являются версии для внутреннего или
внешнего использования. Каждый цикл завершается генерацией очередной
версии системы. Предполагает создание и сопровождение моделей на базе UML.
4. Методология MSF (MicrosoftSolutionFramework) –
технологический материал по реализации итеративной модели разработки,
аналогично RUP, включает 4 фазы: анализ, проектирование, разработку,
стабилизацию; предполагает использование объектно-ориентированного
моделирования.
54
5. ExtremeProgramming (XP) - экстремальное программирование.
Основой методологии является работа в команде, эффективные коммуникации
между заказчиком и исполнителем в течение всего проекта; разработка АИС
ведется с использованием последовательно дорабатываемых прототипов.
В методологии Oracle, RUP, MSF, XP не приводится структура и описание
технической документации по проекту. Поэтому был выбран для
проектирования ИС стандарт ГОСТ Р ИСО/МЭК 12207-2010.
В зависимости от проекта выбираются процессы, которые будут
включены в модель ЖЦ. При применении они могут перекрывать, прерывать
друг друга, выполняться итерационно или рекурсивно. Это определяет
«динамический» характер стандарта и позволяет реализовать с его помощью
произвольную модель ЖЦ ПС.
Для рассматриваемой ИС выделяются следующие базовые процессы
жизненного цикла:
1. Разработка:
Планирование и анализ требований (предпроектная стадия);
Проектирование;
Реализация;
Тестирование;
Внедрение.
2. Эксплуатация:
Поддержка пользователей;
Техническое обслуживание компонентов системы.
3. Сопровождение:
Сбор рекламаций;
Исправление ошибок и недоработок;
Модернизация.
На предпроектной стадии необходимо провести системный анализ,
включающий анализ функционирования и выявление недостатков
существующей технологии учета рабочего времени. На основе выявленных
недостатков формулируется потребность в совершенствовании системы
55
управления рабочим временем, создается технико-экономическое обоснование
проекта (ТЭО), формулируются технические условия и требования к ИС.
Результаты должны быть оформлены в виде технического задания (ТЗ). Первый
этап будет выполняться сотрудниками организации. Входную информацию
разработчики системы получает из интервью с сотрудниками, документации,
должностных инструкций, регламента работы и прочих документов,
характеризующих существующие бизнес-процессы.
Следующий этап – проектирование ИС – включает в себя разработку в
соответствии со сформулированными требованиями состава автоматизируемых
функций (функциональная архитектура), состава обеспечивающих подсистем
(системная архитектура), оформление технического проекта ИС. Входной
информацией для проектирования является ТЗ. На этом этапе определяется
состав программных подсистем и компонентов оборудования, составляются
спецификации требований к компонентам ПО, определяется состав компонентов
ПО (в том числе повторно используемых компонентов), интерфейсы с БД,
структуры хранения данных, алгоритмы обработки информации, спецификации
интерфейсов с другими системами автоматизации, требования к тестам. Данный
этап является очень ответственным с точки зрения качества всей последующей
разработки.
На этапе реализации выполняется физическое проектирование,
программирование, наполнение баз данных, тестирование, разработка
инструкций для персонала.
Тестирование ИС. На этом этапе оценивается система в целом на
соответствие требованиям ТЗ.
Внедрение системы необходимо проводить в три этапа:
подготовка объекта к внедрению;
опытное внедрение;
сдача проекта в промышленную эксплуатацию.
На этапе подготовки объекта к внедрению планируется провести
следующие работы:
развернуть на сервере базу данных;
установить клиентское ПОна все компьютеры АРМ системы;
56
сконфигурировать взаимодействие АРМ системы с сервером базы
данных;
ввести учетные записи и настроить им права доступа;
заполнить справочники системы реальными данными;
обеспечить пользователей эксплуатационной документацией;
обучить персонал работе с системой.
В процессе внедрения системы участвуют: разработчики системы
(проектировщик, программист), системный администратор и будущие
пользователи системы. Системный администратор должен обеспечить место для
установки нового сервера; подключение к локальной сети для сервера и АРМ
пользователей системы; доступ к компьютерам, необходимым для
развертывания системы, с правами администратора. Проектировщик системы
проводит обучение пользователей, конфигурирует систему, заполняет
справочники, проверяет правильность взаимодействия всех подсистем.
Программист оперативно устраняет возникающие при развертывании системы
неполадки.
Опытная эксплуатация системы должна проводиться не менее 3 месяцев.
В случае обнаружения ошибок на этапе опытной эксплуатации, осуществляется
поиск причин и устранение ошибок, внесение коррективов в программу, в
технологию обработки данных. После устранения ошибок подписывается «Акт о
проведении опытной эксплуатации», который служит началом перехода к
третьему этапу – сдаче системы в промышленную эксплуатацию.
На этапе эксплуатации производятся следующие работы:
периодическая актуализация справочников системы
(осуществляется ответственным за справочник лицом);
периодическое архивирование информационной базы системы на
CD-носителях (администратор системы);
локализация проблем и устранение причин их возникновения
(программист);
модификация ПО (бизнес-аналитик, программист);
57
подготовка предложений по совершенствованию системы
(пользователи системы);
развитие и модернизация системы (бизнес-аналитик, программист).
В настоящее время существует две основные модели жизненного цикла –
это каскадная и спиральная модели. В каскадной модели процесс разработки
идет поэтапно, шаг за шагом. Переход к следующему этапу происходит только
после завершения предыдущего. В спиральной модели разработка проходит по
нарастающей. На начальном этапе разрабатывается система с высоким уровнем
абстракции, а на последующих витках эта разработка все больше и больше
конкретизируется. Для жизненного цикла текущего проекта была выбрана
каскадная модель, так как для разрабатываемой системы больше подходит
поэтапная разработка. Переход к следующему этапу происходит только после
завершения всех работ на предыдущем этапе (рисунок 2.2), включая подготовку
полного пакета документации, достаточной для того, чтобы разработка могла
быть продолжена другой группой разработчиков и есть возможность
планирования сроков завершения работ и затрат на их выполнение.
Рисунок 2.2 - Каскадная схема разработки ПО
Каскадная модель жизненного цикла применяется для построения систем,
где в самом начале разработки можно достаточно точно и полно
сформулировать все требования, с тем, чтобы предоставить разработчикам
свободу реализовывать их как можно лучше с технической точки зрения. Однако
в случае, если в середине разработки вскрываются ошибки, допущенные в
58
начале, то приходится прибегать к энтроверсии проекта, и реальная схема
каскадной модели приобретает другой вид (рисунок 2.3). Таким образом,
каскадная модель более всего подходит к рассматриваемой разработке.
Рисунок 2.3 - Реальный процесс разработки ПО по каскадной
схеме
Существуют следующие основные стратегии внедрения системы:
Параллельная стратегия - когда одновременно работают старая
(ручная) и новая система, и их выходные документы сравниваются. Если они
согласуются длительное время, осуществляется переход на новую систему.
«Скачок». Эта стратегия привлекательна, но не рекомендуется.
«Пилотный проект». Это наиболее часто используемая стратегия.
«Пилотный проект» - это тактика «скачка», но применяемая к ограниченному
числу процессов. Область применения стратегии - небольшой участок
деятельности. Такой подход снижает риск и наиболее надежен. Практически все
предприятия применяют эту тактику сегодня.
«Узкое место». «Узкое место» - это малая часть производственного
процесса. При использовании похода «узкое место» план внедрения
выполняется только для «узкого места» и для людей, работающих в нем.
59
Точность данных повышается только для изделий в этом «узком месте»;
переподготовка- только для людей, работающих в нем; анализ эффект-затрат
делается только для него и т.д.
Для проектируемой системы была выбрана стратегия «узкое место»
поскольку система будет автоматизировать только процесс учета рабочего
времени, внедрение системы будет проводиться только в отделе персонала и
социального развития и на рабочих местах руководителей структурных
подразделений.
2.1.2. Ожидаемые риски на этапах жизненного цикла и их описание
Процессы анализа и сокращения рисков должны сопутствовать основным
этапам разработки и обеспечения жизненного цикла сложных программных
средств в соответствии с международными стандартами[7].
При формулировании постановки задачи и требований к системе могут
возникнуть ошибки и неточности, которые приведут к полному несоответствию
разработанного программного продукта потребностям предприятия. Для
снижения данного риска необходимо привлечь к выполнению задачи наиболее
опытных разработчиков, а также руководство компании.
На этапах проектирования и реализации системы имеются следующие
риски:
ухода одного или группы ключевых специалистов. В этом случае
разработка системы может оказаться под угрозой срыва. Руководству компании
необходимо предпринимать меры для снижения этих рисков, в частности,
обеспечивать более тесное сотрудничество сотрудников, обмен ключевой
информацией, взаимозаменяемость сотрудников.
затягивания процесса разработки, соответственно удорожание
разработки. Для снижения этого риска необходим строгий контроль соблюдения
графика разработки. Привлеченные к разработке ИС специалисты не должны
привлекаться к прочим проектам и заданиям, их рабочее время должно быть
полностью посвящено разработке ИС.
60
изменяющихся требований по ходу работы над проектом, которые
могут нарушить все сроки и оценки. Для снижения этих рисков необходимо
привлечение сотрудников на границах каждого этапа, чтобы обнаруживать
изменения на ранних стадиях работы над проектом системы.
возникновения дефектов программного продукта вследствие ошибок,
допущенных на различных этапах разработки системы. Классификация дефектов
приведена в таблице 2.1.
Таблица 2.1
Характеристики дефектов программного продукта
Этапы возникновения
дефектов и ошибок
Типы первичных дефектов и ошибок
программного средства и
документации
Разработка требований к ПО
Дефекты исходных требований
заказчика
Планирование работ
Дефекты, обусловленные реальной
сложностью проекта
Проектирование архитектуры
системы
Ошибки планирования и системного
проектирования программного средства
Детальное проектирование ПО
Системные и алгоритмические дефекты и
ошибки проекта
Кодирование ПО
Программные дефекты и ошибки
компонентов и документов программного
средства
Тестирование ПО
Программные и алгоритмические ошибки
программного средства и документации
Разработка документации
Дефекты и ошибки обобщающих
документов
На этапе эксплуатации возможны риски, возникающие по следующим
причинам:
1. Злоумышленных, активных воздействий заинтересованных лиц. Для
защиты от внешних угроз необходимо применять средства обеспечения защиты
программ и данных (аутентификация пользователей, защита локальной сети при
помощи межсетевых экранов, применение антивирусных программ и пр.).
2. Случайных негативных проявлений внешней среды, дефектов
системы или ошибочных действий пользователей. Основными источниками
отказовых ситуаций могут быть некорректные исходные требования, сбои и
отказы в аппаратуре, дефекты или ошибки в программах и данных
функциональных задач, проявляющиеся при их исполнении в соответствии с
назначением. При таких воздействиях внешняя, функциональная
61
работоспособность систем может разрушаться не полностью, однако
невозможно полноценное выполнение заданных функций и требований к
качеству информации для потребителей.
Для снижения рисков, связанных с дефектами системы, необходимо
проводить тщательное тестирование на контрольных примерах, приближенных к
действительности. Для снижения рисков, связанных с ошибочными действиями
пользователей, необходимо предусмотреть защиту от применения ошибочных
действий по удалению и порче данных.
2.1.3. Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Под информационной безопасностью (ИБ) АИС понимается состояние
защищенности информационной среды АИС, обеспечивающее её формирование,
использование и развитие, которое не приводит к искажению, разрушению или
несанкционированному использованию информационных ресурсов, включая
хранимую, обрабатываемую и передаваемую информацию, а также
программные средства.
Выделяют следующие основные цели ИБ:
конфиденциальность (доступность информации только
определенному кругу лиц);
доступность (возможность получения информации
авторизованными пользователями в нужное для них время);
целостность (гарантия существования информации в неискаженном,
истинном виде).
Информация, обрабатываемая и сохраняемая в, является ценной:
технологическая. Эта информация не является конфиденциальной,
но в любой момент она должна быть целостной и доступной, иначе работа
остановится, и предприятие понесет убытки.
деловая. Эта информация должна быть конфиденциальной,
доступной и целостной.