Управление проектами разработки ПО

Август 10, 2022

Главная
Разное
Управление проектами разработки ПО

Содержание

2. Основные этапы разработки ПО Анализ и описание требований к ПО Планирование выполнения проекта разработки ПО Разработка
3. Проектом называется совокупность распределенных во времени мероприятий или работ, направленных на достижение поставленной цели. Отличия процесса
4. Свойства Проекта: Проект всегда имеет четко определенные Цель, начало и конец исполняется командой использует материальные ресурсы
5. Цель выражается в получении некоторого результата. Достижение этого результата означает успешное завершение и окончание проекта Начало
6. Управление проектом Управление проектом (Project Management - PM) – это наука и искусство руководства и координации
7. Ключевой категорией, участвующей в процессе управления проектами, являются ограничения. Известный закон Лермана гласит: "Любую техническую проблему
8. Работы по управлению проектом Управление проектом включает следующие виды работ: планирование проекта; мониторинг хода выполнения проекта;
9. Планирование выполнения проекта разработки ПО Планирование работ это наиболее важная часть работ по управлению проектом. Основные
10. Без детального планирования невозможно отслеживать и оперативно управлять ходом выполнения проекта. Никакое количество технических усилий, приложенных
11. Входные данные планирования Входными данными для планирования проекта разработки ПО являются: спецификация требований к ПО (СТПО);
12. Процесс планирования проекта Выявление требований Выявление рисков Контроль-ные точки и результаты Определение календарного плана > Планировщик
13. Задачи решаемые в ходе планирования проекта Оценка трудоемкости проекта. Планирование сроков выполнения проекта и состава исполнителей.
14. Оценка трудоемкости Для планирования проекта разработки ПО важным обязательным условием является общая оценка трудоемкости (объема работ)
15. Т.к. основными затратами на выполнение проекта являются усилия разработчиков ПО (и сл-но их зарплата), то стоимость
16. Подходы к оценке трудоемкости Нисходящий подход к оценке трудоемкости оценка основывается на размере проекта; трудоемкость рассчитывается,
17. Нисходящий подход. Формула оценка трудоемкости проекта разработки ПО определение трудоемкости на основе размера проекта: Т =
18. Источники затрат проекта Для оценки влияния других факторов используется до 15 разных показателей проекта, называемых -
19. Таблица коэффициентов трудоемкости для разных источников затрат
20. Восходящий подход Вначале определяются основные единицы ПО (компоненты или модули), которые должны быть разработаны в проекте.
21. Поэтапное описание метода Выявление в системе модулей и классификация их на простые, средние и сложные. Определение
22. Управление командой проекта Состав команды определяется опытом и уровнем коллектива, особенностями проекта, применяемыми технологиями и уровнем
23. Проектировщик - это функция проектирования архитектуры высокого уровня и контроля ее выполнения. В небольших командах функция
24. Разработчик – роль, ответственная за непосредственное создание конечного продукта. Помимо собственно программирования (кодирования) в его функции
25. · Тестировщик – роль, ответственная за удовлетворение требований к продукту (функциональных и нефункциональных). В функции тестировщика
26. Инженер по качеству. o Составление плана качества. План качества включает все мероприятия по повышению качества (на
27. Технический писатель или разработчик пользовательской (и иной) документации как части программного продукта. Функциями технического писателя являются:
28. Модели управления командой Административная модель (теория X) Властная пирамида – решения принимаются сверху-вниз. Четкое распределение ролей
29. Управление проектом состоит из: структурного и календарного планирования и оперативного управления Структурное планирование заключается в разбиении
30. Схема составления диаграммы календарного плана работ Выявление работ Спецификация требований к ПО Выявление зависимостей работ Оценка
31. Управление ресурсами При разработке графика проекта нужно выполнить следующие действия: Уточнить имеющуюся структуру работ проекта для
32. Пример сетевой диаграммы проекта
33. PERT-диаграмма (PERT — program evaluation and review technique, техника оценки и обзора программ). Часто различий между
34. Сетевые и PERT-диаграммы используются для планирования продолжительности проекта и выделения критических путей — последовательностей работ от
35. Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Эта диаграмма показывает и связи между
36. На следующем шаге (после вынесения предварительной оценки трудоемкости и продолжительности работ) нужно привязать их к имеющемуся
37. Промежуточные результаты Специальным видом КТ является создание промежуточного результата (ПР, deliverable) – некоторого продукта, который передается
38. Контрольные отметки Анализ осуществимости Анализ требований Разработка прототипа Проектная проработка Специфицирование требований Отчет Пользовательские требования Проект
39. Планирование управления рисками Программный проект является сложным мероприятием, которое требует создание ПО высокого качества в заданные
40. Основные понятия управления рисками Риск это возможность подвергнуться повреждению или поражению. Т.е., риск предполагает, что существует
41. Управление рисками Схема процесса управления рисками Определение рисков. Определяются возможные риски для проекта, для разрабатываемого продукта
42. Основные риски и методы управления ими
43. Анализ рисков Существует три категории стратегий управления рисками: Стратегии предотвращения рисков. Согласно этим стратегиям следует проводить
44. Показатели рисков
46. Скачать презентацию

Слайд 2

Основные этапы разработки ПО
Анализ и описание требований к ПО
Планирование выполнения проекта

разработки ПО
Разработка архитектуры ПО (общей структуры).
Укрупненное проектирование ПО.
Детальное проектирование ПО.
Кодирование и тестирование единиц кода.
Системное тестирование.
Внедрение разработанного ПО у заказчика.

Слайд 3

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

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

Слайд 4

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

ресурсы
имеет бюджет
имеет ограничения трех видов:
Ограничения по бюджету
Ограничения по времени
Ограничения по ресурсам

Слайд 5

Цель выражается в получении некоторого результата. Достижение этого результата означает успешное

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

Слайд 6

Управление проектом
Управление проектом (Project Management - PM) – это наука и

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

Слайд 7

Ключевой категорией, участвующей в процессе управления проектами, являются
ограничения. Известный закон Лермана

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

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

Слайд 8

Работы по управлению проектом
Управление проектом включает следующие виды работ:
планирование проекта;
мониторинг хода

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

Слайд 9

Планирование выполнения проекта разработки ПО
Планирование работ это наиболее важная часть работ

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

Слайд 10

Без детального планирования невозможно отслеживать и оперативно управлять ходом выполнения проекта.
Никакое

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

Слайд 11

Входные данные планирования
Входными данными для планирования проекта разработки ПО являются:
спецификация требований

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

Слайд 12

Процесс планирования проекта
Выявление требований
Выявление рисков
Контроль-ные точки и результаты
Определение
календарного плана
<>
Планировщик проекта
Выполнение работы
Отслеживание

хода работы по плану

Начало работ по уменьшению рисков

Перепланировка проекта

[нет проблем]

[не большие проблем]

[серьезные проблемы]

[не закончено]

[проект завершен]

Слайд 13

Задачи решаемые в ходе планирования проекта
Оценка трудоемкости проекта.
Планирование сроков выполнения проекта

и состава исполнителей.
Управление качеством.
Управление рисками.
Планирование мониторинга выполнения проекта.

Слайд 14

Оценка трудоемкости
Для планирования проекта разработки ПО важным обязательным условием является
общая

оценка трудоемкости (объема работ) и
общая оценка сроков выполнения работ.
Такие оценки требуются до того, как процесс разработки будет запущен, т.к. они определяют цели проекта по стоимости и по срокам.
Без таких оценок нельзя ответить на такие вопросы, как:
«опаздывает ли выполнение проекта?»
«превышены ли затраты на выполнение проекта?».
Более практическим использованием таких оценок является обсуждение с заказчиком (торг) цены подписания контракта на выполнение проекта.

Слайд 15

Т.к. основными затратами на выполнение проекта являются усилия разработчиков ПО (и

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

Слайд 16

Подходы к оценке трудоемкости
Нисходящий подход к оценке трудоемкости
оценка основывается на размере

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

Слайд 17

Нисходящий подход. Формула оценка трудоемкости проекта разработки ПО
определение трудоемкости на основе

размера проекта:
Т = a * SIZEb,
где
Т – трудоемкость в чел-месяцах;
а и b - константы,
SIZE - размер проекта (обычно в KLOC). KLOC = тысячи передаваемых строк кода (SIZE)
Значения используемых констант а и b для конкретной организации определяется с помощью регрессионного статистического анализа, который применяется к данным проектов, которые выполнялись ранее.

Слайд 18

Источники затрат проекта
Для оценки влияния других факторов используется до 15 разных

показателей проекта, называемых - источниками затрат.
Примерами источников затрат являются:
требование надежности ПО;
сложность ПО;
способности аналитиков;
использование современных инструментов разработки;
жесткость сроков разработки.
Каждый источник затрат имеет качественную оценочную шкалу (высокий, низкий, нормальный) и для каждой оценки задается коэффициент влияния.
Этот коэффициент влияния умножается на оценку трудоемкости:
Т’ = Т * k1*k2*k3*…*kn

Слайд 19

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

Слайд 20

Восходящий подход
Вначале определяются основные единицы ПО (компоненты или модули), которые должны

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

Слайд 21

Поэтапное описание метода
Выявление в системе модулей и классификация их на простые,

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

Слайд 22

Управление командой проекта
Состав команды определяется опытом и уровнем коллектива, особенностями проекта,

применяемыми технологиями и уровнем этих технологий. «Классический» вариант состава команды включает следующие позиции
Менеджер проекта - главное действующее лицо, обладающее знаниями и навыками, необходимыми для успешного управления проектом. Его основные функции:
o Подбор и управление кадрами
o Подготовка и исполнение плана проекта
o Руководство командой
o Обеспечение связи между подразделениями
o Обеспечение готовности продукта

Слайд 23

Проектировщик - это функция проектирования архитектуры высокого уровня и контроля ее

выполнения. В небольших командах функция распределяется между менеджером и разработчиками. В больших проектах это может быть целый отдел. Основными функциями проектирования являются:
o Анализ требований
o Разработка архитектуры и основных интерфейсов
o Участие в планировании проекта
o Контроль выполнения проекта
o Участие в подборе кадров

Слайд 24

Разработчик – роль, ответственная за непосредственное создание конечного продукта. Помимо собственно

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

Слайд 25

· Тестировщик – роль, ответственная за удовлетворение требований к продукту
(функциональных и

нефункциональных). В функции тестировщика входит:
o Составление плана тестирования. План тестирования составляет один из элементов проекта и составляется до начала реализации (разработки)
проекта. Время, отводимое в плане на тестирование может быть сопоставимо с временем разработки.
o Контроль выполнения плана. Важнейшая функция контроля – поддержка целостности базы данных зарегистрированных ошибок. В этой базе регистрируется: кто, когда и где обнаружил, описание ошибки, описание состояния среды; статус ошибки: приоритет, кто разрешает; состояние ошибки: висит, в разработке, разрешена, проблемы
o Разработка тестов. Самая трудоемкая часть в работе тестировщика. Тестирование должно обеспечить полную проверку функциональности при всех режимах работы продукта.
o Автоматизация тестирования включает автоматизацию составления тестов, автоматизацию пропуска тестов и автоматизацию обработки результатов тестирования. В виду важности автоматизации тестирования, иногда вводят нового участника – инженера по автоматизации.
o Выбор инструментов, метрик, стандартов для организации процесса тестирования.
o Организация Бета тестирования - тестирования почти готового продукта внешними тестерами (пользователями).

Слайд 26

Инженер по качеству.
o Составление плана качества. План качества включает все

мероприятия по повышению качества (на всех уровнях). Имеет долговременный характер. План тестирования – его оперативная составляющая.
o Описание процессов. Описание процессов является их формализацией. При описании вводятся метрики процесса, влияющие на качество продукта.
o Оценка процессов включает регистрацию хода выполнения процессов и оценку значений установленных метрик процессов. Выявление «слабых» мест и выработка рекомендаций по улучшению процессов.
o Улучшение процессов - переопределение процесса, автоматизация части работ, обучение персонала.
Повышение качества процессов требует участия всех действующих лиц.

Слайд 27

Технический писатель или разработчик пользовательской (и иной)
документации как части программного продукта.

Функциями технического писателя являются:
o Разработка плана документирования, который включает состав, сроки подготовки и порядок тестирования документов.
o Выбор и разработка стандартов и шаблонов подготовки документов
o Выбор средств автоматизации документирования
o Разработка документации
o Организация тестирования документации
o Участие в тестировании продукта
Технолог разработки ПО обеспечивает выполнение следующих задач:
o Поддержка модели ЖЦ - создание служб и структур по поддержке работоспособности принятой модели ЖЦ ПО.
o Создание и сопровождение среды сборки продукта. Функция особенно важна на завершающих этапах разработки или при использовании модели прототипирования. В такой ситуации сборка будет проводиться достаточно часто (в некоторых случаях - ежедневно). Среда сборки должна быть подготовлена заранее, сборка должна проводиться быстро и без сбоев. С учетом сборки версий это не простая задача.
o Создание и сопровождение процедуры установки с тем, чтобы каждая сборка устанавливалась автоматически с учетом версии и конфигураций сред.
o Управление исходными текстами - сопровождение и администрирование системы управления версиями исходных текстов.

Слайд 28

Модели управления командой
Административная модель (теория X)
Властная пирамида – решения принимаются сверху-вниз.
Четкое

распределение ролей и обязанностей.
Четкое распределение ответственности.
Следование инструкциям, процедурам, технологиям.
Роль менеджера: планирование, контроль, принятие основных решений
Модель хаоса (теория Y)
Отсутствие явно выраженных признаков власти.
Роль менеджера – поставить задачу, обеспечить ресурсами, не мешать и следить, чтобы не мешали другие.
Отсутствие инструкций и регламентированных процедур.
Индивидуальная инициатива - решения по проблеме принимается там, где проблема обнаружена.
Процесс напоминает творческую игру участников на основе дружеской соревновательности.
Открытая архитектура (теория Z)
Адаптация к условиям работы
Коллективное обсуждение проблем, выработка консенсуса и принятие решения – не все могут согласится, но принятое решение является коллективным и в силу этого – обязательным для всех.
Распределенная ответственность – отвечают все, кто обсуждал, вырабатывал, принимал.
Динамика состава рабочих групп в зависимости от текущих задач.
Отсутствие специализации – участники меняются ролями и функциями и могут при необходимости заменить друг друга.
Задача менеджера – активное (но рядовое, не руководящее) участие в процессе, контроль конструктивности обсуждений, обеспечение возможности активного участия всех.

Слайд 29

Управление проектом состоит из:
структурного и
календарного планирования и
оперативного управления
Структурное планирование

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

Слайд 30

Схема составления диаграммы календарного плана работ
Выявление работ
Спецификация требований к ПО
Выявление зависимостей
работ
Оценка

ресурсов для работ

Выделение сотрудников для работ

Составление графиков
работ

Диаграммы календарного плана работ

Слайд 31

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

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

Слайд 32

Пример сетевой диаграммы проекта

Слайд 33

PERT-диаграмма (PERT — program evaluation and review technique, техника оценки и обзора программ). Часто

различий между этими двумя видами диаграмм не делают, называя обе и сетевыми, и PERT-диаграммами.

Слайд 34

Сетевые и PERT-диаграммы используются для планирования продолжительности проекта и выделения критических путей — последовательностей работ от

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

Слайд 35

Расписание работ удобно изображать с помощью диаграмм Ганта (Gantt chart). Эта диаграмма показывает

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

Слайд 36

На следующем шаге (после вынесения предварительной оценки трудоемкости и продолжительности работ)

нужно привязать их к имеющемуся в проекте персоналу и другим ресурсам (оборудованию, материалам и пр.). При этом может оказаться, что некоторые независимые работы не могут проводиться одновременно, поскольку для этого не хватает ресурсов.
Допустим, что первичное планирование и разработка маркетинговых документов требуют полной вовлеченности менеджера проекта. При этом вторая работа может быть начата только после окончания первой. В разработке пользовательского интерфейса могут быть задействованы аналитик, проектировщик интерфейсов и программист. При ограниченности команды проекта это потребует увеличить время на выполнение работы по реализации. Итоговая картина после перепланирования рассматриваемого проекта для команды из менеджера, аналитика-тестировщика, архитектора, трех программистов, один из которых также является проектировщиком пользовательского интерфейса, и еще одного тестировщика, способного писать техническую документацию, Она отличается от предыдущей изменениями, удлиннившими проект на 0.5 месяца.
Естественно, после учета доступных ресурсов критические пути проекта могут измениться.
Кроме того, риски, связанные с непредвиденными ситуациями, неаккуратной оценкой возможностей персонала или технологий и пр., требуют наличия определенных временных и ресурсных резервов при планировании проектов.
В ходе самого проекта необходимо тщательно следить за выполнением запланированных работ в срок, за доступностью ресурсов, отслеживать проблемы, способные привести к срыву графика, а также неучтенные при первоначальном планировании факторы. Реальные длительности и трудоемкости работ могут отличаться от оценочных, что потребует построения новых, уточненных планов проекта. Грамотная отработка изменений в планах и расписаниях — ничуть не менее важная задача, чем их первоначальное составление. В частности, чем быстрее менеджер проекта проинформирует о возможных или необходимых изменениях заказчика, спонсора и других лиц, тем более он может рассчитывать на их понимание и помощь в решении проблем проекта.

Слайд 37

Промежуточные результаты
Специальным видом КТ является создание промежуточного результата (ПР, deliverable) –

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

Слайд 38

Контрольные отметки
Анализ
осуществимости
Анализ
требований
Разработка
прототипа
Проектная
проработка
Специфицирование
требований
Отчет
Пользовательские
требования
Проект
архитектуры
Системные
требования
Отчет
этапы
Контрольные метки
Контрольные отметки— вехи, отмечающие окончание

определенного этапа работ.

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

Слайд 39

Планирование управления рисками
Программный проект является сложным мероприятием, которое требует
создание ПО

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

Слайд 40

Основные понятия управления рисками
Риск это возможность подвергнуться повреждению или поражению.
Т.е., риск

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

Слайд 41

Управление рисками
Схема процесса управления рисками
Определение рисков. Определяются возможные риски для

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

Определение
рисков

Анализ
рисков

Планирование
рисков

Мониторинг
рисков

Список потенциальных рисков

Список первостепенных рисков

Мероприятия по предотвращению рисков
Оценки рисков

Слайд 42

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

Слайд 43

Анализ рисков
Существует три категории стратегий управления рисками:
Стратегии предотвращения рисков. Согласно этим

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

Слайд 44

Управление проектами разработки ПО

Содержание

Основные этапы разработки ПОАнализ и описание требований к ПОПланирование выполнения проекта

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

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

Цель выражается в получении некоторого результата. Достижение этого результата означает успешное

Управление проектомУправление проектом (Project Management - PM) – это наука и

Ключевой категорией, участвующей в процессе управления проектами, являютсяограничения. Известный закон Лермана

Работы по управлению проектомУправление проектом включает следующие виды работ:планирование проекта;мониторинг хода

Планирование выполнения проекта разработки ПОПланирование работ это наиболее важная часть работ

Без детального планирования невозможно отслеживать и оперативно управлять ходом выполнения проекта.Никакое

Входные данные планированияВходными данными для планирования проекта разработки ПО являются:спецификация требований

Задачи решаемые в ходе планирования проектаОценка трудоемкости проекта.Планирование сроков выполнения проекта

Оценка трудоемкостиДля планирования проекта разработки ПО важным обязательным условием является общая

Т.к. основными затратами на выполнение проекта являются усилия разработчиков ПО (и

Подходы к оценке трудоемкостиНисходящий подход к оценке трудоемкостиоценка основывается на размере

Нисходящий подход. Формула оценка трудоемкости проекта разработки ПОопределение трудоемкости на основе

Источники затрат проектаДля оценки влияния других факторов используется до 15 разных

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

Восходящий подходВначале определяются основные единицы ПО (компоненты или модули), которые должны

Поэтапное описание методаВыявление в системе модулей и классификация их на простые,

Управление командой проектаСостав команды определяется опытом и уровнем коллектива, особенностями проекта,