Journal influence
Bookmark
Next issue
Abstract:
Аннотация:
Authors: () - , () - , () - | |
Page views: 10005 |
Print version Full issue in PDF (1.32Mb) |
Как показывает опыт, трудность внедрения процесса [1] заключается в том, что при разработке программного изделия (ПИ) главным действующим лицом является человек, который, как известно, обладает и достоинствами, и недостатками. Однако при внедрении процесса приходится сталкиваться больше с недостатками человека, чем с его достоинствами. Причем проявляются прежде всего те недостатки, которые порождены природой человека, – сопротивление всему, что ограничивает его свободу в каком-либо смысле. Этот недостаток проявляется даже тогда, когда некоторое ограничение свободы выбора организационной культуры при проведении работ по созданию ПИ дает положительный результат и приводит к удачному выполнению программного про- екта. Поскольку процесс – это систематизированный набор механизмов, формальных процедур и стандартов, обусловливающий успешное выполнение проекта, то всю деятельность по проекту он ограничивает определенными рамками. Эти рамки воспринимаются многими программистами (особенно программистами со стажем успешной работы) как ограничение свободы в их труде, хотя процесс не несет никаких ущемлений свободы в их творческой деятельности. В таких условиях требуются значительные усилия и терпение со стороны руководства предприятием, чтобы наладить работу программистов по установленному процессу. С ростом совершенства процесса растет набор механизмов, процедур и стандартов, которые необходимо выполнять или соблюдать, что еще в большей степени вызывает сопротивление внедрению процесса со стороны программистов. В этой ситуации для сокращения этапа внедрения процесса необходимо использование автоматизированных средств выполнения механизмов, процедур и соблюдения стандартов. Таким автоматизированным средством является система, описанию которой посвящена настоящая статья. Эта система разработана и применяется в АОЗТ ИДУ с 1998 года; она получила название "Автоматизированная система интегрированного управления проектами (АСС)". С использованием системы АСС происходит объединение деятельности по управлению проектом и технической разработкой ПИ в единый интегрированный проектный процесс. АСС состоит из трех согласованных автоматизированных рабочих мест (АРМ), предназначенных для руководства предприятия, руководителей проектов и разработчиков ПИ. Наибольшими функциональными возможностями из перечисленных АРМов обладает АРМ руководителя проекта. С его помощью можно осуществлять автоматизированное составление и редактирование проектных планов различной степени детализации (годовых, квартальных, месячных, недельных), ведение базы данных проектных планов; персонифицированный сбор и анализ установленных стандартным процессом метрик, ведение метрической базы данных проекта, а также выполнять автоматизированный анализ ошибок и дефектов, допущенных в проекте ПИ, и т.д. С помощью этого АРМа руководитель проекта может легко выявлять надвигающиеся проблемы и вырабатывать действия по их предотвращению. Наиболее простым является АРМ разработчика, в задачи которого входит, в основном, облегчение выполнения разработчиками ПИ часто встречающихся формальных процедур, таких как процедуры ежедневного занесения в метрическую базу данных метрик, определенных метрической программой, а также процедуры заполнения ведомости предъявленных, открытых и закрытых отклонений, выявляемых в проекте.
Архитектура системы АСС, изображенная на рисунке 1, представляет возможности системы АСС. Из рисунка видно, что в локальной сети реализованы и система АСС, и сервер коллективного пользования, в дисковом пространстве которого для каждого проекта выделена достаточная область для реализации системы управления конфигурацией. В этой же области отведено место для создания резервных копий и ведения библиотеки базовых версий создаваемых продуктов. Кроме того, в дисковом пространстве сервера коллективного пользования расположен архив проектов и установлена библиотека процесса, в которой собраны все формальные процедуры и стандарты, а также представлена документация механизмов, введенных стандартным процессом. Библиотека процесса и архив проектов являются ресурсами коллективного пользования.
Для каждого проекта в локальной сети организуется свой сектор, в который включается один АРМ руководителя проекта и несколько (по числу разработчиков) АРМов разработчиков. Архитектура системы АСС на локальной сети позволяет организовать автономное автоматизированное выполнение стандартов и процедур стандартного процесса одновременно в произвольном количестве проектов. Число проектов ограничивается лишь числом секторов, которое можно организовать в конкретной локальной сети. При этом для контроля над соблюдением стандартного процесса будет использоваться единственный АРМ руководства предприятием. Кроме того, такая архитектура обусловливает возможность автономной модификации каждого АРМа системы. АРМ руководителя проекта. Учетная карточка проекта показана на рисунке 2, из которого видно, что в учетную карточку, кроме полного и сокращенного названия проекта, входят ключевые характеристики проекта, установленные документом "Положение о работе", и другие важные характеристики, а также штатное расписание проектной группы, составляемое руководителем проекта в интерактивном режиме. Набор представленных на рисунке 2 характеристик превращают учетную карточку в паспорт проекта, который сопровождает проект в течение всего его жизненного цикла. После запоминания учетной карточки в базе данных проекта инициалы каждого сотрудника из составленного штатного расписания используются во всех базах данных проекта. К ним привязываются метрики и другая информация, необходимая для управления проектом. Инициалы персон штатного расписания, например, используются при распределении ответственности в процессе планирования. По окончании планирования инициалы персон в базе данных проекта оказываются связанными с соответствующими плановыми работами. Все плановые работы сохраняются в базе данных даже для уволенных в ходе выполнения проекта сотрудников. Это сделано для возможности воссоздания неискаженной истории выполнения проекта. Автоматизированные прогнозные расчеты. Система АСС обеспечивает выполнение автоматизированных прогнозных расчетов численности проектной группы и сроков выполнения проекта. Умение правильно прогнозировать характеристики будущих проектов является одним из требований ключевой области второго уровня зрелости "Планирование проекта". Правильно выполненный прогноз характеристик нового проекта позволяет так сбалансировать его ресурсы, чтобы он был завершен в срок, с заданным качеством и без превышения выделенного бюджета.
В основу реализации расчетов положены реальные метрики стандартного процесса, представленные в графическом виде [2]. На рисунке 3 справа по оси абсцисс отложена метрика стандартного процесса, определяющая длительность фазы системного тестирования (27% от общей трудоемкости проекта), и метрика заключительной фазы (2% от общей трудоемкости проекта). Для осуществления прогнозных расчетов руководитель проекта, исходя из своего предшествующего опыта, должен определить предполагаемый объем ПИ в KAELOC и коэффициент риска нового проекта. При затруднениях в определении объема ПИ рекомендуется привлечь независимых экспертов (как правило, не менее трех) и получить их персональные оценки, которые следует усреднить и использовать в дальнейших расчетах полученным средним значением объема ПИ в KAELOC. После установления предполагаемого объема нового ПИ необходимо определить метрику повторного использования результатов предыдущих разработок в новом проекте и определить долю повторного использования для каждой фазы жизненного цикла нового проекта в отдельности. Затем необходимо записать рекомендуемый заказчиком срок разработки, ожидаемый размер ПИ, доли повторного использования в фазах жизненного цикла разработки ПИ в таблицу исходных данных и выполнить расчет требуемой численности. Полученная численность разработчиков будет гарантировать выполнение проекта в срок, если каждый член проектной группы имеет метрику трудоемкости создания ПИ не ниже, чем значение соответствующей метрики стандартного процесса. Если же численность разработчиков окажется неприемлемо большой, можно по удовлетворительному размеру проектной группы определить оценку новой длительности разработки с уменьшенным числом разработчиков. Изменяя величину долей повторного использования во всех фазах жизненного цикла разработки ПИ, производительности или других метрик стандартного процесса, можно найти приемлемые значения срока разработки и численности разработчиков. По окончании расчетов значения метрик, установленные в таблице исходных данных системы АСС, следует принять в качестве значений метрик проектного процесса для нового проекта. Разумеется, в ходе выполнения проекта необходимо постоянно следить за соответствием метрик проектного процесса, положенных в основу плана, фактическим и при необходимости вносить корректирующие воздействия в ход выполнения проекта. Любые изменения в таблице входных переменных, показанной на рисунке 3, приводят к соответствующим изменениям таблицы прогнозируемых показателей и вида графика. Нужный результат в этом случае достигается путем итеративной процедуры, заключающейся в последовательном изменении значений входных переменных. В системе АСС предусмотрен и графический способ изменения входных переменных. Для использования этого режима необходимо активизировать диаграмму рисунка 3, установить визир в положение, соответствующее требуемому сроку завершения проекта, и произвести вычисления прогнозируемого значения численности проектной группы или трудоемкости. Нажатие кнопки "ОТМЕНИТЬ ПЕРЕСЧЕТ ГРАФИКА" позволяет вернуться в состояние, имевшее место до активизации диаграммы, не производя при этом никаких изменений. Нажатие кнопки "РАСЧЕТ ЧИСЛЕННОСТИ" или "РАСЧЕТ ПРОИЗВОДИТЕЛЬНОСТИ" дает возможность автоматически получить новые значения прогнозируемых данных, соответствующих выбранному сроку окончания проекта. Система АСС отслеживает допустимые значения входных переменных, выдавая при неправильном вводе данных предупреждающие сообщения. В окне графического режима (рис. 3) представлено 17 переменных (14 в таблице входных переменных и 3 в таблице расчетных показателей). Всего в модели насчитывается более 100 переменных. Для обеспечения возможности более тонкого управления моделью и получения дополнительной информации о ходе расчета в системе АСС предусмотрен табличный режим работы. Вход в режим обеспечивается нажатием кнопки "ПЕРЕХОД К ТАБЛИЧНОЙ ФОРМЕ". Планирование. АРМ руководителя проекта обеспечивает автоматизированное создание проектных планов разной степени подробности (годовых, квартальных, месячных, недельных) [3]. Наличие иерархии проектных планов позволяет руководителю проекта ежедневно оценивать объем выполненных работ каждым исполнителем. Кроме того, он имеет возможность ежедневного оценивания реальной трудоемкости выполненных работ и сравнения их с плановой трудоемкостью. В результате этого у руководителя проекта появляется возможность еженедельной (ежедневной) корректировки загрузки каждого разработчика, уточнения месячных и квартальных планов, предвидения приближения критических ситуаций и своевременного принятия необходимых действий по их предотвращению. Иными словами, у руководителя проекта появляется в руках эффективный инструмент для управления проектом. Отслеживание и анализ хода выполнения проекта. В АРМе установлены наглядные формы и способы отображения состояния проекта ПИ, определенные процессом [4]. Все формы отчетов генерируются автоматически. Наличие наглядных отчетов о статусе проекта обеспечивает всем заинтересованным лицам, в том числе заказчику, возможность своевременного принятия эффективных мер всякий раз, когда выполнение проекта отклоняется от плановых показателей. В АРМе также выполняется автоматическая генерация ретроспективных метрических отчетов за выбранный период времени. Генерация отчетов может осуществляться в течение жизненного цикла разработки или по завершении проекта. Ретроспективные отчеты являются объективным средством для сохранения и использования накопленного опыта и знаний в прошлом, для увеличения эффективности выполнения текущего проекта или проектов в будущем. Метрическая база данных проекта. Для сбора метрических данных осуществляется ежедневный автоматизированный персонифицированный сбор метрик, определенных стандартным процессом. С целью повышения достоверности, строгого соблюдении правил сбора и хранения метрик в системе АСС используется электронная форма заполнения метрик [5]. Для обеспечения сохранности уровня достоверности собираемых метрик, определенных исполнителем работы, введена защита метрической базы данных от несанкционированного доступа после записи в нее очередных данных, то есть запрещена корректировка метрик в базе данных сразу после их записи и в последующие моменты времени. По метрическим данным осуществляется автоматическая генерация всех метрических отчетов, обусловленных стандартным процессом, отчетов по предотвращению дефектов в проектах и на предприятии в целом, отчетов, которые используются при отслеживании хода выполнения проектов на еженедельных и ежемесячных научно-организационных семинарах. Оценка объема выполнения. Руководитель проекта имеет возможность с использованием специальной экранной формы ежедневно определять объем выполнения плановых работ в процентах и заносить значения в базу данных проекта, после чего эти работы отмечаются специальным образом в таблице проектного плана. Даты фактического окончания плановых работ и затраченная на их выполнение трудоемкость используются для генерации метрических отчетов по проекту и отчетов отслеживания хода выполнения проектов. Предотвращение дефектов. Автоматизация деятельности по предотвращению дефектов подробно описана в [6]. Отметим, что деятельность по предотвращению дефектов в проекте является основой для повышения качества создаваемых продуктов. Поскольку эта деятельность требует определенных затрат личного времени каждого программиста, то деятельность по предотвращению дефектов многими программистами (особенно программистами со стажем успешной работы, которые ошибочно считают, что они в процессе разработки ПИ не допускают отклонений) воспринимается как обуза.
Шаблоны документов. В АРМе руководителя проекта предусмотрено специальное меню установленных стандартным процессом шаблонов, которыми руководитель проекта должен пользоваться при создании поставляемых документов (рис. 4). Каждый шаблон, кроме формы, имеет текстовое содержание, которым следует пользоваться при составлении того или иного документа. Этим достигается не только одинаковая форма всех документов, выходящих из проекта, но и обусловливается смысловое содержание общих разделов в каждом документе. Следует отметить, что достичь полного устного взаимопонимания в вопросах оформления документов со всеми руководителями проектов не удается. Даже тогда, когда содержание каждого документа согласовано с каждым руководителем проекта, все равно найдется кто-либо, который что-то или все сделает не так. Надо признаться, что и использование руководителями проектов шаблонов иногда приводит к подобным результатам. Для исправления таких ошибок в каждом проекте должен быть сотрудник (или группа), которому поручена роль по контролю качества. Этот сотрудник должен обозревать каждый документ, выходящий из проектной группы. Целью таких обзоров является обнаружение отклонений и последующее их устранение. АРМ разработчика. Как отмечалось, АРМ разработчика является самым простым в системе АСС. Однако именно с его помощью осуществляется сбор ежедневных метрик (объективных данных о свойствах проекта, продуктов и процесса). Поэтому очень важно обеспечить сохранность достоверности внесенных данных в метрическую базу. Для этого в АРМе разработчика предусмотрены специальные меры [5]. Заметим, что достоверность метрик определяется добросовестностью и прилежанием разработчика, который вносит метрики в базу данных. Руководитель проекта обязан личным примером показывать важность и необходимость достоверной работы по сбору метрик, так как их накопление в метрической базе является фундаментом, на котором строится управление проектом. АРМ администрации предприятия. Одной из основополагающих установок СММ является постоянный контроль над выполнением проектного плана и соблюдением всех предписаний процесса. Такой
Из рисунков 5-8 видно, что АРМ руководителя предприятия обеспечивает контроль за соблюдением всех установок стандартного процесса. С помощью этого АРМа руководитель предприятия может генерировать все метрические отчеты и отчеты отслеживания (еженедельный, двухнедельный, месячный, ретроспективный), а также все отчеты по качеству. Это дает возможность руководству предприятия постоянно иметь объективную картину хода выполнения каждого проекта и представление о качестве выпускаемых продуктов, а также оценивать уровень соблюдения процесса в каждом проекте. На рисунке 9 показана форма, по которой контролируется наличие плана и почасовая ежедневная загрузка каждого сотрудника проектной группы в любой выбранный отрезок времени жизненного цикла проекта. Такой контроль над планом и почасовой загрузкой сотрудников, а также другие метрические данные создают объективные предпосылки для оценки руководством предприятия значимости в проекте того или иного сотрудника. Оценку значимости сотрудников целесообразно проводить не реже раза в квартал. Полученные оценки следует использовать при принятии решения о возможности повышения сотруднику должностного оклада или о продвижении его вверх по служебной лестнице. Система АСС охватывает автоматизацией деятельность не из всех ключевых областей СММ. В таблице представлены ключевые области модели СММ по уровням зрелости ключевые области, деятельность которых подвергнута автоматизации в полном объеме, отмечена в таблице жирным шрифтом, а частичная автоматизация отмечена курсивом. Такой выбор ключевых областей и автоматизация деятельности в них обусловлены особенностями нашего предприятия, то есть конкретной реализацией стандартного процесса. Система АСС реализована на программных пакетах MS Office 2000 и MS Project 98 с использованием языка программирования Visual Basic for Applications в среде Windows 98, включает 33 модуля, содержащих 235 KAELOC программного кода. После инсталляции "пустая" система занимает на винчестере 2,6 Mb. Список литературы 1. Домарацкий А.Н. Управление улучшением стандартного процесса и качеством программных изделий. //Программные продукты и системы. - 1998. - №4, - С.20-24. 2. Домарацкий А.Н., Домарацкий Я.А. Вероятность обнаружения дефектов во время тестирования программных изделий. //Там же. - 1999. -№4. - С.12-15. 3. Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Автоматизация планирования разработки программных изделий. // Там же. - 1999. -№4. - С.2-8. 4. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Моро- зов В.П. Отслеживание хода выполнения проектов программных изделий. //Там же. - 1998. - №4. - С.29-30. 5. Баранов С.Н., Домарацкий А.Н., Ласточкин Н.К., Моро- зов В.П. Сбор и анализ метрик при выполнении проектов программных изделий. //Там же. - 1998. - №4. - С.24-29. 6. Домарацкий А.Н., Ласточкин Н.К., Морозов В.П. Автоматизация деятельности по предотвращению дефектов в программном проекте. //Там же. - 2000. - №4. - С.2-7. |
Permanent link: http://swsys.ru/index.php?id=851&lang=en&page=article |
Print version Full issue in PDF (1.32Mb) |
The article was published in issue no. № 4, 2002 |
Back to the list of articles