- •2. Модель па
- •2.1.Бизнес - перспектива
- •2.2.Прикладная перспектива
- •2.3.Информационная перспектива
- •2.4.Технологическая перспектива
- •2.5 Основные опасности при разработке производственной архитектуры
- •2.6 Задачи модели производственной архитектуры msf
- •3. Создание производственной архитектуры
- •1. Общая характеристика модели приложения
- •1.1.Повторное использование компонентов
- •1.2.Размер приложения
- •1.3. Производительность приложения
- •1.4.Масштабируемость приложений
- •1.5.Виды архитектуры
- •2. Модель приложений
- •2.1. Бизнес-модель
- •2.2 Пользовательская модель
- •2.3 Логическая модель
- •2.4 Технологическая модель
- •2.5 Модель разработки
- •2.6 Физическая модель
- •1. Общие характеристики модели проектных групп
- •2. Обязанности членов группы
- •3. Модель проектой группы
- •3.1. Менеджер продукта
- •3.2Менеджер программы
- •3.3.Разработчик
- •3.4 Тестер
- •3.5.Инструктор
- •3.6 .Логистик
- •4.Размер групп и масштаб проекта
- •5. Создание группы
- •5.1.Поиск руководителей
- •5.2.Повышение эффективности коллективной работы
- •5.3. Координация работы с внешними группами
- •1. Модель разработки приложений
- •2.Модель процесса разработки msf
- •Основные этапы
- •Промежуточные этапы
- •Итеративность
- •3. Фазы разработки и их основные этапы.
- •3.1 Фаза Анализ
- •3.3.Фаза «Планирование»
- •3.3.Фаза «Разработка»
- •3.4. Фаза «Стабилизация»
- •4. Принципы модели процесса разработки
- •5.Роли членов группы в модели процесса разработки
- •Динамика фазы Анализ модели процесса разработки msf
- •1.Процесс исследования
- •1.1.Распределение обязанностей ролей
- •2. Модель управление рисками
- •2.1.Источники риска
- •2.2.Способы управления рисками
- •3.Этап «Одобрение концепции» и его результаты
- •3.1Концепция
- •3.2.Прототип
- •3.3. Структура проекта
- •3.4. Сводный документ оценки рисков
- •3.5. Согласование концепции
- •Динамика фазы планирования
- •1.Общая характеристика фазы планирования
- •Фаза «Планирование» и процесс проектирования
- •Распределение ролей при планировании
- •Обязанности ролей при планировании
- •12.Процесс проектирования
- •2.1. Стадии концептуального проектирования
- •2.2.Стадия логического проектирования
- •2.3.Стадия физического проектирования
- •2.1. Управление рисками на фазе планирования
- •4.Этап «Одобрение плана проекта» и его результаты
- •4.1.Функциональные спецификации
- •4.2.Основной план проекта
- •4.2.Основной график проекта
- •4.3.Пересмотренный документ оценки рисков
- •Динамика фазы разработки и ее основные результаты.
- •1. Общая характеристика фазы разработки
- •2. Основные этапы разработки
- •2.1.Распределение обязанностей на стадии разработки
- •2.3.Первый этап: анализ и рационализация
- •2.4.Второй этап: реализация
- •2.5.Третий этап: аттестация
- •2.6.Управление рисками
- •3.Этап «Завершение разработки» и его результаты
- •3.1. Код и исполняемые модули
- •3.2.Средства повышения эффективности работы пользователей и сопроводительные материалы
- •3.3. Тестовые материалы
- •Динамика фазы стабилизации
- •Распределение обязанностей в группе
- •Промежуточные этапы
- •Управление рисками на фазе Стабилизации
- •1)Организованные риски;
- •Этап «Выпуск продукта» и его результаты
2.6.Управление рисками
Процесс управления рисками начинается на стадии концептуального проектирования и продолжается до конца жизненного цикла программного продукта. Сводный документ оценки рисков, который является одним из результатов фазы «Планирование», на всех следующих стадиях постоянно уточняется. Процесс уточнения, состоящий из пяти шагов, проиллюстрирован на рис. 12.2. Очевидно, что проектная группа продолжает определять статус различных рисков, выявленных на стадии «Планирование» и перечисленных в сводном документе.
Как и прежде, рассматривая каждый риск, проектная группа должна ответить на следующие вопросы.
• Что сделано для снижения риска?
• Изменился ли риск под действием внешних факторов?
• Изменились ли вероятность или последствия какого-либо из рисков под действием внешних факторов или в результате деятельности группы? Если да, как изменилась вероятность реализации риска и его приоритет?
• Исключены ли какие-либо факторы риска?
• Какие действия следует предпринять с учетом ответов на эти вопросы
хотим подчеркнуть важность управления рисками для успешного завершения проекта. Проектная группа должна постоянно заниматься этой работой. Более того, это важнейшая составная часть управления проектом в рамках MSF. На стадии «Разработка»проектной группе придется заново оценить 10 важнейших рисков проекта и переработать планы их снижения, а также предпринимать постоянные усилия по устранению реализовавшихся рисков.
3.Этап «Завершение разработки» и его результаты
Основная цель стадии «Разработка» — завершение разработки, о чем свидетельствуют следующие результаты.
• Пересмотренные функциональные спецификации — в этом документе отражаются изменения проекта в результате разработки приложения; другими словами, в этом документе проект приведен в соответствие с готовым продуктом. Пересмотренные функциональные спецификации отражают все коррективы, внесенные в проект на стадии разработки и согласованные с заказчиком. Кроме того, здесь описаны новые функциональные возможности, которые будут включены в следующие версии приложения,
• Пересмотренный план проекта — здесь описан план выполнения последней фазы проекта и стабилизации продукта, а также перечислены все развертываемые составляющие. Пересмотренный план отражает все изменения, внесенные в проект на стадии «Разработка».
• Пересмотренный график проекта — в пересмотренный график включается время, необходимое для стабилизации продукта. Как и пересмотренный план проекта, график отражает все изменения, внесенные на стадии «Разработка».
• Пересмотренный сводный документ оценки рисков — здесь отражены потенциальные угрозы и меры, предпринятые группой для их уменьшения, а также описаны как уже известные, так и новые
риски, обнаруженные на стадии разработки. Кроме того, в документе следует описать план управления рисками и ход его выполнения до настоящего момента.
• Исходные тексты приложения и исполняемые модули — все тексты и модули, составляющие полнофункциональный выпуск продукта. Этот выпуск свидетельствуете завершении разработки и имеет статус версии-кандидата.
• Средства повышения эффективности работы пользователей и сопроводительные материалы — описание работы приложения как для пользователей, так и для группы сопровождения. Средства повышения эффективности работы пользователей варьируются от мастеров и документации до материалов для учебных курсов. Сопроводительные материалы для группы сопровождения включают инструкции по установке, конфигурированию, администрированию и использованию приложения.
• Тестовые материалы — методы аттестации приложения и список элементов, тестируемых на стадии «Стабилизация». Это планы тестирования, спецификации тестов, схемы и сценарии, обеспечивающие тестирование всего набора функциональных возможностей продукта. Группа тестирования должна создать набор автоматизированных тестовых сценариев для использования на стадии стабилизации.