ИТУП / лекционный материал / Управление проектами и разработка ПО

Качество – это степень удовлетворенности потребителя.

5.3.2. Описание целей проекта

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

•Конкретность. Цель проекта должна быть конкретной, выраженной в терминах проекта, с указанием условий и сроков. Например, цель «добиться максимальной степени удовлетворенности потребителей продукта» не конкретна. В то же время цель «получить положительный отзыв на продукт от 90% потребителей за первые полгода продаж» достаточно конкретна для проекта по разработке «коробочного» продукта.

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

•Измеримость. Должен быть указан эффективно проверяемый критерий, который позволял бы определить, достигнута ли цель и в какой степени. Например, цель «разработать программу, существенно повышающую эффективность процесса продаж» неизмерима: неясно, как измеряется эффективность и какое повышение можно считать существенным. В то же время цель «разработать программу, ускоряющую процесс оформления заявки в среднем на 10%» измерима.

•Непротиворечивость. Цели не должны быть внутренне противоречивыми и взаимно исключающими друг друга. Например, цели «разработать продукт с максимальным набором функций» и «затратить минимальное количество ресурсов на разработку» противоречат друг другу (и неконкретны, к тому же). Минимальное количество ресурсов (ноль) будет затрачено, если разработку не проводить, но тогда и возможностей у продукта не будет. В то же время цель «разработать продукт, имеющий не меньше функций, чем конкурент Х и затратить на разработку не более Y человеко-часов» не является противоречивой (но может оказаться нереалистичной).

101

5.4. Виды планов

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

По планируемому периоду различают планы:

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

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

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

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

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

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

Ниже приводится краткое описание каждого плана из набора

IEEE:

SVVP (Software verification and validation plan) – План экспертизы программного обеспечения.

Этот план определяет, каким образом и в какой последовательности должны проверяться стадии проекта, а также сам продукт на соответствие поставленным требованиям. В терминах управления качеством такая проверка подразумевает верификацию и валидацию. Верификация – это процесс проверки на соответствие требованиям процесса разработки программного продукта; валидация проверяет тот факт, что разработан требуемый продукт. Зачастую валидацию и верификацию осуществляют сторонние организации, в этом случае экспертиза называется независимой (Independent V&V, IV&V).

Верификация – проверка соответствия установленным требованиям процесса разработки продукта.

103

Проведение персональных назначений на задачи.

Определение времени выполнения задачи.

Оценка рисков, связанных с конкретными задачами.

Выявление критических путей.

Создание инфраструктуры управления.

Оценка затрат.

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

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

•Анализ документации на полноту, содержание, аккуратность.

•Назначение начальной и конечной дат работ.

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

5.5.1.Выявление и анализ критического пути

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

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

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

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

105

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

Критический путь – это путь наибольшей длины в графе работ.

5.5.2. Методики оценок времени и затрат

Существует несколько методик оценок времени и затрат (трудоемкости, стоимости) для составления планов и расчетов. Перечислим основные из них:

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

√Снизу вверх по составленному графику работ. Данные по трудозатратам и времени берем от исполнителей.

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

√Методика исторических соотношений. Стоимость (трудоемкость,

время) одного проекта относится к стоимости (трудоемкости, времени) другого пропорционально отношению их объемов в некоторой степени n. Степень n – число, которое надо знать или подобрать опытным путем.

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

формуле трапеций: (O+2*Р+П)/4;

формуле Симпсона: (О+4*Р+П)/6.

5.5.3. Распределение работ

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

106

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

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

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

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

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

5.6.Структура декомпозиции работ (WBS)

Структура декомпозиции работ – WBS (Work Breakdown Structure)

или СДР – это широко распространенный, сравнительно простой и проверенный на практике метод составления списка работ, который может послужить основой дальнейшего планирования.

5.6.1. Основные термины и определения

Используемые в названии данного метода термины имеют следующие значения:

•Work (Работа) – непрерывное физическое или умственное усилие, направленное на преодоление препятствий и достижение целей или результатов; специфическая задача, обязанность, функция или задание, часто являющиеся частью фазы или другой, большей по объему работы; что-то, производимое или выполняемое в результате усилия или применения навыков (квалификации).

•Breakdown (Декомпозиция) – разделение на части или категории, выделение простых составляющих.

•Structure (Структура) – фиксированное упорядоченное множество объектов и отношений между ними, классификация чего-либо по заданному основанию.

Эти определения означают, что структура декомпозиции работ (WBS) имеет следующие характеристики:

•описывает с необходимой точностью содержание работ по проекту;

•определяет весь объем работ по проекту;

107

•формируется в виде иерархической структуры (проект декомпозируется на пакеты/субпакеты и т.д. вплоть до отдельных работ).

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

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

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

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

Для проектов средней сложности рекомендуется использовать до 6 уровней WBS: 3 верхние уровня для предоставления информации уровня заказчика, 3 нижние уровня для детализации информации уровня исполнителя. Глубина детализации WBS зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо

108

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

Подводя итог, констатируем, что WBS:

определяет иерархию результатов;

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

разрабатывается путем деления результатов на поддающиеся учету и измеряемые элементы;

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

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

5.6.2. Необходимость использования WBS

Стандарт PMBOK (Project Management Body of Knowledge)

описывает WBS, как средство (инструмент) определения содержания проекта. Он определяет управление содержанием проекта как «процесс, направленный на гарантированное обеспечение того, что проект включает все необходимые работы, и только те работы, которые необходимы для успешного завершения проекта». Основываясь на этом определении, разработка WBS имеет две основные цели:

√обеспечение планирования всех необходимых работ проекта;

√обеспечение отсутствия ненужных (лишних) работ, работ, не связанных с реализацией проекта.

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

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

109

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

5.6.3. Разработка структуры декомпозиции работ

При разработке WBS необходимо принимать во внимание следующие основные правила.

+Результативность. Каждый элемент WBS должен обеспечивать достижение ощутимого результата.

+Агрегация. Каждый элемент WBS должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

+Логичность. Результаты должны логически декомпозироваться до уровня, на котором можно определить, как они будут достигаться (проектирование, поставки, заключение договоров, производство). Декомпозиция результатов, начиная от верхнего уровня WBS (проекта) до нижнего уровня должно быть логически связана.

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

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

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

+Полнота. Все ожидаемые результаты проекта в явном виде должны быть включены в WBS.

+Отчетность. Для всех важных событий, связанных с отчетностью (например, ежемесячные отчеты, отчеты о

110