Опытная эксплуатация автоматизированной системы

Фаза тестирования

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

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

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

Испытание программного решения

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

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

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

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

Испытание системы – это итеративный процесс, включающий следующие этапы:

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

Обучение конечных пользователей

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

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

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

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

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

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

  • Вместе с руководителям группы клиента выяснить и попытаться решить все оставшиеся проблемы.
  • Оценить готовность системы к работе или параллельной эксплуатации (если она предполагается).
  • Для подтверждения завершенности испытаний и готовности системы к запуску требуется официальное заявление клиента.

Документы, рассматриваемые на данном этапе:

Отчет о проделанной работе / о ходе выполнения проекта

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

Сметно-финансовые расчеты

На совещании могут быть представлены в суммарном виде. Должны быть объяснены все расхождения с предыдущими сметами.

Журнал регистрации проблем и Предупреждения о рисках

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

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

План-график проекта

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

План-график испытаний

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

План-график обучения

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

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

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

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

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

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

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

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