Эффективная подготовка к государственным междисциплинарным экзаменам для студентов технических специальностей (стр. 21 )

n  Выполняется классификация (категоризация) рисков

n  Создается список рисков

n  Классификация помогает управлять рисками

n  При выявлении рисков помогает проверить полноту полученного списка рисков

n  Помогает определить общие причины рисков и бороться с ними

n  Возможно использование различных классификаций

Шаг 2: Анализ и приоритезация рисков

§  Приоритезация выявленных рисков

§  Невозможно управлять сразу всеми рисками

§  Существуют риски, которым необходимо уделить больше внимания – как их выявить?

§  Как это сделать?

§  Некоторые риски имеют фатальные последствия, но крайне маловероятны

§  Некоторые риски очень вероятны, но их влияние на проект ничтожно

Пример: анализ риска

n  Риск: Если система не будет реализована и протестирована к началу соревнований, они будут сорваны

n  Оценка вероятности – 2 (средняя)

n  Угроза – 3 (высокая)

n  Общее влияние – 2*3 = 6

n  Риск попал в первую десятку

Шаг 3: Планирование рисков

§  Цели

§  Разработка планов действий по отношению к основным рискам

§  Внесение мероприятий по управлению рисками в расписание проекта

Предотвращение риска

n  Что можно сделать, чтобы уменьшить вероятность риска?

n  Что можно сделать, чтобы уменьшить угрозу риска?

n  Уменьшений вероятности не есть избегание риска

Смягчение последствий

n  Если риск все-таки осуществится, надо быть готовым к этому

n  Действия должны быть продуманы заранее

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

Шаг 4: Мониторинг

n  Цели

•  Отслеживание рисков, триггеров

•  Наблюдение за выполнением планов предотвращения и смягчения последствий

•  Информирование членов комадны о событиях, связанных с рисками

Шаг 5: Корректирование ситуации

n  Успешное выполнение планов предотвращения

n  Своевременное задействование планов смягчения последствий

n  Постоянная деятельность во время работы над проектом

Шаг 6: Извлечение опыта

n  Обратная связь в процессе управления рисками

n  Обмен опытом с другими проектными группами

n  Усовершенствование процесса управления рисками

n  Происходит на протяжении всей жизни проекта

Сравнение XP и MSF

	eXtreme Programming	MSF
Размер команды	Как правило, не большой, до 20 человек	Не менее 3-х, практически нет ограничений
Управление рисками	Неявное	Явное, CMM* Level 4
Документиро-вание	Практически отсутствует	Обязательно, документы не формализованы
* Позволяет организации (при выполнении дополнительных условий) соответствовать CMM Level 4

Сравнение PMBOK и MSF

	PMBOK	MSF
Применимость	Может применяться в любой области	Ориентировано на IT
Управление рисками	Явное, CMM Level 4 *	Явное, CMM Level 4 *
Документиро-вание	Обязательно, документы формализованы	Обязательно, документы не формализованы
* Позволяет организации (при выполнении дополнительных условий) соответствовать CMM Level 4

12. Требования. Управление требованиями.

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

Спецификация требований – документ, определяющий требования к приложению и являющийся подобием контракта и путеводной нити для заказчика и разработчиков.

УРОВНИ ТРЕБОВАНИЙ

•  Бизнес – требования;

•  Требования пользователей;

•  Функциональные требования;

•  Системные требования.

ХАРАКТЕРИСТИКИ ТРЕБОВАНИЙ

•  Полнота;

•  Корректность;

•  Осуществимость;

•  Необходимость;

•  Назначение приоритетов;

•  Недвусмысленность;

•  Проверяемость;

•  Согласованность;

•  Способность к модификации;

•  Трассируемость.

ПРАВА КЛИЕНТОВ ПРИ ФОРМИРОВАНИИ ТРЕБОВАНИЙ

1)  Иметь дело с аналитиком, который разговаривает на вашем языке;

2)  Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создаётся система;

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

4)  Получить от аналитика подробный отчёт обо всех рабочих продуктах, созданных в процессе формулирования требований;

5)  На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков;

6)  Знать о вариантах и альтернативах требований и их реализации;

7)  Описать характеристики, упрощающие работу с продуктом;

8)  Изменить требования или разрешить использование имеющихся программных компонентов;

9)  Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО;

10) Потребовать, чтобы система функциональностью и качеством удовлетворяла требованиям заказчика.

ОБЯЗАННОСТИ КЛИЕНТОВ ПРИ ФОРМИРОВАНИИ ТРЕБОВАНИЙ

1)  Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса;

2)  Потратить столько времени, сколько необходимо, на объяснение требований;

3)  Точно и корректно описать требования к системе;

4)  Принимать своевременные решения;

5)  Уважать определённую разработчиком оценку стоимости и возможность реализации ваших требований;

6)  Определять приоритеты требований;

7)  Просматривать документы с требованиями и оценивать прототипы;

8)  Своевременно сообщать об изменениях требований;

9)  Поддерживать принятый в организации – разработчике порядок контроля изменений;

10) Уважительно относиться к методам, с помощью которых аналитики создают требования.

РАЗРАБОТКА ТРЕБОВАНИЙ

1)  Извлечение

·  Определите процесс формулирования требований;

·  Определите образ и границы проекта;

·  Определите классы пользователей;

·  Выделите из пользователей ярого сторонника продукта;

·  Создайте фокус – группу;

·  Определите назначение проекта;

·  Определите системные события и реакцию на них;

·  Проводите совместные семинары, упрощающие сбор требований;

·  Наблюдайте за пользователями на рабочих местах;

·  Изучите отчёты о проблемах;

·  Используйте требования многократно.

2)  Анализ

·  Нарисуйте контекстную диаграмму;

·  Создайте прототипы;

·  Проанализируйте осуществимость;

·  Расставьте приоритеты для требований;

·  Смоделируйте требования;

·  Создайте словарь терминов;

·  Распределите требования по подсистемам;

·  Воспользуйтесь технологией развёртывания функций качества.

3)  Документирование

·  Используйте шаблон спецификации требований к ПО;

·  Определите источники требований;

·  Задайте каждому требованию уникальный идентификатор;

·  Задокументируйте бизнес – правила;

·  Укажите атрибуты качества.

4)  Проверка

·  Изучите документы с требованиями;

·  Протестируйте требования;

·  Определите критерии приемлемости.

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

•  Создание контекстной диаграммы;

•  Создание пользовательского интерфейса и технических прототипов;

•  Анализ осуществимости требований;

•  Определение приоритетов требований;

•  Моделирование требований;

•  Создание словаря терминов;

•  Распределение требований по подсистемам;

•  Применение технологий развёртывания функций качества.

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

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

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

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

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

На основании приоритетов установите, в какой версии будет реализована та или иная функция или набор требований.

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

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

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

Приоритеты – способ разрешения борьбы между конкурирующими требованиями за ограниченные ресурсы.

При оценке приоритетов учитывают два измерения: важность и срочность.