В данной статье рассмотрена проблема использования диверсионного анализа применительно к информационным системам как средства их оценки.
Ключевые слова:диверсионный анализ, сценарный поход, идеальный сценарий.
В настоящее время все более актуальным становится вопрос повышения надежности программных систем. Учитывая то, что каждый программный проект уникален, оценка качества программной системы становится сложной задачей. Для того, чтобы создать надежную информационную систему, нужно знать слабые места ее конструкции. Появляется вопрос — как же их найти?
Ориентируясь на работу [1], можно выделить два способа анализа программных продуктов и проектов. Первый (Anticipatory Failure Determination-1, AFD-1) — сбор данных, основанный на прежнем опыте использования программных систем, а второй (Anticipatory Failure Determination-2, AFD-2) — для предотвращения неуспешного завершения программного проекта требуется проводить «диверсионный анализ» — необходимо думать как «диверсант», старающийся разрушить систему, при этом не допуская нарушения формальных требований к организации проектов. Речь идет о придумывании диверсии, отсюда и название подхода. Естественно, после того, как диверсия придумана, следует проверить, не реализована ли она на практике, есть ли вероятность ее реализации. И если такая возможность не исключается, необходимо решить следующую задачу: как этого не допустить
Основная идея диверсионного анализа проста. Вместо того, чтобы стараться понять — почему и как данный нежелательный эффект возникает, мы формулируем задачу: «Допустим, нам поручено добиться именно такого результата. Как мы могли бы это сделать, используя имеющиеся ресурсы?» Такое преобразование получило название «инверсия задачи», оно близко по своей сути к тому, что на Западе позже было названо «реверс инжениринг» (RE). Со временем диверсионный анализ начал использоваться не только для выявления причин брака. Другим важным применением этого метода стало прогнозирование возможных нежелательных явлений, особенно при внедрении новых технологий или продуктов.
Первый подход применительно к информационным системам является малоперспективным, т. к. пока будет происходить сбор данных, рассматриваемая система может попросту устареть и потерять свою уникальность. Плюс ко всему, каждый проект уникален, и в таком случае возникает вопрос — как применить прежний опыт в новой системе?
А взгляд на систему глазами диверсанта как-раз-таки позволяет выявлять слабые места на этапе проектирования, когда системы еще фактически не существует. С другой стороны, идея диверсионного анализа уже давно работает — существует теория структурирования сценариев, поэтому возникает очевидная идея: как все эти полезные наработки использовать в сфере информационных технологий? На самом деле вопрос не простой, и свидетельством этому является, например, водопадная модель жизненного цикла, когда идею реализации этой модели в других областях попытались перенести в сферу IT, вследствие чего возникла масса требующих разрешения проблем. Т.о., AFD — это возможная стратегия испытания программных систем, когда сценарии генерируются с учетом тяжести последствий и слабых мест программного продукта.
При проведении «диверсионного» анализа в работе [7] рекомендуется придерживаться следующих правил:
1. Последовательно и тщательно выполнять шаги методики, фиксируя на диаграмме Исикавы по ходу работы все возникающие варианты создания вредных эффектов, а также задачи по их созданию, не решенные на этом шаге, но к решению которых можно вернуться позднее.
2. Процесс поиска новых вариантов «диверсий» желательно совмещать с углубленным изучением системы и постоянной проверкой, не «внедрены» ли эти «диверсии» в реальности, а также с поиском возможности их предотвращения либо устранения вредных последствий.
3. Необходимо помнить, что различных вариантов диверсии может быть очень много и ни один вариант не должен быть при поиске пропущен или отброшен априори, без оценки и проверки возможности реализации. Поэтому досрочное прекращение работы, выполнение ее не в полном объеме может привести к тому, что опасная «диверсия» останется не обнаруженной вовремя.
В результате диверсионного анализа могут быть найдены такие способы изменения технической системы, которые приведут к тому, что система:
- не будет выполнять свою главную функцию,
- уровень выполнения главной функции будет недостаточным,
- уровень затрат на адекватное выполнение главной функции будет избыточным.
Диверсионный анализ применительно к программным продуктам и проектам требует системного подхода, программу необходимо рассматривать с разных сторон, с точки зрения различных уровней управления, с точки зрения функционирования в разных режимах, при изменении внешней и внутренней сред проекта.
В работах [1,2] утверждается, что AFD является обобщением известных сценарных подходов, таких как HAZOP, FTA, FMEA. Таким образом, AFD — это возможная стратегия испытания программных систем, когда сценарии генерируются с учетом тяжести последствий и слабых мест программного продукта.
На рис. 1 приведен процесс создания информационной системы в виде траектории в пространстве состояния системы Ω, определяющей переход системы из начального состояния (НС) в конечное (КС0).
Рис. 1. «Идеальный» сценарий развития информационной системы
После инициирующего события (рис. 2) развитие системы может отклониться от выбранного сценария S0 и перейти к реализации нового сценария S*, заканчивающимся конечным состоянием КС*.
Рис. 2. Сценарий поведения системы после влияния инициирующего события
Диверсионный анализ направлен на создание таких инициирующих событий, которые могут привести к наиболее значимому отклонению поведения системы от запланированного и результаты которых будут наиболее сложными и затратными для устранения.
Таким образом, данный метод обладает следующими достоинствами:
- базируется на функциональном подходе к рассмотрению технических систем,
- результаты анализа могут быть использованы в существующем алгоритме выполнения проекта посредством их включения в цепочки нежелательных эффектов.
- позволяет выявлять скрытые недостатки, присущие технической системе и проявляющиеся только при определенных обстоятельствах.
Литература:
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. Ideation International Inc., 1999.
2. Злотин Б. Л., Вишнепольская С. В. Использование ресурсов при поиске новых технических решений. — Кишинев, 1985.
3. Каплан, Р. С. Стратегические карты. Трансформация нематериальных активов в материальные результаты / Р. С. Каплан, Д. П. Нортон. Пер. с англ. — М.: ЗАО «Олимп-Бизнес», 2005.
4. 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.
5. Беркун С. Искусство управления IT-проектами. — СПб.: Питер, 2007.
6. А. П. Нилов. Применение диверсионного анализа при верификации концепций, 2005.
7. Б. Л. Злотин А. В. Зусман: Методика прогнозирования чрезвычайных ситуаций, вредных и нежелательных явлений. — Кишинев, 1991.
