Модели COCOMO, COCOMO II, метод функциональных точек. Их сравнительный анализ и область применения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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