Гвоздев В.Е., д.т.н., профессор

1 марта 2012 г.

Открытый семинар

Управление ИТ-проектами: Определение требований к программному продукту

2

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

Project Management Institute

Ведущая некоммерческая профессиональная ассоциация с 1969 г.

Управление проектами – обязательное условие достижения результата

Более 480 000 профессионалов в 185 странах

Универсальная методика для всех отраслей

Свод методических знаний (стандарт РМВОК® и др.)

Обучение и сертификация

Исследования и обмен опытом

Московское отделение PMI с 1998 г.

Более 500 членов

Филиалы в Екатеринбурге, Перми, Уфе и Челябинске

Филиал МО PMI в Уфе c 2010 г.

Продвижение технологий Управления проектами

Обмен опытом

Изучение международного опыта

Обучение

3

Международные стандарты PMI

ПЕРЕВЕДЕНО НА РУСС.ЯЗ.

ПЕРЕВЕДЕНО НА РУСС.ЯЗ.

4

1. Руководство к Своду знаний по управлению проектами (Руководство РМВОК), 4-е изд. на русском языке

2. Дополнение к РМВОК по управлению проектами в государственном секторе, 3-е изд.

3. Дополнение к РМВОК по управлению проектами в строительстве, 2-е изд.

4. Стандарт Управление программами, 2-е изд.

5. Стандарт Управление портфелем, 2-е изд.

6. Практический стандарт по планированию расписания, 2-е изд.

7. Практический стандарт по управлению конфигурацией проекта

8. Практический стандарт по управлению выполненной стоимостью

9. Практический стандарт по декомпозиции структуры проектной работы

10. Практический стандарт по управлению рисками проекта

11. Развитие компетенции менеджера проектов, 2-е изд.

12. Модель зрелости управления проектами в организации (ОРМ3), 2-е изд.

Международные стандарты PMI

5

30 января в Уфе впервые прошел экзамен на получение сертификата РМР

• Количество проходивших экзамен – 8 человек, успешно сдали – 7 человек!

• Формат экзамена – бумажный.

Для того, чтобы организовать бумажный экзамен (PBT) необходимо набрать группу минимум 8-10 человек. Все участники должны проходить экзамен одновременно.

Стоимость «бумажного» экзамена – 250 долл. для членов PMI и 400 долл. для нечленов PMI (электронный экзамен – 405 и 555 дол. соответственно)

Экзамены в Уфе будут проходить регулярно, для записи необходимо подать заявку в свободной форме на адрес ufa@pmi.ru

Подробная информация о «бумажном» экзамене: http://pmi.ru/certificates/Paper%20Based%20Testing_PBT.php

В Уфе прошел экзамен РМР

6

• PMP® (Project Management Professional – Профессионал в области управления проектами)

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

Наиболее популярный сертификат менеджера проектов, в мире насчитывается более 300 000 сертифицированных PMP

Вариант 1: Высшее образование И 4500+ часов работы (3 года)

И 35+ часов обучения в области управления проектами

Вариант 2: Полное среднее образование И 7500+ часов работы (5 лет)

И 35+ часов обучения в области управления проектами

Свидетельство об образовании, Форма подтверждения опыта И обучения

в области УП

200 вопросов за 4 часа (знание РМВОК и практические навыки УП)

Язык: английский, русский

Сертификационные программы PMI

7

CAPM® (Certified Associate in Project Management)

Программа базового уровня знаний

PgMP® (Program Management Professional)

Программа для специалистов по управлению программами

PMI-SP® (Scheduling Professional)

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

PMI-RMP® (Risk Management Professional)

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

Другие сертификационные программы PMI

Источник:

Steve McConnell

Software Project

Survival Guide

Microsoft Press

Самой трудной частью сбора требований

является не запись пожеланий пользователей, а

исследовательская деятельность, направленная

на помощь пользователям в определении своих

желаний

1

КОНУС НЕОПРЕДЕЛЕННОСТИ

ПРОГРАММНОГО ПРОДУКТА

4х

2х

х

0,5х

0,25х

Точ

но

сть

оц

енки

ст

ои

мо

сти

и

вр

емен

и

Анализ

требований Проектирование

системы

Реализация Интеграция

и внедрение

Функционирование

и сопровождение

ТИПЫ ДЕФЕКТОВ И ОШИБОК ПРОЕКТОВ

ПРОГРАММНЫХ СРЕДСТВ

Технологические ошибки

ввода и отображение данных

Ошибки в документации программного

средства

Программные ошибки

компонентов

Ошибки реализации спецификаций программных

компонентов

Алгоритмические ошибки программного средства

Системные ошибки программного средства

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

Ошибки корректности требований и планирования проекта

Ошибки вследствие большого масштаба проекта

Ошибки вследствие сложности проекта

Ошибки оценки характеристик системы и внешней среды

Организационные дефекты проекта

Риск и опасность последствий ошибок

ТИПИЧНАЯ СХЕМА РАСПРЕДЕЛЕНИЯ ДЕФЕКТОВ

В ПРОГРАММНОМ ПРОДУКТЕ

20% - логические

11% - обработки данных

7% - стандарты

25% - спецификации (в том

числе требований)

12% - пользовательские

интерфейсы

11% - контроль ошибок

8% - интерфейсы с аппаратными

компонентами

6% - интерфейсы программных

компонентов

СУБЪЕКТЫ ФОРМИРОВНИЯ ТРЕБОВАНИЙ

пользователи представители

бизнеса

разработчики консультанты

Требования к

программному

продукту

ОСНОВНЫЕ ФАКТОРЫ ВОЗНИКОНОВАНИЯ

ДЕФЕКТОВ В СПЕЦИФИКАЦИЯХ

Неоднозначности

в формулировках

Пропуски существенных

особенностей объекта

управления

Дефекты

в спецификации

Вносимые

изменения

Высказывания

заказчика

Неадекватные

исследования

Неправильные

вопросы заказчику

Устаревшая

информация

пользователей

Некорректности

ПИРАМИДА ТРЕБОВАНИЙ

К ПРОГРАММНОМУ ПРОДУКТУ

Определение

продукта

на основе анализа желаний

заказчика

Формирование системных требований

к программному продукту

Формирование требований к компонентам

программной системы

ПРОБЛЕМЫ ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ И

ОБУСЛАВЛИВАЮЩИЕ ИХ РИСКИ

1) Проблема масштаба: в требованиях может содержаться

слишком мало или слишком много информации

- границы системы определены ошибочно

- может быть приведена информация, бесполезная с точки зрения

проектирования системы

2) Проблема одинакового понимания содержания требований как

внутри одной группы правообладателей, так и разными

группами правообладателей

- пользователи не до конца понимают свои потребности

- заказчик плохо понимает ограничения, связанные с обработкой

информации

- разработчики (аналитики) имеют поверхностное представление

о предметной области

- разработчики (аналитики), заказчики и пользователи

«разговаривают на разных языках»

ПРОБЛЕМЫ ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ И

ОБУСЛАВЛИВАЮЩИЕ ИХ РИСКИ (продолжение)

- конфликтующие точки зрения у разных представителей

заказчика и пользователей

- формулировки требований допускают неоднозначное

толкование

- выполнение требований невозможно проверить (например, в

требованиях присутствуют формулировки типа

«…дружественное по отношению пользователям…»,

«…устойчивые…» и т.п.)

3) Проблемы изменчивости: изменения состава и содержания

требований во времени

- требования изменяются во времени, что обусловлено как

все более глубоким пониманием проблемы, так и

изменением ценностей и предпочтений

заказчика/пользователей

ТИПЫ ТРЕБОВАНИЙ

A ) Требования заказчика/покупателя

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

С ) Требования к преобразованиям (качеству)

D ) Требования к проектированию и

конструированию

E ) Наследуемые требования

F) Требования распределения

ОСНОВНЫЕ ЦЕЛИ АНАЛИЗА ТРЕБОВАНИЙ

Анализ требований должен дать четкое

понимание следующего:

1) ожидаемая функциональность: что система

должна делать;

2) ожидаемые характеристики качества:

насколько хорошо и при каких затратах будут

реализовываться функции;

3) интерфейсы: взаимодействие с окружающей

средой;

4) специфика проекта: требования и ограничения,

обусловленные особенностями проекта.

ОСНОВНЫЕ ВОПРОСЫ

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

• Каковы причины создания системы?

• В чем состоят ожидания заказчика?

• Кто является пользователем системы и как они намереваются ее использовать?

• Что пользователь ожидает получить от системы?

• С каких позиций пользователь будет оценивать систему?

• В какой окружающей среде будет использоваться система?

• Каковы существующие и планируемые внешние интерфейсы?

• Какие функции, в терминах заказчика, должна реализовывать система?

• Какие ограничения (аппаратные, программные, экономические, процедурные) накладываются на систему?

• Какова форма ожидаемого результата: модель; прототип программного продукта; «коробочный» программный продукт?

А)Корректность. Требования являются корректными, если все они относятся лишь к разрабатываемому программному обеспечению;

Б) Однозначность. Требования являются однозначными в том, и только в том случае, если каждое требование интерпретируется однозначно. Как минимум, для этого требуется, чтобы каждая характеристика конечного продукта была описана с использованием одного уникального термина;

В) Полнота. Требования являются полными, если только:

В.1) каждое из требований может быть отнесено к одному из следующих классов: описание функциональности; операционные (динамические) характеристики; проектные ограничения; внешние интерфейсы;

В.2)перечислены все ограничения, определяемые вышестоящей системой. Указано, на какие характеристики программного продукта они влияют;

В.3) определены все классы входных данных; перечислены все возможные состояния программного продукта; определены реакции ПП на входные данные (как правильные, так и неправильные) при нахождении системы в различных состояниях;

ПРИЗНАКИ «ХОРОШИХ»

СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ

В.4)пронумерованы все рисунки, таблицы и диаграммы в спецификации. На все графические и табличные данные имеются ссылки в тексте спецификации;

В.5)дано описание содержания всех терминов, указаны единицы измерения все параметров

В.6) отсутствуют фразы «будет определено дополнительно». Если все же этого избежать не удается, то следует:

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

б) описать действия, направленные на уменьшение неопределенности; определить, к какому моменту разработки неопределенность должна быть устранена;

Г) Совместимость, непротиворечивость.

Г.1) Совместимость внутренняя означает, что никакие группы требований не конфликтуют между собою. Причинами конфликтов могут являться:

ПРИЗНАКИ «ХОРОШИХ»

СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)

а) разные способы описания атрибутов объектов реального мира.

Например, в одном требовании формат выходного требования

определен как табличный, а в другом (того же отчета) – как

текстовый;

б) логический либо временной конфликт между описываемыми

действиями. Например, одно требование утверждает, что «А»

появится после «В», в то время как другое требование

утверждает, что они появятся одновременно;

в) разные требования описывают одни и те же объекты

реального мира, но используют при описании разную

терминологию. Например, в одном требовании указано, чтобы

подсказка обозначалась как «prompt», а в другом - как «cue».

Выходом из этой ситуации является стандартизация

терминологии;

Г.2) Совместимость внутренняя означает, что содержание

спецификации требований не противоречит содержанию документов,

относящихся к вышестоящей системе;

ПРИЗНАКИ «ХОРОШИХ»

СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)

Д) Ранжирование по важности/возможности внесения изменений.

Каждому требованию в спецификации должен быть поставлен в

соответствие признак, однозначно характеризующий важность

требования/оценку возможности внесения в него изменений.

Е) Верифицируемость. Требование верифицируемо в том и только том

случае, если существует конечный, приемлемый по затратам процесс,

посредством которого человек, либо машина могут убедиться в том, что

программный продукт соответствует требованию. Как правило

требования, в которых присутствуют двусмысленности, не являются

верифицируемыми;

Ж) Модифицируемость. Требование является

модифицируемым в том и только том случае, если его структура и

содержание могут быть изменены легко, в нужном объеме, без

нарушения согласованности с другими требованиями.

З) Трассируемость. Требования являются трассируемыми, если выявлены

источники каждого требования, установлены и задокументированы

ссылки между разными требованиями.

ПРИЗНАКИ «ХОРОШИХ»

СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)

НЕКОТОРЫЕ ИЗ СПОСОБОВ

ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ

Способы

извлечения

требований

Интервьюи-

рование

Командный

подход (JAD)

Исследование

точек зрения

разных

правообладателей

(CORE)

Макеты

Неструктурированность

вопросов и ответов

Большие

трудозатраты

• Обеспечение соответствия тем

обсуждения, представленных

разными участниками;

• Неоднозначность выбора

структуры процесса

формирования требований

• Ориентация на малые и средние проекты.

Недостаточная формализация сбора

требований;

• Слабо ориентировано на изучение

динамических характеристик требований;

• Слабо ориентирован на выделение

«типовых» (часто встречающихся)

требований;

• Представляет ограниченные средства для

осуществления верификации;

• Ограниченные возможности вовлечения

конечных пользователей в формирование

требований.

*JAD – Joint Application Development

CORE – Controlled Requirements Expression

Благодарим за внимание

Владимир Ефимович Гвоздев, д.т.н., профессор

Заведующий кафедрой Автоматизации проектирования информационных систем УГАТУ

e-mail: wega55@mail.ru

Вопросы & Ответы

www.pmi.ru ufa@pmi.ru