Методические основы управления ИТ-проектами

Управление проектом на фазе разработки и внедрения

Разбить на страницы
Показывать лекцию целиком

Детальное планирование стадии разработки и внедрения

Задачи планирования стадии разработки и внедрения совпадают с задачами предыдущей стадии. Дополнительной задачей является подготовка персонала к завершению проекта. Решение этой задачи включает следующие действия:

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

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

    Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Пример методики оценки персонала предложен В.Ильиным и изложен в книге "Руководство качеством проектов. Практический опыт" [13].

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

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

    Подготовка инфраструктуры для фазы эксплуатации

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

    Для проверки соответствия выполняется аудит ключевых результатов.

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

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

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

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

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

    Осуществление итогов контроля качества проекта

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

    К задачам этого этапа относится:

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

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

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

    Управление рисками настройки и внедрения

    Идентификация рисков данной стадии выполняется аналогично процессу идентификации рисков на предыдущих стадиях.

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

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

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

    Подготовка персонала к завершению проекта

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

  • извещение менеджмента проекта, заказчика и персонала.

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

  • подготовка оценки работы персонала.

    Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией;

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

    Организация тестирования

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

  • Оценка выполняется по ранее разработанным процедурам, на основании контрольных списков для проверки управления проектом и отчетности.
  • Настройка рабочей среды.
  • Настройка конфигурации (для системного тестирования ).
  • Настройка инфраструктуры, тестирование системы.
  • Выполнение системного и пользовательского теста.
  • Установка рабочей среды.
  • Выполнение теста на запуск.
    •

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

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

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

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

    • Реализация цикла тестирования

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

  • Функциональное тестирование

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

  • Первое интеграционное тестирование

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

  • Второе интеграционное тестирование

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

  • Первое пользовательское тестирование

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

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

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

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

    • Тестирование процессов, документов и отчетов

    По ряду причин тестирование процессов следует реализовать отдельно.

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

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

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

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

  • применимо (роль принимает участие в процессе);
  • не применимо (роль не принимает участие в процессе).
    •

    В центральном столбце производится перечисление подпроцессов/шагов тестируемого процесса.

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

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

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

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

    Переход к продуктивной эксплуатации

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

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

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

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

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

    Завершение проекта (фазы)

    Завершение проекта подразумевает завершение всех операций всех групп процессов управления проектом (данного этапа) в целях формального завершения данной стадии и перехода к следующей.

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

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

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

    В случае если по окончании отчетного периода запланированная работа участника проектной команды оказалась не выполненной, руководители проекта от исполнителя и заказчика проводят выяснение причины невыполнения запланированной работы. Если причина невыполнения запланированной работы не может быть устранена оперативно (т.е. в течение 1 дня), она вносится как проблема в журнал проблем администратором проекта и решается в соответствии с процедурой управления открытыми вопросами. По решению проблемы руководители проекта от исполнителя и заказчика производят установление нового срока выполнения работы.

    Пример процедуры приемки результатов проекта

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

    Помимо проектной документации, в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:

  • акт сдачи-приемки услуг как приложение к договору на консультационные услуги;
  • протокол замечаний;
  • протокол устранения замечаний;
  • протокол совещаний руководящего органа проекта.
    •

    Пример процедуры согласования

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

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

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

    Пример процедуры управления открытыми вопросами

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

    Управление открытыми вопросами и проблемами осуществляется на двух уровнях

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

    Уровень проекта в целом: список открытых вопросов/проблем на уровне проекта в целом (ответственность руководителей проекта).

    Порядок работы с открытыми вопросами и проблемами уровня проекта в целом

    Открытый вопрос/проблема могут быть сформулированы любым участником проекта на своем уровне.

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

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

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

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

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

    В случае решения вопроса/проблемы в управляющем комитете и при отсутствии влияния проблемы на сроки, бюджет, ресурсы, качество проекта указанные вопрос/проблема считаются закрытыми и оформляются администратором проекта в журнале проблем изменением статуса вопроса/проблемы на "закрыто"; в противном случае вопрос/проблема переоформляются в виде запроса на изменение.

    Журнал открытых вопросов ведется только администратором проекта и доступен для чтения всем участникам проекта.

    Страницы:

    Детальное планирование стадии разработки и внедрения

    Задачи планирования стадии разработки и внедрения совпадают с задачами предыдущей стадии. Дополнительной задачей является подготовка персонала к завершению проекта. Решение этой задачи включает следующие действия:

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

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

    Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией. Пример методики оценки персонала предложен В.Ильиным и изложен в книге "Руководство качеством проектов. Практический опыт" [13].

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

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

    Подготовка инфраструктуры для фазы эксплуатации

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

    Для проверки соответствия выполняется аудит ключевых результатов.

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

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

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

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

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

    Осуществление итогов контроля качества проекта

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

    К задачам этого этапа относится:

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

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

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

    Управление рисками настройки и внедрения

    Идентификация рисков данной стадии выполняется аналогично процессу идентификации рисков на предыдущих стадиях.

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

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

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

    Подготовка персонала к завершению проекта

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

  • извещение менеджмента проекта, заказчика и персонала.

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

  • подготовка оценки работы персонала.

    Для выполнения оценки работы персонала используют методики и процедуры, принятые компанией;

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

    Организация тестирования

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

  • Оценка выполняется по ранее разработанным процедурам, на основании контрольных списков для проверки управления проектом и отчетности.
  • Настройка рабочей среды.
  • Настройка конфигурации (для системного тестирования ).
  • Настройка инфраструктуры, тестирование системы.
  • Выполнение системного и пользовательского теста.
  • Установка рабочей среды.
  • Выполнение теста на запуск.
    •

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

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

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

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

    • Реализация цикла тестирования

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

  • Функциональное тестирование

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

  • Первое интеграционное тестирование

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

  • Второе интеграционное тестирование

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

  • Первое пользовательское тестирование

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

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

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

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

    • Тестирование процессов, документов и отчетов

    По ряду причин тестирование процессов следует реализовать отдельно.

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

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

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

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

  • применимо (роль принимает участие в процессе);
  • не применимо (роль не принимает участие в процессе).
    •

    В центральном столбце производится перечисление подпроцессов/шагов тестируемого процесса.

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

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

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

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

    Переход к продуктивной эксплуатации

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

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

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

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

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

    Завершение проекта (фазы)

    Завершение проекта подразумевает завершение всех операций всех групп процессов управления проектом (данного этапа) в целях формального завершения данной стадии и перехода к следующей.

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

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

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

    В случае если по окончании отчетного периода запланированная работа участника проектной команды оказалась не выполненной, руководители проекта от исполнителя и заказчика проводят выяснение причины невыполнения запланированной работы. Если причина невыполнения запланированной работы не может быть устранена оперативно (т.е. в течение 1 дня), она вносится как проблема в журнал проблем администратором проекта и решается в соответствии с процедурой управления открытыми вопросами. По решению проблемы руководители проекта от исполнителя и заказчика производят установление нового срока выполнения работы.

    Пример процедуры приемки результатов проекта

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

    Помимо проектной документации, в пакет документов для процедур приемки результатов проекта входят следующие первичные документы:

  • акт сдачи-приемки услуг как приложение к договору на консультационные услуги;
  • протокол замечаний;
  • протокол устранения замечаний;
  • протокол совещаний руководящего органа проекта.
    •

    Пример процедуры согласования

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

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

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

    Пример процедуры управления открытыми вопросами

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

    Управление открытыми вопросами и проблемами осуществляется на двух уровнях

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

    Уровень проекта в целом: список открытых вопросов/проблем на уровне проекта в целом (ответственность руководителей проекта).

    Порядок работы с открытыми вопросами и проблемами уровня проекта в целом

    Открытый вопрос/проблема могут быть сформулированы любым участником проекта на своем уровне.

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

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

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

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

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

    В случае решения вопроса/проблемы в управляющем комитете и при отсутствии влияния проблемы на сроки, бюджет, ресурсы, качество проекта указанные вопрос/проблема считаются закрытыми и оформляются администратором проекта в журнале проблем изменением статуса вопроса/проблемы на "закрыто"; в противном случае вопрос/проблема переоформляются в виде запроса на изменение.

    Журнал открытых вопросов ведется только администратором проекта и доступен для чтения всем участникам проекта.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^