Качество программного обеспечения. Качество программного обеспечения: стандарты и оценка

17.07.2019 Windows 8

Чуть больше года назад в журнале "Открытые Системы" была опубликована моя статья под названием "Принципы управления качеством программ". Онлайн версия доступна здесь: http://www.osp.ru/os/2008/06/5344965/ . Перед публикацией исходный вариант статьи был сильно переработан редакцией, в результате чего её размер уменьшился раза в 2, и текст, включая название, был также сильно перелопачен. Сейчас я решил опубликовать у себя в блоге авторскую обновлённую версию, внеся туда небольшие добавления. Статья не в формате блога, а скорее для научного или учебного издания, так что простите.

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

I. Понятие качества программного обеспечения

Определение качества программного продукта
Согласно ГОСТ Р ИСО 9000-2001 качество – это «степень соответствия присущих характеристик (продукта) требованиям». Это общее определение. Если его буквально перенести на область разработки программного обеспечения (ПО), то оно может быть не совсем верно истолковано. Дело в том, что разработка требований, в том смысле как этот термин понимается для области ПО, есть неотъемлемая часть процесса разработки этого ПО. Качество требований к программному продукту (ПП) напрямую влияет на качество самого этого ПП. Иными словами, если требования к ПП некачественные, то сам продукт, разработанный по этим требованиям, также будет некачественным даже в случае идеального соответствия.

Если слово «требования» в определении ГОСТа заменить словами «цели проекта» (здесь под проектом имеется в виду процесс разработки определённого программного продукта или расширения функциональности имеющегося продукта), то всё встаёт на свои места. Далее в статье мы будем под качеством ПП подразумевать следующее:

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

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

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

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

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

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

Обобщённое понятие дефекта
Удобно было бы ввести и использовать для анализа качества некий обобщённый критерий качества вместо нескольких разрозненных критериев. Таким критерием является обобщённое понятие дефекта:

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

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

Тип дефекта (определяется фазой разработки или активностью, на которой он был внесён);

Критичность дефекта (насколько критично его наличие в ПП);

Приоритет дефекта (насколько важно его исправить);

Сложность дефекта (насколько трудоёмко его исправить);

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

II. Управление качеством программного продукта

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

Рис. 1. Изменение количества дефектов в проекте с течением времени при традиционном подходе к управлению качеством и при водопадном жизненном цикле.

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

Эффективность поиска дефектов
Рассмотрим одну из фаз, направленных на поиск и исправление дефектов, например, фазу системного тестирования. В ходе этой фазы обнаруживается некое количество дефектов D found , в то же время некоторое количество дефектов остаётся ненайденным на момент завершения фазы D missed (рис. 2). Общее число дефектов, прошедших через фазу, будет равно D found + D missed .

Рис. 2. Изменение количества дефектов в течение одной фазы.

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

ЭПД% = .

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

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

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

Рис. 3. Изменение стоимости исправления дефектов с течением времени (водопадный жизненный цикл).

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

Рис. 4. Изменение стоимости исправления дефектов с течением времени (итерационный жизненный цикл).

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

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

Второй подход, который можно и нужно применять параллельно, – это предотвращение или недопущение дефектов , , .

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

Рис. 5. Изменение количества дефектов в проекте с течением времени при комплексном подходе к управлению качеством.

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

статические и динамические;
ручные и автоматизированные.

Таким образом, можно выделить 4 категории методов:

Ручной анализ артефактов:
Автоматическая статическая проверка:
Автоматизированное тестирование:
Ручное тестирование:

У каждого из перечисленных методов есть свои плюсы и минусы. Какие-то виды дефектов лучше ловятся одними методами, какие-то другими. Поэтому, эффективная стратегия поиска дефектов будет состоять в применении комбинации нескольких разнородных методов . Каждый метод поиска в зависимости от того, насколько хорошо он реализован и применяется в конкретных условиях, будет иметь свой собственный уровень эффективности, выраженный в процентах. В книге С. Макконнелл «Совершенный код» можно найти таблицу примерных значений эффективностей поиска дефектов для разных методов (см. копию этой таблицы ниже). Обратите внимание, что согласно этим данным тестирование имеет сравнительно низкую эффективность поиска дефектов (25%-40%), а для того, чтобы сделать её высокой, необходимо увеличить стоимость процесса тестирования в разы (эффективность бета-тестирования при количестве тестеров >1000 около 75%).

Метод поиска	ЭПД%	Метод поиска	ЭПД%
Неформальный обзор дизайна (тех. проекта)	35%	Тестирование новой функции (компонента)	30%
Формальные инспекции дизайна (тех. проекта)	55%	Интеграционное тестирование	35%
Неформальный обзор кода (code review)	25%	Регрессионное тестирование	25%
Формальные инспекции кода	60%	Системное тестирование	40%
Моделирование и прототипирование	65%	Бета-тестирование (<10 тестеров)	35%
Юнит-тестирование	30%	Бета-тестирование (>1000 тестеров)	75%

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

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

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

Применение компонентного (или модульного) подхода . Грамотное применение компонентного подхода при построении программных систем уменьшает их сложность , а, следовательно, сужает пространство возможных дефектов.

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

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

Предварительная разработка тест-кейсов (до этапа кодирования) позволяет глубже понять требования к разрабатываемой системе и лучше спроектировать её. Частный случай этого подхода – Test-Driven Development , при котором модульные тесты разрабатываются не после, а до кодирования.

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

Ваши идеи?

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

Управление качеством при итерационном жизненном цикле
Рассмотрим для примера итерационный жизненный цикл, состоящий из 5 итераций, каждую из которых можно рассматривать как маленький, но полный водопадный жизненный цикл (рис. 6).

Рис. 6. Изменение количества дефектов в проекте с течением времени при итерационном жизненном цикле.

Предположим, что эффективность поиска дефектов каждого из водопадных циклов составляет 50%, и на каждой итерации вносится одинаковое количество дефектов. Подсчитаем по формуле ЭПД%, чему будет равна эффективность поиска дефектов итерационного цикла, состоящего из пяти последовательных итераций. После 1-й итерации эта эффективность будет равна 50%; после 2-й – 62,5%; после 3-й – 70,8%; после 4-й – 76,6%; после 5-й эффективность поиска дефектов всех 5 итераций будет равна 80,6%.

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

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

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

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

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

С. Макконнелл утверждает, что «повышение качества системы снижает расходы на её разработку» , т.к. «устранение дефектов (на поздних стадиях) на самом деле – самый дорогой и длительный этап разработки ПО».

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

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

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

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

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

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

систематическое применение методов предотвращения дефектов;

постоянный контроль качества разрабатываемого ПП и процесса разработки;

постоянное усовершенствование процесса разработки с целью повышения качества.

Литература

1. Humphrey, Watts S., A discipline for software engineering, ISBN 0-201-54610-8. Copyright 1995 by Addison-Wesley.
2. Макконнелл С., Совершенный код. Мастер-класс / Пер. с англ. –М.: Издательско-торговый дом «Русская Редакция»; СПб.: Питер, 2005.
3. Humphrey, Watts S., Introduction to Team Software Process, ISBN 0-201-47719-X. Copyright 2005 by Addison Wesley Longman, Inc.
4. Humphrey, Watts S., PSP: a self-improvement process for software engineers, ISBN 0-321-30549-3. Copyright 2005 Pearson Education, Inc.
5. Амблер С., Гибкие технологии: экстремальное программирование и унифицированный процесс разработки. Библиотека программиста. Пер. с англ. –СПб.: Питер, 2005.
6. Кролл П., Кратчен Ф., Rational Unified Process – это легко. Руководство по RUP для практиков. Пер. с англ. –М.: КУДИЦ-ОБРАЗ, 2004.
7. Торрес Р. Дж., Практическое руководство по проектированию и разработке пользовательского интерфейса. Пер с англ. –М.: Издательский дом «Вильямс», 2002.
8. Бобровский С., Программная инженерия. Технологии Пентагона на службе российских программистов. –СПб.: Питер, 2003.
9. Хант Э., Томас Д., Программист-прагматик. Путь от подмастерья к мастеру. Пер. с англ. –М.: Издательство «Лори», 2004.
10. Фаулер М., Рефакторинг: улучшение существующего кода. Пер. с англ. –СПб.: Символ-Плюс, 2005.
11. Бек К., Экстремальное программирование. Пер. с англ. –СПб.: Питер, 2002.
12. Бек К., Экстремальное программирование: разработка через тестирование. Библиотека программиста. Пер. с англ. –СПб.: Питер, 2003.
13. ГОСТ Р ИСО 9000-2001, http://bib-gost.narod.ru/kazestvo/_gost_r_iso_9000_2001.zip
14. Ройс Уокер, Управление процессом создания программного обеспечения. Пер. с англ. –М.: Издательство «Лори», 2007.
15. Tian, Jeff, Software Quality Engineering, ISBN 0-471-71345-7. Copyright 2005 by the IEEE Computer Society. Методологии Сопутствующие дисциплины

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

Качество исходного кода

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

Читаемость кода
Лёгкость поддержки, тестирования , отладки, исправления ошибок, изменения и портируемости
Низкая сложность кода
Низкое использование ресурсов: памяти и процессорного времени
Корректная обработка исключительных ситуаций
Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг .

Факторы качества

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

Некоторые из факторов качества:

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

С точки зрения пользователя

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

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

См. также

Ссылки

Разработка программного обеспечения
Известные деятели
Процесс
Концепции
Направления
Модели разработки
Другие модели
Прочее

Wikimedia Foundation . 2010 .

Смотреть что такое "Качество программного обеспечения" в других словарях:

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

Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия

Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ Проектирование Программирование Докумен … Википедия

Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия

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

Новый Airbus A 380 использует довольно много ПО, чтобы создать современную кабину в самолете. Метод инженерии программного обеспечения позволил создать программное обеспечение самолёта, описываемое миллионами строк … Википедия

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

Характеристики программного продукта, которые: позволяют минимизировать усилия пользователей по подготовке исходных данных, применению программного продукта и оценке полученных результатов, а также позволяют вызывать положительные эмоции… … Финансовый словарь

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

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

Книги

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

Подходы к качеству программного обеспечения

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

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

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

ISO 9126 является стандартом на качество продукта, определяющим атрибуты и характеристики качества, включая измерения количественной оценки этих характеристик;

"усовершенствованием практики" например, является усовершенствование управления конфигурацией программного обеспечения, инспекций, тестирования и т. п.;

ISO 9000 - это совокупность стандартов, декларирующих требования для качественных систем. С точки зрения разработки программного обеспечения наиболее полезны "Руководящие указания по применению ISO 9001 при разработке, поставке и обслуживании программного обеспечения" ;

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

модель зрелости процесса разработки программного обеспечения - Capability Maturity Model for Software (CMM), предложенная Software Engineering Institute (SEI);

определение возможностей и улучшение процесса создания программного обеспечения. ISO/IEC 15504 Software Process Improvement and Capability determination (SPICE).

Два важнейших утверждения лежат в основе достижения качества.

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

Подходы к достижению качества таковы:

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

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

В настоящее время не существует общепринятых критериев качества программного обеспечения.

Стандарт ISO 9000-3, п. 6.4.1

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

Современные стандарты уточняют понятие качества, вводя совокупность черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей. Перечислим ряд таких характеристик [Жоголев 1996].

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

Надежность (завершенность, устойчивость, восстанавливаемость).

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

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

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

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

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

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

Существуют следующие подходы по обеспечению надежности:

предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.

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

Количественные критерии, связанные с различными способами оценки (метриками) сложности программ. Укажем примеры численных характеристик.

Меры Холстеда [Холстед 1981], включающие ряд формул, оценивающих длину, объем, уровень и интеллектуальное содержание программ.

Оценка сложности управляющего графа программы. Фрагмент программы может быть оценен цикломатическим числом ее управляющего графа, которое равно m - n + 2, где m - число дуг, an - число вершин управляющего графа. Считается, что цикломатическое число не должно превышать 10.

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

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

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

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

Оценка качества процесса разработки

Требовать и эффективности и гибкости от одной и той же программы -

все равно, что искать очаровательную и скромную жену.

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

Д. Вейнберг

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

Оценить качество конечного продукта.
Оценить качество процесса разработки.

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

Модель зрелости процесса разработки программного обеспечения

В модели определено пять уровней зрелости организации (http://www.sei.cmu.edu/cmm).

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

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

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

Управляемый уровень. В компании устанавливаются детальные количественные показатели на процесс разработки и качество продукта. И процесс разработки, и продукты - понимаемы и контролируемы.

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

Определение возможностей и улучшение процесса создания программного обеспечения

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

Уровень 0. Процесс не выполняется.

Уровень 1. Выполняемый процесс.

Уровень 2. Управляемый процесс.

Уровень 3. Установленный процесс.

Уровень 4. Предсказуемый процесс.

Уровень 5. Оптимизирующий процесс.

Во время оценки и улучшения качества процессов выполняются задачи [Терехов, Туньон 1999], описанные ниже.

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

Оценка возможности улучшения данного процесса на основе определения текущих возможностей.

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

О роли министерства обороны

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

"Достаточно хорошее" программное обеспечение

Вчера в Сиэтле после упоминания Биллом Гейтсом о выходе бета-версии

новой программы компании Microsoft произошло землетрясение.

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

Пропагандистом "достаточно хорошего" программного обеспечения является Эдвард Йордон [Йордон 2001]. Подчеркнем, что он применяет это понятие к "безнадежным проектам", которые связаны жесткими ограничениями на время, бюджет и людские ресурсы (см. разд. 1.6). В большинстве безнадежных проектов заказчик может быть удовлетворен системой, которая достаточно дешева, достаточно производительна, обладает необходимыми возможностями, достаточно устойчива и будет готова достаточно скоро. Фактически, эти характеристики можно считать определением "достаточно хорошего" программного обеспечения.

Оказывается, что даже "достаточно хорошее" программное обеспечение создать сложно. Приведем часть из совокупности причин, дающих этому объяснение [Йордон 2001].

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

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

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

Джеймс Бах (James Bach) указывает следующие необходимые условия для создания "достаточно хорошего" программного обеспечения:

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

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

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

Стандартизация информационных технологий

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

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

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

Процесс стандартизации информационных технологий поддерживают три основные группы организаций. Международные организации, входящие в структуру ООН. International Organization for Standardization (ISO) - международная организация по стандартизации.

Об ISO

В 1947 году представители 25 стран решили создать организацию, основной задачей которой стала бы координация разработок и унификация международных стандартов. Новая организация получила название International Organization for Standardization (ISO). Несоответствие полного названия и аббревиатуры объясняется тем, что "ISO" - это греческий префикс, означающий "равный".

International Electrotechnical Commision (IEC) - международная электротехническая комиссия.

International Telecommunication Union-Telecommunications (ITU-T) - международный союз по телекоммуникации - телекоммуникация. До 1993 года эта организация называлась International Telegraph and Telephone Consultative Committee - международный консультативный комитет по телефонии и телеграфии.

Промышленные профессиональные или административные организации.

Institute of Electrical and Electronic Engineers (IEEE) - институтинженеровпоэлектротехникеиэлектронике.

Internet Activity Board (IAB) - совет управления деятельностью Интернета.

Промышленные консорциумы.

Object Management Group (OMG) - группа управления объектами.

Х/Open - консорциум, организованный группой поставщиков компьютерной техники.

Open Software Foundation (OSF) - фонд открытого программного обеспечения.

В 1987 году ISO и IEC объединили свою деятельность в области стандартизации информационных технологий и создали единый орган - Joint Technical Committee 1 (JTC1) - объединенный технический комитет 1. Этот комитет предназначен для формирования системы базовых стандартов з области информационных технологий.

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

Попробуем ответить на вопросы:

Популярный взгляд на качество
Выводы

Что такое качество программного обеспечения?

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

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

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

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

Профессиональный подход к качеству

К сожалению, такое неопределенное и расплывчатое представление не может быть использовано для улучшения процессов разработки программного обеспечения. Следовательно, необходимо дать четкое и удобное для работы определение. В 1979 году Crosby определил качество как «соответствие требованиям» ("conformance to requirements"), а Juran и Gryna в 1970 определили качество как «пригодность к использованию» ("fitness for use"). Эти два определения тесно связанны и прекрасно согласуются, как мы увидим позже.

«Соответствие требованиям» предполагает, что требования должны быть настолько четко определены, что они не могут быть поняты и интерпретированы некорректно. Позже, на этапе разработки, производятся регулярные измерения разработанного продукта, для определения соответствия требованиям. Любые несоответствия должны рассматриваются как дефекты – отсутствие качества. Например, спецификация на определенную модель радиостанции может требовать возможности принимать определенную частоту радиоволн на расстоянии более чем 30 километров от источника вещания. В случае, если радиостанция неспособна выполнить данное требование, она не удовлетворяет требования к качеству и должна быть признана негодной и некачественной. Исходя из тех же принципов, если Кадиллак соответствует всем требованиям к машинам Кадиллак, значит это качественная машина. Если Шевроле соответствует всем требованиям к машинам Шевроле, следовательно, это тоже качественная машина. Эти две машины могут быть совершенно разными по стилю, скорости и экономичности, но если обе измерять по стандартным для них наборам, тогда они обе будут являться качественными машинами.

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

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

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

Guaspari ”I Know It When I See It”

Выводы

Давайте еще раз попытаемся дать определение качеству с точки зрения заказчика или пользователя продукта.

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

А теперь посмотрим на точку зрения разработчика.

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

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

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

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

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

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

Характеристики качества ПО

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

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

Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.

Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями.

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

Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.

Модель качества программного обеспечения

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

Рис.1 – Модель качества программного обеспечения (ISO 9126-1)

29. Характеристики качества программного обеспечения (гост).

ГОСТ ИСО 9126-93

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

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

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

4.2 Надежность (Reliability) Набор атрибутов, относящихся к способности программного обеспечения сохранять свой уровень качества функционирования при установленных условиях за установленный̆ период времени. Примечания 1 Износ или старение программного обеспечения не происходит. Ограничения надежности проявляются из-за ошибок в требованиях, проекте и реализации. Отказы из-за этих ошибок зависят от способа использования программного обеспечения и ранее выбранных версий программ. 2 В определении ИСО 8402 "надежность" - "способность элемента выполнять требуемую функцию". В настоящем стандарте функциональная.возможность является только одной из характеристик качества программного обеспечения. Поэтому определение надежности расширено до "сохранения своего уровня качества функционирования" вместо "выполнения требуемой функции" (см. также 3.4).

4.3 Практичность (Usability) Набор атрибутов, относящихся к объему работ, требуемых для использования и индивидуальной̆ оценки такого использования определенным или предполагаемым кругом пользователей̆. Примечания 1 "Пользователи" могут интерпретироваться как большинство непосредственных пользователей инте-рактивного программного обеспечения. Круг пользователей может включать операторов, конечных пользо-вателей и косвенных пользователей, на которых

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

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

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

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

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