62
II Проектная часть
2.1. Разработка проекта автоматизации
2.1.1. Этапы жизненного цикла проекта автоматизации
Жизненный цикл (ЖЦ) программного обеспечения (ПО) ИС представ-
ляет собой непрерывный процесс, начинающийся с момента принятия реше-
ния о создании ИС и заканчивающийся при завершении его эксплуатации.
Под моделью ЖЦ ИС понимается структура, определяющая последова-
тельность выполнения и взаимосвязи процессов, действий и задач на протяже-
нии ЖЦ. Наибольшее распространение получили следующие модели: каскад-
ная, с промежуточным контролем и спиральная. Для нашей модели наиболее
подходит каскадная модель, потому что подразумевает линейную последова-
тельность выполнения стадий создания информационной системы. Другими
словами, переход с одной стадии на другую происходит только после того, как
будет полностью завершена работа на текущей.
Жизненный цикл информационной системы начинается в момент при-
нятия решения о ее создании и заканчивается в момент выведения ее из экс-
плуатации.
Существует международный стандарт, регламентирующий жизненный
цикл информационных систем – ISO/IEC 12207 [15]. Standard for Information
Technology, а также ГОСТ 34.601-90 «Автоматизированные системы. Стадии
создания».
Он определяет структуру жизненного цикла, включая процессы, дей-
ствия и задачи, которые должны быть выполнены во время создания инфор-
мационной системы. Согласно данному стандарту в структуре жизненного
цикла инструментальных средств выделяют следующие этапы:
Проведение предпроектного обследования и анализ данных:
- обследование объекта и обоснование необходимости создания автома-
тизированной системы;
63
- формирование требований пользователя к автоматизированной си-
стеме;
- оформление отчета о выполнении работ и заявки на разработку авто-
матизированной системы.
На данном этапе выявляются все недостатки рассматриваемой области
и выбора метода их устранения.
Проектирование данных – на данном этапе разрабатывается концепция
и ожидаемого результата от внедрения.
Разработка приложений, тестирование, написание документации:
- создание программного обеспечения;
- оформление проектной и эксплуатационной документации;
- подготовка текстовых и учебных материалов.
Внедрение – на данном этапе внедряются все разрабатываемые прило-
жения, обучаются непосредственно сами работники, для которых разрабаты-
вались эти приложения. Все изменения лучше внедрять и поэтапно.
Эксплуатация и сопровождение – этот этап предусматривает дальней-
шую доработку системы при возникновении такой необходимости. После
внедрения изменений в ООО «Эльдорадо» необходимо будет заполнить все
формы, которые ввели.
Также существуют стандарты ГОСТ 34 «Единая автоматизированная си-
стема учета кадров всех государственных предприятий», который устанавли-
вает процесс автоматизации учета кадров на всех стадиях. Стандарт ISO 15288
«Информационная технология. Системная инженерия. Процессы жизненного
цикла систем» устанавливает общие основы для описания жизненного цикла
систем, созданных людьми, определяет детально структурированные про-
цессы и соответствующую терминологию. В настоящем стандарте представ-
лены также процессы, которые поддерживают определение, контроль и совер-
шенствование процессов жизненного цикла внутри организации или в рамках
какого-либо проекта. Настоящий стандарт применим к полному жизненному
циклу системы, включая замысел, разработку, производство, эксплуатацию и
64
снятие с эксплуатации, а также приобретение и поставку систем, осуществля-
емых внутри или вне организации. В настоящем стандарте не детализируются
процессы жизненного цикла в терминах методов и процедур, необходимых
для удовлетворения требований и достижений результатов процесса.
Стандарт MSF [16] (Microsoft Solutions Framework) – это набор принци-
пов и правил деятельности, в некоторой степени ориентированный на проекты
разработки программного обеспечения и развития информационной инфра-
структуры. Ядром MSF являются шесть основных групп моделей:
− модель производственной архитектуры, суть которой – планомер-
ное приведение информационных технологий в соответствие потребностям
бизнеса;
− модель проектной группы, определяющая взаимосвязанные роли
и обязанности участников на разных стадиях выполнения проекта;
− модель процесса, описывающая фазы проекта, контрольные точки
каждой фазы, деятельность участников проектной группы в каждой фазе и ее
результаты;
− модель управления рисками, описывающая порядок выявления
наиболее существенных рисков и упреждающего реагирования на них;
− модель процесса проектирования, описывающая трехфазное про-
ектирование, реализующее продвижение от точки зрения пользователей через
точку зрения проектной группы к точке зрения разработчиков;
− модель приложения, более важная для проектов разработки про-
граммного обеспечения, описывающая метод его разработки как совокупно-
сти сервисов трех уровней: пользовательских, бизнес-логики и данных.
Ранее в документах фирмы Microsoft описывалась и седьмая модель –
модель совокупной стоимости владения (TCO), однако в более свежих мате-
риалах эта модель как часть MSF не упоминается.
Стандарт RUP (Rational Unified Process) – представляет собой программ-
ный продукт, разработанный компанией IBM Rational Software. RUP является
65
результатом объединения подходов Rational Approach и Objectory Process, про-
исшедшего после слияния в 1995 году компаний Rational Software и Objectory
AB (созданной Иваром Якобсоном).
RUP в значительной степени соответствует стандартам и нормативным
документам, связанным с процессами жизненного цикла программного обес-
печения и оценкой технологической зрелости организаций-разработчиков
(ISO 12207, ISO 9000, CMM и др.).
ISO – это стандарт качества любых процессов, будь то выпуск морожен-
ного или разработка программного обеспечения, а CMM – модель качества,
специально соотнесенная с процессом разработки программного обеспечения.
CMM – большой многоступенчатый стандарт качества, охватывающий весь
цикл разработки программного обеспечения: от проектирования и до внедре-
ния. Он годиться и для оптимизации и для улучшения качества выпускаемого
программного обеспечения.
CMM – модель зрелости процессов создания программного обеспече-
ния, или модель развития способности компании разрабатывать качественное
программное обеспечение. Это описательная модель в том смысле, что она
описывает существенные (или ключевые) атрибуты, которые определяют, на
каком уровне технологической зрелости находиться организация. CMM не яв-
ляется предписанием, она не предписывает организации, каким образом раз-
виваться. CMM описывает характеристики организации для каждого из уров-
ней технологической зрелости, не давая каких-либо инструкций как перехо-
дить с уровня на уровень. Организации может потребоваться несколько лет
для перехода с первого уровня на второй и совсем не мало времени для пере-
хода с уровня на уровень далее.
Стандарт COBIT [18] (англиского Control OBjectives for Information
Technology) – задачи управления в информационных технологиях (ИT) и
смежных областях. Является набором стандартов и рекомендаций для аудита
и управления информационными технологиями.
66
Методология управления, контроля и аудита информационных систем
разработана Международной ассоциацией аудита и контроля за информаци-
онными системами (ISACA) и позволяет:
построить работу информационно-технологической службы на процесс-
ной основе;
организовать мониторинг работы информационно-технологической
службы, привязанный к целям и задачам бизнеса;
осуществить сравнение уровня развития информационных технологий с
другими предприятиями отрасли.
Основной принцип CobIT.
Для того чтобы организация обеспечила себя информацией, необходи-
мой для достижения ее целей, она должна инвестировать и управлять инфор-
мационно-технологическими ресурсами (приложениями, информацией, ин-
фраструктурой, людьми), посредством структурированного комплекса про-
цессов, которые обеспечивают сервисы для предоставления информации.
Чтобы удовлетворять бизнес цели информация должна соответствовать
определенным контрольным критериям, которыми CobIT [17] определяет тре-
бования бизнеса к информации:
− полезность;
− эффективность;
− конфиденциальность;
− целостность;
− доступность;
− соответствие требованиям;
− достоверность.
Стандарт делит всю деятельность ИТ на 4 домена (группы или сферы
деятельности), которые включают 34 процесса. При этом, каждый процесс
привязан к ИТ-цели, а каждая ИТ – цель привязана к одной из целей, которые
ставит перед собой бизнес.
Для каждого процесса определены:
67
- ключевые индикаторы достижения цели (KGI) – метрики, которые по-
казывают руководству, достигнуты ли цели бизнеса с помощью ИТ-процесса,
и в какой степени.
- ключевые показатели эффективности (KPI) – метрики, которые пока-
зывают, насколько хорошо работает информационно-технологический про-
цесс.
- степень зрелости процесса – определяется по шкале от ноля до пяти
(пять – высшая оценка, когда процессы усовершенствованы до уровня передо-
вой практики).
Стандарт представляет виды деятельности в сфере ИТ в виде типовой
модели процессов, состоящей из 4 групп:
Планирование и организация (Plan and Organize – PO). Охватывает стра-
тегию, тактику и направление деятельности ИТ для достижения бизнес-целей.
Отвечает на следующие вопросы управления:
Согласованы ли информационно-технологическая стратегия и корпора-
тивная стратегия?
Оптимально ли используются ресурсы компании?
Понимают ли сотрудники цели информационных технологий?
Осуществляется ли управление информационно-технологическими рис-
ками?
Удовлетворяет ли качество систем информационно-технологическим
потребностям?
Приобретение и внедрение (Acquire and Implement – AI). Для воплоще-
ния информационно-технологической стратегии в бизнес-процесс должны
быть интегрированы разработанные или приобретенные информационно-тех-
нологические решения. Отвечает на следующие вопросы:
Предлагают ли новые проекты решения, отвечающие потребностям биз-
неса?
Выполняются ли новые проекты в срок и в рамках бюджета?
Будут ли новые системы после внедрения работать должным образом?
68
Удастся ли внедрить изменения без сбоев текущих бизнес операциях?
Эксплуатация и сопровождение (Deliver and Support – DS). Домен связан
с вопросами текущего представления услуг и включает предоставление услуг,
обеспечение безопасности и непрерывности сервисов, поддержку пользовате-
лей, управление данными. На этом этапе рассматриваются следующие во-
просы:
Предоставляется ли информационные технология услуги в соответствии
с приоритетами бизнеса?
Оптимизированы ли затраты на информационные технологии?
Способен ли информационно-технологический персонал использовать
информационно-технологические системы эффективно и безопасно?
Обеспечивается ли в рамках информационной безопасности должный
уровень конфиденциальности, целостности и доступности?
Мониторинг и оценка (Monitor and Evaluate – ME). Все информационно-
технологические процессы должны регулярно оцениваться на качество и со-
ответствие бизнес-потребностям. Рассматривает следующие вопросы:
Как своевременно выявить проблемы, связанный с эффективностью ин-
формационно-технологических процессов?
Существует ли эффективная система внутреннего контроля?
Как установить обратную связь между эффективностью информацион-
ных технологий и целями бизнеса?
Обеспечивается ли в рамках информационной безопасности должный
уровень конфиденциальности, целостности и доступности?
Для разрабатываемого программного обеспечения больше подходит
стандарт ISO/IEC 12207 и ГОСТ 34.601-90. Эти стандарты имеют набор про-
цессов, действий и задач, охватывающих наиболее широкий спектр возмож-
ных ситуаций при максимальной адаптируемости. Стандарт содержит пре-
дельно мало описаний, направленных на проектирование базы данных. Это
можно считать оправданным, так как разные системы и разные прикладные
комплексы программных обеспечений могут не только использовать весьма
69
специфические типы баз данных, но и не использовать их. Для решения по-
ставленной задачи, нами будет выбрана стандарт ГОСТ 34.601-90 так как
ГОСТ34 и CDM в первую очередь ориентированы на действия по созданию и
поддержке систем, а ISO12207 - на приобретение и эксплуатацию систем, а
разработка является процессом, логически вытекающим из приобретения.
Обследование объекта и обоснование необходимости создания ИС
Рост числа сотрудников, а так же появление строгих требований к со-
блюдению рабочего графика повлекло за собой резкое увеличение нагрузки на
отдел кадров и расчетный отдел, выполняющий планирование отпусков,
нагрузки, развития производства и т.п. Было принято решение внедрить си-
стему автоматического сбора информации с контрольно пропускных пунктов
предприятия, для последующей централизованной обработки их в едином цен-
тре. Функционал существующих на данное время программных продуктов
оказался недостаточным для выполнения всех задач, возлагаемых на автома-
тизированную систему. Было принято решение о создании собственной ин-
формационной системы, полностью удовлетворяющей требованиям и запро-
сам предприятия.
Формирование требований пользователя к ИС
Количество активных держателей карт является одним из основных по-
казателей размера объекта, от него зависит интенсивность потока сообщений,
поступающего от аппаратуры СКУД в ПК, обслуживающий систему. ПК дол-
жен уметь сохранять поток сообщений в базе данных (БД), а также рассылать
их для отображения на рабочих местах со скоростью, превышающей интен-
сивность этого потока. Следует отметить немаловажный момент - сообщения
необходимо не только сохранять в базе, но и выбирать оттуда при построении
отчетов, причем с приемлемой скоростью.
Каждое рабочее место оператора создает определенную нагрузку на си-
стему: при загрузке клиентского приложения на него передаются данные кон-
фигурации из центрального сервера, также на рабочие места производится
рассылка сообщений.
70
В зависимости от назначения рабочие места могут по-разному влиять на
систему. Например, если речь касается КПП с интенсивным гостевым пото-
ком, то рабочее место для регистрации посетителей, с которого постоянно при-
ходится вводить их данные, сохранять фотографии и выдавать карты, может
довольно сильно загружать центральный сервер. Рабочее место оператора де-
журной службы будет запрашивать информацию о состоянии аппаратных эле-
ментов, отображаемых на планах, а также выводить сведения о пользователях,
проходящих через заданную группу считывателей, что потребует подгрузки
фотографий и личных данных пользователя из БД в режиме реального вре-
мени. При этом рабочее место администратора или сотрудника отдела кадров
из-за низкой активности в нормальном режиме вряд ли будет оказывать суще-
ственное воздействие на систему.
В целях снижения требований к квалификации персонала производя-
щего учет в тех местах, где это необходимо, было принято решение упростить
информационную систему и исключить возможность обрабатывать фотогра-
фии и прочие ресурсоемкие процедуры. Это позволило бы снизить затраты
на специалистов и поручить всю работу по обновлению низко квалифициро-
ванному сотруднику.
Изучение объекта и проведение необходимых научно- исследова-
тельских работ.
В целях увеличения производительности подсистемы хранения данных,
а так же уменьшения возможных точек отказа было принято решение о созда-
нии собственного формата хранения данных в бинарном виде. Базы данных,
хранящие информацию о пользователях и о прохождении сотрудником КПП
решено было разнести в разные файлы, для увеличения отказоустойчивости
информационной системы в целом, а так же для увеличения безопасности кон-
фиденциальных данных.
Разработка и адаптация программ
На данном этапе были разработаны следующие решения:
71
Программное средство администратора, необходимое для обработки по-
ступающей на сервер информации.
Эмулятор электронного ключа, предназначенный для тестирования си-
стемы, а так же позволяющий обеспечить в будущем интеграцию электрон-
ного ключа с любым мобильным устройством под управлением Windows.
Подготовка объекта автоматизации и персонала
Объектом автоматизации явились как существующие контрольно про-
пускные пункты, так и вводящиеся в эксплуатацию. Был выполнен анализ ин-
тенсивности потока сотрудников через каждый из КПП и сопоставлена сум-
марная нагрузка на центр обработки данных с расчетной. Кроме этого выпол-
нен анализ подготовленности обслуживающего персонала к контроли и осу-
ществлению помощи сотрудникам в ходе процедуры учета входа или выхода.
Пусконаладочные работы
На данном этапе был произведен перевод основной части серверов на
новую концепцию, постановка их для работы с разработанной информацион-
ной системой и проверка производительности полученного программно-аппа-
ратного комплекса.
Проведение предварительных испытаний
На данном этапе были произведены испытания системы, выявившие не-
которые ее недостатки и недоработки. Были пересмотрены некоторые концеп-
ции и внесены изменения в техническое задание и документацию. После ис-
правления всех недостатков и недоработок были проведены очередные испы-
тания системы, а после чего оформлен акт о приемке автоматизированной
системы учета рабочего времени в опытную эксплуатацию.
Проведение приемочных испытаний
На данном этапе были проанализированы результаты окончательные ис-
пытаний, произведена финальная доработка технического задания и рабочей
документации. После чего был подписан акт об окончательном внедрении си-
стемы на предприятии.
Послегарантийное обслуживание