И. Соммервилл - Инженерия программного обеспечения (1133538), страница 90
Текст из файла (страница 90)
транзакций. Банк имеет в сети 1000 банкоматов. Это означает, что центральная база данных обрабатывает ЯОО тыс. транзакций вдень (нли 100 млн. ежегодно). Отказы системы банкоматов подразделяются на два больших класса: те, которые отно. сятся к отдельному банкомату. и те, которые относятся к базе данных и, следовательно, воздействуют на всю сеть банкоматов. Ясно, что последний тип отказов более опасен, чем отказы, относящиеся к отдельному банкомату. В табл. 17.Я показаны возможные типы отказов и соответствующие показатели для этих от.
казов. Требованил безотказности определены таким образом, что перманентный отказ возможен приблизительно один раз в три года Это означает, что в сети банкоматов каждый день может выйти из строя в среднем один банкомат. Таким образом, сбои, в результате которых обработка транзакции прерывается и пользователь должен начать операцию сначала, случают. ся довольно часто. Но это относительно небольшое неудобство для пользователя. Многие большие системы состоят из нескольких подсистем с различными требованиями к безотказности. Так как безотказное ПО дорого, обычно благоразумнее оценить требования безотказности каждой подсистемы отдельно, чем накладывать требование безотказности на все подсистемы.
Это позволяет избежать излишне высоких требований безотказности тех подсистем, где в этом нет необходимости. Приведем последовательность шагов по определению требований безотказности. 17. Спецификация критических систем 349 Таблица 17.3. Требования безотказности для сети банкоматов Пример Тнп отказа Показатель Частота отказа: 1 отказ за 1000 дней Постоянный неразрушающий Случайный Система перестает функционировать с лю.
быми данными на входе. Для устранения от- каза систему необходимо перезагрузить Данные на магнитной полосе не читаются, хотя карта не повреждена Частота отказа: 1 отказ на 1000 карт неразрушающий Случайный разру- шающий Последовательность транзакций вызывает нарушение в работе базы данных Измерить невозмож- но. Во время работы системы случаться не должен 1. Случайные отказы, которые пользователь может устранить сзмостолтельно (например, переэапустив или настроив систему).
Допустимая вероятность отказа не должна превышать 0,002. В этом случае на 500 запросов к системс может произойти один отказ. Это означает, что возможен сбой приблизительно один раз в 5,5 дпл. 2. Перманентные отказы, которые требуют восстановления системы разработчиком. Вероятность такого типа отказа должна быть намного ниже — приблизительно один раз в год. В этом случае вероятность отказа должна быть не больше чем 0.00002. В идеале сбои, разрушающие базу данных, никогда не должны возникать за весь срок службы программного обеспечения.
Поэтому требование безотказности в этом случае такое: вероятность разрушающего отказа должна быть меньше 1 отказа иа 200 млн. транзакций, Тогда за весь срок службы одной версии ПО не должно произойти отказов, приводящих к разрушению базы данных. Но подобное требование безотказности фактически невозможно проверить. Пусть каждая транзакция занимает 1 секунду машинного времени и для сети банкоматов построен имитатор.
Время иодслирования транзакций, проходящих через сеть банкоматов за один день, равно 300 тыс. секунд. Эго приблизительно 5,5 дня. Ясно, что это время можно сократить, уменьшая период обработки транзакций и используя несколько имитаторов, но в этом случае очень трудно проверить. насколько имитируемая система удовлетворяет требованиям безотказности.
Также невозможно проверить качественные требования, определяющие очень высо. кий уровень безотказности. Например, если система является критической по обеспечению безопасности, то за весь срок ее.службы не должно произойти ни одного сбоя. Предположим, что должны быть установлены 1000 копий системы и что система "выполняется" 1000 раз в секунду. Срок службы системы составляет 10 лет.
Следовательно, общее прогнозируеиое число "выполнений" системы приблизительно равно 5" 10". Нет смысла определять частоту отказа как один сбой на 10'" "выполнений" (что обеспечит безопасность системы), поскольау для обоснования такого уровня безотказности невозможно протестировать систему. Еще одним примером требований безотказности может служить система инъекций инсулина, которая была рассмотрена в главе 16. Она делает инъекции инсулина несколько рзз в день, а уровень сахара в крови определяется несколько раз в чзс.
Поскольку система используется периодически, а последствия сбоя весьма серьезны, то наиболее подходлщим показателем безотказности системы будет вероятность отказа. Для рассматриваемой сисгемы можно определить два типа отказов. $50 'Часть ТУ. Критические системьг Стоимость разработки и проверки требований безотказности системы может быть очень высока. Органиэации должны реально оценивать, необходимы ли такие затраты.
Они оправданы в системах, где безотказность является критическим фактором, например в телефонных коимугаторах, или в системах, в которых отказ может привести к большим экономическим потерям. Вероятно, они не оправданы для многих типов систем, применяемых в бизнесе и научных исследованиях. Такие системы обычно имеют умеренные требования к безотказности, так как отказ в них просто приводит к задержке процесса и устранить его относительно недорого.
17.2. Специфицирование требований безопасности Безопасная работа является необходимой характеристикой систем ПО, критических по обеспечению безопасности. Это означает, что при разработке требований необходимо рассмотреть потенциальные опасности и риски, которые могут возник. нугь в процессе работы системы. В требованиях следует либо описать, как программ. ная система должна вести себя, чтобы минимизировать риск, либо предусмотреть, чтобы опасность никогда не возникала.
Процесс определения требований безопасности и обеспечение их выполнснил — часть общего "безопасного" жизненного цикла ПО (290], в упрощенном виде представленного на рис. 17.1. Безопасный жизненный цикл ПО предложен в международном стандарте управления безопасностью 1ЕС 61508 [175), разработанном Международной элелтротех. ничсской комиссией (1пгегпаг!опа! Е!есыогссйп!са! Сопип!зз!оп — 1ЕС). Как можно видеть из рис. 17.1. этот стандарт охватывает все аспекты управления безопасностью — от начального определения области применения через планирование и разработку системы до вывода ее пз эксплуатации.
На первых стадиях жизненного цикла стандарта 1ЕС 61508 определяется область действил системы, оцениваются потенциальные опасности н риски. Далее следует специфицирование требований безопасности и определение подсистем, отвечающих за выполнение конкретных положений требований безопасности. Затем следуют этапы планирования и реализации систем.
Системы, критические по обеспечению безопасности, разрабатываются с учетом внешнего окружения, что может дать дополнительные средства снижения рисков. Параллельно с разработкой системы планируются проверка соотвсгствил системы требованиям безопасности, ее инсталляция, эксплуатация и сопровождение. Управление безопасностью нс заканчивается с поставкой систеиы заказчилТ. После поставки система должна быть инсталлирована так, как запланировано при анализе опасностей.
Прежде чем систеиа будет запущена в эксплуатацию, проводится ее проверка па безопасность. Контроль безопасности должен осуществляться в течение всего срока эксплуатации и обслуживания системы. Много проблем, связанных с безопасностью, возникает из.за плохого обслуживания, поэтому особенно важно, чтобы система была удобной для сопровождения. В заключение следует подчеркнуть, что необходимые меры безопасности должны быть также приняты при выводе системы из эксплуатации (например, удаление из системы опасных материалов).
17. Сиецификаззик критических систем 351 Рис 17 1. Безопасный жизненный Еикя ПО в шавмвтствии га свлнапртон !ЕС б1508 17.2.1. Анализ опасностей и рисков Анализ опасностей и рисков складывается из анализа самой системы н окружения, в котором она будет эксплуатироватьсл. В результате должны быть обнаружены потенциальные опасности, которые мо~ут возникнуть в системе и ее окружении. Это комплексный и трудоелгкий процесс, который требует всестороннего анализа и большого кругозора разработчиков. Эту работу должны проводить опытные инженеры совместно со специа. листами в той предметной области, где будет эксплуатироваться система, и профессионалами в области безопасности систем. На рис. 17.2 показан итерационный процесс анализа рисков и опасностей, который включает ряд этапов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
