WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 |   ...   | 24 | 25 || 27 | 28 |   ...   | 33 |

Задавая трудозатраты или длительность в плане, необходимо следить за тем, чтобы они вводились на уровне задач самого нижнего урованя, а для суммарных задач (этапов) вычислялись автоматически (если для планирования используется специальное программное обеспечение, например, Microsoft Project или Primavera Project Management, то именно так и произойдет).

Ниже показана СДР с указанными длительностями каждой работы.

Рис. 2. СДР (WBS) проекта с указанием длительности каждой работы.

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

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

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

Связывание (Linking) – установление зависимости между задачами в проекте. Для связывания задач пользователь определяет зависимость между их датами окончания или начала.

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

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

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

• ОН (окончание-начало), • НН (начало-начало), • ОО (окончание-окончание) • НО (начало-окончание).

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

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

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

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

Henry Laurence Gantt (1861-1919) – американский инженер, теоретик научной организации труда.

Разработал ленточные диаграммы, впоследствии ставшие знаменитыми.

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

Ниже (см. рис. 3) показан календарный план проекта как в виде списка задач с указаниями их дат начала и окончания (а также длительностей), так и в виде диаграммы Гантта, причем представление календарного плана отформатировано с использованием MS Project так, чтобы названия задач критического пути и их отрезки на диаграмме Гантта выделялись красным цветом.

Рис. 3. Критический путь на диаграмме Гантта Очень удобно при составлении календарных планов, имея в виду их дальнейшее представление в виде диаграмм Гантта, вводить в список задач (работ) проекта специальные задачи-вехи.

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

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

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

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

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

Сетевой график – очень удобный инструмент:

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

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

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

Критический путь (Critical path) – набор запланированных задач, которые необходимо выполнить для окончания проекта в срок, установленный календарным планом. Каждая задача на критическом пути является критической задачей.

Второй вариант. Для каждой работы вычислим, насколько можно отодвинуть ее окончание, чтобы общая длительность проекта не изменилась. Эта величина называется полным резервом времени (total slack) для данной работы, причем работа явлается критической, если полный резерв равен нулю (т.е. любая задержка этой работы ведет к задержке всего проекта). Критическим является путь, состоящий из критических работ.

Строго говоря, полный резерв времени данной задачи может быть и отрицательной величиной. Это происходит в том случае, когда у проекта установлена жесткая дата окончания, и для того чтобы в нее «вписаться», необходимо ускорить выполнение данной задачи. Стоит также отметить, что для менеджера проекта важным является и другой параметр задачи – ее свободный резерв времени (free slack). Это та величина, на которую можно задержать окончание данной задачи, чтобы не произожло задержки задачи-последователя.

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

1 – начало работы;

2 – коллектив сформирован, рабочие места подготовлены;

3 – проектирование завершено;

4 – программирование завершено;

5 – комплексная отладка завершена;

6 – оборудование закуплено;

7 – группа технических писателей получила описание проекта и необходимые пояснения от проектировщиков;

8 – то же для ПО, разработка проектной документации завершена;

9 – группа технических писателей получила всю необходимую информацию об интерфейсах с пользователем, разработка программной документации завершена;

10 – группа оценки качества (Quality Assurance – QA) разработала тесты;

11 – группа QA оценила проект положительно;

12 – группа QA завершила автономное тестирование;

13 – группа QA завершила комплексное тестирование, получила всю документацию и действующий вариант системы;

14 – проверка качества завершена;

15 – конец работы (конечно, это не конец, будет ещё сопровождение, но на чём-то пример надо закончить).

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

Критическими путями являются пути 1-6-2-3-4-5-9-13-14-15 и 1-62-3-4-5-12-13-14-15, т.е. вся работа не может быть выполнена быстрее, чем за 21 (двадцать одну) неделю. Понятно, что с точки зрения оптимальной загрузки коллектива, было бы лучше, чтобы все пути в графе от начала к концу имели бы примерно одинаковую длительность с тем, чтобы как-то уменьшить длину критического пути. Например, есть соблазн заставить группу QA проводить даже самое начальное тестирование, уменьшив нагрузку на программистов, работа которых находится на критическом пути. Но тогда очень трудно определить границы ответственности, программисты начинают выдавать откровенную халтуру и, в результате, сроки даже удлиняются. В реальных проектах, где работ очень много, всё-таки удаётся путём перераспределения работ улучшать сетевой график, по крайней мере, к этому стремятся все руководители.

Ещё несколько замечаний по данному примеру. Очевидно, неудачно спланированы работы между событиями 1, 2, 6. Коллектив сформирован за одну неделю, но рабочие места ещё не готовы. Группа технических писателей начинает работать на шесть недель позже проектантов, а группа QA имеет трёхнедельный перерыв перед завершением проектирования и т.д.

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

Для сравнения с сетевым графиком нарисуем диаграмму Гантта для того же примера.

Недели Работы 0 1 2 3 4 5 6 7 8 9 0 Формирование коллектива Закупка оборудования Оборудование рабочих мест Проектирование Программирован ие Комплексная отладка Сдача в QA QA Сдача заказа Объяснение 0 проекта писателям Разработка 1 проектной документации Объяснение 2 программы писателям Разработка 3 программной документации Объяснение 4 интерфейсов писателям Разработка 5 пользоват.

документации Разработка набора 6 тестов Передача проекта 7 в QA Оценка проекта Передача ПО в 9 QA Автономное 0 тестирование Недели Работы 0 1 2 3 4 5 6 7 8 9 0 Передача ПО в 1 QA после комплексной отладки Комплексное 2 тестирование Если в сетевом графике особенно наглядно видны зависимости работ друг от друга, например, работа 12-13 может начаться только после завершения работ 5-12 и 11-12, то в диаграмме Гантта основной упор на то, что делается в каждую конкретную неделю. Например, видно, что группа QA имеет перерыв в работе в 2 недели между работами 11-12 (автономное тестирование) и 12-13 (комплексное тестирование). В этом смысле диаграмма Гантта нагляднее сетевого графика. Технические менеджеры предпочитают сетевые графики, т.к.

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

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

8.5. Список использованной и рекомендованной литературы 1. Баранов С. Н. Управление программным проектом. Лекции по спецкурсу "Технология программирования". - СПб: СанктПетербургский государственный электротехнический университет, рукопись, 1998.

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

3. А.К. Гультяев. Microsoft Office. Project Server 2003. Project Professional 2003. Управление проектами. Практическое пособие.

Корона-принт, 2004.

4. Эдвард Йордон. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. - М.: ЛОРИ, 2001.

Pages:     | 1 |   ...   | 24 | 25 || 27 | 28 |   ...   | 33 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.