Программные продукты и системы

Как показывает опыт, внедрение стандартного процесса, соответствующего модели СММ [1], в повседневную работу организации требует значительных усилий и времени. В ИДУ эта работа началась с интенсивного обучения всех сотрудников, которое включало несколько курсов по модели СММ и способам практического использования новой методологии. По окончании обучения в ИДУ была организована специальная группа процесса, которая взяла на себя труд по приспособлению методологии модели СММ к конкретным условиям работы ИДУ, то есть по разработке и внедрению стандартного процесса.

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

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

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

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

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

Система PLA реализована на программных пакетах Excel 5.0 и MS Project 4.0 с использованием языка программирования Visual Basic for Application в среде Windows-95. Исходный объем дискового пространства, занимаемого системой на жестком диске, составляет 3,5 Мб. Для нормальной работы системы PLA необходимо иметь процессор не ниже 486, оперативную память не менее 16 Мб, графическую карту и монитор, обеспечивающие разрешение 1024´768 пикселей и высокую цветность (16 бит).

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

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

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

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

Если у руководителя проекта возникают затруднения в определении численности штата проектной группы для нового проекта, то он может воспользоваться модельными расчетами численности штата (см. рис.). В основу модельных расчетов положена модель возникновения и устранения ошибок и дефектов при разработке ПИ заданного качества. Эта модель разработана в ИДУ на базе реальных метрик, полученных в результате более чем трехлетней работы над 12 проектами ПИ для различных предметных областей [2-3]. В [2] приведено подробное описание работы первой версии системы PLA в режиме модельных расчетов, а в [3] рассмотрена уточненная в результате опытной эксплуатации первой версии системы PLA модель возникновения и устранения ошибок и дефектов при разработке ПИ заданного качества.

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

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

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

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

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

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

В соответствии со стандартным процессом отслеживание хода выполнения проекта ПИ строится на ежедневных метриках каждого сотрудника проектной группы, которые хранятся в метрической базе данных проекта. Существует правило: "Нет метрик, нет продвижения вперед". Поэтому очень важно добиться сбора достоверных метрик в проектной группе. Как это делать описано на с. 24-29 настоящего номера журнала.

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

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

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

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

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

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

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

 Список литературы

1. Paulk, M.C., B.Curtis, M.B.Chrissis, Ch.V.Weber (1993). Capability Maturity Model for Software, Version 1.1. CMU/SEI-93-TR-24; ESC-TR-93-177. Key Practices of the Capability Maturity Model, Version 1.1. CMU/SEI-93-TR-25; ESC-TR-93-178. Software.

2. Baranoff S., Domaratsky A., Lastochkin N., Morozov V. An automated system for software project planning  International Conference on Informatics and Control (ICI&C'97 June 9-13, 1997 St.Petersburg). Proceedings. Volume 2 of 3. St.Petersburg. SPIIRAS, 1997 - P.785-795  (1353c.).

3. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Предотвращение дефектов при разработке ПИ. // Программные продукты и системы. – 1998. - №2. -С.2-6