57
устройства передачи данных и линий связи;
оргтехника и устройства автоматического съема информации;
эксплуатационные материалы и др.
Разрабатываемый программный продукт имеет клиент-
серверную архитектуру.
Для корректного взаимодействия компонентов клиент-серверной
архитектуры между собой требуется их соответствие некоторым основным
правилам. Эти правила должны в равной степени выполнять и клиенты, и
серверы, и ППО.
Эксплуатация разрабатываемой системя должна производиться на
рабочих станциях следующей конфигурации:
операционная система — Linux, Windows, FreeBSD, Mac OS X,
Solaris;
процессор — Pentium/Celeron/Athlon 1000-1800 МГц;
память (ОЗУ) — 1024 Мб;
жесткий диск — не менее 200 МБ свободного места (для установки
программного обеспечения);
монитор — позволяющий работать с разрешением экрана не менее
1152x864 пикселей;
устройства ввода информации (клавиатура, мышь);
дополнительное программное обеспечение — Oracle Java SE
Runtime Environment (JRE) 7.
Однако для сервера баз данных понадобится более мощное техническое
обеспечение:
операционная система — FreeBSD, Linux, Mac OS X, Solaris,
Windows Server;
процессор — Pentium/Celeron/Athlon 2400-3000 МГц;
память (ОЗУ) — 2024-3072 Мб;
жесткий диск — определяется объемом базы данных;
устройства ввода информации (клавиатура, мышь).
58
2 Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) информационной системы - период времени,
который начинается с момента принятия решения о необходимости создания ИС
и заканчивается в момент ее полного изъятия из эксплуатации.
Ниже приведено описание основных стандартов жизненного цикла:
ГОСТ 34.601-90 – стандарт распространяется на автоматизированные
системы и определяет стадии и этапы их создания. Также в стандарте
содержится описание состава работ по каждому этапу.
ISO 12207 – стандарт устанавливает общую структуру процессов
жизненного цикла. Так же определяет процессы, работы и задачи, которые
используются: при приобретении системы в целом или отдельного программного
продукта; при оказании программной услуги, а также при поставке, разработке,
эксплуатации и сопровождении программных продуктов.
Oracle CDM (Custom Development Method) - стандарт по разработке
прикладных ИС, детализированный до уровня заготовки проектной
документации. Стандарт применяется при разработке с применением Oracle и
рекомендуется в случае малых проектов.
RUP (Rational Unified Process) – предполагает итеративную модель
разработки согласно четырем фазам: начало, исследование, построение и
внедрение. Каждая фаза может подразделяться на этапы, в результате
выполнения которых выпускается версия для внутреннего или внешнего
использования.
MSF (Microsoft Solution Framework) – стандарт, сходный с RUP. Включает
в себя четыре фазы: анализ, проектирование, разработка и стабилизация. Также
как и RUP предполагает итеративную модель с использованием объектно-
ориентированного моделирования. MSF в отличии от RUP ориентирована более
на разработку бизнес-приложений.
XP (Extreme Programming) – стандарт «экстремальное программирование»
разработан в 1996 года, в его основе лежат следующие принципы: командная
59
работа, эффективная коммуникация между заказчиком и исполнителем и также
ведение разработок с использованием последовательно дорабатываемых
прототипов.
Для реализации проектного решения, необходимо первоначально
выделить основные этапы жизненного цикла будущей системы. Из всех
имеющихся стандартов, наиболее оптимальным будет ISO 12207 -2010
Информационная технология. Системная и программная инженерия. Процессы
жизненного цикла программных средств [2].
Выбор пал именно на этот стандарт, в связи со следующими факторами:
Во-первых, стандарт четкое не регламентирует последовательность процессов в
каждом этапе, что позволяет самостоятельно выбирать подходящие для себя
процессы. Во-вторых, стандарт охватывает все этапы более полно, нежели
остальные стандарты. В-третьих, ISO 12207-99 не указывает на этапы, а лишь
регламентирует их, что позволит разработчику самостоятельно управлять
жизненным циклом.
В отличие от стандарта ISO 12207-99, включающего всего 16 процессов,
объединенных в 3 группы, стандарт ISO 12207-2010 более детализирован и
включает 43 процесса, объединенных в 6 групп (рисунок 2.1).
Результаты процесса используются для демонстрации успешного
достижения цели процесса, что помогает оценщикам процесса определять эти
результаты и возможности реализованного процесса. А также предоставлять
исходные материалы для анализа организационных процессов и планирования
их улучшений.
В общем случае совокупность процессов, представленная в стандарте ISO
12207-2010, приспособлена к программных средствам или вкладам в результаты
процессов, предусмотренных в ИСО/МЭК 15288:2007 (ISO|IEC 15288^2007)
Системная инженерия. Процессы жизненного цикла систем. Многие процессы из
ИСО/МЭК 15288:2007 подобны реализациям процессов, специфических для
программных средств, однако сохраняют, важные различия, вытекающие из
целей, результатов и аудиторий.
60
Рисунок 2.1 Группы процессов ЖЦ стандарта ISO 12207-2010
Процессы состоят из отдельных видов деятельности. Всего стандартом
определенно 74 вида деятельности, связанной с разработкой и поддержкой ПО.
Каждый вид деятельности в свою очередь нацелен на выполнение одной или
нескольких задач.
Основной процесс жизненного цикла систем состоит из 4 видов
деятельности. Каждый процесс определяет основного исполнителя и действия,
которые необходимо выполнить в назначенные сроки. Краткое описание целей
этих видов деятельности представлено в таблице 2.1.
61
Таблица 2.1
Основные процессы жизненного цикла систем
Наименование
процесса
Цель процесса
1 Процессы соглашения
1.1 Процесс
приобретения
Получение продукта и (или) услуги в соответствии с
потребностями приобретающей стороны
1.2 Процесс поставки
Обеспечение приобретающей стороны продукцией
или услугой, удовлетворяющей согласованным
требованиям
2 Процессы организационного обеспечения проекта
2.1 Процесс
менеджмента модели
жизненного цикла
Определение, сопровождение и обеспечение
гарантии наличия политик, процессов жизненного
цикла, моделей жизненного цикла и процедур для
использования организацией в пределах области
применения настоящего стандарта
2.2 Процесс
менеджмента
инфраструктуры
Снабжение проекта обеспечивающей
инфраструктурой и услугами для поддержки
организации и целей проекта в течение всего
жизненного цикла
2.3 Процесс
менеджмента
портфеля проектов
Инициации и поддержке необходимых, достаточных
и подходящих проектов для выполнения
стратегических целей организации
2.4 Процесс
менеджмента людских
ресурсов
Обеспечение организации необходимыми людскими
ресурсами и поддержание их компетентности
согласно потребностям деловой деятельности
2.5 Процесс
менеджмента
качества
Обеспечение гарантии того, что продукты, услуги и
реализации процессов жизненного цикла
соответствуют целям организации в области
качества и удовлетворяют заказчика
3 Процессы проекта
3.1 Процесс
планирования
проекта
Составление и доведение до заинтересованных
сторон эффективного и выполнимого плана.
3.2 Оценка проекта и
процесс управления
Определение состояния проекта и гарантии того,
что проект выполняется в соответствии с планами и
графиками работ в пределах бюджета и
удовлетворяет техническим параметрам.
3.3 Процесс
менеджмента
решений
Выбор из существующих альтернатив наиболее
предпочтительного направления проектных
действий.
3.4 Процесс
менеджмента рисков
Постоянное определение, анализ, обработка и
мониторинг рисков, связанных с приобретением,
разработкой, сопровождением или применением
системы.
3.5 Процесс
менеджмента
конфигурации
Установление и поддержание целостности всех
идентифицированных выходных результатов
проекта или процесса обеспечения доступа к ним
любой заинтересованной стороны
62
Продолжение таблицы 2.1
3.6 Процесс
менеджмента
информации
Своевременное предоставление заинтересованным
сторонам релевантной, своевременной, полной,
достоверной и, если требуется, конфиденциальной
информации в течение и соответственно после
завершения жизненного цикла системы
3.7 Процесс
измерений
Сбор, анализ и составление отчетов о данных,
относящихся к разработанным продуктам и
процессам, реализованным в пределах
определенного организационного подразделения,
для поддержки эффективного менеджмента
процессов и объективной демонстрации качества
этих продуктов.
4 Технические процессы
4.1 Процесс
определения
требований
правообладателей
Выявление требований к системе, выполнение
которых может обеспечивать предоставление услуг,
необходимых пользователям и другим
правообладателям в заданной среде применения
4.2 Процесс анализа
системных
требований
Преобразование определенных требований
правообладателей в совокупность необходимых
системных технических требований, которыми будут
руководствоваться в проекте системы.
4.3 Процесс
проектирования
архитектуры системы
Определение того, как системные требования
следует распределить относительно элементов
системы.
4.4 Процесс
реализации
Создании заданных элементов системы.
4.5 Процесс
комплексирования
системы
Объединение системных элементов (включая
составные части технических и программных
средств, ручные операции и другие системы, при
необходимости) для производства полной системы,
которая будет удовлетворять системному проекту и
ожиданиям заказчика, выраженным в системных
требованиях.
4.6 Процесс
квалификационного
тестирования системы
Подтверждение того, что реализация каждого
системного требования тестируется на соответствие
и система готова к поставке
4.7 Процесс
инсталляции
программных средств
Установка программного продукта,
удовлетворяющего заданным требованиям, в
целевую среду применения.
4.8 Процесс
поддержки приемки
программных средств
Содействие приобретающей стороне в обеспечении
уверенности в том, что продукт соответствует
заданным требованиям
4.9 Процесс
функционирования
программных средств
Применение программного продукта в
предназначенной для него среде и обеспечении
поддержки заказчиков программного продукта
4.10 Процесс
сопровождения
программных средств
Обеспечение эффективной по затратам поддержки
поставляемого программного продукта.
4.11 Процесс
Обеспечение завершения существования системного
63
прекращения
применения
программных средств
программного объекта
Существует 4 основных способа начала использования новой системы
Параллельная стратегия;
Скачок;
Узкое место;
Опытная эксплуатация "пилотного проекта.
Параллельная стратегия не аподходит, так как компания не располагает
достаточными ресурсами для ведения учета одновременно в
автоматизированном и ручном вариантах. Стратегия Скачек не позволяет плавно
перейти на использование разработки, узкое место больше подходит для
использования в крупных компаниях. Поэтому в качестве стратегии внедрения
ИС была выбрана «Опытная эксплуатация пилотного проекта».
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
На каждом этапе жизненного цикла ИС есть различные риски. Они
приводят как к серьезным неустойкам во в процессе разработки системы, так и в
ее функциональных возможностях.
Далее будут представлены риски в зависимости от процессов ЖЦ, а также
возможные методы их предотвращения.
Процесс подготовки проекта
Риск персонала
Риски:
• Набор необученного персонала к выполнению проекта;
• Набор в группу разработчиков «случайных» сотрудников, а не
главных участников автоматизируемых процессов производства;
• Неимение выработанной стратегии автоматизации;
• Несогласованность в общих целях и задачах проекта;
• Отсутствие мотивационных поощрений сотрудникам;
• Нежелание персонала участвовать в проекте;
• Хаотичный план ведения работ.
64
Методики предотвращения:
• Постоянное взаимодействие с руководством в процессе всего
проекта, оперативное принятие решений;
• Привлечение к проекту ведущих специалистов и консультантов;
• Четкая формулировка целей и задач;
• Выработка определённой стратегии автоматизации компании;
• Неизменный состав рабочей группы во время подготовки проекта.
Риск ведения проекта
Риски:
• Ошибочная установка границ и масштаба проекта;
• Выделение ошибочных функций системы;
• Подбор неверных технологий и методологий решений задач;
• Несоблюдение приведенных заказчиком требований.
Методики предотвращения:
• Поддержка стабильности границ проекта, которые выделяются еще
на начальном этапе и неизменны вплоть до финала проекта;
• Точное планирование выполняемых работ;
• Включение в проект необходимых ресурсов;
• Согласованное и утвержденное проектное решение;
• Высокий порог принятия изменений.
Риск неверного планирования
Риски:
• Малоэффективный план организации разработки системы;
• Несоблюдение сроков реализации работ по этапам.
Методики предотвращения:
• В начальных стадиях проекта проведение учета, организация
командной работы, выделение ролей и стимулирование;
• Описание и сохранение всех проведенных работ и открытый доступ
к этим данным для всех участников проекта.
Процесс разработки
Риск персонала
Риски:
65
• Увольнение сотрудников, которые отвечают за проведение
разработки;
• Несогласованность действий между участниками проекта из-за
плохой системы коммуникации;
• Ошибочное представление задачи проектирования;
• Набор разработчиком без опыта работы с подобными системами.
Методики предотвращения:
• Грамотный набор сотрудников, участвующих в проекте;
• Реализация четкой системы взаимодействия между сотрудниками,
полное документирование изменений в системе.
Технические риски
Риски:
• Остановка разработки из-за ошибок в применяемом ПО;
• Пользовательская документация состоит из описания лишь
некоторых функций системы.
Методики предотвращения:
• Работа только с проверенным лицензионным ПО, регулярное
резервное копирование данных;
• Отслеживание полноты сведений во всех документах.
Процесс внедрения
Риск персонала
Риски:
• Разрозненность деятельности разработчиков и экспертов
предметной области;
• Отсутствие желания у сотрудников использовать новую систему и
связанные с этим сложности их обучения;
• Безучастность руководства.
Методики предотвращения:
• Обучение пользователей со стороны заказчика методики работы с
системой;
• Подготовка плана внедрения системы;
• Обоснование важности и нужности автоматизации персоналу;
66
• Привлечение руководящего персонала в проект и активное
взаимодействие с ним во время проведения всего проекта.
Технические риски
Риски:
• Утрата информации при внедрении системы.
Методики предотвращения:
• Наем квалифицированных сотрудников, которые имеют опыт
разработки подобных систем.
Процесс эксплуатации и сопровождения
Технические риски
Риски:
• Баги и ошибки ПО, приводящие к невозможности использования
системы;
• Неправильное использование оборудования;
• Отсутствие функциональных возможностей системы из-за
реорганизации предприятия.
Методики предотвращения:
• Полноценное тестирование и дополнение во время разработки
системы;
• Описание и занесение в документы всех технических условий и их
согласование.
2.1.3 Организационно-правовые и программно-аппаратные средства
обеспечения информационной безопасности и защиты информации
Комплекс мер по защите информации в разрабатываемой системе
включает в себя следующие аспекты:
защита информации непосредственно в информационной системе от
внутренних угроз;
защита информации от внешних угроз.
Для защиты от внутренних угроз в системе используется политика
разделения прав доступа. Характеристика политики приведена в таблице 2.2.