Управление проектами

Курсовая работа

По теме: Управление проектами

1 Управление проектами

PROJECT MANGEMENT BODY OF KNOWLEDGE (PMBOK) - документ подготовлен Институтом Управления Проектами (Project Management Institute, PMI) в 1996 году и описывает сумму знаний, относящихся к профессиональной области управления проектами. Приведенная в нем информация применима к большинству проектов, но это не значит, что приведенные рекомендации должны без изменений использоваться всегда и всеми; группа, работающая над проектом, в каждом конкретном случае решает, что именно и как будет использоваться.

Эти источники доступны бесплатно на сайте http://www.pmi.ru. Украинское издание этой книги можно приобрести в Украинской ассоциации управления проектами (uutba@carrier.kiev.ua).

- 31% проектов завершаются провалом

- 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза

- только 16% проектов укладываются в срок и бюджет

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

· определенное и уникальное множество продуктов;

· соответствующее множество видов деятельности, направленных на конструирование этих продуктов;

· соответствующие ресурсы, необходимые для выполнения видов деятельности;

· некоторый конечный интервал времени, составляющий срок жизни проекта;

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

Управление Проектом (Project Management) - применение знаний, опыта, средств и технологий в процессе выполнения проекта с целью удовлетворить (или превысить) требования или ожидания заказчика от данного проекта. Обычно это требует сбалансированности между:

· объемом работ, временем, стоимостью и качеством

· заказчиками с разными потребностями и ожиданиями

· определенными требованиями (требования) и неопределенными требованиями (ожидания)

Стандартный ход проекта

Стандартный подход к проектному управлению состоит из следующих этапов:

· Постановка задачи (фиксация цели проекта).

· Планирование (выработка плана и бюджета).

· Контроль и анализ исполнения, коррекция планов.

· Закрытие проекта по формальной процедуре и анализ статистики.

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

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

Техника планирования

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

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

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

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

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

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

График работ в таких системах, как MS Project, получается автоматически, если определены задачи и ресурсы.

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

Функциональная структура управления проектами включает в себя девять разделов:

1. Управление Интеграцией - процессы, обеспечивающие координацию между различными элементами проекта

2. Управление Областью - процессы, обеспечивающие выполнение всех требуемых и только требуемых работ

3. Управление Временем - процессы, обеспечивающие завершение работ в заданное время

4. Управление Стоимостью - процессы, обеспечивающие завершение работ в заданном бюджете

5. Управление Качеством - процессы, обеспечивающие выполнение требований и ожиданий заказчика

6. Управление Человеческими Ресурсами - процессы, обеспечивающие наиболее эффективное использование людей, участвующих в проекте

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

8. Управление Риском - процессы, связанные с определением, анализом и реакцией на возможный риск, связанные с проектом

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

Для удобства управления, проекты разбиваются на несколько фаз проекта, которые образуют Цикл Жизни Проекта (Project Life Cicle). В каждом проекте (фазе проекта) обязательно присутствуют пять групп процессов:

1. Процессы Инициирования - принятие решения о начале проекта или его фазы

2. Процессы Планирования - создание и поддержка рабочей схемы для достижения бизнес-целей проекта

3. Процессы Выполнения - координация людских и других ресурсов в соответствии с планом выполнения проекта

4. Процессы Управления - мониторинг хода выполнения проекта и принятие необходимых действий по корректировке

5. Процессы Окончания - формальное принятие решения о завершении фазы или проекта.

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

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

2 Структура процесса планирования

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

Декомпозиция целей (Scope Definition). Последовательное деление основных результатов проекта на более мелкие элементы, вплоть до пакетов работ, хорошо поддающихся управлению. В итоге получается иерархическая структура (дерево) работ проекта (Work Breakdown Structure -- WBS).

Определение операций (Activity Definition). Определение перечня элементарных операций (activity), которые должны быть выполнены для достижения результатов, описанных в WBS.

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

Определение взаимосвязи операций (Activity Sequencing). Определение последовательности проведения работ в проекте с учетом технологических, организационных и других ограничений. Одни работы могут выполняться параллельно, другие же, напротив, могут начаться не раньше, чем завершатся предшествующие. Результатом этого этапа является сетевая диаграмма (project network diagram), которая показывает логическую взаимосвязь между работами в проекте (часто ее некорректно называют PERT-диаграммой).

Оценка длительности операций (Activity Duration Estimating). Определение количества рабочего времени, которое необходимо для выполнения каждой элементарной операции. Расчет времени производится на основании экспертных оценок и моделирования (метод Монте-Карло). Учитываются ресурсные и другие ограничения.

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

Составление расписания (Schedule Development). Определение дат старта и финиша для всех работ проекта. Оцениваются реалистичность расписания (project schedule), загрузка ресурсов и их влияние на срок выполнения проекта.

Разработка бюджета (Cost Budgeting). Определение базисной линии стоимости проекта, называемой S-кривой из-за ее сходства с латинской буквой S. Базисная линия показывает распределение во времени (нарастающим итогом) расходов на проект и служит для сравнения текущих результатов с плановыми

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

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

3 Стратегическое управление проектами

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

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

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

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

· чего следует достичь;

· как это перевести в практическую плоскость;

· какие из альтернатив самые многообещающие.

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

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

· критерии оценки проектов;

· оценки и допущения, на которых базировалось решение об отборе проекта;

· определение проекта;

· план выполнения проекта.

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

· оценку прогресса в решении каждой задачи, затрат и длительности работ;

· выявление тех задач, выполнение которых выпадает из графика, оценку последствий этого для общего хода работ над проектом;

· изменение развития проекта в целом относительно запланированных затрат и даты завершения.

Одной из трудностей управления проектом является эффективное распределение ресурсов. Это объясняется следующими причинами.

1. Необходимо, чтобы общая величина ресурсов была относительно стабильной во времени.

2. Ресурсы инвестируются либо в оборудование, имеющее фиксированную стоимость вне зависимости от того, используются оно или нет, либо в оплату труда персонала; и то и другое - специфические и невзаимозаменяемые ресурсы.

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

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

Рис. 1. Изменение факторов принятия управленческих решений в процессе выполнения проекта

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

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

Рис. 2. Планирование и управление проектом

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

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

· передача научно-технической информации для нужд компании от внешних источников и доведение корпоративной политики до проектом;

· обеспечение коммуникаций персонала, занятого маркетингом, производством и финансами, со специалистами ИТ;

· предоставление высокой степени автономии руководителям проектов при сохранении корпоративного контроля за расходованием ресурсов в проекте;

· стиль лидерства, отвечающий социальным и организационным процессам;

· выявление научно-технического профиля компании;

· стимулирование творчества персонала.

4 Контроль за реализацией проекта

Есть такая замечательная методика - Cost/ Schedule Control Systems Criteria (C/SCSC), разработанная в середине 60-х годов МО США для контроля за ходом выполнения работ компаниями-подрядчиками (в некомпьютерных областях). Она позволяет простыми способами отслеживать этот процесс и первоначально основывалась на 35 критериях. В дальнейшем C/SCSC несколько раз улучшалась, на ее основе был создан ряд новых методологий, однако она не теряет актуальности и сегодня, особенно с ростом интереса к подобным разработкам со стороны софтверных компаний.

В самом упрощенном (но все равно полезном) виде с помощью C/SCSC можно контролировать ход выполнения проекта по двум наиболее важным критериям - срокам и бюджету. Центр логистики ВВС США в Оклахоме (первая государственная организация США, сертифицированная в 1996 г. по четвертому уровню CMM), насчитывающий 600 сотрудников, использует эту методику с 1985 г., и за 15 лет ни в одном из множества своих проектов не превысил сроки и бюджет. А среди его проектов - такие, например, как создание системы управления оружием для бомбардировщиков B-1 и B-2.

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

Ход выполнения проекта отслеживается на графике с нормализованными осями "сроки - бюджет". (C/SCSC рекомендует применять несколько критериев оценки. Центр логистики начинал с четырех критериев, это были, в частности, различные индексы производительности. Сегодня он использует 10 критериев, планируя увеличить их число до 64.)

Зеленая область определяет допустимые комбинации значений "срок/бюджет". Прямая 1 показывает идеальный ход проекта. В красной точке проект должен завершиться.

Допустим, в некоторый момент времени (сегодня) проверяется выполненный объем работ (пропорциональный освоенному бюджету или трудозатратам). Соответствующая точка отмечается на линии "сегодня" и через нее проводится прямая 2. Это значение несколько ниже запланированного (точки пересечения линии "сегодня" с прямой 1), что говорит о замедлении темпа работ. Место пересечения прямой 2 с линией, определяющей бюджет проекта (верхняя граница зеленого прямоугольника), обозначит момент завершения проекта. По его отклонению от планируемой величины получим прогнозируемую задержку срока.

Реальные затраты на выполненный объем работ (заложенный в бюджет), как правило, больше планируемых. Отложив на линии "сегодня" соответствующую точку, проведем через нее линию 3. В месте ее пересечения с датой затянутого завершения проекта рассчитывается реальный размер бюджета и его перерасход.

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

Вычисляемые на основе показателей "сроки/бюджет" различные индексы в соответствии с C/SCSC могут находиться в зеленой (нормальной), желтой (опасной) и красной (критической) зонах. В нашем случае показателей два. Если только один из них расположен в зеленой зоне, то проект еще можно закончить в сроки и уложиться в бюджет; когда показатели находятся в желтой и красной зонах, проект, скорее всего, постигнет неудача. Оба показателя в красной зоне - провал проекту гарантирован.

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

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

В пилотные проекты, ведущиеся с использованием C/SCSC, рекомендуется закладывать значительные резервы по каждому из критериев (срокам и бюджету). В дальнейшем на основании накопленного опыта величину этого резерва можно снижать.

Как добиться успеха в безнадежных проектах

Константин Берлинский

17.10.2002

Многим руководителям ИТ-проектов знакомы ситуации, когда прекрасно спланированный процесс не укладывается во временные рамки. Несмотря на то что сроки были определены с запасом, одни модули «забирают» все доступные ресурсы, другие сразу после появления на свет удаляются за ненадобностью, а постоянные изменения требований окончательно разрушают проект.

Все это признаки типичного безнадежного проекта [1]. Интерес к способам решения проблем, возникающих в процессе разработки проектов, не ослабевает. Основной методологией разработки в нашей организации является Rational Unified Process (RUP), поэтому представленные в статье решения ориентированы на продукты компании Rational Software. Однако тех же результатов можно достичь, используя аналогичные инструменты.

Основные черты безнадежных проектов изложены в [2]; там же рассказывается, что делает их таковыми и как их распознать еще до принятия стратегических решений. Напомним факторы, которые переводят проекты в разряд безнадежных:

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

§ проблемы проектирования: концептуальная неполнота и противоречивость; отсутствие единой терминологии; недостаточная инкапсулированность модулей;

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

Информационную систему крайне трудно разрабатывать без четкой методологии. В своих проектах мы используем адаптированную под наши нужды технику RUP. При этом артефакт Business Vision становится Концепцией Системы, документом на 5-10 страниц, описывающим основные архитектурные моменты информационной системы. Business Use Case Model в нашем понимании становится Техническим Заданием (ТЗ), документом, который согласовывается с заказчиком и описывает информационную систему с его точки зрения. Составные части ТЗ: бизнес-процесс, организационная структура предприятия, состав документов, технология проекта, различные поясняющие диаграммы (схема движения информации, основные потоки работ и т.п.). Далее, мы выделяем Технический Проект (Analysis Model), в котором описывается вид на систему с точки зрения программистов: структура выходных форм; список запросов и таблицы базы данных; внешние интерфейсы; доступные модулям процедуры сервера приложений и перечень функций каждого модуля.

На рис. 1 отображено распределение ролей в проекте. Системный аналитик пишет ТЗ и согласовывает его с заказчиком, проектировщик делает ТП и ставит задачи программистам. Реализованная информационная система тестируется отделом контроля качества совместно с программистами и представителями заказчика; в случае успеха отдел тиражирования занимается внедрением программного обеспечения.

Рис. 1. Методология разработки проектов

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

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

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

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

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

К сожалению, «идеальных» заказчиков мало и проблемы прозрачности и изменяющихся требований приходится решать иными методами. Для наглядности информации в ТЗ мы применяем графические стереотипы основных терминов и понятий системы; до написания кода приложений согласуем формы интерфейса, а текущая бизнес-модель, автоматически сформированная модулем WebPublisher из Rational Suite, всегда доступна для просмотра в формате HTML. В случае изменения бизнес-требований заказчик сообщает об этом системному аналитику, и тот исправляет модель информационной системы. Проектировщик определяет масштабы изменения и отражает их в ТП, а затем передает новую постановку задач программистам (рис. 2).

Рис. 2. Технология цикла разработки

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

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

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

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

Непонимание между заказчиком и разработчиком требует создания единого словаря терминов разрабатываемой информационной системы. У нас такой глоссарий системы представляет собой продукт совместной разработки системного аналитика и проектировщика. С учетом того, что модели ТЗ и ТП создаются с помощью CASE-инструментария Rational Rose, мы используем возможность автоматизированного управления глоссарием, который находится в отдельной модели, доступной по сети всей команде. Только один человек добавляет или модифицирует данные глоссария, остальные же автоматически получают его текущую версию при работе со своими моделями. Эта возможность обеспечивается за счет синхронизации информации в разрабатываемой модели (\\Project.mdl) и глоссария, встроенного «по ссылке» в модель, но в то же время существующего отдельно (\\Glossary.cat). Благодаря этому становится реальной параллельная работа системных аналитиков и проектировщиков при централизованном управлении глоссарием и последовательной обработке запросов на его изменение (рис. 3).

Рис. 3. Работа с глоссарием

Для разделения информационных систем на модули используется множество методов -- от описания предметной области на английском языке (при этом существительные станут классами, а глаголы их методами), до практики использования CRC-карт (Class-Responsibility-Collaborator -- идентификация объектов информационных систем, меры их «ответственности» и механизма взаимодействия). Наше решение зависит от требований заказчика, штатной структуры компании и функциональных обязанностей служащих. При этом обеспечивается максимальная интеграция с уже существующим программным обеспечением; автоматизируются только те участки, в которых возникла необходимость и которые реально переработать за установленные сроки и в конкретных условиях, остальное же остается «как есть» и разрабатываются «переходники» для связи между «новыми» и «старыми» модулями.

Среди проблем собственно кодирования, следует выделить нежелание использовать компоненты сторонних производителей; между тем, часто дешевле купить готовый модуль, чем разработать, протестировать и внедрить собственный. При написании кода также могут использоваться готовые программные конструкции, так называемые «паттерны» (design pattern). Последняя версия Rational Rose XDE поддерживает паттерны и интегрирует их с Visual Studio.Net.

Хорошим проектным решением является стандарт на оформление программных форм, нормативы на количество и размеры информационных и управляющих элементов, характеристики цветовой гаммы и т.п. Помочь в данном случае может стандартный репозиторий программных форм. Кроме того, программный код обязательно оформлять с учетом так называемых «правил кодирования», приняв соглашение по форматированию, названиям объектов, механизмам использования памяти и обработки ошибок и т.п. Нашей организации разработать полноценный стандарт кодирования еще предстоит, поэтому пока для нужд непосредственно программирования используется репозиторий объектов. Сотрудник, ответственный за техническую поддержку репозитория, модифицирует его с учетом изменяющихся требований по функциональности и эффективности форм. Кроме того, в связи с использованием метода round-trip engineering (синхронизация между кодом и моделью в обоих направлениях) с помощью RoseDelphiLink_3_2, разработано положение о документировании программного кода, цель которого -- автоматическое получение документации через шаблоны Rational SoDA. В перспективе будет использоваться инструментарий компании BoldSoft, средства которого вошли недавно и в Borland Delphi7 Architect Studio.

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

Рис. 4. Эффективность различных видов коммуникаций

Мы решили задачу автоматизированного создания и модификации ТЗ и ТП за счет использования шаблонов Rational SoDA. При этом из моделей Rose формируются готовые файлы в формате Word, соответствующим образом оформленные и готовые для согласования (рис. 5). Таким образом, достигается главная цель -- налаживается взаимодействие удаленных друг от друга участников проектной команды, а ее создание не является обременительным процессом.

Рис. 5. Принцип работы автодокументирования

И последний вопрос -- тестирование, которому по-прежнему уделяется мало внимания. Между тем, сохраняет свою актуальность мнение, высказанное в [1]: 1/3 времени проекта должно занимать планирование, 1/6 -- написание программ, 1/4 -- тестирование компонентов и предварительное системное тестирование, 1/4 -- системное тестирование при наличии всех компонентов. В нашей организации имеются планы по использованию средств типа Ghost, TestComplete, систем сбора дефектов (Rational ClearQuest), программ определения утечки памяти, «охват» кода и скоростные параметры функций (Rational Purify, PureCoverage и Quantify), но из-за недооцененности этих проблем тестирования руководством, серьезных инвестиций в данную область пока нет. Одним из показателей зрелости ИТ-компании, как известно, является наличие у нее стандарта тестирования, где представлена функциональная модель тестирования, определены сроки, роли и обязанности участников, изготовлены тестовые классы, подсистемы, скрипты, инструменты, имеется соответствующая документация.

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

Литература

1. Ф. Брукс. Мифический человеко-месяц. М.: Символ, 2005

2. Э. Йордан. Путь камикадзе. М.: Лори, 2006

3. А. Коуберн. Каждому проекту своя методология, TR 99.04, 1999, Oct.