«Лекции по управлению программными проектами 2009 Содержание Стоимость Время МОСКВА 2009 МОСКВА С. Архипенков Лекции по управлению программными проектами Москва 2009 1 Содержание Отзыв на книгу Об авторе Благодарности ...»

6.2. Заказчик – начальник Отдела «123» Ф.Федотов 6.3. Пользователи автоматизированной системы:

6.4. Клиенты ОАО «XYZ» (поиск и заказ документации).

6.5. Руководство ОАО «XYZ» (анализ деятельности Отдела «123»).

6.6. Сотрудники производственных департаментов ОАО «XYZ» (сопровождение 6.7. Сотрудники Отдела «123» (обработка заявок и поставка документации).

6.8. Сотрудники департамента информатизации ОАО «XYZ» (администрирование 6.9. Куратор проекта - начальник отдела заказных разработок И.Иванов.

6.10. Руководитель проекта - ведущий специалист отдела заказных разработок МП 7. Соисполнители:

7.1. Поставщик оборудования и операционно-системного ПО - ООО «Альфа».

7.2. Поставщик базового ПО - ООО «Бета».

Ресурсы Для того чтобы понять, сколько будет стоить реализация программного проекта, требуется определить и оценить ресурсы необходимые для его выполнения:

Людские ресурсы и требования к квалификации персонала.

Оборудование, услуги, расходные материалы, лицензии на ПО, Бюджет проекта. План расходов и, при необходимости, предполагаемых доходов проекта с разбивкой по статьям и фазам/этапам проекта.

Специфика программного проекта заключается в том, что людские ресурсы вносят основной вклад в его стоимость. Все остальные затраты, как правило, незначительны, по сравнению с этим расходами. О том, как следует подходить к оценкам трудозатрат на реализацию проекта разработки ПО, мы будем подробно говорить в следующих лекциях. На фазе инициации хорошей считается оценка трудозатрат с точностью от -50% до +100% [2].

Необходимо помнить, что помимо непосредственно программирования в проекте разработки ПО есть много других процессов, которые требуют ресурсы соответствующей квалификации, а само программирование составляет лишь четверть всех затрат. Распределение трудозатрат по основным производственным процессам при современном процессе разработки ПО выглядит в среднем следующим образом – Рисунок 14.Распределение трудозатрат по основным производственным процессам при Поэтому, если по вашей оценки для реализации требуемой функциональности в проекте необходимо написать 10 KSLOC (тысяч строк исходного программного кода), а ваши программисты пишут в среднем по 100 SLOC в день, то общие трудозатраты на проект будут не 100 чел.*дней, а не менее чем 400 чел.*дней.

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

Прежде, чем определять численность и состав проектной команды для нашего примера, нам необходимо сделать оценку трудоемкости разработки ПО. В нашем случае такая экспертная оценка составила с учетом затрат на гарантийное сопровождение на этапе опытной эксплуатации 9000 чел.*час.

Исходя из эмпирической кривой Б. Боэма (Рисунок 15), численность команды, близкая к оптимальной, составила 10 человек, из них 8. Ресурсы проекта 8.1. Требования к персоналу 8.1.1. 1 - руководитель проекта, 8.1.2. 1 - технический лидер (архитектура, проектирование), 8.1.3. 1 - системный аналитик (требования, тест-дизайн, документирование), 8.1.4. 4 - программисты (с учетом работ по конфигурационному управлению), 8.1.5. 3 - тестировщика.

8.2. Материальные и другие ресурсы 8.2.1. Сервер управления конфигурациями и поддержки системы контроля версий 8.2.2. 2 серверных комплекса (для разработки и тестирования):

8.2.3. Сервер приложений с установленным BEA Weblogic AS 8.2.4. Сервер оперативной БД с установленной Oracle RDBMS 8.2.5. Сервер каталога с установленной OODB “Poet” 8.3. Лицензии на средства разработки и тестирования:

8.3.1. Oracle Designer – 1 лицензия 8.3.2. Symantec Visual Cafe for Java - 5 лицензий.

8.3.3. IBM Rational Test Robot (1 лицензия разработчика + неограниченная лицензия 8.4. Расходная часть бюджета проекта 8.4.1. Разработка и сопровождение прикладного ПО:

8.4.2. Поставка оборудования и операционно-системного ПО:

8.4.3. Поставка базового ПО:

Сроки Ф. Брукс [3] писал: «Чтобы родить ребенка требуется девять месяцев независимо от того, сколько женщин привлечено к решению данной задачи.

Многие задачи программирования относятся к этому типу, поскольку отладка по своей сути носит последовательный характер».

Там же Брукс приводит исключительно полезную, но почему-то редко применяемую, эмпирическую формулу оценки срока проекта по его трудоемкости. Формула была выведена Барии Боэмом (Barry Boehm) на основе Мы в данном разделе оцениваем себестоимость проекта. Определение продажной цены проекта не анализа результатов 63 проектов разработки ПО, в основном в аэрокосмической области. Согласно этой формуле, для проекта, общая трудоемкость которого составляет N ч.*м. (человеко-месяцев), пожно утверждать что:

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

Для сколь-нибудь серьезного программного проекта недостаточно определить контрольные точки, в которых будет происходить переоценка проекта на основе отмечающее достижение заданного результата и/или начало / завершение определенного объема работы. Каждая контрольная точка характеризуется Как мы говорили ранее, современный проект разработки ПО должен реализовываться с применением инкрементального процесса. В этом случае контрольные точки должны соответствовать выпуску каждой промежуточной версии ПО, в которой будет реализована и протестирована определенная часть конечной функциональности программного продукта. В зависимости от сложности и масштаба проекта продолжительность одной итерации может Соответствующий раздел концепции нашего проекта-примера будет иметь 9. Сроки проекта 9.1. 03.03 старт 9.2. 28.11 завершение 9.3. Контрольные точки:

9.3.1. 15.04 ТЗ утверждено 9.3.2. 30.04 1-я итерация завершена. Подсистема заказа документации передана в тестовую эксплуатацию (на серверах разработчика).

9.3.3. 15.05 Монтаж оборудования у заказчика завершен.

9.3.4. 30.05 Базовое ПО установлено у заказчика.

9.3.5. 15.06 2-я итерация завершена. Подсистема обработки заказов передана в тестовую эксплуатацию на оборудовании Заказчика 9.3.6. 02.09 3-я итерация завершена. Акт передачи системы в опытную 9.3.7. 28.11 Система передана в промышленную эксплуатацию.

Риски отрицательно или положительно сказывается на целях проекта [1].

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

На этапе инициации, когда нет необходимых данных для проведения детального анализа, часто приходится ограничиваться качественной оценкой общего уровня рисков: низкий, средний, высокий.

В случае нашего проекта-примера раздел «риски» будет выглядеть следующим 10. Риски проекта 10.1. Задачи системы поняты недостаточно полно. Понимание масштаба и рамок проекта недостаточно. Системы создаются на новой технологической платформе, сомнения в рыночной стабильности платформы. Суммарный уровень рисков следует оценить выше среднего.

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

В рассматриваемом примере раздел «Критерии приемки» будет выглядеть 11. Критерии приемки. По итогам опытной эксплуатации система должна продемонстрировать следующие показатели:

11.1. Средние затраты сотрудников Отдела «123» на регламентную обработку одного заказа не превышают 4 чел.*час.

11.2. Срок регламентной обработки 1-го заказа не более 2 недель.

11.3. Время поиска и предоставления информации о наличии дополнительной документации не более 1 мин.

11.4. Время предоставления информации о сделанных заказах и истории их обработки 11.5. Система хранит всю информацию о сделанных заказах и истории их обработки.

11.6. Показатель доступности системы 98%.

Обоснование полезности проекта Этот раздел концепции должен содержать краткое технико-экономическое Описание текущей ситуации «As Is». Какие у потенциального заказчика Каким образом результаты проекта решают эти проблемы («To Be»).

Насколько значимо для клиента решение данных проблем (оценка Какие преимущества в итоге из этого может извлечь компанияисполнитель проекта.

12. Обоснование полезности проекта 12.1. Для Заказчика:

12.1.1. Повышение производительности обработки заказов в 2 раза.

12.1.2. Повышение оперативности контроля 12.1.3. Повышение удовлетворенности клиентов:

Сокращение времени на поиск необходимой документации в 10 раз Повышение оперативности обновления каталога 10 раз.

12.2. Для компании-исполнителя:

12.2.1. Высокая стратегическая ценность. Дает устойчивое увеличение рынка и 12.2.2. Финансовая ценность выше среднего. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы.

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

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

Дополнительная литература и источники «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

Брукс Фредерик, «Мифический человеко-месяц, или Как создаются программные комплексы», Пер. с англ., СПб., Символ-Плюс, 1999.

Лекция 4. Планирование проекта Уточнение содержания и состава работ «Если не получается проглотить слона целиком, то его надо порезать на отбивные». Человечество пока не придумало ничего более эффективного для решения сложной задачи, чем анализ и ее декомпозиция на боле простые подзадачи, которые, в свою очередь, могут быть разделены на еще боле простые подзадачи и так далее. Получается некоторая иерархическая структура, дерево, в корне которого находится проект, а на листьях элементарные задачи или работы, которые надо выполнить, чтобы завершить проект в условиях заданных ограничений. Согласно [1]:

Иерархическая структура работ (ИСР) (Work Breakdown Structure, WBS) ориентированная на результат иерархическая декомпозиция работ, выполняемых командой проекта для достижения целей проекта и необходимых результатов. С ее помощью структурируется и определяется все содержание проекта. Каждый следующий уровень иерархии отражает более детальное определение элементов проекта.

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

ИСР делит проект на подпроекты, пакеты работ, подпакеты. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку сроков и объемов работ. ИСР должна включать все промежуточные и конечные продукты.

Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы:

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход не эффективен. Как мы уже говорили, современный процесс разработки коммерческого ПО должен быть инкрементальным. Это означает, что на верхнем уровне декомпозиции нашего проекта должны находиться продукты проекта, а на следующем уровне - компоненты, из которых эти продукты состоят. Компоненты далее могут быть декомпозированы на «фичи» функции, которые они должны реализовывать.

Выделение компонентов, составляющих программный продукт, это элемент высокоуровневого проектирования, которое мы должны выполнить на фазе планирования проекта, не дожидаясь проработки всех функциональных требований к разрабатываемому ПО. Компонентами могут быть как прикладные подсистемы, так и инфраструктурные или ядерные, например, подсистема логирования, безопасности, библиотека визуальных компонентов GUI.

При составлении базового плана работ не стоит стремиться максимально детализировать все работы. ИСР не должна содержать слишком много уровней, достаточно 3-5. Например, ИСР нашего проекта-примера разработки «Автоматизированной системы продажи документации» может выглядеть следующим образом (Рисунок 17).

1. Проект разработки «Автоматизированной системы продажи документации»

1.1. Подготовка технического задания на автоматизацию 1.1.1.1. Проведение аналитического обследования 1.1.1.2. Разработка функциональных требований 1.1.1.3. Разработка требований базовому ПО 1.1.1.4. Разработка требований к оборудованию и к операционносистемному ПО 1.1.1.5. Согласование и утверждение ТЗ 1.2. Поставка и монтаж оборудования 1.2.1.Разработка спецификации на оборудование 1.2.2.Закупка и поставка оборудования 1.2.3.Монтаж оборудования 1.2.4.Установка и настройка опреационно-системного ПО 1.2.5.Монтаж оборудования завершен 1.3. Поставка и установка базового ПО 1.3.1.Разработка спецификаций на базовое ПО 1.3.2.Закупка базового ПО 1.3.3.Развертывание и настройка базового ПО 1.3.4.Базовое ПО установлено у заказчика 1.4. Разработка и тестирование прикладного ПО 1.4.1.Разработка спецификаций на прикладное ПО 1.4.2.Установка и конфигурирование рабочей среды 1.4.3.Проектирование и разработка ПО 1.4.3.1. Авторизация и аутентификация пользователей.

1.4.3.2. Разработка подсистемы заказа документации 1.4.3.2.4. Просмотр информации о статусе заказа.

1.4.3.2.5. Информирование клиента об изменении статуса заказа.

1.4.3.2.6. Подсистема заказа документации передана в 1.4.3.3. Разработка подсистемы обработки заказов 1.4.3.3.1. Просмотр и обработка заказов исполнителями из службы 1.4.3.3.2. Просмотр статистики поступления и обработки заказов за 1.4.3.3.3. Подсистема обработки заказов передана в тестовую 1.4.3.4. Разработка подсистемы сопровождения каталога 1.4.3.4.1. Подготовка и сопровождение каталога продукции.

1.4.4.Тестирование ПО 1.4.4.4. Выходное тестирование 1.4.5.Документирование прикладного ПО 1.5. Обучение пользователей 1.5.1.Подготовка учебных курсов 1.5.2.Обучение сотрудников Отдела 1.5.3.Обучение руководства ОАО XYZ 1.5.4.Обучение администраторов системы 1.6. Ввод в опытную эксплуатацию 1.6.1.Развертывание и настройка прикладного ПО 1.6.2.Проведение приемо-сдаточных испытаний 1.6.3.Акт передачи системы в опытную эксплуатацию утвержден 1.7. Сопровождение системы в период опытной эксплуатации 1.8. Система передана в промышленную эксплуатацию Рисунок 17. Иерархическая структура работ проекта разработки «Автоматизированной системы продажи документации» (курсивом выделены контрольные точки проекта) Должна быть установлена персональная ответственность за все части проекта (подпроекты и пакеты работ). Для каждого пакета работ должен быть четко определен результат на выходе. Работы и оценки проекта должны быть согласованы с ключевыми участниками команды, руководством компанииисполнителя и, при необходимости, с заказчиком. В результате согласования члены команды принимают на себя обязательства по реализации проекта, а руководство принимает на себя обязательства по обеспечению проекта необходимыми ресурсами.

ИСР является одним из основных инструментов (средств) в механизме управления проектом, с помощью которого измеряется степень достижения результатов проекта. Важнейшая ее функция это обеспечить консистентное представление всех у частников проекта относительно того, как будет делаться проект. В последующем базовый план будет служить ориентиром для сравнения с текущим исполнением проекта и выявления отклонений для целей Планирование управления содержанием Одна из распространенных «болезней» программных проектов называется «ползучий фичеризм». Это, когда к изначально спроектированной будке для любимой собаки сначала пристраивают сарайчик для хранения садового инвентаря, а потом и домик в несколько этажей для ее хозяина. И все это пытаются построить на одном и том же фундаменте и из тех же самых материалов. Эта болезнь стала причиной летального исхода многих проектов Поэтому, сразу, как только удалось стабилизировать и согласовать ИСР, необходимо разработать план управления содержанием проекта. Для этого Определить источники запросов на изменение.

Определить порядок документирования изменений содержания.

Определить порядок информирования об изменении содержания.

Первая задача, которую необходимо решить при анализе запроса на изменения - выявить объекты изменений: требования, архитектура, структуры данных, исходные коды, сценарии тестирования, пользовательская документация, проч.

Затем требуется спроектировать и детально описать изменения во всех выявленных объектах. И наконец, следует оценить затраты на внесение изменений, тестирование изменений и регрессионное тестирование продукта и их влияние на сроки проекта.

Эта работа, которая потребует затрат рабочего времени и порой значительных разных специалистов: аналитиков, проектировщиков, разработчиков, тестировщиков, наконец, менеджера проекта. Поэтому эта работа должна обязательно быть учтена в плане.

Планирование организационной структуры Организационная структура это согласованное и утвержденное распределение ролей, обязанностей и целей деятельности ключевых участников проекта. Она в обязательном порядке должна включать в себя систему рабочих взаимоотношений между рабочими группами проекта, систему отчетности, оценки хода выполнения проекта и систему принятия решений. Следует помнить, что организационная структура проекта – «живой» организм. Она начинает складываться на стадии планирования и должна меняться по ходу И еще. Нестабильность организационной структуры – частая смена исполнителей - может стать серьезной проблемой в управлении проектом, поскольку, существует цена замены, которая определяется временем вхождения нового участника в контекст проекта.

Планирование управления конфигурациям Конфигурационное управление один из важных процессов производства программного обеспечения. Об этой области знаний написана не одна книга.

Мы будем говорить только о том, что эта работа должна быть спланирована.

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

Эти работы, как правило, выполняет один человек – инженер по конфигурациям. Если проект небольшой, то эта роль может быть дополнительной для одного из программистов. Я как-то видел, что эту роль выполнял менеджер проекта. «Размазывать» эту работу на всех участников проекта, во-первых, неэффективно. Установка и конфигурирование среды разработки, например, баз данных и серверов приложений, требует определенных компетенций и знаний особенностей конкретных версий продуктов. Если эти навыки придется осваивать всем разработчикам, то на это уйдет слишком много рабочего времени. Во-вторых, «размазывание» работ по безответственности, когда никто не знает, от чего не собирается проект и как откатиться к консистентной версии.

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

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

План управления качеством должен включать в себя следующие работы:

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

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

Эти вопросы будут рассмотрены далее в специальных лекциях.

Базовое расписание проекта После определения трудоемкости работ необходимо определить график их выполнения и общие сроки реализации проекта – составить расписание работ по проекту. Базовое расписание - утвержденный план-график с указанными временными фазами проекта, контрольными точками и элементами иерархической структуры работ.

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

Базовое расписание это, как правило, элемент контракта с заказчиком.

Контрольные точки (вехи) должны служить точками анализа состояния проекта и принятия решения «GO/NOT GO», поэтому они должны зримо демонстрировать статус проекта. Контрольная точка «Проектирование завершено» - плохо. Наиболее эффективный подход – метод последовательных поставок: контрольная точка «Завершено тестирование требований 1, 3, 5, 7»

Если работы не связаны между собой, то любую из них мы можем начинать и завершать, когда нам удобно. Все работы можно делать параллельно и в этом случае минимальная длительность проекта равна длительности самой долгой работы. Однако, на практике между работами существуют зависимости, которые могут быть «жесткими», например, анализ - проектирование – кодирование – тестирование и документирование конкретной функции; или «нежесткими», которые могут пересматриваться или смягчаться. Например, последовательное выполнение задач конкретным исполнителем (можно перепланировать на другого исполнителя) или разработка базового ПО, которая должна предшествовать разработке прикладного ПО. В этом случае можно создавать «заглушки» эмулирующие работу базового ПО. Таким образом, диаграмма Ганта для расписания проекта выглядит как гамак, составленный из множества цепочек взаимосвязанных работ с единой точкой начала и завершения.

Критический путь проекта (Critical path)– самая длинная цепочка работ в проекте. Увеличение длительности любой работы в этой цепочки приводит к увеличению длительности всего проекта.

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

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

Чтобы проиллюстрировать понятие критического пути рассмотрим пример «суперпроекта». Концепция проекта выглядит следующим образом.

Цель проекта. Сделать завтрак в постель Результаты проекта. Завтрак в постели из вареного яйца, тоста и апельсинового сока.

Ресурсы. Имеется один оператор и обычное кухонное оборудование.

Сроки. Проект начинается на кухне в 8:00 и завершается в спальне.

Критерий приемки. Используются минимальные трудовые ресурсы и срок.

Конечный продукт имеет высокое качество: яйцо свежесваренное, тост теплый, сок холодный.

Обоснование полезности. Проект служит достижению стратегических целей.

Интернет-источник идеи, к сожалению, восстановить не удалось.

Иерархическая структура работ, ориентированная на конечный продукт, с оценкой их длительности представлена на Рисунок 18.

Рисунок 18. Иерархическая структура работ «суперпроекта»

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

С учетом зависимостей мы получим следующую диаграмму расписания нашего проекта (Рисунок 19) Рисунок 19. Диаграмма расписания «суперпроекта» с учетом зависимостей между работами.

В результате мы определили, что минимальный срок реализации нашего проекта составляет 10 минут. Однако мы не можем на этом остановиться, поскольку должны еще учесть ограничение по ресурсам. У нас только один оператор. Если мы посмотрим на диаграмму загруженности ресурсов (Рисунок 20), то увидим, что наш критический ресурс загружен на первой минуте на 400%.

что недопустимо.

Рисунок 20. Диаграма загруженности ресурсов в «суперпроекте»

Следовательно, мы должны выполнить выравнивание ресурсов. Поскольку одним из критериев успеха проекта является его минимальная длительность, то если мы не хотим ее увеличивать, мы должны выявить критический путь в проекте (Рисунок 21) и не сдвигать работы, которые на нем находятся.

Рисунок 21. Критический путь в «суперпроекте»

Поэтому, после выравнивания ресурсов, расписание нашего проекта будет выглядеть следующим образом (Рисунок 22).

Рисунок 22. Расписание «суперпроекта» после выравнивания ресурсов Теперь диаграмма загруженности ресурсов (Рисунок 23) выглядит приемлемо и у оператора даже появилось три минуты свободного времени на перекур. При этом общая длительность реализации проекта по-прежнему составляет минут.

Рисунок 23. Диаграмма загруженности ресурсов после выравнивания Выводы На верхнем уровне ИСР должны находиться не процессы, а продукты проекта, на следующем уровне - компоненты из которых эти продукты состоят.

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

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

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

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

Дополнительная литература и источники «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е Лекция 5. Управление рисками проекта Основные понятия Том Демарко в своей книге [1] пишет: «Проект без риска – удел неудачников.

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

Риск это проблема, которая еще не возникла, а проблема – это риск, который материализовался. Риск характеризуется следующими характеристиками [2] Причина или источник. Явление, обстоятельство обусловливающее Симптомы риска, указание на то, что событие риска произошло или вотвот произойдет. Первопричина нам может быть не наблюдаема, например, заразились гриппом. Мы наблюдаем некоторые симптомы – Последствия риска. Проблема или возможность, которая может реализоваться в проекте в результате произошедшего риска.

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

Многие риски происходят частично и оказывают соразмерное отрицательное или положительное воздействие на проект.

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

Майк Ньюэлл, вице-президент компании PSM Consulting, рассказывал, как он объясняет аудитории на своих лекциях, что такое риск. Он предлагает сыграть в кости на таких условиях, если на кубике выпадает шестерка, то выигрывает он.

Если - любое другое число, то выигрывает слушатель. Ставка по 1 доллару.

Обычно, большая часть аудитории соглашается сыграть на таких условиях.

Майк поднимает ставки: $10, $100, $1000. Постепенно количество желающих поиграть становится все меньше и меньше. При ставке $1000, как правило, желающих рисковать не остается.

Принято [3] выделять две категории рисков:

«Известные неизвестные». Это те риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия.

идентифицировать и, следовательно, спланировать ответные действия.

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

На расходование этого резерва менеджер проекта, как правило, обязан получать одобрение вышестоящего руководства. Управленческие резервы на непредвиденные обстоятельства не входят в базовый план по стоимости проекта, но включаются в бюджет проекта. Они не распределяются по проекту, как бюджет, и поэтому не учитываются при расчете освоенного объема.

Девиз разработчиков ПО из Microsoft [2]:«Мы не боремся с рисками — мы ими управляем». Цели управления рисками проекта – снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий. Адекватное управление рисками в компании – признак зрелости производственных процессов. Том Демарко пишет [1]: «Рассматривать только благоприятные сценарии и встраивать их в план проекта – настоящее ребячество. И все же мы постоянно так поступаем. …Если тех, кто говорит о возможных проблемах до открытия проекта, называют troublemakers, а тех, кто сдает проект спустя 2 месяца после обещанного срока, работая при этом по 60часов в неделю, – героями, то у вас плохая команда».

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

Планирование управления рисками Управление рисками это определенная деятельность, которая выполняется в проекте от его начала до завершения. Как и любая другая работа в проекте управление рисками требует времени и затрат ресурсов. Поэтому эта работа обязательно должна планироваться. Планирование управления рисками – это процесс определения подходов и планирования операций по управлению рисками проекта. Тщательное и подробное планирование управления рисками позволяет:

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

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

В соответствие с [3] исходными данными для планирования управления рисками служат:

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

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

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

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

План управления рисками обычно включает в себя следующие элементы:

Определение подходов, инструментов и источников данных, которые могут использоваться для управления рисками в данном проекте.

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

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

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

Категории рисков. Структура, на основании которой производится систематическая и всесторонняя идентификация рисков с нужной степенью детализации. Такую структуру можно разработать с помощью составления иерархической структуры рисков (Рисунок 25).

Общие подходы для определения уровней вероятности, шкалы воздействия и близости рисков на проект.

Рисунок 25. Пример иерархической структуры рисков проекта Шкала оценки воздействия отражает значимость риска (Таблица 2) в случае его возникновения. Шкала оценки воздействия может различаться в зависимости от потенциально затронутой риском цели, типа и размера проекта, принятыми в организации стратегиями и его финансовым состоянием, а также от чувствительности организации к конкретному виду воздействий.

Таблица 2. Пример шкалы оценки воздействия рисков Хотя риск может воздействовать и на сроки проекта, и на качество получаемого продукта, но все эти отклонения могут быть оценены в денежном эквиваленте.

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

Похожая шкала может быть применена для оценки вероятности наступления Таблица 3. Пример шкалы оценки вероятности осуществления риска Еще одной важной характеристикой риска является близость его наступления.

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

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

Исходные данные для выявления и описания характеристик рисков могут браться из разных источников.

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

Следует помнить, что проблемы завершенных и выполняемых проектов, это, как правило, риски в новых проектах.

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

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

Для сбора информации о рисках могут применяться различные подходы. Среди этих подходов наиболее распространены:

Карточки Кроуфорда Цель опроса экспертов – идентифицировать и оценить риски путем интервью подходящих квалифицированных специалистов. Специалисты высказывают своё мнение о рисках и дают им оценку, исходя из своих знаний, опыта и имеющейся информации. Этот метод может помочь избежать повторного наступления на одни и те же грабли.

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

К участию в мозговом штурме привлекаются квалифицированные специалисты, которым дают «домашнее задание» - подготовить свои суждения по определенной категории рисков. Затем проводится общее собрание, на котором специалисты по очереди высказывают свои мнения о рисках. Важно: споры и замечания не допускаются. Все риски записываются, группируются по типам и характеристикам, каждому риску дается определение. Цель – составить первичный перечень возможных рисков для последующего отбора и анализа.

Метод Дельфи во многом похож на метод мозгового штурма. Однако есть важные отличия. Во-первых, при применении этого метода эксперты участвуют в опросе анонимно. Поэтому результат характеризуется меньшей субъективностью, меньшей предвзятостью и меньшим влиянием отдельных экспертов. Во-вторых, опрос экспертов проводится в несколько этапов. На каждом этапе модератор рассылает анкеты, собирает и обрабатывает ответы.

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

Для быстрого выявления рисков можно воспользоваться еще одной из методик социометрии является известной как "Карточки Кроуфорда" [5].

Суть этой методики в следующем. Собирается группа экспертов 7-10 человек.

Каждому участнику мини-исследования раздается по десять карточек (для этого вполне подойдет обычная бумага для записок). Ведущий задает вопрос: "Какой риск является наиболее важным в этом проекте?" Все респонденты должны записать наиболее, по их мнению, важный риск в данном проекте. При этом никакого обмена мнениями не должно быть. Ведущий делает небольшую паузу, после чего вопрос повторяется. Участник не может повторять в ответе один и тот же риск.

После того как вопрос прозвучит десять раз, в распоряжении ведущего появятся от 70 до 100 карточек с ответами. Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство значимых для проекта рисков, весьма высока. Остается составить список названных рисков и раздать его участникам для внесения изменений и дополнений.

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

Например, Барии Боэм [6] приводит список 10 наиболее распространенных рисков программного проекта:

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

“Золотая сервировка”, перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

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

Недостаточная производительность получаемой системы.

10. “Разрыв” в квалификации специалистов разных областей знаний.

Демарко и Листер [1] приводят свой список из пяти наиболее важных источников рисков любого проекта разработки ПО:

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

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

Если вернуться к примеру проекта создания «Автоматизированной системы продажи документации», который мы рассматривали в предыдущих лекциях, то список главных выявленных рисков может выглядеть следующим образом:

Таблица 4 Список рисков проекта создания «Автоматизированной системы продажи За процессом идентификации рисков следует процесс их качественного Качественный анализ рисков Качественный анализ рисков включает в себя расстановку рангов для идентифицированных рисков. При анализе вероятности и влияния предполагается, что никаких мер по предупреждению рисков не производится.

Качественный анализ рисков включает:

Определение тяжести последствий реализации рисков.

Определения ранга риска по матрице «вероятность - последствия».

Для качественной оценки вероятности реализации риска и определения тяжести последствий его реализации применяется, как правило, общепринятые в организации шкалы, примеры которых мы приводили ранее.

Для определения ранга риска используется матрица вероятностей и последствий (Рисунок 26). Ранг риска определяется произведением веса вероятности и значимости последствий.

Могут, конечно, существовать и более сложные шкал для оценок вероятностей, значимости последствий и ранга рисков. Встречались шкалы, которые содержали до 10 градаций. Но, на мой взгляд, наиболее прагматичный подход – это использовать трехуровневое ранжирование.

Продолжая рассмотрение примера проекта создания «Автоматизированной системы продажи документации», матрица рангов главных выявленных рисков может выглядеть следующим образом (Таблица 5).

Таблица 5. Матрица рангов главных выявленных рисков проекта создания «Автоматизированной системы продажи документации»

квалифицированных кадров.

Рисунок 26 Ранг риска и матрица вероятностей и последствий Для оценки рисков необходима точная и адекватная информация.

Использование неточной информации ведет к ошибкам в оценке. Неверная оценка риска также является риском.

Критерии оценки качества используемой при анализе информации выглядят следующим образом:

Степень понимания риска.

Доступность и полнота информации о риске.

Надежность, целостность и достоверность источников данных.

Результатом качественного анализа рисков является их подробное описание (Таблица 6).

Таблица 6. Пример карточки с описанием риска квалифицированных кадров. использовать новую платформу J2EE.

Вероятность: Очень вероятно. Степень воздействия:

Исходные данные: «Содержание проекта», «План обеспечения ресурсами», Протоколы совещаний №21 от 01.06.2008, №27 от Результаты качественного анализа используются в ходе последующего количественного анализа рисков и планирования реагирования на риски.

Количественный анализ рисков Количественный анализ производится в отношении тех рисков, которые в процессе качественного анализа были квалифицированы как имеющие высокий Для количественного анализа рисков могут быть использованы следующие Анализ чувствительности помогает определить, какие риски обладают наибольшим потенциальным влиянием на проект. В процессе анализа устанавливается, в какой степени неопределенность каждого элемента проекта отражается на исследуемой цели проекта, если остальные неопределенные элементы принимают базовые значения. Результаты представляются, как правило, в виде диаграммы «торнадо». Рисунок 27 представляет пример такой диаграммы, которая отражает влияние на проектные трудозатраты различных факторов профессионализма разработчиков ПО [7].

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

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

Рисунок 28. Пример анализ дерева решений при выборе покупать или производить необходимую для проекта библиотеку визуальных компонентов (VCL).

При моделировании рисков проекта используется модель для определения последствий от воздействия подробно описанных неопределенностей на результаты проекта в целом. Моделирование обычно проводится с помощью метода Монте-Карло.

Интересный пример подобной модели - система Riskology от Демарко и Листера, который иллюстрирует применение метода Монте-Карло для получения информации о том, какой запас времени будет необходим для того, чтобы преодолеть влияние всех неуправляемых рисков проекта, приведен в источнике [8]. Модель позволяет учесть пять основных (Рисунок 29) и пять дополнительных рисков проекта.

НАЗВАНИЕ

РИСКА ОПИСАНИЕ СТАТУС

Рисунок 29. Пять основных факторов риска программного проекта, учитываемые в модели Характеристики предопределенных в системе Riskology рисков пользователь может изменить, задав значения минимальной, максимальной и наиболее Число прогонов в диапазоне

ОТМЕНЕН

Планирование реагирования на риски Передача риска (risk transference).

Снижение рисков (risk mitigation).

Принятие риска (risk acceptance).

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

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

Снижение рисков предполагает понижение вероятности и/или последствий негативного рискованного события до приемлемых пределов. Принятие предупредительных мер по снижению вероятности наступления риска или его последствий часто оказываются более эффективными, нежели усилия по устранению негативных последствий, предпринимаемые после наступления события риска. Например, раннее разрешение архитектурных рисков снижает потери при досрочном закрытии проекта. Или регулярная ревизия поставок заказчиком может снизить вероятность риска его неудовлетворенности конечным результатом. Если в проектной команде высока вероятность увольнения сотрудников, то введение на начальной стадии в проект дополнительных (избыточных) людских ресурсов снижает потери при увольнении членов команды, поскольку не будет затрат на «въезд» в проектный контекст новых участников.

И, наконец, принятие риска означает, что команда проекта осознанно приняла решение не изменять план управления проектом в связи с риском или не нашла подходящей стратегии реагирования. Мы вынуждены принимать все «неизвестные риски».

Принятие это то, что всегда происходит, когда мы вообще не управляем рисками. Если же мы управляем рисками, то мы можем страховать риски, закладывая резерв в оценки срока завершения и/или трудозатрат. Проактивное отношение к принятым рискам может состоять в разработке план реагирования на риски. Этот план может быть введен в действие только при заранее определенных условиях, если есть уверенность и достаточное количество признаков того, что данный план будет успешно выполнен.

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

Главные риски программных проектов и способы реагирования Мой список из пяти главных причин провала программных проектов следующий:

Требования заказчика отсутствуют / не полны / подвержены частым Отсутствие необходимых ресурсов и опыта.

Отсутствие рабочего взаимодействия с заказчиком.

Неполнота планирования. «Забытые работы».

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

Это звучит банально, но сколько бы раз об этом не твердили ранее, попрежнему, приходится сталкиваться с программными проектами, в которых отсутствуют какие-либо определенные цели и требования. Цитата из жизни:

«Была бы разработана хорошая программа, а какой процесс автоматизировать с ее помощью, мы найдем». К этому можно добавить только одно: «Когда человек не знает, к какой пристани он держит путь, для него никакой ветер не будет попутным» (Сенека Луций Аней, философ, 65-3 до н.э.) К часто упускаемым требованиям можно отнести:

Как правило, эти требования «всплывают» при подготовке и проведении приемо-сдаточных испытаний и могут сильно задержать проект по времени и увеличить трудозатраты на его реализацию. Чтобы этого не происходило, следует достигать соглашения с заказчиком по всем перечисленным пунктам предпочтительнее еще на стадии инициации проекта. Например, если требования портируемости продукта на разные аппаратно-программные платформы нет, то это целесообразно включить в раздел концепции с допущениями проекта.

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

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

Итерационная разработка. Контракт с компенсацией затрат на основе «Time & Materials» (передача риска Заказчику).

Учет в оценках трудоемкости и сроков возможности роста требований, например, на 50% (резервирование риска).

И еще, при сборе требований следует соблюдать принцип минимализма Вольтера: «Рассказ закончен не тогда, когда в него нечего добавить, а тогда, когда из него нечего больше выкинуть». Для большинства программных продуктов применим принцип Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

Если у нас в проекте недостаточно квалифицированных специалистов, то мы можем снизить последствия этого риска, применив следующие действия:

Привлечь экспертов-консультантов на начальных этапах.

Учитывать в оценках трудоемкости издержки на обучение сотрудников.

Уменьшать потери от текучести кадров, привлекая на начальном этапе избыточное число участников.

Учесть в оценках «время разгона» для новых сотрудников.

Для установления открытых и доверительных отношений с заказчиком, необходимо предпринимать следующие шаги:

Постоянное взаимодействие.

Согласование пользовательских интерфейсов и разработка прототипа Периодические поставки тестовых версий конечным пользователям для При планировании работ по проекту часто «забывают»:

Координация работ.

Уточнение требований.

Управление конфигурациями.

Разработка и поддержка скриптов автосборки.

И еще. Не стоит надеяться, что участники проекта будут каждую неделю по часов работать именно над вашим проектом. Есть множество причин, по которым они не смогут работать по проекту 100% своего времени. К списку наиболее распространенных причин этого относятся:

Сопровождение действующих систем.

Участие в подготовке технико-коммерческих предложений.

Рекомендация, планировать, что разработчики, которые назначены в ваш проект на 100% будут реально работать над вашими задачами в среднем от Ошибкам в оценках трудоемкости и сроков проекта и походам, которые позволяют их минимизировать, буде посвящена следующая лекция.

Управление проектом, направленное на снижение рисков На стадии инициации проекта оценка его трудоемкости имеет погрешность от до +100% [4]. Это, если оценка хорошая! А если плохая, то неопределенность, а, следовательно, и риски сорвать сроки и превысить плановую трудоемкость, могут быть в разы больше. Если не прилагать специальных усилий этот «дамоклов меч» неопределенности будет висеть над проектом на всем его протяжении (Рисунок 31).

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

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

Но есть и еще архитектурные риски. Известно, что закон Парето применим и к потреблению вычислительных ресурсов: 80% потребления ресурсов (время и память) приходится на 20% компонентов. Поэтому, необходимо реализовывать архитектурно-значимые требования так же в первую очередь, создавая «представительный» прототип будущей системы, который «простреливает»

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

Рисунок 31. Неопределенность не уменьшается, если управление не направлено на раннее разрешение рисков Рисунок 32. Определение приоритетов требований на первые итерации проекта Управление, нацеленное на снижение рисков, позволяет существенно снизить неопределенность на ранних стадиях проекта (Рисунок 33).

Рисунок 33. Управление, нацеленное на снижение рисков, позволяет уменьшать Проработка ключевых функциональных требований и детальное планирование их реализации позволяет уменьшить разброс начальных оценок, примерно, в раза: от -30% до +50%. Детальное проектирование и разработка прототипа будущей системы позволит получить еще более точные оценки общей трудоемкости: от -10% до +15%.

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

Если с заказчиком не удается найти взаимоприемлемое решение при первоначальной оценке проекта, то разумно попытаться договориться о выполнении проекта в 2 этапа с самостоятельным финансированием:

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

Эта работа, как правило, требует 10 % общих трудозатрат и 20% Непосредственно реализация. Если уточненные оценки трудозатрат С вменяемыми заказчиками это часто удается.

Мониторинг и контроль рисков Управление рисками должно осуществляться на протяжении всего проекта. Не вести мониторинг рисков в ходе проекта – все равно, что не следить за уровнем топлива при поездке на автомобиле.

Мониторинг и управление рисками – это процесс идентификации, анализа и планирования реагирования на новые риски, отслеживания ранее идентифицированных рисков, а также проверки и исполнения операций реагирования на риски и оценка эффективности этих операций.

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

Мониторинг и управление рисками включает в себя следующие задачи:

Пересмотр рисков должен проводиться регулярно, согласно расписанию.

Управление рисками проекта должно быть одним из пунктов повестки дня всех совещаний команды проекта. Неплохо начинать каждый статус митинг с вопроса: «Ну и какие еще неприятности нас ожидают?» Идентификация новых рисков, и пересмотр известных рисков происходит с использованием процессов, Аудит рисков предполагает изучение и предоставление в документальном виде результатов оценки эффективности мероприятий по реагированию на риски, относящихся к идентифицированным рискам, изучение основных причин их возникновения, а также оценку эффективности процесса управления рисками.

Тренды в процессе выполнения проекта подлежат проверке с использованием данных о выполнении. Для мониторинга выполнения всего проекта могут использоваться анализ освоенного объема и другие методы анализа отклонений проекта и трендов (см. Лекция 8. Реализация проекта). На основании выходов этих анализов можно прогнозировать потенциальные отклонения проекта на момент его завершения по показателям стоимости и расписания. Отклонения от базового плана могут указывать на последствия, вызванные как угрозами, так и благоприятными возможностями.

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

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

Цели управления рисками проекта – снижение вероятности возникновения и/или значимости воздействия неблагоприятных для проекта событий.

Главные причины провала программных проектов:

Требования заказчика отсутствуют / не полны / подвержены частым Отсутствие необходимых ресурсов и опыта.

Отсутствие рабочего взаимодействия с заказчиком.

Неполнота планирования. «Забытые работы».

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

Дополнительная литература и источники Том ДеМарко, Тимоти Листер, «Вальсируя с Медведями. Управление рисками в проектах по разработке программного обеспечения», М., «Microsoft Solutions Framework. Дисциплина управления рисками MSF», «PMBOK. Руководство к Своду знаний по управлению проектами», 3-е С.Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

Ньюэл М.В., «Управление проектами для профессионалов. Руководство по подготовке к сдаче сертификационного экзамена PMP», КУДИЦОбраз, 2006.

Barry W. Boehm. «A Spiral Model of Software Development and Barry Boehm, et al. «Software cost estimation with COCOMO II». Englewood www.systemsguild.com/riskology © 2005 Том ДеМарко, Тимоти Листер.

Лекция 6. Оценка трудоемкости и сроков разработки ПО Оценка - вероятностное утверждение Стив Макконнелл [1] пишет, что мы от природы склонны верить, что сложные всегда обеспечивают более точные результаты, чем простые формулы Трудоемкость = КоличествоФакторов х СредниеЗатратыНаФактор Однако, далеко не всегда это так. Сложные формулы, как правило, очень чувствительны к точности большого числа параметров (в приведенном примере формул COCOMO II содержится 21 параметр), которые надо задать, чтобы получить требуемые оценки.

Первое, что необходимо понимать при оценке проекта, это то, что любая оценка это всегда вероятностное утверждение. Если мы просто скажем, что трудоемкость данного пакета работ составляет М чел.*мес. (Рисунок 34), то это будет плохой оценкой потому, что одно единственное число ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес. Вряд ли мы можем считать себя «предсказамусами», которые точно знают что произойдет в будущем и сколько потребуется затрат на реализацию этого пакета работ.

Рисунок 34. Точечная оценка трудоемкости пакета работ ничего не скажет нам о вероятности того, что на реализацию этого пакета потребуется не более, чем М чел.*мес.

Для того, чтобы понять, откуда берется неопределенность, рассмотрим простейший пример, попытаемся оценить трудоемкость добавления поля ввода телефонного номера клиента к уже существующей форме. Менеджер, наблюдающий работу программистов только со стороны, скажет, что эта работа потребует не больше 15 минут рабочего времени. Человек, умудренный программистским опытом, скажет, что эта работа может занять от 2 до часов, и чтобы дать более точную оценку ему надо получить ответы на ряд вопросов:

Может ли вводиться несколько номеров?

Должна ли быть проверка номеров на действительность?

Простая или сложная проверка?

Если реализуем простую проверку, то не захочет ли клиент заменить ее Должна ли проверка работать для иностранных номеров?

Можно ли воспользоваться готовым решением?

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

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

То, что наша оценка должна быть вероятностным утверждением, означает, что для нее существует некоторое распределение вероятности (Рисунок 35), которое может быть очень широким (высокая неопределенность) или достаточно узким (низкая неопределенность).

Рисунок 35. Оценка – всегда вероятностная величина Если M – наиболее вероятное значение, то это не означает что это хорошая оценка, поскольку вероятность того, что фактическая трудоемкость превысит эту оценку, составляет более 50%.

Какая оценка может считаться хорошей? Стив Макконнелл утверждает [1]:

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

Негативные последствия «агрессивного» расписания В программостроении уже стало банальностью то, что разработчики без достаточного основания называют слишком оптимистичные сроки. Среди руководителей даже распространено неписаное правило: умножать на 2 оценку трудоемкости, которую сделал программист. Это пессимистичный подход.

Действительно, так иногда приходится поступать, если это программист, который только вчера отладил свою первую программу «Hello world!». Но если помочь молодым специалистам научится анализировать задачу, проектировать решение, составлять план работы, эффективно его реализовывать и анализировать полученные результаты, то можно будет не вспоминать, чему Еще один распространенный источник занижения сроков - необоснованные ожидания на применение новых технологий и средств разработки. Эти ожидания, как правило, не оправдываются. Согласно статистике, приведенной Демарко, средняя производительность в программном производстве растет Часто «агрессивное» расписание проекта появляется из-за того, что руководство и/или заказчик боятся переоценить проект, полагая, что согласно закону Паркинсона, работы по проекту займут все отведенное для него время.

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

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

Если расписание излишне агрессивное, то с целью сэкономить время, недостаточно внимания уделяется анализу требований и проектированию.

Исправление ошибок, допущенных на этих этапах, приведет к существенным дополнительным затратам.

Половина всех ошибок программирования возникают из-за стресса, вызванного излишним давлением фактора сроков. Ошибки исправляются наспех, обходными путями. В результате будет получен большой проблемный код и постоянно растущие затраты на исправление ошибок и внесение изменений.

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

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

Нереальные сроки, постоянное давление, сверхурочные, авралы приводят к тому, что затраты на проект растут экспоненциально и неограниченно.

Если участники проектной команды адекватно мотивированы на выполнение проектных работ с наименьшими затратами, то, на мой взгляд, этого достаточно, чтобы проект был реализован в минимально возможные сроки. О мотивации мы еще будем говорить (см. Лекция 7. Формирование команды).

Прагматичный подход. Метод PERT Использование собственного опыта или опыта коллег, полученного в похожих проектах, это наиболее прагматичный подход, который позволяет получить достаточно реалистичные оценки трудоемкости и срока реализации программного проекта, быстро и без больших затрат.

Инженерный метод оценки трудоемкости проекта PERT (Program / Project Evaluation and Review Technique) был разработан в 1958 году в ходе проекта по созданию баллистических ракет морского базирования «Поларис». Входом для данного метода оценки служит список элементарных пакетов работ. Для инженерного подхода нет необходимости точно знать закон распределения нашей оценки трудоемкости каждого такого элементарного пакета. Диапазон неопределенности достаточно охарактеризовать тремя оценками:

Mi – наиболее вероятная оценка трудозатрат.

Оi – минимально возможные трудозатраты на реализацию пакета работ. Ни один риск не реализовался. Быстрее точно не сделаем. Вероятность такого, что мы уложимся в эти затраты, равна 0.

Рi – пессимистическая оценка трудозатрат. Все риски реализовались.

Оценку средней трудоемкости по каждому элементарному пакету можно определит по формуле:

Для расчета среднеквадратичного отклонения используется формула:

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

А среднеквадратичное отклонение для оценки суммарной трудоемкости будет составлять:

Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, можно применить формулу:

Это значит, что вероятность того, что проект превысит данную оценку трудоемкости составляет всего 5%. А это уже вполне приемлемая оценка, под которой может расписаться профессиональный менеджер.

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

Проиллюстрирую данный подход на примере реального проекта. В Ассоциации CBOSS задачей проекта, который нам с коллегами посчастливилось реализовывать, была разработка на основе стандартов J2EE общесистемного ПО для перевода рабочих мест CBOSS на новую трехзвенную архитектуру. Был разработан набор стандартных компонентов и сервисов, из которых как из конструктора можно эффективно и качественно собирать прикладные подсистемы. Высокоуровневая архитектура реализовывала стандартный паттерн MVC (Рисунок 36), каждый из компонентов которого имел «точки расширения» для прикладной разработки, которые на рисунке выделены красным светом.

Рисунок 36. Высокоуровневая архитектура J2EE фреймворка для разработки приложений.

Такими точками расширения являлись:

Пользовательский экран (UI Form), который собирался из готовых визуальных компонентов.

Обработчики (Action), которые обрабатывали на сервере приложений события от активных визуальных компонентов, входящих в состав Объекты (Business Obj), которые моделировали прикладную область, и к которым обращались обработчики событий.

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

Согласно этой статистике, разработка и отладка требовала у программиста:

для одного экрана - от 2 до 20 часов (наиболее вероятно – 4 часа);

для одного обработчика событий - от 4 до 32 часов (наиболее вероятно для нового бизнес-объекта - от 2 до 8 часов (наиболее вероятно – для добавление нового бизнес-метода - от 2 до 26 часов (наиболее Весь проект прикладной разработки измерялся в «попугаях»:

КUI – количество пользовательских экранов.

КAct – количество обработчиков событий.

КBO – количество новых бизнес-объектов.

КBM – количество новых или модифицируемых бизнес-методов.

Если новое разрабатываемое приложение содержит 20 пользовательских экранов, 60 обработчиков событий, 16 новых бизнес-объекта и 40 новых бизнесметодов, которые необходимо добавить, как в новые, так и в уже существующие бизнес-объекты, тогда, согласно нашей статистике, EUI = (2 + 4*4 + 20) / 6 = 6.7 чел.*час., СКОUI = (20 - 2) / 6 = 3 чел.*час EAct = (4 + 4*8 + 32) / 6 = 11.3 чел.*час., СКОAtct = (32 - 4) / 6 = 4.7 чел.*час EBO = (2 +4*3 + 8) / 6 = 3.7 чел.*час., СКОBO = (8 - 2) / 6 = 1 чел.*час EBM = (2 + 4*6 + 26) / 6 = 8.7 чел.*час., СКОBM = (26 - 2) / 6 = 4 чел.*час Для средней трудоемкости работ по кодированию в проекте может быть получена следующая оценка:

Тогда для оценки суммарной трудоемкости проекта, которую мы не превысим с вероятностью 95%, получим Хотя относительная погрешность в оценке трудоемкости каждой такой элементарной работы составляла десятки процентов, для нашего проекта, в котором было таких «попугаев» было 136, относительная погрешность оценки суммарной трудоемкости, сделанной по методу PERT, составила, приблизительно, лишь 4%.

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

Полученную оценку трудоемкости кодирования необходимо умножить на четыре, поскольку помним (см. Лекция 3. Инициация проекта), что кодирование составляет только 25% общих трудозатрат проекта. Поэтому суммарная трудоемкость нашего проекта составит, приблизительно, 5200 чел.*час.

Как мы уже говорили ранее, если сотрудник на 100% назначен на проект, это, как правило, не означает, что он все 40 часов в неделю будет тратить на проектные работы. Тратить он будет 60 – 80% своего рабочего времени.

Поэтому, в месяц сотрудник будет работать по проекту, примерно, 165 * 0.8 = 132 чел.*час/мес. Следовательно, трудоемкость проекта в человеко-месяцах составит, приблизительно 5200 / 132 40.

Тогда согласно формуле Б.Боэма (Рисунок 15) оптимальная продолжительность проекта составит:

а средняя численность команды – 5 человек.

Помним, что потребление ресурсов в проекте неравномерно (Рисунок 13), поэтому начинать проект должны 1-3 человека, а на стадии реализации начальная численность команды может быть увеличена в несколько раз.

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

Обзор метода функциональных точек Анализ функциональных точек - стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (Alan Albrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group – IFPUG), которая опубликовала несколько ревизий метода [2].

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

При анализе методом функциональных точек надо выполнить следующую последовательность шагов (Рисунок 37):

Определение области оценки и границ продукта.

Подсчет функциональных точек, связанных с данными.

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

Определение суммарного количества не выровненных функциональных Определение значения фактора выравнивания (FAV).

Расчет количества выровненных функциональных точек (AFP).

Рисунок 37. Процедура анализа по методу функциональных точек Определение типа оценки Первое, что необходимо сделать, это определить тип выполняемой оценки.

Метод предусматривает оценки трех типов:

Проект разработки. Оценивается количество функциональности поставляемой пользователям в первом релизе продукта.

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

Продукт. Оценивается объем уже существующего и установленного Определение области оценки и границ продукта Второй шаг – это определение области оценки и границ продукта. В зависимости от типа область оценки может включать:

Все разрабатываемые функции (для проекта разработки) Все добавляемые, изменяемые и удаляемые функции (для проектов Только функции, реально используемые, или все функции (при оценке продукта и/или продуктов).

Третий шаг. Границы продукта (Рисунок 38) определяют:

Что является «внешним» по отношению к оцениваемому продукту.

Где располагается «граница системы», через которую проходят транзакции передаваемые или принимаемые продуктом, с точки зрения Какие данные поддерживаются приложением, а какие – внешние.

Рисунок 38. Границы продукта в методе функциональных точек К логическим данным системы относятся:

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

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

Примером логических данных (информационных объектов) могут служить:

клиент, счет, тарифный план, услуга.

Подсчет функциональных точек, связанных с данными Третий шаг - подсчет функциональных точек, связанных с данными. Сначала определяется сложность данных по следующим показателям:

DET (data element type) – неповторяемое уникальное поле данных, например, Имя Клиента – 1 DET; Адрес Клиента (индекс, страна, область, район, город, улица, дом, корпус, квартира) – 9 DET’s RET (record element type) – логическая группа данных, например, адрес, паспорт, телефонный номер.

Оценка количества не выровненных функциональных точек, зависит от сложности данных, которая определяется на основании матрицы сложности (Таблица 7).

Таблица 7. Матрица сложности данных Оценка данных в не выровненных функциональных точках (UFP) подсчитывается по-разному для внутренних логических файлов (ILFs) и для внешних интерфейсных файлов (EIFs) (Таблица 8) в зависимости от их сложности.

Таблица 8. Оценка данных в не выровненных функциональных точках (UFP) для внутренних логических файлов (ILFs) и внешних интерфейсных файлов (EIFs) функциональных точках объекта данных «Клиент» (Рисунок 39).

Рисунок 39. Пример оценки в не выровненных функциональных точках объекта данных Объект «Клиент» содержит четыре логических группы данных, которые в совокупности состоят из 15 неповторяемых уникальное полей данных. Согласно матрице (Таблица 7), нам следует оценить сложность этого объекта данных, как «Low». Теперь, если оцениваемый объект относится к внутренним логическим файлам, то согласно Таблица 8 его сложность будет 7 не выровненных функциональных точек (UPF). Если же объект является внешним интерфейсным файлом, то его сложность составит 5 UPF.

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

Транзакция – это элементарный неделимый замкнутый процесс, представляющий значение для пользователя и переводящий продукт из одного консистентного состояния в другое.

В методе различаются следующие типы транзакций (Таблица 9):

EI (external inputs) – внешние входные транзакции, элементарная операция по обработке данных или управляющей информации, поступающих в систему из вне.

EO (external outputs) – внешние выходные транзакции, элементарная операция по генерации данных или управляющей информации, которые выходят за пределы системы. Предполагает определенную логику обработки или вычислений информации из одного или более ILF.

EQ (external inquiries) – внешние запросы, элементарная операция, которая в ответ на внешний запрос извлекает данные или управляющую информацию из ILF или EIF.

Таблица 9. Основные отличия между типами транзакций. Легенда: О – основная; Д – дополнительная; NA – не применима.

EI EO EQ

Оценка сложности транзакции основывается на следующих ее характеристиках:

FTR (file type referenced) – позволяет подсчитать количество различных модифицируемых или считываемых в транзакции.

DET (data element type) – неповторяемое уникальное поле данных.

Примеры. EI: поле ввода, кнопка. EO: поле данных отчета, сообщение об ошибке. EQ: поле ввода для поиска, поле вывода результата поиска.

Для оценки сложности транзакций служат матрицы, которые представлены в Таблица 10 и Таблица 11.

Таблица 10. Матрица сложности внешних входных транзакций (EI) Таблица 11. Матрица сложности внешних выходных транзакций и внешних запросов (EO & Оценка транзакций в не выровненных функциональных точках (UFP) может быть получена из матрицы (Таблица 12) Таблица 12. Сложность транзакций в не выровненных функциональных точках (UFP) В качестве примера, рассмотрим оценку управляющей транзакции (EI) для диалогового окна, задающего параметры проверки орфографии в MS Office Outlook (Рисунок 40).

Рисунок 40. Диалоговое окно, управляющее проверкой орфографии в MS Office Outlook Каждый “Check box” оценивается, как 1 DET. Выпадающий список - 1 DET.

Каждая управляющая кнопка должна рассматриваться как отдельная транзакция. Например, если оценивать управляющую транзакцию по кнопке «OK», то, для данной транзакции мы имеем 1 FTR и 8 DET. Поэтому, согласно матрице (Таблица 10), мы можем оценить сложность транзакции, как Low. И, наконец, в соответствие с матрицей (Таблица 12), данная транзакция должна быть оценена в 3 не выровненных функциональных точек (UFP).

Определение суммарного количества не выровненных функциональных точек (UFP) Общий объем продукта в не выровненных функциональных точках (UFP) определяется путем суммирования по всем информационным объектам (ILF, EIF) и элементарным операциям (транзакциям EI, EO, EQ).

UFP UFPi UFPi UFPi UFPi UFPi EI

ILF EIF EO EQ

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

Обмен данными (0 – продукт представляет собой автономное приложение; 5 – продукт обменивается данными по более, чем одному телекоммуникационному протоколу).

Распределенная обработка данных (0 – продукт не перемещает данные; 5 – распределенная обработка данных выполняется несколькими компонентами системы).

Производительность (0 – пользовательские требования по производительности не установлены; 5 – время отклика сильно ограничено критично для всех бизнес-операций, для удовлетворения требованиям необходимы специальные проектные решения и инструменты анализа.

Ограничения по аппаратным ресурсам (0 – нет ограничений; 5 – продукт целиком должен функционировать на определенном процессоре и не может быть распределен).

Транзакционная нагрузка (0 – транзакций не много, без пиков; 5 – число транзакций велико и неравномерно, требуются специальные решения и Интенсивность взаимодействия с пользователем (0 – все транзакции обрабатываются в пакетном режиме; 5 – более 30% транзакций – интерактивные).

Эргономика (эффективность работы конечных пользователей) (0 – нет специальных требований; 5 – требования по эффективности очень Интенсивность изменения данных (ILF) пользователями (0 – не требуются; 5 – изменения интенсивные, жесткие требования по восстановлению).

Сложность обработки (0 – обработка минимальна; 5 – требования безопасности, логическая и математическая сложность, многопоточность).

разрабатывается как стандартный многоразовый компонент).

11. Удобство инсталляции (0 – нет требований; 5 – установка и обновление ПО производится автоматически).

12. Удобство администрирования (0 – не требуется; 5 – система автоматически самовосстанавливается).

13. Портируемость (0 – продукт имеет только 1 инсталляцию на единственном процессоре; 5 – система является распределенной и предполагает установку на различные «железо» и ОС).

14. Гибкость (0 – не требуется; 5 – гибкая система запросов и построение произвольных отчетов, модель данных изменяется пользователем в интерактивном режиме).

14 системных параметров (degree of influence, DI) оцениваются по шкале от 0 до 5. Расчет суммарного эффекта 14 системных характеристик (total degree of influence, TDI) осуществляется простым суммированием:

Расчет значения фактора выравнивания производится по формуле Например, если, каждый из 14 системных параметров получил оценку 3, то их суммарный эффект составит TDI = 3 * 14 = 42. В этом случае значение фактора выравнивания будет: VAF = (42 * 0.01) + 0.65 = 1. Расчет количества выровненных функциональных точек (AFP) Дальнейшая оценка в выровненных функциональных точках зависит от типа оценки. Начальное оценка количества выровненных функциональных точек для программного приложения определяется по следующей формуле:

Она учитывает только новую функциональностсть, которая реализуется в продукте. Проект разработки продукта оценивается в DFP (development functional point) по формуле:

где CFP (conversion functional point) – функциональные точки, подсчитанные для дополнительной функциональности, которая потребуется при установке продукта, например, миграции данных.

Проект доработки и совершенствования продукта оценивается в EFP (enhancement functional point) по формуле:

где ADD - функциональные точки для добавленной функциональности;

CHGA - функциональные точки для измененных функций, рассчитанные после модификации;

VAFA – величина фактора выравнивания рассчитанного после завершения проекта;

DEL – объем удаленной функциональности;

VAFB - величина фактора выравнивания рассчитанного до начала проекта.

Суммарное влияние процедуры выравнивания лежит в пределах +/- 35% относительно объема рассчитанного в UFP.

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

Основы методики COCOMO II Методика COCOMO позволяет оценить трудоемкость и время разработки программного продукта. Впервые была опубликована Бари Боэмом [3] в году в виде результат анализа 63 проектов компании «TRW Aerospace». В методика была усовершенствована и получила название COCOMO II.

Калибровка параметров производилась по 161 проекту разработки. В модели используется формула регрессии с параметрами, определяемыми на основе отраслевых данных и характеристик конкретного проекта.

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

Формула оценки трудоемкости проекта в чел.*мес. имеет вид:

EM i - множители трудоемкости n 7 - для предварительной оценки Главной особенностью методики является то, что для того, чтобы оценить трудоемкость, необходимо знать размер программного продукта в тысячах строках исходного кода (KSLOC, Kilo Source Lines Of Code). Размер программного продукта может быть, например, оценен экспертами с применением метода PERT.

Если мы провели анализ продукта методом функциональных точек, то его размер может быть рассчитан с использованием собственных статистических данных или с использованием статистики по отрасли [5] (Таблица 13).

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

программирования В методике используются пять факторов масштаба SFj, которые определяются следующими характеристиками проекта:

PREC – прецедентность, наличие опыт аналогичных разработок (Very FLEX – гибкость процесса разработки (Very Low – процесс строго детерминирован; Extra High – определены только общие цели).

неизвестны/не проанализированы; Extra High – риски разрешены на взаимодействия; Extra High – полное доверие, взаимозаменяемость и Значение фактора масштаб, в зависимости от оценки его уровня, приведены в Таблица 14. Значение фактора масштаба, в зависимости от оценки его уровня масштаба Множители трудоемкости В нашу задачу не входит детальное описание метода COCOMO II, поэтому мы рассмотрим только случай предварительной оценки трудоемкости программного проекта. Для этой оценки необходимо оценить для проекта уровень семи множителей трудоемкости Mi:

PERS – квалификация персонала (Extra Low – аналитики и программисты имеют низшую квалификацию, текучесть больше 45%;

Extra High - аналитики и программисты имеют высшую квалификацию, RCPX – сложность и надежность продукта (Extra Low – продукт простой, специальных требований по надежности нет, БД маленькая, документация не требуется; Extra High - продукт очень сложный, требования по надежности жесткие, БД сверхбольшая, документация RUSE – разработка для повторного использования (Low – не требуется;

Extra High – требуется переиспользование в других продуктах) PDIF – сложность платформы разработки (Extra Low – специальные ограничения по памяти и быстродействию отсутствуют, платформа стабильна; Extra High – жесткие ограничения по памяти и быстродействию, платформа нестабильна) PREX – опыт персонала (Extra Low – новое приложение, инструменты и платформа; Extra High - приложение, инструменты и платформа хорошо FCIL – оборудование (Extra Low – инструменты простейшие, коммуникации затруднены; Extra High – интегрированные средства длительности; Very High – 160% от номинальной длительности) Влияние множителей трудоемкости в зависимости от их уровня определяется их числовыми значениями, которые представлены в матрице, приведенной ниже, (Таблица 15).

Таблица 15. Значения множителей трудоемкости, в зависимости от оценки их уровня Из этой таблицы, в частности, следует, если в нашем проекте низкая квалификация аналитиков, то его трудоемкость возрастет примерно в 4 раза по сравнению с проектом, в котором участвуют аналитики экстра-класса. И это не выдумки теоретиков, а отраслевая статистика!

Оценка многокомпонентного продукта Как мы отмечали ранее (см. Лекция 4. Планирование проекта), для того чтобы адекватно спланировать проект и оценить его трудоемкость, необходимо выполнить предварительное проектирование программного продукта. В результате декомпозиции мы получаем некоторое количество компонентов (N), которые составляют программный продукт.

Следует понимать, что суммарная трудоемкость проекта не равна простой сумме трудоемкостей разработки каждого из компонентов:

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

Методика COCOMO II определяет следующую последовательность вычисления трудоемкости проекта при многокомпонентной разработке.

Суммарный размер продукта рассчитывается, как сумма размеров его Базовая трудоемкость проекта рассчитывается по формуле:

Затем рассчитывается базовая трудоемкость каждого компонента:

На следующем шаге рассчитывается оценка трудоемкости компонентов с учетом всех множителей трудоемкости, кроме множителя SCED.

И, наконец, итоговая трудоемкость проекта определятся по формуле:

Оценка длительности проекта Длительность проекта в методике COCOMO II рассчитывается по формуле:

PMNS – трудоемкость проекта без учета множителя SCED, определяющего сжатие расписания.

Выводы Оценка трудоемкости должна быть вероятностным утверждением. Это означает, что для нее существует некоторое распределение вероятности, которое может быть очень широким, если неопределенность высокая, или достаточно узким, если неопределенность низкая.

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

Если собственный опыт аналогичных проектов отсутствует, а коллеги-эксперты недоступны, то необходимо использовать формальные методики, основанные на обобщенном отраслевом опыте. Среди них наибольшее распространение получили два подхода:

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

Дополнительная литература и источники С. Макконнелл, «Сколько стоит программный проект», «Питер», 2007.

2. Function Point Counting Practices Manual, Release 4.2, IFPUG, 2004.