- •Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Ивановский государственный энергетический университет имени в.И. Ленина».
- •Иваново 2014
- •Оглавление
- •Предисловие
- •Введение
- •1.Предмет программной инженерии
- •1.1.Определение и свойства программного обеспечения
- •1.2.Проблемы разработки программного обеспечения
- •1.3.Процессы производства программного обеспечения
- •1.4.Понятие программного проекта
- •1.5. Стандартизация в области производства по
- •1.6.Определение программной инженерии и ее место в системе информационных технологий
- •2.Жизненный цикл программных продуктов
- •2.1.Понятие жизненного цикла
- •2.2.Процессы жизненного цикла программного обеспечения
- •2.3.Модели жизненного цикла
- •3.Виды деятельности в программной инженерии
- •3.1.Управление требованиями
- •3.1.1.Проблема
- •3.1.2.Цикл работы с требованиями
- •3.1.3.Виды и свойства требований
- •3.1.4.Варианты формализации требований
- •3.2.Проектирование программного обеспечения
- •3.2.1.Понятие
- •3.2.2.Принципы
- •3.2.3.Шаблоны
- •3.2.4.Моделирование по
- •3.2.5.Методологии
- •3.2.6.Оценка качества
- •3.3.Конструирование программного обеспечения
- •3.3.1.Определение
- •3.3.2.Связь с другими процессами
- •3.3.3.Принципы
- •3.3.4.Модели и методы
- •3.3.5.Языки конструирования
- •3.4.Конфигурационное управление
- •3.4.1.Проблемы управления активами программного проекта
- •3.4.2.Единицы конфигурационного управления
- •3.4.3.Управление версиями
- •3.4.4.Управление сборками
- •3.4.5.Понятие baseline
- •3.5.Тестирование программного обеспечения
- •3.5.1.Основные определения
- •3.5.2.Уровни тестирования (Test Levels)
- •3.5.3.Виды тестирования
- •3.5.4.Метрики
- •3.6.Сопровождение программного обеспечения
- •Эволюция программного обеспечения (Evolution of Software)
- •4.Методология объектно-ориентированного анализа и проектирования
- •4.1.Основные понятия
- •4.1.1.Объекты и классы
- •4.1.2.Принципы ооп
- •4.1.3.Разработка объектно-ориентированных программ
- •4.2.Язык uml
- •4.2.1.Что дает uml
- •4.2.2.Структура языка uml
- •4.2.3.Uml диаграммы
- •4.2.4.Программы поддержки языка uml
- •4.3.Вопросы для самоконтроля
- •5.Технологии разработки программного обеспечения
- •5.1.Тяжеловесные и облегченные технологии
- •5.2.Технология rup
- •5.3.Гибкие технологии
- •5.4.Технология msf
- •5.4.1. Управление рисками в msf for Agile Software Development1
- •5.4.2.Основные сведения о рисках
- •5.4.3.Планирование управления рисками
- •5.4.4.Процесс управления рисками
- •5.4.5.Управление рисками как составная часть жизненного цикла проекта
- •5.4.6.Учебный пример. Выделение рисков
- •5.5.Модель процессов msf for Agile Software Development2
- •5.5.1.Принципы модели процессов
- •5.5.2.Управление компромиссами
- •5.5.3.Схема процесса разработки
- •5.6.1. Подготовка проекта
- •5.6.2. Планирование проекта
- •5.6.3. Планирование спринта
- •5.6.4. Выполнение спринта
- •5.6.5. Отслеживание проекта
- •5.7.1. Каково назначение модели cmmi?
- •5.7.2. Как лучше использовать модель cmmi?
- •5.7.3. Элементы модели cmmi
- •Заключение Литература
- •153003, Г. Иваново, ул. Рабфаковская, 34.
5.5.2.Управление компромиссами
В силу свойственной IT-проектам неопределенности и рискованности, одним из ключевых факторов их успеха являются эффективные компромиссные решения (trade-offs).
Треугольник компромиссов
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник компромиссов (tradeoff triangle).
Рис. 6.3. Треугольник компромиссов. Источник: белая книга [1]
После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Нахождение верного баланса между ресурсами, временем разработки и возможностями – ключевой момент в построении решения, должным образом отвечающего нуждам заказчика.
Матрица компромиссов проекта
Другое полезное средство управления проектными компромиссами – матрица компромиссов проекта (project tradeoff matrix).
Она отражает достигнутое на ранних этапах проекта соглашение между проектной группой и заказчиком о выборе приоритетов в возможных в будущем компромиссных решениях.
Возможный вариант такой матрицы представлен на рисунке.
Рис. 6.4. Матрица компромиссов (возможный вариант). Источник: белая книга [1]
Матрица компромиссов помогает обозначить проектное ограничение, воздействие на которое практически невозможно (колонка “Фиксируется”), фактор, являющийся в проекте приоритетным (колонка “Согласовывается”), и третий параметр, значение которого должно быть принято в соответствии с установленными значениями первых двух величин (колонка “Принимается”).
5.5.3.Схема процесса разработки
Модели процессов описывают последовательность действий, осуществляемых в ходе реализации проекта. Можно сказать, что они задают тем самым жизненный цикл проекта. Спектр моделей, применяемых в настоящее время различными организациями, весьма широк. Среди них есть и модель процессов MSF, возникшая на основе используемого в компании Microsoft подхода к разработке программных приложений. В результате своего развития она объединила ряд наиболее эффективных принципов других известных моделей процессов, сформировав при этом единую базу для работы над проектами любых типов: ориентированных на фазы (phase-based), основанных на вехах/контрольных точках (milestone-driven) и итеративных (iterative).
Структурные единицы схемы
MSF for Agile Software Development поддерживает быструю итеративную разработку. Проектирование, разработка, тестирование выполняются в перекрывающих друг друга итерациях, каждая из которых фокусируется на реализации отдельных аспектов решения.
Рис. 6.5. Итерации процесса разработки. Источник: MSF for Agile Software Development Process Guidance [11]
Короткие итерации позволяют свести к минимуму влияние ошибок в понимании и формулировании требований, дают быструю обратную реакцию о точности проектных планов.
Каждая итерация должна завершаться получением результата в виде стабильной части целого продукта.
Цикличность процесса разработки
На каждом уровне процесса создания решения MSF предполагает цикличность. Создание версии продукта – цикл из итераций. Итерация – цикл из ежедневно собираемых билдов. Билд – цикл изменений, вносимых в систему контроля версий.
Рис. 6.6. Циклы процесса разработки. Источник: MSF for Agile Software Development Process Guidance [11]
Фазы и вехи процесса разработки
Модель MSF покрывает процесс создания решения с самого его начала и до момента окончательного внедрения. Весь процесс создания решения разбит на пять фаз. Каждая из них заканчивается главной вехой, результаты которой становятся видимыми за пределами проектной команды.
Рис. 6.7. Фазы и вехи модели процессов MSF. Источник: белая книга [1]
Веха является точкой синхронизации достигнутых результатов и ожиданий заказчика, а также анализа проектной среды. В решении о закрытии очередной фазы должны принимать участие ответственные представители всех ролевых групп.
В рамках фазы обычно присутствуют промежуточные вехи, обозначающие достигнутые промежуточные результаты. MSF дает определенные рекомендации (будут рассмотрены при изучении соответствующих фаз) относительно промежуточных вех на каждой фазе, однако проектная команда может сформировать свои специфические для проекта и фазы промежуточные вех.
5.6.MSF for Agile Software Development
Выбор оптимального шаблона процесса при создании командного проекта позволяет предоставить команде набор инструментов, соответствующий стилю ее работы, а также помогает команде сосредоточиться на качестве за счет уменьшения непроизводительных трудозатрат .Шаблон процесса задает набор рабочих элементов, отчетов, панелей мониторинга, которые будут использоваться для планирования и отслеживания проекта.
Шаблон процесса определяет типы рабочих элементов, доступных для отслеживания, а также создаваемые по умолчанию правила, политики, группы безопасности и запросы, используемые участниками команды. Как правило, при выборе шаблона следует руководствоваться следующими соображениями.
Если команда использует Scrum или другие гибкие процессы, следует предпочесть шаблон процесса Microsoft Solutions Framework (MSF) для гибкой разработки программного обеспечения версии 5.0 (MSF for Agile Software Development v5.0).
Если команде требуется тщательное ведение журнала аудита и в ней внедрен формальный процесс управления изменениями, следует предпочесть шаблон процесса MSF для улучшения процесса CMMI версии 5.0 (MSF for CMMI Process Improvement v5.0).
Кроме того, можно загрузить дополнительные шаблоны процессов из Интернета или настроить шаблон процесса в соответствии со своими потребностями.
Scrum — это платформа для запуска проектов, основанная на гибких принципах и показателях. Она определяет набор действий, которые помогут команде быстрее достигать поставленных заказчиками целей. Эти действия обеспечивают заказчикам возможность проверять промежуточные результаты, руководить ходом работ и влиять на них иным образом. При этом подходе не предпринимается попытка полностью определить проект в самом его начале. Работа команды разбивается на короткие итерации (также называемые спринтами), и план действий уточняется по мере выполнения поставленных задач. Сведения о гибких принципах и показателях, лежащих в основе методологии Scrum, см. в статье Принципы и значение гибкой разработки, Джеф Сазерленд (Jeff Sutherland).
Платформа MSF для гибкой разработки программного обеспечения версии 5.0 основана на методологии Scrum.Поэтому команды могут внедрять процессы Scrum, используя средства, интегрированные о основными действиями разработки.
Содержание раздела
|
|
