Lecture03

Технологии программирования. Компонентный подход
В. В. Кулямин
Лекция 3. Требования. Качество ПО и методы его обеспечения.
Потребности, функции, требования. Варианты использования.
Требования к ПО определяют, какие свойства и характеристики оно должно иметь для
удовлетворения потребностей пользователей и других заинтересованных лиц.
Для того, чтобы ПО действительно было полезным, важно, чтобы отражались их
реальные потребности, которые часто отличаются от непосредственно выражемых
пользователями и заказчиками желаний. Для выявления этих потребностей зачастую
приходится проводить достаточно значительную работу. При разработке ПО для
непосредственной продажи это практически очевидно — чтобы оно действительно
продавалось, необходимо сначала выяснить, что же хотят его потенциальные покупатели.
Но и при разработке на заказ, когда заказчик приходит с вроде бы готовым заданием —
например, ему нужно сделать систему поддержки контроля качества строительства и
эксплуатации магистральных газопроводов — полезно выяснить, в чем же именно он
нуждается, какие основные задачи должна решать эта система, какие из задач стоят очень
остро и обязательно должны быть отражены уже в первой версии, а какие могут и
потерпеть.
Определение потребностей базируется на анализе предметной области, выявляющего
основные цели и задачи деятельности организаций-будущих пользователей системы.
Потребности выявляются на основе наиболее актуальных проблем и задач, которые эти
организации видят перед собой. При этом часто требуется аккуратное рассмотрение
текущей ситуации, выявление значимых проблем и расстановка приоритетов их решения,
поскольку чаще всего решить сразу все проблемы невозможно.
Формулировка потребностей может быть разбита на следующие этапы.
1. Выделить одну-две-три основных проблемы
2. Определить причины возникновения проблем, оценить их степень влияния и
выделить наиболее существенные из проблем, влекущие появление остальных
3. Выявить всех заинтересованных лиц, которым придется иметь дело с системой
4. Определить границы системы — линию раздела между системой, которую надо
сделать, и ее окружением, влияние которого надо учитывать
5. Определить ограничения на возможные решения
Формулировка потребностей не должна накладывать лишних органичений на
возможные решения, удовлетворяющие им. Нужно попытаться сформулировать, что
именно является проблемой, а не придумывать сразу возможные решения.
Например, формулировки «система должна использовать СУБД Oracle для хранения
данных», «нужно, чтобы при вводе неверных данных раздавался звуковой сигнал» не
очень хорошо описывают потребности (за исключением особых случаев, например, если
использование конкретного поставщика СУБД является внешним ограничением,
политикой компании, при этом первая формулировка должна быть взята за основу).
Соответствующие потребности лучше описать так: «нужно организовать надежное
хранение данных», «необходимо предотвращать попадание некорректных данных в
хранилище».
При выявлении потребностей пользователей используются такие приемы, как
анкетирование, демонстрация раскадровок работы будущей системы, интерактивные
сеансы, где пользователям предоставляется возможность самим предложить варианты
внешнего вида системы и ее работы или поменять предложенные кем-то другим,
прототипы.
На основе потребностей пользователей формулируются возможные функции будущей
системы, представляющие собой услуги, удовлетворящие потребности одной или
нескольких групп пользователей (или других заинтересованных лиц). Идеи для
определения функций можно брать из имеющегося опыта (наиболее часто используемый
источник) или из результатов мозговых штурмов и других форм выработки
Формулировка функций должна быть достаточно короткой, ясной для пользователей,
без лишних деталей. Например:
 Все данные о сделках и клиентах будут сохраняться в базе данных
 Статус выполнения заказа можно будет узнать через Интернет
 Система будет поддерживать до 1000 одновременно работающих пользователей
 Расписание проведения ремонтных работ будет строится автоматически
Только имея набор функций, достаточно полно решающий проблемы, выделенные на
предыдущем этапе как наиболее существенные, можно составлять требования —
детализацию работы этих функций. При этом надо учитывать, что часто ПО является
частью программно-аппаратной системы, требования к которой надо преобразовать на
требования к программной и аппаратной ее составляющим (в последнее время, в связи со
значительным падением цен на мощное аппаратное обеспечение общего назначения,
фокус внимания переместился, в основном, на программное обеспечение). Соотношение
между проблемами, потребностями, функциями и требованиями изображено на Рис. 1.
Четкость,
конкретность,
полнота
Проблемы
Потребности
Функции
Требования к ПО
Рисунок 1. Соотношение между проблемами, потребностями, функциями и требованиями.
Каждое требование раскрывает детали поведения системы при выполнении ею
некоторой функции в некоторых обстоятельствах. При этом часть требований происходит
из пожеланий заинтересованных лиц и решений, удовлетворяющих эти пожелания, а часть
— из внешних ограничений, накладываемых на систему, например, законами той области
знания, в рамках которой системе придется работать, государственным
законодательством, корпоративной политикой и пр.
Еще до перехода от функций к требованиям полезно расставить приоритеты и оценить
трудоемкость их реализации и рискованность. Это позволит отказаться от реализации
наименее важных функций еще до их детальной проработки, а также выявить наиболее
проблемные места проекта.
Список стандартов, определяющих правила работы с требования к ПО (и более
общими, системными требованиями), выглядит так.
 IEEE 830-1998 Recommended Practice for Software Requirements Specifications.
Описывает структуру документов для фиксации требований к ПО.
Кроме того, он определяет характеристики, которыми должен обладать правильно
составленный набор требований.
o Корректность (соответствие реальным потребностям)
o Недвусмысленность (однозначность понимания)
o Полнота (отражение всех основных потребностей)
o Непротиворечивость (согласованность между различными элементами)
o Упорядоченность по важности и стабильности
o Возможность проверки
o Модифицируемость
o Прослеживаемость в ходе разработки (возможность увязать требование с
подсистемами, модулями и операциям, ответственными за его выполнение,
и с тестами, проверяющими его выполнение)
 IEEE 1233-1998, 2002 Guide for Developing System Requirements Specifications.
Описывает правила построения требований для (программно-аппаратных) систем в
целом.
Сейчас широко распространены техники фиксации требований в виде вариантов
использования.
Вариантом использования (use case) называют некоторый сценарий действий системы,
который обеспечивает ощутимый и значимый для ее пользователей результат. На
практике в виде одного варианта использования оформляется сценарий действий системы,
который будет, скорее всего, неоднократно возникать во время ее использования и имеет
достаточно четко определенные условия начала выполнения и завершения.
Примеры сценариев использования:
 Покупатель в Интернет магазине выбирает товар. Для этого он может выбрать
категорию товара, фирму-изготовителя или группу таких фирм, и отфильтровать
оставшиеся товары по цене, габаритам и цвету. Определившись, он выбирает товар,
кликая на соответствующем значке мышкой.
 Оператор системы контроля качества газопровода ищет участки газопровода с
повышенным риском аварии. Для этого он выбирает группу ранее случившихся
аварий, фильтруя их по дате, нанесенному ущербу, типу аварии и запускает
процедуру анализа характеристик соответствующих участков газопровода на
совпадения по крайней мере двух (учитывается изготовитель труб и их партия,
история хранения труб на складах, землепроходческая бригада, бригада сварщиков,
показатели химической активности грунтов и пр.). После этого на карте выделяются
участки, характеристики которых также попадают под найденный «шаблон аварии».
В языке UML варианты использования изображают в виде овалов на соответсвующих
диаграммах. Варианты использования могут быть связаны с участвующими в них
действующими лицами (actors), представляющими различные роли пользователей
системы или внешние системы, взаимодействующие с ней.
Поиск
товара
Выбор
товара
Добавление
товара
Покупатель
Оператор сайта
Выбор способа
оплаты
Удаление
товара
Рисунок 2. Диаграмма «сырых» вариантов использования для простого Интернет-магазина.
Кроме того, варианты использования могут быть связаны друг с другом двумя видами
связей: связями расширения и использования.
Вариант использования B расширяет (extends) вариант использования A, если B
определяет дополнительные действия, которые вставляются в некоторое место в сценарии
работы A. Рассмотрим систему регистрации участия студентов в курсах. В ее рамках есть
вариант использования «Регистрации участия студента в некотором курсе». Если в
институте есть иностранные студенты и их регистрация трубет каких-то дополнительных
действий, вариант использования «Регистрация участия иностранного студента в курсе»
будет расширять указанный ранее.
Вариант использования B использует (uses, или включает, includes) вариант
использования A, если B включает полностью сценарий A где-то внутри своего сценария
работы. В рамках той же системы может существовать вариант использования
«Исправление ошибочно введенных данных о студенте». Если в рамках регистрации
студента такое исправление становится возможным, то вариант использования
«Регистрация участия студента в курсе» использует «Исправление ошибочно введенных
данных».
Основная разница между расширением и использованием состоит в целях двух
находящихся в таком отношении вариантов использования. Если их цели по большому
счету одинаковы, пользователь ожидает от них примерно одинаковых результатов, то
один из них расширяет другой, если цели существенно различны — то использует.
Покупка
include
Поиск товара
extend
Поиск по
изготовителю
extend
include
Поиск по
названию
Ведение
данных
include
include
Покупатель
Выбор способа
оплаты
Удаление
товара
Оператор сайта
extend
extend
Изменение
данных о товаре
extend
Добавление
товара
Рисунок 3. Доработанная диаграмма вариантов использования для простого Интернет-магазина.
Хорошо описанный вариант использования должен иметь следующие данные.
1. Имя, ясно говорящее о назначении соответсвующего сценария
2. Описание. Несколько предложений, описывающих этот вариант использования.
3. Частота. Насколько часто соответсвующий сценарий возникает.
4. Предусловия. Все условия запуска такого сценария.
5. Постусловия. Все условия, которые выполнены по успешном выполнении
сценария.
6. Основной сценарий работы, который используется в большинтсве случаев.
7. Альтернативные сценарии, возникающие иногда. Для каждого альтернативного
сценария указываются условия его срабатывания.
8. (Необязательно) Задействованные роли (actors).
9. (Необязательно) Расширяемые варианты.
10. (Необязательно) Используемые варианты.
11. (Необязательно) Статус — в разработке, готов к проверке, в процессе проверки,
подтвержден, отвергнут.
12. (Необязательно) Допущения об окружениии и ходе работ системы,
использованные при разработке сценария. В полностью готовом сценарии эти
допущения должны быть подтверждены и стать ограничениями системы либо
давать начало различным подсценариям работы.
Качество ПО.
Как проверить что требования заданы достаточно полно? Для этого служит понятие
качества ПО.
Если попросить группу людей высказать своё мнение по поводу того, что такое
качественное ПО, можно получить следующие варианты ответов:
 Его легко использовать
 Оно демонстрирует хорошую производительность
 В нем нет ошибок
 Оно не портит пользовательские данные при сбоях
 Его можно использовать на разных платформах
 Оно может работать 24 часа в сутки и 7 дней в неделю
 В него легко добавлять новые возможности
 Оно удовлетворяет потребности пользователей
 Оно надежно
 Оно хорошо документировано
Все это действительно имеет непосредственное отношение к качеству ПО. Но все эти
ответы выделяют характеристики, важные для конкретного пользователя, разработчика
или группы таких лиц. Для повышения степени удовлетворения всех заинтересованных
сторон, для достижения прочного положения на рынке и повышения потенциала развития
важен учет всей совокупности характеристик ПО, важных для всех заинтересованных лиц:
конечных пользователей, заказчиков, разработчиков, администраторов систем, в которых
оно будет работать, регулирующих организаций и пр.
Приведенные ответы показывают, что качество ПО может быть описано только
большим количеством разнородных характеристик.
Общие принципы разработки качественных продуктов во всех отраслях экономики
регулируются набором стандартов ISO 9000. Наиболее важные для разработки ПО
стандарты в его составе следующие.
 ISO 9000:2000 Quality management systems — Fundamentals and vocabulary.
Системы управления качеством — Основы и словарь. (Аналог ГОСТ Р-2001).
 ISO 9001:2000 Quality management systems — Requirements. Models for quality
assurance in design, development, production, installation, and servicing.
Системы управления качеством — Требования. Модели для обеспечения качества
при проектировании, разработке, коммерциализации, установке и обслуживании.
Определяет общие правила обеспечения качества результатов во всех процессах
жизненного цикла. (Аналог ГОСТ Р-2001)
 ISO 9002:1994 Quality systems — Model for quality assurance in production, installation
and servicing.
Системы качетсва — Модель для обеспечения качества при коммерциализации,
установке и обслуживании.
 ISO 9003:1994 Quality systems — Model for quality assurance in final inspection and test.
Системы качества — Модель обеспечения качества при финальном
инспектировании и тестировании.
 ISO 9004:2000 Quality management systems — Guidelines for performance
improvements.
Системы управления качеством. Руководство по улучшению деятельности. (Аналог
ГОСТ Р-2001).
 ISO 9000-3:1997. Стандарты в области административного управления качеством и
обеспечения качества. Часть 3. Руководящие положения по применению стандарта
ISO 9001 при разработке, поставке и обслуживании программного обеспечения.
Понятие качества ПО в виде совокупности атрибутов качества определяется
стандартом ISO 9126. В этом стандарте выделено 6 основных факторов качества ПО,
называемых также целями, и каждый из факторов качества описывается при помощи
нескольких входящих в него атрибутов.
Ниже приведен полный список этих атрибутов по стандарту ISO 9126:2001.
 Функциональность (определяет, что делает ПО, какие задачи оно решает)
 Пригодность к определенной работе (suitability)
 Точность, правильность (accuracy)
 Способность к взаимодействию (interoperability)
 Соответствие стандартам и правилам (compliance)
 Защищенность (security)
 Надежность («насколько надежно ПО работает»)
 Зрелость, завершенность (обратна к частоте отказов) (maturity)
 Устойчивость к отказам (fault tolerance)
 Способность к восстановлению работоспособности при отказах (recoverability)
 Соответствие стандартам надежности (reliability compliance, добавлен в 2001)
 Практичность, удобство использования («насколько удобно пользоваться ПО»)
 Понятность (understandability)
 Удобство обучения (learnability)
 Работоспособность (operability)
 Привлекательность (attractiveness, добавлен в 2001)
 Соответствие стандартам практичности (usability compliance, добавлен в 2001)
 Эффективность («насколько эффективно работает ПО»)
 Временные характеристики (time behaviour)
 Использование ресурсов (resource utilisation)
 Соответствие стандартам эффективности (efficiency compliance, добавлен в 2001)
 Сопровождаемость («насколько удобно вносить изменения и поправки в ПО»)
 Анализируемость (analyzability)
 Изменяемость, удобство внесения изменений (changeability)
 Риск возникновения неожиданных эффектов при внесении изменений (stability)
 Контролируемость, удобство проверки (testability)
 Соответствие стандартам сопровождаемости (maintainability compliance, добавлен
в 2001)
 Переносимость, мобильность («насколько удобно переносить ПО в другое
окружение»)
 Адаптируемость (adaptability)
 Устанавливаемость, удобство установки (installability)
 Способность к сосуществованию с другим ПО (coexistence)
 Удобство замены другого ПО данным (replaceability)
 Соответствие стандартам переносимости (portability compliance, добавлен в 2001)
Помимо перечисленных выше атрибутов стандарт ISO 9126:2001 определяет
некоторые наборы метрик для оценки каждого атрибута. Примеры таких метрик:
 Полнота реализации функций. Используется для измерения пригодности.
 Корректность реализации функций. Используется для измерения пригодности.
 Отношение числа обнаруженных дефектов к прогнозируемому. Используется для
определения зрелости.
 Отношение числа проведенных тестов к общему их числу. Используется для
определения зрелости.
 Отношение числа доступных проектных документов к указанному в их списке.
Используется для измерения анализируемости.
Для того чтобы получить качественное ПО, надо иметь список требований к нему по
всем перечисленным характеристикам. Требования определяют, какие свойства ПО по
данной характеристике хотят видеть заинтересованные стороны. Таким образом,
требования должны определять следующее.
 Что ПО должно делать. Примеры:
Позволять клиенту оформить заказы и обеспечить их доставку;
Обеспечивать контроль качества строительства и отслеживать проблемные места;
Поддерживать нужные характеристики автоматизированного процесса
производства, предотвращая аварии, и оптимальным образом используя имеющиеся
ресурсы.
 Насколько оно должно быть надежно. Примеры:
Работать 7 дней в неделю и 24 часа в сутки;
Допускается неработоспособность в течение не более 3 часов в год.
Никакие введенные пользователями данные при отказе не должны теряться.
 Насколько им должно быть удобно пользоваться. Примеры:
Покупатель должен легко находить нужный ему товар;
Инженер по специальности «строительство мостов» должен легко понимать, как
пользоваться системой.
 Насколько оно должно быть эффективно. Примеры:
Поддерживать обслуживание до 10000 запросов в секунду;
Время отклика на запрос при максимальной загрузке не должно превышать 3 с;
Время реакции на изменение параметров процесса производства не должно
превышать 0.1 с;
На обработку одного запроса не должно тратиться более 1 MB оперативной памяти.
 Насколько удобно должно быть его сопровождение. Примеры:
Добавление в систему нового вида запросов не должно требовать более 3 человекодней;
Добавление поддержки нового процесса производства не должно занимать более 24
человеко-месяцев.
 Насколько оно должно быть переносимо и заменяемо. Примеры:
ПО должно работать на операционных системах Linux, Windows XP и MacOS X;
ПО должно работать с документами в форматах MS Word 97 и HTML;
ПО должно сохранять файлы отчетов в форматах MS Word 2000, MS Excel 2000,
HTML, RTF и в виде обычного текста.
ПО должно сопрягаться с существующей системой записи данных о заказах.
Методы контроля качества
Как контролировать качество системы? Как точно узнать, что программа делает
именно то, что нужно, и ничего другого? Как определить, что она достаточно надежна,
переносима, удобна в использовании?
Ответы на этот вопрос можно получить с помощью процессов верификации и
валидации.
 Верификация — проверка того, что продукт делался правильно, т.е. проверка того,
что он разрабатывался в соответствии со всеми требованиями по отношению к
процессу и этапам разработки.
 Валидация — проверка того, что сам продукт правилен, т.е. установление того, что
он удовлетворяет требованиям, ожиданиям пользователя, заказчика и других
заинтересованных сторон.
Эффективность верификации и валидации, как и эффективность разработки ПО
зависит от точности и корректности формулировки требований к программному продукту.
Выделяют следующие методы обеспечения качества ПО.
 Тестирование — частный вариант верификации и валидации, состоящий в
наблюдении за работой ПО в специальных условиях, на некоторых данных с целью
проверки соответствия его свойств требованиям.
Такого рода специальные условия называют тестовыми или просто тестами.
Тестирование бывает следующих видов.
o Функциональное (оно же черного ящика) — это тестирование проверяет
соответствие системы требованиям, пользуясь при этом, как для создания
тестов, так и для оценки степени соответствия только самими требованиями.
o Структурное (оно же белого ящика) — тесты создаются на основе знаний о
структуре самой системы и о том, как она работает. Для оценки степени
соответствия требованиям могут привлекаться дополнительные знания о
прослеживании требований в определенные условия на значения
внутренних данных системы (например, в органичения на значаения
параметров вызовов, результатов и локальных переменных).
o Тестирование производительности. При этом виде тестирования измеряются
показатели производительности системы и определяется, насколько они
соответствуют требуемым, а также, не может ли экстраполяция этих данных
привести к нарушению требований в других возможных ситуациях. В
случае возникновения серьезных подозрений во втором случае, тесты





производительности дорабатываются для проверки этих дополнительных
ситуаций.
 Нагрузочное тестирование. Это особый вид тестирования
производительности, целью которого является определение
характеристик производительности системы при большой нагрузке
на нее (большом количестве пользователей, интенсивном обмене
данными с другими системами, большим объемом
передавемых/используемых данных, и пр.)
o Тестирование на отказ (smoke testing) имеет целью обнаружение ситуаций, в
которых система выходит из строя, хотя не должна делать этого.
o Тестирование удобства использования проверяет насколько система удобна
в использовании. Делается это на основе измерения времени, необходимого
на обучение работе с системой, и производительности труда при работе с
системой различных групп пользователей (уже знакомых с ней, незнакомых,
опытных в данной предметной области, новичков и пр.).
o Тестирование преносимости проверяет работоспособность системы в
разных окружениях.
o Тестирование на соответствие проверяет строгое соответствие требованиям
любого рода, зафиксированным в достаточно строгом и полном виде
(спецификациям, стандартам, корпоративной политике, и пр.).
o Модульное, интеграционное и системное тестирование — различаются
масштабом целей.
Модульное тестирование предназначено для проверки правильности работы
отдельных модулей, вне зависимости от окружения, интеграционное — для
проверки того, что модули корректно работают вместе (используют друг
друга, не нарушая взаимных ограничений на такое использование),
системное — для проверки правильности работы системы в целом и ее
способности решать заявленные задачи в различных ситуациях.
Инспектирование, т.е. целенаправленное изучение кода и документов на предмет
поиска ошибок определенного вида (по заранее определенному набору шаблонов),
двусмысленностей, расхождений со стандартами оформления, нессоответствий
между отдельными документами или частями одного документа
Формальный анализ: формальное доказательство свойств ПО и формальный анализ
эффективности алгоритмов
Неформальный анализ: анализ статической семантики языков программирования,
автоматизированный анализ кода на предмет обнаружения сомнительных мест,
анализ свойств ПО и архитектуры человеком
Измерения: определение метрик ПО, проекта, документации, измерения
производительности, измерения трудоемкости работы с ПО, скорости обучения,
профилирование (измерение времени работы отдельных элементов кода в рамках
реалистичных сеансов работы, измерение затрат памяти на отдельные виды
объектов, отдельными процедурами)
Использование моделей различного рода — каждый вид моделей моделирует ПО,
соответствуя ему в каких-то свойствах и пренебрегая другими, не значимыми для
целей моделирования. Применяются
o Модели использования (какие операции использует пользователь, насколько
часто, как долго он работает с отдельными экранами и диалогами) для
анализа удобства использования ПО
o Модели использования и надежности для анализа надежности и
производительности
o Модели функционирования для анализа свойств и их проверки на моделях.
Обычно к проверке свойств на моделях (model checking) прибегают для
того, чтобы проверить работоспособность каких-то отдельных
архитектурных или алгоритмических решений, которые планируется
использоват при построении сложных систем, их способность
соответствовать требованиям. В качестве проверяемых свойств часто
выступают
 Отсутствие взаимных блокировок процессов (deadlocks) — ситуаций,
при которых несколько параллельных процессов ждут освобождения
ресурсов друг другом и не могут продолжать работу из-за этого.
 Завершаемость отдельных циклов — то, что выполнение цикла
завершится после конечного числа шагов.
 Завершаемость циклов обмена сообщениями между процессами —
отсутствие livelocks, т.е. ситуаций, при которой параллельные
процессы бесконечно обмениваются сообщениями и не способны
выполнить какую-либо другую работу.
 Слабая справедливость системы — свойство, гарантирующее, что
каждый запущенный процесс через некоторое время получит все
необходимые для его работы ресурсы и сможет продвинутся в
выполнении своей задачи.
 Сильная справедливость системы — свойство, гарантирующее, что
каждый запущенный процесс через некоторое время после любого
момента получит все необходимые для его работы ресурсы и сможет
продвинутся в выполнении своей задачи.
o Прототипирование — построение прототипов системы для оценки
достижимости тех или иных целей и получения отзывов от
заинтересованных лиц
Использование различных методов обеспечения качества регламентируемтся
следующими стандартами — их довольно много.
 IEEE 730-2002 Standard for Software Quality Assurance Plans.
Описывает структуру планирования обеспечения качества.
 IEEE 829-1998 Standard for Software Test Documentation.
Описывает виды документов, служащих для подготовки тестов.
 IEEE 982.1-1988 Standard Dictionary of Measures to Produce Reliable Software
 IEEE 1008-1987 (R1993, R2002) Standard for Software Unit Testing
 IEEE 1012-1998 Standard for Software Verification and Validation
 IEEE 1028-1997 (R2002) Standard for Software Reviews
 IEEE 1044-1993 (R2002) Standard Classification for Anomalies
 IEEE 1061-1998 (R2004) Standard for Software Quality Metrics Methodology
 IEEE 1228-1994 (R2002) Standard for Software Safety Plans
 IEEE 1465-1998 [Adoption of ISO/IEC 12119: 1994(E)], Standard Adoption of
International Standard ISO/IEC 12119: 1994(E) Information Technology — Software
packages. Quality requirements and testing
 ISO/IEC 12119:1994 (AS/NZS 4366:1996) Software packages — Quality requirements
and testing
 ISO 10005:1995 — Административное управление качеством. Руководящие указания
по программам качества.
 ISO 10006:1997 — Руководство по качеству при управлении проектом.
 ISO 10007:1995 — Административное управление качеством. Руководящие указания
при управлении конфигурацией.
 ISO 10013: 1995 — Руководящие указания по разработке руководств по качеству.
 ISO 10011-1-3:1990. Руководящие положения по проверке систем качества. Ч. 1.
Проверка. Ч. 2. Квалификационные критерии для инспекторов-аудиторов систем
качества. Ч. 3. Управление программами проверок.
 ISO 14598-1-6: 1998-2000. Оценивание программного продукта. Ч. 1. Общий обзор.
Ч. 2. Планирование и управление. Ч. 3. Процессы для разработчиков. Ч. 4. Процессы
для покупателей. Ч. 5. Процессы для оценщиков. Ч. 6. Документирование и
оценивание модулей.
 ISO 9126-1-4. (проекты). ИТ. Качество программных средств: Ч. 1. Модель качества.
Ч. 2. Внешние метрики. Ч. 3. Внутренние метрики. Ч. 4. Метрики качества в
использовании.
 ISO 14756: 1999. ИТ. Измерение и оценивание производительности программных
средств компьютерных вычислительных систем.
 ISO 12119: 1994. (ГОСТ Р-2000). ИТ. Требования к качеству и тестирование.
 ISO 15408-1-3: 1999. (ГОСТ Р-2002). Методы и средства обеспечения безопасности.
Критерии оценки безопасности информационных технологий. Ч. 1. Введение и
общая модель. Ч. 2. Защита функциональных требований. Ч. 3. Защита требований к
качеству.
 ISO 13335-1-5: 1996-1998. ИТ. ТО. Руководство по управлению безопасностью. Ч. 1.
Концепция и модели обеспечения безопасности информационных технологий. Ч. 2.
Планирование и управление безопасностью информационных технологий. Ч. 3.
Техника управления безопасностью ИТ. Ч. 4. Селекция (выбор) средств обеспечения
безопасности. Ч. 5. Безопасность внешних связей.
 ISO 10181: 1-7. ВОС. 1996-1998. Структура работ по безопасности в открытых
системах. Ч. 1. Обзор. Ч. 2. Структура работ по аутентификации. Ч. 3. Структура
работ по управлению доступом. Ч. 4. Структура работ по безотказности. Ч. 5.
Структура работ по конфиденциальности. 4. 6. Структура работ по обеспечению
целостности. Ч. 7. Структура работ по проведению аудита на безопасность.
Ошибки в ПО
Ошибками в ПО, вообще говоря, являются все возможные несоответствия между
демонстрируемыми характеристиками его качества и предписанными требованиями и,
иногда, ожиданиями пользователей.
В англоязычной литературе используется несколько терминов, часто переводящихся
как «ошибка» на русский язык.
 defect — самое общее нарушение каких-либо требований или ожиданий, не
обязательно проявляющееся вовне (к дефектам относятся и нарушения
стандартов кодирования, недостаточная гибкость системы и пр.)
 failure — нарушение требований, проявляющееся при каком-то реальном
сценарии работы ПО, это скорее проявление ошибки
 fault — ошибка в коде программы, вызывающая нарушения требований при
работе (failures), то место, которое надо исправить. Хотя это понятие
используется довольно часто, оно, вообще говоря, не вполне четкое, поскольку
для устранения нарушения можно исправить программу в нескольких местах.
Что именно надо исправлять, зависит от дополнительных условий, выполнение
которых мы хотим при этом обеспечить.
 error — используется в двух смыслах.
Первый — это ошибка в ментальной модели программиста, которая заставляет
его делать ошибки в коде (faults).
Второй смысл — это некорректные значения данных (выходных или
внутренних), которые возникают при ошибках в работе программы.
Первое место в неформальном состязании за место «самой дорого обошедшейся
ошибки в ПО» (см. [10,11]) долгое время удерживала ошибка, приведшая к неудаче
первого запуска ракеты Ариан-5 4 июня 1996 года (см. [12]), стоившая около $500 M.
После произошедшего 14 августа 2003 года обширного отключения электричества на
северо-востоке Северной Америки, стоившего экономике США и Канады от 4 до 10
миллиардов долларов [13], это место закрепилось за вызвавшей его ошибкой в системе
управления электростанцией.
Литература
[1] И. Соммервилл. Инженерия программного обеспечения. Вильямс, 2002.
[2] А. Якобсон, Г. Буч, Дж. Рамбо. Унифицированный процесс разработки
программного обеспечения. Питер, 2002.
[3] Э. Дж. Брауде. Технология разработки программного обеспечения. Питер, 2004.
[4] Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному
обеспечению. Унифицированный подход. Вильямс, 2002.
[5] A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000.
[6] В. В. Липаев. Методы обеспечения качества крупномасштабных программных
средств. М., Синтег, 2003.
[7] Е. А. Жоголев. Лекции по технологии программирования: Учебное пособие. М.,
Издательский отдел факультета ВМиК МГУ, 2001.
[8] Б. Боэм, Дж. Браун, Х. Каспар и др. Характеристики качества программного
обеспечения. М., Мир, 1991.
[9] ISO/IEC 9126-1. 2001. Software engineering – Software product quality – Part 1: Quality
model. Geneva, Switzerland: International Organization for Standardization.
[10] http://www5.in.tum.de/~huckle/bugse.html
[11] http://infotech.fanshawec.on.ca/gsantor/Computing/FamousBugs.htm
[12] http://www.ima.umn.edu/~arnold/disasters/ariane5rep.html
[13] http://www.elcon.org/Documents/EconomicImpactsOfAugust2003Blackout.pdf