Руководство проектом. (Лекция 2)

Июль 24, 2022

Главная
Информатика
Руководство проектом. (Лекция 2)

Содержание

2. «Если водитель трамвая начнет искать новые пути, жди беды» Классическое управление проектами выделяет два вида организации
3. Проект – основа инноваций Условия применимости проектной деятельности: разрабатывается новый продукт, внешние условия и требования к
4. Проект – основа инноваций Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или
5. Проект – средство стратегического развития * Руководство проектом
6. Проект – средство стратегического развития Цель – описание того, что мы хотим достичь Стратегия – констатация
7. Критерии успешности проекта Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений «железного треугольника»: ни один
8. Критерии успешности проекта Проект считается успешным, если: выполнен в соответствие со спецификациями, выполнен в срок, выполнен
9. Организация проектной команды Каждый проект разработки ПО имеет свою организационную структуру, которая определяет распределение ответственности и
10. Роли и ответственности Роли и ответственности участников типового проекта разработки ПО можно условно разделить на пять
11. Группа анализа Включает в себя следующие роли: Бизнес-аналитик. Построение модели предметной области (онтологии). Бизнес-архитектор. Определяет общее
12. Группа управления Состоит из следующих ролей: Руководитель проекта. Отвечает за достижение целей проекта при заданных ограничениях.
13. Производственная группа В ее состав входят: Проектировщик. Проектирование компонентов и подсистем в соответствие с общей архитектурой,
14. Группа тестирования Состоит из следующих ролей: Проектировщик тестов. Разработка тестовых сценариев. Разработчик автоматизированных тестов. Тестировщик. Тестирование
15. Группа обеспечения Участники этой группы, как правило, не входят в команду проекта. Они выполняют работы в
16. Временное распределение ресурсов В операционной деятельности ресурсы расходуются равномерно по времени В проектном управлении расходование ресурсов
17. Начало проекта В компании, которая принимает решение о старте того или иного проекта разработки ПО, должна
18. Шкала оценки финансовой ценности проекта Может выглядеть следующим образом: Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые
19. Шкала оценки финансовой ценности проекта Средняя. Проект позволяет улучшить эффективность производства в компании и потенциально может
20. Шкала оценки стратегической ценности Может иметь следующий вид: Высокая. Обеспечивает стратегическое преимущество, дает устойчивое увеличение рынка
21. Шкала оценки стратегической ценности Средняя. Поддерживается доверие рынка к компании. Повышает мнение клиентов о качестве предоставляемых
22. Шкала оценки уровня рисков проекта Может иметь следующий вид: Низкий. Цели проекта и требования хорошо поняты
23. Шкала оценки уровня рисков проекта Выше среднего. Цели проекта недостаточно четки. Задачи системы или бизнес-приложения поняты
24. * Руководство проектом Начало проекта В начале работы над проектом необходимо: установить цели и проблемную область
25. * Руководство проектом Процесс оценки Оценка объема предстоящих работ производится в человеко-месяцах Исходя из нее определяют
26. * Руководство проектом Анализ рисков Риском называется возможная потеря в процессе разработки. Это может быть потеря
27. * Руководство проектом Пример проверочного списка элементов риска
28. * Руководство проектом Ранжирование рисков Ранжирование заключается в назначении каждому риску приоритета в соответствии со степенью
29. * Руководство проектом Планирование процесса разработки Основная задача планирования – декомпозиция проекта и представление его в
30. Планирование процесса разработки Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) – это ориентированная на результат
31. Выделение компонентов Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на
32. Базовое расписание проекта Базовое расписание — утвержденный план-график с указанными временными фазами проекта, контрольными точками и
33. Диаграмма Ганта * Руководство проектом
34. * Руководство проектом Границы времени выполнения Распараллеливание задач требует согласования процессов их выполнения во времени. Для
35. * Руководство проектом Распределение времени выполнения Рекомендуемое распределение времени выполнения проекта: на анализ и проектирование 40%
36. * Руководство проектом Выбор модели разработки Реальный процесс разработки никогда жестко не увязывается с какой-либо одной
37. Оценка объема и сложности проекта Первое, что необходимо понимать при оценке проекта – это то, что
38. Оценка объема и сложности проекта Вероятностный характер оценки, означает, что для нее существует некоторое распределение вероятности,
39. * Руководство проектом Оценки на основе метрик Для оценки различных свойств процесса создания программного продукта, а
40. Оценки на основе метрик Метрики используются для получения предварительной, текущей и итоговой оценок: экономических параметров проекта
41. Классификация метрик Метрики сложности программ принято разделять на три основные группы: метрики размера программ; метрики сложности
42. Метрики размера программ Метрики этой группы базируются на определении количественных характеристик, связанных с размером программы, и
43. Метрики потока управления Метрики сложности потока управления базируются на анализе управляющего графа программы Управляющий граф программы,
44. Метрики потока данных Метрики третьей группы базируются на оценке использования, конфигурации и размещения данных в программе
45. * Руководство проектом Размерно-ориентированные метрики Основаны на LOC-оценках, т.е. на количестве строк в текстах программ (Lines
46. * Руководство проектом Метрики производительности и качества Длина [тыс. LOC] Производительность = Затраты [чел.-мес.] Ошибки [Единиц]
47. * Руководство проектом Метрики стоимости и документированности Стоимость [Тыс. руб.] Удельная Стоимость = Длина [LOC] Страниц
48. * Руководство проектом Достоинства и недостатки Размерно-ориентированные метрики: основаны на объективных данных просты и легко вычислимы
49. Метрики сложности кода Помимо показателей оценки объема работ по проекту очень важными для получения объективных оценок
50. Метрики Холстеда При вычислении этих метрик используются следующие опорные значения: nu1 – число уникальных операторов программы,
51. Метрики Холстеда На основании этих опорных значений рассчитываются следующие метрики программы: словарь NU = nu1 +
52. Метрика Мак-Кейба Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки сложности программных проектов (Мак-Кейб,
53. Метрика Мак-Кейба Упрощенная формула вычисления цикломатической сложности представляется следующим образом: C = e - n +
54. Достоинства и недостатки метрики Достоинства метрики Мак-Кейба: простоту вычисления и повторяемость результата, наглядность и содержательность интерпретации
55. Метрика Чепина Суть метода состоит в оценке информационной прочности отдельно взятого программного модуля с помощью анализа
56. Функциональные группы Множество Р - вводимые переменные для расчетов и для обеспечения вывода (переменные, содержащие исходную
57. Формула метрики Чепина Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо учитывать ее в каждой
58. Весовые коэффициенты По мнению автора метрики наибольший вес, равный трем, имеет функциональная группа С, так как
59. Формула Чепина С учетом весовых коэффициентов выражение для метрики Чепина примет вид: Q = P +
61. Скачать презентацию

Слайд 2

«Если водитель трамвая начнет искать новые пути, жди беды»
Классическое управление проектами

выделяет два вида организации человеческой деятельности: операционная и проектная
Операционная деятельность представляет собой продолжающийся во времени и повторяющийся процесс
Задача операционной деятельности – обеспечение нормального течения бизнеса
В этом случае основой эффективности служат узкая специализация и повышение компетенции

Руководство проектом

Слайд 3

Проект – основа инноваций
Условия применимости проектной деятельности:
разрабатывается новый продукт,
внешние условия

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

Руководство проектом

Слайд 4

Проект – основа инноваций
Проект – это временное предприятие, предназначенное для создания

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

Руководство проектом

Слайд 5

Проект – средство стратегического развития
*
Руководство проектом

Слайд 6

Проект – средство стратегического развития
Цель – описание того, что мы

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

Руководство проектом

Слайд 7

Критерии успешности проекта
Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений

«железного треугольника»: ни один из углов треугольника не может быть изменен без оказания влияния на другие

Руководство проектом

Слайд 8

Критерии успешности проекта
Проект считается успешным, если:
выполнен в соответствие со спецификациями,

выполнен в срок,
выполнен в пределах бюджета,
каждый участник команды уходил с работы в 18:00 с чувством успеха
Нет ничего более гибельного для проекта, чем равнодушие или уныние его участников

Руководство проектом

Слайд 9

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

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

Руководство проектом

Слайд 10

Роли и ответственности
Роли и ответственности участников типового проекта разработки ПО можно

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

Руководство проектом

Слайд 11

Группа анализа
Включает в себя следующие роли:
Бизнес-аналитик. Построение модели предметной

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

Руководство проектом

Слайд 12

Группа управления
Состоит из следующих ролей:
Руководитель проекта. Отвечает за достижение

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

Руководство проектом

Слайд 13

Производственная группа
В ее состав входят:
Проектировщик. Проектирование компонентов и подсистем

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

Руководство проектом

Слайд 14

Группа тестирования
Состоит из следующих ролей:
Проектировщик тестов. Разработка тестовых сценариев.

Разработчик автоматизированных тестов.
Тестировщик. Тестирование продукта. Анализ и документирование результатов

Руководство проектом

Слайд 15

Группа обеспечения
Участники этой группы, как правило, не входят в команду проекта.

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

Руководство проектом

Слайд 16

Временное распределение ресурсов
В операционной деятельности ресурсы расходуются равномерно по времени
В проектном

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

Руководство проектом

Слайд 17

Начало проекта
В компании, которая принимает решение о старте того или иного

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

Руководство проектом

Слайд 18

Шкала оценки финансовой ценности проекта
Может выглядеть следующим образом:
Высокая. Ожидаемая

окупаемость до 1 года. Ожидаемые доходы от проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении этих оценок четко обоснованы.
Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3 лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы. Большинство допущений при проведении этих оценок имеют под собой определенные основания.

Руководство проектом

Слайд 19

Шкала оценки финансовой ценности проекта
Средняя. Проект позволяет улучшить эффективность производства

в компании и потенциально может снизить расходы компании не менее чем на 30%. Проект может иметь информационную ценность или помочь лучше контролировать бизнес.
Низкая. Проект снижает расходы компании не менее чем на 10% и дает некоторые улучшения производительности производства

Руководство проектом

Слайд 20

Шкала оценки стратегической ценности
Может иметь следующий вид:
Высокая. Обеспечивает стратегическое

преимущество, дает устойчивое увеличение рынка или позволяет выйти на новый рынок. Решает значительные проблемы, общие для большинства важных клиентов. Повторение конкурентами затруднено или потребует от 1 до 2 лет.
Выше среднего. Создает временные конкурентные преимущества. Выполнение обязательств перед многими важными клиентами. Конкурентное преимущество может быть удержано в течение 1 года.

Руководство проектом

Слайд 21

Шкала оценки стратегической ценности
Средняя. Поддерживается доверие рынка к компании. Повышает

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

Руководство проектом

Слайд 22

Шкала оценки уровня рисков проекта
Может иметь следующий вид:
Низкий. Цели

проекта и требования хорошо поняты и документированы. Масштаб и рамки проекта заданы четко. Ресурсы требуемой квалификации доступны в полном объеме. Разрабатываемые системы не потребуют новой технологической платформы.
Средний. Цели проекта определены более-менее четко. Хорошее понимание требований к системе. Масштаб и рамки проекта заданы достаточно хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются на новой, но стабильной технологической платформе.

Руководство проектом

Слайд 23

Шкала оценки уровня рисков проекта
Выше среднего. Цели проекта недостаточно четки.

Задачи системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены. Системы создаются на новой технологической платформе.
Высокий. Цели проекта нечетки. Основные функциональные компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы требуемой квалификации практически отсутствуют. Системы создаются на новой технологической платформе. Технологии имеют неподтвержденную стабильность.

Руководство проектом

Слайд 24

*
Руководство проектом
Начало проекта
В начале работы над проектом необходимо:
установить цели и проблемную

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

Слайд 25

*
Руководство проектом
Процесс оценки
Оценка объема предстоящих работ производится в человеко-месяцах
Исходя из нее

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

Слайд 26

*
Руководство проектом
Анализ рисков
Риском называется возможная потеря в процессе разработки. Это может

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

Слайд 27

*
Руководство проектом
Пример проверочного списка элементов риска

Слайд 28

*
Руководство проектом
Ранжирование рисков
Ранжирование заключается в назначении каждому риску приоритета в соответствии

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

Слайд 29

*
Руководство проектом
Планирование процесса разработки
Основная задача планирования – декомпозиция проекта и представление

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

Слайд 30

Планирование процесса разработки
Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) –

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

Руководство проектом

Слайд 31

Выделение компонентов
Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое

мы должны выполнить на фазе планирования проекта
Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например, подсистема логгирования, безопасности, библиотека визуальных компонентов GUI

Руководство проектом

Слайд 32

Базовое расписание проекта
Базовое расписание — утвержденный план-график с указанными временными фазами

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

Руководство проектом

Слайд 33

Диаграмма Ганта
*
Руководство проектом

Слайд 34

*
Руководство проектом
Границы времени выполнения
Распараллеливание задач требует согласования процессов их выполнения во

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

Слайд 35

*
Руководство проектом
Распределение времени выполнения
Рекомендуемое распределение времени выполнения проекта:
на анализ и проектирование

40% временных затрат (из них 5% на анализ и планирование)
на кодирование – 20%
на тестирование и отладку – 40%

Слайд 36

*
Руководство проектом
Выбор модели разработки
Реальный процесс разработки никогда жестко не увязывается с

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

Слайд 37

Оценка объема и сложности проекта
Первое, что необходимо понимать при оценке проекта

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

Руководство проектом

Слайд 38

Оценка объема и сложности проекта
Вероятностный характер оценки, означает, что для нее

существует некоторое распределение вероятности, которое может быть очень широким (высокая неопределенность) или достаточно узким (низкая неопределенность)

Руководство проектом

Слайд 39

*
Руководство проектом
Оценки на основе метрик
Для оценки различных свойств процесса создания программного

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

Слайд 40

Оценки на основе метрик
Метрики используются для получения предварительной, текущей и итоговой

оценок:
экономических параметров проекта трудоемкости, длительности, стоимости;
оценка рисков по проекту: риска нарушения сроков и невыполнения проекта, риска увеличения трудоемкости на этапах отладки и сопровождения проекта и пр.
На основе отслеживания метрик проекта можно своевременно предупредить возникновение нежелательных ситуаций и устранить последствия непродуманных проектных решений

Руководство проектом

Слайд 41

Классификация метрик
Метрики сложности программ принято разделять на три основные группы:
метрики размера

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

Руководство проектом

Слайд 42

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

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

Руководство проектом

Слайд 43

Метрики потока управления
Метрики сложности потока управления базируются на анализе управляющего графа

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

Руководство проектом

Слайд 44

Метрики потока данных
Метрики третьей группы базируются на оценке использования, конфигурации и

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

Руководство проектом

Слайд 45

*
Руководство проектом
Размерно-ориентированные метрики
Основаны на LOC-оценках, т.е. на количестве строк в текстах

программ (Lines Of Code). К числу размерно-ориентированных метрик относятся:
производительность
качество
удельная стоимость
документированность

Слайд 46

*
Руководство проектом
Метрики производительности и качества
Длина [тыс. LOC]
Производительность = Затраты [чел.-мес.]
Ошибки [Единиц]
Качество

=
Длина [тыс. LOC]

Слайд 47

*
Руководство проектом
Метрики стоимости и документированности
Стоимость [Тыс. руб.]
Удельная Стоимость =

Длина [LOC]
Страниц Документа
Документированность =
Длина [тыс. LOC]

Слайд 48

*
Руководство проектом
Достоинства и недостатки
Размерно-ориентированные метрики:
основаны на объективных данных
просты и легко вычислимы
Недостатки:
зависят

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

Слайд 49

Метрики сложности кода
Помимо показателей оценки объема работ по проекту очень важными

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

Руководство проектом

Слайд 50

Метрики Холстеда
При вычислении этих метрик используются следующие опорные значения:
nu1 – число

уникальных операторов программы, включая символы-разделители, имена процедур и знаки операций (словарь операторов);
nu2 – число уникальных операндов программы (словарь операндов);
n1 – общее число операторов в программе;
n2 – общее число операндов в программе

Руководство проектом

Слайд 51

Метрики Холстеда
На основании этих опорных значений рассчитываются следующие метрики программы:
словарь NU

= nu1 + nu2
длина N = n1 + n2
объем V = N * Log2 (NU)
сложность D = (nu1 / 2) * (n2 / nu2)
трудоемкость E = D * V

Руководство проектом

Слайд 52

Метрика Мак-Кейба
Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки

сложности программных проектов (Мак-Кейб, 1976 г.)
Этот показатель вычисляется на основе графа управляющей логики программы (control flow graph)
Данный граф строится в виде ориентированного графа, в котором вычислительные операторы или выражения представляются в виде узлов, а передача управления между узлами - в виде дуг

Руководство проектом

Слайд 53

Метрика Мак-Кейба
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e

- n + 2,
где e - число ребер, а n - число узлов на графе управляющей логики.
Практически цикломатическая сложность ПО равна числу предикатов плюс единица, что позволяет вычислять ее без построения управляющего графа простым подсчетом предикатов

Руководство проектом

Слайд 54

Достоинства и недостатки метрики
Достоинства метрики Мак-Кейба:
простоту вычисления и повторяемость результата,
наглядность

и содержательность интерпретации
Недостатки:
нечувствительность к размеру ПО,
нечувствительность к изменению структуры ПО,
отсутствие корреляции со структурированностью ПО,
отсутствие чувствительности к вложенности циклов
Существует значительное число модификаций показателя цикломатической сложности

Руководство проектом

Слайд 55

Метрика Чепина
Суть метода состоит в оценке информационной прочности отдельно взятого программного

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

Руководство проектом

Слайд 56

Функциональные группы
Множество Р - вводимые переменные для расчетов и для обеспечения вывода

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

Руководство проектом

Слайд 57

Формула метрики Чепина
Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо

учитывать ее в каждой соответствующей функциональной группе
Далее вводится значение метрики Чепина:
Q = a1 * P + a2 * M + a3 * C + a4 * T,
где a1, a2, a3, a4 - весовые коэффициенты
Весовые коэффициенты использованы для отражения различного влияния на сложность программы каждой функциональной группы

Руководство проектом

Слайд 58

Весовые коэффициенты
По мнению автора метрики наибольший вес, равный трем, имеет функциональная

группа С, так как она влияет на поток управления программы
Весовые коэффициенты остальных групп распределяются следующим образом: a1=1; a2=2; a4=0.5.
Весовой коэффициент группы T не равен нулю, поскольку "паразитные" переменные не увеличивают сложности потока данных программы, но иногда затрудняют ее понимание

Руководство проектом

Слайд 59

Формула Чепина
С учетом весовых коэффициентов выражение для метрики Чепина примет вид:
Q

= P + 2 * M + 3 * C + 0.5 * T

Руководство проектом

Руководство проектом. (Лекция 2)

Содержание

«Если водитель трамвая начнет искать новые пути, жди беды»Классическое управление проектами

Проект – основа инновацийУсловия применимости проектной деятельности:разрабатывается новый продукт, внешние условия

Проект – основа инновацийПроект – это временное предприятие, предназначенное для создания

Проект – средство стратегического развития *Руководство проектом

Проект – средство стратегического развития Цель – описание того, что мы

Критерии успешности проектаЗадача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений

Критерии успешности проектаПроект считается успешным, если: выполнен в соответствие со спецификациями,

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

Роли и ответственностиРоли и ответственности участников типового проекта разработки ПО можно

Группа анализа Включает в себя следующие роли: Бизнес-аналитик. Построение модели предметной

Группа управления Состоит из следующих ролей: Руководитель проекта. Отвечает за достижение

Производственная группа В ее состав входят: Проектировщик. Проектирование компонентов и подсистем

Группа тестирования Состоит из следующих ролей: Проектировщик тестов. Разработка тестовых сценариев.

Группа обеспеченияУчастники этой группы, как правило, не входят в команду проекта.

Временное распределение ресурсовВ операционной деятельности ресурсы расходуются равномерно по времениВ проектном

Начало проектаВ компании, которая принимает решение о старте того или иного

Шкала оценки финансовой ценности проекта Может выглядеть следующим образом: Высокая. Ожидаемая

Шкала оценки финансовой ценности проекта Средняя. Проект позволяет улучшить эффективность производства

Шкала оценки стратегической ценности Может иметь следующий вид: Высокая. Обеспечивает стратегическое

Шкала оценки стратегической ценности Средняя. Поддерживается доверие рынка к компании. Повышает

Шкала оценки уровня рисков проекта Может иметь следующий вид: Низкий. Цели

Шкала оценки уровня рисков проекта Выше среднего. Цели проекта недостаточно четки.

*Руководство проектомНачало проектаВ начале работы над проектом необходимо:установить цели и проблемную

*Руководство проектомПроцесс оценкиОценка объема предстоящих работ производится в человеко-месяцахИсходя из нее

*Руководство проектомАнализ рисковРиском называется возможная потеря в процессе разработки. Это может

*Руководство проектомПример проверочного списка элементов риска

*Руководство проектомРанжирование рисковРанжирование заключается в назначении каждому риску приоритета в соответствии

*Руководство проектомПланирование процесса разработкиОсновная задача планирования – декомпозиция проекта и представление

Планирование процесса разработкиИерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) –

Выделение компонентовВыделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое

Базовое расписание проектаБазовое расписание — утвержденный план-график с указанными временными фазами

Диаграмма Ганта*Руководство проектом

*Руководство проектомГраницы времени выполненияРаспараллеливание задач требует согласования процессов их выполнения во

*Руководство проектомРаспределение времени выполненияРекомендуемое распределение времени выполнения проекта:на анализ и проектирование

*Руководство проектомВыбор модели разработкиРеальный процесс разработки никогда жестко не увязывается с

Оценка объема и сложности проектаПервое, что необходимо понимать при оценке проекта

Оценка объема и сложности проектаВероятностный характер оценки, означает, что для нее

*Руководство проектомОценки на основе метрикДля оценки различных свойств процесса создания программного

Оценки на основе метрикМетрики используются для получения предварительной, текущей и итоговой

Классификация метрикМетрики сложности программ принято разделять на три основные группы:метрики размера

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

Метрики потока управленияМетрики сложности потока управления базируются на анализе управляющего графа

Метрики потока данныхМетрики третьей группы базируются на оценке использования, конфигурации и

*Руководство проектомРазмерно-ориентированные метрикиОснованы на LOC-оценках, т.е. на количестве строк в текстах

*Руководство проектомМетрики производительности и качества Длина [тыс. LOC]Производительность = Затраты [чел.-мес.] Ошибки [Единиц]Качество

*Руководство проектомМетрики стоимости и документированности Стоимость [Тыс. руб.] Удельная Стоимость =

*Руководство проектомДостоинства и недостаткиРазмерно-ориентированные метрики:основаны на объективных данныхпросты и легко вычислимыНедостатки:зависят

Метрики сложности кодаПомимо показателей оценки объема работ по проекту очень важными

Метрики ХолстедаПри вычислении этих метрик используются следующие опорные значения:nu1 – число

Метрики ХолстедаНа основании этих опорных значений рассчитываются следующие метрики программы:словарь NU

Метрика Мак-КейбаПоказатель цикломатической сложности является одним из наиболее распространенных показателей оценки

Метрика Мак-КейбаУпрощенная формула вычисления цикломатической сложности представляется следующим образом: C = e

Достоинства и недостатки метрикиДостоинства метрики Мак-Кейба:простоту вычисления и повторяемость результата, наглядность

Метрика ЧепинаСуть метода состоит в оценке информационной прочности отдельно взятого программного

Функциональные группыМножество Р - вводимые переменные для расчетов и для обеспечения вывода

Формула метрики ЧепинаПоскольку каждая переменная может выполнять одновременно несколько функций, необходимо

Весовые коэффициентыПо мнению автора метрики наибольший вес, равный трем, имеет функциональная

Формула ЧепинаС учетом весовых коэффициентов выражение для метрики Чепина примет вид: Q

Похожие презентации

«Если водитель трамвая начнет искать новые пути, жди беды»
Классическое управление проектами

Проект – основа инноваций
Условия применимости проектной деятельности:
разрабатывается новый продукт,
внешние условия

Проект – основа инноваций
Проект – это временное предприятие, предназначенное для создания

Проект – средство стратегического развития
*
Руководство проектом

Проект – средство стратегического развития
Цель – описание того, что мы

Критерии успешности проекта
Задача проекта — достижение конкретной бизнес-цели, при соблюдении ограничений

Критерии успешности проекта
Проект считается успешным, если:
выполнен в соответствие со спецификациями,

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

Роли и ответственности
Роли и ответственности участников типового проекта разработки ПО можно

Группа анализа
Включает в себя следующие роли:
Бизнес-аналитик. Построение модели предметной

Группа управления
Состоит из следующих ролей:
Руководитель проекта. Отвечает за достижение

Производственная группа
В ее состав входят:
Проектировщик. Проектирование компонентов и подсистем

Группа тестирования
Состоит из следующих ролей:
Проектировщик тестов. Разработка тестовых сценариев.

Группа обеспечения
Участники этой группы, как правило, не входят в команду проекта.

Временное распределение ресурсов
В операционной деятельности ресурсы расходуются равномерно по времени
В проектном

Начало проекта
В компании, которая принимает решение о старте того или иного

Шкала оценки финансовой ценности проекта
Может выглядеть следующим образом:
Высокая. Ожидаемая

Шкала оценки финансовой ценности проекта
Средняя. Проект позволяет улучшить эффективность производства

Шкала оценки стратегической ценности
Может иметь следующий вид:
Высокая. Обеспечивает стратегическое

Шкала оценки стратегической ценности
Средняя. Поддерживается доверие рынка к компании. Повышает

Шкала оценки уровня рисков проекта
Может иметь следующий вид:
Низкий. Цели

Шкала оценки уровня рисков проекта
Выше среднего. Цели проекта недостаточно четки.

*
Руководство проектом
Начало проекта
В начале работы над проектом необходимо:
установить цели и проблемную

*
Руководство проектом
Процесс оценки
Оценка объема предстоящих работ производится в человеко-месяцах
Исходя из нее

*
Руководство проектом
Анализ рисков
Риском называется возможная потеря в процессе разработки. Это может

*
Руководство проектом
Пример проверочного списка элементов риска

*
Руководство проектом
Ранжирование рисков
Ранжирование заключается в назначении каждому риску приоритета в соответствии

*
Руководство проектом
Планирование процесса разработки
Основная задача планирования – декомпозиция проекта и представление

Планирование процесса разработки
Иерархическая структура работ (ИСР) (Work /Breakdown Structure, WBS) –

Выделение компонентов
Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое

Базовое расписание проекта
Базовое расписание — утвержденный план-график с указанными временными фазами

Диаграмма Ганта
*
Руководство проектом

*
Руководство проектом
Границы времени выполнения
Распараллеливание задач требует согласования процессов их выполнения во

*
Руководство проектом
Распределение времени выполнения
Рекомендуемое распределение времени выполнения проекта:
на анализ и проектирование

*
Руководство проектом
Выбор модели разработки
Реальный процесс разработки никогда жестко не увязывается с

Оценка объема и сложности проекта
Первое, что необходимо понимать при оценке проекта

Оценка объема и сложности проекта
Вероятностный характер оценки, означает, что для нее

*
Руководство проектом
Оценки на основе метрик
Для оценки различных свойств процесса создания программного

Оценки на основе метрик
Метрики используются для получения предварительной, текущей и итоговой

Классификация метрик
Метрики сложности программ принято разделять на три основные группы:
метрики размера

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

Метрики потока управления
Метрики сложности потока управления базируются на анализе управляющего графа

Метрики потока данных
Метрики третьей группы базируются на оценке использования, конфигурации и

*
Руководство проектом
Размерно-ориентированные метрики
Основаны на LOC-оценках, т.е. на количестве строк в текстах

*
Руководство проектом
Метрики производительности и качества
Длина [тыс. LOC]
Производительность = Затраты [чел.-мес.]
Ошибки [Единиц]
Качество

*
Руководство проектом
Метрики стоимости и документированности
Стоимость [Тыс. руб.]
Удельная Стоимость =

*
Руководство проектом
Достоинства и недостатки
Размерно-ориентированные метрики:
основаны на объективных данных
просты и легко вычислимы
Недостатки:
зависят

Метрики сложности кода
Помимо показателей оценки объема работ по проекту очень важными

Метрики Холстеда
При вычислении этих метрик используются следующие опорные значения:
nu1 – число

Метрики Холстеда
На основании этих опорных значений рассчитываются следующие метрики программы:
словарь NU

Метрика Мак-Кейба
Показатель цикломатической сложности является одним из наиболее распространенных показателей оценки

Метрика Мак-Кейба
Упрощенная формула вычисления цикломатической сложности представляется следующим образом:
C = e

Достоинства и недостатки метрики
Достоинства метрики Мак-Кейба:
простоту вычисления и повторяемость результата,
наглядность

Метрика Чепина
Суть метода состоит в оценке информационной прочности отдельно взятого программного

Функциональные группы
Множество Р - вводимые переменные для расчетов и для обеспечения вывода

Формула метрики Чепина
Поскольку каждая переменная может выполнять одновременно несколько функций, необходимо

Весовые коэффициенты
По мнению автора метрики наибольший вес, равный трем, имеет функциональная

Формула Чепина
С учетом весовых коэффициентов выражение для метрики Чепина примет вид:
Q