Андрей Колесов

Обзор подготовлен на базе материалов, представленных в учебном курсе для подготовки к экзамену по программе сертификации Microsoft Certified Solution Developer N 70-300: Analyzing Requirements and Defining Microsoft .NET Solution Architectures. Русский перевод этого курса выпущен в 2004 г. издательством "Русская Редакция" под названием "Анализ требований и создание архитектуры решений на основе Microsoft .NET".

В последние годы мы видим, что ведущие поставщики средств разработки ПО (в первую очередь IBM Rational и Borland) от выпуска отдельных инструментов переходят к созданию комплексных платформ управления жизненным циклом приложений (application lifecycle management, ALM). Microsoft (http://www.microsoft.com) пока не форсирует процесс формирования полного спектра ALM-решений для автоматизации различных этапов производства ПО, хотя движется именно в этом направлении (об этом свидетельствуют последние новости с конференции TechEd"2004, см. врезку), и основной акцент делает на средствах проектирования и разработки - Visio, Visual Studio и т. д.

Однако для реализации идеологии ALM на практике необходим не только набор инструментов сам по себе, но и общая методологическая база. Microsoft уже более десяти лет занимается развитием собственной ALM-методологии под названием Microsoft Solutions Framework (MSF). Может показаться неожиданным, но MSF в целом - по сути платформно-независимая методология, детально описывающая отдельные процессы на уровне абстракций. Инструменты самой Microsoft присутствуют в ней в минимальной степени, лишь как примеры реализации тех или иных рекомендаций. Вместе с тем, хотя и неявно, концепция эта четко выражает общую нацеленность средств разработки корпорации (круг задач, для решения которых они предназначены), что очень хорошо видно из анализа динамики ее развития. Так, если десять лет назад MSF была ориентирована на создание локальных клиентских приложений, то сегодня - на разработку и внедрение сложных систем масштаба предприятия.

Структура процессов MSF

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

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

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

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

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

Создание общей картины приложения

На этом этапе решаются следующие основные задачи:

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

На этапе выделяются две промежуточные контрольные точки: "Организован костяк команды" и "Создана общая картина решения".

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

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

Этап завершается контрольной точкой "Утверждение документа общей картины и области действия проекта".

Планирование

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

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

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

В ходе данного этапа решаются такие задачи:

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

Контрольные точки этапа планирования связаны с достижением следующих результатов:

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

Результаты данного этапа служат для принятия компромиссных решений в дальнейшем.

Разработка

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

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

Результаты этапа предполагают следующие элементы:

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

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

Стабилизация

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

Тестирование подразумевает следующие основные виды работ:

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

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

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

Развертывание

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

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

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

Комментарии по поводу этапов работ

Добавим к изложенному выше несколько важных замечаний. В целом те же самые идеи лежат в основе всех современных промышленных методологий разработки ПО (IBM/Rational, Borland, Microsoft и т. д.). И здесь нет ничего удивительного: именно этим отличаются выверенные временем технологии от кустарного производства. Но в то же время в каждой методологии есть свой подход к выделению различных этапов разработки и зачастую используется собственная терминология, что усложняет проведение параллелей между ними. Проблема эта усугубляется и отсутствием устоявшейся русской терминологии.

Общепринятый на сегодня список ALM-этапов, которого, в частности, придерживаются Borland и Rational, выглядит следующим образом:

• Defining (определение требований);
• Designing (анализ и проектирование);
• Developing (разработка);
• Testing (тестирование);
• Deploying (развертывание).

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

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

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

Microsoft для разработчиков - новости с TechEd"2004 На проходившей в конце мая в Сан-Диего (шт. Калифорния, США) конференции Microsoft TechEd"2004 был сделан целый ряд важных объявлений относительно развития средств разработки, новых инициатив в области безопасности информационных систем и поддержки жизненного цикла продуктов Microsoft. На конференции были представлены два новых инструмента, предназначенных для интеграции с текущей версией Visual Studio .NET 2003. Первый из них, Web Services Enhancements 2.0 (WSE 2.0), позволяет повысить уровень безопасности создаваемых Web-сервисов за счет использования самых последних спецификаций протоколов WS-Security (на базе утвержденных в 2004 г. стандартов OASIS), в том числе WS-Policy, WS-Security Policy, WS-Trust и WS-SecurityConversation. Версия WSE 2.0 для VS.NET доступна уже сейчас. Кроме того, Microsoft планирует использовать эту технологию для решения задач интеграции данных и приложений: специальный модуль BizTalk Server Adapter for WSE 2.0 представлен пока лишь в виде предварительной технической версии. Второй инструмент - Microsoft Office Information Bridge Framework (IBF), реализованный сейчас в виде бета-версии, - дает возможность использовать Microsoft Office в качестве интеллектуальных клиентских приложений при работе с Web-сервисами, созданными с помощью WSE 2.0. IBF представляет собой набор из нескольких компонентов, предназначенных для разработчиков и пользователей. Один из них устанавливается со стороны Office 2003 Pro и обеспечивает взаимодействие с IBF-приложениями прямо из офисных документов через смарт-теги. Второй компонент IBF - конструктор Information Bridge Metadata Designer, подключаемый к среде VS.NET и обеспечивающий визуальную разработку Web-сервисов с использованием модели безопасности WSE 2.0. В состав IBF входит также Information Bridge Metadata Service - серверный программный модуль, позволяющий передавать на клиентское ПО данные от запущенных на выполнение бизнес-приложений через Web-сервисы. Однако для разработчиков, пожалуй, наиболее интересна информация о намерении существенно расширить в VS.NET возможности управления всем жизненным циклом приложений. Представленная на TechEd"2004 версия Visual Studio 2005 (кодовое имя Whidbey) Enterprise Edition получила название Visual Studio Team System (VSTS). Предполагается, что эта система будет поставляться в трех основных вариантах: Team Architect, Team Developer и Team Test. Предназначенный для архитекторов программных решений инструмент Team Architect включает три конструктора для проектирования распределенных приложений, моделирования логической инфраструктуры и автоматической генерации кода. Последний из них (class designer) выполняет двухстороннюю синхронизацию между визуальной моделью проекта и программным кодом. Примечательно, что в нем используется не классический UML, а собственная нотификация языка моделирования Microsoft. Для поддержки UML в Visual Studio будет по-прежнему использоваться Visio, но встроенные средства самого VS развиваются в несколько ином направлении. Team Developer включает набор инструментов, обеспечивающих выполнение статического анализа и профилирования программного кода, определение степени покрытия кода при тестировании и решение ряда других задач. Эти инструменты можно применять непосредственно в среде разработки приложения, что существенно повышает эффективность процесса отладки. Следует отметить, что Team Architect представляет собой развитие средств, уже имеющихся в текущей версии VS 2003. Функциональность же Team Developer лишь в незначительной степени покрывается текущей версией VS.NET 2003, для эффективного решения подобных задач сегодня требуется подключать соответствующие расширения для VS от третьих фирм. Но в VS 2005 разработчики смогут применять встроенные средства самой Microsoft. Что же касается третьей составляющей VSTS - Team Test, предназначенной для нагрузочного тестирования приложений, то данная функциональность ранее была доступна лишь в автономных продуктах других поставщиков. Теперь же она появилась непосредственно в среде VS 2005, причем в исполнении Microsoft. При этом особое внимание будет уделено задачам тестирования Web-сервисов, в том числе с использованием скриптов, работающих с различными транспортными протоколами, и режимов удаленного мониторинга. Из всей этой информации следует, что Microsoft наращивает возможности своего инструментария в направлении создания комплексных систем масштаба предприятия, включая в него средства автоматизированной поддержки всех этапов жизненного цикла приложений и постепенно вытесняя соответствующие расширения от третьих фирм. Тем не менее многие независимые поставщики одобрительно восприняли сделанные объявления, так как новшества VSTS позволят поднять на качественно новый уровень сотрудничество в рамках "партнерской экосистемы VS", охватывающей несколько десятков компаний-разработчиков. В частности, о своей поддержке будущего продукта на TechEd"2004 уже заявили Borland, Compuware, Telelogic AB и Unisys.

Формирование проектных команд

Один из ключевых элементов реализации проекта - задача управления коллективом его участников. Поэтому наряду с моделью процессов в MSF детально проработана модель команд (MSF Team Model), которая исходит из важности четкого понимания ролей, обязанностей и задач отдельных ее членов, а также их повышенной ответственности за реализацию проекта в целом. Она может применяться в соответствии с потребностями и контекстом проекта, размером коллектива и опытом участников команды. Ниже коротко охарактеризованы роли, используемые в модели команд MSF.

Менеджер продукта (product manager) отвечает за управление связями с клиентом. На этапе проектирования он собирает требования заказчика и ведет контроль за тем, чтобы они соответствовали потребностям его бизнеса. Он также разрабатывает план взаимодействия с клиентом в ходе реализации проекта, в том числе организует встречи с клиентом, демонстрации продукта и другие маркетинговые акции.

Менеджер программы (program manager) управляет собственно разработкой ПО и несет ответственность за его поставку в соответствии с утвержденными спецификациями.

Разработчик (developer) занимается разработкой ПО в соответствии с заданными спецификациями.

Тестировщик (tester) выявляет и устраняет все неполадки в продукте и дает окончательное разрешение на его выпуск. Он также оценивает соответствие набора реализованных в продукте функций общей концепции и области действия проекта.

Менеджер по выпуску (release manager) отвечает за развертывание и поддержку продукта, проверяет корректность ИТ-инфраструктуры заказчика на предмет ее готовности к эксплуатации ПО.

Специалист по удобству использования (user experience specialist) занимается изучением и решением проблем пользователей, оценивает продукт с точки зрения соответствия их потребностям.

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

Возможное совмещение ролей в проектной команде

	Менеджер продукта	Менеджер программы	Разработчик	Тестиров-щик	Менеджер по выпуску	Специа-лист по удобству исполь-зования
Менеджер продукта		-	-	+	-+	-+
Менеджер программы	-		-	-+	+	-+
Разработчик	-	-		-	-	-
Тестиров-щик	+	-+	-		+	+
Менеджер по выпуску	-+	+	-	+		-+
Специалист по удобству исполь-зования	+	-+	-	+	-+
Примечание: "- " - совмещение не рекомендуется, "-+ " - нежелательно, "+ " - возможно.

Кроме собственно исполнителей проекта, в команду могут входить и другие лица:

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

Управление компромиссами

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

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

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

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

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

Учитывая, что зафиксировано ____________, мы определим _____________ и в случае необходимости скорректируем ____________________.

Вставляя переменные из определенной заранее матрицы компромиссов, можно получить формулировку, соответствующую целевой задаче проекта, например:

Учитывая, что зафиксированы РЕСУРСЫ, мы определим ГРАФИК и в случае необходимости скорректируем ФУНКЦИОНАЛЬНОСТЬ.

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

Русская версия Visual Basic .NET В отличие от продуктов Microsoft массового спроса (Windows, Office), которые переведены на несколько десятков национальных языков, средства разработки Visual Studio .NET представлены сейчас лишь восемью локализованными версиями (французская, немецкая, испанская, итальянская, японская, корейская и два варианта китайских). Освоение русского языка началось лишь в этом году с одного инструмента, но зато самого массового, Visual Basic .NET Standard Edition (поставки его начались в мае 2004 г.). Чтобы представить себе значимость этого проекта, нужно иметь в виду, что полный объем локализации VS.NET 2003 составляет около 20 млн слов (включая всю справочную систему), что существенно превышает аналогичные показатели всего пакета Microsoft Office 2003. VB.NET Standard - это подмножество VS.NET, объем его локализации - 5,6 млн слов. Нужно отметить, что редакция Standard не пользовалась до сих пор большим спросом со стороны профессиональных разработчиков. Тем не менее, по мнению сотрудников московского представительства Microsoft, наличие русской документации непременно повысит интерес разработчиков к VB.NET Standard, тем более что, несмотря на усеченные функции по сравнению с версией VS.NET Pro, с помощью этого инструмента можно создавать весьма широкий круг приложений, компонентов и Web-сервисов промышленного уровня. В отличие от VS.NET Pro, VB.NET Standard не может создавать элементы управления для Windows и Web, мобильные приложения, а также мощные серверные решения. Конечно же, в VB.NET не входят другие языки программирования - VC++, VC# и VJ#. Но подчеркнем, что VS.NET Pro стоит более 1000 долл. (вариант Upgrade - 550 долл.), а VB.NET Standard - всего 100 долл. И все же появление русского VB.NET в основном связано с намерением Microsoft активно продвигать свои инструментальные средства в более широкие круги программистов, в первую очередь - в сферу образования, в частности, подготовки разработчиков. Что касается перспектив расширения линейки русскоязычных средств разработки, сотрудники Microsoft говорят об этом достаточно осторожно. Однако вероятность появления русской версии будущей VS 2005 представляется достаточно большой.

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

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

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

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

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

ь применяемый метод должен быть достаточно устойчивым к попыткам раскрыть исходный текст, имея только зашифрованный текст;

ь объем ключа должен быть оптимальным для запоминания и пересылки;

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

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

ь длина зашифрованного текста не должна превышать длину исходного текста;

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

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

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

Множество современных методов защитных преобразований можно классифицировать на четыре большие группы:

I. перестановки - заключается в том, что входной поток исходного текста делится на блоки, в каждом из которых выполняется перестановка символов;

II. замены (подстановки) - заключаются в том, что символы исходного текста (блока), записанные в одном алфавите, заменяются символами другого алфавита в соответствии с принятым ключом преобразования;

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

IV. комбинированные методы - могут содержать в себе основы нескольких методов.

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

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

Все перечисленные методы относятся к так называемому симметричному шифрованию: один и тот же ключ используется для шифрования и дешифрования.

В последнее время появились методы несимметричного шифрования:

один ключ для шифрования (открытый), второй -- для дешифрования (закрытый).

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

Правило Скрытия Информации можно сформулировать следующим образом:

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

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

Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными, или закрытыми (секретные) (secret) . Вместо терминов - общедоступные и закрытые свойства - используются также термины: экспортируемые и частные (скрытые) (private) свойства. Общедоступные свойства модуля известны также как интерфейс (interface) модуля (не следует путать с пользовательским интерфейсом системы программирования).

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

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

Рис. 3.10. Модуль в условиях скрытия информации

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

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

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

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

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

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

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

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

Из этого обсуждения следует, что ключом к скрытию информации являются не решения по организации доступа к исходному тексту модуля в рамках управления проектом или маркетинговой политики, а строгие языковые правила, определяющие, какие права на доступ к модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких "языках с инкапсуляцией" как Ada и Modula-2. Объектно-ориентированная технология программирования приведет к более полному решению проблемы.

Лет восемь назад (был на втором курсе) мой научный руководитель предложил мне в качестве темы курсовой исследование и реализацию стеганографических методов. Тема тогда была намного более новая, чем сейчас. Как-то вспомнилось - решил написать заметку. Итак... Стеганография - это наука, изучающая способы скрытой передачи информации путем скрытия самого факта передачи. Наука - абсолютно не новая по своей идее, но с изобретением цифровых способов реализации алгоритмов, применяемых в ней, ее развитие вышло на существенно новый уровень. Ввиду серьезности возможных последствий результатов применения стеганографических методов в реальной жизни и наличия людей, жаждущих острых ощущений, сразу хочу написать disclaimer:) Автор не несет никакой ответственности за возможное (злонамеренное) использование каких бы то ни было методов стеганографии и их реализаций третьими лицами и рассматривает данный материал исключительно с образовательной и исследовательской точек зрения. Вся информация получена из открытых источников и собственных наблюдений и опытов. Как мы выяснили, стеганография преследует своей целью обеспечение сокрытия и защиты информации от несанкционированного доступа. Похожие цели ставит перед собой и криптография. Существенным отличием является то, что задача криптографии - предотвратить несанкционированный доступ к информации путем двустороннего применения математических алгоритмов к данным (шифрование). Основная задача стеганографии - именно скрытие факта наличия конфиденциальной информации. Сложность алгоритмов может быть разной и влияет (в случае конечного множества принимаемых значений из области определения) на время поиска решения, которое в идеале сводится к бесконечному. На практике, естественно, применяются ключи шифрования конечной длины, что подразумевает наличие конечного множества возможных вариантов для перебора или подбора значений... Это очень обширная тема. Целью статьи не является подробное освещение особенностей алгоритмов шифрования. Скажу только (в качестве примера), что на рубеже XXI века по не до конца подтвержденным данным китайские математики смогли доказать возможность уменьшения вариантов для перебора в алгоритме SHA-1 (на основе получения хэша) с примерно 80 порядка до 63, т.е. на 17(!) порядков сразу. SHA-1 считается очень стойким алгоритмом и применяется, опять-таки - по неподтвержденным данным, правительством США как один из основных алгоритмов шифрования... (информация из открытых источников) Также, на проходившей в конце апреля-начале мая конференции Eurocrypt 2009, была продемонстрирована серьезная системная уязвимость алгоритма SHA-1, способная скомпрометировать использующие его приложения. Незадолго до опубликования отчета на Eurocrypt Национальный институт стандартов США (NIST) распорядился к 2010 году прекратить использование SHA-1 в правительственных учреждениях. Не далее, как в ноябре 2008 года, Stéphane Manuel опубликовал наличие уязвимости, снижающей сложность до 57 порядков. А уже на Eurocrypt 2009 была продемонстрирована уязвимость с возможностью уменьшения количества вариантов "всего" до 52 порядков!. Для современных суперкомпьютеров это действительно практически пустяки, чтобы считать такой алгоритм надежным... Хотя еще совсем недавно он считался крайне надежным. Однако, я отвлекся. Вернемся к возможности применения стеганографии. Каким же образом можно скрыть сам факт наличия информации? Необходимо поместить ее в такой контейнер, который бы не вызвал подозрения... Однако любое размещение _дополнительной_ информации в какой-либо контейнер влечет за собой модификацию контейнера, что уже само по себе подозрительно. Однако, и данная задача нашла решение:) На сегодняшний день наиболее интересным вариантом, с точки зрения скрытия информации, является использование медиа-файлов как контейнеров. Возникает вопрос: а как это работает? Для ответа необходимо разобраться со структурой медиа-форматов. Основные - это графика, звук и видео... Начнем с графики. Известно, что изображения состоят из пикселей, каждый из которых описывается компонентами цвета (тот же RGB, например) и описанием канала. Каждый параметр обычно изменяется в пределах определенного диапазона. Самый простой формат - BMP. Например, 24-битный BMP предоставляет нам три используемых байта на пиксел для описания цвета. Теперь зададим себе вопрос: что будет, если мы изменим каждый (или некоторые) компонент цвета на 1. Человек заметит это? Определенно, может и заметить, но только на однородной по цвету картинке. А если это натуральная фотография с большим количеством деталей (например, трава, пейзаж и тд), то человек просто не в состоянии обратить внимание на измененный пиксел. Тем более, в случае, когда он и не подозревает об этом. Таким образом, изменение всего лишь 1 бита (естественно, младшего) на компонент в картинке размером 1024х768 дает нам битовое пространство в 1024х768х3= ~2.36 миллиона битов! = ~ 300 килобайт(!) информации на файл. Т.е, грубо говоря, 1/8 размера файла. Заметьте, и это - без изменения исходного размера файла, который, к тому же, может быть просмотрен любой программой как обычная картинка. Данная техника получила незатейливое название "изменение младших битов" и основана на том, что при незначительном изменении параметров в медиа-форматах органы чувств человека не могут отличить измененный контейнер от исходного. Более того, при выборе достаточно пестрой картинки и изменении двух младших битов на компонент, мы сможем удвоить объем скрываемой информации. Очевидно, что даже 300 КБ - это очень немало. Кстати, может случиться так, что при изменении даже двух битов их значения совпадут с исходными после наложения... Т.е. изменения вообще не будет, но благодаря "контракту" при записи мы сожем извлечь информацию. Выполняя курсовую в то далекое время, автору статьи:) удалось-таки реализовать свой мини-вариант файловой системы с поддержкой иерархии каталогов, атрибутами файлов, шифрованием с хэшированием и контролем доступа на таком битовом пространстве. И, естественно, "вьювер-интегратор" для всего этого хозяйства. Может возникнуть вопрос, а зачем применять еще и шифрование? Просто мы рассматривали вариант, когда _человек_ не видит разницы в контейнере... Но то - глаз, а что нам скажут математики? А они скажут, что есть возможность попытаться использовать эвристические алгоритмы для поиска информации. Конечно, для этого необходимо сначала отыскать подозрительный контейнер. Против этого приема тоже есть выход - замести следы. Можно использовать неявный контракт в формате записи и записывать биты сохраняемых данных не в прямом порядке, а по какому-либо алгоритму. Конечно, использование BMP в современном мире уже подозрительно само по себе, но при изучении других форматов техника будет не очень сильно отличаться по своему принципу. В зависимости от сложности формата будет отличаться только максимальный объем "полезной нагрузки". Теперь далее... Звук... Ухо плохо воспринимает высокие частоты, а после 20 кГц - и вовсе никак... Между тем, многие форматы сохраняют звук в более широком диапазоне, который не всегда доступен на слух. То есть - вуаля - может использоваться в тех же целях. Мы можем изменить немало битов в звуковых данных - и это будет практически неотличимо от других "шумов". Все дело - в контракте! Мы-то знаем, как извлечь данные из такого "шума". Так как звуковые файлы имеют гораздо больший размер, то в них можно единовременно сохранить намного больше информации. Может дойти до парадокса, что в картинке мы можем сохранить другую картинку, в звуке - другой звук... Объем-то позволяет (без изменения размера исходного файла!). Наверное, многие догадались, что нас ждет с видео, где количество шума может быть еще бОльшим. Правильно: можно использовать как минимум ключевые кадры в качестве контейнеров. Поле для деятельности в случаях использования звука и видео намного более широкое, чем с графикой. Ведь в видео есть еще и звуковая дорожка! Да и обнаружить такую информацию будет намного сложнее. Да, есть еще один способ. Это скрытие текста в тексте. Т.е. когда по определенному алгоритму из текста-контейнера (может быть что угодно, любой связный текст) извлекаются символы для составления скрываемого сообщения. Но этот способ требует поистине творческого подхода при низкой отдаче. Поэтому развития, естественно, в цифровом мире не получил. При наличии таких-то собратьев, как графика, звук и видео. Замечу, что все виды контейнеров предполагается возможным использовать по их прямому назначению: картинки - смотреть, звук - слушать и т.д. И, напоследок, хотелось бы рассказать о том, какое продолжение получает стеганография. В статье нигде не упоминалось, но данный вид скрытия информации может быть и полезным в широком смысле. Один из таких вариантов - это цифровая авторская подпись. Стоит отметить, что после модификации контейнера вероятность потери данных при пересохранении файла-контейнера достаточно велика. Однако, потенциально автор может доказать авторство своей работы, скрыв свою подпись внутри самой работы. Как обычно, человеческий разум не знает предела... появились методы, которые позволяют восстановить скрытую информацию в графике даже после ее распечатки и (!) последующего сканирования. На этом завершаю свой "обзор" методов стеганографии... Хотя, поле для мыслей и применений в этой области действительно большое.

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

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

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

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

Комментарий к Ст. 237 УК РФ

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

Преступления, предусмотренные ч. 1 комментируемой статьи, относятся к категории преступлений небольшой тяжести; преступления, предусмотренные ч. 2, — к категории преступлений средней тяжести.

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

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

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

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

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

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

Окружающая среда — совокупность компонентов природной среды, природных и природно-антропогенных объектов (ст. 1 Закона об охране окружающей среды).

Объективная сторона преступления выражается: 1) в сокрытии информации (путем действия и бездействия); 2) в искажении информации (путем действия).

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

Искажение информации — предоставление необъективной, недостоверной, фальсифицированной информации, сообщение неполных или недостоверных данных, официальных прогнозов, оценок и т.д.

4. Обязательным условием сокрытия или искажения информации является создание опасности для жизни или здоровья людей либо для окружающей среды.

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

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

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

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

Отсутствует состав указанного преступления в случае сокрытия или искажения информации, которая в соответствии с Законом РФ от 21.07.1993 N 5485-1 «О государственной тайне» (в ред. от 08.11.2011) не могла быть сообщена тем или иным лицам.
———————————
РГ. 1993. 21 сент.; СЗ РФ. 1996. N 15. Ст. 1768; 1997. N 41. Ст. 4673; 2002. N 52 (ч. 2). Ст. 5288; 2003. N 6. Ст. 549; N 27 (ч. 1). Ст. 2700; N 46 (ч. 2). Ст. 4449; 2004. N 27. Ст. 2711; N 35. Ст. 3607; 2007. N 49. Ст. 6055, 6079; 2009. N 29. Ст. 3617; 2010. N 47. Ст. 6033; РГ. 2011. N 159, 160, 254.

8. Субъект преступления — специальный. Им может быть физическое лицо, обязанное обеспечить население и органы, уполномоченные на принятие мер по устранению опасности, соответствующей информацией. Подобная обязанность возлагается на них законом или иным нормативным правовым актом, инструкцией. Например, такими лицами могут быть должностные лица органов государственной власти, органов местного самоуправления, сотрудники специальных подразделений (владельцы информационных систем, сотрудники и руководители органов местного самоуправления, бюро прогнозов, санэпидемстанций, МЧС России, МВД России).

9. Квалифицирующим признаком ч. 2 комментируемой статьи является совершение указанного преступления лицом, занимающим государственную должность РФ или субъекта РФ, а также главой органа местного самоуправления (см. коммент. к ст. 285).

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

Под причинением в результате совершенного преступления вреда здоровью человека понимается вред здоровью любой тяжести, в том числе и тяжкий вред. Поэтому дополнительной квалификации действий виновного помимо ч. 2 комментируемой статьи еще и по ст. 118 УК не требуется.

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