<< Пред.           стр. 1 (из 1)           След. >>

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

 Основные понятия и процессы управления проектами
 Владимир Либерзон
 Дата публикации: 03.09.2003
 Источник: OSP.ru
 В мире уже давно признано, что управление проектами - особая область менеджмента, применение которой дает ощутимые результаты. Профессионалы в этой области высоко ценятся (в США это третья по средней величине оплаты профессия после юристов и врачей), а сама методология управления проектами стала фактическим стандартом управления на многих тысячах предприятий и применяется в той или иной степени практически во всех крупных корпорациях. В прошлом году приняты стандарты управления проектами ANSI, разработан проект стандартов управления проектами ISO 10006.
 В нашей стране не все и не всегда правильно понимают предмет управления проектами, часто путая управление проектами с составлением бизнес-планов. В этой статье мы попытаемся кратко охарактеризовать предмет и сущность управления проектами, основываясь на признанных в мире стандартах этой дисциплины, но с учетом принятых у нас подходов и методов.
 Управление проектами дает ощутимые результаты во всех областях приложений, чем и объясняется растущая популярность этой технологии. Для руководителей информационных служб она представляет интерес и как технология, которую полезно внедрить на своих предприятиях, и как средство управления собственными проектами, к которым можно отнести и разработку программного обеспечения, и внедрение тех или иных информационных систем, и прочие изменения, носящие уникальный характер и временные по своей природе.
 Сущность управления проектами
 Проект - это временное предприятие, предназначенное для создания уникальных продуктов или услуг.
 "Временное" означает, что у любого проекта есть начало и непременно наступает завершение, когда достигаются поставленные цели, либо возникает понимание, что эти цели не могут быть достигнуты. "Уникальных" означает, что создаваемые продукты или услуги существенно отличаются от других аналогичных продуктов и услуг.
 Уникальность продуктов или услуг проекта обусловливает необходимость последовательного уточнения их характеристик по мере выполнения проекта.
 В качестве примеров проектов можно привести строительство, разработку любой новой продукции, проведение ремонтных работ, внедрение информационной системы на предприятии, проведение избирательной кампании, съемки кинофильма и многое другое, что отвечает приведенному определению.
 Управление проектами - это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям, необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта.
 Управление проектами подчиняется четкой логике, которая связывает между собой различные области знаний и процессы управления проектами.
 Прежде всего у проекта обязательно имеются одна или несколько целей. Под целями мы будем далее понимать не только конечные результаты проекта, но и выбранные пути достижения этих результатов (например, применяемые в проекте технологии, система управления проектом).
 Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей. Обычно в число основных критериев оценки различных вариантов исполнения проекта входят сроки и стоимость достижения результатов. При этом запланированные цели и качество обычно служат основными ограничениями при рассмотрении и оценке различных вариантов. Конечно, возможно использование и других критериев и ограничений, в частности ресурсных.
 Для управления проектами необходимы рычаги. Влиять на пути достижения результатов проекта, цели, качество, сроки и стоимость исполнения работ можно, выбирая применяемые технологии, состав, характеристики и назначения ресурсов на выполнение тех или иных работ. Таким образом, применяемые технологии и ресурсы проекта можно отнести к основным рычагам управления проектами. Кроме этих основных существуют и вспомогательные средства, предназначенные для управления основными. К таким вспомогательным рычагам управления можно отнести, например, контракты, которые позволяют привлечь нужные ресурсы в нужные сроки. Кроме того, для управления ресурсами необходимо обеспечить эффективную организацию работ. Это касается структуры управления проектом, организации информационного взаимодействия участников проекта, управления персоналом.
 Проект - это временное предприятие, предназначенное для создания уникальных продуктов или услуг.
 "Временное" означает, что у любого проекта есть начало и непременно наступает завершение, когда достигаются поставленные цели, либо возникает понимание, что эти цели не могут быть достигнуты. "Уникальных" означает, что создаваемые продукты или услуги существенно отличаются от других аналогичных продуктов и услуг.
 Уникальность продуктов или услуг проекта обусловливает необходимость последовательного уточнения их характеристик по мере выполнения проекта.
 В качестве примеров проектов можно привести строительство, разработку любой новой продукции, проведение ремонтных работ, внедрение информационной системы на предприятии, проведение избирательной кампании, съемки кинофильма и многое другое, что отвечает приведенному определению.
 Управление проектами - это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить этим требованиям и ожиданиям, необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта.
 Управление проектами подчиняется четкой логике, которая связывает между собой различные области знаний и процессы управления проектами.
 Прежде всего у проекта обязательно имеются одна или несколько целей. Под целями мы будем далее понимать не только конечные результаты проекта, но и выбранные пути достижения этих результатов (например, применяемые в проекте технологии, система управления проектом).
 Достижение целей проекта может быть реализовано различными способами. Для сравнения этих способов необходимы критерии успешности достижения поставленных целей. Обычно в число основных критериев оценки различных вариантов исполнения проекта входят сроки и стоимость достижения результатов. При этом запланированные цели и качество обычно служат основными ограничениями при рассмотрении и оценке различных вариантов. Конечно, возможно использование и других критериев и ограничений, в частности ресурсных.
 Для управления проектами необходимы рычаги. Влиять на пути достижения результатов проекта, цели, качество, сроки и стоимость исполнения работ можно, выбирая применяемые технологии, состав, характеристики и назначения ресурсов на выполнение тех или иных работ. Таким образом, применяемые технологии и ресурсы проекта можно отнести к основным рычагам управления проектами. Кроме этих основных существуют и вспомогательные средства, предназначенные для управления основными. К таким вспомогательным рычагам управления можно отнести, например, контракты, которые позволяют привлечь нужные ресурсы в нужные сроки. Кроме того, для управления ресурсами необходимо обеспечить эффективную организацию работ. Это касается структуры управления проектом, организации информационного взаимодействия участников проекта, управления персоналом.
 Информация, используемая в управлении проектами, обычно не бывает стопроцентно достоверной. Учет неопределенности исходной информации необходим и при планировании проекта, и для грамотного заключения контрактов. Анализу и учету неопределенностей посвящен анализ рисков.
 Любой проект в процессе своей реализации проходит различные стадии, называемые в совокупности жизненным циклом проекта. Для реализации различных функций управления проектом необходимы действия, которые в дальнейшем именуются процессами управления проектами.
 Процессы управления проектами
 Управление проектами - интегрированный процесс. Действия (или их отсутствие) в одном направлении обычно влияют и на остальные направления. Такая взаимосвязь заставляет балансировать между задачами проекта - часто улучшение в одной области может быть достигнуто лишь за счет ухудшения в другой. Для лучшего понимания интегрированной природы управления проектами опишем его через процессы, из которых оно состоит, и их взаимосвязи.
 Проект состоит из процессов. Процесс - это совокупность действий, приносящая результат. Процессы проекта обычно выполняются людьми и распадаются на две основные группы:
 * процессы управления проектами - касающиеся организации и описания работ проекта (которые будут подробно описаны далее);
 * процессы, ориентированные на продукт - касающиеся спецификации и производства продукта. Эти процессы определяются жизненным циклом проекта и зависят от области приложения.
 В проектах процессы управления проектами и процессы, ориентированные на продукт, накладываются и взаимодействуют. Например, цели проекта не могут быть определены при отсутствии понимания того, как создать продукт.
 Процессы управления проектами могут быть разбиты на шесть основных групп, реализующих различные функции управления:
 * процессы инициации - принятие решения о начале выполнения проекта;
 * процессы планирования - определение целей и критериев успеха проекта и разработка рабочих схем их достижения;
 * процессы исполнения - координация людей и других ресурсов для выполнения плана;
 * процессы анализа - определение соответствия плана и исполнения проекта поставленным целям и критериям успеха и принятие решений о необходимости применения корректирующих воздействий;
 * процессы управления - определение необходимых корректирующих воздействий, их согласование, утверждение и применение;
 * процессы завершения - формализация выполнения проекта и подведение его к упорядоченному финалу.
  Рис. 1. Наложение групп процессов в фазе Процессы управления проектами накладываются друг на друга и происходят с разной интенсивностью на всех стадиях проекта, как показано на рис. 1.
 Кроме того, процессы управления проектами связаны своими результатами - результат выполнения одного становится исходной информацией для другого. Эти взаимосвязи проиллюстрированы на рис. 2.
  Рис. 2. Взаимосвязи групп процессов управления проектами в фазе И наконец, имеются взаимосвязи групп процессов различных фаз проекта. Например, закрытие одной фазы может являться входом для инициации следующей фазы (пример: завершение фазы проектирования требует одобрения заказчиком проектной документации, которая необходима для начала реализации).
 В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться.
 Повторение инициации на разных фазах проекта помогает контролировать актуальность выполнения проекта. Если необходимость его осуществления отпала, очередная инициация позволяет вовремя это установить и избежать излишних затрат.
 Взаимосвязи процессов
 Процессы инициации
 Инициация включает единственный подпроцесс - авторизацию, то есть решение начать следующую фазу проекта.
 Процессы планирования
 Планирование имеет большое значение для проекта, поскольку проект содержит то, что ранее не выполнялось. Естественно, что планирование включает сравнительно много процессов. Однако не следует считать, что управление проектами - это в основном планирование. Усилия, прилагаемые для планирования, следует соизмерять с целями проекта и полезностью полученной информации.
 Напомним, что следует различать цели проекта и цели продукта проекта, под которым понимается продукция (или услуги), созданная или произведенная в результате исполнения проекта.
 * Цели продукта - это свойства и функции, которыми должна обладать продукция проекта.
 * Цели проекта - это работа, которую нужно выполнить для производства продукта с заданными свойствами.
  Рис. 3. Взаимосвязи процессов планирования Взаимосвязи между процессами планирования представлены на рис. 3.
 В ходе исполнения проекта эти процессы многократно повторяются. Изменениям могут подвергнуться цели проекта, его бюджет, ресурсы и т. д. Кроме того, планирование проекта - это не точная наука. Различные команды проекта могут разработать различные планы для одного и того же проекта. А пакеты управления проектами могут составить различные расписания выполнения работ при одних и тех же исходных данных.
 Некоторые из процессов планирования имеют четкие логические и информационные взаимосвязи и выполняются в одном порядке практически во всех проектах. Так, например, сначала следует определить, из каких работ состоит проект, а уж затем рассчитывать сроки выполнения и стоимость проекта. Эти основные процессы выполняются по нескольку раз на протяжении каждой фазы проекта.
 Кроме перечисленных основных процессов планирования имеется ряд вспомогательных процессов, необходимость в использовании которых сильно зависит от природы конкретного проекта:
 * планирование качества - определение того, какие стандарты качества использовать в проекте, и того, как этих стандартов достичь;
 * планирование организации - определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации;
 * назначение персонала - назначение человеческих ресурсов на выполнение работ проекта;
 * планирование взаимодействия - определение потоков информации и способов взаимодействия, необходимых для участников проекта;
 * идентификация риска - определение и документирование событий риска, которые могут повлиять на проект;
 * оценка риска - оценка вероятностей наступления событий риска, их характеристик и влияния на проект;
 * разработка реагирования - определение необходимых действий для предупреждения рисков и реакции на угрожающие события;
 * планирование поставок - определение того, что, как и когда должно быть поставлено;
 * подготовка условий - выработка требований к поставкам и определение потенциальных поставщиков.
 Взаимосвязи между вспомогательными подпроцессами, как и само их наличие, в большой мере зависят от природы проекта.
 Процессы исполнения и контроля
  Рис. 4. Взаимосвязи процессов исполнения Под исполнением подразумеваются процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для того, чтобы выявить отклонения от намеченного плана и оценить их влияние на проект. Регулярное измерение параметров проекта и идентификация возникающих отклонений далее также относится к процессам исполнения и именуется контролем исполнения. Контроль исполнения следует проводить по всем параметрам, входящим в план проекта.
 Как и в планировании, процессы исполнения (рис. 4) можно подразделить на основные и вспомогательные.
 К основным можно отнести сам процесс исполнения плана проекта.
 Среди вспомогательных процессов отметим:
 * учет исполнения - подготовка и распределение необходимой для участников проекта информации с требуемой периодичностью;
 * подтверждение качества - регулярная оценка исполнения проекта с целью подтверждения соответствия принятым стандартам качества;
 * подготовка предложений - сбор рекомендаций, отзывов, предложений, заявок и т. д.;
 * выбор поставщиков - оценка предложений, выбор поставщиков и подрядчиков и заключение контрактов;
 * контроль контрактов - контроль исполнения контрактов поставщиками и подрядчиками;
 * развитие команды проекта - повышение квалификации участников команды проекта.
 Процессы анализа
 Процессы анализа включают как анализ плана, так и анализ исполнения проекта.
 Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана командой и другими участниками проекта. На стадии планирования результатом анализа плана может быть принятие решения о необходимости изменения начальных условий и составления новой версии плана либо принятие разработанной версии в качестве базового плана проекта, который в дальнейшем служит основой для измерения исполнения. В дальнейшем изложении анализ плана не выделяется в качестве отдельной группы процессов, а включается в группу процессов планирования, делая эту группу процессов по своей природе итеративной. Таким образом, под процессами анализа в дальнейшем понимаются процессы анализа исполнения.
  Рис. 5. Взаимосвязи процессов анализа Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования. В силу уникальности проектов эти критерии не являются универсальными, но для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество и стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями.
 Процессы анализа также можно подразделить на основные и вспомогательные.
 К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта:
 * анализ сроков - определение соответствия фактических и прогнозных сроков исполнения операций проекта директивным или запланированным;
 * анализ стоимости - определение соответствия фактической и прогнозной стоимости операций и фаз проекта директивным или запланированным;
 * анализ качества - мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определения путей устранения причин нежелательных результатов исполнения качества проекта;
 * подтверждение целей - процесс формальной приемки результатов проекта его участниками (инвесторами, потребителями и т. д.).
 Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают:
 * оценку исполнения - анализ результатов работы и распределение проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта;
 * анализ ресурсов - определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов плановым значениям.
 В число процессов анализа не включены анализ взаимодействия с целью оптимизации процедур обработки информации, анализ исполнения контрактов с целью своевременного внесения изменений и предотвращения споров и ряд других процессов, которые не носят регулярного характера (как анализ взаимодействия) либо составляют часть включенных процессов (как анализ контрактов).
 В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному ранее плану, либо определяется необходимость применения корректирующих воздействий.
 Процессы управления
 Управление исполнением проекта - это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта. Если исполнение проекта происходит в соответствии с намеченным планом, то управление фактически сводится к исполнению - доведению до участников проекта плановых заданий и контролю их реализации. Эти процессы нами включены в процессы исполнения.
  Рис. 6. Взаимосвязи процессов управления Другое дело, если в процессе реализации возникли отклонения, анализ которых показал, что необходимо определение и применение корректирующих воздействий. В этом случае требуется найти оптимальные корректирующие воздействия, скорректировать план оставшихся работ и согласовать намеченные изменения со всеми участниками проекта. Итак, процессы управления предназначаются для определения, согласования и внесения необходимых изменений в план проекта. Такие процессы управления часто называются управлением изменениями и инициируются процессами анализа (рис. 6).
 К основным процессам управления, встречающимся практически в каждом проекте, относятся:
 * общее управление изменениями - определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту;
 * управление ресурсами - внесение изменений в состав и назначения ресурсов на работы проекта;
 * управление целями - корректировка целей проекта по результатам процессов анализа;
 * управление качеством - разработка мероприятий по устранению причин неудовлетворительного исполнения.
 Среди вспомогательных процессов управления отметим:
 * управление рисками - реагирование на события и изменение рисков в процессе исполнения проекта;
 * управление контрактами - координация работы (суб)подрядчиков, корректировка контрактов, разрешение конфликтов.
 Процессы завершения
  Рис. 7. Взаимосвязи процессов завершения Завершение проекта сопровождается следующими процессами (рис. 7):
 * закрытие контрактов - завершение и закрытие контрактов, включая разрешение всех возникших споров;
 * административное завершение - подготовка, сбор и распределение информации, необходимой для формального завершения проекта.
 Методы и технологии реализации перечисленных процессов, их интеграция составляют сущность управления проектами. Обратите внимание, что все перечисленные процессы приложимы к проектам любой природы - и к строительным, и к информационным, и к любым другим. Однако имеются и существенные отличия в управлении проектами различных типов. Следует также отметить, что успешное внедрение системы управления проектами связано с определенной организационной перестройкой и с внедрением специализированных программных средств. Перечисленные вопросы, а также специализированные методы решения отдельных задач управления проектами, технология, опыт и проблемы внедрения будут раскрыты в последующих публикациях.
 Литература
 1.
 1. A Guide to the Project Management Body of Knowledge . Project Management Institute Standards Committee, 1996.
 2. Либерзон В. И. Основы управления проектами. М., 1997.
 3. Эдвард Ферн. Управление проектами Time-to-Profit. М.: Технологии управления Спайдер, 1999.
 Сравнение методов оценки стоимости проектов по разработке информационных систем
 Николай Михайловский
 Дата публикации: 22.06.2003
 Сайт: www.pmprofy.ru
 Всякий, кто участвовал в проектах по разработке информационных систем, сталкивался с проектами, которые не завершались в срок, превышали бюджет или были сданы с недостаточной функциональностью для того, чтобы системой можно было пользоваться. Основными источниками этих печальных результатов являются:
 * Плохое управление проектом
 * "Плывущие" требования
 * Неправильная оценка проекта
 Мы не будем здесь рассматривать вопросы управления проектами, а сосредоточимся на двух последних проблемах, сводящихся к адекватной оценке стоимости проекта. Адекватная оценка стоимости проекта важна как для заказчика, так и для исполнителя проекта. Данный доклад анализирует четыре основные модели оценки трудремкости разработки информационных систем и предлагает способы использования моделей типа функциональных точек при управлении проектами разработки информационных систем и контрактами по их разработке.
 "Плывущие" требования
 Хотя все и ругаются на них, в плывущих требованиях есть одна большая истина - информационная система должна отвечать потребностям заказчика. Причины изменения требований достаточно ясны:
 * Постепенное понимание заказчиком того, что же ему на самом деле нужно
 * Изменение бизнеса заказчика за время реализации проекта
 Понятны и негативные следствия плывущих требований:
 * Разногласия между заказчиком и поставщиком
 * Превышения сроков
 * Работа, сделанная впустую.
 * Превышение бюджетов и финансовые потери
 Неправильная оценка проекта
 О неправильной оценке проекта, как важном источнике проблем проекта (причем таких, с которыми никакими средствами и подходами к управлению проектами не справиться!), почему-то очень мало вспоминают. Наверное, просто неприятно вспоминать. Основные причины неправильной оценки проекта:
 * Отсутствие опыта или методики оценки проекта
 * Непредвиденные проблемы в используемых средствах и компонентах
 * Непонимание ключевых технических проблем проекта
 Контрактная сторона вопроса
 Естественно, все вышеописанные проблемы в первую очередь упираются в деньги. А раз в деньги, то, значит, и в контракты, по которым эти деньги выплачиваются (или, не приведи господь, не выплачиваются). Значит, важно составить контракт так, чтобы обе стороны выигрывали. При этом, на наш взгляд, вопрос упирается в едницу имерения контракта.
 Наиболее популярые единицы измерения - время и проект.
 Если в качестве единицы измерения используется время, то оплата исполнителю, как правило, производится регулярно (например, раз в месяц или раз в две недели). Преимуществом такого способа является то, что исполнтель не связан рамками контрактных стоимостей и запросы покупателя выполняются без вопросов и не вызывают пререканий (любые желания за ваши деньги). Недостатками является то, что все риски на покупателе, и в такой ситуации покупатели стремятся к микроменедменту со всеми вытекающими последствиями.
  Если в качестве единицы измерения используется проект, то оплата производится после окончания значимых этапов проекта. Преимуществом такого способа является то, что бюджет заказсика четко определен, или, по крайней мере, четко отслеживается. Недостатками является то, что все риски на исполнителе, он стремится ограничить функциональность и изменения
 Вввиду всего вышесказанного, зотелось бы иметь едницу измерения проекта такую, которая:
 * непрерывно зависит от сложности проекта и позволяет изменять оценку размера проекта с изменением требований;
 * приложима на всех стадиях жизненного цикла системы., причем на различных этапах жизненного цикла проекта его эффективность определяется заново, с различной глубиной проработки;
 * давала бы независимые оценки времени выполнения проекта и его трудоемкости;
 * позволяет распределить риски по-честному;
 Методы оценки размера проектов
 Методы оценки размера проектов разделяются на две основные группы: микрооценка и макрооценка.
 *
 * Методы микрооценки основаны на точном знании процесса. Такова, например, Oracle AIM и оценки трудоемкости для него. В любом случае, когда для построения оценки необходимо построение разбивки работ и оценка каждой индивидуальнрой работы (разделяй и властвуй), метод является методом микрооценки
 * Методы макрооценки, основанные на функциональных требованиях и/или продукте. Таковы методы функциональных точек и методы типа СОСОМО
 В данном докладе мы не будем рассматривать методы микрооценки. Мы рассмотрим с позиций, приведенных выше. Следующие методы макрооценки:
 * IFPUG FPA
 * COCOMO II
 * модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году
 * FPA mkII
 * Основные модели для определения объемов работ при разработке информационных систем
 Вероятно, одним из наиболее известных моделей данного рода является конструктивная модель стоимости (Constructive Cost Model - COCOMO), разработанная в конце 70х годов Барри Боэмом . Построенная на основе анализа ряда проектов, выполненных в основном в интересах Министерства Обороны США, она устанавливает соответствие между размером системы в тысячах условных строк кода и "классом" проекта, с одной стороны, и трудоемкостью разработки системы, с другой стороны.
 Базовый тип модели COCOMO учитывает только класс проекта - естественный, полуинтегрированный, "встроенных систем". Естественные проекты - относительно маленькие и разрабатываются командами, знакомыми с прикладной областью. Полуинтегрированные проекты - системы среднего размера и сложности, разрабатываемые группами разработчиков с различным опытом. Проекты "встроенных систем" выполняются при значтельных аппаратных, программных и организационных ограничениях.
 Промежуточный тип модели вводит 15 поправочных факторов, принадлежащих к одной из четырех категорий: атрибуты продукта, такие, как его сложность и требования к его надежности; атрибуты системы, такие, как ограничения на оперативную память и время выполнения; атрибуты команды, такие, как опыт в прикладной области; и атрибуты проекта, такие, как используемые средства разработки. Продвинутый тип модели дополнительно вводит разбиение по стадиям жизеннного цикла.
 Существенным недостатком данной модели является ее основанность на тысячах условных строк кода, как метрике размера программного комплекса. Видимо, одной из первых попыток отойти от данной метрики размера ПО была разработка Аланом Альбрехтом (Alan Albrecht) в середине 70-х годов метода функциональных точек с целью разработки механизма предсказания усилий, сопряженных с разработкой программных систем. Метод был впервые опубликован в 1979 году. В 1984 году Альбрехт усовершенствовал свой метод и с 1986 года, в котором была сформирована Международная Ассоциация Пользователей Функциональных Точек (International Function Point User Group - IFPUG), было опубликовано несколько ревизий метода.
 Чарльз Саймон (Charles Symon) разработал другой, аналогичный, но несколько более логичный и использующий более современную терминологию, метод функциональных точек Mark II. В отличие от FPA IFPUG, MK II FPA использует единое понятие транзакции, имеющей вход, обработку и выход. MK II FPA принят в качестве национального стандарта Великобритании.
 Другими аналогичными методами, которые мы здесь не рассматриваем, являются Feature Points, разработанный Кэйперсом Джонсом (Capers Jones) 3D Points, разработанный в компаниии Боинг (Boeing) и Function Points.
 Со временем модель СОСОМО оказалась устаревшей в значительной своей части. Поэтому на ее основе была разработана модель СОСОМО II, опубликованная в 1999 году. Она усовершенствует оригинальную модель в следующих основных направлениях:
 * использование входных данных, доступных на ранних этапах жизненного цикла системы для оценки ее сложности (в частности, использование функциональных точек);
 * подходы, основанные на повторном использовании, включая интеграцию коммерческих продуктов, реинжиниринг, генерацию приложений;
 * объектно-ориентированные подходы, поддерживаемые распеделенным ПО промежуточного слоя;
 * влияние зрелости процессов разработки.
 * новые - циклические и обобщенные - модели процессов разработки;
 В течение восьмидесятых годов в СССР также на основе COCOMO были разработаны собственные модели оценки трудоемкости разработки программных систем, утвержденные Госкомтруда в 1986 году. В них по-своему была решена задача оценки функционального размера программной системы и получения количества тысяч условных машинных команд.
 Параметры для сравнения основных моделей для определения объемов работ при разработке информационных систем
 Перечислим те параметры, по которым можно сравнить описанные выше модели.
 Тип модели
 Каждая из описанных выше моделей так или иначе опирается на статистику выполнения проектов. Назовем модель открытой, если модель предусматривает возможность сбора и использования пользователем модели статистики, специфичной для организации, отрасли, прикладной области и т.п., в предположении, что на основе этой статистики модель будет давать более точные оценки в рамках применимости собранной статистики. Назовем модель закрытой в противном случае.
 Доступность репозиториев
 В соответствии с вышеизложенным, репозитории проектов с набранной статистикой могут быть доступными публично. Таким образом, чтобы модель была применимой без накопления собственного репозитория, она должна быть либо закрытой, либо открытой с доступными репозиториями.
 Время применения
 Модель может быть применимой в различные моменты жизненного цикла системы. В соответствии с требованиями, модель должна быть применима в течение всего жизненного цикла системы.
 Независимая оценка трудоемкости и времени
 Важным показателем качества модели является независимая оценка трудоемкости и времени, отражающая тот факт, что увеличение количества персонала увеличивает коммуникационные затраты, и таким образом, существует оптимальное количество персонала для проекта.
 Учет факторов размера системы
 Важным показателем качества модели является учет ею нелинейного возрастания сложности разработки системы с ростом ее размера.
 Непрерывная зависимость от сложности проекта
 При добавлении новых небольших функций получаемая оценка сложности проекта должна незначительно возрастать.
 Учет функциональной сложности
 Основным назначением модели является оценка функционального размера системы. От адекватности этой оценки зависит адекватность и успех оценки трудоемкости.
 Учет нефункциональных требований к системе
 Трудоемкость разработки системы также существенно зависит от нефункциональных требований к системе. Полнота и адекватность учета нефункциональных требований к системе существенно влияют на качество модели.
 Поддержка различных жизненных циклов и разбиения по стадиям жизненного цикла
 Желательно, чтобы модель подерживала различные модели жизненного цикла системы и оценку разбиения трудоемкости по стадиям жизненного цикла.
 Учет степени новизны
 Модель может позволять учитывать степень новизны системы - абсолютной либо для конкретных разработчиков.
 Учет использования в разработке типовых элементов
 Модель может позволять учитывать использование в разработке типовых элементов.
 Учет реинжиниринга или конверсии
 Модель может позволять учитывать использование в разработке реинжиниринга или конверсии ранее существовавших приложений.
 Учет интеграции готовых коммерческих продуктов
 Модель может позволять учитывать использование в разработке готовых коммерческих продуктов.
 Учет жесткости требований
 Желательно, чтобы модель отражала степень жесткости требований к системе. Это связано с тем фактом, что жесткость требований к системе повышает трудоемкость ее разработки.
 Учет качества управления проектом, организационных факторов, инфраструктурных факторов, персонала
 Модель может учитывать факторы, связанные с командой, в том числе качество управления проектом, организационные факторы, инфраструктурные факторы, персонал.
 Учет зависимости трудоемкости от средств разработки
 Желательно, чтобы модель отражала зависимость трудоемкости от средств разработки.
 Учет влияния графика на трудоемкость
 Желательно, чтобы модель отражала возрастание трудоемкости разработки в более сжатые сроки.
 Сравнение моделей для определения объемов работ при разработке информационных систем
 В соответствии с вышеизложенным, главными факторами при выборе модели должны являться:
 * Тип модели и доступность репозиториев;
 * Учет факторов размера системы;
 * Непрерывная зависимость от сложности проекта;
 * Учет функциональной сложности;
 * Учет нефункциональных требований к системе;
 * Время применения.
 Данные факторы для анализируемых нами моделей сведены в следующей таблице (Таблица 1).
 Таблица 1 - Основные параметры качества для анализируемых моделей
 Параметр Методика Госкомтруда COCOMO 2.0 FPA IFPUG 4.1 MK II FPA Тип модели Закрытая Закрытая Открытая Открытая Доступность репозиториев Не приложимо Не приложимо Да, множество репозиториев Нет Время применения На протяжении всего жизненного цикла На протяжении всего жизненного цикла после определения требований На протяжении всего жизненного цикла после определения требований На протяжении всего жизненного цикла после определения требований Учет факторов размера системы Да Да На основе репозитория На основе репозитория Непрерывная зависимость от сложности проекта Нет Да Да Да Таблица 2 - Учет требований к системе в моделях
 Параметр Методика Госкомтруда COCOMO 2.0 FPA IFPUG 4.1 MK II FPA Учет функ-циональной сложности Неадек-ватный Да, на основе неcкорре- ктирован-ного количества функ-циональных точек IFPUG Да, на основе cкорректиро- ванного количества функцио-нальных точек IFPUG
  Да, на основе cкоррект- ированного количества функцио-нальных точек MK II Учет нефунк-циональных требований к системе Защита инфор-мации, распа-раллел-ивание вычислений Надежность, объем обрабат-ываемых данных, повторная исполь-зуемость, требования к документи- рованию, измен-чивость платформы, ограничения на производ- ительность, ограничения на хранимые данные. Распред-еленная обработка, Производ-ительность, Загруженность конфигурации, Частота транзакций, повторная исполь-зуемость, Множество инсталляций, Упрощение внесения изменений Распред-еленная обработка, Производ-ительность, Загружен-ность конфигу-рации, Частота транзакций, повторная исполь-зуемость, Множество инстал-ляций, Упрощение внесения изменений, защита информации, требования к документи-рованию Проанализирум подробнее модели на основе этих факторов.
 Время применения и учет факторов размера системы
 Все рассматриваемые модели могут быть применены на протяжении всего жизненного цикла а также адекватно учитывают факторы размера системы.
 Тип модели и доступность репозиториев
 Методика Госкомтруда и COCOMO 2.0 являются закрытыми, а FPA IFPUG4.1 и MK II FPA- открытыми. В то же время авторам неизвестны открытые репозитории статистики MK II FPA. Ввиду последнего обстоятельства, использование MK II FPAв данном проекте представляется сомнительным, несмотря на все остальные преимущества модели.
 Учет функциональной сложности
 Функциональная сложность в моделях COCOMO 2.0 и FPA IFPUG 4.1 оценивается на основе подсчета функциональных точек. Таким образом, в этом смысле эти две модели аналогичны.
 Чтобы сравнить их с методикой Госкомтруда, разберем последнюю несколько подробнее. По этой методике, приближенная общая трудоемкость разработки ПС ( T0) рассчитывается по формуле
  , где
 - базовая трудоемкость разработки ПС;
 - коэффициент сложности ПС.
 - поправочный коэффициент, учитывающий конкретные условия и средства разработки ПС.
 Базовая трудоемкость разработки ПС
 определяется по таблице в зависимости от группы сложности ПС, и от объема ПС ( ).
 Таким образом, ключевым для данной методики является также определение объема ПС и его группы сложности.
 Группа сложности ПС определяется в зависимости от наличия или отсутствия у разрабатываемого ПС одной или нескольких из 11 основных характеристик, приведенных в этой таблице.
 Таблица 3 - Таблица зависимости группы сложности ПС от их характеристик
 Характеристики ПС ЭВМ Группа сложности ПС, обладающие одной или несколькими из следующих характеристик:
 1) наличие мощного интеллектульного языкового интерфейса высокого уровня с пользователем (без учета подсказок и меню функций)
 2) режим работы в реальном времени
 3) обеспечение телекоммуникационной обработки данных
 4) машинная графика
 5) криптография и другие методы защиты информации от несанкционированного доступа
 6) обеспечение существенного распараллеливания вычислений 1 (максимальная
 ПС, не обладающие ни одной из характеристик группы сложности "1", но обладающие одной или несколькими из следующих характеристик:
 1) оптимизационные расчеты
 2) моделирование объектов и процессов
 3) задачи анализа и прогнозирования
 4) сложные экономические, инженерные или научные расчеты
 5) обеспечение настройки ПС на изменения структур входных и выходных данных 2 (средняя) ПС, не обладающие перечисленными выше характеристиками 3 (минимальная) По своему смыслу эта таблица не вызывает каких либо вопросов и возражений, за исключением того, что предполагает облать приложимости существенно шире, чем остальные модели, которые мы рассматривали. Это одновременно означает, что для информационных систем ее точность будет заметно хуже.
 Общий объем разрабатываемого ПС V0
  определяется по формуле:
  ,где
 Vi - объем i-й функции ПС;
  n - общее число функций ПС.
 Объем каждой отдельной функции разрабатываемого ПС (Vi), выраженный числом условных машинных команд, определяется по Каталогу функций ПС для соответствующего типа ЭВМ (больших ЭВМ, малых ЭВМ или ПЭВМ) на основании имеющейся информации о составе функций разрабатываемого ПС.
 Приведенный ниже список функций "Каталога функций ПС" составлен, по утверждению разработчиков модели, "на основе метода структурной аналогии по результатам анализа существующих аналогов ПС". Для каждой из приведенных функций в Каталоге назначено некоторое количество условных машинных команд, в зависимости от типа ЭВМ (большая, малая, средняя).
 Таблица 4 - Каталог функций программных средств ЭВМ
 Номер функции Наименование (содержание) функции 1. Управление работой ПС, ввод и вывод данных 101 Управление работой компонентов ПС 102 Обработка прерываний 103 Ввод данных в интерактивном режиме 104 Вывод данных в табличной форме на экран и на печать 105 Обработка ошибочных ситуаций 106 Система настройки ПС на условия применения 2. Формирование и обработка файлов и баз данных 201 Формирование последовательных файлов 202 Сортировка файлов 203 Обработка файлов 204 Формирование базы данных 205 Обработка записей базы данных 206 Организация поиска и поиск в базе данных 3. Функциональные (прикладные) задачи 301 Статистическая обработка данных 302 Расчет экономических показателей 303 Экономический анализ и прогнозирование 304 Составление сводных балансов Данная таблица, лежащая в сердцевине модели, вызывает наибольшее число возражений. В корне всех этих претензий лежит попытка разработчиков модели объять необъятное. В результате становится неясной граница между различными функциями и отдельными единицами аналогичных функций оказывается размытым. Действительно, методика НЕ дает детального определения НИ ОДНОЙ из функций в вышеприведенной таблице. Это и является ее основным и ключевым недостатком.
 Поскольку использование фактически неопределенной методики при оценке размера критически важного приложения является рискованным, мы не рекомендуем ее применение.
 В нижеприведенной таблице вседено сравнение методик по остальным параметрам.
 Параметр Методика Госкомтруда COCOMO 2.0 FPA IFPUG 4.1 MK II FPA Независимая оценка трудоемкости и времени Нет Да Да, на основе данных репози-ториев Да, на основе данных репози-ториев Поддержка различных жизненных циклов Да (в модификации [29]) Да Да Да Поддержка разбиения по стадиям жизненного цикла Да Да В зависимости от репозитория В зависимости от репозитория Учет степени новизны Платформа, средства Платформа, средства, прикладная область Нет Нет Учет использования в разработке типовых элементов Да Да Да Да Учет реинжиниринга или конверсии Нет Да Да Да Учет интеграции готовых коммерческих продуктов Нет Да Нет Нет Учет жесткости требований Нет Да Нет Нет Учет факторов, связанных с командой Нет Да Нет, но может являться свойством репозитория Нет, но может являться свойством репозитория Учет зависимости трудоемкости от средств разработки Интег-рированный Детальный Интег-рированный Интег-рированный Учет влияния графика на трудоемкость Нет Да Нет Нет Выводы
 В соответствии с вышеизложенным, мы рекомендуем применение методик, основанных на методе функциональных точек IFPUG FPA. При этом собственно IFPUG FPA наиболее предпочтительно применять на стороне заказчика, а СОСОМО II - на стороне разработчика, так как для заказчика разница в конкретных условиях разработки не важна, а для разработчика - важна.
 
 ??
 
 ??
 
 ??
 
 ??
 
 
 
 
 2
 
 
 

<< Пред.           стр. 1 (из 1)           След. >>

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