Качество программного обеспечения (Software Quality). Процесс планирования качества: входы
Среди всех стандартов в области разработки программного обеспечения, используемых в настоящее время в мире, наиболее популярными моделями являются: ISO 9001, TickIT, SEI SW-CMM.
Стандарты ISO серии 9000
Стандарты международной организации по стандартизации ISO являются наиболее известными и распространенными в мире. Стандарты ISO универсальны, их можно применять в качестве моделей независимо от отрасли, в которой функционирует компания. В следствие этого у модели ISO есть свои неоспоримые преимущества и недостатки.
Но основным преимуществом модели ISO является известность, распространенность, признание на мировом уровне. Сейчас стандарты ISO являются обязательным минимумом который должна иметь любая организация существующая на рынке. Но конечно же, вследствие своей универсальности, модель на основе стандартов ISO серии 9000 получилась достаточно “высокоуровневой”
Поэтому для построения полноценной системы качества, основанной на модели ISO, необходимо использовать большое количество вспомогательных отраслевых и ISO стандартов.
Стандарт TickIT
Достаточно широкую известность получил британский стандарт TickIT. Этот отраслевой стандарт регламентирует требования к системе качества для организаций разработчиков программного обеспечения и базируется на модели ISO 9001:94. В отличие от модели ISO 9001, которая регламентирует “что необходимо сделать”, разработчики данного стандарта попытались ответить на вопрос “как” можно выполнить требования, определенные в ISO 9001. TickIT объединяет в себе модель ISO 9001 с набором рекомендательных стандартов ISO 12207 и ISO 9000-3.
Стандарты SEI SW-CMM
Очень интересный подход к улучшению внутренних процессов разработки программного обеспечения определен в модели SEI SW-CMM. В основу данной модели (также как и в основу стандартов ISO серии 9000) положена теория TQM. Теория TQM основывается на постепенном улучшении внутренних производственных процессов за счет множества небольших внедряемых в компании улучшений. Однако, модели ISO и CMM несколько различаются в своих подходах к построению самосовершенствующихся систем управления качеством и улучшению производственных процессов.
В отличие от модели ISO, где для того, чтобы соответствовать требованиям, необходимо продемонстрировать 100%-ное соответствие модели (и только оно позволяет компании самосовершенствоваться), в модели SEI SW-CMM предусмотрен поэтапный подход к построению системы совершенствования процессов. Для достижения этой цели разработчики стандарта СММ определили пять уровней, которые должна пройти организация для того, чтобы достичь основной цели – повышения эффективности функционирования процессов компании и, как следствие, улучшения качества результатов производственных процессов и разрабатываемого программного обеспечения.
Стандарты по Project Management
Одним из важных моментов, который необходимо иметь в виду при внедрении каких-либо стандартов (ISO 9000, SEI SW-CMM, TickIT, Spice ISO 15504 и т.п.), связан с тем, что структура производства компаний, разрабатывающих программное обеспечение, связана со спецификой продукта. Каждый продукт, разрабатываемый IT-компанией, уникален. И для его разработки, как правило, используется проектный тип организации производства, который тесно связан с матричной структурой управления проектами.
Управление проектами – это приложение знаний, опыта, методов и средств к работам проекта для удовлетворения требований, предъявляемых к проекту, и ожиданий участников проекта. Чтобы удовлетворить эти требования и ожидания, необходимо найти оптимальное сочетание между целями, сроками, затратами, качеством и другими характеристиками проекта.
176 комитет ISO разработал рекомендательный стандарт ISO 10006 “Менеджмент качества. Руководство качеством при управлении проектами”, который определяет основные подходы к управлению проектами и определяет его место в модели обеспечения качеством. Авторы стандартов ISO серии 9000 определяют процесс управления проектами как часть системы менеджмента качества. С другой стороны, возможен и противоположный взгляд (которого придерживаются оппоненты стандартов ISO серии 9000), согласно которому менеджмент качества является одной из составной частей системы управления проектами.
Управление проектами является скелетом производства в организациях разработчиков программного обеспечения. Поэтому неудивительно, что для приведения в соответствие системы управления качеством производства к требованиям модели ISO 9001 и к требованиям модели улучшения процессов производства SEI SW-CMM использование стандартов и признанных в мире технологий по управлению проектами является краеугольным камнем развития внутренних технологий в IT-компаниях.
Аннотация: Рассматриваются характеристики качества программных продуктов. Отмечается, что вопросы качества должны решаться на протяжении всего жизненного цикла. Показано, тестирование программного продукта позволяет гарантировать заданные параметры качества. Рассматриваются различные типы тестов и инструментарий тестирования в VisualStudio 2012. Показано, что рефакторинг кода улучшает качество программного продукта.
Презентацию к данной лекции Вы можете скачать .
Цель лекции:
Получить представление о способах и инструментарии обеспечения качества программных продуктов.
Введение
Качество программного продукта определяется по нескольким критериям. Качественный программный продукт должен отвечать функциональным и нефункциональным требованиям, в соответствии с которыми он создавался, иметь ценность для бизнеса, отвечать ожиданиям пользователей .
В жизненном цикле управления приложениями качество должно отслеживаться на всех этапах жизненного цикла ПО . Оно начинает формироваться с определения необходимых требований. При задании требований необходимо указывать желаемую функциональность и способы проверки её достижения.
Качественный программный продукт должен обладать высоким потребительским качеством, независимо от области применения: внутреннее использование разработчиком, бизнес, наука и образование, медицина, коммерческие продажи, социальная сфера, развлечения, веб и др. Для пользователя программный продукт должен удовлетворять определенному уровню его потребностей.
Важным аспектом создания качественного ПО является обеспечение нефункциональных требований, таких как удобство в эксплуатации, надежность , производительность , защищенность, удобство сопровождения . Надежность ПО определяет способность без сбоев выполнять заданные функции в заданных условиях и в течение заданного отрезка времени. Производительность характеризуется временем выполнения заданных транзакций или длительных операций. Защищенность определяет степень безопасности системы от повреждений, утраты, несанкционированного доступа и преступной деятельности. Удобство сопровождения определяет легкость, с которой обслуживается продукт в плане простоты исправления дефектов, внесения корректив для соответствия новым требованиям, управления измененной средой.
Управление жизненным циклом программного продукта помогает разработчикам целенаправленно добиваться создания качественного ПО , избегать потерь времени на переделку, повторное проектирования и перепрограммирование ПО .
Тестирование программного обеспечения
Тестирование программного продукта позволяет на протяжении всего жизненного цикла ПО гарантировать, что программные проекты отвечают заданным параметрам качества. Главная цель тестирования - определить отклонения в реализации функциональных требований, обнаружить ошибки в выполнении программ и исправить их как можно раньше в процессе выполнения проекта.
На протяжении всего жизненного цикла разработки ПО применяются различные типы тестирования для гарантии того, что промежуточные версии отвечают заданным показателям качества. При этом применяются автоматические и ручные тесты.
| Модульное тестирование | предназначено для проверки правильности функционирования методов классов ПО. Модульные тесты пишутся и исполняются разработчиками в процессе написания кода. Модульное тестирование применяется как для проверки качества кода приложения, так и для проверки объектов баз данных. |
| предназначено для тестирования, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. | |
| Интеграционное тестирование | используется для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | предполагает проверку конкретных требований к ПО и проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | предназначено для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | применяется при внесении изменений в программное обеспечение с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | предназначено для тестирования функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | представляет собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. Приемочные тесты пишутся бизнес-аналитиками, специалистами по контролю качества и тестировщиками. |
Для разработчика программного обеспечения в VisualStudio 2012 предоставлена возможность создавать модульные и нагрузочные тесты, а также тесты пользовательского интерфейса. В VisualStudio 2012 имеются следующие шаблоны тестовых проектов:
- проект модульного теста, который позволяет создавать модульные тесты в процессе разработки;
- проект с веб-тестами производительности и нагрузочными тестами;
- проект с закодированными тестами пользовательского интерфейса.
Инструментарием тестировщика в VisualStudio 2012 является MicrosoftTestManager (MTM). MTM предназначен для управления жизненным циклом тестирования программного обеспечения, включая планирование, тестирование и мониторинг . MTM интегрирован с TeamFoundationServer. С помощью Microsoft TestManager тестировщики подготавливают планы тестирования, управляют тестированием. При создании плана тестирования в него добавляются наборы тестов, тестовые случаи и конфигурации, необходимые для тестирования. Конфигурации используются для установления среды, в которой будут исполняться наборы тестов. Microsoft TestManager позволяет выполнять ручные и автоматические тесты, а также исследовательские тесты. Результаты тестирования сохраняются в базе данных, что позволяет подготавливать различные аналитические отчеты. Ошибки, выявленные в процессе тестирования, фиксируются, документируются и передаются разработчикам для их устранения. При внесении изменений в код программной системы возникает необходимость в регрессионном тестировании, причем MTM автоматически формирует план регрессионного тестирования, выявляя какие тесты должны быть повторно выполнены.
Для тестировщиков и разработчиков программного обеспечения VisualStudio 2012 включает диспетчер виртуальной среды LabManagement. Инструментарий тестирования LabManagement позволяет создать инфраструктуру, которая максимально близко эмулирует реальную среду планируемого использования программного продукта. Такие среды могут использоваться для выполнения автоматических построений, автоматизации тестов и выполнения разработанного кода.
Рефакторинг
Качество кода программного продукта во многом определяется тем, насколько трудно или легко вносить изменения в код, а также тем насколько доступен код для понимания. Созданное программное приложение может выполнять требуемые функции, но иметь проблемы с внесением изменений или пониманием созданного кода. В этом случае такое ПО нельзя назвать качественным, так как на этапе его сопровождения могут возникнуть проблемы с его модификацией при изменении пользовательских требований.
Для улучшения качества кода программных приложений применяют рефакторинг [ , ]. По определению Фаулера М. рефакторинг определяется как "процесс изменения программной системы таким образом, что её внешнее поведение не изменяется, а внутренняя структура улучшается". Следовательно, в процессе проектирования для создания высококачественного программного продукта необходимо не только обеспечить выполнение функциональных требований, но и нефункциональных, в частности, удобства сопровождения, что предполагает возможность и простоту внесения изменений в код, а также возможность легкого понимания созданного кода.
Некачественный дизайн кода определяется по ряду признаков :
- жесткость - характеристика программы, затрудняющая внесение изменений в код;
- хрупкость - свойство программы повреждаться во многих местах при внесении единственного изменения;
- косность характеризуется тем, что код содержит части, которые могли бы оказаться полезными в других системах, но усилия и риски, сопряженные с попыткой отделить эти части кода от оригинальной системы, слишком велики;
- ненужная сложность характеризуется тем, что программа содержит элементы, которые не используются в текущий момент;
- ненужные повторения, которые состоят в повторяющихся фрагментах кода в программе;
- непрозрачность, которая характеризует трудность кода для понимания.
Для создания качественного дизайна кода целесообразно применять некоторые принципы и паттерны проектирования ПО [ , ].
Принцип единственной обязанности определяет, что у класса должна быть только одна причина для изменения. Из этого принципа следует, что классу целесообразно поручать только одну обязанность.
Принцип открытости/закрытости определяет, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для модификации.
Принцип подстановки Лисков определяет, что должна быть возможность вместо базового класса подставить любой его подтип .
Принцип инверсии зависимостей определяет два положения:
- модули верхнего уровня не должны зависеть от модулей нижнего уровня. И те и другие должны зависеть от абстракций;
- абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Принцип разделения интерфейсов определяет, что клиенты должны знать только об абстрактных интерфейсах, обладающих свойством сцепленности.
Паттерны проектирования предлагают универсальные, проверенные практикой решения. В приведен обширный перечень паттернов. Среди общего списка паттернов следует выделить те, которые целесообразно применять при гибкой разработке программного обеспечения. Это паттерны Команда , Стратегия, Фасад, Посредник, Одиночка, Фабрика, Компоновщик, Наблюдатель, Абстрактный сервер/адаптер/ шлюз , Заместитель и Шлюз , Посетитель и Состояние.
Использование паттернов при разработке позволяет создавать программное обеспечение , которое легко модифицировать и сопровождать.
Следует отметить, что для проведения рефакторинга необходимо иметь надежные тесты, которые обеспечивают контроль соблюдения функциональных требований при улучшении дизайна кода программного обеспечения.
Ключевые термины
| Модульное тестирование | тестирование, предназначенное для проверки правильности функционирования методов классов ПО. |
| Исследовательское тестирование | тестирование, при котором тестировщик не имеет заранее определенных тестовых сценариев и пытается интуитивно исследовать возможности программного продукта и обнаружить и зафиксировать неизвестные ошибки. |
| Интеграционное тестирование | тестирование, предназначенное для проверки корректности совместной работы компонентов программного продукта. |
| Функциональное тестирование | тестирование, предназначенное для проверки конкретных требований к ПО, которое проводится после добавление к системе новых функций. |
| Нагрузочное тестирование | тестирование, предназначенное для проверки работоспособности программного продукта при предельной входной нагрузке. |
| Регрессионное тестирование | тестирование, применяемое при внесении изменений в программное обеспечение, с целью проверки корректности работы компонентов системы, которые потенциально могут взаимодействовать с измененным компонентом. |
| Комплексное тестирование | тестирование, предназначенное для проверки соответствия функциональных и нефункциональных требований всей системы программного продукта. |
| Приемочное тестирование | тестирование, представляющее собой функциональные испытания, которые должны подтвердить то, что программный продукт соответствует требованиям и ожиданиям пользователей и заказчиков. |
| MicrosoftTestManager | инструментарий Microsoft, предназначенный для управления жизненным циклом тестирования программного обеспечения. |
| LabManagement | диспетчер виртуальной среды тестирования. |
Набор для практики
Вопросы
- Какими характеристиками должен обладать качественный программный продукт?
- Какие нефункциональные требования определяют качество программного продукта?
- Какая роль тестирования в обеспечении качества программного продукта?
- Какие типы тестов используют для проверки качества программного продукта?
- Для чего применяется регрессионное тестирование?
- Какие шаблоны тестовых проектов имеются вVisualStudio 2012?
- Для чего применяется MicrosoftTestManager? Какие он имеет функциональные возможности?
- Для чего используется LabManagement при тестировании?
- Для чего применяют рефакторинг кода?
- Приведите признаки некачественного кода.
Упражнения
- Подготовьте аналитический обзор по NUnit тестированию.
- Подготовьте аналитический обзор по xUnit.net тестированию.
- Подготовьте аналитический обзор по MbUnit тестированию.
Если попросить группу людей высказать свое мнение по поводу того, что такое качественное ПО , можно получить следующие варианты ответов:
- Его легко использовать.
- Оно демонстрирует хорошую производительность .
- В нем нет ошибок.
- Оно не портит пользовательские данные при сбоях.
- Его можно использовать на разных платформах.
- Оно может работать 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).
- Этот стандарт выделяет следующие процессы:
- Управление качеством.
- Управление ресурсами.
- Развитие системы управления.
- Исследования рынка.
- Проектирование продуктов.
- Приобретения.
- Производство.
- Оказание услуг.
- Защита продуктов.
- Оценка потребностей заказчиков.
- Поддержка коммуникаций с заказчиками.
- Поддержка внутренних коммуникаций.
- Управление документацией.
- Ведение записей о деятельности.
- Планирование.
- Обучение персонала.
- Внутренние аудиты.
- Оценки управления.
- Мониторинг и измерения.
- Управление несоответствиями.
- Постоянное совершенствование.
- Управление и развитие системы в целом.
- Для каждого процесса требуется иметь планы развития процесса, состоящие как минимум из следующих разделов:
- Проектирование процесса.
- Документирование процесса.
- Реализация процесса.
- Поддержка процесса.
- Мониторинг процесса.
- Управление процессом.
- Усовершенствование процесса.
- Помимо поддержки и развития системы процессов, нацеленных на удовлетворение нужд заказчиков и пользователей,
- Этот стандарт выделяет следующие процессы:
Каждое ПС должно выполнять определенные функции, т.е. делать то, что задумано. Хорошее ПС должно обладать еще целым рядом свойств, позволяющим успешно его использовать в течении длительного периода, т.е. обладать определенным качеством. Качество ПС - это совокупность его черт и характеристик, которые влияют на его способность удовлетворять заданные потребности пользователей . Это не означает, что разные ПС должны обладать одной и той же совокупностью таких свойств в их высшей возможной степени. Этому препятствует тот факт, что повышение качества ПС по одному из таких свойств часто может быть достигнуто лишь ценой изменения стоимости, сроков завершения разработки и снижения качества этого ПС по другим его свойствам. Качество ПС является удовлетворительным, когда оно обладает указанными свойствами в такой степени, чтобы гарантировать успешное его использование.
Совокупность свойств ПС, которая образует удовлетворительное для пользователя качество ПС, зависит от условий и характера эксплуатации этого ПС, т.е. от позиции, с которой должно рассматриваться качество этого ПС. Поэтому при описании качества ПС должны быть, прежде всего, фиксированы критерии отбора требуемых свойств ПС. В настоящее время критериями качества ПС принято считать :
функциональность,
надёжность,
лёгкость применения,
эффективность,
сопровождаемость,
мобильность.
Функциональность - это способность ПС выполнять набор функций, удовлетворяющих заданным или подразумеваемым потребностям пользователей. Набор указанных функций определяется во внешнем описании ПС.
Надежность подробно обсуждалась в первой лекции.
Лёгкость применения - это характеристики ПС, которые позволяют минимизировать усилия пользователя по подготовке исходных данных, применению ПС и оценке полученных результатов, а также вызывать положительные эмоции определённого или подразумеваемого пользователя.
Эффективность - это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объему используемых ресурсов.
Сопровождаемость - это характеристики ПС, которые позволяют минимизировать усилия по внесению изменений для устранения в нём ошибок и по его модификации в соответствии с изменяющимися потребностями пользователей.
Мобильность - это способность ПС быть перенесенным из одной среды (окружения) в другую, в частности, с одной ЭВМ на другую.
Функциональность и надёжность являются обязательными критериями качества ПС, причём обеспечение надёжности будет красной нитью проходить по всем этапам и процессам разработки ПС. Остальные критерии используются в зависимости от потребностей пользователей в соответствии с требованиями к ПС - их обеспечение будет обсуждаться в подходящих разделах курса.
Обеспечение надёжности - основной мотив разработки программных средств
Рассмотрим теперь общие принципы обеспечения надёжности ПС, что, как мы уже подчёркивали, является основным мотивом разработки ПС, задающим специфическую окраску всем технологическим процессам разработки ПС. В технике известны четыре подхода обеспечению надёжности :
предупреждение ошибок;
самообнаружение ошибок;
самоисправление ошибок;
обеспечение устойчивости к ошибкам.
Целью подхода предупреждения ошибок - не допустить ошибок в готовых продуктах, в нашем случае - в ПС. Проведенное рассмотрение природы ошибок при разработке ПС позволяет для достижения этой цели сконцентрировать внимание на следующих вопросах:
борьбе со сложностью;
обеспечении точности перевода;
преодоления барьера между пользователем и разработчиком;
обеспечения контроля принимаемых решений.
Этот подход связан с организацией процессов разработки ПС, т.е. с технологией программирования. И хотя, как мы уже отмечали, гарантировать отсутствие ошибок в ПС невозможно, но в рамках этого подхода можно достигнуть приемлемого уровня надежности ПС.
Остальные три подхода связаны с организацией самих продуктов технологии, в нашем случае - программ. Они учитывают возможность ошибки в программах. Самообнаружение ошибки в программе означает, что программа содержит средства обнаружения отказа в процессе ее выполнения. Самоисправление ошибки в программе означает не только обнаружение отказа в процессе ее выполнения, но и исправление последствий этого отказа, для чего в программе должны иметься соответствующие средства. Обеспечение устойчивости программы к ошибкам означает, что в программе содержатся средства, позволяющие локализовать область влияния отказа программы, либо уменьшить его неприятные последствия, а иногда предотвратить катастрофические последствия отказа. Однако, эти подходы используются весьма редко (может быть, относительно чаще используется обеспечение устойчивости к ошибкам). Связано это, во-первых, с тем, что многие простые методы, используемые в технике в рамках этих подходов, неприменимы в программировании, например, дублирование отдельных блоков и устройств (выполнение двух копий одной и той же программы всегда будет приводить к одинаковому эффекту - правильному или неправильному). А, во-вторых, добавление в программу дополнительных средств приводит к её усложнению (иногда - значительному), что в какой-то мере мешает методам предупреждения ошибок.
Каждый день в своей работе мы сталкиваемся с достаточно абстрактным понятием «качество ПО» и если задать вопрос тестировщику или программисту – «что такое качество?», то у каждого найдется своё толкование. Рассмотрим определение "качества ПО" в контексте международных стандартов:
Качество программного обеспечения - это степень, в которой ПО обладает требуемой комбинацией свойств.
Качество программного обеспечения - это совокупность характеристик ПО, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
Характеристики качества ПО
Функциональность (Functionality) - определяется способностью ПО решать задачи, которые соответствуют зафиксированным и предполагаемым потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика отвечает за то, что ПО работает исправно и точно, функционально совместимо, соответствует стандартам отрасли и защищено от несанкционированного доступа.
Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных условиях на протяжении заданного промежутка времени или указанное количество операций. Атрибуты данной характеристики – это завершенность и целостность всей системы, способность самостоятельно и корректно восстанавливаться после сбоев в работе, отказоустойчивость.
Удобство использования (Usability) – возможность легкого понимания, изучения, использования и привлекательности ПО для пользователя.
Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень производительности в соответствие с выделенными ресурсами, временем и другими обозначенными условиями.
Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться, тестироваться, изменяться для исправления дефектов, для реализации новых требований, для облегчения дальнейшего обслуживания и адаптироваться к имеющемуся окружению.
Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из одного окружения (software/hardware) в другое.
Модель качества программного обеспечения
На данный момент наиболее распространена и используется многоуровневая модель качества программного обеспечения , представленная в наборе стандартов ISO 9126. На верхнем уровне выделено 6 основных характеристик качества ПО , каждую из которых определяют набором атрибутов, имеющих соответствующие метрики для последующей оценки (