Лекция 04 (планирование проекта) 2
реклама
Технологии разработки программного обеспечения Планирование и управление выполнением проекта разработки ПО План лекции • Процесс управления проектом разработки ПО. • Задачи управления проектом. • Планирование управления проектом. Программный процесс • Подпроцессы программного процесса Программный процесс создания программного продукта Процесс разработки Процесс управления проектом Процесс управления конфигурированием ПО Процесс управления проектом • При выборе подходящей модели процесса разработки определяется: – какие этапы и задачи должны быть выполнены; – в какой последовательности они должны выполняться. • Но кроме этого требуется: – определить, как долго каждый этап будет продолжаться; – сколько ресурсов должно быть выделено (люди, техника); – как результаты работы должны отслеживаться. • Качество и производительность проекта критически зависят от управления проектом. • Хорошее управление проектом не гарантирует его успех, но плохое управление почти гарантировано приведет к неудаче: – ПО м.б. поставлено с задержкой; – стоимость разработки может превысить бюджет; – ПО может не соответствовать требованиям заказчика. • Результатом выполнения проекта разработки ПО должно быть: – создано ПО выполняющее требуемые функции с требуемым качеством; – разработка должна не превышать заданную стоимость; – разработка должна быть выполнена в заданные сроки. • Для уменьшения затрат на выполнение проекта, повышения его качества и обеспечения заданных сроков выполнения (календарный план) требуется, чтобы: – выделялись требуемые ресурсы для все работ проекта; – отслеживался ход выполнения разных видов деятельности; – при необходимости предпринимались корректирующие действия. Работы по управлению проектом • Управление проектом включает следующие виды работ: 1. 2. 3. 4. планирование проекта; мониторинг хода выполнения проекта; управление рисками; анализ завершения проекта; Планирование выполнения проекта разработки ПО Планирование выполнения проекта разработки ПО • Планирование работ это наиболее важная часть работ по управлению проектом. • Основные цели: – определить обоснованные цели проекта: • затраты (деньги); • календарный план; • уровень качества. • Проект будет считаться успешным, если он достигнет поставленные цели по деньгам, срокам и качеству. • Без детального планирования не возможно отслеживать и оперативно управлять ходом выполнения проекта. • Никакое количество технических усилий, приложенных позже, не сможет компенсировать недостаток тщательного планирования. • Недостаток планирования большого проекта по разработке ПО практически является гарантией его неудачного выполнения. Входные данные планирования • Входными данными для планирования проекта разработки ПО являются: – спецификация требований к ПО (СТПО); – предполагаемая архитектура разрабатываемого ПО. • Для планирования не требуется детальные требования к ПО, но должны быть уже известны все важные требования. • Очень желательным является наличие ключевых архитектурных решений. Процесс планирования проекта Выявление требований <<system>> Планировщик проекта [не закончено] Выполнение работы Выявление рисков Контрольные точки и результаты Определение календарного плана Отслеживание хода работы по плану [проект завершен] [нет проблем] [серьезные проблемы] [не большие проблем] Начало работ по уменьшению рисков Перепланировка проекта Задачи решаемые в ходе планирования проекта 1. Оценка трудоемкости проекта. 2. Планирование сроков выполнения проекта и состава исполнителей. 3. Управление качеством. 4. Управление рисками. 5. Планирование мониторинга выполнения проекта. 1. Оценка трудоемкости Оценка трудоемкости • Для планирования проекта разработки ПО важным обязательным условием является – общая оценка трудоемкости (объема работ) и – общая оценка сроков выполнения работ. • Такие оценки требуются до того, как процесс разработки будет запущен, т.к. они определяют цели проекта по стоимости и по срокам. • Без таких оценок нельзя ответить на такие вопросы, как: – «опаздывает ли выполнение проекта?» – «превышены ли затраты на выполнение проекта?». • Более практическим использованием таких оценок является обсуждение с заказчиком (торг) цены подписания контракта на выполнение проекта. • Т.к. основными затратами на выполнение проекта являются усилия разработчиков ПО (и сл-но их зарплата), то стоимость проекта можно определить из объема работ по выполнению проекта, путем использования подходящей величины стоимости человека-месяца (месячной зарплаты). • Оценки объема работ (трудоемкости) и сроков выполнения также требуются – для определения количества разработчиков на разных этапах проекта, – для детального планирования и – для мониторинга проекта. Точность оценки трудоемкости • Точность оценки трудоемкости зависят от уровня доступной информации о проекте. • Чем более детальной будет данная информация, тем более точные оценки могут быть сделаны. • Однако, даже при наличии полной информации, точек оценок будет зависеть от эффективности и точности используемых процедур и моделей оценивания. • Если процедуры оценки трудоемкости на основе СТПО позволяют определить трудоемкость с точность в 20% от реальных, в 2/3 случаях, то данный подход может считаться хорошим. Подходы к оценке трудоемкости • Нисходящий подход к оценке трудоемкости – оценка основывается на размере проекта; – трудоемкость рассчитывается, как функция размера проекта. – для учета специфики вводятся поправочные коэффициенты. • Восходящий подход к оценке трудоемкости – проект делится на задачи, – получаются оценки для каждой задачи проекта. – из оценок разных задач определяется общая оценка проекта. Нисходящий подход к оценке трудоемкости • Хотя объем работы (трудоемкость) проекта является функции большого кол-ва параметров, обычно считается, что основным фактором, влияющим трудоемкость проекта является его размер. • Чем больше размер, тем больше требуемый объем работ (трудоемкость). • Нисходящий подход к оценке трудоемкости использует это и рассматривает трудоемкость, как функцию размера проекта. • Для использования такого подхода требуется – оценить размер рассматриваемого проекта; – определить тип функции и ее применение. Нисходящий подход к оценке трудоемкости • Производительность разработчиков (в KLOC) при выполнении аналогичных проектов, то она м.б. использована в качестве оценочной функции для определения трудоемкости исходя из размеров проекта (тоже в KLOC). • Предыдущая производительность разработчиков определяется, как P = SIZE (KLOC) / PM Здесь: – PM = кол-во человеко-месяцев (person-months); – KLOC = тысячи передаваемых строк кода (SIZE) • Тогда оценка трудоемкости в человеко-месяцах PM будет вычисляться, как PM = SIZE / P • Однако производительность разработчиков зависит от размера проекта. – чем больше проект, тем меньше производительность отдельного разработчика, • В связи с этим данный подход может работать только в том случае, если размер и тип проекта аналогичен набору проектов, в которых определялась производительность. • Кроме этого в новом проекте аналогичная производительность м.б. получена в результате следования тому процессу разработки, который использовался в более ранних проектах. Формула оценка трудоемкости проекта разработки ПО • Обычно используется более общая функции для определения трудоемкости на основе размера проекта: Т = a * SIZEb, • где – Т – трудоемкость в чел-месяцах; – а и b - константы, – SIZE - размер проекта (обычно в KLOC). • Размер проекта также может измеряться в других единицах, называемых функциональными точками, которые могут определяться на основе требований. • Значения используемых констант а и b для конкретной организации определяется с помощью регрессионного статистического анализа, который применяется к данным проектов, которые выполнялись ранее. Примеры формул 1. В результате анализа данных более чем 60 проектов, выполненных в IBM Federal Systems Division (размерами от 4 до 467 KLOС передаваемого кода) было выявлено Т = 5.2*(SIZE)0.91. 2. В модели COCOMO (COnstructive COst MOdel) для начальной оценки (также называемой номинальной оценкой) используется следующая формула T = 3.9 * (SIZE)0.91. Влияние других факторов на оценку трудоемкости • Хотя размер создаваемого кода является основным фактором влияющим на стоимость проекта, другие факторы также оказывают некоторый эффект. • В модели COCOMO, после определения начальной оценки учитываются некоторые другие факторы для получения конечной оценки. Источники затрат проекта • Для оценки влияния других факторов используется до 15 разных показателей проекта, называемых - источниками затрат. • Примерами источников затрат являются: – требование надежности ПО; – сложность ПО; – способности аналитиков; – использование современных инструментов разработки; – жесткость сроков разработки. Качественная оценка факторов • Каждый источник затрат имеет качественную оценочную шкалу (высокий, низкий, нормальный) и для каждой оценки задается коэффициент влияния. • Этот коэффициент влияния умножается на оценку трудоемкости: Т’ = Т * k1*k2*k3*…*kn • Например, для источника «обеспечение надежности ПО», оценочными значениями и соответствующими им коэффициентами являются: Оценка важности Очень низкая Низкая Нормальная Высокая Очень высокая Коэффициент 0.75, 0.88, 1.00, 1.15, 1.40, Таблица коэффициентов трудоемкости для разных источников затрат Источник затрат Оценки Очень низкая Низкая Нормальная Высокая Очень высокая 0.75 0.88 1.00 1.15 1.40 0.94 1.00 1.08 1.16 0.85 1.00 1.15 1.30 TIME, ограничение на время выполнения 1.00 1.11 1.30 STOR, ограничение на основную память 1.00 1.06 1.21 Свойства продукта RELY, требуемая надежность DATA, размер БД CPLX, сложность ПС 0.70 Свойства компьютера VITR, изменчивость виртуальной машины 0.87 1.00 1.15 1.30 TURN, время обработки заданий на компьютере 0.87 1.00 1.07 1.15 Таблица коэффициентов трудоемкости для разных источников затрат (2) Источник затрат Оценки Очень низкая Низкая Нормальная Высокая Очень высокая ACAP, способности аналитиков 1.46 1.19 1.00 0.86 0.71 AEXP, опыт разработки 1.29 1.13 1.00 0.91 0.82 PCAP,способности программ-ов 1.42 1.17 1.00 0.86 0.70 VEXP, опыт работы с вирт. маш. 1.21 1.10 1.00 0.90 LEXP, опыт в языке прогр. 1.14 1.07 1.00 0.95 MODP, соврем.програм. подходы 1.24 1.10 1.00 0.91 0.82 TOOL, использование SW tools 1.24 1.10 1.00 0.91 0.83 SCHED, сроки разработки 1.23 1.08 1.00 1.04 1.10 Свойства персонала Свойства проекта Пример оценки трудоемкости системы проведения аукционов 1. Из вариантов использования и других требований было определено, что данная ПС будет состоять из 5 разных модулей: – – – – – – Подключение (Login) - 200 LOC Оплата (Payment) - 200 LOC Интерфейс администратора - 600 LOC Функции продавца - 200 LOC Функции покупателя - 500 LOC Представление и бухгалтерия - 300 LOC --------------------------------------------------------Итого - 2000 LOC Пример оценки трудоемкости системы (2) 2. Если использовать методику COCMO для оценки, то нужно оценить значения разных источников затрат. • Предположим, мы считаем, что: – Сложность системы – Способности программистов – Опыт команды по разработке • • - Высокая - Низкие - Низкий Все другие факторы имеют оценку «нормальный». Тогда корректирующий коэффициент (КК) будет вычисляться следующим образом: КК = 1.15 * 1.17 * 1.13 = 1.52 Пример оценки трудоемкости системы (3) 3. Начальная оценка трудозатрат получается с помощью соответствующего выражения: Тн = 3.9 *2 0.91 = 7.3 PM • Используя корректирующий коэффициент получаем: Т = Тн * КК = 7.3 * 1.52 = 11.1 ЧМ Трудоемкость этапов проекта • Из общей оценки трудоемкости м.б. определена трудоемкость разных этапов проекта. • Обычно это выполняется с помощью распределения трудоемкости между этапами. • Доля (процент) общей трудоемкости относимая на разные этапы меняется в зависимости от типа и размера проекта и м.б. получена из данных о ранее выполненных аналогичных проектах. Таблица распределения трудоемкости по этапам разработки • Таблица распределения трудоемкости (в %) по этапам разработки одного типа ПС, предлагаемая в методике COCOMO. Этап Размер Небольшой (2 KLOC) Промежуточн Средний ый (8 KLOC) (32 KLOC) Большой (128 KLOC) Анализ 16 16 16 16 Проектирование 26 25 24 23 Кодирование и тестирование единиц 42 40 38 36 Объединение и тестирование 16 19 22 25 Весь проект 100 100 100 100 • При использовании нисходящего подхода к оценке трудоемкости (даже при наличии подходящей функции) требуется оценивать размер проекта. • Т.е. проблема оценки трудоемкости заменяется проблемой оценки размера ПО. • Это связано с тем, что оценить размер ПО часто проще, чем оценить его трудоемкость. • В основном оценка размера ПО выполняется на путем сложения оценок размеров его компонентов (которые оценить проще). • Аналогичное нельзя сделать для оценки трудоемкости, – усилия (трудоемкость) по разработке все системы не является суммой усилий по разработке компонент (т.к. дополнительные усилия требуются для интеграции и другой деятельности при разработке системы из готовых компонент). • Для того, чтобы нисходящая оценка работала хорошо важно получить хорошую оценку размера ПО. • Нет «простого» метода точной оценки размера ПО. • При оценке размера ПО лучшим методом м.б. – получение как можно детального описания разрабатываемого ПО – знать о своей предвзятости при оценке размера различных компонент. • В этом случае можно получить достаточно точную оценку размера конечного ПО. Восходящий подход к оценке трудоемкости • В восходящий подходе подходе – проект делится на задачи, – получаются оценки для каждой задачи проекта. – из оценок разных задач определяется общая оценка проекта. • Данный подход также называется оценкой на основе видов работ. • Фактически в данном подходе размер и сложность проекта фиксируется набора задач проекта, которые должны быть выполнены. • В восходящий подходе выполняется прямая оценка трудоемкости (усилий): – проект делится на более мелкие задачи, – появляется возможность напрямую оценить их трудоемкость (особенно, если задачи достаточно малы); • Трудность данного подхода: для получения общей оценки требуется перечислить все задачи. • Риск данного подхода – возможность пропустить какие-то виды деятельности; – трудность оценки трудоемкости (усилий) для некоторых общих вспомогательных задач, которые выполняются в течении всего проекта (например, управление проектом). • Полностью перечислять все задачи не потребуется, если – разработана архитектура создаваемого ПО; – известно распределение трудоемкости по разным этапам. • Далее рассматривается один из таких подходов, используемых в коммерческих организациях. Описание подхода • Вначале определяются основные единицы ПО (компоненты или модули), которые должны быть разработаны в проекте. – Каждая программная единица, на основании некоторого критерия, оценивается, как простая, средняя или сложная (категория классификации). • Для каждой категории определяется средняя трудоемкость кодирования, которая основывается – на прошлых данных из аналогичных проектов; – на основе методических указаний; – на основе опыта специалистов. • Определяется общая оценка трудоемкости кодирования, т.к. для каждой категории известно колво прогр. единиц и оценка трудоемкости кодирования. • Трудоемкость других этапов и работ проекта определяется как процент от трудоемкости кодирования (на основе информации о прошлой производительности данного процесса). – В результате определяется распределение трудоемкости по разным этапам данного проекта. – Оценка общей трудоемкость проекта определяется на основе оценок трудоемкости этапов. • При отсутствии подходящих прошлых данных (например, запускается новый подход), трудоемкость кодирования можно оценить используя прошлый опыт, если определена природа разных типов программных единиц. Поэтапное описание метода 1. Выявление в системе модулей и классификация их на простые, средние и сложные. 2. Определение средней трудоемкости кодирования для простых/средних/сложных модулей. 3. Вычисление общей трудоемкости кодирования на основе трудоемкости разных типов модулей и их количества. 4. Оценивание трудоемкости других работ и общей трудоемкости на основе распределения трудоемкостей работ в аналогичных проектах. 5. Уточнение оценок на основе специфических для данного проекта факторов. Задачи решаемые в ходе планирования проекта 1. Оценка трудоемкости проекта. 2. Планирование сроков выполнения проекта и состава исполнителей. 3. Управление качеством. 4. Управление рисками. 5. Планирование мониторинга выполнения проекта. Календарное планирование и определения состава исполнителей • После определения трудоемкости нужно определить плановые сроки поставки ПО (календарный план). • На основе трудоемкости проекта в чел-месяцах можно – определить сроки и – количество сотрудников (исполнителей) проекта. • Однако все не так просто. Человек и месяц не совсем взаимозаменяемы в проектах разработки ПО. • Человек и месяц могут заменяться только в том случае, если: – Все задачи проекта могут выполняться параллельно; – Никакой коммуникации между людьми выполняющими задачи не требуется. • Для проекта разработки ПО после выполнения оценки трудоемкости проекта, можно сформировать разные расписания (сроки) его выполнения. • Например, если трудоемкость 56 чел-месяцев: – возможными графиками работ являются: • 7 месяцев с участием 8 сотрудников; • 8 месяцев с участием 7 сотрудников; • или, примерно, 9 месяцев с участием 6 сотрудников. – невозможными графиками работ являются: • 1 месяц с участием 56 сотрудников; • никто не возьмется выполнить проект за 2 месяца с участием 28 сотрудников. • Вывод: если трудоемкость определена (зафиксирована), то имеется некоторая гибкость в формировании расписания его выполнения. • Нет простой формулы для вычисления расписания при известных трудоемкости. Правило квадратного корня • Планируемый срок выполнения проекта должен примерно равняться квадратному корню общих трудозатрат в человеко-месяцах. • Такой срок может быть выполнен при условии предоставления соответствующих ресурсов. – Например, если трудоемкость оценивается в 50 человеко-месяцев, то срок выполнения в 7-8 месяцев является подходящим. • С помощью такой макро-оценки срока выполнения, можно определить основные контрольные точки проекта. Функции оценки срока выполнения проекта • Есть функция оценки сроков выполнения проекта на основе оценки ее трудоемкости. • В IBM Federal Systems Division определили, что общая продолжительность выполнения проекта в календарных месяцах (M) может быть оценена следующим образом M = 4.1* Т0.36. • В методике COCOMO используется следующая формула M = 2.5 * Т0.38. • Срок выполнения является не только функцией трудоемкости, поэтому такая оценка является только предварительной. Контрольные точки • Для определения контрольных точек нужно вначале понять «выход на рабочий режим», который обычно происходит в проекте. • Количество сотрудников, которых можно выгодно использовать в программном проекте определяется кривой Rayleigh: – в начале и в конце проекта требуется небольшое количество сотрудников; – наибольший размер команды требуется где-то в середине проекта; – и опять меньше сотрудников требуется после этого. Выход на рабочий режим в обычном проекте • Для простоты составления расписания в небольших проектах, часто требуемое количество сотрудников назначается неизменным в начале проекта. • Это приводит к тому, что вначале и конце проекта, некоторые сотрудники могут быть не занятыми. • Это время простоя часто используется для поддержки таких видов деятельности в проекте, как обучение (вначале) и документирование (в конце). • Если известна оценка трудоемкости для этапа работ, то можно определить длительность данного этапа, если известен • В общем случае: – проектирование занимает около четвертой части всего срока – 0.25; – кодирование занимает примерно половину срока; – интеграция и системное тестирование занимает оставшуюся четверть срока. • В методике COCOMO выделяется: – на проектирование - 19% , – на программирование – 62%, – на интеграцию и тестирование -19%. Календарное планирование проекта • Календарное планирование проекта это процесс определения того, – как работа в проекте будет организована в виде набора отдельных задач; – когда и как эти задачи будут выполняться. • Необходимо оценить: – календарное время, требуемое для выполнения каждой задачи; – требуемую трудоемкость; – кто будет работать над поставленной задачей. • Также необходимо оценить ресурсы, требуемые для завершения каждой задачи, такие, как: – кол-во сотрудников; – дисковое пространство на сервере; – время требуемое на специализированных технических устройствах; – командировочные расходы и т.п. Начальный календарный график проекта • Разработанный календарный график затем уточняется и изменяется в ходе планирования разработки. • Однако, почти все процессы разработки (плановые, гибкие) требуют начального календарного графика проекта, хотя уровень детальности может быть значительно ниже в гибких процессах разработки. • Начальный календарный график используется – для планирования выделения распределения сотрудников по проектам и – проверки хода их выполнения сроков заданных в подписанных договорах. • В традиционных (плановых) процессах разработки вначале разрабатывается полный график работ, который затем корректируется в ходе выполнения проекта. • В гибких процессах разрабатывается укрупненный график, который определяет, когда большие этапы проекта будут выполнены. Диаграмма календарного плана работ • Вся работа выполняемая в проекте разбивается на отдельные задачи и оценивается время требуемое для завершения каждой задачи. • Задачи должны обычно продолжаться от 2 до 8 недель (не более 2 месяцев). • Некоторые задачи могут выполняться параллельно, когда разные сотрудники работают над разными задачами. • Необходимо координировать такие параллельные задачи и организовывать работу таким образом, чтобы сотрудники использовались оптимально и не вносились не нужные зависимости между задачами. • Важно избегать ситуаций, когда весь проект задерживается из-за не завершения критически важной задачи. Схема составления диаграммы календарного плана работ Выявление работ Спецификация требований к ПО Выявление зависимостей работ Оценка ресурсов для работ Выделение сотрудников для работ Составление графиков работ Диаграммы календарного плана работ Контрольные точки • При планировании проекта необходимо определить контрольные точки (КТ, milestones) – моменты выполнения проекта, в которых должна выполняться оценка достигнутых результатов. • Каждая КТ должна быть документирована кратким отчетом, который достигнутые результаты. • КТ может быть связана с отдельной задачей или с группой взаимосвязанных работ. Промежуточные результаты • Специальным видом КТ является создание промежуточного результата (ПР, deliverable) – некоторого продукта, который передается заказчику. • Например: – спецификация требований к ПО; – проект (модель) ПО; – Подсистема и т.п. • Обычно требуемые ПР фиксируются в контракте (хоз. договоре) проекта. Табличное представление графика работ Представление графика работ в виде столбчатой диаграммы Диаграмма распределения ресурсов Задачи решаемые в ходе планирования проекта 1. Оценка трудоемкости проекта. 2. Планирование сроков выполнения проекта и состава исполнителей. 3. Управление качеством разработки ПО. 4. Управление рисками выполнения проекта. 5. Планирование мониторинга выполнения проекта. 6. Составление детального графика выполнения проекта. Планирование качества • План качества это набор работ предназначенных для достижением требуемого в проекте качества ПО. • Для планирования качества вначале нужно вначале понять цикл внесения и удаления дефектов, т.к. именно дефекты определяют качество конечного предоставляемого ПО. • Разработка ПО в значительной степени связана с деятельностью людей и поэтому имеет большое кол-во ошибок. • Программный проект начинаем без дефектов (нет ПО и нет ошибок). • Дефекты вносятся в ПО по ходу его разработки на разных этапах проекта. • Т.е., в ходе преобразования потребностей заказчика в ПО, дефекты вносятся в ходе выполнения работ. • Основными этапами, которых вносятся дефекты являются: – – – – спецификация требований; высокоуровневое проектирование; детальное проектирование кодирование. • Для гарантии разработки высококачественного ПО эти дефекты должны выявляться и удаляться в ходе работ по управлению качеством. • К работам по управлению качеством относятся: – – – – – – – – – проверка требований; проверка результатов проектирования, проверка кода, тестирование единиц кода; интегрированное тестирование; системное тестирование; тестирование приемо-сдаточные испытания, и т.п. Цикл внесения и удаления дефектов • Обеспечение качества ПО м.б. достигнуто за счет: – уменьшения дефектов, которые м.б. внесены в ПО • за счет следования стандартам, методологиям, лучшим практическим решениям, которые помогают уменьшать вероятность появления ошибок; – увеличение количества найденных и удаленных дефектов. Проверка и тестирование • Проверка и тестирование это два наиболее часто используемых в проекте вида деятельности в по управлению качеством. – Проверка это структурированный, выполняемый людьми процесс; – Тестирование это процесс выполнения ПО (или его части) в попытке выявить дефекты. • Для увеличения вероятности достижения целей по качеству ПО наиболее общими подходами к планированию качества проекта является: – определение того, какие виды деятельности по УК должны выполняться; – задание методических рекомендаций по выполнению каждой задачи УК. • В ходе выполнения проекта эти виды деятельности выполняются в соответствии с определенными процедурами. Задачи решаемые в ходе планирования проекта 1. Оценка трудоемкости проекта. 2. Планирование сроков выполнения проекта и состава исполнителей. 3. Управление качеством. 4. Управление рисками выполнения проекта. 5. Планирование мониторинга выполнения проекта. Планирование управления рисками • Программный проект является сложным мероприятием, которое требует – создание ПО высокого качества – в заданные сроки и – за заданные деньги (бюджет). • На выполнение программного проекта отрицательное влияние могут оказать не предвиденные события. • Управление рисками это попытка минимизировать вероятность неудачи, вызванной не запланированными событиями. • Управление рисками это не отказ от проекта, который имеет риски, а работа по предвидению, выявлению и минимизации рисков в выполняемом проекте. Основные понятия управления рисками • Риск это возможность подвергнуться повреждению или поражению. • Т.е., риск предполагает, что существует возможность, что может случиться что-то нежелательное (негативное). • Управление рисками это вид деятельности, которая гарантирует, что влияние рисков на стоимость, качество и сроки выполнения проекта будет минимальным. • Управление рисками начинается тогда, когда заканчивается нормальный ход управления проектом Пример управления рисками • При путешествии есть риски: – потерять документы, – кража денег, – физическое повреждение, – болезнь …. • Нужно подумать, как этого избежать: – где надежнее хранить документы и деньги, – как ими безопасно пользоваться, – во что одеваться, – как себя вести и т.п. Работы по управлению рисками • Управление рисками включает следующие работы: 1. Оценка возможных рисков: 1. определение возможных нежелательных событий, которые могут возникнуть; 2. оценка вероятности их появления; 3. оценка потерь при появлении событий. 2. Определение стратегии по уменьшению вероятности возникновения рисков или уменьшения потерь от возникших рисков. Основные риски и методы управления ими № Вид риска Метод управления риском 1 Недостаток сотрудников Поиск талантливых сотрудников; соответствие способностей сотрудника его работе; создание команд; обучение; и т.п. 2 Не реальные сроки и финансы (бюджет) Детальное оценивание затрат графика работ; проектирование согласно заданной стоимости; итеративная разработка; повторное использование компонент; уточнение требований. 3 Разработка не верных функций ПО Анализ организации; обследование пользователей; прототипирование; подготовка инструкций пользователей заранее. 4 Разработка не верного интерфейса пользователей Прототипирование; сценарии; анализ задач; определение характеристик пользователей. 5 Не нужные украшательства Уточнение требований; прототипирование; анализ стоимости и эффективности; проектирование согласно заданной стоимости План управления рисками проекта № Риск Вероят ность Влиян ие Exp. План уменьшения влияния 1 Невозможность достичь высокой производительнос ти высока я высок ая высок ая Study white papers and guidelines on perf. Train team on perf. tuning. Update review checklist to look for perf. Pitfalls. Test application for perf. during system testing. 2 Отсутствие людей с требуемой квалификацией Средня Средн я яя Средн яя Train resources. Review prototype with Customer. Develop coding practices. 3 Сложность приложения Средня Средн я яя Средн яя Ensure ongoing knowledge transfer. Deploy persons with prior experience with the domain. 4 Трение между сотрудниками Средня Средн я яя Средн яя Train a core group of four people. Rotate assignments among people. Identify backups for key roles. 5 Не ясность требований Средня Средн я яя Средн яя Review a prototype. Conduct a midstage review. • Упорядочение рисков по приоритетности и их последующее планирование основывается на понимании рисков во время выполнения анализа рисков. Пример практического подхода к планированию управления рисками • В данном подходе: • Оценивание рисков и воздействий: – Вероятность рисков оценивается по категориям: малая, средняя, высокая. – Воздействие риска также оценивается по категориям: низкое, среднее, сильное. • Упорядочение рисков по их вероятности и воздействию: – Например, высоко-вероятные риски с сильным воздействием будут иметь более высокий рейтинг, чем риск со средней вероятностью и сильным воздействием.. – В случае конфликтной ситуации используется экспертная оценка.. • Выбор нескольких высоко-рейтинговых рисков для уменьшения последствий и отслеживания. Показатели рисков Тип риска Возможные индикаторы Технологический Поздняя доставка техн. или прогр. обеспечения; много сообщений о технических проблемах. Люди Плохое моральное состояние сотрудников; плохие отношения между членами команды разработчиков; большая смена текучесть кадров. Организационный Организационные слухи; недостаток действий руководства организации. Инструментальный Нежелание членов команды использовать инструменты; жалобы на CASE инструменты; требования более мощных рабочих компьютеров. Требования Много отчетов о изменении требований; жалобы пользователей. Оценки Сложность составить согласованное расписание; трудность ясно определить дефекты. Задачи решаемые в ходе планирования проекта 1. Оценка трудоемкости проекта. 2. Планирование сроков выполнения проекта и состава исполнителей. 3. Управление качеством. 4. Управление рисками выполнения проекта. 5. Планирование мониторинга выполнения проекта. План мониторинга проекта • План управления проектом это просто документ, который может быть использован для отслеживания хода выполнения проектом. • Любой хороший план является бесполезным, если его не соблюдать требуемым образом. • Выполнение проекта не может быть правильно направляться планом, если оно тщательно не отслеживается (не выполняется мониторинг) и реальные результаты не сравниваются с данным планом. • Если измерение некоторых показателей должно производиться в ходе выполнения проекта, то требуется тщательно спланировать: – какие показатели будут использоваться; – когда выполнять измерение показателей; – как определять значения показателей. • Сл-но планирование выполнения измерений является ключевым элементом в планировании проекта. • Кроме этого нужно заранее спланировать, как будет выполняться анализ и описание результатов (данных) измерений, чтобы избежать ситуацию, когда данные собираются, но не понятно, что с ними делать. • Результата от планирования проекта не будет без тщательного планирования сбора данных и их анализа. Измеряемые показатели • Основной целью измерений в проекте является предоставление данных о текущем состоянии проекта сотрудникам выполняющим управление данным проектом. • Это требуется для того, чтобы они могли эффективно отслеживать и управлять проектом и гарантировать достижения поставленных целей. • Т.к. цели проекта задаются в терминах предоставляемого ПО, затрат, сроков, качества, то для мониторинга состояния проекта базовыми измеряемыми показателями являются: размер ПО, трудозатраты, сроки и дефекты.
