В данной статье приведен обзор наиболее используемых методов сценарного подход, а также рассмотрена проблема использования диверсионного анализа применительно к информационным технологиям с целью повышения надежности.
Ключевые слова: диверсионный анализ, сценарный подход, уязвимость.
На сегодняшний день все более актуальным становится вопрос эффективной разработки и тестирования программных продуктов. Учитывая то, что каждый программный проект уникален, оценка качества программной системы становится сложной задачей. Для того, чтобы создать надежную информационную систему, необходимо на всех этапах её жизненного цикла проводить анализ уязвимости системы, что позволит устранить существующие недостатки и предотвратить возникновение новых. Особенно важным является выявление слабых мест на ранних стадиях разработки проекта, т. е. когда программный продукт еще фактически не существует.
В настоящее время для проектирования информационных систем широко используются методы сценарного подхода [7]. Сценарный подход подразумевает моделирование различных сценариев использования системы. Но что значит разработка сценариев? Очевидно, что всех сценариев на свете не разработаешь. В таком случае, возникает вопрос — на что ориентироваться? В некоторых источниках рекомендуется при разработке сценариев ориентироваться на наиболее вероятные ситуации, т. е. на ситуации, в которых программная система с большой вероятностью откажет. Но можно предложить и другую стратегию — искать слабые места или такие сценарии, при которых отказ системы принесет наибольший ущерб. В этом случае как раз выходим на идею диверсионного анализа, т. е. что бы я сделал, чтобы сломать эту систему?
Такой метод, как диверсионный анализ предполагает инвертирование взгляда на рассматриваемую проблему, т. е. взгляд на систему с точки зрения «диверсанта». Диверсионный анализ широко используется в технических системах, при решении экономических задач (анализ деятельности и анализ бренда) и для защиты интеллектуальной собственности [1], но применительно к программному обеспечению понятие и методология диверсионного анализа не получили распространения.
Программное обеспечение является сложной системой со многими элементами, проходящей через все стадии развития таких систем от появления (проектирования) до гибели (утилизации). Именно поэтому «перенос идеологии» диверсионного анализа в область программного обеспечения возможен, но необходима разработка новых технологий с учетом специфики информационных систем, данную методологию надо пересматривать и адаптировать с учетом того, что критический фактор информационной системы — это человеческий фактор, в отличие других сфер инженерной деятельности, в которых функционируют автоматические системы, а человека нет вообще, либо автоматизированные системы, где роль человека сведена к четкому действию под четкими инструкциями.
Диверсионный анализ применительно к программным продуктам и проектам требует системного подхода, программу необходимо рассматривать с разных сторон, с точки зрения различных уровней управления, с точки зрения функционирования в разных режимах, при изменении внешней и внутренней сред проекта.
В работе [7] утверждается, что AFD может расцениваться как один из методов ТРИЗ. И в работах [1,2] также утверждается, что AFD является обобщением известных сценарных подходов, таких как HAZOP, FTA, FMEA.
Дадим краткий обзор существующих методов в теории структурирования сценариев, ссылаясь на [8]:
РНА — предварительный анализ опасности (Preliminary Hazard Analysis). РНА является индуктивным методом анализа, задачей которого является идентификация опасностей, опасных ситуаций и событий, которые могут причинить вред данной деятельности, объекту или системе, который проводится на ранней стадии разработки проекта, когда мало информации по деталям конструкции и рабочим процедурам. Анализ связан с определением возможностей аварии, качественной оценкой величины возможного вреда или ущерба здоровью, который мог быть нанесен, и идентификацией возможных мер исправления, предупреждения и смягчения последствий.
ФСА — функционально-стоимостной анализ. При проведении ФСА определяют функции систем и компонентов технического объекта либо системы, проводят оценку издержек на реализацию этих функций и разработку предложений с целью их снижения. В последнее время этот метод широко используется для анализа и оптимизации процессов на предприятии. Развитием ФCА-метода стал метод функционально-стоимостного управления (ФСУ, Activity-Based Management, ABM). ФСУ — это метод, который включает управление затратами на основе применения более точного отнесения затрат на процессы, процедуры, функции и продукцию. Министерство энергетики США выпустило документ, который прямо предписывает проводить функционально-стоимостной анализ на самых ранних стадиях создания объекта для обоснования инвестиций.
ETA — анализ «дерева событий» (Event Tree Analysis). ЕТА представляет собой индуктивный тип анализа, в котором основным задаваемым вопросом является «что случится, если...?". Он обеспечивает взаимосвязь между функционированием (или отказом) разнообразных систем безопасности и опасным событием, следующим после того, как происходит единичное инициирующее событие. ЕТА очень полезен при выявлении событий, которые требуют дальнейшего анализа с использованием FТА (то есть вершины событий «деревьев отказов»). ЕТА может быть использован, как для идентификации опасности, так и для вероятностной оценки последовательности событий, влекущих за собой опасные ситуации.
FTA — анализ методом деревьев отказов (FaultTreeAnalysis). При анализе методом деревьев отказов для начала для каждой функции системы выявляются ее нежелательные (катастрофические) события.
Например, для функции «герметизации кабины самолета» катастрофическими являются следующие события:
- Начинается герметизация самолета при том, что хотя бы одна из дверей не до конца закрыта.
- Не начинается герметизация самолета из-за поступления сигнала, что одна из дверей открыта, при том, что все двери заперты.
После выявления всех катастрофических событий для всех основных функций системы, для каждого нежелательного события строится дерево отказов. Дерево отказов состоит из последовательностей и комбинаций нарушений и неисправностей элементарных функций системы и представляет собой графическую многоуровневую структуру логических связей между событиями и возможными причинами их возникновения. При построении дерева отказов реализуется дедуктивный метод, в котором выявляются причины катастрофических событий. Дерево отказов позволяет определить сценарии отказов элементарных функций системы, приводящих к возникновению катастрофического события.
FMEA — анализ видов и последствий отказов и FMECA — анализ видов, последствий и критичности отказов. Для каждой элементарной функции системы выявляются ее нежелательные события или отказы, а так же анализируются их последствия на функционирование всей системы и оценивается степень критичности каждого отказа для функционирования системы. Представляет собой таблицу, в первой колонке которой перечислены все элементарные функции системы, затем во второй колонке для каждой элементарной функции перечислены ее возможные отказы, затем для каждого отказа выявляются его последствия на функционирование системы и, наконец, оценивается критичность данного отказа для функционирования системы. FMEA — анализ позволяет выявить конкретно те дефекты, которые обуславливают наибольший риск потребителя, найти их потенциальные предпосылки и выработать корректирующие мероприятия по их исправлению задолго до того, как эти дефекты проявятся и, таковым образом, предупредить издержки на их исправление.
Анализ методом деревьев отказов и анализ видов и последствий отказов дополняют друг друга. Анализ видов и последствий отказов (FMEA) рассматривает влияние единичного отказа на работу системы, тогда как метод деревьев отказов (FTA) позволяет рассматривать влияние совокупности отказов на функционирование системы.
Оба метода (FMEA и FTA) используют базовые функционально-структурные модели.
HAZOP — анализ угроз и работоспособности (Hazard and Operability Analysis).Эта методология означает исследование опасности и работоспособности. Методология HAZOP — это особый вид структурированного и систематизированного исследования существующей или готовящейся к производству продукции, процесса или системы. HAZOP является методом идентификации опасностей и риска для людей, оборудования, окружающей среды и/или достижения целей организации. От группы исследования HAZOP обычно ожидают по возможности конкретных решений по обработке риска. HAZOP является качественным методом, основанным на использовании управляющих (ключевых) слов, которые помогают понять, почему цели проектирования или условия функционирования не могут быть достигнуты на каждом этапе проекта, процесса, процедуры или системы. Исследование HAZOP обычно выполняет междисциплинарная группа в течение нескольких заседаний.
Исследование HAZOP, подобно методу FMEA, направлено на идентификацию видов отказов процесса, системы или процедуры, их причин и последствий. Отличие исследования HAZOP от метода FMEA заключается в том, что при применении исследования HAZOP рассматриваются нежелательные результаты и отклонения от намеченных результатов и условий для поиска возможных причин и видов отказа, тогда как в методе FMEA анализ начинают с идентификации видов отказа.
Исследование HAZOP первоначально было разработано для анализа системы химических процессов, но впоследствии сфера его применения была расширена для применения в технических системах и сложных производствах. Область применения метода включает в себя механические и электронные системы, процедуры, системы программного обеспечения, организационные изменения, разработку и анализ юридических документов (например, контрактов) и др.
Исследование HAZOP обычно предпринимают на стадии детализации конструкции, когда полная схема намеченного процесса уже разработана, однако еще можно внести некоторые изменения локального характера. С другой стороны, исследование HAZOP может быть применено последовательно с различными ключевыми словами на каждой стадии проектирования и разработки. Оно также может быть выполнено на стадии производства, однако на этой стадии внесение изменений по результатам исследований может быть более затратным. Примеры ключевых слов: «нет», «да», «меньше», «больше», «ниже», «выше», «замена», «другой», и др.
Заключение
Существует достаточно большое количество методов оценки уязвимости программных продуктов, отличительной особенностью которых является взгляд на проблему с точки зрения различных правообладателей. В свою очередь диверсионный анализ позволяет взглянуть на систему с точки зрения «диверсанта», что помогает выявить слабые стороны программной системы на всех этапах ее жизненного цикла. Это позволяет сократить временные и материальные затраты на устранение внезапно возникших неполадок, что, в свою очередь, приведет к повышению качества готового программного продукта.
Литература:
1. Stan Kaplan, S. Visnepolschi, B. Zlotin, A. Zusman: NEW TOOLS FOR FAILURE & RISK ANALYSIS. An Introduction to Anticipatory Failure Determination (AFD) and The Theory of Scenario Structuring. IdeationInternationalInc., 1999.
2. Злотин Б. Л., Вишнепольская С. В. Использование ресурсов при поиске новых технических решений. — Кишинев, 1985.
3. Беркун С. Искусство управления IT-проектами. — СПб.: Питер, 2007.
4. Йордан Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: ЛОРИ, 2000.
5. Каплан, Р. С. Стратегические карты. Трансформация нематериальных активов в материальные результаты / Р. С. Каплан, Д. П. Нортон. Пер. с англ. — М.: ЗАО «Олимп-Бизнес», 2005.
6. Демарко Том. Человеческий фактор: успешные проекты и команды. — М.: Символ-Плюс, 2005.
7. S. Kaplan, Y. Y. Haimes, B. J. Garrick: Fitting Hierarchical Holographic Modeling into the Theory of Scenario Structuring and a Resulting Refinement to the Quantitative Definition of Risk, 2001.
8. ГОСТ Р ИСО/МЭК 31010–2011
