10-software_engineering_quality (1133550), страница 5
Текст из файла (страница 5)
Гарантоспособность(dependability) программного обеспечения включает такие характеристики, как защищенность отсбоев (fault-tolerance), безопасность использования (safety – безопасность в контекстеприемлемого риска для здоровья людей, бизнеса, имущества и т.п. ), информационнаябезопасность или защищенность (security – защита информации от несанкционированныхопераций, включая доступ на чтение, а также гарантия доступности информации авторизованнымпользователям, в объеме заданных для них прав), а также удобство и простота использования(usability).
Надежность (reliability) также является критерием, который может быть определен втерминах гарантоспособности (см. стандарт ISO/IEC 9126-1:2001 “Software Engineering - ProductQuality, Part 1: Quality Model”).В обсуждении данного вопроса существенную роль играет обширная литература по системамповышенной надежности. При этом, применяется терминология, пришедшая из областитрадиционных механических и электрических систем (в т.ч.
не включающих программноеобеспечение) и описывающая концепции опасности, рисков, целостности систем и т.п. SWEBOKприводит ряд источников, где подробно обсуждаются эти вопросы.3.1.3 Уровни целостности программного обеспечения (Integrity levels of software)Уровень целостности программного обеспечения определяется на основании возможныхпоследствий сбоя программного обеспечения и вероятности возникновения такого сбоя. Когдаважны различные аспекты безопасности (применения и информационной безопасности), приразработке планов работ в области идентификации возможных очагов аварий могутиспользоваться техники анализа опасностей (в контексте безопасности использования, safety) ианализа угроз (в информационной безопасности, security). История сбоев аналогичных системможет также помочь в идентификации наиболее полезных техник, направленных на обнаружениесбоев и <всесторонней> оценки качества программного обеспечения.
Уровни целостности(например, градации целостности) предлагаются, в частности, стандартом IEEE 1012-98 “IEEEStandard for Software Reviews”.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru12Основы программной инженерии (по SWEBOK)Программная инженерия. Качество программного обеспечения.При более детальном рассмотрении целостности программного обеспечения в контекстеконкретных проектов, необходимо уделять специальное внимание (выделяя соответствующиересурсы и проводя необходимые работы) не только SQM-процессам (особенно, формальным,включая аудит и аттестацию), но и аспектам управления требованиями (в части критериевцелостности), управления рисками (включая планирование рисков как на этапе разработки, так ина этапе эксплуатации и сопровождения системы), проектирования (которое, для повышениягарантоспособности, в обязательном порядке предполагает глубокий анализ и проверкупланируемых к применению архитектурных и технологических решений, часто, посредствомсоздания пилотных проектов, демонстрационных стендов и т.п.) и тестирования (для обеспечениявсестороннего исследования поведенческих характеристик системы, в том числе с эмуляциейрабочего окружения/конфигурации, в которых система должна использоваться в процессеэксплуатации).3.2 Характеристика дефектов (Defect Characterization)SQM-процессы обеспечивают нахождение дефектов.
Описание характеристик дефектов играетосновную роль в понимании продукта, облегчает корректировку процесса или продукта, а такжеинформирует менеджеров проектов и заказчиков о статусе (состоянии) процесса или продукта.Существуют множество таксономий (классификации и методов структурирования) дефектов(сбоев). На сегодняшний день нет четкого консенсуса по этому вопросу и SWEBOK приводитнекоторые источники, освещающие его более подробно, упоминая, в частности, стандарт IEEE1044-93 “IEEE Standard for the Classification of Software Anomalies”. Характеристика дефектов(аномалий) также используется в аудите и оценках, когда лидер оценки часто представляет дляобсуждения на соответствующих встречах список аномалий, сформированный членами оценочнойкоманды.На фоне эволюции (и появления новых) методов проектирования и языков, наравне с новымипрограммными технологиями, появляются и новые классы дефектов.
Это требует огромныхусилий по интерпретации (и корректировке) ранее определенных классов дефектов (сбоев). Приотслеживании дефектов инженер интересуется не только их количеством, но и типом. Данныйаспект (а именно, распределение дефектов по типам) особенно важен для определения наиболееслабых элементов системы, с точки зрения используемых технологий и архитектурных решений,что приводит к необходимости их углубленного изучения, создания специализированных пилотныхпроектов, дополнительной проверки концепции (proof of concept, POC – часто применяемыйподход при использовании новых технологий), привлечения сторонних экспертов и т.п.
SWEBOKотмечает, что сама по себе информация, без классификации, часто бывает просто бесполезна дляобнаружения причин сбоев, так как для определения путей решения проблем необходима ихгруппировка по соответствующим типам. Вопрос состоит в определении такой таксономиидефектов, которая будет значима для инженеров и организации, в целом.SQM обеспечивает сбор информации на всех стадиях разработки и сопровождения программногообеспечения. Обычно, когда мы говорим “дефект”, мы подразумеваем “сбой”, в соответствии сопределением, представленным ниже. Однако, различные культуры и стандарты могутпредполагать различное смысловое наполнение этих терминов.
Частичные определения понятийтакого рода (из стандарта IEEE 610.12-90 “ IEEE Standard Glossary of Software EngineeringTerminology ”) выглядят следующим образом: Ошибка (error): “Отличие … между корректным результатом и вычисленным результатом <полученным с использованием программного обеспечения>” Недостаток (fault): “Некорректный шаг, процесс или определение данных в компьютернойпрограмме” Сбой (failure): “<Некорректный> результат, полученный в результате недостатка” Человеческая/пользовательская ошибка (mistake): “Действие человека, приведшее кнекорректному результату”Данные понятия достаточно детально рассматриваются в области знаний SWEBOK “Тестированиепрограммного обеспечения”.При обсуждении данной темы, под дефектом (defect) понимается результат сбоя программногообеспечения. Модели надежности строятся на основании данных о сбоях, собранных в процессетестирования программного обеспечения или его использования.
Такие модели могут бытьCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru13Основы программной инженерии (по SWEBOK)Программная инженерия. Качество программного обеспечения.использованы для предсказания будущих сбоев и помогают в принятии решения о прекращениитестирования.По результатам SQM-работ, направленных на обнаружение дефектов, выполняются действия поудалению дефектов из исследуемого продукта. Однако, этим дело не ограничивается.
Есть идругие возможные действия, позволяющие получить полную отдачу от результатов выполнениясоответствующих SQM-работ. Среди них – анализ и подведение итогов (резюмирование) <пообнаруженным несоответствиям/дефектам>, использование техник количественной оценки(получение метрик) для улучшения продукта и процесса, отслеживание дефектов и удаления их изсистемы (с управленческим и техническим контролем проведения необходимых корректирующихдействий). Улучшение процесса рассматривается более детально в области знаний SWEBOK“Процесс программной инженерии”. В свою очередь источником информации для улучшенияпроцесса, в частности, является SQM-процесс.Данные о несоответствиях и дефектах, найденных в процессе реализации соответствующихтехник SQM, должны фиксироваться для предотвращения их потери.
Для некоторых техник(например, технической оценки, аудита, инспекций), присутствие регистратора (recorder) –обязательно, именно для фиксирования такой информации, наравне с вопросами (в том числе,требующими дополнительного рассмотрения) и принятыми решениями. В тех случаях, когдаиспользуются соответствующие средства автоматизации, они могут обеспечить и получениенеобходимой выходной информации о дефектах (например, сводную статистику по статусамдефектов, ответственным исполнителям и т.п.). Данные о дефектах могут собираться изаписываться в форме запросов на изменения (SCR, software change request) и могут,впоследствии, заноситься в определенные типы баз данных (например, в целях отслеживаниякросс-проектной/исторической статистики для дальнейшего анализа и совершенствованияпроцессов), как вручную, так и в автоматическом режиме из соответствующих средств анализа(ряд современных средств проектирования и специализированных инструментов позволяютанализировать код и модели с применением соответствующих метрик, значимых для обеспечениякачества продуктов и процессов).
Отчеты о дефектах направляются управленческому звенуорганизации/организационной единицы или структуры (для принятия соответствующих решений вотношении проекта, продукта, процесса, персонала, бюджета и т.п.).3.3 Техники управления качеством программного обеспечения (Software Quality ManagementTechniques)Техники SQM могут быть распределены по нескольким категориям: статические техники, требующие интенсивного использования человеческих ресурсов аналитические динамические3.3.1 Статические техники (Static techniques)Статические техники предполагают <детальное> исследование (examination) проектнойдокументации, программного обеспечения и другой информации о программном продукте без егоисполнения. Эти техники могут включать другие, рассматриваемые ниже, действия по“коллективной” оценке (см.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
