Липаев В.В. Программная инженерия

Лекция 9. Управление ресурсами в жизненном цикле программных средств

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

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

Практически всегда необходимы время и трудоемкость на систем­ ный анализ и оценивание целесообразности разработки комплекса про-

250

9.5. Ресурсы на имитацию внешней среды для обеспечения тестирования и испытаний...

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

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

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

9.5. Ресурсы на имитацию внешней среды для обеспечения тестирования и испытаний программных средств

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

251

Лекция 9. Управление ресурсами в жизненном цикле программных средств

ватных этим объектам по результатам функционирования и генерируемой информации. При этом возникает проблема — какой метод и когда выгод­ ней по затратам на генерацию тестов и по обеспечению необходимой степени покрытия тестами испытываемых ПС (см. лекцию 14).

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

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

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

252

9.5. Ресурсы на имитацию внешней среды для обеспечения тестирования и испытаний...

ятными в реальных условиях. Однако такие, даже маловероятные ситуа­ ции и значения тестов могут быть критическими и/или особо валсными

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

Экономическую эффективность программной имитации внешней

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

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

Затраты на программную имитацию тестовых данных определяются ресурсами, необходимыми на проектирование и эксплуатацию сложных комплексов программ для этих целей, и следующими составляющими:

—затратами на разработку комплекса программ для имитации ин­ формации внешних объектов и среды их функционирования;

—затратами на эксплуатацию программ имитации за время проведе­ ния тестирования, испытаний и/или определения характеристик качества тестируемого ПС;

253

Лекция 9. Управление ресурсами в жизненном цикле программных средств

— затратами на первичную установку и эксплуатацию моделирую­ щей ЭВМ и вспомогательного оборудования, используемого в имитацион­ ном стенде.

Имитационные стенды практически всегда являются уникальными и достаточно полно используют ресурсы моделирующей ЭВМ. В ряде слу­ чаев эти комплексы программ могут иметь объем порядка 10"* — 10^ строк текста и должны создаваться с применением современных технологичес­ ких систем. Затраты на эксплуатацию программ имитации в основном определяются длительностью проведения тестирования, испытаний и/или измерения характеристик качества ПС. Значения этого времени соответ­ ствуют реальному времени генерации тестовых данных и тестирования программ. Затраты на эксплуатацию ЭВМ, используемую в моделирую­ щем имитационном стенде (МИС), включают: первичные затраты на за­ купку и установку оборудования, необходимого для имитации тестовых данных, стоимость имитирующей ЭВМ и устройств сопряжения имитаци­ онного стенда с ЭВМ, на которой функционируют тестируемые программы.

Обычно МИС используется для тестирования нескольких ПС разно­ го, но близкого целевого назначения. Следовательно, затраты на имитаци­ онный стенд и на часть его программ распределяются на число проектов ПС, тестируемых с его использованием. В результате удельные затраты на создание и эксплуатацию стендов быстро убывают при унификации ими­ таторов и расширении области их применения для тестирования и оцени­ вания качества большого числа ПС, имеющих близкое функциональное назначение. Даже приближенные оценки при системном анализе соотно­ шения этих затрат в большинстве случаев показывают высокую рента­ бельность программных имитаторов внешней среды, особенно для ква­ лификационного тестирования и оценивания характеристик качества круп­ номасштабных ПС реального времени. Например, при тестировании ПС для управления воздушным движением применение имитационных стен­ дов, по крайней мере, на порядок снижает затраты по сравнению с натур­ ными экспериментами и использованием реальных объектов (самолетов), а для управления космическими аппаратами или атомными электростан­ циями это соотношение может быть значительно больше (=^10—100). При создании и определении качества административных систем с полной за­ грузкой имитация способна заменить сложную организацию функциони-

254

Л Е К Ц И Я 10

ДЕФЕКТЫ, ОШИБКИ И РИСКИ В ЖИЗНЕННОМ ЦИКЛЕ ПРОГРАММНЫХ СРЕДСТВ

10.1.Общие особенности дефектов, ошибок и рисков

всложных программных средствах

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

К понятию «риски» относятся негативные события и их величины, отражающие потери, убытки или ущерб от процессов или продуктов, выз-

256

10.1. Общие особенности дефектов, ошибок и рисков в сложных программных средствах

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

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

Характеристики дефектов и рисков непосредственно связаны с дос­ тигаемой корректностью, безопасностью и надежностью функционирова­ ния программ и помогают:

—оценивать реальное состояние проекта и планировать необходи­ мую трудоемкость и длительность для его положительного завершения;

—выбирать методы и средства автоматизации тестирования и отлад­ ки программ, адекватные текущему состоянию разработки и сопровожде­ ния ПС, наиболее эффективные для устранения определенных видов де­ фектов и рисков;

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

257

Лекция 10. Дефекты, ошибки и риски в жизненном цикле программных средств

— оценивать требующиеся ресурсы ЭВМ по расширению памяти и производительности, с учетом затрат на реализацию контрмер при моди­ фикации и устранении ошибок и рисков.

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

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

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

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

258

10.1. Общие особенности дефектов, ошибок и рисков в сложных программных средствах

здания гаммы методов и средств тестирования для выявления некоррект­ ностей в спецификациях на компоненты разных уровней.

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

Разработчики проекта программного средства

X

Требования спецификаций и ограничения ресурсов проекта программного средства

Первичные ошибки в программах и данных — потенциальные угрозы проекту программного средства

X

Вторичные ошибки в результатах применения программного средства

з:

Риски — ущерб системе и внешней среде от вторичных ошибок в программном средстве

Диагностика вторичных ошибок и рисков в программном средстве для обнаружения и исключения первичных ошибок

Сокращение или ликвидация вторичных ошибок и рисков в результате исключения первичных ошибок

Рис. 10.1

259