Проведение

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

Рис. 4.1.  Принцип структурирования информации о бизнес-процессе

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

3. Дальнейшие действия

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

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

• Определены ли факторы ценности для заказчика?

• Усвоила ли команда проекта эти факторы?

• Были ли факторы ценности интегрированы в процессы и проектные продукты?

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

Функция качества - это инструмент для работы с заказчиком, который позволяет встроить его требования в проект. Цель этого инструмента - убедиться, что требования заказчика интегрированы в каждую часть проекта, от определения (1) требований проекта и (2) установления характеристик решения до формирования (3) проектных работ и выстраивания (4) программы обеспечения качества.

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

На рис. 4.2 отражена типовая структура "дома качества". Его заполнение производится в несколько этапов.

1. Подготовка требований заказчика

Рис. 4.2.  Схема и рекомендации по проведению интервью

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

2. Определение требований проекта

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

3. Формирование матрицы взаимосвязей

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

4. Формирование матрицы отношений

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

5. Субъективная оценка через сравнительный анализ

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

6. Объективная оценка через установку конечных целей

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

5. План управления проектом

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

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

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

1. Вспомогательные планы управления проектом, в число которых входят:

   • план управления содержанием проекта;

   • план управления расписанием проекта;

   • план управления стоимостью проекта;

   • план управления качеством проекта;

   • план управления обеспечением персоналом;

   • план управления коммуникациями проекта;

   • план управления рисками проекта;

   • план управления конфигурацией.

2. Базовая линия проекта, состоящая из:

   • базового расписания проекта;

   • базового плана по стоимости;

   • базового плана по качеству;

   • базового плана по конфигурации;

   • реестра рисков.

3. Результаты анализа, проведенного проектной командой в отношении содержания, объема и сроков проекта.

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

6. Формирование списка операций проекта

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

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

Построение иср

Существуют два основных способа разработки ИСР: "сверху вниз" и "снизу вверх". Далее приводится описание подхода "сверху вниз".

1. Сбор исходной информации.

Разработка ИСР станет более легким и осмысленным делом, если будет доступна следующая информация:

• требования заказчика;

• пул доступных ресурсов;

• конкретная проектная ситуация.

Выбор типа ИСР

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

В соответствие с принципом, лежащим в основе построения ИСР по фазам жизненного цикла, на 1-ом уровне происходит разбитие проекта на фазы. Этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях и, в принципе, значительно упрощает разработку расписания проекта. Хороший пример использования такого типа структурирования ИСР - проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Принцип разбития по системам подразумевает разбитие на составляющие физические системы и отображение их на уровне 1 ИСР. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых ИСР больше напоминает спецификацию производственного образца. Разбиение ИСР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 ИСР проекта может состоять из здания A, здания B и т. д. Что касается следующих уровней ИСР, многие специалисты практикуют гибридные ИСР, сочетающие два или три метода.

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

3. Определение степени детализации ИСР

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

Для определения степени детализации ИСР нужна следующая информация:

• количество уровней в ИСР;

• количество и средний размер пакета работ, принятые в отрасли. Так, для большинства средних и малых ИТ-проектов характерны

ИСР со следующей детализацией:

• от трех до четырех уровней;

• от 15 до 40 пакетов работ;

• от 40 до 80 часов на средний пакет работ;

• от 3% до 7% общего бюджета рабочих часов на средний пакет работ.

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

Перечень вопросов.

1. Управление проектом построения информационной системы.

2. Методология разработки сложных программных систем.

3. Управление временем выполнения проекта и отклонениями от плана.

4. Планирование ресурсов. Распределение работ по проекту.

5. Основные принципы организации работы над проектом.

6. Методология Rational Unified Process (RUP).

7. Средства разработки ПО.

8. Тестирование программного обеспечения.

9. Управление проектами и портфелями.

10. Управление требованиями.

11. Управление конфигурациями и изменениями.

12. Управление выполнением проекта и документированием.

13. Структура информационно-логической модели ИС.

14. Разработка внутреннего и пользовательского интерфейса.

15. Жизненный цикл ИС.

16. Управление качеством проекта создания ИС.

17. Управление рисками проекта создания ИС. Обзор типичных рисков, связанных с внедрением ИС.

18. Итерационное планирование проекта создания ИС.

19. Определение целей проектов разработки и внедрения новой ИС или модернизации существующей ИС.

20. Организация процесса оценки и выбора ИС для организации.

21. Обзор методологий и стандартов в области разработки и внедрения ИС.

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

23. Методики и инструменты современных технологий управления проектами.

24. Календарно-сетевой график выполнения проекта.

25. Современное состояние и тенденции управления проектами в области создания информационных систем.

26. Технологии расчета затрат при создании ИС.

27. Определение экономической и технологической эффективности внедрения ИС.

28. Организационная структура управления проектом. Матрица ответственности.

29. Некорректно поставленные задачи и цели создания ИС.

30. Особенности планирования организации и исполнения проектов создания ИС.

Список литературы.

1. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Методические основы управления ИТ-проектами БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2010

2. Скопин И.Н. Основы менеджмента программных проектов Интернет-университет информационных технологий - ИНТУИТ.ру, 2004

3. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем Интернет-университет информационных технологий - ИНТУИТ.ру, 2008

4. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Управление внедрением информационных систем БИНОМ. Лаборатория знаний, Интернет-университет информационных технологий - ИНТУИТ.ру, 2008

УТВЕРЖДАЮ

Зав.кафедрой __________________

______________________________

«____» _________________ 20___г.

ЗАДАНИЕ

на педагогическую практику

для 6 курса направления 230100 «Информатика и вычислительная техника»

Ф.И.О. (полностью) студента группы МИУ51 (МПС51, МЭС51).

Место прохождения практики: Сибирский государственный аэрокосмический университет им. М.Ф. Решетнева.

Руководитель практики: Суворов Александр Георгиевич (к.т.н., профессор каф. ИУС) или Бочаров Алексей Николаевич (к.т.н., доцент каф. ИУС).

За время прохождения практики необходимо:

1. Изучить вопросы, предусмотренные программой по разделам:

• Инициация ИТ-проекта;

• Планирование ИТ-проекта.

2. Разработать рабочую программу курса «Управление проектами информационных систем».

3. Подготовить и провести лекционные и/или лабораторные занятия:

• Адаптация модели жизненного цикла проекта;

• Разработка технико-экономического обоснования;

• Разработка устава проекта;

• Формирование требований проекта;

• План управления проектом;

• Формирование списка операций проекта;

• Оценка трудоемкости и потребности в ресурсах;

Отчет по практике составить к ___________________________________

Задание выдал: ________________________________________________

Задание принял: _______________________________________________

«____» _______________ 2011 г.

26