Содержание
- 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. Скачать презентацию