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

1. Открытый семинар
Управление ИТ-проектами:
Определение требований к
программному продукту
Гвоздев В.Е., д.т.н., профессор
1 марта 2012 г.

2. Институт Управления Проектами
Project Management Institute
Ведущая некоммерческая профессиональная ассоциация с 1969 г.
 Управление проектами – обязательное условие достижения результата
 Более 480 000 профессионалов в 185 странах
 Универсальная методика для всех отраслей
 Свод методических знаний (стандарт РМВОК® и др.)
 Обучение и сертификация
 Исследования и обмен опытом
Московское отделение PMI с 1998 г.
 Более 500 членов
 Филиалы в Екатеринбурге, Перми, Уфе и Челябинске
Филиал МО PMI в Уфе c 2010 г.
 Продвижение технологий Управления проектами
 Обмен опытом
 Изучение международного опыта
 Обучение
2

3. Международные стандарты PMI
ПЕРЕВЕДЕНО
НА РУСС.ЯЗ.
ПЕРЕВЕДЕНО
НА РУСС.ЯЗ.
3

4. Международные стандарты PMI
1. Руководство к Своду знаний по управлению проектами
(Руководство РМВОК), 4-е изд. на русском языке
2. Дополнение к РМВОК по управлению проектами в
государственном секторе, 3-е изд.
3. Дополнение к РМВОК по управлению проектами в строительстве,
2-е изд.
4. Стандарт Управление программами, 2-е изд.
5. Стандарт Управление портфелем, 2-е изд.
6. Практический стандарт по планированию расписания, 2-е изд.
7. Практический стандарт по управлению конфигурацией проекта
8. Практический стандарт по управлению выполненной стоимостью
9. Практический стандарт по декомпозиции структуры проектной
работы
10. Практический стандарт по управлению рисками проекта
11. Развитие компетенции менеджера проектов, 2-е изд.
12. Модель зрелости управления проектами в организации (ОРМ3),
2-е изд.
4

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
5

6. Сертификационные программы PMI
• PMP® (Project Management Professional – Профессионал в области
управления проектами)
Программа рассчитана на менеджеров проектов, имеющих значительный
опыт в управлении проектами
Наиболее популярный сертификат менеджера проектов,
в мире насчитывается более 300 000 сертифицированных PMP
 Вариант 1: Высшее образование И 4500+ часов работы (3 года)
И 35+ часов обучения в области управления проектами
 Вариант 2: Полное среднее образование И 7500+ часов работы (5 лет)
И 35+ часов обучения в области управления проектами
 Свидетельство об образовании, Форма подтверждения опыта И обучения
в области УП
 200 вопросов за 4 часа (знание РМВОК и практические навыки УП)
 Язык: английский, русский
6

7. Другие сертификационные программы PMI
 CAPM® (Certified Associate in Project Management)
Программа базового уровня знаний
 PgMP® (Program Management Professional)
Программа для специалистов по управлению программами
 PMI-SP® (Scheduling Professional)
Программа для специалистов по календарному планированию проектов
 PMI-RMP® (Risk Management Professional)
Программа для специалистов по управлению рисками
7

8. 1
Источник:
Steve McConnell
Software Project
Survival Guide
Microsoft Press
Самой трудной частью сбора требований
является не запись пожеланий пользователей, а
исследовательская деятельность, направленная
на помощь пользователям в определении своих
желаний

9. КОНУС НЕОПРЕДЕЛЕННОСТИ
ПРОГРАММНОГО ПРОДУКТА
4х
Точность оценки стоимости и времени
2х
х
0,5х
0,25х
Анализ Проектирование Реализация Интеграция Функционирование
требований системы и внедрение и сопровождение

10. ТИПЫ ДЕФЕКТОВ И ОШИБОК ПРОЕКТОВ
ПРОГРАММНЫХ СРЕДСТВ
Организационные дефекты проекта
Ошибки оценки характеристик системы и внешней среды
Ошибки вследствие сложности проекта
Ошибки вследствие большого масштаба проекта
Ошибки корректности требований и планирования проекта
Ошибки проектирования и структуры программного средства
Системные ошибки программного средства
Алгоритмические ошибки программного средства
Ошибки реализации спецификаций программных
компонентов
Ошибки в документации программного
средства
Программные ошибки
компонентов
Технологические ошибки
ввода и отображение данных
Риск и опасность последствий ошибок

11. ТИПИЧНАЯ СХЕМА РАСПРЕДЕЛЕНИЯ ДЕФЕКТОВ
В ПРОГРАММНОМ ПРОДУКТЕ
20% - логические
11% - обработки данных
7% - стандарты
25% - спецификации (в том
числе требований)
12% - пользовательские
интерфейсы
11% - контроль ошибок
8% - интерфейсы с аппаратными
компонентами
6% - интерфейсы программных
компонентов

12. СУБЪЕКТЫ ФОРМИРОВНИЯ ТРЕБОВАНИЙ
представители пользователи
бизнеса
Требования к
программному
продукту
разработчики консультанты

13. ОСНОВНЫЕ ФАКТОРЫ ВОЗНИКОНОВАНИЯ
ДЕФЕКТОВ В СПЕЦИФИКАЦИЯХ
Пропуски существенных Неоднозначности
особенностей объекта в формулировках
управления
Дефекты
в спецификации
Неправильные
вопросы заказчику
Высказывания
заказчика
Неадекватные
исследования
Устаревшая
информация
пользователей
Вносимые
Некорректности
изменения

14. ПИРАМИДА ТРЕБОВАНИЙ
К ПРОГРАММНОМУ ПРОДУКТУ
Определение
продукта
на основе анализа желаний
заказчика
Формирование системных требований
к программному продукту
Формирование требований к компонентам
программной системы

15. ПРОБЛЕМЫ ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ И
ОБУСЛАВЛИВАЮЩИЕ ИХ РИСКИ
1) Проблема масштаба: в требованиях может содержаться
слишком мало или слишком много информации
- границы системы определены ошибочно
- может быть приведена информация, бесполезная с точки зрения
проектирования системы
2) Проблема одинакового понимания содержания требований как
внутри одной группы правообладателей, так и разными
группами правообладателей
- пользователи не до конца понимают свои потребности
- заказчик плохо понимает ограничения, связанные с обработкой
информации
- разработчики (аналитики) имеют поверхностное представление
о предметной области
- разработчики (аналитики), заказчики и пользователи
«разговаривают на разных языках»

16. ПРОБЛЕМЫ ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ И
ОБУСЛАВЛИВАЮЩИЕ ИХ РИСКИ (продолжение)
- конфликтующие точки зрения у разных представителей
заказчика и пользователей
- формулировки требований допускают неоднозначное
толкование
- выполнение требований невозможно проверить (например, в
требованиях присутствуют формулировки типа
«…дружественное по отношению пользователям…»,
«…устойчивые…» и т.п.)
3) Проблемы изменчивости: изменения состава и содержания
требований во времени
- требования изменяются во времени, что обусловлено как
все более глубоким пониманием проблемы, так и
изменением ценностей и предпочтений
заказчика/пользователей

17. ТИПЫ ТРЕБОВАНИЙ
A ) Требования заказчика/покупателя
B ) Функциональные требования
С ) Требования к преобразованиям (качеству)
D ) Требования к проектированию и
конструированию
E ) Наследуемые требования
F) Требования распределения

18. ОСНОВНЫЕ ЦЕЛИ АНАЛИЗА ТРЕБОВАНИЙ
Анализ требований должен дать четкое
понимание следующего:
1) ожидаемая функциональность: что система
должна делать;
2) ожидаемые характеристики качества:
насколько хорошо и при каких затратах будут
реализовываться функции;
3) интерфейсы: взаимодействие с окружающей
средой;
4) специфика проекта: требования и ограничения,
обусловленные особенностями проекта.

19. ОСНОВНЫЕ ВОПРОСЫ
АНАЛИЗА ТРЕБОВАНИЙ
• Каковы причины создания системы?
• В чем состоят ожидания заказчика?
• Кто является пользователем системы и как они намереваются
ее использовать?
• Что пользователь ожидает получить от системы?
• С каких позиций пользователь будет оценивать систему?
• В какой окружающей среде будет использоваться система?
• Каковы существующие и планируемые внешние интерфейсы?
• Какие функции, в терминах заказчика, должна реализовывать
система?
• Какие ограничения (аппаратные, программные, экономические,
процедурные) накладываются на систему?
• Какова форма ожидаемого результата: модель; прототип
программного продукта; «коробочный» программный продукт?

20. ПРИЗНАКИ «ХОРОШИХ»
СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ
А)Корректность. Требования являются корректными, если все они
относятся лишь к разрабатываемому программному обеспечению;
Б) Однозначность. Требования являются однозначными в том, и
только в том случае, если каждое требование интерпретируется
однозначно. Как минимум, для этого требуется, чтобы каждая
характеристика конечного продукта была описана с использованием
одного уникального термина;
В) Полнота. Требования являются полными, если только:
В.1) каждое из требований может быть отнесено к одному из
следующих классов: описание функциональности; операционные
(динамические) характеристики; проектные ограничения; внешние
интерфейсы;
В.2)перечислены все ограничения, определяемые вышестоящей
системой. Указано, на какие характеристики программного продукта
они влияют;
В.3) определены все классы входных данных; перечислены все
возможные состояния программного продукта; определены реакции
ПП на входные данные (как правильные, так и неправильные) при
нахождении системы в различных состояниях;

21. ПРИЗНАКИ «ХОРОШИХ»
СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)
В.4)пронумерованы все рисунки, таблицы и диаграммы в
спецификации. На все графические и табличные данные имеются
ссылки в тексте спецификации;
В.5)дано описание содержания всех терминов, указаны единицы
измерения все параметров
В.6) отсутствуют фразы «будет определено дополнительно». Если
все же этого избежать не удается, то следует:
а) привести описание причин, по которым описание не может быть
получено в момент составления спецификаций с тем, чтобы было
ясно, когда оно появится в дальнейшем;
б) описать действия, направленные на уменьшение
неопределенности; определить, к какому моменту разработки
неопределенность должна быть устранена;
Г) Совместимость, непротиворечивость.
Г.1) Совместимость внутренняя означает, что никакие группы
требований не конфликтуют между собою. Причинами конфликтов
могут являться:

22. ПРИЗНАКИ «ХОРОШИХ»
СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)
а) разные способы описания атрибутов объектов реального мира.
Например, в одном требовании формат выходного требования
определен как табличный, а в другом (того же отчета) – как
текстовый;
б) логический либо временной конфликт между описываемыми
действиями. Например, одно требование утверждает, что «А»
появится после «В», в то время как другое требование
утверждает, что они появятся одновременно;
в) разные требования описывают одни и те же объекты
реального мира, но используют при описании разную
терминологию. Например, в одном требовании указано, чтобы
подсказка обозначалась как «prompt», а в другом - как «cue».
Выходом из этой ситуации является стандартизация
терминологии;
Г.2) Совместимость внутренняя означает, что содержание
спецификации требований не противоречит содержанию документов,
относящихся к вышестоящей системе;

23. ПРИЗНАКИ «ХОРОШИХ»
СПЕЦИФИКАЦИЙ ТРЕБОВАНИЙ (продолжение)
Д) Ранжирование по важности/возможности внесения изменений.
Каждому требованию в спецификации должен быть поставлен в
соответствие признак, однозначно характеризующий важность
требования/оценку возможности внесения в него изменений.
Е) Верифицируемость. Требование верифицируемо в том и только том
случае, если существует конечный, приемлемый по затратам процесс,
посредством которого человек, либо машина могут убедиться в том, что
программный продукт соответствует требованию. Как правило
требования, в которых присутствуют двусмысленности, не являются
верифицируемыми;
Ж) Модифицируемость. Требование является
модифицируемым в том и только том случае, если его структура и
содержание могут быть изменены легко, в нужном объеме, без
нарушения согласованности с другими требованиями.
З) Трассируемость. Требования являются трассируемыми, если выявлены
источники каждого требования, установлены и задокументированы
ссылки между разными требованиями.

24. НЕКОТОРЫЕ ИЗ СПОСОБОВ
ИЗВЛЕЧЕНИЯ ТРЕБОВАНИЙ
Исследование
Интервьюи- Способы точек зрения
рование извлечения разных
требований правообладателей
Неструктурированность (CORE)
вопросов и ответов
• Ориентация на малые и средние проекты.
Недостаточная формализация сбора
Командный требований;
подход (JAD) • Слабо ориентировано на изучение
Макеты
динамических характеристик требований;
• Обеспечение соответствия тем • Слабо ориентирован на выделение
Большие «типовых» (часто встречающихся)
трудозатраты обсуждения, представленных
разными участниками; требований;
• Неоднозначность выбора • Представляет ограниченные средства для
структуры процесса осуществления верификации;
формирования требований • Ограниченные возможности вовлечения
конечных пользователей в формирование
требований.
*JAD – Joint Application Development
CORE – Controlled Requirements Expression

25. Вопросы & Ответы
Благодарим за внимание
www.pmi.ru
ufa@pmi.ru
Владимир Ефимович Гвоздев, д.т.н., профессор
Заведующий кафедрой Автоматизации проектирования информационных
систем УГАТУ
e-mail: wega55@mail.ru