Во многих случаях важны не столько затраты на создание ПС сколько длительность разработки. Локальное ускорение отдельных этапов разработки (особенно начальных) может приводить к значительному увеличению длительности других этапов и к общему возрастанию длительности проектирования. Поэтому совершенствование технологии и средств автоматизации проектирования сопряжено с перераспределением затрат и длительностей этапов работ с целью сокращения общей длительности разработки проекта, в некоторых случаях даже за счет увеличения суммарных затрат.
Характеристики ошибок при разработке программ значительно влияют на затраты при создании программ (см. табл.1). Поэтому целесообразны оценки относительных и абсолютных трудозатрат на устранение ошибок. Общие тенденции состоят в быстром росте затрат на выявление каждой ошибки по последовательным этапам разработки программ. Поэтому экономически целесообразно в максимальной степени выявлять ошибки на начальных этапах ЖЦ ПС. Это, естественно, приводит к увеличению затрат и длительности этих этапов, однако способствует минимизации суммарных затрат и длительности разработки проекта в целом.
Характеристики ошибок непосредственно связаны с достигаемыми корректностью, безопасностью и надежностью функционирования программ. Изучение характеристик ошибок при разработке реальных программ позволило создать ряд математических моделей, обеспечивающих возможность прогнозирования длительности разработки и затрат, необходимых для достижения определенной безопасности и надежности программ. Анализ и обобщение характеристик выявленных и устраненных ошибок в процессе разработки позволяет контролировать и прогнозировать качество программ при аналогичных разработках.
Стремление заказчиков резко ускорить разработку, снизить затраты или нерационально увеличить нормативы для специалистов, всегда сопряжено со снижением качества в трудно оцениваемых пределах. При рассмотрении ТЭП разработки ПС ниже предполагается достаточно высокое, однако, не всегда зафиксированное качество программ. Имеющиеся попытки введения заказчиками нормативов на ТЭП для разработчиков либо не способствуют выполнению их управляющей и регламентирующей роли (если они занижены), либо приводят к снижению качества программ (если они завышены). Поэтому приводимые далее ТЭП следует использовать с учетом всех условий, для которых они получены, и нецелесообразно применять в качестве нормативов при конкретных разработках. Они могут служить только ориентирами для оценки и обоснования экономических характеристик аналогичных проектов ПС.
Выбор и применение единиц измерения размера программ одна из самых сложных задач при анализе и формализации объектов разработки и затрат на их создание. Этот параметр в современной практике, среди всех факторов, влияющих на ТЭП, изменяется в самом широком диапазоне на три — четыре порядка от 103 до 107 строк текста программ. Поэтому методам его оценивания ниже уделяется большое внимание.
Неопределенность единиц измерения размера комплексов и компонентов программ значительно влияет на численные значения показателей и их разброс в опубликованных работах. Этому также способствует неоднозначность учитываемых этапов разработки программ и категорий специалистов, трудозатраты которых заметно влияют на ТЭП. При одних и тех же процессах измерения объектов разработки и затрат на их создание методики определения количественных значений основных показателей пока не формализованы, что вносит дополнительную дисперсию в их значения, приводимые в различных исследованиях. В результате могут делаться различные и даже принципиально неверные выводы, например, об очень высокой эффективности некоторых частных технологических методов или инструментальных систем автоматизации разработки ПС. Для уменьшения этих неопределенностей и возможных методических ошибок в ТЭП программ необходимо определить основные понятия и единицы измерения: размера или масштаба программ, трудозатрат на их разработку, производительности труда специалистов и некоторых частных характеристик (см. табл.1).
Оценку размера комплекса программ и трудозатрат приходится выполнять неоднократно во время жизненного цикла, причем после каждого оценивания повышается уровень доверия к полученным результатам. Точность оценки значительно повышается после формулирования начальных требований и спецификаций заказчиков, проведения анализа требований, после завершения разработки проекта. Хороший менеджер проекта обязан взять себе за правило оценивать (повторно) размеры ПС, используя результата оценивания в качестве выходных критериев для каждого этапа. Известно, что программисты весьма плохо справляются с проблемами оценивания результатов своего труда. К этому выводу приводит факт, что около 15% программных проектов не доводятся до завершения, так как прогнозы по поводу предполагаемой производительности разработчиков весьма далеки от совершенства. Несоответствие производительности изначально предполагаемым показателям, может иметь две следующие причины: плохая работа специалистов или некорректная техника и методы оценки ТЭП. Имеется множество свидетельств плохо выполненной оценки, однако практически невозможно доказать, что персонал не трудился усердно над разрешением проблемы, либо не является в достаточной степени компетентным. Разработчиков зачастую нельзя призвать к ответственности за такие результаты. Все начинается с прогнозирования размеров ПС, оценивание и достоверность которых обусловлены следующими факторами:
- проблема может быть недостаточно хорошо понята разработчиками и/или заказчиками из-за того, что некоторые факты были упущены или искажены из-за предвзятого к ним отношения;
- недостаток либо полное отсутствие исторических данных и прототипов не позволяет создать базу для оценок и прогнозирования в будущем;
- специалисты-оценщики могут потерпеть неудачу при попытке описания того, насколько большой может быть система или комплекс программ, еще до их создания или даже еще до этапа разработки предварительного проекта;
- проектирующая организация не располагает стандартами, с помощью которых можно выполнять процесс оценивания (либо в случае наличия стандартов их никто не придерживается); в результате наблюдается недостаток совместимости при осуществлении процесса оценивания;
- менеджеры проектов полагают, что было бы неплохо фиксировать требования в начале проекта, заказчики же считают, что не стоит тратить драгоценное время на разработку спецификации требований и оценки размеров проекта;
- для достижения желаемой четкости в функционировании других частей системы (интерфейсов наследованной системы, аппаратного обеспечения и т.д.) могут потребоваться дополнительные компоненты ПС, что скажется на размерах программного продукта; имеет место недостаточно четкое представление об ограничениях на уровне системы и возможностях совершенствования рассматриваемого программного продукта.
Исследованию различных единиц измерения, используемых при оценке размеров ПС, посвящены рассмотрению некоторых наиболее часто используемых из них. Выбор этих единиц зависит от конкретного проекта и потребностей организации. За рубежом чаще всего размер ПС определяется в терминах строк кода (Lines of Code - LОС), функциональных точек и точек свойств. Вне зависимости от того, оценивается ли конечный продукт, как в случае с применением показателя LОС, либо некоторая его абстракция или модель, в данном случае оценке подвергаете то, чего еще нет в природе. Поэтому оценивание размеров ПС представляет значительные трудности.
Размер или масштаб программ в настоящее время приводится в публикациях в различных единицах, что может изменять их численные значения для одних и тех же программ в несколько раз. В качестве таких единиц чаще всего используются численные значения: строк текста программы на языке программирования, предложений на ассемблере, символов в тексте программы, байт или команд в объектном коде после трансляции (табл.1). Каждая из этих единиц измерения имеет некоторые преимущества при определенных целях исследования. Однако при сравнительном технико-экономическом анализе различных проектов применение в каждом из них отличающихся единиц для характеристики объекта разработки приводит к дополнительному разбросу численных значений размеров и к несопоставимости измеренных технико-экономических показателей.
Важная задача при оценивании ТЭП состоит в выборе базовых унифицируемых единиц измерения исходного текста и исполняемых (объектных) программ, при применении которых имеется наибольшая корреляция этих видов измеряемых размеров программ. Для остальных единиц измерения необходимы методы пересчета к базовым единицам с учетом особенностей языков программирования, применяемых трансляторов и архитектуры ЭВМ. Кроме того, следует определять коэффициенты корреляции с базовыми единицами измерения при применении остальных единиц. С этих позиций наиболее адекватной единицей измерения объема программ является число операторов на машино-ориентироваином ассемблере, которое имеет корреляцию с числом команд в объектном коде реализующей ЭВМ, близкую к единице. В этом случае при сопоставлении измеренных объемов программ влияет единственный фактор - архитектура реализующих ЭВМ. Этот фактор может учитываться путем небольших коэффициентов перевода, определяемых путем анализа особенностей структуры и системы команд ЭВМ, а также конкретного ассемблера. Для сопоставления численных значений объемов программ следует выделять базовый, наиболее широко применяемый ассемблер.