47
Windows Server 2012
(x64-bit)
Windows Server 2008 R2
(x64-bit)
Windows Server 2008
(x64-bit)
Windows Server 2003
(x64-bit)
Windows Vista (x64-bit)
Windows XP (x64-bit)
рекомендуется установка
пакета обновлений 2
(SP2)
Для Windows XP (x64-
bit) рекомендуется
установка пакета обнов-
лений 1 (SP1)
Linux (*)
ASP Linux 11 и выше
CentOS 4 и выше
Debian GNU/Linux 4.0 и
выше
Fedora Core 4 и выше
Fedora 7 и выше
Mandriva Powerpack 2009
Red Hat Enterprise Linux
4 update 4 и выше
Ubuntu 7.10 и выше
только на рабочих и цен-
тральных серверах кла-
стера
48
Требования к операционной системе сервера баз данных представлена в
Таблице 1.15.
Таблица 1.15
Требования к техническому обеспечению
СУБД
Примечания
Microsoft SQL Server
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2005
SQL Server 2000
Для SQL Server 2008 тре-
буется установка пакета
обновлений 1 (SP1)
Для SQL Server 2005 тре-
буется установка пакета
обновлений 3 (SP3)
Для SQL Server 2000
рекомендуется установка
пакета обновлений 4
(SP4)
требуется установка па-
кета обновлений 2 (SP2)
рекомендуется использо-
вать SQL Server 2005 и
выше
PostgreSQL(*)
PostgreSQL 9.2.4
PostgreSQL 9.1.9
PostgreSQL 9.1.2
PostgreSQL 9.0.3
PostgreSQL 8.4.3
PostgreSQL 8.3.8
PostgreSQL 8.2.4
PostgreSQL 8.1.5
IBM DB2
IBM DB2 10.1
IBM DB2 9.7 FixPack 6
49
IBM DB2 9.7 FixPack 1
IBM DB2 9.5 FixPack 4
(сборка 22521)
IBM DB2 9.1 (сборка
19840)
Oracle Database
(редакции Standard Edi-
tion One, Standard Edition
и Enterprise Edition)
Oracle Database 11gR2
Oracle Database 11gR1
(Версия 11.1.0.7.0)
Oracle Database 10gR2
(Версия 10.2.0.4)
Microsoft Windows вер-
сия 10.2.0.4 поддержива-
ется при условии уста-
новки патча Bundle36
(patch 9544021).
Linux Версия 10.2.0.4
поддерживается при
условии установки сле-
дующего набора патчей:
8576156, 9535703,
9038070, 9002115,
6642692, 8889930,
7556778, 5586604.
50
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл информационной системы – это период создания и ис-
пользования ЭИС, охватывающий её различные состояния, начиная с момента
возникновения необходимости в данной ЭИС и заканчивая моментом её полного
выхода из употребления у пользователей [9].
На данный момент, наиболее распространенными стандартами, регламен-
тирующими жизненный цикл информационных систем, являются:
серия стандартов ГОСТ 34 (ГОСТ 34.601-90 «Автоматизированные си-
стемы Стадии создания»),
ISO 12207 «Standard for Information Technoiogy - Software Life Cycle Pro-
cesses»,
ISO 15288 «Standard for Information Technoiogy - System Life Cycle Pro-
cesses».
В процессе дипломного проектирования будет использоваться стандарт
жизненного цикла ISO 12207. Этот стандарт является основным нормативным до-
кументом, регламентирующим состав процессов жизненного цикла ПО. Он опре-
деляет структуру жизненного цикла, содержащую процессы, действия и задачи,
которые должны быть выполнены во время создания ПО. Каждый процесс разде-
лен на набор действий, каждое действие - на набор задач. Каждый процесс, дей-
ствие или задача инициируется и выполняется другим процессом по мере необхо-
димости, причем не существует заранее определенных последовательностей вы-
полнения. Связи по входным данным при этом сохраняются.
Рассмотрим этапы жизненного цикла разрабатываемой информационной
системы, в соответствии с выбранным стандартом жизненного цикла:
Этап разработки и внедрения состоит из работ и задач, выполняемых
разработчиком (на начальных этапах и заказчиком). Основными целями данного
этапа является: разработка технического задания (ТЗ) на информационную си-
стему; преобразование требований ТЗ в детальные спецификации информацион-
ной системы; собственно, разработка и тестирование программного продукта.
51
Этап эксплуатации состоит из работ и задач оператора. Этап охваты-
вает эксплуатацию программного продукта и поддержку пользователей в про-
цессе эксплуатации.
Этап сопровождения состоит из работ и задач, выполняемых персо-
налом сопровождения. Данный этап реализуется при изменениях (модификациях)
программного продукта и соответствующей документации, вызванных возник-
шими проблемами или потребностями в модернизации или настройке. Целью
этапа является изменение существующего программного продукта при сохране-
нии его целостности. Данный этап охватывает вопросы переносимости и снятия
программного продукта с эксплуатации. Заканчивается этап снятием программ-
ного продукта с эксплуатации.
Рассмотрим модель жизненного цикла разрабатываемого программного
обеспечения для автоматизации учета рабочего времени сотрудников в АО «Сель-
энергопроект». Наиболее походящей для реализации функций разрабатываемой
системы является каскадная модель. Это обусловлено следующими ее преимуще-
ствами:
на каждом этапе формируется законченный набор проектной документа-
ции, отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют пла-
нировать сроки завершения всех работ и соответствующие затраты.
Представим модель жизненного цикла разрабатываемой системы в виде
ряда последовательно выполняемых этапов. Среди этих этапов обычно выделя-
ются следующие:
– определение потребностей;
– исследование и описание основных концепций;
– проектирование и разработка;
– испытания системы;
– создание и производство;
– внедрение;
– распространение и продажа;
– эксплуатация;
– сопровождение и мониторинг;
52
– снятие с эксплуатации (утилизация).
Проведенный анализ характеристик компании АО «Сельэнергопроект» и
основных бизнес-процессов однозначно определяет потребность в такой автома-
тизированной системе.
Бизнес-процессы в рассматриваемой компании связаны с движением мате-
риальных средств, и неправильный учет, которых может привести к материаль-
ным потерям и другим существенным недостаткам. Поэтому разработка системы
заканчивается проведением этапа испытаний разработанной автоматизированной
системы АО «Сельэнергопроект».
Таким образом, каскадная модель жизненного цикла более всего подходит
к конкретной разработке.
Процесс внедрения — трансформация описания разработки программного
проекта в программный продукт, а также создание исходного кода, баз данных и
документации независимо от того, были ли эти программные продукты разрабо-
таны, приобретены либо имеют смешанное происхождение.
На сегодняшний день существуют следующие основные стратегии внедре-
ния системы.
1. Параллельная стратегия. При этой стратегии одновременно работают
старая (ручная) и новая система, и их выходные документы сравниваются. Если
они согласуются длительное время, осуществляется переход на новую систему.
2. «Скачок». При такой стратегии происходит моментальный переход на
работу с новой системой. Эта стратегия привлекательна, но не рекомендуется.
3. «Пилотный проект». Это наиболее часто используемая стратегия. «Пи-
лотный проект» — это тактика «скачка», но применяемая к ограниченному числу
процессов. Область применения стратегии - небольшой участок деятельности. Та-
кой подход снижает риск и наиболее надежен. Практически все предприятия при-
меняют эту тактику сегодня.
4. «Узкое место». «Узкое место» — это малая часть производственного про-
цесса. При использовании подхода «узкое место» план внедрения выполняется
только для «узкого места» и для людей, работающих в нем. Точность данных по-
вышается только для изделий в этом «узком месте"; переподготовка - только для
людей, работающих в нем, анализ эффект - затрат делается только для него и т.д.
53
В качестве стратегии внедрения ИС был выбран пилотный проект. Данная
стратегия внедрения информационной системы была выбрана, так как при ней ав-
томатизируется ограниченное число процессов и поэтому риски сведены к мини-
муму.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
В процессе жизненного цикла разрабатываемой информационной системы
всегда существует вероятность возникновения различного рода рисков, влияю-
щих, как и на процесс разработки, так и на функционирование школы. Рассмотрим
ожидаемые риски по этапам жизненного цикла подробнее:
Этапы разработки и внедрения.
o Риск нарушения методологии ведения проекта. Причиной возникно-
вения данного риска может служить необдуманное описание и утверждение до-
кументов, содержащих информацию о состоянии проекта.
Меры предотвращения этому может послужить:
четкое определение прав и обязанностей рабочей группы;
обучение рабочей группы и ключевых пользователей;
документирование и согласование технических условий проекта;
документальное подтверждение вносимых изменений в проект;
o Риск ведения проекта:
неправильное определение рамок и масштабов проекта;
проектирование ошибочных функций и интерфейсов будущей си-
стемы;
выбор неправильных технологий и методов решения поставленных
задач;
несоблюдение требований при проектирование будущей системы
или постоянное изменение требований.
В качестве мер предотвращения, обозначенных выше моментом можно
назвать:
обеспечение стабильности границ проекта, определенных на началь-
ном этапе;
54
качественное планирование работ;
обеспечение проекта необходимыми ресурсами;
обязательное утверждение и согласование по проектным решениям;
дополнительный анализ функций и целей проекта, тщательная фор-
мулировка концепции;
o Риск неверного планирования:
плохая проработка плана внедрения системы;
срыв сроков выполнения;
Мерами предотвращения данных обстоятельств может служить следую-
щее:
укомплектование проектной команды наиболее талантливыми и ква-
лифицированными проектировщиками;
распределение работ соответственно способностям членов проект-
ной команды;
документирование всех работ на этапе проектирования и обеспече-
ние доступности данных для всех участников проекта;
o Технический и программный риски вызывают:
частичную или полную приостановку этапа разработки из-за ошибок
в используемом программном обеспечении;
частичная или полная потеря программного кода;
контрольный пример не учитывает всех особенностей системы, то
есть недостаточно проработан;
документация по системе не включает в себя подробного описания
всего функционала системы.
Этого можно избежать следующим образом:
использовать лицензионного программное обеспечение;
производить регулярное резервное копирование данных;
проводить многократные проверки и прогоны работоспособности си-
стемы для выявления малейших неисправностей в ходе работы;
проверка документации перед передачей системы в эксплуатацию.
Этапы эксплуатации:
o Риск персонала;
55
трудности с обучением персонала из-за нежелания работать с новой
системой;
отсутствие поддержки внедрения ИС со стороны отдельных ключе-
вых участников проекта;
неучастие руководителей высшего звена в проекте;
нарушение информационной безопасности в процессе работы си-
стемы.
Этого можно избежать, путем реализации следующих идей:
проведение обучения персонала работы с системой;
составление плана внедрения ИС;
доведение до персонала смысла внедрения автоматизированной си-
стемы;
активное вовлечение высшего руководства;
организация системы поощрений использующего систему персонала
заказчика.
o Технический риск:
потеря данных при внедрении ИС;
возможный отказ технического оборудования при внедрении ИС;
ошибки в программе, вызывающие простой системы;
невозможность осуществления требуемых действия, «зависание»
программы;
использование вредоносных программ (вирусы, черви, трояны, логи-
ческие бомбы), использование в корыстных целях найденных ошибок;
приостановка деятельности третьего лица (например, провайдера
Интернет-услуг);
Мерами предупреждения этого служит:
использование пилотного, поэтапного -подхода к организации внед-
рения;
тщательное тестирование и выявление ошибок на этапе разработки;
устранять в кратчайшие сроки ошибки;
наличие альтернативных средств доступа в Интернет или других спо-
собов передачи данных;
56
обязательное утверждение любых изменений системы.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Для обеспечения информационной безопасности и защиты информации
необходимо реализовывать следующие меры обеспечения информационной без-
опасности:
Законодательные (законы, нормативные акты и т.д.);
Административные (действия общего характера, предпринимаемые руко-
водством);
Процедурные (конкретные меры безопасности, принимаемые сотрудни-
ками);
Программно-технические.
В АО «Сельэнергопроект» используются следующие законодательные и
нормативно-технические акты в области информационной безопасности:
Закон «Об информации, информатизации и защите информации»;
Закон «О государственной тайне»
статьи Уголовного кодекса РФ (глава 28: статья 272 «Неправомерный до-
ступ к компьютерной информации», статья 273 «Создание, использование
и распространение вредоносных программ для ЭВМ», статья 274 «Нару-
шение правил эксплуатации ЭВМ, системы ЭВМ или их сети»).
Доктрина информационной безопасности РФ, утвержденная Президентом
РФ в 2000 г. [6].
Для защиты от внутренних угроз в системе используется политика разделе-
ния прав доступа. Характеристика политики приведена в таблице 2.1.