Вопрос: Ресурсы для обеспечения функциональной пригодности при разработке сложных программных средств

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

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

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

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

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

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

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

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

- максимальной трудоемкостью – ПС систем управления динамическими объектами или процессами в реальном времени (СРВ);

- средней трудоемкостью – ПС административных, организационных и информационно-поисковых систем (ИПС);

- минимальной трудоемкостью создания – пакеты автономных расчетных прикладных программ (ППП).

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

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

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

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

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

Затраты на обеспечение безопасности и надежности функционирования ПС определяются требуемым уровнем защищенности и сложностью (размером) программ для ее реализации (см. лекцию 11). При наличии особенно высоких требований к безопасности критических ПС эти затраты могут даже в 2-4 раза превышать затраты на решение базовых, функциональных задач. Для типовых административных систем трудоемкость создания программных средств защиты обычно составляет 20-40% затрат на решение основных, функциональных задач. В более простых случаях доля таких затрат может снижаться до 5-10%. Затраты на обеспечение высокой надежности в составе разработки ПС могут достигать 2-3-кратного увеличения общих затрат, при высоких требованиях наработки на отказ. Для минимального обеспечения автоматического рестарта в ординарных системах они составляют порядка 10-20%. Однако практически в любых системах должен присутствовать минимум программных компонентов, обеспечивающих надежность и защиту от преднамеренных и случайных угроз.

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

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

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

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

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

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

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