Реализация информационной системы. Разработка и внедрение информационных систем

Разработка любого программного продукта всегда проходит в несколько этапов, на каждом из которых, проектируется какая-то отдельная составляющая.

Так, разработка данной информационной системы была проведена в пять этапов.

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

Следующим шагом стала визуализация того, как именно люди будут использовать информационную систему. Для этого используется специальная UML диаграмма - USE CASE, предоставляющая в наглядной форме возможные действия пользователя, имеющего определённую роль.

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

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

Общая архитектура информационной системы

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

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

Существует несколько типов архитектур применяемых при разработке информационных систем - как то:

Настольная архитектура (рисунок 9);

Распределённая архитектура (рисунок 10).

Первый тип архитектуры приложения подразумевает нахождение всей информации на той же рабочей станции, где установлена информационная система. Распределённая архитектура системы, в свою очередь подразумевает возможность выбора из файл-серверной или же клиент-серверной. Первый вариант подразумевает нахождение СУБД и клиентского приложения на рабочей станции, в то время как база данных находится на отдельном сервере.

Р и с у н о к 9 - Настольная архитектура приложения

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


Р и с у н о к 10 - Многозвенная архитектура с сервером приложений в качестве посредника

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

Преимущества системы:

Отсутствие дублирования кода программы-сервера программами-клиентами;

Так как все вычисления выполняются на сервере, то требования к компьютерам, на которых установлен клиент, снижаются;

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

Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.;

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

Недостатки:

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

Поддержка работы данной системы требует отдельного специалиста -- системного администратора;

Высокая стоимость оборудования.

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

Разработка локальных хранилищ и базы данных на сервере это фактически отдельный этап проектирования системы, но в то же время их разработка является частью проектирования общей архитектуры. Так что следует упомянуть и эту часть информационной системы. Так, в качестве СУБД используется Microsoft SQL Server Express - бесплатная версия системы управления реляционными базами данных Microsoft SQL Server. Основным языком запросов этой СУБД является Transact-SQL, который является реализацией стандарта ANSI/ISO по структурированному языку запросов.

Р и с у н о к 11 - Архитектура ИС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Без комментариев…

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

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

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

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

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

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

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

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них .

Критически важными для внедрения являются следующие факторы :

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

· планирование работ, ресурсов и контроль выполнения плана внедрения;

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

· регулярный мониторинг качества выполняемых работ;

· быстрое получение положительных результатов хотя бы в части внедренных модулей ИС или в процессе ее опытной эксплуатации.

Перед началом разработки проекта внедрения необходимо:

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

· установить высокий приоритет проекта внедрения перед остальными текущими проектами;

· наделить руководителя проекта максимально возможными полномочиями;

· провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;

· разработать организационные меры для применения новых информационных технологий;

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

Необходимо также определить функциональные сферы внедрения модулей информационной системы:

· организационное управление;

· организационно-административное обеспечение;

· управление бизнес-процессами;

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

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

· системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

· адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

6.6.1 Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС" . В ходе предпроектного обследования предприятия (рис. 4) происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта" . После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

· формирование проектной и экспертной групп;

· распределение полномочий и ответственности;

· определение организационно-технических требований к процессу внедрения;

· уточнение спецификаций и ожиданий заказчика;

· обучение группы внедрения, состоящей из специалистов предприятия-заказчика.

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

Фаза "Концептуальная проработка проекта" . В течение этой фазы:

· формируется и утверждается концептуальный проект;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

· согласуются укрупненный план работы, последовательность этапов и условия опытной эксплуатации, планово-финансовые и отчетные показатели;

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

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

Рисунок 12 - Примерное содержание репозитория проекта внедрения

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


Рисунок 13 - Примерный состав документации по процессу внедрения информационной системы

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

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы

1. Что такое "открытая информационная система"? Перечислите основные свойства открытых систем.

2. Охарактеризуйте суть современного процессного подхода к управлению деятельностью предприятия и использования этого подхода при разработке ИС.

3. Какие модели и каким образом используются при проектировании информационных систем?

4. Какие программные средства используются для моделирования процессов при разработке информационных систем?

5. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?

6. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?

7. Назовите основные этапы проектирования информационных технологий.

8. Перечислите этапы жизненного цикла информационной системы.

9. На каком этапе разработки и внедрения ИС производится обучение персонала компании?

10. Перечислите основные фазы внедрения ИС.

Обычно выделяют следующие этапы создания ИС:

1. формирование требований к системе,

2. проектирование,

3. реализация,

4. тестирование,

5. ввод в действие,

6. эксплуатация и сопровождение.

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

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

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

Параллельно с проектированием схемы базы данных выполняется проектирование процессов, чтобы получить спецификации (описания) всех модулей ИС. Оба эти процесса проектирования тесно связаны, поскольку часть бизнес-логики обычно реализуется в базе данных (ограничения, триггеры, хранимые процедуры). Главная цель проектирования процессов заключается в отображении функций, полученных на этапе анализа, в модули информационной системы. Конечными продуктами этапа проектирования являются схема базы данных (на основании ER-модели, разработанной на этапе анализа) и набор спецификаций модулей системы (они строятся на базе моделей функций).

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

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

Этап тестирования обычно оказывается распределенным во времени.

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

2. Понятие «архитектура информационной системы»

Рассмотрим определение "архитектуры информационной системы", которое дают различные источники:

Архитектура – это организационная структура системы.

АрхитектураИС – концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

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

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

Если все эти определения объединить, то получим следующее:

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

Под архитектурой программных систем будем понимать совокупность решений относительно:

· организации программной системы;

· выбора структурных элементов, составляющих систему и их интерфейсов;

· поведения этих элементов во взаимодействии с другими элементами;

· объединение этих элементов в подсистемы;

· архитектурного стиля, определяющего логическую и физическую организацию системы: статические и динамические элементы, их интерфейсы и способы их объединения.

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

По мере развития программных систем все большее значение приобретает их интеграция друг с другом с целью построения единого информационного пространства предприятия.

Вопрос: «Кто осуществит внедрение информационной системы?», чрезвычайно важен в каждом из случаев запуска проекта автоматизации.

Данный тезис неоспорим, по нескольким причинам:

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

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

Внедрение информационных систем в основном происходит по одной из следующих схем:

    Внедрение осуществляет компания-внедренец;

  1. Собственный отдел информационных технологий;
  2. Привлекается фрилансер, который выполняет функцию руководителя проекта.

Рассмотрим каждый вариант подробнее.

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

Нюансы работы с крупной компанией внедренцем:

    Внедрение информационной системы поставлено на поток;

    В штате компании присутствуют специалисты с очень разной квалификацией. Как правило, такие компании имеют весьма высокую «текучку кадров», набирают множество неопытной (иногда весьма перспективной) молодежи, и ее где-то надо «тренировать». Соответственно, на проект направляются сотрудники с уровнем подготовки на прямую зависимым от степени важности клиента для компании;

    Неудача на «небольших» проектах мало влияет на общую репутацию компании и отношения к таким проектам соответствующее;

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

    Стоимость услуг – самая высокая из всех рассматриваемых вариантов.

Альтернативный вариант – небольшая компания:

    Проект может стать приоритетной задачей для специалистов компании;

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

    Успех проекта полностью зависит от квалификации сотрудников компании и в первую очередь менеджера проекта;

    Обходятся значительно дешевле чем.

Собственный отдел информационных технологий (ИТ).

На первый взгляд кажется оптимальным вариантом, свои сотрудники, контролируемые затраты, гарантия сохранения информации. Однако мировой опыт говорит случаи реализации проектов внедрения информационных систем таким методом – единичны! Характерным элементом таких проектов являются затянутые сроки реализации, причем затянутые на годы. Такие проекты переходят в операционную деятельность.

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

Еще одним моментом является слишком тесная коммуникация, пользователь просит что-то сделать устно, однако потом вносит коррективы, а потом еще. Таким образом, пропадает мера оценки работы и консультанта и программиста. Сложно попасть, когда цель не задана.

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

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

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

Но никто не гарантирует, что данный специалист сможет стойко преодолевать менеджерские проблемы которые были описаны в предыдущем пункте.

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

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

Делая выводы из всего вышесказанного, хочется зафиксировать:

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

Исходя из того, что предложенные способы не идеальны.