Методологические основы

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

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

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

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

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

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

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

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

2. 
   Методика 1 —
   экспертное технико-экономическое обоснование
   проектов программных средств
   

• 
  В этой методике реализован метод прогноза ТЭП с учетом эксперт­ной оценки минимального числа факторов. Данная методика оценки ТЭП может применяться, когда определены цели и общие функции проек­та ПС, сформулированные в концепции и первичных требованиях с досто­верностью около 20—40%. Основная цель оценки ТЭП — подготовить возможность принять обоснованное решение о допустимости дальнейше­го продвижения проекта в область системного анализа, разработки тре­бований и предварительного проектирования. Если оказывается, что рас­считанные технико-экономические показатели и требуемые ресурсы не могут быть обеспечены для продолжения проекта, то возможны карди­нальные решения: либо изменение некоторых ТЭП и выделяемых ресур­сов, либо прекращение проектирования данного ПС. Учитывая полноту и достоверность доступных характеристик и требований к проекту ПС, дол­жны быть определены цели и возможная достоверность технико-эко­номического обоснования продолжения проектирования ПС.
  
• 
  При первичном технико-экономическом обосновании сложных про­ектов ПС составляется таблица 5.2 — исходными для которой являются концепция проекта ПС и комплекс предварительных требований к иерархическому набору функций, которые могут быть разбиты на предпо­лагаемые фактические компоненты ПС. В дальнейшем разбиение может детализироваться, формируя упрощенный или более точный уровень абст­ракции и взаимодействия компонентов. Наиболее низкий и глубокий уро­вень детализации, как правило, редко формируется ко времени первона­чальной экспертной оценки размера ПС.
  
• 
  Таблица 5.2
  
•