Структурное проектирование сложных программных средств При разработке структуры программного средства

Затраты на технологию и инструментальные программные средства автоматизации разработки ПС обычно являются весьма весомыми при использовании высокоэффективных автоматизированных технологий. При технико-экономическом обосновании проекта следует учитывать, что размер и сложность создаваемого ПС значительно влияют на выбор инструментальных средств и уровня автоматизации технологии, а также на долю этих затрат в общих затратах на разработку. Встречаются ситуации, при которых затраты на технологию достигают 30—50% общих затрат на разработку. Такие затраты могут быть оправданы повышением производительности труда, сокращением сроков разработки и последующим снижением затрат на множество базовых версий ПС. Однако чаще всего эта группа затрат при создании первой версии сложных ПС находится в пределах 30% от суммарных затрат. В первом приближении степень автоматизации разработки программ отражает размер программных средств, используемых в технологических системах. Этот показатель соответствует сложности систем автоматизации разработки программ и пропорционален затратам на их приобретение (или создание) и эксплуатацию.
Стремление уменьшить технологические затраты в период разработки без учета последующего использования ПС, его компонентов и всего жизненного цикла может оказаться мало полезным, а в некоторых случаях привести к значительному увеличению совокупных затрат в ЖЦ. При применении сложных ПС эти затраты исчисляются сотнями человеко-лет, что определяет особую актуальность их снижения. Поэтому необходим системный анализ распределения и использования технологических ресурсов на разработку программ с учетом всего их жизненного цикла, включая сопровождение и возможный перенос на другие платформы.
Уровень автоматизации и качество технологии и инструментальных средств, используемых для поддержки всего жизненного цикла ПС, обычно сильно коррелирован с достигаемым качеством комплексов программ, а также с качеством средств автоматизации для оценивания этого качества. Поэтому определение уровня зрелости технологической поддержки процессов жизненного цикла, организационного и инструментального обеспечения качества ПС, непосредственно связано с выбором и оцениванием реальных или возможных характеристик качества конкретного комплекса программ. В модели СОСОМО для оценивания технико-экономических показателей при разработке ПС рекомендуется методология сложных программных средств СММ — система и модель оценки зрелости комплекса, применяемых технологических процессов жизненного цикла ПС (см. лекцию 3). Эти уровни зрелости характеризуются степенью формализации, адекватностью измерения и документирования процессов и продуктов ЖЦ ПС, широтой применения стандартов и инструментальных средств автоматизации работ, наличием и полнотой реализации функций системой обеспечения качества технологических процессов и их результатов. В модели СОСОМО приводятся количественные рекомендации коэффициентов влияния уровней зрелости СММ на трудоемкость реализации сложных проектов ПС. Влиянию технологической зрелости разработки ПС в детальной модели СОСОМО сопоставлены уровни СММ, для каждого из которых приводятся коэффициенты изменения трудоемкости разработки.
Для приближенной оценки влияния на трудоемкость некоторых характеристик процессов разработки ПС в детальной модели СОСОМО выделены небольшая группа показателей и соответствующие им наборы рейтингов. Инструментальные системы, поддерживающие разработку, описаны качественными характеристиками и рейтингами, изменяющими трудоемкость в пределах приблизительно 20% от средней — номинальной. Уровень технологии и комплекса инструментальных средств особенно сильно влияет на ТЭП крупных проектов ПС. Поэтому затраты на их реализацию и применение целесообразно учитывать конкретно с использованием функций и характеристик проекта.
В модели и таблицах отмечено значительное влияние на трудоемкость ПС директивного ограничения сроков разработки относительно типовых — номинальных. При ограничении сроков сокращению трудоемкости может сопутствовать значительное снижение качества ПС и увеличение рисков реализации проекта. Для уменьшения сроков разработки есть ряд путей, с помощью которых руководство может добиваться некоторого ускорения разработки за счет увеличения трудоемкости и стоимости проекта, для чего рекомендуется:
обеспечить детальные структурирование комплекса программ на модули и спецификации интерфейса для обеспечения максимального параллелизма работы специалистов;
приобрести и освоить технологические, инструментальные средства для более быстрого кодирования, контроля и тестирования и обучить разработчиков их использованию;
обеспечить дополнительную подготовку программистов и группы тестирования к работе в тематической области функций проекта;
привлечь дополнительный вспомогательный персонал;
отложить на время несущественное документирование проекта.
Тем не менее есть предел сокращению сроков разработки с помощью увеличения числа специалистов и приобретения оборудования. При максимально возможном сокращении сроков разработки до 75% от оптимального затраты возрастают на 25%.
При разработке комплексов программ систем реального времени большие затраты могут потребоваться для обеспечения тестирования и испытаний ПС, которые непосредственно не учитываются моделью СОСОМО. Основные усилия сосредоточивались на процессах программирования и автономной отладки компонентов. На этих этапах выявлялась основная масса дефектов и ошибок, хотя при использовании ПС и сопровождении обнаруживалось некоторое их количество. В последнее время центр тяжести разработки сложных ПС сдвинулся к начальным этапам и внимание акцентировано на предотвращение ошибок, прежде всего путем тщательного системного проектирования ПС из готовых программных компонентов, а также на комплексной отладке и испытаниях в реальном времени.
Этапы комплексной отладки, испытаний и модификации программ имеют много общего, в основе которого лежит широкое применение их тестирования для обнаружения ошибок и удостоверения функциональной корректности ПС. Разработка детерминированных тестов при отладке модулей и некоторых групп программ в большинстве случаев производится вручную. Однако их доля может составлять заметную часть общих затрат на отладку компонентов. Достаточно автономными и локализуемыми обычно являются затраты на стохастические тесты и тесты в реальном времени, используемые при комплексной отладке и испытаниях (см. лекцию 14).
При технико-экономическом обосновании проектов комплексов программ на оценку трудоемкости их разработки может оказать существенное влияние ограниченность вычислительных ресурсов специализированных, реализующих ЭВМ реального времени. Это привело к необходимости разрабатывать методы эффективного использования аппаратных ресурсов ЭВМ. Одним из важнейших и наиболее общих показателей, характеризующих возможность применения таких ЭВМ, является их производительность для конкретных задач реального времени. При этом существенным ограничивающим фактором являются длительность, в течение которой ЭВМ может быть предоставлена для решения данной задачи, или то реальное время, в пределах которого целесообразно получить результаты для их практического использования. При ограничениях ресурсов вследствие требований минимизации весов и габаритов специализированных, реализующих ЭВМ в авиационных, ракетных и космических системах, их экономное использование остается актуальным и его следует учитывать при обосновании соответствующих проектов ПС.
Быстрый рост в мире масштабов — размеров комплексов программ и баз данных, решающих единую целевую задачу, потребовал создания новых, более эффективных методов разработки сложных систем. Возникла проблема разработки функционально законченных ПС и БД и их компонентов, потенциально готовых к многократному применению в различной внешней и операционной среде, а также в различных сочетаниях их взаимодействия. Унификация всегда требует некоторых ресурсов, которые в данном случае выражаются в дополнительной трудоемкости создания повторно используемых программ и данных, а также в увеличении необходимой памяти и производительности ЭВМ для их реализации. Сохранение и развитие довольно широкого спектра архитектур ЭВМ, естественно, привело к повторному использованию компонентов (ПИК) не только на однотипных платформах, но и к разработке ПС и БД, переносимых на различные аппаратные и операционные платформы. При этом выделились две технологические проблемы'.
— создание программных компонентов и баз данных, которые рентабельно повторно применять и/или переносить на различные операционные и аппаратные платформы;

— проблема реализации повторного использования и/или переноса ПС и БД для создания из них новых систем на иных платформах.
Увеличение затрат при решении первой проблемы должно компенсироваться сокращением затрат при создании комплексов программ и баз данных на базе готовых компонентов. Освоение методов и средств решения этих проблем позволило качественно изменить процессы создания сложных комплексов программ и резко повысить производительность труда специалистов при их разработке. Это активизировало в последние годы интерес к проблеме мобильности программ и данных во всех отраслях применения вычислительной техники. Создание новых ПС и БД путем переноса их с других аппаратных и операционных платформ стало особенно актуальным для современных административных систем государственного и регионального управления, управления отраслями и предприятиями, а также банковскими системами и в социальной сфере.
На практике при создании нового ПС не всегда имеется полный набор готовых, и пригодных для применения программных компонентов. Тогда при сборке версии ПС может потребоваться доработка отдельных компонентов, их сопряжение в новых сочетаниях и создание новых программ для решения дополнительных задач. Поэтому целесообразно оценивать трудоемкость сборочного программирования с учетом частичных затрат на новые компоненты. Относительное снижение трудоемкости разработки в первом приближении пропорционально доле готовых ПИК. В пределе при создании базовой версии ПС полностью из многократно применяемых готовых компонентов трудоемкость может сократиться в 3—5 раз. В промежуточных случаях, когда готовые компоненты используются частично, оценку изменения трудоемкости можно провести по степени сокращения затрат на программирование и автономную отладку всех необходимых компонентов.