Тема 26. Организация системы управления IT-проектами
План лекции
1. Проблемы: дефицит сроков, фондов и компетенций
2. Стандарты и модели управления жизненным циклом ИС
3. Онтологии как средство формализации знаний в системах управления IT-проектами
1.Проблемы: дефицит сроков, фондов и компетенций
В современном мире информационные технологии получают всеболее широкое применение. С каждым годом объем рынка информационных услуг увеличивается, возрастает сложность разрабатываемых систем. Вместе с ростом объемов и сложности информационныхсистем ужесточаются требования к качеству выпускаемых продуктов.
При этом наиболее критичной становится проблема управления разработкой программного обеспечения в информационно-технологической (ИТ) компании.
Численность современных проектных команд достигает сотени более человек, непосредственно участвующих в производственномпроцессе. Создание программных систем становится технологией, гдеу каждого члена проектной команды определены свое место и кругобязанностей, где строго регламентированы все этапы – от замысла до передачи пользователям рабочей версии программы. Это единственный путь к созданию больших и малых программных систем, который позволяет уложиться в установленные сроки и выделенныйбюджет, обеспечив при этом систему требуемого качества.
При разработке современных проектов возникает ряд сложностей: сжатые сроки разработки, сокращенные бюджеты, недостаточное количество квалифицированных ресурсов. В связи с этим, руководителям проектов приходится постоянно модифицироватьподходы к управлению. Мероприятия, вводимые на первом этаперазработки, могут впоследствии оказаться мало эффективными, таккак средства, затраченные на внедрение мероприятий, превышаютэффект от них. Каждый день руководитель проекта сталкиваетсясо сложной задачей выбора правильного решения. При этом в миреежегодно разрабатываются тысячи проектов, использующих десятки методологий и сотни подходов. При внедрении каждого подходанаблюдаются определенные результаты, которые могли бы быть использованы на других проектах, помогая выбрать правильный путьразвития. Но, чтобы это стало возможным, необходимо выполнитьряд сложных задач:
1) корректно оценить состояние текущего проекта, выявив специфичные характеристики используемых процессов;
2) идентифицировать риски, которые могут наступить при текущем состоянии проекта;
3) провести анализ проекта и осуществить прогноз дальнейшегоразвития проекта;
4) выбрать подходы разработки и управления, которые позволятминимизировать возникновение рисков;
5) провести мониторинг внедренных подходов, оценить их эффективность, определить корректирующие мероприятия.
При этом указанные задачи должны выполняться периодически, так как ситуация на проекте может изменяться очень быстро.
2.Стандарты и модели управления жизненным циклом ИС
Во всех современных стандартах и методологиях управления жизненным циклом программного обеспечения уделяется значительноевнимание сбору и управлению метриками. Именно метрики позволяют количественно производить мониторинг хода проекта и оценивать его текущее состояние.
Так, в методологии RUP (IBM Rational Unified Process) в рамкахдисциплины «Управление проектом» выделяется задача «Мониторингсостояния проекта». На выходе данной задачи составляется артефакт«Показатели проекта», представляющий собой активное хранилищепоказателей проекта.
В методологии RUP рассматриваются метрики для различныхаспектов проекта:
- ход разработки в форме размера и сложности;
- стабильность в форме частоты изменения требований или реализации, размера или сложности;
- модульность в форме области изменений; качество в форме числаи типа ошибок;
- зрелость в форме частоты появления новых ошибок;
- ресурсы в форме отношения фактических расходов к планируемым.
При этом RUP отмечает, что важнее отслеживать тенденции, чемабсолютные значения метрик.
Модель CMMI (Capability Maturity Model Integration) придает ещебольшее значение сбору и анализу метрик. Четвертый уровень носитназвание «Управляемый количественно», и одной из двух процессныхобластей данного уровня является Quantitative Project Management(количественное управление проектом). Кроме того, необходимостьсбора метрик упомянута уже на втором уровне в процессной областиMeasurementandAnalysis (измерениеианализ). Это означает, что начиная со второго уровня компания должна собирать, анализироватьи управлять метриками[2, 3].
В моделях ускоренной разработки ПО (Agile) процесс сбора и анализа метрик является также значимым. Между выпусками необходимо контролировать основные показатели (ресурсы, качество, время), во время работы над выпуском следует уделять внимание оценке работы проектной команды, на протяжении всего проекта необходимовыполнять мониторинг результатов[4].
Поскольку концепция MSF (Microsoft Solutions Framework) основана на CMMI и Agile, в ней также большое внимание уделяется сбору и анализу метрик. Данный процесс должен выполняться на протяжении всего жизненного цикла ПО.
Ключевые понятия, термины и методы измерений в приложениик программному обеспечению определены в стандарте ISO 15939 «SoftwareEngineering–SoftwareMeasurementProcess» имеждународном словаре метрологии ISO. ISO 15939 также определяет стандартный процесс для измерения характеристик процессов и продуктов.
Метрики в управлении проектами и инструменты их измерения. Метрики программных проектов – это количественные показатели, отражающие их отдельные характеристики; измерение иликомбинация измерений, выполняемая внутри программного проектаили процесса[3].
Измерения могут проводиться:
- для поддержки, инициирования, реализации и изменения процессов и для оценки результатов этих процессов;
- оценки результатов процессов – рабочих продуктов, включая программное обеспечение и документацию;
- оценки проектов: совокупности ресурсов, задач и результатов работы проекта;
- оценки ресурсов: работников, методов и утилит, времени, трудозатрат и бюджета в распоряжении проекта.
Измерения могут производиться в отношении процессов и в отношении непосредственно разрабатываемых продуктов. Измеренияв отношении процесса подразумевают сбор, анализ и интерпретациюколичественной информации о процессе. Измерения используются дляидентификации сильных и слабых сторон процесса и оценки процесса после того, как он реализован и (или) изменен. Это очень важныйаспект использования метрик, поскольку метрики позволяют делатьвыводы об успешности внедрения тех или иных мероприятий на проекте. Измерения в отношении программного продукта включают в себяколичественную оценку его размера, структуры и качества.
Сбор и анализ метрик – это весьма дорогостоящая задача без использования специализированных систем. Метрики должны разрабатываться в соответствии с требованиями клиентов и организации, тестироваться на предмет возможности реализации, должен выполняться постоянный мониторинг эффективности выбранных показателей. Однако в связи с существенными различиями в характере и назначении собираемых показателей достаточно сложно разработатьединую систему управления метриками. Чаще всего сбор различныхгрупп метрик привязывают к специализированным инструментам.
Сбор метрик, связанных с разработкой и получением кода, обычно осуществляют с помощью систем контроля версий. Типичнымипредставителями таких систем являются Subversion и IBM RationalCLEARCASE. Эти системы позволяют управлять версиями разрабатываемого решения и снабжать их необходимыми атрибутами. В атрибутах как раз и осуществляется хранение показателей для дальнейшегоанализа. В системах контроля версий можно осуществлять хранениетаких метрик, как количество строк кода, количество добавленныхкомментариев, сложность написанного кода и другие показатели, связанные непосредственно с кодом.
Метрики, связанные с дефектами и запросами на улучшениепрограммного решения, получают, как правило, с помощью систембаг-трекинга (Bugzilla, IBMRationalCLEARQUEST, REDMINE). Данныесистемы предназначены для управления, отслеживания и храненияошибок и запросов на расширение функциональности программного продукта. Информацию о ресурсах проекта и о финансовой составляющей получают из специализированных систем планирования (Microsoft Project, Rational Portfolio Manager).
Отдельно следует сказать о крупных программных комплексах, позволяющих собирать и управлять метриками из несколькихгрупп. Здесь можно выделить два лидера: система Microsoft VisualStudio Team System и группа продуктов Rational компании IBM.
Данные комплексы представляют собой интегрированное решениедля управления жизненным циклом приложений, в состав котороговходят программные средства, процессы и руководства. В системахиспользуется компонентный принцип построения программногообеспечения с разделением инструментов по ролям и специализациям пользователей.
Все перечисленные системы являются дорогостоящими и не позволяют решать задачу управления метриками комплексно. Наиболеедорогие системы способны автоматизировать сбор метрик в различныхнаправлениях, но производить анализ метрик и, тем более, предлагатькорректирующие мероприятия они не могут. В настоящее время основной проблемой количественного управления проектом является неоднозначность и сложность выбора показателей для отслеживания.
Выбор между минимальным и более широким набором показателей делается на основе параметров проекта и ряда других условий. Необходимо учитывать, например, размер проекта, повышенные требования к безопасности и надежности. Сбор определенных показателей может оговариваться контрактом или руководством компаниив целях поиска способов улучшения в определенных областях. Приэтом не существует универсального решения и рекомендаций длявыбора метрик и руководитель проекта должен самостоятельно выбрать подходящий набор показателей. Ориентируясь на собственнуюинтуицию и опыт, сделать правильный выбор очень не просто. Здесь могла бы помочь информация об опыте использования техили иных метрик в аналогичных по уровню сложности, размеру и тематике проектах. Однако наличие подобных проектов и, тем болеезафиксированных данных о проводимых мероприятиях – явлениередкое. Руководитель проекта ориентируется на свой личный опытработы или, в лучшем случае, на опыт «соседних» проектов внутрисвоей компании. Очевидно, что на основании только этой информации сделать правильные выводы об опыте использования метрикзатруднительно. Другой проблемой является сложность интерпретации результатов и использование полученных данных для предвидения ситуациина проекте. Мало получить необходимые статистические данные, необходимо провести корректно анализ этих данных и понять, какиемероприятия следует проводить для изменения ситуации на проекте.
Современные системы позволяют лишь собирать и накапливать статистические данные о ходе проекта, практически не помогая провестианализ ситуации. Здесь особую роль играет человеческий фактор.
Разный характер измерений приводит к необходимости использования отдельных инструментов управления проектом. Другими словами, для получения исчерпывающей информации о проекте приходится использовать несколько несвязанных или слабо связанныхинструментов. Отсутствие централизованной системы управленияметриками существенно увеличивает стоимость мероприятий, связанных с анализом.
Процесс сбора и анализа метрик не должен существенно усложнятьи удорожать разработку проекта. В настоящее время для сбора и интерпретации результатов требуются существенные дорогостоящие ресурсы. Принцип экономичности управления гласит, что затраты на получение информации не должны превышать эффект, получаемый от ееиспользования. В связи с этим от задачи статистического управленияпроектом зачастую отказываются в пользу классических подходов.
Пути решения проблем управления проектами. С учетом изложенного ранее следует, что необходимо:
- разработать единую централизованную систему управления метриками, использующую универсальный аппарат накопленияи представления данных;
- сделать возможным взаимодействие проектов не только внутриодной организации, но и между компаниями-партнерами. Данноевзаимодействие должно выражаться в реализации единой системызнаний о практиках использования метрик и их полезности дляповышения эффективности проекта;
- создать условия для свободного расширения системы – необходима возможность введения новых предметных областей, характеристик проектов и метрик;
- предоставить поддержку аналитикам и руководителям проектовв интерпретации статистических данных, полученных в ходе мониторинга проектов. Исследователь должен иметь возможностьне только анализировать эффективность проводимых мероприятий по историческому опыту предшествующих проектов, но и получить возможность предвидения ситуации на текущем проекте.
Перечисленные меры помогают руководителю принять правильное решение для реализации проектных мероприятий. Сам по себе сбор метрик практически бесполезен – необходимокорректно интерпретировать результаты. Имея определенный наборпоказателей проекта, можно идентифицировать проектные риски.
При этом для идентификации той или иной проблемы может бытьнедостаточно одной метрики, необходимо анализировать сразу несколько показателей. Данная задача сама по себе является непростой. Для ее решения необходимы аппарат анализа входных данныхи система логического вывода, позволяющая по исходным фактамсделать выводы о возможных рисках. Кроме того, возможные рискидолжны быть классифицированы и снабжены рядом признаков дляих более точной идентификации.
Проанализировав метрики и определив риски, возникает задачапоиска оптимальных методов управления и корректирующих проектных мероприятий. Их выбор должен осуществляться на основанииданных о предметной области проекта, его специфике, выбраннойметодологии разработки. При этом следует учитывать, что к настоящему моменту разработаны десятки методологий управления проектами, сотни полезных практик.
После определения и внедрения корректирующих мероприятий, необходимо проводить мониторинг ситуации на проекте и оценивать эффективность принятых мер. Затем этапы, описанные ранееповторяются.
Важной задачей является предвидение хода развития проекта. Здесь может помочь прогнозирование метрик. При этом следует понимать, что прогнозирование – это отдельная задача, требующаяособого внимания. На качество выполненного прогнозированиявлияет ряд факторов: выбор метода прогнозирования, подход к определению свободных параметров, объем и качество исходных данныхи т. д. Исследования в данной области ведутся одновременно по нескольким направлениям: регрессионные и авторегрессионные модели, нейронные сети. По каждому из направлений создано множествометодов, предложены подходы для определения оптимальной структуры прогнозирующих описаний. Возникает задача в максимальнойстепени автоматизировать процесс прогнозирования. Для этого необходимо единое описание всех имеющихся методов и полученныхпрактических результатов.