Требования к наборы критериев

Формирование критериев оценки и требований для выбора САБ

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

Эффективная система автоматизации банка (далее САБ) — один из основополагающих факторов, определяющих конкурентное преимущество, или, наоборот, конкурентный проигрыш той или иной кредитной организации.

Естественно, что решение о дальнейшем развитии или замене существующей САБ — крайне болезненный шаг, определяемый стратегическим планом развития кредитной организации, видением своего будущего, что само по себе достаточно непросто, а на постсоветском пространстве отягощено слабой предсказуемостью внешних условий ведения бизнеса. Фактически все игроки данного бизнеса играют по постоянно меняющимся правилам.

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

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

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

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

IT-подразделения банков, как правило, этот разрыв не в состоянии компенсировать, так как выполняют в основном технические функции текущего обеспечения бизнеса.

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

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

Таким образом, проблема выбора автоматизированной банковской системы затрагивает целый ряд внутренних и внешних проблем банка и рынка САБ. Тем не менее, эта проблема решаема и не столь сложна, как может показаться на первый взгляд. Важен правильный подход и для каждого банка он во многом уникален.

Тем не менее, опираясь на существующие стандарты, мы разработали некоторую методику, которая позволяет правильно оценить и выбрать САБ. Опыт применения данной методики в целом ряде банков разного размера продемонстрировал её практичность и жизнеспособность. Основным аспектам выбора и внедрения САБ и посвящается цикл статей, первая из которых и предлагается Вашему вниманию. В ней пойдёт речь о формировании требований и некоей системы показателей, позволяющей кредитной организации корректно оценить применимость той или иной САБ для своих нужд. Во второй статье цикла мы поговорим о различных способах организации процедуры выбора САБ. В третьей речь пойдет о процессе внедрения САБ, его тонкостях и подводных камнях. И, наконец, последняя статья цикла будет посвящена краткой классификации САБ и нашему представлению ответа на вопрос: «Что лучше собственная разработка или готовое решение?» Применяемые термины

Прежде чем приступать к изложению методики оценки и выбора САБ следует кратко определить основные термины, применяемые в тексте:

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

Основные подходы к проблеме выбора САБ

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

Казалось бы, САБ — типичное ПО определенного класса. Существует целый ряд стандартов посвященных аспектам оценки ПО. В качестве примера не могу не упомянуть, как международные стандарты: (ISO 12207 1995, ISO 9126 2001—2004, ISO 14598 1998—2000, SQUARE (ISO 25000) (проект)), так и национальные стандарты Украины (отражение стандартов ISO, правда, в предыдущих версиях): ДСТУ 3918-99, ДСТУ 2844-94, ДСТУ 2850-94.

К сожалению всё не так просто. Эти стандарты предусматривают методики построения метрик и характеристик, но, к сожалению, оставляют за кадром целый ряд весьма существенных факторов, зачастую влияющих на успех всего проекта выбора и внедрения САБ.

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

В процессе работы над методикой оценки САБ было выделено два основных класса критериев оценки: критерии, характеризующие компанию и критерии, характеризующие продукт. Дело в том, что зачастую, выбор САБ осуществляется без учета характеристик компании, представившей продукт, проводится оценка только конкретного программного решения. Мне представляется это серьезным упущением, так как жить кредитной организации придется не только с конкретным программным продуктом, а в тесном сотрудничестве с компанией разработчиком или дилером, представляющим данный продукт на рынке. Я видел целый ряд проектов, в которых была выбрана действительно лучшая, на тот момент система, но которые по прошествии некоторого времени были свёрнуты из-за невозможности нормального сопровождения и развития продукта.

Рассмотрим более подробно каждый из этих классов критериев. Критерии компании

Критерии, характеризующие компанию можно, в свою очередь разделить на три большие группы: экономические, организационные и технологические.

Понятно, что на момент проведения оценки не все из описываемых критериев могут быть доступны, однако, неопределенность такого вида легко учесть. Об этом более подробно речь пойдет во второй статье цикла, посвященной аспектом проведения оценки и выбора САБ.

Вторым потенциальным подводным камнем для оценки может служить невозможность прямого сравнения, казалось бы, однотипных характеристик. Это может быть связано с тем, что разработчики САБ работают в разных правовых сферах, например, сравнивать балансы компании, работающей в Великобритании, с балансами компании, работающей в Украине, напрямую просто смешно. Для проведения оценки представленную информацию необходимо будет нормализовывать (приводить в одинаковую систему координат). Разработка данных процедур также является прерогативой этапа формирования требований к САБ и лица, привлеченные к данному проекту должны быть готовы к подобной работе. Мне неизвестны универсальные методики решения подобных проблем, однако, для каждой потенциальной проблемы оценки очень несложно найти некое решение, например, в качестве экономических характеристик последнего завершенного финансового года компании мы рекомендуем использовать такой критерий как «приведенная прибыль на одного сотрудника компании».

Вернемся к более детальному взгляду на каждую из групп критериев оценки компании. Критерии, характеризующие экономическую сторону компании

Данная группа критериев характеризует общую устойчивость компании — потенциального партнера на рынке, как субъекта хозяйственно-экономических отношений. В её состав входят следующие критерии: экономические характеристики последнего завершенного финансового года, экономические характеристики текущего финансового года, наличие основных фондов в собственности, наличие имущественных/финансовых претензий со стороны третьих лиц. Первые два критерия характеризуют успешность компании на рынке, причем в динамике, что достаточно важно. Третий критерий показывает экономическую прочность компании, её готовность к долговременному существованию. Ну и, наконец, последний критерий — потенциальная работа для службы экономической безопасности кредитной организации и может иметь как качественную оценку (есть/нет), так и количественную, что предпочтительнее. Критерии, характеризующие организационную сторону компании

Эти критерии характеризуют так называемую организационную стабильность компании и уровень организационной зрелости компании. В её состав входят следующие критерии: срок жизни компании, количество проектов успешных/неудачных, численность персонала, четкость распределения функций, наличие/отсутствие информации о конфликтах с законодательными органами. Я полагаю, что кроме последних двух критериев нет необходимости пояснять назначение представленных критериев.

Четкость распределения функций характеризует степень организационной зрелости компании. Речь идет о разделении функций внутри компании на: службу продаж, службу разработки, службу сопровождения и т.д. Как правило, для оценки данного критерия мы применяем метрику: отсутствует, слабая, удовлетворительная, выраженная, четкая.

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

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

Хочется обратить внимание читателей на то, что при осуществлении выбора следует опираться не на общее число специалистов службы сопровождения в компании, а на число специалистов в конкретном территориальном подразделении или филиале компании. Дело в том, что тысячи специалистов в службе сопровождения компании, расположенной в джунглях Амазонки будут для Вас крайне слабым утешением при решении срочных проблем. Факс, телефон и электронная почта, за редким исключением — слабая замена реальному физическому присутствию специалиста службы сопровождения, да и эффективность подобной работы не очень велика, исключая возможность прямого доступа специалистов службы сопровождения к реально работающей системе в кредитной организации. Правда подобная организация работы несёт риски иного рода, и является серьёзной брешью в системе информационной безопасности банка. Иными словами, если срок появления у Вас в офисе специалистов службы поддержки в экстренных ситуациях более 8-ми часов — смело ставьте для соответствующего критерия оценку 0(нуль). Критерии представленного программного обеспечения

Данный класс критериев описывает непосредственно характеристики оцениваемого программного обеспечения. Выбор критериев основан на стандарте ISO 9126 и дополнен группами политических и экономических критериев.

Таким образом, класс критериев программного обеспечения разделён нами на четыре группы: критерии, характеризующие функционал САБ, критерии, характеризующие IT сущности, экономические и политические критерии.

Более подробно о критериях программного обеспечения немного ниже. Критерии, характеризующие функционал

Эта группа критериев описывает непосредственно функциональные составляющие оцениваемой САБ. В нее входят три критерия:

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

Поскольку все три критерия относятся к критериям косвенной оценки, для их оценки предлагается использовать метрику: низкая, средняя, высокая.

Ну и несколько слов о применении данных критериев оценки. Естественно, что оценить функционал системы в целом, сродни определению средней температуры по больнице. Поэтому для оценки функционала САБ проводится работа по выделению групп функционала и отдельных функций. Перечень групп и функций, а также степень их детализации зависит от каждой конкретной кредитной организации, поскольку каждая кредитная организация с точки зрения осуществляемых операций, а также их значимости уникальна. Результаты сводятся в таблицу, для проведения последующей оценки. Фрагмент подобной таблицы представлен ниже:

В этой группе критериев собраны характеристики программного обеспечения, описывающие значимые для IT подразделений характеристики САБ. В неё входят следующие критерии:

1. Надежность — количественные и качественные характеристики таких аспектов САБ, как: завершенность, устойчивость к дефектам, восстанавливаемость и доступность/готовность;
2. Производительность — определение предельной пропускной способности информационной системы с данной САБ путём измерения экстремальных и средних значений времени исполнения отдельных функций САБ (смотри п. «Критерии, характеризующие функционал»);
3. Защищенность — полнота использования доступных методов и средств защиты САБ от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1—3 «Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий»;
4. Способность к взаимодействию — определение качества совместной работы компонентов САБ и баз данных с другими прикладными системами и компонентами на различных вычислительных платформах, а также взаимодействия с пользователями в стиле, удобном для перехода от одной вычислительной системы к другой с подобными функциями. В том числе этот критерий позволяет косвенно охарактеризовать трудоемкость процедур перехода от существующей САБ к новой;
5. Мобильность — качественное определение экспертами адаптируемости, простоты установки, совместимости и замещаемости программ, выражаемое в баллах. Количественно эту характеристику программного средства и совокупность ее атрибутов можно (и целесообразно) оценивать в экономических показателях: стоимости, трудоемкости и длительности реализации процедур переноса САБ на иные платформы;
6. Сопровождаемость — полнота и достоверность документации о состояниях САБ и её компонентов, всех предполагаемых и выполненных изменениях, позволяющей установить текущее состояние версий САБ в любой момент времени и историю их развития. Она должна определять стратегию, стандарты, процедуры, распределение ресурсов и планы создания, изменения и применения документов САБ.

Экономические критерии

В этой группе существует всего один критерий — совокупная стоимость владения. Не следует путать эту характеристику с ценой контракта на внедрение системы. Несмотря на то, что этот термин широко известен, кратко опишу, из чего складывается совокупная стоимость владения САБ. Совокупная стоимость владения САБ складывается из следующих составляющих:

1. Приведенной стоимости САБ (цена контракта на внедрение САБ, делённая на количество лет планируемой эксплуатации САБ);
2. Стоимости годовой поддержки САБ;
3. Приведенного фонда оплаты труда IT подразделения банка (взвешенная годовая заработная плата сотрудников с учетом степени их занятости в процессе эксплуатации САБ);
4. Приведенной стоимости обеспечивающего ПО (стоимость лицензий на операционные системы, СУБД и прочее ПО, необходимое для обеспечения эксплуатации САБ, делённая на планируемое число лет эксплуатации САБ, плюс стоимость годового сопровождения этого ПО);
5. Приведенной стоимости проекта по расширению сетевой инфраструктуры для обеспечения функционирования САБ (Общая стоимость проекта, делённая на количество лет планируемой эксплуатации САБ);
6. Приведенной стоимости проекта по аппаратному переоснащению кредитной организации для обеспечения функционирования САБ (Общая стоимость проекта, делённая на количество лет планируемой эксплуатации САБ).

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

Эта группа критериев состоит из двух небольших подгрупп: субъективных политических критериев (предпочтения высшего менеджмента банка) и объективных политических критериев: известность фирмы производителя в сфере разработки САБ и признание представленного продукта мировым сообществом. Формирование требований к САБ

Итак, все критерии перечислены, определены, определены способы их измерения, для косвенных критериев определены метрики. Теперь настала пора сформировать документ, именуемый «Требования кредитной организации к САБ». Этот документ формируется не просто объединением вышеперечисленных критериев и групп, а подразумевает определение весовых коэффициентов для каждого из критериев. Определение весовых коэффициентов — достаточно тонкий инструмент, глубоко индивидуальный для каждой кредитной организации, так как он позволяет выделить наиболее значимые для конкретного банка характеристики САБ.

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

Несмотря на всю индивидуальность построения такого рода требований, можно условно выделить три основные группы банков, так как опыт показывает весьма сходные подходы банков, входящих в состав этих групп, к проблеме выбора САБ. Зависимость весовых характеристик критериев от размера кредитной организации

Как это ни удивительно, но прослеживается практически прямая зависимость состава критериев для выбора САБ от размера кредитной организации. Также, прежде чем приступить к рассмотрению конкретных критериев, выделяемых банками той или иной группы, хочу обратить ваше внимание на следующие закономерности:

1. Чем больше размер кредитной организации, тем меньше значимость экономических критериев программного обеспечения;
2. Чем больше размер кредитной организации, тем больше значимость объективных политических критериев программного обеспечения.

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

Ещё раз оговорюсь — следует иметь в виду, что как само деление на группы, так и выделение основных критериев является весьма условным. Типовой набор критериев для малого банка

В подавляющем большинстве случаев в малом банке из всего спектра описанных ранее критериев и метрик оценки применяются две — «цена» и «предпочтения высшего менеджмента банка». «Предпочтения высшего менеджмента банка», как правило, это опыт (позитивный или негативный) высшего и среднего руководящего звена в другом банке на конкретной системе.

По моему мнению, исходя из критерия «Предпочтения высшего менеджмента банка», неоспоримыми лидерами, очевидно, являются «CS Ltd», «ProFix», СНПФ «Аргус» и «Lime Systems». Косвенно это подтверждается и долей рынка САБ вышеперечисленных компаний.

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

Основными критериями для выбора САБ банками данной группы являются — «экономические критерии представленного программного обеспечения», «критерии, характеризующие функционал представленного программного обеспечения», особенно в части реализации различных форм отчетности, «сопровождаемость» и «надежность». При выборе САБ банки этой группы, как правило, рассматривают большинство вышеперечисленных критериев, за исключением, может быть, такого критерия как «мобильность», так как ориентируются в основном на гомогенный состав аппаратных средств, в основном, на базе процессоров Intel. По всем остальным критериям данная группа банков от системы требует средних характеристик. Типовой набор критериев для крупного банка

Банки используют при выборе все перечисленные критерии по максимальным меркам. Как уже отмечалось выше, пристальное внимание уделяется «объективным политическим критериям». Следует также учитывать, что банки этой группы отдают предпочтение системам, способным обеспечить эффективное функционирование развернутой филиальной сети, и вообще рассчитывают на индивидуальный подход разработчика или же на сопровождающую разработку САБ собственными силами.

Поскольку среди САБ невозможно выделить явного лидера, то при выборе системы банк вынужден расставлять приоритеты в зависимости от определенных им целей автоматизации.

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

Выбор САБ является сложной многокритериальной задачей, и ошибки выбора стоят кредитной организации очень дорого. Как и в разработке программного обеспечения, чем раньше заложена ошибка, тем выше её цена. Самыми дорогими являются ошибки на стадии формирования требований к системе.

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

1. Привлечение сторонних наблюдателей, а тем более организаторов и исполнителей процедуры формирования требований и выбора САБ существенно повышает независимость и объективность выбора. Не секрет, что зачастую выбор САБ осуществляется на основании личных пристрастий того или иного руководителя кредитной организации. Поэтому привлечение консультантов, которые не только проводят процедуру, но могут сформировать требования к САБ, разработать и представить рекомендации по правильному выбору САБ может оказаться неоценимым;
2. Зачастую привлечение сторонних консультантов помогает грамотно отстроить приоритетность требований к САБ кредитной организации, особенно в решении задач поиска оптимального соотношения между функциональной пригодностью, корректностью и практичностью, с одной стороны, и способностью к взаимодействию, надежностью, защищенностью и сопровождаемостью, с другой стороны;
3. Наличие практических навыков и опыта в проведении выбора существенно сокращает сам процесс подготовки требований, который по разным оценкам занимает от 5% до 20% времени реализации проекта внедрения САБ, а также позволяет оптимизировать процедуру выбора и избегнуть целого ряда ошибок. Как правило, в составе персонала кредитных организаций нет специалистов, планомерно занимающихся анализом рынка САБ, и вопросами оценки программного обеспечения, к тому же персонал банка серьезно загружен текущей деятельностью, поэтому для занятий перспективными проектами не остается ни сил, ни времени. А вот в штате консалтинговых фирм, особенно специализирующихся на консалтинге в области информационных технологий такие специалисты есть. Также в арсенале этих фирм представлен целый спектр разнообразных методик оценки и выбора ПО с богатой практикой их применения.

Поэтому, практически любая кредитная организация только выигрывает от вовлечения сторонних консультантов в процесс выбора САБ. Причем схемы такого вовлечения могут быть различны — от отдельных кратких консультаций до полной организации процесса выбора и контроля внедрения сторонними консультантами.

Мне представляется, что, используя изложенный материал, Вы сможете подойти к решению проблемы составления требований к новой САБ более взвешенно и системно.

Критерии выбора тестов

Требования к идеальному критерию тестирования

Требования к идеальному критерию были выдвинуты в работе [ 11 ] :

1. Критерий должен быть достаточным, т.е. показывать, когда некоторое конечное множество тестов достаточно для тестирования данной программы.
2. Критерий должен быть полным, т.е. в случае ошибки должен существовать тест из множества тестов, удовлетворяющих критерию, который раскрывает ошибку.
3. Критерий должен быть надежным, т.е. любые два множества тестов, удовлетворяющих ему, одновременно должны раскрывать или не раскрывать ошибки программы
4. Критерий должен быть легко проверяемым, например вычисляемым на тестах

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

Поэтому мы стремимся к идеальному общему критерию через реальные частные.

Классы критериев

1. Структурные критерии используют информацию о структуре программы (критерии так называемого "белого ящика")
2. Функциональные критерии формулируются в описании требований к программному изделию ( критерии так называемого "черного ящика" )
3. Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
4. Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.

Структурные критерии (класс I).

Структурные критерии используют модель программы в виде "белого ящика", что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Структурная информация понятна и доступна разработчикам подсистем и модулей приложения, поэтому данный класс критериев часто используется на этапах модульного и интеграционного тестирования ( Unit testing , Integration testing ).

Структурные критерии базируются на основных элементах УГП, операторах, ветвях и путях.

• Условие критерия тестирования команд (критерий С0) - набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
• Условие критерия тестирования ветвей (критерий С1) - набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования .
• Условие критерия тестирования путей (критерий С2) - набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раза. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто - 2, или числом классов выходных путей).

На пример 3.1 приведен пример простой программы. Рассмотрим условия ее тестирования в соответствии со структурными критериями .

Тестовый набор из одного теста, удовлетворяет критерию команд (C0):

(X,Y)=<(x_вх=30, x_вых=0)> покрывает все операторы трассы 1-2-3-4-5-6

Тестовый набор из двух тестов, удовлетворяет критерию ветвей (C1):

(X,Y)= <(30,0), (17,17)>добавляет 1 тест к множеству тестов для С0 и трассу 1-2-4-6. Трасса 1-2-3-4-5-6 проходит через все ветви достижимые в операторах if при условии true , а трасса 1-2-4-6 через все ветви, достижимые в операторах if при условии false .

Тестовый набор из четырех тестов, удовлетворяет критерию путей ( C2 ):

Набор условий для двух операторов if c метками 2 и 4 приведен в таблица 3.1

Многокритериальные оценки, требования к системам критериев

ТЕМА 8. МНОГОКРИТЕРИАЛЬНЫЙ ВЫБОР И ОЦЕНОЧНЫЕ СИСТЕМЫ УПРАВЛЕНЧЕСКИХ РЕШЕНИЙ

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

Критерий появляется, если существует связь между целью и вводимым критерием.

Каждой цели должен соответствовать свой критерий. Например, если цель определить «экономическую доступность жилья», это легко достигается с помощью критерия «цена жилья».

В строительстве часто вместо термина «критерий» используют термины «показатель», «фактор».

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

1. Каждый критерий должен отвечать какой-то цели;
2. Критерии могут быть не только экономические, но и любые другие (техническая возможность, экология, санитария, соц. условия и т.д.) + степень риска;
3. Критерий может быть сформулирован не только количественно, но и описательно;
4. Набор критериев должен характеризоваться полнотой;
5. Ответ на каждый критерий может быть получен (нельзя ставить «туманные» критерии);
6. При невозможности получить объективную оценку критерия, возможна оценка субъективная (экспертная) на заранее оговоренных условиях.

Цели при принятии решений нередко представляют в виде дерева целей, отражающего иерархию целей. Соответственно, целе-сообразно использовать и дерево критериев.

Стандарты и спецификации в области информационной безопасности

Стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий"

Основные понятия

Мы возвращаемся к теме оценочных стандартов, приступая к рассмотрению самого полного и современного среди них - "Критериев оценки безопасности информационных технологий" (издан 1 декабря 1999 года). Этот международный стандарт стал итогом почти десятилетней работы специалистов нескольких стран, он вобрал в себя опыт существовавших к тому времени документов национального и межнационального масштаба.

По историческим причинам данный стандарт часто называют " Общими критериями " (или даже ОК). Мы также будем использовать это сокращение.

"Общие критерии" на самом деле являются метастандартом, определяющим инструменты оценки безопасности ИС и порядок их использования. В отличие от " Оранжевой книги ", ОК не содержат предопределенных "классов безопасности" . Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы.

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

Важно отметить, что требования могут быть параметризованы, как и полагается библиотечным функциям.

Как и " Оранжевая книга ", ОК содержат два основных вида требований безопасности:

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

Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы.

Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы:

• определение назначения, условий применения, целей и требований безопасности;
• проектирование и разработка;
• испытания, оценка и сертификация;
• внедрение и эксплуатация.

В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами.

В свою очередь, угрозы характеризуются следующими параметрами:

• источник угрозы ;
• метод воздействия;
• уязвимые места, которые могут быть использованы;
• ресурсы (активы), которые могут пострадать.

Уязвимые места могут возникать из-за недостатка в:

• требованиях безопасности;
• проектировании ;
• эксплуатации.

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

С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс-семейство-компонент-элемент.

Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности ).

Семейства в пределах класса различаются по строгости и другим нюансам требований.

Компонент - минимальный набор требований, фигурирующий как целое.

Элемент - неделимое требование.

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

Как указывалось выше, с помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности.

Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях).

Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности .

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

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

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

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

Функциональные требования

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности. Всего в "Общих критериях" представлено 11 функциональных классов, 66 семейств, 135 компонентов. Это, конечно, значительно больше, чем число аналогичных сущностей в " Оранжевой книге ".

Перечислим классы функциональных требований ОК:

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

Опишем подробнее два класса, демонстрирующие особенности современного подхода к ИБ.

Класс "Приватность" содержит 4 семейства функциональных требований.

Анонимность. Позволяет выполнять действия без раскрытия идентификатора пользователя другим пользователям, субъектам и/или объектам. Анонимность может быть полной или выборочной. В последнем случае она может относиться не ко всем операциям и/или не ко всем пользователям (например, у уполномоченного пользователя может оставаться возможность выяснения идентификаторов пользователей).

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

Невозможность ассоциации. Семейство обеспечивает возможность неоднократного использования информационных сервисов , но не позволяет ассоциировать случаи использования между собой и приписать их одному лицу. Невозможность ассоциации защищает от построения профилей поведения пользователей (и, следовательно, от получения информации на основе подобных профилей).

Скрытность. Требования данного семейства направлены на то, чтобы можно было использовать информационный сервис с сокрытием факта использования. Для реализации скрытности может применяться, например, широковещательное распространение информации, без указания конкретного адресата. Годятся для реализации скрытности и методы стеганографии, когда скрывается не только содержание сообщения (как в криптографии), но и сам факт его отправки.

Еще один показательный (с нашей точки зрения) класс функциональных требований - "Использование ресурсов", содержащий требования доступности. Он включает три семейства.

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

Обслуживание по приоритетам. Выполнение этих требований позволяет управлять использованием ресурсов так, что низкоприоритетные операции не могут помешать высокоприоритетным.

Распределение ресурсов. Требования направлены на защиту (путем применения механизма квот ) от несанкционированной монополизации ресурсов.

Мы видим, что " Общие критерии " - очень продуманный и полный документ с точки зрения функциональных требований. В то же время, хотелось бы обратить внимание и на некоторые недостатки.

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

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

К сожалению, в "Общих критериях" отсутствуют архитектурные требования , что является естественным следствием избранного старомодного программистского подхода "снизу вверх". На наш взгляд, это серьезное упущение. Технологичность средств безопасности, следование общепризнанным рекомендациям по протоколам и программным интерфейсам, а также апробированным архитектурным решениям, таким как менеджер/агент, - необходимые качества изделий информационных технологий, предназначенных для поддержки критически важных функций, к числу которых, безусловно, относятся функции безопасности. Без рассмотрения интерфейсных аспектов системы оказываются нерасширяемыми и изолированными. Очевидно, с практической точки зрения это недопустимо. В то же время, обеспечение безопасности интерфейсов - важная задача, которую желательно решать единообразно.

Требования доверия безопасности

Установление доверия безопасности, согласно " Общим критериям ", основывается на активном исследовании объекта оценки.

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

• действия разработчиков ;
• представление и содержание свидетельств ;
• действия оценщиков.

Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы:

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

Применительно к требованиям доверия в "Общих критериях" сделана весьма полезная вещь, не реализованная, к сожалению, для функциональных требований. А именно, введены так называемые оценочные уровни доверия (их семь), содержащие осмысленные комбинации компонентов.

Оценочный уровень доверия 1 (начальный) предусматривает анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации, а также независимое тестирование . Уровень применим, когда угрозы не рассматриваются как серьезные.

Оценочный уровень доверия 2, в дополнение к первому уровню, предусматривает наличие проекта верхнего уровня объекта оценки, выборочное независимое тестирование , анализ стойкости функций безопасности , поиск разработчиком явных уязвимых мест.

На третьем уровне ведется контроль среды разработки и управление конфигурацией объекта оценки.

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

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

На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня.

Оценочный уровень 7 (самый высокий) предусматривает формальную верификацию проекта объекта оценки. Он применим к ситуациям чрезвычайно высокого риска.

На этом мы заканчиваем краткий обзор " Общих критериев ".