1.4.3 Обоснование проектных решений по программному обеспечению
Программное обеспечение — комплекс программ:
- обеспечивающих обработку или передачу данных;
- предназначенных для многократного использования и применения разными пользователями.
По видам выполняемых функций программное обеспечение подразделяется на:
- системное;
- прикладное;
- инструментальное [16].
Опираясь на существующую в организации программно-техническую архитектуру (см. рис. 1.8), постараемся обосновать необходимость использования определенных программных средств.
Программное обеспечение – это совокупность программ системы обработки информации и программных документов, необходимых для их эксплуатации.
В качестве операционной системы для проектируемого программного обеспечения должна использоваться операционная система Windows XP Professional Service Pack 3. Операционная система определенна в корпоративных стандартах фирмы. Использование других операционных систем в прикладных решениях для обеспечения бизнес-процессов недопустимо, так как вся ИТ-инфраструктура компании реализована с использованием продуктов Microsoft.
Для используемой операционной системы предъявлены следующие требования:
- Возможность работы со службой каталогов ActiveDirectory Windows Server 2003.
- Обработка групповых политик пользователей и компьютеров.
- Наличие технической возможности использования приложения для удаленного управления ПК Radmin 3.3.
- Использование корпоративного антивирусного ПО.
- Использование единого центра обновления ОС WSUS 3 SP 1.
К системному программному обеспечению, обслуживающему подсистему хранения информации предъявляются следующие требования:
- Разработчик не должен заботиться о реализации механизма хранения данных на носителях ЭВМ.
- Должна существовать формализованная схема доступа к хранимым на носителях данным.
- Используемых механизм хранения данных должен давать возможность логического структурирования данных.
- Должен быть реализован механизм быстрого доступа к любой структуре построенной атомарного набора данных хранимых в подсистеме.
- Необходимо иметь версии соответствующего программного обеспечения под выбранную операционную систему.
- Должен иметься документированный API под выбранную ОС.
- Хранение данных должно осуществляться на том же ПК, на котором запущено приложение.
Исходя из предъявленных требований в качестве подсистемы хранения информации будет выбрана СУБД. В качестве СУБД можно использовать программное обеспечение построенное на архитектуре файл-сервер, клиент- сервер либо встраиваемую СУБД.
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. Ядро СУБД располагается на каждом клиентском компьютере. Доступ к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок.
Преимуществом этой архитектуры является низкая нагрузка на ЦП сервера, а недостатком — высокая загрузка локальной сети. На данный момент файл-серверные СУБД считаются устаревшими. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера.
Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и мало загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по надобности его можно заменить другим. Недостаток клиент-серверных СУБД в самом факте существования сервера (что плохо для локальных программ — в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примеры: Firebird, Interbase, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР. Встраиваемая СУБД — библиотека, которая позволяет унифицированным образом хранить большие объѐмы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объѐмами данных. Примеры: OpenEdge, SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL, Sav Zigzag, Microsoft SQL Server Compact, ЛИНТЕР.
В качестве используемой СУБД будет выбран один из используемых продуктов встраиваемой СУБД. Этот тип СУБД будет использован, потому что нет необходимости реализовывать механизм клиент-сервер. Окончательный выбор продукта будет возможен только после выбора специального ПО для разработки приложений.
Требования для системы разработки приложений:
— Использование объектно-ориентированной архитектуры языка.
— Наличие среды разработки приложений под выбранную операционную систему.
— Наличие стандартных библиотеках под встраиваемые СУБД.
— Возможность создания интуитивно понятного пользовательского интерфейса.
— Простой в освоении язык.
— Отсутствие дополнительного ПО для запуска приложений (фреймворков, run-time библиотек).
Итак, средой разработки, соответствующей указанным выше требованиям будет являться PHP — язык программирования, созданный для генерирования HTML-страниц на веб-сервере и работы с базами данных. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров. Входит в LAMP — распространенный набор для создания веб-сайтов (Linux, Apache, MySQL, PHP (Python или Perl)).
В области программирования для Сети, PHP — один из популярнейших скриптовых языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности и распространению исходных кодов на основе лицензии PHP. PHP отличается наличием ядра и подключаемых модулей, «расширений»: для работы с базами данных, сокетами, динамической графикой, криптографическими библиотеками, документами формата PDF и т. п. Любой желающий может разработать своѐ собственное расширение и подключить его. Существуют сотни расширений, однако в стандартную поставку входит лишь несколько десятков хорошо зарекомендовавших себя. Интерпретатор PHP подключается к веб-серверу либо через модуль, созданный специально для этого сервера (например, для Apache или IIS), либо в качестве CGI-приложения.
Кроме этого, он может использоваться для решения административных задач в операционных системах UNIX, GNU/Linux, Microsoft Windows, Mac OS X и AmigaOS. Однако в таком качестве он не получил распространение, отдавая пальму первенства Perl, Python и VBScript [12].
2 Проектная часть
2.1 Разработка жизненного цикла проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Под понятием жизненный цикл информационной системы принято понимать совокупность стадий и этапов, которые проходит ИС от момента принятия решения о ее создании до полного прекращения ее использования [3].
На практике используется несколько стандартов, описывающих ЖЦ:
- ГОСТ 34.601-90 — стандарт распространяется на автоматизированные системы, используемые в различных видах деятельности (исследование, проектирование, управление и т.п.), включая их сочетания, создаваемые в организациях. Стандарт устанавливает стадии и этапы создания автоматизированной системы [5].
- ISO 12207 — стандарт применяется при приобретении систем, программных продуктов и оказании соответствующих услуг (внедрение, сопровождение); а также при поставке, разработке, эксплуатации и сопровождении программных продуктов и программных компонентов программно-аппаратных средств как в самой организации, так и вне ее.
- ISO 15288 — стандарт обеспечивает общие основы процессов, составляющих жизненной цикл систем, созданных человеком. Этот жизненный цикл охватывает концепции идей вплоть до снятия системы с эксплуатации. Он обеспечивает процессы для приобретения и поставки системы.
- RUP (Rational Unified Process – рациональный унифицированный процесс) — это методология разработки ПО, созданная и распространяемая корпорацией Rational Software (www.rational.com/ rup_info/). Она описывает упорядоченный подход к распределению задач и обязанностей в организации-разработчике.
Для описания этапов жизненного цикла нашей разработки будет использоваться методика Rational Unified Process (RUP) так как она, по нашему мнению, является наиболее подходящей для описания данного проекта.
В основе RUP лежат следующие основные принципы:
- Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.
- Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов).
- Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.
- Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.
- Постоянное обеспечение качества на всех этапах разработки проекта (продукта).
- Работа над проектом в сплоченной команде, ключевая роль в которой принадлежит архитекторам.
Данный стандарт выделяет следующие этапы жизненного цикла информационных систем:
Начало (Inception) На этом этапе:
- Формируются видение и границы проекта.
- Создается экономическое обоснование.
- Определяются основные требования, ограничения и ключевая функциональность продукта.
- Создается базовая версия модели прецедентов.
- Оцениваются риски.
При завершении начальной стадии оценивается достижение вехи целей жизненного цикла, которое предполагает соглашение заинтересованных сторон о продолжении проекта.
Проектирование (Elaboration)
На этапе проектирования производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
- Документирование требований (включая детальное описание для большинства прецедентов).
- Спроектированную, реализованную и оттестированную исполняемую архитектуру.
- Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
- Сниженные основные риски.
Успешное выполнение фазы проектирования означает достижение вехи архитектуры жизненного цикла.
Построение (Construction)
Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial
Operational Capability).
Внедрение (Transition)
Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки [13].
Первой стадией этапа внедрения будет реорганизация информационной инфраструктуры для обеспечения технической возможности развертывания разработанной нами информационной системы. Далее будет проведена подготовка ответственных специалистов на уровне ЦО банка и его филиалов. Подготовка специалистов будет заключаться в разъяснении им общей концепции функционирования внедряемой системы и карт использования ресурсов.
Так же должна быть проведена подготовка специалистов, которые будут заниматься непосредственно внедрением ИС и поддержкой данного процесса. Внедрением системы будут заниматься инженеры ИТ-отделов на вверенных им объектах, а информационной поддержкой – специалисты по ИС банка.
Конечным этапом тестирования будет проверка функционирования внедренной ИС операторами банка при поддержке ИТ-отдела. На данном этапе будет проведена проверка взаимодействия всех логических модулей информационной системы и подготовлен пакет документов по внедрению и тестированию ИС.
2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание
К сожалению, как и в любом другом деле, в процессе жизненного цикла создаваемой нами информационной системы нельзя обойтись без разного рода рисков. Но лучше предотвратить их возникновение, чем устранять последствия. Выделим основные риски, характерные для каждого этапа жизненного цикла нашей информационной системы и обозначим меры их предотвращения.
Начнем с самой первой пред проектной стадии. Для данной стадии характерны такие риски, как:
- Риск персонала со стороны заказчика и исполнителя;
- Риск нарушения методологии ведения проекта.
Рассмотрим каждый из них более подробно.
Итак, среди основных факторов первого риска можно выделить следующий:
- привлечение к проекту неопытных бизнес-аналитиков и ИТ-консультантов;
- включение в команду работы над проектом со стороны заказчика случайных сотрудников, а не ключевых участников бизнес-процессов, подлежащих автоматизации;
- ошибочные выводы, сделанные на основе анализа данных, неверная интерпретация данных, прошедших обработку;
- отсутствие у руководства предприятия единой целостной стратегии в области информационных технологий;
- непонимание руководством основных целей задач проекта;
- стремление скрыть реальные результаты работы того или иного сотрудника со стороны заказчика;
- некомпетентность сотрудников в рамках выполняемой работы;
- неправильный подбор персонала в рабочую группу над проектом;
- отсутствие мотивации и заинтересованности у функциональных менеджеров проекта;
- не налаженная система коммуникаций между участниками рабочей группы;
- негативное отношение персонала к проекту; — необдуманный план ведения работ [7].
Все это может привести к плачевному результату, во избежание чего, можно противопоставить следующее:
- активное вовлечение высшего руководства в проект, активное взаимодействие с ним в ходе проекта и своевременное принятие решений;
- активное участие в проекте ведущих специалистов заказчика, ответственных за исполнение основных процессов;
- четко сформулированные цели и критерии успеха внедренческого проекта;
- участие профессиональных консультантов со стороны заказчика, а также сотрудников предметных подразделений со стороны исполнителя;
- проработка общей стратегии автоматизации предприятия;
- четкое разъяснение целей, материальное стимулирование, пропаганда позитивного примера среди участников на время реализации проекта;
- организация рабочих мест и процедур взаимодействия таким образом, чтобы члены проектной команды могли постоянно и беспрепятственно общаться друг с другом;
- стабильный состав рабочий группы в течение всего проекта;
- отбор людей в проектную команду по принципу их личной заинтересованности в успехе внедрения.
Следующих из выделанных нами на данном этапе жизненного цикла рисков является риск нарушения методологии ведения проекта.
Основным фактором возникновения данного риска является необдуманное описания и утверждения документов, содержащих информацию об интересах сторон и состоянии проекта.
Меры предотвращения этому может послужить:
- четкое определение прав и обязанностей каждого участника;
- компетентность участников проектной группы со стороны заказчика;
- участие профессиональных консультантов;
- заблаговременное обучение рабочей группы и ключевых пользователей;
- своевременные разъяснительные работы для персонала заказчика;
- документирование технических условий и их согласование со всеми заинтересованными участниками проекта;
- обязательное утверждение любых изменений;
- утверждение технического задания, не содержащего избыточных характеристик.
Для стадии проектирования необходимой информационной системы, по нашему мнению, характерны такие риски, как:
- Риск ведения проекта;
- Риск неверного планирования;
- Стоимостной риск; — Форс-мажор.
Основными факторами риска ведения проекта можно назвать следующие:
- неправильное определение рамок и масштабов проекта;
- проектирование ошибочных функций и интерфейсов будущей системы;
- не отлаженная система определения и управления рисками проекта
- выбор неправильных технологий и методов решения поставленных задач;
- несоблюдение требований заказчика при проектирование будущей системы или постоянное изменение требований.
В качестве мер предотвращения, обозначенных выше моментом можно назвать:
- обеспечение стабильности границ проекта, определенных на начальном этапе, вплоть до окончания проекта;
- качественное планирование работ;
- своевременная идентификация проектных рисков и разработка рекомендаций по снижению рисков;
- обеспечение проекта необходимыми ресурсами;
- обязательное утверждение и согласование по проектным решениям;
- дополнительный анализ функций и целей проекта, более тщательная формулировка концепции, разработка руководств пользователя на ранней стадии, проведение опроса пользователей;
- установление достаточно высокого порога принятия изменений;
- использование методологии управления качеством для выявления неизвестных рисков проекта по ходу его выполнения.
Риск неверного планирования может возникнуть в следствие следующих обстоятельств:
- неэффективный организационный план внедрения системы на предприятии, то есть план работы проектной команды с учетом обязанностей, необходимых ресурсов и способов контроля результатов ее работы;
- срыв сроков выполнения работ по данному этапу в силу некомпетентности персонала исполнителя при проектировании.
Мерами предотвращения данных обстоятельств может служить следующее:
- укомплектование проектной команды наиболее талантливыми и квалифицированными проектировщиками;
- распределение работ соответственно способностям членов проектной команды;
- перекрестное обучение и контроль со стороны непосредственных руководителей;
- аудиты на ранних стадиях, конкурентное проектирование и прототипирование, организация командной работы, симуляция и моделирование;
- документирование всех работ на этапе проектирования и обеспечение доступности данных для всех участников проекта;
- разработка системы поощрении и делегирование полномочий между участниками проекта;
- создание и обучение резервных людских ресурсов.
В качестве обстоятельств, способствующих возникновению стоимостного риска можно назвать:
- ошибочное планирование окупаемости системы;
- ошибочное планирование общей стоимости проекта;
- не получение оплаты заказчиком по завершении данного этапа (исключая случаи, относящиеся к непредвиденным ситуациям).
Мерами предотвращения этого является:
- детальная оценка стоимости с использованием нескольких источников;
- соотнесение сложности проектирования с его стоимостью;
- составления поэтапного плана выплат и определение штрафных санкций при задержке.
В качестве основного обстоятельства возникновения форс-мажорных ситуаций можно назвать аварии или отказы в работе аппаратного или программного обеспечения, используемого на этапе проектирования. Мерой предотвращения этому может послужить работа только надежное оборудование (Brand), а также наличие в штате квалифицированных технических специалистов, которые способны в минимальные сроки устранить неисправность.
Как нами уже было отмечено ранее, основным этапом жизненного цикла в рамках данного проекта выступает разработка самой АИС. При этом можно выделить следующие риски:
- Риск персонала и проектных коммуникаций;
- Технический и программный риски.
Основными факторами возникновения первого риска являются:
- зависимость от ключевого персонала;
- увольнение ключевых сотрудников, что повлечет за собой потери для проекта в виде знаний и информации, собранной данными сотрудниками;
- недопонимание между участниками проекта из-за отсутствия налаженной системы коммуникаций и поэтапного документирования работ;
- неправильное понимание задач проектирования программистами, в связи с чем неправильная реализация проекта;
- привлечение программистов без достаточного опыта работы с системами подобного класса.
Основными мерами предотвращения этого служит:
- тщательный отбор персонала, задействованного в данном проекте, обеспечение сертификации, а также организация контроля деятельности персонала их руководителями;
- разделение обязанностей, наличие резерва на выдвижение, обучение перспективных сотрудников, а также документирование накопленных знаний;
- налаженная система коммуникаций между сотрудниками проекта, подробное и четкое документирование требований и доступность проектной документации всем участникам рабочей группы.
Технический и программный риски могут породить:
- частичную или полную приостановку этапа разработки из-за ошибок в используемом программном обеспечение. Последствиями данного риска также может быть частичная или полная потеря созданной на данном этапе информации в виде кода программы;
- контрольный пример не учитывает всех особенностей системы, то есть недостаточно проработан, что может привести к ошибкам на этапе эксплуатации системы;
- документация по системе не включает в себя подробного описания всего функционала системы, что в дальнейшем может привести к возникновению трудностей не этапе эксплуатации.
Этого можно избежать, учитывая:
- использование только проверенного лицензионного программного обеспечения, а также производить регулярное резервное копирование данных на альтернативные источники хранения данных;
- привлечение к тестированию опытных специалистов, многократные проверки и прогоны работоспособности системы для выявления малейших неисправностей в ходе работы;
- проверка документации перед передачей системы заказчику, контроль ее ведения и составления на протяжение всех этапов жизненного цикла ИС.
В процессе внедрения могут возникнуть такие риски, как:
- Риск персонала;
- Технический риск.
Факторами первого риска являются:
- увеличение нагрузки на персонал;
- несогласованность действий персонала исполнителя и сотрудников предметных областей;
- трудности с обучением персонала заказчика из-за нежелания работать с новой системой;
- отсутствие поддержки внедрения ИС со стороны отдельных ключевых участников проекта;
- неучастие руководителей высшего звена в проекте.
Этого можно избежать, путем реализации следующих идей:
- проведение обучения персонала заказчика работы с системой;
- составление плана внедрения ИС;
- доведение до персонала заказчика смысла внедрения автоматизированной системы;
- активное вовлечение высшего руководства в проект, активное взаимодействие с ним в ходе проекта и своевременное принятие решений, необходимых для нормальной реализации проекта.
Основными факторами технического риска являются следующие:
- потеря данных при внедрении ИС;
- возможный отказ технического оборудования при внедрении ИС.
Мерами предупреждения этого служит:
- привлечение квалифицированных технических специалистов, работающих ранее с проектами внедрения ИС, а также их активная работа с техническими специалистами исполнителя;
- использование пилотного, поэтапного — подхода к организации внедрения.
В процессе эксплуатации и сопровождения разработанной ИС могут возникнуть:
- Технические риски;
- Риски персонала.
Факторами технических рисков являются:
- ошибки в программе вызывающие простой системы;
- невозможность осуществления требуемых действия, «зависание» программы;
- использование вредоносных программ (вирусы, черви, трояны, логические бомбы), использование в корыстных целях найденных ошибок (дыр) в программах, перехват информации по телекоммуникациям, воровство информации;
- некорректная эксплуатация оборудования;
- приостановка деятельности третьего лица (например, провайдера Интернет услуг), что повлечет за собой невозможность передачи отчетов из филиалов и контроля деятельности филиалов;
- несоответствие функциональных возможностей системы бизнес-процессам в комплексе задач в следствие реорганизационных изменений.
Предотвратить данные обстоятельства можно, соблюдая следующие моменты:
-тщательное тестирование и выявление ошибок на этапе разработки;
- устранять в кратчайшие сроки ошибки силами прошедших подготовку на этапе внедрения технических специалистов;
- администратор сети должен следить за безопасностью информации, использовать и вовремя обновлять антивирусные программы, правильно настроить FireWall, которые будут разделять локальную и внешнюю сеть, предоставить работникам организации возможность работы только с той информацией, которая им необходима для исполнения своих служебных обязанностей;
- разделение клиентского и серверного оборудования, а также необходимо привлечение обученного работе с системой квалифицированного персонала;
- наличие альтернативных средств доступа в Интернет или других способов передачи данных;
- документирование технических условий и их согласование со всеми заинтересованными участниками проекта;
- обязательное утверждение любых изменений.
Факторами возникновения риска персонала являются следующие обстоятельства:
- нарушение информационной безопасности работы — возможна утечка информации из-за злоумышленных действий сотрудников и не желании работать с новой системой;
- не определен этап выхода их проекта консультантов заказчика.
В противовес этому может выступать:
- организация системы поощрений использующего систему персонала заказчика;
- прием на работу сотрудников при условии неразглашения коммерческой тайны в противном случае — применение штрафных санкций;
- четкое планирование сроков проекта и момента прекращения работы над проектом со стороны исполнителя.
Таким образом, нам удалось определить основные риски, которые могут возникнуть на каждом из этапов жизненного цикла нашей информационной системы, определить факторы их возникновения, а также привести рекомендации по их предотвращению.