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

Разработка и планирование учебных занятий

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

Аудиторное обучение

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

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

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

Электронное обучение

  • Чтобы составить расписание виртуально-аудиторных занятий и распределить учебные материалы, требуется примерно 2 недели. Не переработку курса в соответствии с индивидуальными потребностями обычно уходит 6-8 недель.
  • Курс обучения на основе компьютера/Интернета нужно заказать на этом этапе, чтобы клиент мог вовремя получить его для распространения. Корректировка курса такого типа занимает 8-10 недель.

Планирование испытаний и подготовка к ним

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

Испытание блоков

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

Системное испытание

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

Испытание защищенности информации

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

Интеграционное испытание

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

Испытание приемлемости системы для пользователя

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

Испытание загрузки / преобразования данных

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

Испытание объема

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

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

Параллельные испытания

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

Контрольная точка

 

Основной целью контрольной точки построения является получение от клиента официального согласия в том, что система построена согласно разработке.

Основные моменты, фиксируемые в данной точке:

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

Вопросы и ответы по автоматизированным системам

  • Как классифицировать проекты внедрения автоматизированных систем? +

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

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

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

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

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