Ресурсы на реализацию конструктивных характеристик качества программных средств

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

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

Наиболее активно в качестве простейшего показателя сложности используется размер – масштаб комплекса программ, выраженный числом операторов (команд) или строк текста на языке программирования (с учетом коэффициента, зависящего от класса ПС и специфики языка) (см. лекцию 5). Размер программ без комментариев является одной из наиболее достоверно измеряемых характеристик сложности ПС и достаточно адекватен экономическим затратам на его разработку. Реальное изменение создаваемых в настоящее время новых сложных ПС объемом от 10³ до 10⁶ строк определяет диапазон трудоемкости разработки таких программ от человеко-года до тысяч человеко-лет. С другой стороны, отсутствуют какие-либо данные о значительном преимуществе других достаточно простых мер сложности при прогнозировании ресурсов на разработку крупномасштабных ПС.

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

При современных технологиях полностью новые, крупномасштабные комплексы программ, реализуемые в допустимое время 2 – 4 года, ограничены объемом 10⁶ - 10 ⁷ строк текста. Выше отмечалось (см. лекцию 5), что диапазону размеров современных ПС в три-четыре порядка (до 10 млн. строк) соответствуют приблизительно такие же диапазоны изменения трудоемкости и стоимости их разработок. Очевидна принципиальная нерентабельность разработки очень сложных ПС за 5 - 10 лет. С другой стороны, даже относительно небольшие программы высокого качества в несколько тысяч строк по полному технологическому циклу с сертификационными испытаниями продукции редко создаются за время, меньшее, чем полгода - год. Таким образом, диапазон вариации длительностей разработок ПС много меньше, чем вариация их трудоемкости, а эти длительности ограничены сверху и снизу, и объем новых программ является одним из основных факторов, определяющим эти границы.

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

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

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

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

Особенности затрат на реализацию остальных требований к конструктивным характеристикам качества отмечаются при представлении соответствующих характеристик (см. лекцию 11) и сводятся к следующему:

- дополнительные затраты на обеспечение высокой надежности ПС могут достигать 2 – 3 кратного увеличения затрат относительно функциональной пригодности при требованиях наработки на отказ в десятки тысяч часов, а для минимального обеспечения автоматического рестарта в ординарных системах составляют порядка 10 – 20%;

- для повышения эффективности использования ресурсов ЭВМ затраты могут быть относительно невелики (несколько процентов) и их трудно выделить из затрат на решение основных, функциональных задач;

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

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

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

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

- полностью нового ПС, для которого отсутствуют или недоступны подходящие готовые компоненты – прототипы и/или их заведомо нерентабельно использовать;

- программного продукта на базе комплексирования набора готовых программных компонентов и информации баз данных, для которого почти не требуется создания новых компонентов.

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

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

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

Практически всегда необходимо время и трудоемкость на системный анализ, и оценивание целесообразности разработки комплекса программ из готовых компонентов с учетом стоимости приобретения и адаптации переносимых программ. Интегрирование компонентов в новой операционной среде, тестирование и испытания в комплексе с унаследованными программами, также почти всегда требует времени и других ресурсов. Некоторые, казалось бы, второстепенные, детали и факторы несовместимости готовых, переносимых программ и новой платформы могут заметно отражаться на трудоемкости проекта. Особенно тщательно их следует анализировать в унаследованных системах, в которых относительно мелкие детали взаимодействия новых и старых программ могут существенно влиять на экономические характеристики проекта.

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

Дата добавления: 2014-01-13