Опубликован: 25.01.2011 | Уровень: для всех | Доступ: платный | ВУЗ: Национальный исследовательский университет "Высшая Школа Экономики"
Лекция 12:

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

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >

Контроль качества проекта

На стадии контроля каждой стадии ЖЦ ИТ выполняются мониторинг, контроль и формирование отчетности о соответствующем этапе проекта.

Целями этапа являются [22]:

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

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

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

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

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

Таблица 11.5. Пример формы сводной таблицы сценариев тестирования
Наименование сценария Описание сценария Дата, время Тестировщик Приемщик Успешно (да/нет) Примечания
.
Комментарий к форме
  1. : Номер сценария тестирования бизнес-процесса.
  2. Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса.
  3. Описание сценария:Описание сценария тестирования бизнес-процесса.
  4. Дата, время:Дата и время проведения тестирования.
  5. Тестировщик:Консультант от исполнителя, участвующий в тестировании.
  6. Приемщик:Сотрудник функциональной группы от заказчика, участвующий в тестировании.
  7. Успешно? (да/нет):Отметка об успешности прохождения сценария тестирования.
  8. Примечания:Дополнительные пояснения к результатам сценария

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

Ошибки, выявленные при тестировании, фиксируют в специальном журнале. Пример формы журнала ошибок представлен в табл. 11.6.

Контроль качества обеспечивается руководителем проекта, менеджером по качеству, командой проекта. В табл. 11.7 собраны функции участников процесса контроля [22].

Контроль рисков проекта

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

Мониторинг рисков выполняется с помощью следующих методов.

  1. Пересмотр рисков
    Таблица 11.6. Пример формы журнала ошибок
    Наиме-нование сценария № шага тестирования Шаг процесса Модуль Описа- ние ошибки Решение Ответственный Наме- ченная дата
    .
    .
    .
    Комментарий к форме "Журнал ошибок"
    1. Наименование сценария:Короткое наименование сценария тестирования бизнес-процесса.
    2. № шага тестирования:Уникальный идентификатор шага тестирования в формате Z.P#.NN, где Z - номер сценария тестирования, Р# - 5-значный номер процесса и NN - уникальный 2-циферный код в рамках сценария.
    3. Шаг процесса:Номер и наименование тестируемого шага бизнес-процесса. Номер шага бизнес процесса в формате P#.NN, где Р# - 5-значный номер процесса, и NN - уникальный 2-циферный код в рамках процесса.
    4. Модуль: Модуль ИС, с использованием которого реализуется шаг бизнес-процесса.
    5. Описание ошибки:подробное описание ошибки, выявленной в ходе тестирования, со ссылкой на файл, в котором находятся полные сведения об ошибке.
    6. Решение:Планируемые мероприятия по устранению ошибки.
    7. Ответственный:Сотрудник, назначенный ответственным за устранение ошибки в намеченный срок.
    8. Намеченная дата:Планируемый срок устранения ошибки

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

    • не выполняется процесс управления изменениями, в результате чего происходит "сползание" объема, или содержания, проекта;
    • влияние спорных вопросов, изменений и проблем оценивается неадекватно;
      Таблица 11.7. Функции участников команды проекта, обеспечивающих выполнение процесса контроля
      Функция Результат выполнения функции
      Руководитель проекта
      Организация обзора результатов проекта и согласование выявленных замечаний Обзор качества (результаты процесса обзора)
      Организация аудита качества работ и согласование выявленных замечаний Аудит качества (результаты процесса аудита)
      Организация работы по сбору информации по показателям качества работ Показатели качества (результаты процесса контроля показателей качества)
      Менеджер по качеству
      Анализ и согласование выявленных результатов Обзор качества (результаты процесса обзора)
      Анализ и утверждение результатов аудита Аудит качества (результаты процесса аудита)
      Анализ показателей качества Показатели качества (результаты процесса контроля показателей качества)
      Команда проекта
      Участие в обзорах результатов проекта Обзор качества (результаты процесса обзора)
      Участие в проведении аудита качества работ, выполнении согласованных мероприятий Аудит качества (результаты процесса аудита)
      Участие в сборе информации по показателям качества работ. Показатели качества (результаты процесса контроля показателей качества)
    • обзоры состояния работ проводятся поверхностно и нерегулярно;
    • стратегии по реагированию на риски не анализируют на предмет их эффективности;
    • полученные результаты проекта не контролируются;
    • не выполняется обзор качества работ, связанных с получением ключевых результатов.
  2. Аудит рисков

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

    Таблица 11.8. Пример формы (интенсивного) мониторинга сотрудника
    Тип риска Описание риска Проактивные мероприятия Реактивные мероприятия Пороговые состояния Вероятность Влияние Фактор риска
    Политический Заказчик решил не внедрять систему Плана нивелирования риска не существует. Заказчик решает либо внедрять систему, либо не внедрять Если заказчик не представляет стратегической ценности для компании-исполнителя - не начинать проект 6 9 54
    Политический Ввиду того, что выбор системы (и подрядчика) проводился холдинговым руководством заказчика, сам заказчик на текущий момент не заинтересован в проекте и внедрении системы
    1. . Проведение ряда заблаговременных семинаров, повышающих уровень заинтересованности заказчика во внедрении системы.
    2. Организация референс-визи-тов к успешным клиентам.
    3. Определение реальных лидеров в организации. Точечное повышение уровня их заинтересованности в успешном внедрении системы
    4. ...
    п/а 8 4 32
    . 0
  3. Анализ отклонений и трендов

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

  4. Анализ резервов

    При анализе резервов производится сравнение объема оставшихся резервов на непредвиденные обстоятельства с количеством оставшихся рисков.

  5. Совещания по текущему состоянию

Периодические совещания команды проекта по вопросам управления рисками являются инструментом для отслеживания состояния рисков проекта.

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

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

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

< Лекция 11 || Лекция 12: 1234 || Лекция 13 >
Анна Яковлева
Анна Яковлева
Надежда Артюх
Надежда Артюх
Курс Методологии проектирования и внедрения корпоративных информационных систем
Денис Бочаров
Денис Бочаров
Россия
Анна Небеснюк
Анна Небеснюк
Россия, Софрино-1, Майская средняя, 2012