ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА Федеральное государственное бюджетное образовательное учреждение высшего образования «МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ ГРАЖДАНСКОЙ АВИАЦИИ» (МГТУ ГА) Кафедра вычислительных машин, комплексов, систем и сетей Н.И. РОМАНЧЕВА УПРАВЛЕНИЕ ПРОЕКТАМИ Утверждено Редакционноиздательским советом МГТУ ГА в качестве учебного пособия Москва- 2016 2 УДК ББК 6Ф7 Р 69 Печатается по решению редакционно-издательского Московского государственного технического университета ГА совета Рецензенты: зам. директора по IT и производству Белов С.Д. (ЗАО «СиренаТрэвел») д-р. техн. наук, доц. А.А. Егорова (МГТУ ГА) Романчева Н.И. Р 69 Управление проектами: Учебное пособие. - М.: МГТУ ГА, 2016.- 72 с., 15 ил., 2 табл., лит.: 16 наим. Учебное пособие содержит материал по дисциплине «Управление проектами в КИС». В учебном пособии рассмотрены основные категории и понятия области управления проектами, современная методология и технология управления проектами, современное программное обеспечение в области управления проектами. В конце каждого раздела учебного пособия приводятся контрольные вопросы. В заключении приведены тестовые вопросы. Учебное пособие издается в соответствии с учебным планом для студентов направления подготовки 09.03.01 «Информатика и вычислительная техника» (бакалавриат) очного обучения. Рассмотрено и одобрено 19 мая 2016г. на заседаниях кафедры ВМКСС и методического совета по направлению подготовки 09.03.01 19 мая 2016 г. Пособие издается в авторской редакции. Печать офсетная 1,86 усл.печ. л. подписано в печать 24.05.16 г. Формат 60х84/16 Заказ № 53 4,5 уч.-изд. л. Тираж 60 экз. Московский государственный технический университет ГА 125993 Москва, Кронштадтский бульвар, д. 20 Редакционно-издательский отдел 125493 Москва, ул. Пулковская, д.6а © Московский государственный технический университет ГА, 2016 3 CОДЕРЖАНИЕ Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5 Часть 1. Теоретические основы управления проектами, программами и портфелями проектов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Современные концепции и стандарты управления проектами, программами и портфелями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.1. Основные понятия и определения. Стандарты . . . . . . . . . . . . . . . . 7 1.1.2 . Организационная культура, ее структура . . . . . . . . . . . . . . . . . . . . .9 1.1.3. Необходимость и оправданность применения проектного подхода . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1.4. Формализация управления проектами . . . . . . . . . . . . . . .. . . . . . . . . 14 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.2. Структура управления проектами. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3. Жизненный цикл проекта. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.4. Модели жизненного цикла проекта . . . . . . .. .. . . . . . . . . . . . . . . . . . . . . . . . . 23 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.5. Процессы управления проектами. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.6. Управление рисками проекта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 38 1.6.1. Идентификация рисков . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. 38 1.6.2. Технологии анализа рисков. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.6.3. Качественный и количественный анализ рисков . . . . . . . . . . . . . . 41 1.6.4. Мониторинг и управление рисками . . . . . . . . . . . . . . . . . . . . .. . . . . . 43 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 1.7. Корпоративное управление проектами. . . . . . . . . .. . . . . . . . . . . . . . . . . . . . .44 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Часть 2. Практические основы управления проектами, программами и портфелями проектов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 2.1. Реализация проекта. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 2.1.1. Конфликты при реализации проектов. . . . . . . . . . . . . . . . . . . . . . . . . 48 2.1.2. Средства мониторинга информационной системы. .. . . . . . . . . . . . . 50 2.1.3.Тестирование. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.2. Управление программами. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.2.1.Определение программы как объекта управления . . . . . . . . . . . . . . . 60 2.2.2. Структура системы управления программой . . . . . . . . . . .. . . . . . . 61 2.2.3. Управление реализацией программ .. . . . . . . . . . . . . . . . . . . . . . . . 62 4 Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Управление портфелями проектов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1. Определение портфеля проектов как объекта управления. . . . . . . . . . . . 2.3.2. Жизненный цикл управления портфелем проектов. . . . . . . . . . . . . . . 2.3.3. Оптимизация и балансировка портфеля проектов . . . . . . . . . . . . . . . . Контрольные вопросы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Итоговый тест . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Используемая литература . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 64 64 65 67 69 70 72 5 ВВЕДЕНИЕ Настоящее учебное пособие строится на материале, который читается для студентов направления подготовки 09.03.01 «Информатика и вычислительная техника» (бакалавриат) очного обучения по дисциплине «Управление проектами в КИС». Управление проектами стала чрезвычайно актуальной и популярной дисциплиной нашего времени. Известны общесистемные источники, а также специальные журнальные статьи, посвященные отдельным аспектам управления проектами. Самым распространенным международным стандартом по управлению проектами является A Guide to the Project Managament Body of Knowledge (PMBOK Guide). Он был разработан Project Management Institute (PMI) как национальный стандарт США и стал в последствии международным стандартом де-факто. Насчитывает четыре редакции, первая редакция вышла в 1987 году, а последняя редакция опубликована в 2008. Вторым по популярности стандартом является международный квалификационный стандарт Международной ассоциации управления проектами (IPMA) - International Competence Baseline (ICB). Документ описывает требования к компетентности владения знаниями в области управления проектами. Последняя версия стандарта - третья, опубликована в 2006 году. Учебное пособие состоит из двух частей, в которых рассмотрены теоретические и практические основы управления проектами, программами и портфелями проектов. Первая часть учебного пособия содержит семь разделов, в которых рассматриваются современные концепции и стандарты управления проектами, программами и портфелями, организационная культура, ее структура. Проводится сравнение функциональной, проектно-ориентированной и матричной организации, выделяются их преимущества и недостатки. Описывается структура и этапы управления проектами, их характеристики и фазы. Рассматриваются вопросы общего взаимодействия проектов управления, управление рисками: идентификация и технологии анализа рисков, качественный и количественный анализ рисков, а также корпоративное управление проектами. Во второй части данного учебного пособия рассмотрены практические основы управления проектами, программами и портфелями проектов: обработка результатов проектирования, дается классификация конфликтов при реализации проектов, рассмотрены средства мониторинга информационной системы и процедура тестирования, приемы и методики разработки коммерческого программного обеспечения. Дается определение портфеля проектов с точки зрения как объекта управления, а также оптимизация и балансировка портфеля проектов. 6 Для контроля качества усвоения материала каждый раздел завершается контрольными вопросами, в конце учебного пособия приведен итоговый тест по рассмотренным темам. Пособие рассчитано на студентов направления подготовки 09.03.01 (бакалавриат) и слушателей высших учебных заведений, обучающихся по техническим дисциплинам. Может быть использовано как при выполнении выпускной квалификационной работы, так и для изучения вопросов, связанных с использованием управления проектами в своей практической деятельности. 7 ЧАСТЬ 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ПРОЕКТАМИ, ПРОГРАММАМИ И ПОРТФЕЛЯМИ ПРОЕКТОВ Современные концепции и стандарты управления проектами, программами и портфелями 1.1.1.Основные понятия и определения. Стандарты Проект - это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов (PMBOK) [1]. Проект - особым образом организованный комплекс действий, направленный на достижение определенной цели, выполнение которого ограничено во времени, а также связано с потреблением конкретных финансовых, материальных и трудовых ресурсов. Программа - это ряд связанных друг с другом проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недоступных при управлении ими по отдельности. Портфель - это набор проектов или программ и других работ, объединенных вместе с целью эффективного управления данными работами для достижения стратегических целей. Операционная деятельность организации - это функция, направленная на непрерывное выполнение действий по производству одного и того же продукта или предоставлению повторяющейся услуги (например, производственные и бухгалтерские операции). Проект КИС предприятия – уникальное временное мероприятия (с определенными датами начала и окончания) по созданию оптимальной корпоративной информационной среды на базе современных информационнокоммуникационных технологий (ИКТ) с целью удовлетворения информационных потребностей предприятия и его подразделений в ходе реализации бизнеспроцессов в пределах ограниченных стоимости, графика и требуемого качества выполнения [9]. Инновационный проект - сложная система взаимообусловленных и взаимоувязанных по ресурсам, срокам и исполнителям мероприятий, направленных на достижение конкретных целей (задач) на приоритетных направлениях развития науки и техники. Информационная система управления проектом - организационнотехнологический комплекс методических, технических, программных и информационных средств, направленный на поддержку и повышение эффективности процессов управления проектом. 1.1. 8 Особенности проекта как объекта управления: комплексность, направленность на достижение целей, ограниченность по времени и ресурсам, уникальность. Ниже приведены обобщенные сравнительные характеристики проектов и текущих операций: проекты: конкретное начало и завершение, временный характер, производство уникального товара или услуги, ресурсы направлены на реализацию проекта, завершение определяется конкретными критериями; - текущие операции: отсутствие конкретного начала и завершения, непрерывность, постоянное производство одного товара или услуги, ресурсы направлены на производство, процесс не имеет завершение. Проектная деятельность требует управления проектами, а операционная деятельность требует управления бизнес-процессами или управления операциями. Проекты могут пересекаться с операциями в различных точках в течение жизненного цикла продукта. Команда Проекта - специфическая организационная структура, возглавляемая руководителем проекта и создаваемая на период осуществления проекта с целью эффективного достижения его целей. Институт управления проектами - всемирная организация, занимающаяся продвижением стандартизованных методов управления проектами в различных промышленных областях. PMBOK Guide (A Guide to the Project Managament Body of Knowledge) международный стандарт по управлению проектами, разработан Project Management Institute (PMI) как национальный стандарт США и стал в последствии международным стандартом де-факто. Насчитывает четыре редакции. Первая вышла в 1987 году, а последняя редакция опубликована в 2008 [2]. ICB (International Competence Baseline) международный квалификационный стандарт Международной ассоциации управления проектами IPMA. Документ описывает требования к компетентности владения знаниями в области управления проектами. Последняя версия стандарта - третья, опубликована в 2006 году. GAPPS (Global Alliance for Projec tPerformance Standards) - Международное объединение по разработке Стандартов управления проектами. Организация занимается разработкой квалификационных стандартов для проектных менеджеров (Global Performance Based Standards for Project Managers). В настоящее время действующей версией данного стандарта является версия 1.7а, выпущенная в октябре 2007 года. Данный Стандарт определяет два уровня компетентности: Global Level 1 (GL1) - "Руководитель проектов"; Global Level 2 (GL2) - "Руководитель проектов высокой сложности". 9 Данные уровни соответствуют разным уровням сложности реализованных проектов, по результатам одного из которых и производится оценка компетентности руководителя проектов. Метод CIFTER (Сrawford-Ishikura factor table for evaluating roles) - метод оценки факторов сложности управления проектом по 4-х бальной шкале. PRINCE2 - британский стандарт, созданный в 1989 году для управления государственными проектами в области информационных технологий. Последняя версия стандарта опубликована в 2002 году. Project & Program Management (P2M) - японский стандарт, привлекающий все больше внимания со стороны специалистов всего мира. В основе модели P2M лежит тесная связь между стратегией организации и путями ее реализации через проекты. C-PMBOK - видоизмененный под реалии Китая PMBOK. Первая версия стандарта опубликована в 2002 году. Этот документ используется в качестве руководства для профессионалов в управлении проектами при подготовке к сертификации. НТК СОВНЕТ - национальные требования к компетенции (Россия). Документ является базой для проведения квалификационной сертификации менеджеров. В основе лежат Международные требования к компетенции специалистов по управлению проектами - International Competence Baseline (ICB), развиваемые IPMA. 1.1.2. Организационная культура, ее структура Управление проектами используется практически во всех отраслях экономики и промышленности, в том числе в гражданской авиации. В условиях жесткой экономии организации и компании начинают понимать важность привлечения профессиональных менеджеров проектов, и стремятся обеспечить гарантии успеха предпринимаемого проекта. Обеспечение совместной работы всех подразделений и всех пользователей информации на основе единого хранилища данных и организация комплексного информационного обеспечения управления всеми бизнес-процессами данного предприятия реализуется в настоящее время в корпоративных информационных системах. Современная интенсификация технологического развития предопределяет повышение требований устойчивости средств и систем к влиянию внешних факторов. Статистика появления сбоев в системах управления показывает, что изза невозможности строгой алгоритмизации воздействия «человеческого фактора» на работу автоматизированных систем наименее надежными принято считать элементы на «ручном управлении». Для повышения рациональности использования людских ресурсов, рассмотрим автоматизированную систему как киберсоциальную (КСС) [7]. 10 Киберсоциальной будем называть человеко-машинную систему (ЧМС), которая включает в себя компьютерные средства, обладающие интеллектом. Наличие в системе управления технологическим процессом интеллектуальных программно-технических средств позволяет давать рекомендации оператору по адаптации его решений к изменяющимся внешним условиям, что влияет на живучесть управляемого объекта. Особенностью киберсоциальной системы является учет ограничений на скорость и полноту адаптации элементов системы управления, определяемых не только параметрами IT-средств, но и компетенциями специалистов, участвующих в управлении технологическим процессом. В настоящее время практически любая ЧМС характеризуется сочетанием технологических и экономических параметров, а также психофизиологическими данными операторов и администрации (как активных элементов). В качестве инварианта, позволяющего учитывать разнообразие характеристик каждого из агентов, используется информация. Собственно процесс создания функционального модуля рассмотрим в виде цикла информационной передачи, определяемого работой агентов: Разработчик, Производитель, Потребитель. Разработчик передает конструктивно-технологические решения создаваемого модуля Производителю. Производитель изготавливает предложенную ему конструкцию и передает еѐ Потребителю. Потребитель вводит функциональный модуль в использование и по результатам эксплуатационных испытаний дает техническое задание Разработчику на усовершенствование предложенных им решений. Выделим два контура взаимосвязи названных агентов (рис 1.1): АгентАгентРазработчик Разработчик Конструктивнотехнологические решения cоздаваемого модуля АгентАгентПроизводитель Производитель Изготовление предложенной конструкции АгентАгентПотребитель Потребитель Ввод в эксплуатацию, ТЗ на усовершенствование решения Рис.1.1. Информационная модель КСС 1) экономический. Сообщения, между агентами, включают в себя экономические характеристики связей. Каждая из таких связей определяет 11 финансовую заинтересованность агента, передающего сообщение, в обеспечении функциональной надежности данной связи в цикле «производство – внедрение». Замкнутость рассматриваемого контура определяет наличие отрицательной обратной связи, которая обеспечивает устойчивость работы цикла. Эффективность построения этого контура определяется классическими методами принятия решений в экономике. 2) психологический. Сообщения, определяемые психологическими характеристиками связи между агентами цикла. Наличие таких характеристик является важной причиной установления экономических связей. Улучшение социальных отношений между агентами ведет к повышению эффективности экономических связей (в 1-м контуре), что, в свою очередь, является стимулом для повышения связей во 2-м контуре и т.д. Таким образом, наличие положительной обратной связи определяет возможность развития информационного взаимодействия между агентами (при наличии необходимых ресурсов). Каждая структура предприятия имеет свои достоинства и недостатки. Менеджер проекта должен хорошо знать организацию, в которой работает. Организации и их культура также уникальны, как и сами проекты [11]. Выделяют следующие базовые структуры компаний: функциональную, проектную и матричную. Наиболее традиционной является функциональная структура компании. Проектные организации ориентированы на выполнение проектов. Матричная структура совмещает качества функциональной и проектной культур. Функциональные организации структурированы таким образом, чтобы рассредоточить сходные операции по отделам. Корпоративная культура функциональной организации обычно диктует строгое соответствие иерархической структуре подчинения. Функциональная организация имеет следующие преимущества: - четкая структура подчинения: участники проектной группы подчиняются одному руководителю и ясно понимают структуру подчинения; - единая группа: члены группы хорошо знают друг друга, так как работают в одном структурном подразделении. Поскольку их способности и достоинства также хорошо известны, распределение работ значительно упрощается; - распределение функций: такая структура позволяет сотрудникам оттачивать профессиональное мастерство и со временем становиться экспертами. К недостаткам функциональной организации следует отнести: - конкуренция ресурсов: при выполнении множества задач и проектов ресурсы отдела (структурного подразделения) истощаются, что негативно сказывается на эффективности работы; - полномочия менеджеров проектов ограничены, так как обычно они вынуждены полагаться только на свои навыки ведения переговоров с функциональными менеджерами для выделения ресурсов; 12 - бюрократическая прослойка: иерархическая структура тормозит выполнение проекта из-за необходимости множества согласований для принятия решений; - менеджеры проектов одновременно выполняют функции функциональных менеджеров: такая организация часто отвлекает внимание менеджера на несколько направлений сразу, что приводит к небрежному выполнению работы. Структура проектно-ориентированной организации сосредоточена не на работе функционального отдела, а непосредственно на проекте. Менеджер проекта чаще всего напрямую подчиняется заместителю или главному лицу компании (предприятия). Все сотрудники группы проекта подотчетны непосредственно менеджеру проекта, и в их обязанности входят только те задачи, которые напрямую связаны с проектом. Вся проектная группа, как правило, расположена в одной проектно-ориентированной среде. Следует заметить, что проектно-ориентированные структуры могут существовать внутри функциональной организации. Проектно-ориентированная организация имеет следующие преимущества: - менеджеры проектов обладают самыми высокими полномочиями: члены группы подчиняются только одному руководителю и ясно понимают структуру руководства. Проектные группы, как правило, размещены совместно, что значительно упрощает взаимодействие; - менеджеры проектов принимают решение самостоятельно: это конкретизирует взаимодействие, решение проблем и расстановку приоритетов. Решения принимаются именно на этом уровне; - организация ориентирована на проектные работы: все ресурсы сосредоточены на проекте и проектных работах. К проекту и менеджеру проекта проявляется особая лояльность. Проектно-ориентированная организация имеет следующие недостатки: - простои: специалисты узкой квалификации могут быть востребованы только на определенное время для выполнения особых проектных работ. В такой организации трудно решить вопрос из занятости в течение всего остального времени; - конкуренция: при формировании проектных групп и получении материалов менеджеры проектов ведут борьбу внутри организации за лучше ресурсы. Это может негативным образом сказаться на внешнем потребителе; - перераспределение членов проектной группы: после завершения проекта сотрудники группы должны искать другую работу, так как не всегда сразу появляются новые проекты. Матричная организация - тип организационной структуры, где все сотрудники подчиняются многочисленным менеджерам, включая одного функционального и, как минимум, одного проектного. Матричные организации 13 совмещают достоинства функциональных и проектно-ориентированных структур, сглаживая их недостатки. Основным недостатком таких структур является подчинение проектной группы разнообразным менеджерам (многоначалие). 1.1.3. Необходимость и оправданность применения проектного подхода Термин "управление проектами" традиционно ассоциируется с сетевыми графиками и настольными приложениями типа MS Project. С помощью подобных инструментов можно описывать какие-то отдельные аспекты. Однако в современных условиях актуальной является выработка комплексной моделей проектной деятельности и методов ее описания. В [10] отмечается, что электронизация бизнеса и коммерции требует нового взгляда на проблему управления проектами. Речь идет о том, что от управления проектами необходимо переходить к поддержке проектной деятельности как важнейшей составляющей бизнеса. В современном бизнесе существует ряд глобальных тенденций, позволяющих говорить о его "проективизации", т.е. возрастании доли и значения деятельности, связанной с осуществлением проектов. Важнейшими среди них являются: - переход от регулирования и концентрации к координации и распределенности; - сокращение жизненного цикла изделий и услуг, в особенности сроков разработки и запуска; - персонализация спроса и предложения, продуктов и услуг. С учетом тенденции "проективизации" бизнеса можно предположить, что поддержка проектной деятельности должна стать центральным элементом корпоративной информационной системы. Это означает отход от "ERPцентризма", который господствовал до настоящего времени. Например, в интегрированных ERP-системах, таких как Axapta, присутствует более-менее развитый модуль управления проектами, обычно ориентированный на решение задач проектного учета и контроля. Как правило, на уровне экспорта-импорта поддерживается возможность использования популярных настольных систем управления проектами. Кроме того, на рынке появляются мощные системы поддержки проектной деятельности, реализованные современной вебархитектурой, например, Maconomy. Они содержат возможности управления знаниями, детальную ролевую проработку, множество других полезных функций, отсутствующих в проектных модулях ERP-систем. В ближайшее время следует ожидать изменения подхода к построению информационных систем для проектного бизнеса, основанных на современной системной архитектуре, хорошо масштабируемых и доступных по цене, учитывающих его особенности: - интеллектуалоемкий характер предметной области большинства проектов; 14 - малая доля в проектах хозяйственной деятельности, связанной с материальными активами; - сильная зависимость успеха проектов от внешних условий, прежде всего поведения заказчика; - повышенные риски, включая риск нарушения сроков и бюджета, прекращения либо приостановки проекта, неудачного внедрения; - повышенные требования к качеству, имеющие конструктивный, т. е. объективно проверяемый характер; - высокая степень индивидуализации "под клиента" и большое значение организации "плотной" работы с ним; - высокая вероятность появления новых, ранее не выполнявшихся работ, для которых методология, технология и система управления создаются "на лету"; - высокие требования к квалификации менеджеров и исполнителей, их высокая стоимость; - критическая важность корпоративной офисной системы, поддерживающей - особый характер бюджетирования, планирования, контроля и учета; - большая неравномерность поступления заказов, затрудняющая управление людскими ресурсами; - географическая удаленность клиента; - коммуникации и базу знаний; - наличие нескольких исполнителей и их географическая распределенность. Следует отметить первостепенную важность для проектного бизнеса проблемы людских ресурсов (как менеджеров, так и специалистов) во всех ее аспектах. 1.1.4. Формализация управления проектами В области управления крупными проектами, программами и мультипроектами обязательна формализация начала проекта в виде принятия его участниками (прежде всего заказчиком продукта проекта) документа, определяющего начало работ по проекту. Наличие такого документа на этапе инициации проекта позволит избежать некоторых проектных рисков, таких как неадекватное понимание масштабов проекта, «расползание» целей проекта, нерегулярность финансирования, дезинтеграция механизмов управления проектом. Документ, инициирующий работы по проекту, должен быть своевременно разработан и принят к действию. Для масштабных проектов крупных компаний разработка модели управления подобным проектом является весьма трудоемкой операцией. Решение данной проблемы достигается при помощи этапности разработки: сначала определяются основные цели, масштабы и участники проекта и это надлежащим образом документируется, затем - отрабатываются остальные необходимые вопросы инициации проекта. 15 Условное наименование документа первого этапа инициации работ проекта - «паспорт проекта». Паспорт проекта, помимо перечисленных разделов, может содержать указание сроков начала и окончания проекта, структуру и персоналии руководящих ролей в проекте, перечень первоочередных задач по выполнению проекта и другие характеристики проекта. Появление утвержденного руководством компании паспорта проекта способствует закреплению статусу проекта и началу полномасштабного хода работ по проекту. Развитием паспорта проекта должен явиться Устав (комплекс уставов) проекта. Устав проекта – официальный документ, санкционирующий начало проекта, он уполномочивает менеджера проекта приступить к его реализации и определяет необходимые проектные ресурсы. В уставе проекта необходимо уточнить и декомпозировать цели проекта, организационную структуру управления проектом, определить условия и основные этапы реализации проекта, описать методики, процессы и основные задачи управления проектом. Устав проекта должен рассматриваться и утверждаться кураторами проекта - представителями топ-менеджмента компании. При этом Устав является для руководителя проекта основанием по организации работ по достижению целей проекта и формирования системы управления проектом, а для подразделений компании - нормативным документом. Для подрядных организаций - участников проекта устав проекта носит рекомендательный характер, и обязательства, определяемые договорными документами по проекту не должны ему противоречить. При создании раздела Устава проекта, определяющего процессы управления проектом и функции, должен активно использоваться инструментарий организационного проектирования, в первую очередь матрицы разделения административных задач управления. Упрощенная структура разделов устава может выглядеть следующим образом: 1. Характеристика проекта: сведения о проекте, цели проекта, структура проекта - общее описание структуры проекта, реквизиты подпроектов; 2. Масштаб проекта: участники (группы участников) проекта, результаты проекта, ограничения (условия реализации) проекта; 3. Основные этапы и сроки реализации проекта; 4.Финансирование проекта; 5. Организационная структура управления проектом: общее описание организационной структуры управления проектом, распределение ответственности, функций и полномочий по управлению проектом; 6. Процессы управления проектом. Приложениями к уставу проекта могут быть самые различные документы, определяющие предметную область проекта. 16 Контрольные вопросы 1) Что можно назвать проектом? 2) Перечислите преимущества организации качественного процесса работы? 3) В чем состоит преимущество проектных организаций? 4) По каким критериям определяются цели проекта? 5) Сформулируйте цель устава проекта. 6) Где документируются функции и обязанности заинтересованных лиц? 7) Перечислите особенности современного проектного бизнеса. 8) Перечислите достоинства и недостатки базовых структур компаний: функциональной, проектной и матричной. 1.2. Структура управления проектами Структуру управления проектами можно представить в виде трех основных блоков: субъекты управления, объекты управления, процессы управления проектами. Каждый из этих блоков имеет иерархическую структуру (рис.1.2). Рассмотрим более подробно. 1. Объекты управления - объектами управления могут быть: - проекты, - программы, - организации, - системы. В свою очередь, каждый из объектов управления имеет свои цели, стратегии, структуру, фазы жизненного цикла, окружение и т.д. 2. Субъекты управления проектами - субъектами управления проектами являются участники проекта (программы), взаимодействующие при выработке и принятии управленческих решений. К субъектам управления проектом относятся: - ключевые участники проекта: • инвестор, • заказчик, • генконтрактор, • генподрядчик, • исполнители и др. - команда управления проектом: • управляющий проектом, • члены команды проекта, • прочие участники проекта. 3. Процессы управления осуществлением проекта - процессы управления проектами реализуются посредством прямой и обратной связей между субъектами и объектами управления. Процесс управления также имеет иерархическую 17 структуру, в основании которой лежат отдельные задачи и процедуры управления проектом. Каждая из задач управления проектом относится к определенной стадии процесса управления, функциональной подсистеме, временному разрезу, объекту и субъекту управления. Управление проектом Субъекты Субъекты управления управления Менеджер Менеджер проекта проекта Функциональные менеджеры проекта Объекты управления Проекты и программы Фазы жизненного цикла объекта управления Процесс управления Уровни управления Функции управления Стадии процесса управления Рис.1.2. Структура управления проектами Процесс управления может быть структурирован основаниям: Стадии процесса управления: - инициация – организация и запуск проекта и его частей, - планирование работ проекта, - организация и контроль выполнения работ проекта, - анализ и регулирование хода работ проекта, - закрытие проекта и его частей. по следующим 18 Функции управления: - управление предметной областью проекта, - управление проектом по временным параметрам, - управление стоимостью в проекте, - управление качеством в проекте, - управление рисками в проекте, - управление персоналом в проекте, - управление коммуникациями в проекте, - управление контрактами в проекте, - управление изменениями в проекте, - прочие функции управления. Уровни управления, рассматриваемые с точки зрения временного разреза управления проектом, который, как правило, соотносится с соответствующими субъектами управления: - стратегический уровень охватывает весь жизненный цикл проекта и соответствует организационно-экономическому уровню проекта, - годовой уровень управления рассматривает работы проекта, выполнение которых запланировано в течение года, - квартальный уровень управления рассматривает работы проекта, выполнение которых запланировано в течение квартала, - оперативный уровень управления рассматривает работы проекта, выполнение которых соответственно запланировано в течение месяца, декады, недели, суток, смены и т.д. Каждая задача управления проектом однозначно определяется компонентами всех уровней структуры, логично взаимосвязанных «снизу вверх». Структура управления проектом включает в качестве основного элемента свернутое дерево избыточного множества задач и процедур, которые теоретически могут осуществляться при управлении проектом. В целом можно сказать, что для описания структуры проектов могут использовать следующие технологии: - структурные кооперативные списки; - структурные иерархические списки; - графические структурные схемы – обычные и блочные; - сетевые графики первого и второго рода; - матрицы и схемы связей; - диаграммы Ишикавы. Эти технологии предназначены для представления как иерархической, так и кооперативной структуры проектов. Обзор технологий описания структуры проектов представлен в [11]. 19 а Гр я ем ик ф Вр О бъ е би м а з н вт ес ом -п ат П ро из ро це ир из сс уе во ов мы ди х те ль но ст ь Целью управления проектом КИС предприятия является создание качественной информационной системы при оптимальном соотношении затрат и времени ее проектирования и внедрения. Говоря другими словами, задача проекта - достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника» (рис.1.3). Это означает, что ни один из углов треугольника не может быть изменен без оказания влияния на другие. Например, чтобы уменьшить время, потребуется увеличить стоимость и/или сократить содержание. Задача главного менеджера проекта КИС – уравновешивать такие параметры проекта, как производительность (объем автоматизируемых бизнеспроцессов), время (график) и стоимость (ресурсы). Качество Стоимость Ресурсы Рис.1.3. Треугольник менеджмента проекта КИС График, бюджет и качество чаще подвержены изменениям в процессе реализации проекта, поэтому руководитель проекта вынужден выбирать только один или два параметра для оптимизации из следующих: стоимость, время, качество, производительность. Согласно текущей редакции стандарта PMBOK, проект считается успешным, если удовлетворены все требования заказчика и участников проекта. Поэтому у проекта разработки КИС сегодня не три, а четыре фактора успеха: - выполнен в соответствие со спецификациями; - выполнен в срок; - выполнен в пределах бюджета; - каждый участник команды уходил с работы с чувством успеха. Контрольные вопросы 1) Какие параметры включает треугольник менеджмента ИТ-проекта? 2) Какова цель управления проектом КИС предприятия? 3) Перечислите элементы структуры проекта. 20 4) Назовите объекты и субъекты структуры проекта. 5) Сформулируйте основные задачи каждого из процессов управления проектом. 6) Перечислите факторы успеха проекта. 1.3. Жизненный цикл проекта Жизненный цикл проекта – это совокупность этапов создания и использования проекта, отражающая его различные состояния, начиная с момента возникновения идеи о создании проекта и заканчивая моментом завершения. Одно из требований сегодняшнего дня - это создание продукта (ИС, программу и т.д.) в короткие сроки, но с сохранением высокого качества разработки. Баланс между скоростью и качеством достигается за счет стандартизации методов и методологий создания такого продукта. В основе такой методологии лежит «пошаговый подход», который определяет этапы жизненного цикла, их последовательность, контрольные точки, а также правила выполнения каждого этапа. Достаточно большое количество факторов влияет на характеристику жизненного цикла проектов. К таким факторам влияния можно отнести четыре основных: тип проекта, финансовые возможности, технологические особенности реализации проекта и выбранная стратегия реализация проекта. Укрупнено жизненный цикл проекта включает начальную, промежуточную, завершающую фазы. Под термином фаза понимается документированная часть проекта, завершающаяся получением определенного результата. На рис.1.4. представлены фазы жизненного цикла (ЖЦ) управления проектом. Выделяют следующие основные этапы жизненного цикла проекта: - анализ требований (начальная стадия); - разработка (поэтапный процесс исполнения проекта); - реализация (отладка и тестирование); - эксплуатация и сопровождение (завершающая стадия). Начальная фаза. Главным содержанием работ на этой фазе является разработка концепции проекта, включающая: - сбор исходных данных и анализ существующего состояния (предварительное обследование); - выявление потребности в изменениях (проекте); - определение основных параметров и характеристик проекта: цели и стратегия их достижения, задачи, результаты; основные требования, ограничительные условия, критерии; уровень риска; окружение проекта, потенциальные участники; требуемые время, ресурсы, средства и др. 21 Исполнение Инициация Планирование Завершение Контроль (администри рование) Начальная фаза Промежуточная фаза Завершающая фаза Рис.1.4. Фазы ЖЦ управления проектом - определение и сравнительная оценка альтернатив; - представление предложений, их апробация и экспертиза; - утверждение концепции и получение одобрения для следующей фазы. Фаза разработки. Главным содержанием этой фазы является разработка основных компонент проекта и подготовка к его реализации. Общее содержание работ этой фазы: - назначение руководителя проекта и формирование команды проекта, в первую очередь ключевых членов команды; - установление деловых контактов и изучение целей, мотивации и требований заказчика и владельцев проекта, других ключевых участников; - развитие концепции и разработка основного содержания проекта: конечные результат(ы) и продукт(ы); стандарты качества; структура проекта; основные работы; требуемые ресурсы. - структурное планирование, в том числе: декомпозиция проекта; календарные планы и укрупненные графики работ и обеспечения; смета и бюджет проекта; потребность в ресурсах; процедуры управления проекта и техника контроля; определение и распределение рисков. - организация и проведение торгов, заключение субконтрактов с основными исполнителями; 22 - организация выполнения базовых проектных и опытно-конструкторских работ по проекту; - представление проектной разработки; - получение одобрения на продолжение работ. Фаза реализации проекта. Главное содержание этой фазы следует из ее наименования - выполнение основных работ проекта, необходимых для достижения цели проекта. Основными работами этой фазы являются: - организация и проведение торгов, заключение контрактов; - полный ввод в действие разработанной системы управления проектом; - организация выполнения работ; - ввод в действие средств и способов коммуникации и связи участников проекта; - ввод в действие системы мотивации и стимулирования команды (участников) проекта; - детальное проектирование и технические спецификации; - оперативное планирование работ; - установление системы информационного контроля над ходом работ; - организация и управление материально-техническим обеспечением работ, в том числе запасами, покупками, поставками; - выполнение работ, предусмотренных проектом (в том числе производство строительно-монтажных и пусконаладочных работ); - руководство, координация работ, согласование темпов, мониторинг прогресса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта: ход работ, их темпы; качество работ и проекта; продолжительность и сроки; стоимость и другие показатели; - решение возникающих проблем и задач. Завершающая фаза или окончание проекта. На этой фазе достигаются конечные цели проекта, осуществляется подведение итогов и разрешение конфликтов и закрытие проекта. Основное содержание работ этой фазы, как правило, состоит в следующем: - планирование процесса завершения проекта; - эксплуатационные испытания окончательного продукта(ов) проекта; - подготовка кадров для эксплуатации создаваемого объекта; - подготовка документации, сдача объекта и конструкторской продукции заказчику; - оценка результатов проекта и подведение итогов; - подготовка итоговых документов; 23 - закрытие работ и проекта; - разрешение конфликтных ситуаций; - реализация оставшихся ресурсов; - накопление фактических и опытных данных для последующих проектов; - расформирование команды проекта. Последние три фазы могут выполняться с совмещением работ во времени - по последовательно-параллельной схеме. Описания жизненных циклов проектов могут быть как весьма обобщенными, так и в высшей степени подробными. Очень подробные описания жизненных циклов проектов могут включать формы, диаграммы и контрольные списки в целях структурирования и управления. Переход из одной фазы в другую в пределах жизненного цикла проекта обычно подразумевает некую форму технической передачи или сдачи результатов, и часто именно это указывает на переход от фазы к фазе, то есть фаза проекта характеризуется завершением и одобрением одного или нескольких результатов поставки. Результат поставки - это измеримый, проверяемый продукт работы, например спецификация, отчет по анализу осуществимости, детальный план или опытный образец. Создание одних результатов поставки определяется процессом управления проектом, а другие могут быть конечными продуктами или элементами конечных продуктов, ради которых создавался проект. Результаты поставки, а значит и фазы, являются частью общего последовательного процесса, предназначенного для обеспечения необходимого контроля над проектом и получения нужного продукта или услуги, которые являются целью проекта. Контрольные вопросы 1) Что понимается под жизненным циклом проекта? 2) Какие факторы влияют на ЖЦ проекта? 3) Перечислите основные этапы ЖЦ проекта. 4) Поясните термин «фаза» ЖЦ проекта. 5) Какое преимущество дает стандартизация методов и методологий создания продуктов или услуги, как конечной цели проекта? 1.4. Модели жизненного цикла проекта При реализации проекта КСС одной из важных задач является выбор модели жизненного цикла. Для решения этой задачи необходимо определить критерии выбора, которые охватывают: требования к системе, участников команды разработчиков, коллектив пользователей, тип проекта. Модель жизненного цикла - структура, содержащая процессы, действия, задачи, которые осуществляются в ходе разработки, функционирования и 24 сопровождения продукта в течение всей жизни системы: от определения требований к системе до завершения ее использования. Существуют различные модели жизненного цикла: классическая (каскадная или водопадная), V-образная, быстрого проектирования, спиральная. Существуют и другие модели и методологии, такие как разработка на основе тестирования (Test Driven Development), рациональный унифицированный процесс разработки (RUP), методология «чистой комнаты» (Cleanroom) и др. Тем не менее, все эти модели также могут быть отнесены к каскадной (водопадной) модели, поскольку они являются последовательными, обладая при этом четкой границей между этапами, так же, как и этапы гибкой и итеративной моделей, периодически повторяются, при этом граница между этапами не так ясно выражена. Перечисленные модели отличаются порядком выполнения этапов и критериями перехода от одного этапа к другому. 1) Каскадная (водопадная) модель. Данная модель является традиционным методом и использовалась специалистами по программному инжинирингу наиболее активно в 70-80 годы прошлого века, доказав при этом свои преимущества в способности предоставления своевременных результатов. Более того, согласно публикации 1998 года (Standard 2167A), Министерство обороны США активно поддерживало использование данного метода во всех своих проектах. Каскадная (водопадная) модель - это последовательный метод разработки с четко определенными выходными продуктами на каждом этапе. Многие специалисты в исследуемой области до сих пор строго выполняют анализы ревизий для того, чтобы обеспечить наличие удовлетворительных входных критериев для перехода к следующему этапу. Отличительным свойством каскадной (водопадной) модели является то, что она представляет собой разновидность разработки «сверху вниз». Она состоит из независимых фаз, выполняемых последовательно. Переход на следующий этап осуществляется в случае полного окончания работ, проделанных на предыдущем этапе. Основными этапами каскадной (водопадной) модели являются: анализ требований, проектирование, разработка, тестирование и эксплуатация. На рис.1.5 приведена полная версия каскадной модели жизненного цикла информационной системы (ИС). Преимущества каскадной модели: - хорошо известна заказчикам и конечным пользователям (часто используется для различных проектов, не связанных с разработкой программного обеспечения); - последовательно реализует этапы работ; - доступна для понимания, проста и удобна в эксплуатации, так как процесс разработки выполняется поэтапно; 25 Исследование концепции Исследование системы Требования Проектирова ние Разработка Внедрение Установка Эксплуатация и поддержка Сопровождение Вывод из эксплуатации Рис.1.5. Каскадная модель ЖЦ ИС - процедуры по контролю качества выполняются поэтапно; - эффективна, когда требования к качеству доминируют над требованиями к затратам и графику выполнения проекта; - позволяет участникам проекта, завершившим действия на выполняемой ими фазе, приступить к реализации других проектов; - ход выполнения проекта легко проследить с помощью временной шкалы (или диаграммы Ганта). В случае ошибочного выбора каскадной модели для реализации проекта могут проявиться следующие недостатки: - сложность в определении выполненного объема работ по проекту; - не отображает процессы, направленные на разрешение проблем; - в основе лежит последовательная линейная структура процесса разработки, в результате возврат к предыдущим шагам для решения возникающих проблем приводит к увеличению затрат и нарушению графика работ; - отсутствует возможность поэтапного внедрения системы; - невозможность гибкого моделирования систем, не имеющих аналогов; - модели необходимы жесткое управление и контроль, т.к. в ней не предусмотрена возможность модификации требований; - невозможность предварительной оценки качества системы пользователем; 26 - модель основана на документации, что предполагает избыточность документов. Ограничение области применения каскадной модели определяется ее недостатками. Ее использование наиболее эффективно в следующих случаях: - требования к системе четко определены и неизменяемы в течение ЖЦ, а методы их реализации известны и уже апробированы на практике; - при разработке проекта, ориентированного на построение системы или продукта такого же типа, как уже разрабатывались разработчиками ранее; - при разработке новой версии уже существующего продукта или системы, когда вносимые изменения определены и управляемы; - при разработке проекта, связанного с переносом уже существующего продукта на новую платформу; - при выполнении масштабных проектов, в которых задействовано несколько больших команд разработчиков. 2) V-образная модель V-образная модель является разновидностью каскадной модели. Имеет последовательную структуру, при которой каждая фаза начинается и завершается после завершения предшествующей. При этом учитываются взаимосвязи фаз тестирования (верификация, аттестация) с фазами проектирования киберсоциальной системы (рис.1.6). Проектирование проекта Эксплуатация КСС Анализ и спецификация требований Комплексное системное тестирование Разработка архитектуры КСС Интеграция и тестирование Покомпонентное тестирование Детальная разработка Кодирование Рис. 1.6. V-образная модель ЖЦ КСС В настоящее время имеется несколько методологий разработки программного обеспечения, которые можно рекомендовать при использовании спиральной модели жизненного цикла. Наиболее известными из них являются методология быстрой разработки приложений (Rapid Application Development, RAD) и экстремальное программирование (eXtreme Programming, XP – автор Кент Бек, 1999). 27 3) Модель RAD. На начальном этапе существования компьютерных информационных систем их разработка велась на традиционных языках программирования и подразумевала, как правило, ручной набор текстов программ. Однако по мере возрастания сложности разрабатываемых систем и увеличения запросов пользователей потребовались новые средства, обеспечивающие значительное сокращение сроков разработки. Это послужило предпосылкой к созданию инструментальных средств для быстрой разработки приложений. Развитие этого направления привело к появлению на рынке разработки программного обеспечения средств автоматизации практически всех стадий жизненного цикла. Под RAD-разработкой обычно понимается процесс разработки, содержащий три элемента: - небольшую команду программистов (до 10 человек); - короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев); - повторяющийся цикл, при котором разработчики по мере того, как приложение начинает обретать форму, реализуют в продукте требования, полученные через взаимодействие с заказчиком. Модель RAD (рис.1.7) включает следующие фазы: Планирование требований Пользовательское описание Конструирование Ввод в эксплуатацию Рис.1.7. Модель RAD - планирование требований – структурный анализ и обсуждение с заказчиком реализуемых коммерческих задач; пользовательское описание – выполняется сбор пользовательской информации и построение моделей процессов предметной области с 28 использованием автоматизированных инструментальных средств при активном участии заказчиков; - конструирование - выполняется детализированное проектирование, включающее разработку (кодирование и тестирование) системы, а также поставку заказчику программного продукта; - ввод в эксплуатацию – проведение совместно с заказчиком приемочных испытаний, установка системы и обучение пользователей. Помимо особенностей, характерных для спиральной модели жизненного цикла, методология RAD подразумевает использование на каждой итерации: - CASE2-средств для формирования и анализа требований, проектирования системы, автоматической генерации кода программ и структуры БД, а также автоматического тестирования программного обеспечения; - инструментальных средств, обеспечивающих визуальную разработку (программирование) системы; - инструментальных средств, поддерживающих объектно-ориентированный подход. Эти средства позволяют создать описание предметной области в виде совокупности объектов - сущностей реального мира, характеризуемых свойствами (атрибутами) и поведением (методами); инструментальных средств, обеспечивающих событийное программирование. Каждый объект, входящий в состав приложения, может генерировать события и реагировать на события, генерируемые другими объектами; - шаблонов и библиотек готовых решений, как собственной разработки, так и сторонних производителей. Модель RAD применима для относительно небольших проектов, разрабатываемых под конкретного заказчика, требования которых хорошо известны и неприменима для построения сложных приложений, от которых зависит безопасность людей (например, управление самолетом), так как итеративный подход предполагает, что первые несколько версий, скорее всего не будут полностью работоспособны, что в данном случае исключается. 4) Спиральная модель жизненного цикла разработки КСС впервые была представлена доктором Барри Боэмом и опубликована в 1988 году. Она представляет собой процесс разработки, сочетающий в себе как проектирование, так и прототипирование с целью сочетания преимуществ каскадной модели. Кроме того, в нее включены анализ и управление рисками, процессы поддержки и управления, предусмотрены возможности использования прототипирования и быстрой разработки приложений. Базовая концепция спиральной модели заключается в следующем. Каждый цикл разработки (итерация) представляет собой набор операций, соответствующий шагам в каскадной модели. При этом учитываются каждый 29 компонент продукта или системы и каждый уровень сложности, начиная с общего анализа требований и заканчивая программированием каждого компонента. В варианте классической спиральной модели Боэма, ориентированной на работы процесса разработки программного обеспечения модель поделена на четыре квадранта (рис. 1.8) [9]. В каждый квадрант модели входят основные и вспомогательные действия по разработке продукта или системы. В квадранте 1 - анализ требований, альтернативных вариантов и ограничений - определяются рабочие характеристики, выполняемые функции, стабильность (возможность внесения изменений), аппаратно-программный интерфейс. Определяются альтернативные способы реализации системы (разработка, повторное использование компонент, покупка, договор подряда и т.п.). Определяются ограничения, налагаемые на применение альтернативных вариантов (затраты, график выполнения, интерфейс, ограничения среды и др.). Определяются риски, связанные с недостатком опыта в данной предметной области, применением новой технологии, жесткими графиками, недостаточно хорошо организованными процессами. В квадранте 2 - оценка альтернативных вариантов, идентификация и разрешение рисков - выполняется оценка альтернативных вариантов, рассмотренных в предыдущем квадранте; оценка возможных вариантов разрешения рисков. Выполняется прототипирование как основа для работ следующего квадранта. Рис.1.8. Классическая спиральная модель Боэма 30 В квадрант 3 - разработка продукта текущего уровня - включаются действия по непосредственной разработке системы или программного продукта: проектирование системы и ее программных компонентов, разработка и тестирование исходных текстов программ, интеграция тестирование и квалификационные испытания продукта или системы и т.п. В квадранте 4 - планирование следующей фазы - выполняются действия, связанные с разработкой планов проекта, управления конфигурацией, тестирования, установки системы. Работа над проектом в соответствии со спиральной моделью начинается с определения заказчиком потребности в разработке системы или программного продукта (центр квадранта 1). Первая создаваемая версия системы основывается на предварительных требованиях заказчика. Затем начинается планирование следующего цикла, учитывающее требования и пожелания заказчика, сформулированные им по результатам работ соответствующего уровня 3-го квадранта. Каждая последующая версия более точно воплощает требования заказчика. Степень вносимых изменений от одной версии программы к следующей уменьшается с каждой новой версией. В результате получается конечная система (программный продукт). Для каждого цикла модели анализируются требования, альтернативные варианты и ограничения, определяются и разрешаются риски, разрабатывается версия продукта или системы этого цикла спирали и подтверждается ее правильность; планируется следующий цикл и выбираются методы его осуществления. В конце каждого цикла осуществляется оценка его результатов, по результатам которой выполняется либо переход к следующему циклу, либо в случае необходимости повторное выполнение цикла. Количество итераций модели выбирается в соответствии со сложностью проекта. Под итерацией понимается законченный цикл разработки, приводящий к выпуску некой сокращенной версии системы, которая расширяется от итерации к итерации, чтобы стать законченной системой [12]. Работы каждой итерации должны бать адаптированы под конкретный проект. Программирование в спиральной модели выполняется значительно позже, чем в других моделях. Это позволяет минимизировать риски посредством последовательных уточнений требований, выдвигаемых пользователем. На каждой итерации рассматривается один или несколько главных факторов риска, начиная с фактора наивысшего риска. Типичные риски включают в себя неправильно истолкованные требования, архитектуру, потенциальные проблемы эксплуатации продукта или системы, проблемы в технологии и т.д. При использовании спиральной модели при выполнении соответствующего ей проекта проявляются следующие ее преимущества: 31 - наличие действий по анализу рисков, что обеспечивает их сокращение и заблаговременное определение непреодолимых рисков; - обеспечение разбиения большого потенциального объема работ по выполнению проекта на небольшие части; - первоочередность реализации решающих функций с высокой степенью риска, что позволяет при необходимости остановить работы над проектом на ранних циклах модели и уменьшить расходы; - возможность гибкого проектирования, основанная на преимуществах каскадной модели при одновременном разрешении итераций; - реализация преимуществ инкрементной модели (выпуск инкрементов, сокращение графика работ, неизменяемость ресурсов при постепенном росте системы); - реализация связи с пользователем с высокой частотой и на ранних этапах модели, что обеспечивает создание нужного продукта высокого качества; - возможность оценки системы пользователем на ранних этапах, за счет использования в жизненном цикле разработки ускоренного прототипирования; - возможность пользователям принимать участие при планировании, анализе рисков, проектировании, разработке, выполнении оценочных действий; - усовершенствование административного управления процессами жизненного цикла разработки, затратами, соблюдением графика и кадровым обеспечением, что достигается путем выполнения анализа (обзора) в конце каждой итерации; - повышение производительности за счет использования пригодных для повторного использования результатов; повышение вероятности предсказуемого поведения системы с помощью уточнения поставленных целей; - отсутствие необходимости в предварительном распределении всех нужных для выполнения проекта финансовых ресурсов; - возможность регулярной оценки совокупных затрат, что в результате приводит к их общему сокращению. В случае ошибочного выбора спиральной модели для реализации проекта могут появиться следующие недостатки: - модель имеет более сложную структуру, чем каскадная, что приводит к сложности ее использования разработчиками, менеджерами и заказчиками; - неоправданно высокая стоимость модели для проектов, имеющих низкую степень риска или небольшие размеры; - необходимость к привлечению высококвалифицированных специалистов для оценки рисков; - возможность отдаления окончания работы над проектом в связи с желанием заказчика улучшать каждую созданную версию; 32 - высокая стоимость модели за счет стоимости и дополнительных временных затрат на планирование, определение целей, выполнение анализа рисков и прототипирование при прохождении каждого цикла спирали; - большое количество промежуточных стадий может вызвать необходимость в обработке дополнительной внутренней и внешней документации; - необходимость в четком распределении работ между разработчиками; - сложность определения критериев для продолжения процесса разработки на следующей итерации; - наличие мощных инструментальных средств и методов прототипирования. Область применения спиральной модели Целесообразность использования спиральной модели может быть обоснована следующими причинами: - необходимость разработки проектов в организации, обладающей навыками, требуемыми для адаптации модели; - необходимость разработки проектов, связанных со средней и высокой степенью риска; - при разработке проектов, использующих новые технологии; - при разработке проектов, в которых необходимо протестировать базовые концепции; - при разработке широкомасштабных проектов; - при разработке проектов со сложными требованиями; - при разработке новой серии продуктов или систем; - при разработке проектов в случае, если пользователь не уверен в своих потребностях; - при разработке проектов с ожидаемыми существенными изменениями или дополнениями требований; - при разработке проектов в условиях отсутствия возможности заблаговременного выделения всех необходимых для выполнения проекта денежных средств, - для выполнения долгосрочных проектов; - при разработке проектов, в которых необходима демонстрация качества и версий системы или продукта через короткий период времени; - при разработке систем, требующих большого объема вычислений; - при выполнении бизнес-проектов, проектов в области гражданской авиации и инжиниринга. Очевидно, что классическая спиральная модель является достаточно сложной. С учетом этого разработан ряд ее упрощенных версий. На рис.1.9 представлен вариант упрощенной спиральной модели. л из ир ов а на П л ск ри ан А ни е 33 ов Версия n П ро е а нк к а це чи О аз к за кт ир ов ан ие я2 Верси 1 сия Вер Рис.1.9.Упрощенный вариант спиральной модели В данной модели процесс жизненного цикла разработки проекта разделен на четыре квадранта: «Планирование», «Риск», «Разработка», «Заказчик». В пределах квадрантов выделяются только основные действия различного уровня. Таким образом, в данной модели устранена чрезмерная детализация процесса. Необходимая детализация процессов предусматривается при выполнении работ этапов планирования конкретного проекта. К достоинствам упрощенных спиральных моделей можно отнести: более понятна как разработчику, так и заказчику; в отличие от других моделей, внимание уделяется действиям непосредственно не связанных с разработкой. Это обеспечивает более высокое качество процесса разработки продукта, и упрощает прогнозирование сроков и стоимости разработки, повышает удовлетворенность заказчика результатами продукта. 5) Методология XP [5]. Данный подход ориентирован на разработку информационных систем группами малого и среднего размера в условиях неопределенных или быстро изменяющихся требований. Отличительными особенностями XP-разработки являются: - частая смена версий и модификаций (длительность итераций вплоть до часов и минут, а обычно – 2 недели); - непрерывная связь с заказчиком - в группе все время находится квалифицированный представитель заказчика, который может оперативно ответить на все увеличивающее количество вопросов со стороны команды разработчиков; - простое проектирование - при разработке всегда выбирается наиболее простое решение; 34 - простой дизайн - система должна быть спроектирована настолько просто, насколько это возможно на данный момент времени. Согласованный интерфейс должен быть интуитивно-понятным для пользователя; - коллективное владение кодом - применение одинаковых стандартов и правил оформления кода с исчерпывающими комментариями, а также и ведение общедоступной истории развития системы; - программирование в парах - более разумном сочетании разных видов деятельности каждого из них; - непрерывное и пересекающееся проектирование, разработка, интеграция и тестирование системы. Рассмотренные выше модели и методологии направлены на сокращение сроков и расходов по разработке приложений с одновременным повышением качества результатов работы. Главное достоинство этих моделей и методологий заключается в наиболее полном и точном удовлетворении требований заказчика за счет обеспечения своевременной обратной связи. Контрольные вопросы 1) Какие факторы влияют на эффективность создания КСС? 2) Какая модель основана на итерационном подходе к созданию системы? 3) Какая модель позволяет в короткие сроки разработать продукт (услуги)? 4) Чем обусловлено появление модели RAD? 6) В чем заключаются достоинства и недостатки каскадной (водопадной модели)? 7) Какая модель более эффективна при переходе системы на новую платформу? 1.5. Процессы управления проектами Управление проектами - интегрированный процесс. Действия (или их отсутствие) в одном направлении обычно влияют и на остальные направления. Такая взаимосвязь заставляет балансировать между задачами проекта - часто улучшение в одной области может быть достигнуто лишь за счет ухудшения в другой. Для лучшего понимания интегрированной природы управления проектами опишем его через процессы, из которых оно состоит, и их взаимосвязи. Проект состоит из процессов. Процесс - это совокупность действий, приносящая результат. Процессы проекта обычно выполняются людьми и распадаются на две основные группы: - процессы управления проектами - касающиеся организации и описания работ проекта (которые будут подробно описаны далее); 35 - процессы, ориентированные на продукт - касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения. В проектах процессы управления проектами и процессы, ориентированные на продукт, накладываются и взаимодействуют. Например, цели проекта не могут быть определены при отсутствии понимания того, как создать продукт. Процессы управления проектами могут быть разбиты на шесть основных групп, реализующих различные функции управления: - процессы инициации - принятие решения о начале выполнения проекта; - процессы планирования - определение целей и критериев успеха проекта и разработка рабочих схем их достижения; - процессы исполнения - координация людей и других ресурсов для выполнения плана; - процессы анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям успеха и принятие решений о необходимости применения корректирующих воздействий; - процессы управления - определение необходимых корректирующих воздействий, их согласование, утверждение и применение; - процессы завершения - формализация выполнения проекта и подведение его к упорядоченному финалу. Инициация проекта может включать следующие процедуры: - разработка концепции проекта: анализ проблемы и потребности в проекте, сбор исходных данных, определение целей и задач проекта; - рассмотрение альтернативных вариантов проекта; - рассмотрение и утверждение концепции. - принятие решения о начале проекта: определение и назначение менеджера проекта; принятие решения об обеспечении ресурсами выполнения первой фазы проекта. Планирование проекта непрерывный процесс, направленный на определение и согласование наилучшего способа действий для достижения поставленных целей проекта с учетом всех факторов его реализации. Основным результатом этого этапа является План проекта. В ходе осуществления проекта могут происходить изменения как внутри проекта, так и во внешнем окружении, которые требуют уточнения планов, а часто значительного перепланирования. Поэтому процессы планирования могут осуществляться на протяжении всего жизненного цикла проекта, начиная с предварительного укрупненного плана в составе концепции проекта, и заканчивая детальным планом работ завершающей фазы проекта. Планирование проекта может включать следующие процедуры: - планирование целей и содержания проекта, - календарное планирование работ проекта, 36 - планирование затрат и финансирования проекта, - планирование качества, - организационное планирование, - планирование коммуникаций, - планирование управления рисками, - планирование контрактов, - разработку сводного плана проекта. Организация исполнения проекта - процесс обеспечения реализации плана проекта путем организации выполнения включенных в него работ и координации исполнителей. Организация исполнения проекта может включать следующие процедуры: - распределение функциональных обязанностей и ответственности, - постановку системы отчетности, - организацию контроля выполнения расписания проекта, - организацию контроля затрат по проекту, - организацию контроля качества, - оперативное управление мерами по снижению и предотвращению рисков, - управление командой проекта, - распределение информации в проекте, - подготовку и заключение контрактов, - управление изменениями в проекте. В ходе процессов организации исполнения менеджеру проекта необходимы лидерские навыки, умение решать проблемы и разрешать конфликты. Контроль исполнения проекта - процесс сравнения показателей плановых и фактических показателей выполнения проекта, анализ отклонений и их причин, оценка возможных альтернатив и принятие, в случае необходимости, решений о корректирующих действиях для ликвидации нежелательных отклонений. Контроль проекта может включать следующие процедуры: - сбор отчетности о ходе работ по проекту, - анализ текущего состояния проекта относительно основных базовых показателей (результаты, стоимость, время), - прогнозирование достижения целей проекта, - подготовку и анализ последствий корректирующих воздействий, - принятие решений о воздействиях и изменениях. Завершение проекта - процесс формального окончания работ и закрытия всего проекта. Завершение проекта может включать следующие процедуры: - сдача результатов проекта заказчику, - заключительная оценка финансовой ситуации (постпроектный отчет), - заключительный отчет по проекту и проектная документация, - список открытых вопросов и заключительных работ; 37 - разрешение всех спорных вопросов, - роспуск команды проекта. Документирование и анализ опыта выполнения данного проекта производится архивация основных управленческих и содержательных проектных документов для последующего использования при реализации других проектов. Основным процессом управления проектом является процесс планирования. Планирование проекта принципиально различается в зависимости от базовой структуры (иерархической или кооперативной). Планирование имеет общий характер при наличии иерархической структуры, и основано на определении требуемых сроков выполнения отдельных работ с учетом потребности в необходимых ресурсах. Оно имеет иерархическую направленность, поскольку преследует главную цель - выполнение сроков работ нижнего уровня не должно приводить к нарушению сроков реализации работ более высокого уровня. Для соблюдения сроков критических проектных работ привлекаемые ресурсы могут перераспределяться и концентрироваться. Для планирования выполнения проектов, имеющих иерархическую структуру, применяются технологии линии балансировки LOB и дерева зависимости [11]. В большинстве случаев планирование базируется на кооперативной структуре проектов, описываемой сетевыми графиками, иные формы (например, временные диаграммы), могут использоваться как вспомогательные. Технологии планирования проекта считаются основными инструментами, методически отличающими управление проектами от управления предприятиям. Они выбираются с учетом специфики проекта. В роли критериев могут выступать следующие характеристики проектов: доминирующий тип структуры (иерархическая или кооперативная), определенность структуры (детерминированная или стохастическая), определенность длительности проектных работ (детерминированная или стохастическая). Обзор технологий планирования выполнения проектов представлен в табл.1. Контрольные вопросы 1) Что понимается под процессом управления проектом? 2) Перечислите группы, на которые делятся процессы управления проектами. 3) Приведите классификацию технологий планирования проекта. 4) Какие характеристики проектов могут выступать в качестве критериев? 5) Назовите основные группы, реализующие различные функции управления проектами. 6) Какой процесс управления проектом является основным? 7) Перечислите процедуры контроля проекта. 38 Таблица 1. Обзор технологий планирования выполнения проектов Структура Кооперативная проекта Иерархическая детерминированная стохастическая Проектные работы Детерминированные Технологии Временные LOB диаграммы Технологии дерева зависимости PATTERN CPE Стохастические Технологии дерева решений Сетевая технология CPM Сетевая технология MPM Сетевая технология Сетевая PERT технология GERT 1.6. Управление рисками проекта 1.6.1. Идентификация рисков Поскольку понятие проекта определяется как создание уникального продукта или услуги, то проект как таковой является риском, предпринятым для использования новой возможности. Риск в контексте проекта (риск проекта) рассматривается, как воздействие на проект и его элементы непредвиденных событий, которые могут нанести определенный ущерб и препятствовать достижению целей проекта. Риски могут происходить из внутренних и внешних источников. Внутренние риски определяются характером самого проекта, организационными вопросами, кадровыми и ресурсными проблемами и т.д. Источниками внешних рисков являются политические, юридические, экологические и социальные проблемы. Независимо от источников, риск проекта характеризуется тремя факторами: событиями, оказывающими негативное воздействие на проект; вероятностью появления таких событий; оценкой ущерба, нанесенного проекту такими событиями. Идентификацию нужно начинать непосредственно с проекта, выделяя внутренние известные риски. Ограничения проекта, матрица распределения 39 ответственности, список заданий и критические факторы успеха помогут выявить проектные риски. Управление проектами подразумевает не только констатацию факта наличия неопределенности и рисков и анализ рисков и ущерба. Рисками проектов можно и нужно управлять. Управление риском - это искусство и формальные методы определения, анализа, оценки, предупреждения возникновения, принятия мер по снижению степени риска на протяжении жизни проекта и распределения возможного ущерба от риска между участниками проекта. Управление рисками совокупность методов анализа и нейтрализации факторов рисков, объединенных в систему планирования, мониторинга и корректирующих воздействий. Управление рисками является подсистемой управления проектом. Экспертный анализ рисков применяют на начальных этапах работы с проектом в случае, если объем исходной информации является недостаточным для количественной оценки эффективности (погрешность результатов превышает 30%) и рисков проекта. Алгоритм экспертного анализа рисков следующий: - по каждому виду рисков определяется предельный уровень, приемлемый для организации, реализующей данный проект. Предельный уровень рисков определяется по 100-ой шкале; - устанавливается, при необходимости, дифференцированная оценка уровня компетентности экспертов, являющаяся конфиденциальной. Оценка выставляется по десятибалльной шкале; - риски оцениваются экспертами с точки зрения вероятности наступления рискового события (в долях единицы) и опасности данных рисков для успешного завершения проекта (по 100-ой шкале); - оценки, проставленные экспертами по каждому виду рисков, сводятся разработчиком проекта в таблицы. В них определяется интегральный уровень по каждому виду рисков; - сравниваются интегральный уровень рисков, полученный в результате экспертного опроса, и предельный уровень для данного вида и выносится решение о приемлемости данного вида риска для разработчика проекта. - в случае если принятый предельный уровень одного или нескольких видов рисков ниже полученных интегральных значений, разрабатывается комплекс мероприятий, направленных на снижение влияния выявленных рисков на успех реализации проекта, и осуществляется повторный анализ рисков. 1.6.2. Технологии анализа рисков Методы оценки рисков включают следующее: 1. Количественная оценка рисков с помощью методов математической статистики. 40 2. Методы экспертной оценки рисков. 3. Методы имитационного моделирование рисков. 4. Комбинированные методы, представляющие собой объединение нескольких отдельных методов или их отдельных элементов. Все методы, позволяющие минимизировать проектные риски можно разделить на три группы: 1. Диверсификация, или распределение рисков (распределение усилий предприятия между видами деятельности, результаты которых непосредственно не связаны между собой), позволяющая распределить риски между участниками проекта. Распределение проектным рисков между его участниками является эффективным способом его снижения. 2. Резервирование средств на покрытие непредвиденных расходов представляет собой способ борьбы с риском, предусматривающий установление соотношения между потенциальными рисками, влияющими на стоимость проекта, и размером расходов, необходимых для преодоления сбоев в выполнении проекта. Минимизация рисков всегда увеличивает проектные затраты, но зато увеличивает и проектную прибыль. Необходимым условием успеха проекта является превышение предполагаемых поступлений от реализации проекта над оттоками денежных средств на каждом шаге расчета. С целью снижения рисков в плане финансирования необходимо создавать достаточный запас прочности, учитывающий следующие виды рисков: - риск незавершенного строительства (дополнительные затраты и отсутствие запланированных а этот период доходов); - риск временного снижения объема продаж продукции проекта; - налоговый риск (невозможность использования налоговых льгот и преимуществ, изменение налогового законодательства); - риск несвоевременной уплаты задолженностей со стороны заказчиков. При расчете рисков необходимо, чтобы сальдо накопленных реальных денег в финансовом плане проекта на каждом шаге расчета было не менее 8% планируемых на данном шаге затрат. Кроме того, необходимо предусматривать дополнительные источники финансирования проекта и создание резервных фондов с отчислением в них определенного процента с выручки от реализации продукции. 3. Страхование рисков. В случае если участники проекта не в состоянии обеспечить реализацию проекта при наступлении того или иного рискового события собственными силами, необходимо осуществить страхование рисков. Страхование рисков есть, по существу, передача определенных рисков страховой компании. При заключении договора страхования предпринимательского риска 41 страховщик вправе произвести анализ рисков, а при необходимости назначить экспертизу. Эффективность методов снижения рисков определяется с помощью следующего алгоритма: - рассматривается риск, имеющий наибольшую важность для проекта; - определяется перерасход средств с учетом вероятности наступления неблагоприятного события; - определяется перечень возможных мероприятий, направленных на уменьшение вероятности и опасности рискового события; - определяются дополнительные затраты на реализацию предложенных мероприятий; - сравниваются требуемые затраты на реализацию предложенных мероприятий с возможным перерасходом средств вследствие наступления рискового события; - принимается решение об осуществлении или об отказе от противорисковых мероприятий; - процесс сопоставления вероятности и последствий рисковых событий с затратами на мероприятия по их снижению повторяется для следующего по важности риска. 1.6.3. Качественный и количественный анализ рисков Оценка любого из рисков может быть разделена на две группы: качественная оценка и количественная. Качественная оценка риска направлена на то, чтобы ответить на следующие вопросы: какой риск ожидается; какие источники риска имеются, где они находятся, когда они могут быть актуальны; в чем выражается риск; какие стороны и/или участники деятельности могут быть подвержены риску. После определения риска, как правило, не возникает проблем для актуализации источников, мест их нахождения, времени их действия. Неверная классификация риска приведет к ошибкам совершенно непредсказуемым. Количественную оценку рисков всегда определяют тремя понятиями: премлемые или допустимые риски; умеренные риски и недопустимые риски. Количественная оценка риска (измерение риска) может преследовать различные цели. Классически при оценке риска проводится анализ стоимости всех его обстоятельств или потерь в случае наступления негативных последствий, а также ее вероятность. Риск имеет математически выраженную вероятность наступления определенного события, которая опирается на статистические данные или экспертные оценки и может быть математически рассчитана (например, дисперсия как показатель степени риска): 42 n 2 x (x t 1 i 2 x) n -1 , где xi - i-е значение случайной величины, n- количество наблюдений. Рассматривая риск с точки зрения его оценки, необходимо решить следующие задачи: - описать как можно больше возможных вариантов развития событий в будущем, соответствующих данному риску; определить вероятности наступления каждого из этих вариантов (случайных событий). Вероятность наступления события (вероятностная мера риска) может быть определена объективным или субъективным методом. Объективный метод имеет следующие разновидности: прямой вероятностный (статистически) метод, основанный на вычислении относительной частоты, с которой происходит случайное событие: если в n испытаниях случайное событие наблюдается m раз, то его вероятность находится по формуле: p = m / n. При этом следует учитывать следующие ограничения: pi = 1, то есть сумма вероятностей всех событий равна 1; 0 <= pi< 1, вероятность отдельного события должна быть больше или равна 0 и меньше 1. Этот метод является наиболее предпочтительным в том случае, когда имеется обширная и достаточно надежная информация об истории оцениваемого объекта. Любое измерение рисков практически лишено смысла без соответствующей методической базы. Современные методы их измерения, как правило, опираются на теории финансовых инструментов, теорию вероятности, статистические методы и теорию случайных событий. Почти для каждого применения оценки рисков возможно подобрать оптимальный метод их измерения. Так, при оценке инвестиционных рисков применяют анализ чувствительности проекта на изменения его параметров. Технический анализ может выступать как набор статистических методов прогнозирования, то есть измерения рисков. Практически повсеместно применяется один из простейших методов количественной оценки риска - метод экспертных оценок. Аналитик обращается к нескольким экспертам с определенными вопросами, потом составляет некую общую оценку и привязывает ее к определенной зоне рисков. Многие кредитные организации в рамках управления рисками применяют методики с использованием VaR (value at risk) - стоимостной оценки максимального убытка, ожидаемого в течение некоего периода времени потери с заданной вероятностью. Этот показатель пользуется спросом из-за его 43 универсальности. Также на уровень методов оценки рисков влияют масштабы действий и размеры активов, которыми собирается рисковать организация, ведь всегда существует определенная вероятность полных потерь. 1.6.4. Мониторинг и управление рисками Симптомы рисков определяются на этапе идентификации рисков и фиксируются в плане и программе управления рисками. Следует внимательно следить за сигналами риска – признаками, сигнализирующими о возможном событии риска. Мониторинг и управление рисками представляет собой процесс применения планов реагирования на риски, слежения за выявленными рисками, контроля остаточных рисков, идентификации новых рисков и оценки эффективности процесса регулирования рисков на протяжении проекта. Цель мониторинга состоит в наблюдении за прогрессом выполнения принятых планов (предотвращения рисков и смягчения их последствий – максимизация положительных и минимизация отрицательных последствий наступления рисковых событий), количественными параметрами, условиями, определяющими применения плана реагирования на риски, и в информировании команды в случае наступления риска. Входными данными для мониторинга являются: реестр рисков, план управления проектом, информация об исполнении работ (статус результатов, ход выполнения расписания, понесенные затраты), отчеты об исполнении. В процессе мониторинга и управления рисками применяются такие методы, как анализ отклонений и тенденций, для выполнения которых необходимы данные об исполнении, собранные в процессе выполнения проекта. Другие цели процесса контроля и управления рисками призваны определить: - действительны ли еще допущения проекта; - показывает ли анализ, что оцененный риск изменился или потерял свою актуальность; - исполняются ли правила и процедуры по управлению рисками; - необходимо ли согласовывать резервы на возможные потери по стоимости или расписанию с текущими оценками рисков. Выходными данными мониторинга являются: обновления реестра рисков, обновления активов процессов организации, запросы на изменение (рекомендованные корректирующие воздействия, рекомендованные предупреждающие действия), обновления плана управления проектом, обновления документов проекта. Реализуя проекты, имеющие высокую степень неопределенности в таких элементах, как цели и технологии их достижения многие компании уделяют внимание разработке и применению корпоративных методов управления рисками. 44 Данные методы учитывают как специфику проектов, так и корпоративных методов управления. Контрольные вопросы 1) Что такое риск? 2) Назовите наиболее типичные проектные риски. 3) Какие документы можно использовать в процессе идентификации рисков? 4) Какие технологии используются при идентификации рисков? 5) Перечислите стратегии реагирования на риски. 6) Поясните цель мониторинга рисков. 7) Какие методы применяются в процессе мониторинга и управления рисками? 1.7. Корпоративное управление проектами Корпоративное управление проектами (КУП) представляет собой методологию организации, планирования, руководства, координации и контроля людских и материальных ресурсов всей совокупности проектов организации, направленную на эффективное достижение целей проектов путем применения системы современных методов, техники и технологий управления для достижения определенных в проекте результатов по составу и объему работ, стоимости, времени и качеству. Критерии корпоративного управления проектами: - легкость в использовании и администрировании многопользовательских, многопроектных приложений, масштабируемость и настройка в масштабах всей организации для всех участников проектов; - сохранение больших объемов проектных данных и информации по всей организации; - возможность распределенного выполнения задач, характерных для управления проектами: расчет расписания, выравнивание ресурсов, отчетность по отдельным проектам, организации в целом и портфелям проектов; - обеспечение каждого участника проекта соответствующим инструментом, достаточным для выполнения их функций - как участников команды проекта, которым необходимо отчитываться только о статусе выполняемых ими работ, так и руководителей проектов и отделов. Внедрение КУП предполагает, что управление программами и проектами производится при помощи специализированной организационной структуры в рамках принятой в компании методологии с использованием проектноориентированной информационной системы. 45 Сегодня практически невозможно обеспечить эффективную реализацию управленческих процедур без использования современных средств обработки информации и коммуникаций, так как процесс разработки продукта (услуги) не является последовательным и замкнутым внутри одного предприятия. С тех пор как широкое распространение получили специализация и аутсорсинг, критическим моментом управления крупными проектами стало предоставление всем его участникам механизма обмена информацией и реализации возможности параллельной работы. Наличие единой информационной модели планирования проектов и единой информационной среды - важнейший фактор, обеспечивающий работоспособность команд проектов и руководителей разного уровня в оперативном режиме. Следует учитывать, что переход на единые технологии управления проектами в различных компаниях осуществляется по-разному. Выбор той или иной стратегии реализации проекта обусловлен как спецификой проектов компании, так и текущим состоянием развития бизнеса, готовностью компании к внедрению. Так как КУП относится к типу «открытых», т.е. к проектам, которые достаточно сложно спланировать с высокой степенью точности на начальных этапах и соответственно планирование и реализация подобных проектов выполняется поэтапно, с учетом достигаемых результатов. К особенностям таких проектов можно отнести: - сложность формулирования и согласования четких целей и требований к конечным результатам и критериям успеха. Возможное изменение (уточнение) этих требований в ходе проекта; - повышение формализации в подготовке и принятии управленческих решений, что предполагает повышение требований к квалификации и степени ответственности персонала, следствием чего является высокая зависимость от человеческого фактора; - необходимость проведения организационных изменений, что может быть связано с конфликтом интересов отдельных подразделений и руководителей. Для успеха таких проектов особую важность приобретают задачи разработки общей стратегии реализации с выделением ключевых фаз и промежуточных результатов. Разработку стратегии обычно начинают с анализа предпосылок и задач корпоративного управления проектом, расстановки приоритетов достижения результатов с учетом рисков и ограничений. Создание эффективной корпоративной системы УП предполагает наличие трех компонентов: - нормативно-регламентного и методологического обеспечения (стандарта); - технического и информационного обеспечения; - организационного и кадрового обеспечения. 46 Чтобы комплексно управлять крупным проектом, необходимо решать следующие задачи: - планирования и управления ресурсами; - организации управления совместной работой групп разработчиков, в том числе и географически распределенных; - централизованного управления всей совокупностью проектных данных; - управления распределением работ на каждом из этапов жизненного цикла (workflow); - автоматизированного выполнения бизнес-процессов; - автоматического извещение участников работ проекта в соответствии с их ролью в проекте о появлении новой проектной информации и о внесении/проведении изменений; - предоставления каждому участнику проекта простого и удобного доступа к той части проектных данных, которая требуется ему в ходе выполнения работ. Модель среды совместного ведения проектов группами исполнителей в рамках расширенного предприятия представлена на рис.1.10. Производство Маркетинг Разработка Руководитель программы Среда совместной разработки Сбыт Сопровождение ПРОЕКТ А ПРОЕКТ N Внутренняя среда Межсетевой экран Проект 1 Проект 2 Проект 3 Защита данных Внешняя среда Среда совместной разработки Партнер Поставщик А Поставщик N Заказчик Рис.1.10. Модель среды совместного ведения проектов Независимо от ситуации, в которой стартует проект, менеджер должен понимать, что КУП предполагает реализацию комплекса внутрикорпоративных изменений. Цикл управления изменениями включает три последовательных этапа: 47 «разморозки» ситуации; реализации изменения; фиксации изменения. Для повышения вероятности успеха проводимых изменений желательно с самого начала добиться: - комплексного рассмотрения организационного проекта; - четкого понимания целей проекта всеми его участниками; - сбалансированного подхода (разработка стандарта, применение информационных технологий, обучение персонала). Игнорирование отдельных составляющих может существенно снизить эффективность результатов. Контрольные вопросы 1) Что понимается под корпоративным управлением проекта? 2) В чем особенность таких проектов? 3) Назовите основные критерии КУП. 4) Что является критическим моментом управления крупными проектами? 5) Как организационная структура предприятия влияет на КУП? 6) Перечислите задачи для комплексного управления проектом. 7) Поясните проблему сопровождения КУП. 8) Что понимается под термином «сбалансированный подход»? 48 ЧАСТЬ 2. ПРАКТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ПРОЕКТАМИ, ПРОГРАММАМИ И ПОРТФЕЛЯМИ ПРОЕКТОВ 2.1. Реализация проекта 2.1.1. Конфликты при реализации проектов В процессе реализации задач проекта часто возникают ситуации, когда интересы работников не совпадают. Это может приводить к конфликтам, что является прежде всего следствием несоответствия структуры проекта и разделения труда, а также и разобщенности людей с различными ценностными представлениями. Умение управлять конфликтами сегодня приобретает особое значение. Конфликт - это отсутствие согласия между двумя или несколькими субъектами, столкновение противоположных сторон, сил, которые могут быть конкретными лицами или группами работников, а также: внутренний дискомфорт одного человека. Классическая точка зрения на конфликт в промышленности проявлялась в том, что он не должен возникать. Но признано, что конфликт может быть положительным, если он является основой для начала дискуссии с обсуждения того или иного вопроса, способствует решению того, или иного вопроса, улучшает отношения между людьми, позволяет снять напряженность, дает возможность работникам полнее раскрыть свои возможности. Конфликт может быть отрицательным, если он отрывает людей от решения важных вопросов, вызывает чувство неудовлетворенности в коллективе, ведет к личностной или групповой изоляции, а также противодействует развитию. Конфликты обычно делятся на психологические и социальные. Психологический конфликт связан с психологическими проблемами одного индивидуума (наличием конкурирующих желаний, желанием избежать негативных результатов и т.п.). Социальный конфликт - это конфликт, возникающий между индивидуумами, их группами, а также системами и подсистемами. С момента инициации проекта и до его завершения, менеджер проекта и проектная команда постоянно находятся в «конфликтном окружении», несмотря на то, как воспринимается сам конфликт, как негативное или как позитивное воздействие. Задача менеджера сводится к умению управлять конфликтами, поскольку они могут носить конструктивную (совместный поиск решения конфликта с выгодой для обеих сторон) и деструктивную (когда каждый участник конфликта остается при своем мнении) форму. Конструктивные конфликты связаны с разногласиями и борьбой по принципиальным проблемам научно-технической и социальной политики организации. Они способствуют предотвращению застоя, служат источником идей, сопровождают формирование новых научных направлений. Поэтому таких конфликтов не следует избегать, а плодотворно 49 использовать путем удовлетворения объективных требований конфликтующих сторон. Для этого менеджер должен уметь отличить непосредственный повод конфликта от его причины, может покрываться конфликтующими сторонами. Важно установить, как предмет разногласия касается производственных проблем, в какой степени - деловых и личных взаимоотношений участников конфликта. Необходимо также выяснить мотивы конфликтного столкновения работников, направленность действий участников конфликту. С этой целью следует выслушать всех участников конфликта, не торопиться с выводами и обобщениями, избегать проявления личных симпатий. Основная цель - добиться взаимопонимания участников конфликта, определяет следующие возможные случаи разрешения конфликта: взаимное примирение на объективной основе; компромисс, основанный на частичном удовлетворении желаний обеих сторон. Выделяют основные источники конфликтов в проектах: 1) Конфликт через приоритеты - связан с тем, что мысли участников проекта про последовательность выполнения работ и задач различаются; 2) Конфликты через административные процедуры - связаны с теми нормативно-регулятивными правилами, которые регламентируют то, как управлять проектом, какие документы должны создаваться и в каком формате; 3) Конфликты через технические решения - связаны с техническими вопросами в процессе реализации проекта; 4) Конфликты через человеческие ресурсы - постоянный конфликт проекта, связан с набором персонала в команду проекта из функциональных подразделений компании; 5) Конфликты через стоимость - связаны с вопросами выделения дополнительных бюджетов, расценкой на работы, оплатой работы подрядчикам и т.д.; 6) Конфликты через календарный план проекта - связаны со спорами вокруг сроков выполнения работ, их последовательностью, взаимозависимостью и т.д. 7) Межличностные конфликты - связаны с несогласием между участниками на личностном уровне. Управление конфликтом - это целенаправленное воздействие на ликвидацию (минимизацию) причин возникновения конфликта или коррекцию поведения участников. Существует большое количество методов управления конфликтами. Укрупнено их можно представить в виде нескольких групп: внутриличностный метод (метод воздействия на отдельную личность); структурные методы (ликвидация организационных конфликтов); межличностные методы или стили поведения в конфликте; переговоры. Общеизвестны пять стилей поведения в конфликтных ситуациях. 50 Ориентация на своих целях 1) Метод уклонения. Он базируется на том, что человек старается уйти от конфликта, избежать ситуации, провоцирует противоречия и избежать обсуждения вопроса, что приводит к конфликту. 2) Метод приспособления. Этот стиль характерен при естественном нежелании избежать конфликта, т.е. необходимо стимулировать чувство общности в коллективе. 3) Метод компромисса. Он характеризуется принятием точки зрения другой стороны, но до определенного предела. Менеджер проекта может эффективно его использовать при официальных переговорах по контракту и при неформальных переговорах с участниками проекту. 4) Метод форсирования. Принуждение к принятию одной точки зрения. Этот стиль эффективен, когда руководитель имеет большую власть над подчиненными. 5) Метод решения проблем. Это признание расхождений во мнениях и готовность ознакомиться с иными точками зрения, чтобы лучше понять причину конфликта и найти выход, приемлемый для всех. Решения проблемы является синтезом всех методов управления конфликтами и используется, когда есть достаточно времени и существует доверие между конфликтными сторонами. На рис.2.1 показано, какой метод применяется, в зависимости от ориентации на своих или чужих целях в рамках конфликта. Форсирование Компромисс Решение проблемы Уклонение Приспособление Ориентация на целях других, желающих сотрудничать Рис.2.1. Использование метода в зависимости от целей 51 2.1.2. Средства мониторинга информационной системы Автоматизация управления проектами может быть обеспечена средствами таких информационных технологий, как, например, система управления документами в документарной части стандарта или система управления деловыми процессами в процедурной части стандарта. К основным областям деятельности по управлению проектами, подлежащим в той или иной степени автоматизации относятся: - собственно управление проектами, которое в узком смысле обычно понимается как календарно - ресурсное планирование; - формирование и ведение бюджета проекта; - управление документами - как управленческими, так и являющимися результатами выполнения проекта; - управление деловыми процессами в проектах, включая процессы согласования документов. В части календарно-ресурсного планирования система управления проектом должна обеспечить следующие возможности: - формирование структуры декомпозиции работ (WBS-структуры), требуемой степени детализации; - формирование календарного плана, содержащего продолжительность работ, их объем и стоимости, ограничения на даты начала и окончания, а также технологические зависимости между работами; - формирование ограничений по проекту, определяющих перечень трудовых ресурсов, которые предполагается использовать в проекте с указанием доступного количества в определенное время; - формирование детального плана работ, в котором работам назначены ресурсы - трудозатраты и материально-технические ресурсы; - построение отчетов о состоянии проекта, в том числе с использованием различных аналитик. В части финансового планирования СУП должна обеспечить следующие возможности: - планирование и учет финансовых потоков, включая расчеты с заказчиком и субподрядчиками; - формирование заданий исполнителям и учет реально затраченного времени; - учет непроектного и нерабочего времени, отпусков и больничных листов; - учет командировочных и административных расходов. В проектах большое значение имеют не только традиционные функции управления документами, такие как поддержание версий документов и истории работы с ними, ведение архива, авторизация доступа, поддержание связей между документами (EDMS-функции). Все большее значение приобретают функции 52 управления движением документов и контроля сроков их исполнения (workflowфункции). Управление документами реализуется с использованием базовой функциональности промышленных пакетов (Docs Open, Documentum). Функции управления движением документов и контроля сроков их исполнения реализуются с использованием базовой функциональности специализированных программных систем (Eastman) или промышленных пакетов управления документами (Documentum). Эффективность использования КИС зависит от многих факторов и подробно описана в [6]. 2.1.3. Тестирование Разные источники определяют тестирование по-разному. В соответствие с RUP (Rational Unified Process) тестирование - одна из дисциплин RUP. Она ориентирована в первую очередь на оценку качества с помощью следующих методов: поиск и документирование дефектов качества; общие рекомендации относительно качества; проверка выполнения основных предположений и требований на конкретных примерах; проверка, что продукт функционирует так, как было запроектировано; проверка, что требования выполнены соответствующим образом. По ГОСТ Р ИСОМЭК12207-99 в жизненном цикле программного обеспечения определены среди прочих вспомогательные процессы верификации, аттестации, совместного анализа и аудита. Процесс верификации является процессом определения того, что программные продукты функционируют в полном соответствии с требованиями или условиями, реализованными в предшествующих работах. Данный процесс может включать анализ, проверку и испытание (тестирование). Процесс аттестации является процессом определения полноты соответствия установленных требований, созданной системы или программного продукта их функциональному назначению. Процесс совместного анализа является процессом оценки состояний и, при необходимости, результатов работ (продуктов) по проекту. Процесс аудита является процессом определения соответствия требованиям, планам и условиям договора. В сумме эти процессы и составляют то, что обычно называют тестированием. При выполнении проекта необходимо учитывать: в соответствии с какими стандартами и требованиями будет проводиться тестирование продукта; какие инструментальные средства будут (если будут) использоваться для поиска и для документирования найденных дефектов. При разработке ПО используются итеративные процессы. Одним из примеров такого подхода является RUP. При использовании такого подхода процесс тестирования начинается с самого начала работы над проектом. Работа над тестами начинается с самого начального этапа выявления требований к 53 Число ошибок будущему продукту и тесно интегрируется с текущими задачами. Все это предъявляет новые требования к тестировщикам – не просто выявить ошибки как можно полнее и как можно раньше, но и участвовать в общем процессе выявления и устранения наиболее существенных рисков проекта. Для этого на каждую итерацию определяется цель тестирования и методы ее достижения, в конце каждой итерации определяется, насколько эта цель достигнута, нужны ли дополнительные испытания, и не следует ли изменить принципы и инструменты проведения тестов. Каждый обнаруженный дефект заносится в базу дефектов. Аналитик определяет, не является ли он повтором внесенного ранее дефекта, действительно ли он является дефектом? Руководитель утверждает исполнителя, который приступает к устранению дефекта в соответствие с назначенным дефекту приоритетом. Тестировщик повторяет выполнение теста, убедившись (или не убедившись) в устранении дефекта. Строгое соблюдение жизненного цикла дефекта позволяет существенно улучшить управление проектом, а также избежать ―расползания― требований под видом исправления ошибок и избежать ненужной работы. Выгоды от использования автоматизации процесса тестирования очевидны из рис.2.2, который демонстрирует то, каким образом снижается число ошибок в версиях программного продукта при применении технологии IBM Rational. В данном случае речь идет о применении регрессионных тестов. Поскольку процесс тестирования автоматизирован, то сокращаются трудозатраты тестировщиков, соответственно, возрастает объем тестов, и, как следствие программное обеспечение тестируется все более и более полно. 1 2 3 4 Версия/ время Рис.2.2 Количество ошибок, найденных в версиях программного обеспечения Следует понимать, что тестирование не есть обособленный вид деятельности или поток работ, оторванный от остальных. Процесс тестирования идет непосредственно после кодирования и происходит достаточно обособленно. В таком подходе кроется существенный недостаток: получается так, что команда разработчиков и тестировщики - две разрозненные группы, порой плохо 54 согласованные друг с другом. Отсюда возникает проблемы межгруппового взаимодействия, что отрицательно влияет на сроки и качество тестирования. Кроме того, подобная рассогласованность ведет к удорожанию тестирования, о котором говорилось выше. RUP оговаривает процесс тестирования, как процесс неотрывный от этапа определения требований и этапа разработки программного продукта. То есть тестирование проводится на протяжении всего жизненного цикла разработки программного продукта и организуется такой процесс, при котором любое видоизменение (перекомпиляция) программного продукта приводит к его тестированию. Таким образом, различные скрипты функционального тестирования начинают появляться сразу после того, как разработчик создал определенную графическую форму. Последующее добавление различных компонент приводит к появлению новых скриптов тестирования, и так до тех пор, пока не выйдет стабильная версия программного продукта, удовлетворяющая заданному качеству. Отдельного разговора заслуживает процедура связи тестировщиков и разработчиков. Тестировщик, обнаружив ошибку, документирует, а разработчик ее исправляет, перекомпилирует программный продукт (или его модуль), а затем передает тестеру. Тестер повторно запускает наработанные тесты для данного программного продукта. В зависимости от результатов (ошибка действительно была исправлена или все-таки нет) ошибка позиционируется либо как исправленная, и в этом случае к ней больше не возвращаются, либо признается неисправленной, и тогда разработчик проводит еще одну итерацию для ее исправления. И так до тех пор, пока программный продукт или модуль не будут удовлетворять нужному качеству. Зачастую, такой вид тестирования называют регрессионным. Основные преимущества итерационного подхода состоят в том, что: проводится тестирование ранних прототипов программного продукта; получение точной информации о ходе прогресса (или регресса) в работе над программным продуктом (с целью своевременной корректировки неудачных решений); постепенное создание библиотеки тестовых скриптов; при тестировании массивных приложений облегчается жизнь тестеров (за счет автоматической проверки каждого релиза программного продукта. Программный продукт совершенствуется через итерации. В каждой итерации коллектив разработчиков выполняет сборку программы. Каждая сборка является потенциальным кандидатом для тестирования. Для каждой сборки могут разрабатываться или уточняться тесты. Поскольку процесс разработки является итерационным некоторые тесты, используемые при тестировании ранних сборок, могут быть использованы и при тестировании последующих сборок. Такой процесс тестирования называется регрессионным тестированием. Каждая новая итерации подразумевает повторное тестирование всех компонентов, 55 разработанных на предыдущей итерации, плюс разработка тестов для тестирования новых компонент и их тестирование. На рис.2.3. приведен пример [10] тестируемых компонент на различных итерациях. Рис. 2.3. Пример тестируемых компонент на различных итерациях Итерационный подход позволяет получить наибольший эффект в регрессионном тестировании. Большинство итерации Х присутствует в итерации Х+1, а итерация Х+2 содержит в себе все компоненты всех предыдущих итерации, плюс новые. Так как одни и те же операции повторяются достаточно часто, то необходимо иметь определенный набор инструментальных средств, которые обеспечат автоматизированное тестирование уже имевшихся компонентов в предыдущих итерациях. Обратите внимание на жизненный цикл тестирования вне остальной части проекта. Это тот путь, которым различные действия по тестированию связаны и обобщены, если смотреть на них в не итеративном представлении. Жизненный цикл тестирования часть жизненного цикла разработки программного обеспечения (рис.2.4). Рис. 2.4. Жизненный цикл тестирования 56 Они должны запускаться одновременно. Дизайн и разработка механизмов тестирования, определения тактики и стратегии тестирования, такие же трудоемкие задачи, как и задачи разработки программного кода. Из этого следует, что любое упущение в тестировании (поздний старт, недостаточная проработка тестов,) негативно сказывается как на эффективности самого тестирования, так и на качестве итогового программного продукта. Стадии тестирования. Обычно тестирование используется для различных целей на разных стадиях жизненного цикла программного обеспечения. По RUP процесс тестирование можно разбить на следующие стадии: - модульное тестирование (Unit Test); комплексное тестирование (Integration Test); тестирование системы (System Test); тестирование для разработчиков (Developer Testing); приемочное тестирование (Acceptance Test) . Комплексное тестирование проводится для того, чтобы гарантировать, что компоненты в модели этапа реализации работают должным образом совместно, реализуя соответствующую функцию системы. При этом тестируется подсистема или набор подсистем модели этапа реализации. Комплексное тестирование позволяет выявить неполноту или ошибки в спецификациях интерфейсов подсистем. Тестирование системы проводится, когда программное обеспечение уже функционирует в целом, или когда отдельные функциональные подсистемы полностью реализованы. Тестированию системы обычно подвергается полная модель стадии реализации. Приемосдаточные испытания выполняются перед развертыванием программного продукта в среде конечных пользователей. Цель этих испытаний показать, что программный продукт готов и может быть использован пользователями при выполнении ими свих функциональных обязанностей. Тестирование для разработчиков (Developer Testing). Определяет объем работ по тестированию на этапе разработки программистом программного кода. Для осуществления данного вида тестирования определен специальный набор программных инструментов, которые используют как разработчики, так и независимые тестировщики. Предметная область и набор инструментов совместного тестирования (тестировщики+разработчики) способствует улучшению качества конечного продукта. Данный вид тестирования может содержать дополнительный требования на качество разрабатываемого кода - на соответствие его определенным стандартам разработки (подробнее смотрите в главе инструментальной поддержки). Приемочное тестирование конечный этап тестирования. Пользовательского тестирования. Определяет последние шаги по тестированию 57 перед сдачей продукта заказчику (перед внедрением). Цель тестирования заключается в финальной проверке приложения на соответствие ранее установленным требованиям по интерфейсу, стабильности, и т. д Основные метрики тестирования. Основными характеристиками тестирования являются характеристики тестового покрытия и качества. Тестовое покрытие является мерой полноты тестирования и основывается на покрытии требований к системе или покрытии исполняемого кода. Качество системы или приложения определяется его надежностью и производительностью. Для оценки характеристик тестового покрытия, надежности и производительности используют различные метрики. Для оценки тестового покрытия требований к системе используются следующие метрики: тестовое покрытие; планируемое тестовое покрытие; разработанное тестовое покрытие; исполняемое тестовое покрытие; Метрики покрытий могут вычисляться как по отношению к контрольным задачам, так и тестовым процедурам. Например, метрика тестовое покрытие определяется как отношение общего числа запланированных, разработанных, исполняемых, успешных контрольных задач или тестовых процедур к общему числу требований. Для оценки тестового покрытия исполняемого кода используются метрика, вычисляемая как отношение числа строк исполняемого кода при тестировании к общему числу строк кода. Оценки надежности и производительности определяются на основе анализа результатов тестирования и запросов на изменения, возникших во время тестирования. Для оценки надежности, например, могут использоваться следующие метрики : - время наработки на отказ; время восстановления (как долго автоматизированная система может не работать после появления неисправности); точность в соответствие с известными стандартами, если это требуется для результатов программного продукта на выходе; максимальное число программных ошибок или коэффициент ошибок (число программных ошибок на тысячу строк кода или на функцию). Для оценки производительности, например, могут использоваться следующие метрики: время отклика - получения результатов на типовое задание; пропускная способность - число типовых заданий, исполняемых в единицу времени. Термин качество связан с понятием отсутствие дефектов в приложении. Основной целью тестирования является оценка качества будущего программного 58 продукта. Это общая оценка и выводить общую оценку качества нужно по многим критериям. Перечислим факты, которые влияют на качество: Развернутый, исполняемый код. Данный критерий относится к самому коду программы, тому, из которого вырастает приложение, тестируемое в дальнейшем по функциональному сценарию. Но перед тем как модуль (приложение или его часть) будут подвергаться функциональному тестированию, разработчики должны проверить код своих модулей таким образом, чтобы он удовлетворял следующим критериям: Надежность. Полученный в разработке код устойчив к падениям при каждом запуске программного продукта (т.е. ПО не содержит ошибок связанных с неправильным разделениям памяти, не содержит run-time ошибок, и т.д); Функциональность. Код удовлетворяет предыдущему критерию, а также тем требованиям, которые были выявлены на вышестоящих этапах (моделирование, анализ и дизайн, определение требований); производительность. Код удовлетворяет двум вышеприведенным требованиям и показывает наивысшую производительность при исполнении. Совокупность трех критериев дает качественный продукт уже на этапе его разработки. То есть разработчики отдают тестерам программный модуль с нужной (определенной) функциональностью и свободным от всех логических ошибок в коде. То есть код практически без ошибок. Качества для данных критериев можно добиться, используя одинаковый набор программных средств для каждого участника проекта (то есть данные по проекту передавать не устно, а через набор специальных программных продуктов), а так же широкого применения универсальных шаблонов различного вида словарей для избежания рассогласования в терминах. Качество всех компонентов, составляющих приведенные группы, должно быть измерено и оценено. И что немаловажно, при оценке качества нужно оперировать не только материальными критериями (артефактами), но и такими как моментами организации и качеством самих процессов, протекающих в компании. Основной документ этапа тестирования «тест–план» - регламент всех плановых работ, связанных с тестированием. Точно определение целей тестирование и их ясное изложение в плане позволит наиболее оптимально использовать ресурсы компании, как аппаратные, так и человеческие. Серьезное отношение должно быть ко всем регламентирующим документам. За конечное качество продукта ответственны все участники проекта, если продукт получился некачественным, то в этом виновны все. Задача тестирования состоит не в том, чтобы гарантировать качество, а в том, чтобы его оценить, обеспечив при этом обратную связь со всеми участниками проекта, т.е. главная задача тестера состоит в оценке качества тестируемого программного продукта и организации обратной связи с коллективом 59 разработчиков (для исправления найденных дефектов). Основная же роль «остальных» участников состоит в предоставлении артефактов, удовлетворяющих требованиям и критериям качества. Оценку качества программного продукта следует производить для следующих типов требований: функциональных (Functionality); удобства использования (Usability); надежности (Reliability); производительности (Performance); требований к сопровождению системы (Supportability), проектных ограничений (Design Requirement); требований к реализации (Implementation Requirement); требований к интерфейсу (Interface Requirement); требований к физическим характеристикам системы (Physical Re Requirement). Стратегия тестирования. На этапе стратегии предопределяются вся дальнейшая политика, все дальнейшие действия, связанные с тестированием. Определяются стадии тестирования и типы тестов. Оформляется и разрабатывается тест план, определяется состав участников и их роли. Стратегия определяет: - какие инструментальные средства и методы будут применяться; критерии завершения итераций; единицы измерения качества конечного программного продукта; процентную установку области охвата кода (то есть, что считать полностью протестированным приложением); Е - специальные соображения, затрагивающие ресурсы; типы отчетов и способы автоматизированного их хранения; виды применяемых тестов: «черный ящик» или «стеклянный ящик», либо их комбинации на различных стадиях. Перечислим основные виды тестов: функциональное тестирование; тестирование целостности баз данных; тестирование бизнес циклов; тестирование пользовательского интерфейса; профилирование производительности; нагрузочное тестирование; стрессовое тестирование; объемное тестирование; тестирование управления доступом, тестирование безопасности, тестирование восстановления после сбоев; конфигурационное тестирование; инсталляционное тестирование. Перечисленные виды тестов позволят осуществить всестороннее тестирование программного продукта. RUP регламентирует все виды работ, а также методику подготовки тестовых наборов. В том числе регламентируются такие параметры как: цель тестирования, методика тестирования, критерии тестирования, а также определяются особые условия, необходимые для проведения всестороннего тестирования. Функциональное тестирование объекта-тестирования планируется и проводится на основе требований к тестированию, заданных на этапе определения требований. В качестве требований выступают диаграммы use-case, бизнесфункции и бизнес-правила. Цель функциональных тестов состоит в том, чтобы 60 проверить соответствие разработанных графических компонентов установленным требованиям. В основе функционального тестирования лежит методика "черного ящика". Идея тестирования сводится к тому, что группа тестировщиков проводит тестирование, не имея доступа к исходным текстам тестируемого приложения. При этом во внимание принимается только входящие требования и соответствие им тестируемым приложением. При необходимости можно воспользоваться подходом, называемым «стеклянным ящиком». В режиме «стеклянного ящика» тестировщик должен владеть языком реализации и тестировать код приложения в соответствии с принятыми стандартами на разработку. На этапе функционального тестирования не применяется тестирование «стеклянного ящика» в чистом виде - используется комбинация двух видов тестирования. Подход «стеклянного ящика» для функционального тестирования несет ряд ограничений, и способен проводить тестирование по ряду категорий [6]. Контрольные вопросы 1) Что вкладывается в понятие тестирование? 2) Проясните стратегию тестирования. 3) Что понимается под функциональным тестированием? 4) Какие функции возлагаются на тестировщика как участника проекта? 5) Поясните основные метрики тестирования. 2.2. Управление программами 2.2.1. Определение программы как объекта управления Управление программами (Program Management) - процесс управления совокупностью взаимосвязанных проектов и отдельных работ, включенных в общую программу, для достижения предусмотренных в программе целей и результатов. Наличие стратегических выгод, общих ресурсов, взаимозависимости, необходимость скоординированного планирования - именно эти факторы определяют, нужно ли управлять множеством проектов как программой. В рамках управления программой проводится анализ всех взаимозависимостей между проектами и определяется оптимальная стратегия реализации данной программы. Это влияет на планирование и организацию исполнения каждого проекта в рамках программы. Управление множеством проектов, объединенных в программу, может предусматривать оптимизацию затрат, расписания работ, распределения человеческих ресурсов в интересах программы в целом [15]. 61 В рамках организационной структуры руководства программой могут выделяться следующие роли: - куратор (директор) программы. Отвечает за стратегию и политику ее реализации, поддержку программы внешним окружением; - совет управления программой. Обладает полномочиями принимать стратегические решения относительно содержания, бюджета, расписания программы, а также решать проблемы и предотвращать риски; - менеджер программы. Пользуется поддержкой офиса программы, отвечает за работы по ее исполнению; - менеджеры проектов. Отвечают за своевременное предоставление отчетов по своим проектам. При выявлении рисков и проблем должны сразу же сообщать о них или принимать меры по их разрешению. Руководитель программы должен поддерживать необходимый баланс между ожиданиями и требованиями участников, часто противоречащими друг другу, временными и ресурсными ограничениями, которые неизбежно возникают во взаимозависимых проектах. Standard for Program Management - Third Edition дает детальное описание управления программами, и способствует более эффективной и продуктивной коммуникации и координации между и внутри групп, осуществляющих управление проектами. 2.2.2. Структура системы управления программой Управление программами на предприятии следует рассматривать как механизм перевода стратегических приоритетов в согласованные практические инициативы с последующим управлением программами и проектами, сформированными с целью реализации этих стратегических приоритетов, и адаптацией к изменяющимся потребностям. Выделяют три основных процесса: стратегическое управление портфолио (совокупностью программ предприятия), управление реализацией программ, управление проектами. Основные отличия программ от проектов заключаются в следующем: как правило, программа состоит из нескольких взаимосвязанных проектов; программы продолжительнее отдельных проектов и могут не иметь фиксированного срока завершения; программы в большей степени, чем проекты, развиваются и изменяются с течением времени по мере изменения внешних и внутренних условий; программы сложнее проектов и требуют большего внимания высшего руководства. Процессы управления программой во многом соответствуют процессам управления отдельным проектом и перечислены ниже: - процессы инициации. Обеспечивают авторизацию программы или проектов внутри нее. Определяются выгоды от реализации программы, создается соответствующий план; - процессы планирования. Определяется оптимальный план действий для достижения выгод и выполнения объема работ по программе; 62 - процессы организации исполнения. Обеспечивают интеграцию и организацию работы участников проектов и мобилизацию ресурсов для реализации плана программы в целом и достижения ожидаемых выгод; - процессы мониторинга и контроля. Оценивается реализация программы и соответствующих проектов - достигаются ли ожидаемые выгоды. Выявляются отклонения от плана реализации, при необходимости выполняются корректирующие действия; процессы завершения. Обеспечивают формальную приемку и оформление полученных результатов и выгод, подготовку итоговой отчетности по программе в целом. Особенность реализации процессов управления программой заключается в необходимости согласования отдельных проектов в рамках программы и в нацеленности на получение дополнительных выгод для компании за счет управления изменениями и интеграции результатов отдельных проектов. Для обеспечения согласованного управления различными проектами, входящими в программу, создается соответствующая организационная структура, а также разрабатываются единая политика и процедуры, определяющие общие правила УП, входящими в программу, и программой в целом. Единая политика и процедуры могут регламентировать следующие требования и процессы, общие для всех проектов программы: - общие требования к разработке документов, утверждению документации и решений в рамках программы; - общий подход к управлению изменениями; - систему показателей для оценки успеха отдельных проектов и программы в целом; - общие подходы к управлению рисками, проблемами, выгодами; соответствующие меры контроля, обеспечивающие постоянное соблюдение процедур. 2.2.3. Управление реализацией программ Управление реализацией программ - это постоянное применение определенных процессов, инструментов и методов, обеспечивающих координацию и выполнение проектов в рамках программы с целью получения предприятием максимальных преимуществ. Структура управления включает три традиционные группы процессов – планирование, выполнение и контроль – эффективность которых определяется наличием соответствующих организационных структур, человеческих навыков, опыта и вспомогательных инструментов. Планирование включает создание ряда документов, обеспечивающих общее понимание заинтересованных лиц и определяющих принципы реализации программы и контроля над ней. На основе целей, задач и ожиданий, определенных 63 в ходе стратегического управления портфолио, разрабатывается план их реализации, проводится анализ взаимозависимостей, загрузки ресурсов, рисков. Выполнение заключается в поддержке реализации плана программы. Сюда же относятся инициация новых проектов, закрытие завершенных или потерявших свою актуальность. Контроль включает в себя выявление связанных с программой рисков, проблем, изменений и затрат, управление ими и составление отчетов о них, отслеживание запланированных результатов и мониторинг основных контрольных точек. Остановимся более подробно на этапе исполнения программы и достижение выгод. Цель этого этапа - инициировать проекты, входящие в состав программы, и координировать цели для достижения запланированных выгод. Этот этап является итеративным и может длиться неопределенно долго, поскольку работы, перечисленные ниже, повторяются столько раз, сколько это необходимо, а выгоды (положительные результаты) постепенно накапливаются. Этап заканчивается только тогда, когда достигнуты запланированные выгоды программы или принимается решение закрыть ее по какой-либо причине. На этом этапе выполняются следующие работы: - формирование структуры проектов в рамках программы; - создание организационных структур и запуск процессов контроля исполнения проектов; - обеспечение менеджерами проектов определенной методологии управления ими; - обеспечение соответствия получаемых результатов необходимым техническим требованиям; - анализ прогресса (динамики продвижения) в реализации плана программы; - определение изменений, которые могут повлиять на управление программой или запланированные выгоды; - обеспечение координации общих работ и зависимостей между проектами или другими программами портфеля; - определение рисков и проведение соответствующих действий по их уменьшению; - определение проблем и проведение корректирующих воздействий; - координация эффективного использования ресурсов в программе и проектах; - обзор запросов на изменения и одобрение дополнительных работ (при необходимости); - коммуникации с участниками и советом управления программой. Контрольные вопросы 1) Что понимается под управлением программами на предприятии? 64 2) В чем заключается управление программой? 3) Перечислите и поясните суть основных этапов управления программами 4) В чем особенность реализации процессов управления программой 2.3. Управление портфелями проектов 2.3.1. Определение портфеля проектов как объекта управления Портфель проектов - множество проектов и программ, объединенных для удобств управления. Проекты и программы в портфеле проектов могут иметь или не иметь общие цели, но, как правило, имеют общие ограничения по ресурсам. В методе PRINCE2(R) 2009 под портфелем проектов понимаются все программы и отдельные проекты, которые осуществляет организация, группа организаций или организационная единица. Управление портфелем проектов - неотъемлемая часть общего стратегического плана организации. Целью управления портфелями является «сделать правильную работу». Standard for Portfolio Management - Third Edition содержит самую актуальную информацию по используемым практикам в сфере управления портфелем проекта. Управление портфелем (Portfolio Management) централизованное управление одним или несколькими портфелями, включая идентификацию, определение приоритетов, авторизацию и управление проектами, программами и другими имеющими отношение работами для достижения определенных стратегических целей. Сегодня существует целый ряд методологических подходов к управлению портфелем проектов, каждый из которых дает свое определение, и по-своему структурирует жизненный цикл управления портфелем проектов: - стандарт PMI по управлению портфелем проектов; - Национальные Требования к компетенции специалистов по управлению проектами; - ряд методологических наработок российских и зарубежных консалтинговых компаний. Если сравнивать ценность управления проектами для организации, то можно сделать выводы, что: 1) управление портфелем дает возможность организациям идентифицировать и отобрать те инвестиции, которые максимизируют бизнесценность; 2) управление проектами дает возможность организациям успешно реализовать отобранные инвестиции, тем самым, увеличив бизнес-ценность. Другими словами, управление портфелем отвечает на вопрос "Какие проекты являются правильными, т.е. имеют максимальную ценность для компании"", а управление проектами позволяет правильно управлять этими 65 правильными проектами" т.е. достигать проектные цели, не выходя за рамки проектных ограничений, тем самым обеспечивая эту ценность. 2.3.2. Жизненный цикл управления портфелем проектов Жизненный цикл управления портфелем проектов включает в себя несколько фаз, представленных на рис. 2.5. Рассмотрим более подробно. Создание портфеля Отбор проектов Планирование Управление реализацией Рис.2.5. Жизненный цикл управления портфелем проектов Фаза Создания портфеля проектов. Основной целью фазы создания портфеля проектов является формирование пула проектов, которые потенциально затем могут быть инициированы и приняты к реализации. Т.е. на данной фазе осуществляется сбор проектных (инвестиционных) инициатив и заявок без учета финансовых и иных ограничений Компании. В разных компаниях данная фаза может быть организована по-разному - в зависимости от масштаба компании и объема проектных заявок. В основном, все это сводится к 2-х шаговой структуре: - сначала проектная идея прорабатывается укрупнено (в разных компаниях могут использоваться различные формы " Проектная заявка, Инвестиционная заявка, Запрос на реализацию проекта и т.д.). Цель этой проработки " получение оценки того, насколько данная идея удовлетворяет стратегическим целям Компании и является ли реализация данной идеи целесообразной и актуальной. После согласования и утверждения проектной идеи (инвестиционной заявки) проводятся технологические, экономические и иные изыскания/расчеты (в форме ТЭО, Бизнес-плана и т.д.). Целью данных расчетов является оценка того, насколько эффекты от реализации данной идеи соответствуют вложениям в ее реализацию. По завершению согласования и утверждения Бизнес-плана, данный проект попадает в пул проектов, потенциально интересных для реализации в составе портфеля проектов. В крупных компаниях данные 2 этапа могут разбиваться на подэтапы. Например, для многих крупных компаний характерно разбиение этапа 2 на два подэтапа: - Расчет проекта без учета возможностей по его финансированию (когда принимается, что проект будет финансироваться за счет собственных средств). На этом этапе рассматриваются альтернативы с точки зрения технологических и 66 организационных вариантов реализации проекта, выбирается оптимальный вариант и для него рассчитывается экономическая эффективность. - Расчет проекта с учетом альтернативных вариантов его финансирования (связанное кредитование, проектное финансирование, гранты, долевое участие и т.д.). На этом этапе учитывается различная стоимость денег, привлекаемых из различных источников, а также возможности по разделению проектных рисков с внешними участниками. Фаза отбора портфеля проектов. Целью фазы отбора портфеля проектов является отбор проектов в портфель с учетом финансовых и иных ограничений портфеля. Т.е. на данной фазе из полученного на фазе создания пула потенциальных проектов создается тот портфель, который будет принят к реализации. Типичный процесс на данной фазе также состоит из двух этапов, которые могут модифицироваться в зависимости от специфики бизнеса и организационной структуры компании: Ранжирование (приоритизация) проектов. Т.к. в условиях ограниченности финансовых ресурсов для компании крайне важно реализовывать наиболее эффективные и стратегически значимые проекты, то на первом этапе необходимо выстроить проекты в порядке убывания их значимости для того, чтобы на следующем этапе производить отбор. Ранжирование может производиться по различным критериям. В рыночноориентированных компаниях в основном ранжирование опирается на экономические и инвестиционные показатели (NPV, срок окупаемости и т.д.). В компаниях, владеющих инфраструктурой и капитальными объектами, часто в ранжировании участвуют технологические показатели, т.е. проекты приоритизируются по их технологической эффективности. В компаниях, которые помимо экономической эффективности, несут на себе нагрузку в виде социальных и государственных обязательств (естественные монополии, госкомпании), в ранжировании могут участвовать показатели социальной эффективности и другие, более специфичные, показатели. На данном этапе наиболее силен субъективный фактор, включаются лоббистские силы, которые пытаются доказать руководству, что их проекты самые эффективные и нужные для компании. Для того чтобы максимально уйти от данного субъективного фактора, необходимо разрабатывать соответствующие методики, в которых были бы прописаны показатели и принципы, на основании которых осуществляется ранжирование. Отбор проектов. После того как проекты проранжированы, начинается этап отбора «какие принять к реализации, а какие нет». Наиболее приоритетные отбираются в первую очередь, наименее приоритетные - в последнюю. 67 При этом вариантов решений может быть много, например, если у компании не хватает средств на реализацию каких-то проектов, она может привлечь эти деньги с рынка и реализовать больше проектов, что увеличит совокупную эффективность портфеля. Фаза планирования портфеля проектов. На фазе планирования портфеля проектов осуществляются: - запуск проектов (назначение менеджеров проектов, формирование организационных структур, выпуск Уставов проектов); - допланирование (детализация всех видов планов относительно приведенных в бизнес-плане до степени, необходимой для успешной реализации проекта); - выделение ресурсов (выделение конкретных людей, производственных мощностей и т.д.) Спецификой данной фазы относительно фаз инициации и планирования отдельных проектов является то, что при планировании портфеля проектов должны учитываться разделяемые ресурсы (т.е. те ресурсы, которые будут потребляться несколькими проектами) и ресурсные конфликты должны разрешаться уже на этой фазе. Фаза управления реализацией. На фазе управления реализацией выполняются следующие задачи: - мониторинг выполнения проектов в портфеле, анализ отклонений при реализации проектов и их влияния на связанные проекты и портфель в целом; - координация ресурсов. В ходе реализации некоторые проекты могут приостанавливаться, а их ресурсы перебрасываться на другие, более приоритетные проекты. 2.3.3. Оптимизация и балансировка портфеля проектов Главное ограничение в любой организации - ресурсы (люди и финансы) Организация не может в краткосрочной перспективе нарастить денежные запасы и нанять квалифицированный персонал, поэтому эффективное распределение ресурсов между проектами - самое важная цель управления проектами портфеля. Целями управления проектами портфеля является: - оптимизация - распределение ресурсов с целью максимизации ценности портфеля с учетом таких его показателей, как рентабельность, ROI, NPV (чистый дисконтированный доход), IRR (внутренняя форма доходности), риск и другие; - балансировка - достижение желаемого равновесия проектов через такие параметры как риск и ROI, краткосрочность и долгосрочность проекта и другое; - стратегическое выравнивание – гарантирование того, фиксированный объем средств на исполнение проектов компании будет расходоваться в соответствии с ее приоритетами; 68 - приоритезация – ранжирование правильных проектов для достижения наилучшего баланса между потребностями в ресурсах (люди, машины и механизмы, финансы) и их наличием; - осуществимость – гарантирование того, что благодаря предложенным проектам будут достигнуты их цели и, как следствие, будут достигнуты цели компании. Рассмотрим семейство продуктов для управления проектами Enterprise Project Management. Линейка продуктов покрывает полный жизненный цикл управления портфелем проектов. Project Portfolio Server включает в себя основные модули. Модуль PortfolioBuilder предназначен для сбора проектных заявок и формирования пула проектов, которые потенциально могут быть интересны для реализации. По умолчанию в PortfolioBuilder заложена следующая логика. Пользователь создает заявку на проект (Project Request), в котором указываются основные параметры заявки (описание проектной идеи, соответствие стратегии, оценка затрат и доходов, рисков, ресурсов и т.д.). При этом форма заявки может настраиваться - туда могут включаться те поля, которые содержатся в форме заявки на проект, приведенной в корпоративном стандарте Компании по управлению портфелем проектов. После создания заявка начинает свое движение по маршруту согласования, при этом маршруты также могут настраиваться. Согласованная заявка утверждается, и на основе утвержденной заявки разрабатывается бизнес-план (Business Case), в котором приводятся уже более детальные параметры проекта. После создания бизнес-план также запускается по маршруту согласования. При этом маршрут для бизнес-плана может быть отличным от маршрута заявки на проект. Согласованный и утвержденный бизнес-план попадает в пул потенциально интересных проектов и в дальнейшем участвует в ранжировании и отборе. При этом по умолчанию логика при внедрении системы может быть переопределена в соответствии с корпоративным стандартом по управлению портфелем проектов. Например, может быть реализована 3-х этапная схема (заявка - технико-экономическое обоснование - бизнес-план): 1) Модуль РortfolioOptimizer является основным и предназначен для оптимизации портфеля проектов. Первый этап оптимизации портфеля «Ранжирование проектов», включает в себя следующие шаги: Попарное сравнение стратегических целей компании необходимо проранжировать стратегические цели, чтобы определить, какая из них более важна, а какая менее. 69 Цель Цель 2 1 Цель 1 Цель 2 Цель 3 Цель n-1 Критично важнее Цель 3 Цель n-1 Цель n Сильно важнее Сильно важно Ненамного важнее Ненамного менее важно Эквивалентно Эквивалентно Сильно важнее менее Критично менее важно Ненамного важнее Цель n После получения отранжированного перечня стратегических целей, выполняется ранжирование проектов по их стратегической значимости, для чего производится оценка влияния проектов на стратегию; 2) Второй этап оптимизации портфеля «Отбор проектов», который включает в себя следующие шаги. Первый шаг отбор проектов с учетом ограничений портфеля. Наиболее распространенное ограничение " бюджетное. Следующий шаг отбора «Учет проектных взаимосвязей». Предположим те же условия, но Проект 1 связан с Проектом n (т.е. реализация Проекта n невозможна без реализации Проекта 1 и наоборот). Включив это ограничение, система отберет проекты в соответствии с заданными параметрами; 3) Модуль для мониторинга портфеля проектов на этапе реализации PortfolioDashBoard". Для многих российских компаний функциональность Project Portfolio Server позволяет вывести многие процессы управления проектами, особенно оптимизации портфеля проектов, на новый уровень. Контрольные вопросы 1) Чем отличается портфель проектов от программы? 2) В чем заключается управление портфелем проектов? 3) Перечислите и поясните суть основных фаз управления портфелями проектов. 4) Перечислите ресурсы, необходимые при планировании портфеля 70 3 ИТОГОВЫЙ ТЕСТ Вопрос 1 Укажите номер правильного ответа: Проект бюджета: а) постатейный список предполагаемых затрат, необходимых для осуществления проектных работ; б) список предполагаемых затрат, напрямую относящихся к проекту; в) список предполагаемых затрат, включающих административную поддержку, заработную плату, аренду оборудования. Вопрос 2 Укажите номер правильного ответа: 2) Метод аналоговой оценкиа) метод индивидуальной оценки каждого задания с последующим суммированием всех полученных результатов для определения стоимости проекта; б) метод оценки проекта, основанный на фактической стоимости предыдущих проектов, аналогичных по размеру и содержанию оцениваемому проекту; в) метод, основанный на использовании прямых и косвенных затрат. Вопрос 3 Укажите номер правильного ответа: 3) Метод оценки и пересмотра планов (ПЕРТ) используется для: а) определения ожидаемого значения критического пути; б) определения средневзвешенной величины времени проекта; в) определения длительности проекта путем определения трех прогнозов – ожидаемого, пессимистического и оптимистического. Вопрос 4 Процесс управления совокупностью взаимосвязанных проектов и отдельных работ, включенных в общую программу, для достижения предусмотренных в программе целей и результатов называется: а) управлением проектом; б) управлением программой; в) управлением портфелем проектов, г) корпоративным управлением. Вопрос 5 Укажите все правильные ответы: Особенность реализации процессов управления программой заключается: а) в необходимости согласования отдельных проектов в рамках программы; б) в нацеленности на получение дополнительных выгод для компании; в) в управлении изменениями и интеграции результатов отдельных проектов; 71 Вопрос 6 Какие данные содержатся в плане взаимодействия? а) сроки и периодичность получения информации; б) способ получения информации, метод сбора и хранения информации; в) лица, осуществляющие взаимодействие по проекту; г) метод архивирования проектной документации. Вопрос 7 По каким критериям определяются цели проекта? а) методика СМАРТ б) наличие обратной связи через оценку (Evaluated) в) возможность и необходимость периодической корректировки цели (Reviewed); г) морфологический анализ. Вопрос 8 Назовите методы оценки длительности операций? а) экспертная оценка; б) параметрическая оценка; в) матричная; г) методика СМАРТ. Вопрос 9 Какие документы планирования используются в процессе идентификации рисков? а) список заданий; список проектных ограничений; факторы, определяющие успех; иерархическая структура работ; б) таблицы оценки профессиональных навыков; список заданий, список возможных рисков; в) факторы, определяющие успех; иерархическая структура работ; таблицы оценки профессиональных навыков. Вопрос 10 Выберите стратегии реагирования на риски: а) передача, смягчение; б) принятие, уклонение; в) принятие, уклонение; передача, смягчение; г) экспертная оценка. Вопрос 11 Какие процессы планирования может изменить корректировка описания содержания проекта? а) изменение графика и бюджета проекта; б) корректировка целей проекта; в) промежуточные отчеты о развитии проекта; г) корректировка целей проекта, изменение графика и бюджета проекта. 72 Используемая литература 1. A Guide to the Project Management Body of Knowledge, 4th Edition, 2008. 2. Верзух, Эрик. Управление проектами: ускоренный курс по программе MBA. – М.: ООО «И.Д. Вильямс", 2010. 3. Богданов В.В. Управление проектами в Microsoft Project 2007. Учебный курс (+CD). – Спб.: Питер, 2008. 4. Исследование операций в экономике: учебное пособие для вузов / под ред. Н.Ш. Кремера. – М.: ЮНИТИ, 2006. 5. Муравьев В.И., Тавридович С.А. Экстремальные модели менеджмента: учебное пособие / Балт. гос. техн. ун-т. – СПб., 2006. 6. Сатунина Е.А. Управление проектом корпоративной информационной системы предприятия: учеб. пособие / А.Е. Сатунина, Л.А. Сысоева.- М.: Финансы и статистика; ИНФРА-М, 2009.-352 с. 7. Юркевич Е.В. Оценка существенности взаимосвязей характеристик киберсоциальной системы / Е.В.Юркевич, Н.И.Романчева // Труды Международного симпозиума Надежность и качество. - 2016. -№1.- С.59-62. 8. Хэлдман Ким. Управление проектами. Быстрый старт/ Ким Хэлдман; Пер. с анг. Шпаковой Ю.; Под ред. Неизвестного С.И.- М.: ДМК Пресс; Академия АйТи, 2008.-352с. 9. Бирюков В., Дрожжинов В. Проектный подход в современном бизнесе.http://iteam.ru/publications/project/section_42/article_2826 10. Троцкий М. , Груча Б., Огонек К. Управление проектами.-М.: Финансы и статистика, 2006.- 301с. 11. Шеер А.В. Моделирование бизнес-процессов/ А.В. Щеер: пер. с анг. М.: Весть- МетаТехнология, 2000. 12. Шейн Э. Г. Организационная культура и лидерство. 3-е изд. -2011. - 336 с. 13. ДеМарко Т., Листер Т. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения. - Издательство: Компания p.m.Office, 2005. — 196 с. 14. Web-cайт «Корпоративные финансы»: http://www.cfin.ru/itm/project 15. Web-site «Профессионал управления проектами»: http://www.pmprofy.ru/
