Способы внедрения информационной системы

Организация процессов производства информационных систем. Часть 4. Внедрение информационной системы

IX Внедрение информационной системы

Нет ничего труднее, опаснее и неопределённее, чем руководить введением нового порядка вещей, потому что у каждого нововведения есть ярые враги, которым хорошо жилось по старому, и вялые сторонники, которые не уверены, смогут ли они жить по новому.
Н. Макиавелли

И вот интересная и насыщенная творчеством, прожектерством, креативом и созиданием часть в проекте подходит к концу. Начинаются суровые будни защиты своего решения в реальной атмосфере конкретного предприятия, и что не мало важно, все также в рамках действующего законодательства.

Для начала реализованный продукт необходимо развернуть на оборудовании, уготовленном для организации его опытной эксплуатации.

1. Развертывание системы на площадке опытной эксплуатации

В соответствии с спроектированной технологической архитектурой, отраженной в документации, закупается серверное, коммуникационное и прочее оборудование, а также системное ПО. Компоненты информационной системы монтируются в единый программно-аппаратный комплекс, на площадках, на которых планируется его промышленное использование.

Ввиду того, что в крупных проектах, задействовано большое количество оборудования на котором ПО разбросано по нодам, узлам и даже облакам, то этот процесс необходимо сопровождать полномасштабным документированием. Например, в техдокументацию включаются таблицы с адресами серверов, рабочих мест, способов доступа и т.п. Для визуального представления используются диаграммы компонентов, дающие понимание расположения узлов сети, распределения компонентов их взаимодействия и т.п. А ведь еще должны быть определены мероприятия, регламентирующие всевозможные изменения в инфраструктуре, позволяющие устранить последствия отказов различных элементов системы.

Рисунок 19. – Пример технического описания этапа внедрения

Это все чрезвычайно важно, поскольку следующим этапом на этих эксплуатационных площадках начнет толкаться множество специалистов команды внедрения и поддержки, и они не должны каждый раз выуживать необходимую для работы информацию из разных, пускай даже информированных источников. А потому, документация должна поддерживаться в актуальном состоянии и меняться одновременно с изменениями в настройках системы, изменениями архитектурного решения и т.п.

Нелишне на «боевых» площадках для промышленной эксплуатации системы, разворачивать и тестовые стенды, имитирующие работу, приближенную к реальной. Ну вдруг еще будут замечания, требующие выпуска новых релизов. Все конечно профессионалы, ответственные люди и всякое такое, но все же обновления лучше сперва погонять на тестовом стенде. Так на всякий случай.

Между тем 90% времени уже пролетело…

2. Обучение персонала заказчика работе с информационной системой

Как уже неоднократно упоминалось, в больших проектах особое внимание уделяется качеству документации, включая и инструкции пользователей системы. Чаще всего инструкции пользователей делятся на сегменты по видам деятельности, специализации и т.п. Это позволяет акцентировать внимание в документе на важные моменты и не грузить пользователей ненужной для них информацией.

Поскольку в обучении может быть задействовано значительное количество различных сотрудников заказчика, которые в свою очередь, для обеспечения непрерывности деловых процессов не могут обучаться в одно и то же время, которые должны обучаться различным функциональным обязанностям и по прочим уважительным причинам, необходимо тщательно планировать процесс подготовки персонала. Также полезно разбивать обучающихся на группы по категориям, требующим использование различных подходов и глубины обучения, исходя из уровня их первоначальной подготовленности. В итоге, составленный план-график обучения должен быть согласован со всеми заинтересованными лицами, и утвержден руководством заказчика, как обязательный к исполнению.

А мы на этапе проектирования предупреждали, что обучение персонала заказчика не только очень ответственная задача, но еще и очень трудоемкая…

3. Выявление недостатков и дефектов информационной системы

Очень часто в больших проектах, тестирование финального релиза не позволяет выявить все проблемные места решения. Причиной тому могут быть: огромные объемы данных на деле в «боевых» условиях, проявление уникальных сочетаний бизнес правил в реальных деловых процессах, особенности работы конкретного оборудования, специфические сочетания компонентов системы, балансирование нагрузки между распределенными узлами и т.п.

Зачастую ситуация еще осложняется тем, что внедрение новых систем на начальных стадиях ни в коей мере не отменяет необходимость производить работы на старых системах. То есть пользователи дублируют данные в обоих системах. Иногда требуется миграция существующих актуальных данных из устаревших хранилищ в новые, а структура и формат информации обычно весьма и весьма отличаются. Например, если в новой структуре данных не хватает информации для заполнения обязательных реквизитов, они заполняются какими-то данными назначенными «по умолчанию», а потом уже корректируются вручную пользователями. И это только малая толика того, с чем приходится сталкиваться в реальных проектах.

Отдельная тема — интеграционные решения, в которых может происходить сбои в цепочке, использующей различные компоненты, разработанные двумя, тремя и больше командами. Найти виноватых в этой ситуации крайне сложно, поскольку дефекты чаще всего возникают на стыке интеграционных элементов, из-за выявленных в ходе внедрения несоответствий. И тут важно не искать виновных для наказания, а быстро и конструктивно договориться о совместных уступках разработчиков стыкуемых компонентов, и эффективно решить проблему.

Учитывая все вышеперечисленное, этап опытной эксплуатации, чаще всего, насыщен эмоциональными всплесками и взаимными претензиями, как между командами разработчиков, так и с заказчиками. В этом случае очень важна роль архитекторов и системных аналитиков, которые должны оперативно локализовать проблему, предложить ее решение и согласовать его со всеми заинтересованными лицами. Для выполнения подобных работ требуется помимо основных профессиональных навыков, еще и обладание талантом переговорщика, и знанием основ менеджмента.

А тем временем мы достигли дна, отведенного для проекта времени…

4. Согласование изменений в процессе внедрения информационной системы

Если работа некоторых функциональных модулей информационной системы критически не соответствует потребностям и ожиданиям заказчика, и найдены решения по преодолению этих проблем, то необходимо их зафиксировать и согласовать с заказчиком.

Этап согласования нового решения очень важен, как минимум по двум причинам.

Во-первых, если объем реализации изменений превысит суммы, заложенные на подобные риски в плане проекта, то необходимо либо заключать дополнительные соглашения, либо команда исполнителей будет работать в убыток. Зачастую исполнителей призывают по-быстрому сделать изменения, а мол учтем их и рассчитаемся за работы по ним потом, одним пакетом. Но по факту же такие случаи, обычно приводят, к тому, что заказчик опосля напрочь забывает свои обещания, а выполненные работы объявляет — исправлением исполнителями своих собственных ошибок.

Во-вторых, любые изменения одних компонентов системы могут повлечь за собой неизбежное изменение взаимозависимых компонентов, что требует тщательного анализа и, возможно, перепроектирования целой цепочки подсистем. В противном случае неизбежно возникновение дефектов в работе системы в целом. Проявляться это может например, в отказе работы модуля смежной команды исполнителей, и заказчик уже их объявляет халтурщиками и бракоделами. Правда конечно всплывет, но осадчик останется.

И вот перефразируя Ежи Леца: «Когда мы достигли дна отведенного времени, снизу постучались . »

Поскольку время просрочено, необходимо договариваться с заказчиком, и убеждать его, что он в проекте тоже был не подарок, и часть вины лежит именно на нем.

5. Доработка информационной системы по итогам опытной эксплуатации

Если в ходе опытной эксплуатации принимаются и согласуются решения о внесении изменений в разработанный программно-аппаратный комплекс, то на основании их выставляются задачи исполнителям по их реализации. Процесс, описанный в разделе Часть 3. Реализация проектного решения повторяется. Но…

Если на стадии проектирования системы мы обсуждали отрицательное влияние полномасштабного использования методологии Scrum (1) в больших проектах, то на данном этапе она подходит как нельзя лучше. Особенно это ощутимо в проектах в которых продукт, переданный заказчику, не устраивает его по большей части показателей. Иными словами, пора поддаться панике и очень быстро, «сломя голову» вносить изменения в продукт, который уже эксплуатируют.

Собственно говоря, наступил момент, когда актуальны следующие условия:

1. Заказчик уже начал реально работать с системой, у него для этого выделено время, и он теперь наглядно представляет, что же ему действительно необходимо. Соответственно он готов плотно работать с командой исполнителей и у него есть в этом критическая необходимость;
2. Документация большей частью уже готова и ее изменение и дополнение может вестись уже не так оперативно, а оформляться постфактум по результатам успешной реализации.
3. Доработки большей частью происходят в отдельных модулях, подсистемах, контурах, у которых есть конкретная команда исполнителей, отвечающая за сегмент. Поэтому общение пользователей с разработчиками уже локализовано, легко установить качественную обратную связь;
4. Доработки и исправления необходимо выполнять очень оперативно, небольшими очередями с передачей результата заказчику, который в них кровно заинтересован;

Очень важно, чтобы в конечном итоге, проектная документация была приведена в полное соответствие с нововведениями, и команда могла легко отыскать в ней актуальное решение для анализа и проектирования последующих изменений.

Рисунок 20. – Этап внедрения информационной системы

6. Передача информационной системы в промышленную эксплуатацию

Когда в ходе опытной эксплуатации решены все спорные вопросы и недоразумения по поводу того как должна функционировать внедренная система, и насколько она соответствует договору на ее разработку, стороны подписывают акты о выполнении контракта. Заказчик осуществляет полный расчет за выполненные работы. Договор на разработку и внедрение информационной системы может считаться выполненным.

Внедрение переходит в фазу промышленной эксплуатации. Эти взаимоотношения чаще всего юридически регулируются уже отдельным договором или дополнительным соглашением на сопровождение промышленной эксплуатацией системы. В рамках этого контракта могут происходить профилактические работы по диагностике работы компонентов системы, их взаимодействия, устранение мелких сбоев и т.п.

7. Резюме раздела

Этап внедрения информационной системы, являет собой момент истины всего процесса ее производства и ознаменует старт самого тяжелого периода для всех участников проекта. Он может включать в себя следующие активности:

1. Развертывание системы на площадке промышленной эксплуатации, включая поставку оборудования, установку системного ПО, установку актуального релиза внедряемой системы и т.п.;
2. Обучение пользователей работе с системой, включая администраторов, специалистов по обслуживанию оборудования и т.п.
3. Выявление и устранение недостатков и дефектов, выявленных в ходе опытной эксплуатации.
4. Согласование изменений в работе системы и приведение ее к соответствию контрактным обязательствам;
5. Подписание документов о выполнении договорных обязательств. Произведение полного расчета за выполненные работы;
6. Ввод системы в промышленную эксплуатацию;

Источник

Способы внедрения информационной системы

Аннотация: работа содержит обзор базовых схем внедрения корпоративных информационных систем, заданных каскадной, итерационной и спиралевидной моделями, определяются области их применения и демонстрируются примеры современных методологий.
Скачать : PDF (статья) , PDF (база знаний) .
Ключевые слова: waterfall model, spiral model, iterative model, жизненный цикл каскадная модель, инкрементная модель жизненного цикла, спиральная модель жизненного цикла, жизненный цикл продукта, жизненный цикл программного продукта, жизненный цикл программного обеспечения, этапы создания программного обеспечения, ЖЦ информационных систем, жизненный цикл информационных систем, модель жизненного цикла, жизненный цикл проекта, эволюционная модель жизненного цикла, модели жизненного цикла для разработки программных систем, модель жизненного цикла ПО.

Типовые этапы внедрения корпоративных информационных систем (КИС) включают: подготовку, проектирование, реализацию, опытно-промышленную и продуктивную эксплуатации. Стадии внедрения КИС задают последовательность операций, необходимых для реализации и успешного использования решения на предприятии заказчика. Процесс имплементации КИС часто называют моделью внедрения, задающей порядок следования операций, более того от модели к модели последовательность и содержание задач может отличаться. Выделяют три базовые модели внедрения информационных систем, все прочие рассматриваются как производные от них: каскадная, итерационная и спиралевидная [1].

1. Каскадная модель внедрения

Каскадная модель или модель водопад была предложена еще в 1970 г. Реализация проекта внедрения, следуя этой модели, ведётся путём строгого выполнения задач каждого из этапов, переход к последующему этапу возможен лишь в случае успешного завершения предыдущего. Пропуск этапов, возврат к предыдущим и повторение запрещены (рис.1).

Проект внедрения КИС на основе данной модели состоит из активностей:

• подготовка проекта;
• идентификация, анализ и приоритизация требований;
• формирование проектных решений и спецификаций на разработку;
• настройка и доработка системы;
• проведение функционально-модульного, интеграционного и приёмочного тестирований;
• миграция данных и обучение пользователей;
• переход к продуктивной эксплуатации и поддержка.

Каскадная модель хорошо подходит для проектов внедрения многофункциональных КИС, интегрированных с множеством как внешних, так и внутренних подсистем, где даже самые незначительные обновления требований могут привести к изменениям сроков, работ и затрат. Именно поэтому водопадную модель часто применяют на проектах имплементации «с нуля» и «тиражирования», в которых объём трудозатрат достаточно велик. Примерам каскадной модели служат методологии внедрения ASAP (Accelerated SAP) компании SAP AG, MDSS (Microsoft Dynamics Sure Steps) от Microsoft и AIM (Application Implementation Method) как часть концепции Oracle Unified Method.

Рис. 1. Каскадная методология внедрения КИС

2. Итерационная модель внедрения

Итерационная модель обеспечивает контур обратной связи между этапами проекта, возможность возврата на предыдущие стадии, многократное выполнение этапов, а также является многопроходной (рис.2). Была изначально предложена еще в 1957 г. Разработка программного обеспечения согласно данной модели сводится к разбиению этапа реализации на серию быстрых, лёгких и адаптивных итераций, оперативно приносящих результаты. Каждая итерация завершается демонстрацией заказчику полученного промежуточного продукта с целью скорейшего выявления потенциальных ошибок. В ходе выполнения итераций понимание содержания конечного продукта может меняться, поэтому добавляются все новые и новые функциональные возможности. Продолжительность каждой итерации варьируется в пределах 1-6 недель, а число таких итераций рассчитывается на основе заранее определенных сроков завершения или бюджета проекта.

Проект имплементации КИС согласно предлагаемой модели состоит из шагов:

• идентификация, анализ и приоритизация изначальных требований;
• определение числа и продолжительности итераций разработки;
• доработка и кастомизация КИС, функциональное и интеграционное тестирование с последующей демонстрацией полученного продукта заказчику для уточнения требований, реализуемых на последующих итерациях, перенос решения в продуктивную среду (для каждой итерации);
• проведение приёмочного тестирования;
• миграция данных и обучение пользователей;
• переход к продуктивной эксплуатации и поддержка.

Из приведенного списка легко заметить, что шаги проектирования и документирования решения отсутствует, это действительно так. Однако поскольку окончание этапа продуктивного запуска завершается передачей системы службе поддержки, на практике документацию все же приходится готовить. В отличие от каскадной модели внедрения итерационная схема нашла свое применение в проектах по доработке уже реализованного решения новыми функциями, требования к которым до конца могут быть не сформулированы бизнес пользователями. Семейство гибких методов разработки Agile служит примером использования итерационной модели, в частности: Scrum, Kanban и Feature Driven Development.

Рис. 2. Итерационная методология внедрения КИС

3. Спиралевидная модель внедрения

В 1986 г. была предложена спиралевидная модель внедрения (рис.3). Данная модель сочетает в себе подходы как последовательной, так и многопроходной моделей. Основной акцент в спиралевидной схеме сделан на обработке рисков и оценивании степени готовности решения. Спиралевидную модель нередко рассматривают как частный случай итерационной, поэтому каждый виток спирали сравним с итерацией одноимённой модели внедрения и характеризуется:

• определением цели и задач;
• обработкой рисков;
• разработкой, настройкой и тестированием решения;
• оцениванием результатов и планированием следующего витка разработки.

Проект внедрения КИС на основе спиралевидной схемы сопоставим с итерационной с той лишь разницей, что каждый виток спирали помимо обработки рисков должен включать:

• оценку необходимости выполнения ещё одного витка спирали;
• оценку уровня понимания требований к системе;
• анализ целесообразности завершения проекта.

Обработка сроков, ресурсов, бюджета, качества, коммуникаций и прочих параметров проекта, а также оценивание необходимости выполнения следующих витков разработки требуют значительных трудозатрат. Поэтому применение данной модели целесообразно в больших проектах развития КИС. Для небольших подпроектов время, потраченное на обработку и оценивание параметров проекта, будет несопоставимо больше самого процесса доработки системы [2]. Примерами использования спиралевидной модели внедрения служат методологии RAD (Rapid Application Development) и XP (eXtreme Programming).

Источник