6. Разработка программ оценки сложности ПО на базе отдельных метрик сложности программ - метрик стилистики, и понятности программ

Лабораторная работа №1

Цель работы: Оптимизация программ (процесс замены имеющихся операторов на более быстро работающие, различные способы реализации вычислений).

Краткие теоретические сведения и методические указания к выполнению работы

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

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

Определение 2 (IEEE): Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

Анализ всех составляющих качества должен проводиться с учетом сфер ответственности заинтересованных сторон, как внутренних участников исполняемого процесса (in-process stakeholder), так и пользователей процесса (end-of-process stakeholders).

Очевидно, что управление качеством требует контроля всех измерений и оценок качества в жизненном цикле ПС (рис.1).

Измерение и оценка характеристик качества ПО

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

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

Рис.1. Анализ Измерения и оценки качества в контуре управления качеством.

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

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

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

Измерение (оценка) одной или нескольких характеристик программы дает представление о том, насколько программе присуще то или иное свойство.

Каждому свойству соответствует одна или несколько характеристик программного обеспечения.

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

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

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

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

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

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

Интервальная шкала фиксирует не только отношение порядка, но и величину, отличающую одно значение характеристики от другого (интервал между значениями).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Показатель качества - численное значение критерия качества, определяющее степень, в которой программе присуще определенное критерием свойство. В соответствии с ГОСТ 15467-79 под показателем качества следует понимать количественную характеристику одного или нескольких свойств программной продукции, составляющих ее качество применительно к определенным условиям ее создания и эксплуатации.

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

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

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

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

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

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

Концепция и сущность управления качеством ПС

Основное содержание концепции управления качеством сводится к следующим положениям:

1. Требования к уровню качества по каждому фактору определяют базовым значением показателя качества

2. Требуемый уровень качества обеспечивается процессом и в процессе производства.

3. Измерение, оценка и контроль уровня качества производится на всех стадиях жизненного цикла.

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

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

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

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

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

Рис. 2. Группы свойств и характеристики программного обеспечения

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

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

Рис.3. Факторы качества, отражающие полезность ПО

Рис. 4. Модель измерений характеристик качества (по ГОСТ 28195-89.)

Рис. 5. Управление качеством и разработка ПС

Роль стандартизации и сертификации в управлении качеством ПС

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

Стандартизация выполняет следующие функции:

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

2) закрепление в нормативных документах оптимальных требований к упорядоченным объектам;

3) установление правил применения этих нормативных документов.

На международном уровне стандартизация:

1) обеспечивает взаимозаменяемость элементов сложной продукции;

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

3) содействует взаимообмену научно-технической информацией;

4) содействует международной торговле.

5) ускоряет научно-технический прогресс участников международных организаций.

Необходимость стандартизации разработки ПС на международном уровне, согласно стандарту ИСО/МЭК 12207 (введение), определена следующим образом: "Программное обеспечение является неотъемлемой частью информационных технологий и традиционных систем, таких, как транспортные, военные, медицинские и финансовые. Имеется множество разнообразных стандартов, процедур, методов, инструментальных средств и типов операционной среды для разработки и управления программным обеспечением. Это разнообразие создает трудности при проектировании и управлении программным обеспечением, особенно при объединении программных продуктов и сервисных программ. Стратегия разработки программного обеспечения требует перехода от этого множества альтернатив к общему порядку, который позволит специалистам, практикующимся в программном обеспечении, "говорить на одном языке" при разработке и управлении программным обеспечением. Этот международный стандарт обеспечивает такой общий порядок".

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

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

Виды нормативных документов, рекомендуемые международными организациями по стандартизации (ИСО/МЭК), а также принятые в государственной системе стандартизации представлены на рис. 5. (стандарты, технические условия, своды правил, регламенты, положения).

Рис.6. Схема разновидностей нормативных документов

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

Таким образом, стандарты в разработке ПС важны по целому ряду причин. Основными из них являются:

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

2. Стандарты предоставляют необходимую основу для процесса обеспечения качества: достаточно контролировать соблюдение стандартов.

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

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

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

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

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

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

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

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

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

Типовые этапы в разработке программ:

· разработка спецификации требований к программе;

· определение архитектуры;

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

· разработка кода и тестирование.

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

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

Вариант 1

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

IF X=1 THEN

BEGIN <оператор> END;

IF X=2 THEN

BEGIN <оператор> END;

IF X=3 THEN

BEGIN <оператор> END;

IF X=1 THEN

BEGIN <оператор> END

ELSE IF X=2 THEN

BEGIN <оператор> END

ELSE IF X=3 THEN

BEGIN <оператор> END;

CASE X OF

1: BEGIN <оператор> END;

2: BEGIN <оператор> END;

3: BEGIN <оператор> END;

END;

Вариант 2

Посчитать в процентном соотношении быстродействие циклических операторов (WHILE, REPEAT, FOR):

Вариант 3

Посчитать в процентном соотношении быстродействие арифметических операторов. Произвести для сравнения замену дробных чисел целыми, замену оператора деления на оператор умножения и так далее. Например, Rez:= X / 4.0 заменить на Rez:= X * 0.25.

Вариант 4

Посчитать в процентном соотношении быстродействие операций записи на диск и чтения с диска с помощью замены процедур Read и Write на BlockRead и BlockWrite.

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

Вариант 5

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

Вариант 6

Повысить производительность программ за счет:

a) замены операций обработки строк на операции с массивами. Например, замените оператор иницилизации строки

FOR I := 1 TO 240 DO

St:=St + `*';

на

FOR I:=1 TO 240 DO

St[I]:=`*';

St[0]: = Chr[240];

b) замены процедуры Copy на команду Move:

например, заменив оператор

NewSt:= Copy(DldSt, 60, 38);

на комбинацию

Move(DldSt[60], NewSt[1],38);

NewSt[0]:= Chr(38);

Контрольные вопросы

1. Дать определение качества ПО согласно международным стандартам.

2. Что такое управление качеством ПО?

3. Что мы понимаем под понятиями свойства и характеристика программы?

4. Перечислить известные характеристики измерительных шкал ПО.

5. Какие существуют группы методов оценки характеристик ПО?

6. Что образует иерархию характеристик качества ПО?

7. Нарисовать модель измерений характеристик качества ПО согласно ГОСТ.

8. Перечислить положения составляющие основное содержание концепции управления качеством ПС.

9. Какие основные виды деятельности составляют сущность управления качеством в процессе разработки ПС?

10. Необходимость стандартизации и сертификации в управлении качеством ПС.

11. Каковы типовые этапы в разработке программы?

12. Что означает взвешенная насыщенность класса 1 в объектно-ориентированном проекте?

13. Что означает глубина дерева наследования в объектно-ориентированном программировании?

14. О чем говорит чрезмерная связность объектов?

15. Пояснить, что означает отклик на класс?

16. Что понимается под оптимизацией программы?

Лабораторная работа №2

Краткие теоретические сведения и методические указания к выполнению работы

Защита от несанкционированного доступа

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

Защита готовых программных продуктов осуществляется от:

1) копирования;

2) модификации фрагмента программы, отражающего авторство (чаще всего в заставке системы) при сохранении всего остального текста программы;

3) несанкционированной эксплуатации.

Защита данных выполняется от:

1) нежелательной модификации;

2) уничтожения;

3) несанкционированного чтения.

Проблемы защиты имеют организационный и технологический аспекты.

Организационный аспект предполагает:

1) разработку и строгое соблюдение правил доступа к магнитным носителям;

2) хранение магнитных носителей в местах, не доступных для посторонних лиц;

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

4) хранение данных, относящихся к разным задачам, на отдельных носителях;

5) информация, находящаяся на жестком диске, должна иметь копии на ленте или гибких дисках.

Организационные аспекты хорошо отработаны в фирмах-производителях программных продуктов и достаточно полно описаны.

Технологические аспекты включает программную и аппаратную защиту Программная защита применяется для предотвращения от несанкционированной перезаписи или незаконной эксплуатации. Аппаратная защита носит самый разнообразный характер и аппаратным путем предотвращает доступ к отдельной программе, к магнитному носителю или к ресурсам компьютера в целом. Так, против незаконной эксплуатации широко применяется следующая технология: аналог ключа (то есть микросхема, имеющая ПЗУ) подключается к адаптеру RS-232 для IBM PC и программа сразу после старта запрашивает зашитый в ПЗУ пароль. Если пароль не подтвержден, программа завершает работу. Для обеспечения. ЕХЕ-файла этой защитой достаточно указать его имя специальной программе, которая присоединяет блок обращения к ПЗУ ключа к соответствующему исполнительному коду. Такая технология обеспечивает работу защищенной программы только на той машине, где имеется ключ. Этим примером ограничим рассмотрение аппаратной защиты, так как она связана с языком Паскаль крайне незначительно.

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

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

Далее введем два понятия - Хозяин и Злоумышленник, - 6ез| которых трудно ясно описать логическую суть защиты программных продуктов. Хозяин - это лицо, разработавшее или эксплуатирующее на законном основании определенный программный продукт. Злоумышленник - лицо, которое желает эксплуатировать без разрешения программный продукт Хозяина на его компьютере (цель 1) или, переписав на промежуточный носитель, установить и эксплуатировать на своем компьютере (цель 2).

Для нейтрализации цели 1 защита должна:

1) не допустить старта программного продукта;

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

3) если система относится к классам СПП или ОСПП, то для исключения возможности снятия защиты Злоумышленником и повторного старта может потребоваться уничтожение на диске. ЕХЕ-файла выполняющейся программы или вообще всех файлов на доступных носителях.

Для нейтрализации цели 2 защита должна:

1) не допустить копирования определенного программного продукт с компьютера Хозяина на промежуточный носитель Злоумышленника;

2) если копирование все же удалось, активизировать все средства защиты, указанные для нейтрализации цели 1.

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

Защита на стадии выполнения

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

При организации защиты предварительно разрабатывается ее сценарий. Сценарий состоит из трех частей:

1) запрос с требованием сообщить пароль;

2) реакция на неправильный ответ;

3) реакция на правильный ответ.

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

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

Повысить надежность пароля поможет выполнение следующих требований:

1) пароль должен состоять не менее чем из 6 символов;

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

3) ввести в строку пароля хотя бы один пробел, небуквенный символ или прописную букву;

4) в зависимости от степени секретности пароль должен знать ограниченный круг лиц;

5) записи, содержащие пароль, должны храниться в недоступных посторонним местах;

6) пароль должен регулярно меняться.

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

Сценарий 1:

1) запросить пароль;

2) проанализировать ответ;

3) если ответ неправильный, завершить выполнение программы;

4) если ответ правильный, продолжить выполнение.

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

Сценарий 2:

1) запросить пароль;

2) проанализировать ответ;

3) если ответ неправильный, уничтожить на диске.EXE-файл вызванной программы и завершить выполнение;

4) если ответ правильный, продолжить выполнение программы.

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

Сценарий 3:

1) запросить пароль;

2) проанализировать ответ;

3) если ответ неправильный, уничтожить на диске определенную группу файлов;

4) если ответ правильный, продолжить выполнение программы.

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

Сценарий 4:

1) запросить фамилию;

2) проанализировать ответ, сверив его со списком фамилий в системе;

3) если введенной фамилии нет в списке, выйти из программы;

4) если введенная фамилия имеется в списке системы; продолжить работу;

5) запросить пароль;

6) проанализировать ответ;

7) если ответ неправильный, уничтожить все имеющиеся на диске файлы;

8) если ответ правильный, продолжить выполнение программы.

Защита авторского права

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

- коммерческое наименование фирмы-изготовителя либо фамилия автора;

- краткое наименование программного продукта;

- номер версии программного продукта;

- год издания;

- в случае необходимости место издания.

Пример:

Turbo Pascal 6.0 Copyright (c) 1990 by Borland International.

All rights reserved.

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

- запрещено несанкционированное копирование программ и документации;

- запрещено вносить изменения в программы;

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

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

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

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

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

- при возникновении определенных условий во время выполнения программы;

- постоянно в специально зарезервированном для этого месте экрана;

- в начале либо в конце выполнения программы.

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