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

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

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

Разработчики ПС стремятся выделить и определить единый критерий эффективности программ:

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

2. Позволять выявить и оценить степень влияния на эффективность системы различных факторов и параметров, и в том числе затрат различного вида на ее реализацию.

3. Быть простым и иметь малую дисперсию, т.е. мало зависеть от неконтролируемых, случайных факторов.

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

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

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

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

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

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

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

Особо следует выделить временные показатели ЖЦ программ:

1. длительность проектирования

2. продолжительность эксплуатации очередной версии

3. длительность проведения каждой модификации

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

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

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

­ Операционные системы

­ Оболочки операционных систем.

­ Программы-утилиты

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

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

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

функциональность,

надёжность,

лёгкость применения,

эффективность,

сопровождаемость,

мобильность.

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

Надежность подробно обсуждалась в первой лекции.

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

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

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

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

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

2. Обеспечение надёжности - основной мотив разработки программных средств

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

предупреждение ошибок;

самообнаружение ошибок;

самоисправление ошибок;

обеспечение устойчивости к ошибкам.

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

борьбе со сложностью;

обеспечении точности перевода;

преодоления барьера между пользователем и разработчиком;

обеспечения контроля принимаемых решений.

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

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

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

Качество программного обеспечения

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

1. Управление дефектами.
2. Атрибут качества.

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

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

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

Управление качеством ПО делится на три основных направления:

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

Политика организации SQA

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

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

Чтобы были выполнены все требования стандарта, компании назначают ответственного по качеству. Обязанности данного сотрудника:

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

Концепции высокого уровня

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

Например, при оценке синтаксического анализатора XML можно использовать набор тестов на соответствие XML W3C. Он включает в себя тесты, разработанные для удовлетворения всех направлений контроля, а также рекомендации W3C Extensible Markup Language (XML) с особым акцентом на требованиях к обработке ошибок в правильности или достоверности документов XML. Таким образом процент пройденных тестовых случаев используется, как метрика для оценки следующих характеристик рассматриваемого XML-анализатора:

• Перспектива пользователя.
• Функциональность.
• Надежность и отказоустойчивость.

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

• Кто предоставляет полный спектр необходимых функций по назначению?
• Надежно ли работает ПО для получения необходимых результатов при правильном использовании?
• Функционирует ли программа безопасно и надежно в случае неправильного ввода?
• Легко ли использовать программный продукт?
• ПО функционирует быстро или кажется излишне медленным?
• Хорошо ли сочетается программа с другим продуктом, который использует пользователь?

Считая, что вопросы качества пользователю важны, ИТ-группа, отвечающая за развертывание и обслуживание ПО, может столкнуться с другими проблемами:

1. Защита от вредоносных атак.
2. Качество использования вычислительных ресурсов.

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

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

Требования ISO 9126 к продукту

ISO 9126 является международным стандартом для оценки ПО. Он разделен на четыре части, в которых рассматриваются следующие темы:

• Внешние показатели.
• Внутренние показатели.
• Модель качества.
• Показатели качества программного обеспечения.

Первая часть ISO 9126 является расширением предыдущего стандарта, выполненного McCall (1977), Boehm (1978) и FURPS в определении набора характеристик качества.

• Функциональность.
• Надежность.
• Юзабилити.
• Ремонтопригодность.
• Портативность.

Функциональность продукта

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

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

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

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

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

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

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

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

Характеристики ремонтопригодности:

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

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

Стоимость процессов анализа

Стоимость качества рассчитывается путем анализа затрат на соответствие и несоответствие. Цена первого показателя связана с:

1. Расходами на профилактику. Это сумма, потраченная на обеспечение правильного соблюдения всех методов. Она включает в себя обучение командам, проверки кода и любые другие действия, связанные с QA.
2. Затратами на оценку. Это сумма денег, потраченная на планирование всех тестовых заданий, а затем на их выполнение, например, на разработку тестовых примеров.
3. Расходы на несоответствие. Это затраты, которые возникают из-за внутренних и внешних сбоев.

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

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

Дисциплинированный анализ процесса

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

1. Самооценка. Проводится внутри собственного персонала организации.
2. Оценка сторонней организации.
3. Оценка третьей стороной.

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

Что касается сбора данных, то используются четыре метода:

1. Стандартный перечень вопросов зрелости.
2. Индивидуальные и групповые интервью.
3. Обзоры документов.

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

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

Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding - связывание и встраивание объектов). Без таких стандартов программные продукты были бы "закрытыми" друг для друга.

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

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

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

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

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

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

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

Одна из главных причин значимости современной программы стандартизации - осознание опасности злоупотребления стандартами "де-факто". В 60-е и 70-е годы XX века создание стандартов "де-факто" ставило пользователей в зависимое от производителей положение при использовании основных средств обработки данных и телекоммуникаций. Важный аспект сегодняшней работы по стандартизации - преодоление этой зависимости через продвижение стандартных интерфейсов. Долгое время такими стандартами были SQL (Structured Query Language) и язык диаграмм Д. Росса SADT (Structured Analysis and Design Technique). Стандарт "де-юре" создается формально признанной стандартизующей организацией. Он разрабатывается при соблюдении правил консенсуса в процессе открытой дискуссии, в которой каждый имеет шанс принять участие. Ни одна группа не может действовать независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков создаст стандарт, не учитывающий требования пользователей, она потерпит неудачу. То же самое происходит, если пользователи создают стандарт, с которым не могут или не будут соглашаться поставщики, - этот стандарт также не будет успешным. Стандарты "де-юре" не могут быть изменены, не пройдя процесс согласования под контролем организации, разрабатывающей стандарты. Стандарты OSI (Open Systems Interconnection reference model), Ethernet, POSIX, SQL и большинство стандартов языков -- примеры такого рода стандартов. В качестве примера перехода стандарта "де-факто" в стандарт "де-юре" рассмотрим историю развития и стандартизации языка SQL.

Работы по созданию языка SQL были начаты в 70-х годах прошлого столетия в исследовательских лабораториях компании IBM. В настоящее время он стал одним из главных стандартов в области информационных систем и обеспечил технологию базового языка для целого поколения СУБД, основанных на реляционной модели. Несмотря на то, что он был коммерчески реализован в начале 80-х годов лишь для небольшой группы программных продуктов, SQL, бесспорно, получил признание с принятием ANSI и ISO стандарта SQL-86. Позднее, при подготовке стандарта SQL-89, в язык был включен ряд дополнительных возможностей.

Рис. 1.3. Схема классификации стандартов в области информационных технологий

Истоки SQL следует отнести к периоду рождения реляционной модели данных (описанной в статье Э.Ф. Кодда) . Поскольку в течение нескольких последующих лет не появилось никаких языков, подобных SQL, в исследовательских проектах, инициированных компанией IBM после публикации статьи Э.Ф. Кодда, придавалось особое значение необходимости создания языков интерфейса создаваемых СУБД для проверки возможностей реляционной модели. Историю разработки языка SQL иллюстрирует рис. 1.4.

В исследовательских лабораториях IBM в начале 70-х годов 20 века одновременно с работой над будущим языком SQL разрабатывались и другие проекты по созданию и экспериментальной реализации реляционных языков. Вероятно, наиболее известным из них является созданный М. Злуфом из лаборатории IBM в Йорктаун-Хейтс примерно в одно и то же время с SEQUEL (ранней версией SQL) реляционный язык Query-By-Example (QBE). Этот язык используется в настоящее время во многих коммерческих программных продуктах наряду с SQL.

В 1974 г. Дональд Д. Чамберлин из Исследовательской лаборатории IBM в Сан-Хосе предложил спецификации реляционного языка, названного SEQUEL (Structured English QUEry Language). Пересмотренная версия этого языка (SEQUEL/2) была разработана в 1976-1977 годах, и он приобрел свое окончательное название - SQL (Structured Query Language).

Еще перед тем, как коммерческие продукты IBM в начале 80-х годов 20 века вышли на рынок программного обеспечения, компания Relation Software Inc. (называющаяся теперь Oracle Corporation) объявила о выпуске реляционной СУБД, основанной на языке SQL. Эта система в результате ее эволюции стала одной из доминирующих коммерческих систем и носит название ORACLE.

Продукт ORACLE с его языком SQL столкнулся с конкуренцией в сфере средних ЭВМ и мини-ЭВМ со стороны продуктов ряда других разработчиков, в частности СУБД Ingres с языком QUEL компании Relation Technology Inc., а также продукта Rdb/ VMS с языком RDML компании Digital Equipment Corporation.

Одной из причин преуспевания SQL послужило формирование Американским национальным институтом стандартов (American National Standards Institute, ANSI) комитета ХЗН2, учрежденного для разработки стандартов языков баз данных. Представитель IBM предложил использовать в качестве предварительных спецификаций реляционного языка результаты ранее проведенной IBM работы над SEQUEL/2, и разработчики стандарта приступили к работе. Документ, озаглавленный "SQL", представлял собой по большей части трактат о различных формах SQL, используемых в коммерческих программных продуктах.

Международная организация по стандартизации (International Standards Organization, ISO) в рамках технического комитета ТС97 (называемого теперь как ISO/IEC JTC1) также вела работу по созданию стандарта языков реляционных баз данных. В середине 80-х годов как ANSI, так и ISO одобрили стандарты SQL (ANSI -в 1986 г., a ISO - в начале 1987 г.).

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

Однако еще до 1989 г. как в ANSI, так и в ISO началась работа по радикальным расширениям SQL. Эта работа, первоначально идентифицированная как "SQL2", началась в 1987 г., и ее результаты были спустя пять лет приняты в качестве стандарта SQL-92.

Добавляет путаницы еще и то обстоятельство, что работа над SQL2 перекрывалась работой над SQL3, новой версией стандарта SQL, которая еще до сих пор находится в стадии разработки. Работа над SQL3 началась еще в 1990 г. параллельно с SQL2, главным образом как над "запасным резервуаром" для возможностей, которые предполагалось не включать по тем или иным причинам в SQL2. SQL3 включает объектно-ориентированные расширения языка, а также дополнительные реляционные возможности, которым не нашлось места в SQL2 .

Проиллюстрируем на рис. 1.5 с привязкой к оси времени процесс разработки различных стандартов SQL.

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

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

Недостаток этого подхода состоит в том, что стандартом становится не самое сильное, а самое массовое коммерческое решение.

В качестве еще одного примера появления стандарта можно привести появление ныне популярного UML - Unified Modeling Language. Основные разработки по методам объектно-ориентированного анализа и проектирования появились между 1988 и 1992 гг. К 1994 г. было большое количество неформальных лидеров разработчиков-практиков (около полутора десятков), которые продвигали свои методологии. Все их методы были схожи, при этом зачастую отличия между ними заключались во второстепенных деталях. Назревал разговор о стандартизации. Команда из OMG пыталась рассмотреть проблему стандартизации, но в ответ получила открытое письмо с протестом от всех авторов. В 1996 г. три ведущих специалиста в области объектно-ориентированного анализа и проектирования Джеймс Рамбо (James Rumbaugh), Гра-ди Буч (Grady Booch), Ивар Якобсон (Ivar Jacobson) объединились, и появился на свет Унифицированный метод версии 0.8, в 1996 г. "трое друзей" работали над своим методом, который получил название Unified Modeling Language. В январе 1997 г. различные организации представили свои предложения по стандартизации методов, предусматривающие в первую очередь возможность обмена информацией между различными моделями. В результате сейчас имеется единственное предложение - стандарт UML.

Понятие «качество ПО».

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

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

Модели качества ПО имеют следующие четыре уровня представления.

Первый уровень соответствует определению характеристик (показателей) качества ПО, каждая из которых отражает отдельную точку зрения пользователя на качество. Согласно стандартам ГОСТ Р ИСО/МЭК 9126-93, ГОСТ Р ИСО/МЭК 12119-2000, ГОСТ 28195-89, в модель качества входит шесть характеристик, или шесть основных показателей качества, которые перечислим в порядке их значимости для большинства пользователей:

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

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

Рассмотрим наборы атрибутов для каждого из перечисленных показателей качества (рис. 3.1).

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

К атрибутам функциональных возможностей относятся:

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

Функциональная надежность. К атрибутам функциональной надежности ПО относятся:

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

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

Рис. 3.1.

К атрибутам удобства применения относятся:

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

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

К атрибутам эффективности ПО относятся:

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

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

Сопровождаемость включает следующие атрибуты:

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

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

Переносимость включает атрибуты:

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

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

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