exam05 4 - stankin/design-part-1 GitHub Wiki

Понятия риска и управления рисками. Риски и дисциплины в методологии RUP.

Реферат к лекции 5. Проектирование и разработка программных средств.

Выполнил: Баркан Александр | ИДБ-18-05

Проверил: Белинский Петр | ИДБ-18-05

Понятие риска и управления рисками

Риск — следствие влияния неопределенности на достижение поставленных целей.

❌ Не хватает примеров и более предметного рассмотрения управления рисками, т.е. типовых стратегий. См.лекцию и тест.

Можно выделить несколько определений, которые в полной мере могут описать понятие "управление рисками".

Менеджмент риска (risk management) — скоординированные действия по руководству и управлению организацией в области риска.

Структура менеджмента риска (risk management framework) — взаимосвязанные элементы, которые обеспечивают реализацию принципов и организационные меры, применяемые при проектировании, разработке, внедрении, мониторинге, анализе и постоянном улучшении менеджмента риска организации.

Политика в области менеджмента риска (risk management policy) — заявление высшего руководства об общих намерениях, руководящих принципах и направлениях деятельности организации в области менеджмента риска.

План менеджмента риска — краткое, схематичное описание деятельности и мероприятий в пределах структуры менеджмента риска, устанавливающих подход, элементы менеджмента и ресурсы, применяемые для менеджмента риска.

Процесс менеджмента риска (risk management process) — взаимосвязанные действия по обмену информацией, консультациям, установлению целей, области применения, идентификации, исследованию, оценке, обработке, мониторингу и анализу риска, выполняемые в соответствии с политикой, процедурами и методами менеджмента организации.

Далее идет определение, которое объединяет в себе все, что описано выше.

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

Понятие RUP, риски и дисциплины

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

Принципы методологии RUP

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

Жизненный цикл

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

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

Начало (Inception)

На этом этапе:
- Формируются видение и границы проекта.
- Создается экономическое обоснование (business case).
- Определяются основные требования, ограничения и ключевая функциональность продукта.
- Создается базовая версия модели прецедентов
- Оцениваются риски.
- При завершении фазы Начало оценивается достижение вехи целей жизненного цикла Lifecycle Objective Milestone, которое предполагает соглашение заинтересованных сторон о продолжении проекта.
Уточнение (Elaboration)

На этапе Уточнение производится анализ предметной области и построение исполняемой архитектуры. Это включает в себя:
- Документирование требований (включая детальное описание для большинства прецедентов использования).
- Спроектированную, реализованную и оттестированную исполняемую архитектуру.
- Обновленное экономическое обоснование и более точные оценки сроков и стоимости.
- Сниженные основные риски.
- Успешное выполнение фазы Уточнение означает достижение вехи архитектуры жизненного цикла (Lifecycle Architecture Milestone).
Построение (Construction)

Во время этой фазы происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).
Внедрение (Transition)

Во время фазы Внедрение создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки.

Дисциплины

Существуют следующие дисциплины:

Business Modeling
Анализ и проектирование
Развертывание
Реализация
Среда
Тестирование
Требования
Управление конфигурацией и изменениями
Управление проектом

Также существуют наборы ролей:

Администраторы
Аналитики
Общие роли
Работа и поддержка
Разработчики
Тестировщики

Внутри каждого набора определены точные роли.

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

Рассмотрим на примере.

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

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