Материалы представленные на сайте исключительно с целью ознакомления пользователям Интернета и не преследуют коммерческих целей или нарушение авторских прав.
© 2018 - 2024
· План измерений должен быть оценен и утвержден соответствующими заинтересованными лицами. Это включает процедуры сбора данных, их хранения, анализа и отчетности; критерии оценки; расписание и распределение ответственности. Критерии обзора и оценки этих артефактов должны быть установлены на уровне организационной единицы или выше. Такие критерии должны принимать во внимание существующий опыт, доступность ресурсов и потенциальный срыв проекта когда предлагается изменение существующих практик. Утверждение (approval) <выделения ресурсов> демонстрирует поддержку и принятие обязательств по проведению измерений.
· Ресурсы должны быть доступны для реализации запланированных и утвержденных задач по ведению измерений. Доступность ресурсов может быть распределена по стадиям внедрения изменений в процесс измерений, например, когда изменения производятся изначально в “пилотном” режиме, а уже затем, становятся составной частью стандартного процесса (т.е. используемого в рамках всего проекта, подразделения или организации). Также, необходимо уделять внимание ресурсам, необходимым для успешного внедрения новых процедур и измерений (метрик).
Овладение и внедрение технологий поддержки <измерений>. Это включает оценку доступных технологий, выбор наиболее соответствующих (заданному контексту и ограничениям) технологий, их приобретение и овладение ими и, наконец, внедрение в повседневную практику.
9.6.3 Выполнение процесса измерений (Perform the Measurement Process)
Интеграция процедур проведения измерений с соответствующими процессами. Процедуры измерения (например, сбор данных) должны быть интегрированы в оцениваемые процессы. Это может приводить к изменению самих процессов для адаптации действий по сбору или генерации необходимых данных. Это может подразумевать и анализ существующих процессов для минимизации дополнительных усилий, и оценку влияния на сотрудников, необходимые для реального принятия процедур проведения измерений. Важно понимать и принимать во внимание моральные и другие аспекты “человеческого фактора”, без которых проведение измерений, как дополнительная (к функциональной) деятельность будет восприниматься лишь как помеха основной работе. Более того, процедуры измерений должны обсуждаться с теми, кто непосредственно предоставляет данные; может потребоваться соответствующее обучение персонала; необходимо обеспечить и соответствующую поддержку (по аналогии с технической поддержкой программного обеспечения). Анализ данных и процедуры отчетности должны быть интегрированы в организационные и/или проектные процессы.
Сбор данных. Данные должны собираться, верифицироваться и сохраняться <для дальнейшего использования>.
| Информационный продукт (information product) - этот термин используется в отношении результатов измерений |
Обсуждение результатов. Полученный “информационный продукт” должен быть документирован и передан пользователям и заинтересованным лицам.
9.6.4 Оценка измерений (Evaluate Measurement)
| Сильные и слабые стороны ( S trengths and weaknesses) – два из четырех элементов SWOT-анализа. SWOT - Strengths, Weaknesses, Opportunities, Threats – сильные стороны, слабые стороны, возможности, угрозы. Обычно представляется как совокупность четырех указанных факторов. |
Оценка процесса проведения измерений. Данная оценка проводится на соответствие специфицированным критериям оценки и определяет сильные и слабые стороны самого процесса. Оценка может проводиться в рамках внутренних процессов или внешнего аудита и должна включать анализ отзывов от лиц, использующих полученные результаты. Сделанные выводы должны быть записаны в соответствующую базу данных.
Определение потенциальных возможностей улучшения / усовершенствований процесса проведения измерений. Такие рекомендации по улучшению могут заключаться в изменении формата используемых количественных индикаторов, единиц измерения или изменений в их классификации (категориях метрик). Необходимо определять стоимости и отдачу (benefits) от предлагаемых улучшений и отобрать те из них, которые соответствуют целям и критериям измерений, после чего сформулировать действия, необходимые для внедрения выбранных улучшений. Предполагаемые улучшения должны быть обсуждены и утверждены заинтересованными лицами. Отсутствие потенциальных улучшений (если они не были идентифицированы в результате проведенного анализа) также должно быть обсуждено с заинтересованными лицами.
// IEEE Std 982.1 содержит совокупность показателей для прогноза и оценки надежности программного продукта.
10. Управление качеством
4 часа
Три дня и три ночи мастер не появлялся из своей кельи. На четвертый день монахи отправили послушника проведать его.
Мастер был занят созерцанием диаграммы потоков данных. Послушник узнал в ней второстепенную деталь обширной системы, поддержкой которой занимались монахи. Поклонившись, послушник поинтересовался, над чем работает мастер.
Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»
Послушник воскликнул: «Но вы же проповедуете важность расстановки приоритетов, как же можете вы зацикливаться на чем-то столь мелком и незначительном?»
Ни слова не говоря, мастер поднял посох и с силой опустил его на босую ногу послушника, сломав тому мизинец. Послушник закричал от боли и заплетающимся шагом покинул келью. В этот момент он достиг просветления.
Что такое качество и почему оно должно быть столь глубоко представлено (в виде самостоятельной области знаний)? На протяжении многих лет отдельные авторы и целые организации определяли термин качество по-разному. Фил Кросби в 1979 году дал определение качеству как соответствие пользовательским требованиям Уотс Хемпфри (Watts Hamphrey, оригинальный автор концепции модели оценки зрелости CMM, а также PSP и TSP – People Software Process и Team Software Process) описывает качество как достижение отличного уровня пригодности к использованию. Компания IBM, в свою очередь, ввела в оборот фразу качество, управляемое рыночными потребностями. Критерий Бэлдриджа для организационного качества использует похожую фразу – качество, задаваемое потребителем, рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ISO 9001 как степень соответствия присущих характеристик требованиям (именно так это сформулировано в официальном переводе ИСО 9000-2000 "Системы менеджмента качества. Основные положения и словарь).
Эти взгляды перекликаются и с предлагаемым в этом переводе термином приемлемое качество, определяемым не только уровнем запросов конечных потребителей в отношении параметров создаваемого продукта, но и заданным контекстом/ограничениями проекта. Это не значит, что приемлемое качество противопоставляется “качеству, диктуемому заказчиком”. Конечно, не стоит и проводить параллель приемлемого качества с “продуктом второй свежести”. Введение категории “приемлемости” в отношении качества является лишь прагматичным взглядом на желаемую степень совершенства создаваемого продукта (услуги), способную удовлетворить пользователей и достижимую в рамках заданных проектных ограничений. Интересно, что и сама “степень приемлемости” также выступает в роли ограничения проекта, а в приложении к индустрии программного обеспечения представлена практически во всех областях проектной деятельности – от управления требованиями (атрибуты качества как категория нефункциональных требований), до тестирования (т.н. наработка на отказ, такие метрики как MTTF - Mean Time To Failure, то есть среднее время между обнаруженными сбоями системы, и т.п. ). В какой-то степени, приемлемое качество можно сравнивать с уровнем обслуживания в рамках заданного уровня предоставляемого сервиса (SLA – Service Level Agreement), давно уже принятого на вооружение в телекоммуникационной индустрии. Таким образом, приемлемое качество может рассматриваться как количественно выраженный компромисс между заказчиком и исполнителем в отношении характеристик продукта, создаваемого исполнителем в интересах заказчика с учетом других ограничений проекта (в частности, стоимостью, что часто именуется как cost of quality – стоимость качества). Можно сказать, что такой взгляд может в какой-то степени рассматриваться как расширение определения ISO 9001 с учетом достигнутого компромисса между заказчиком и исполнителем (поставщиком) в отношении характеристик качества (Орлик, 2004).
Данная глава (область знаний) рассматривает вопросы качества программного обеспечения, выходя за рамки <отдельных> процессов жизненного цикла. Качество программного обеспечения является постоянным объектом заботы программной инженерии и обсуждается во многих областях знаний (что вполне обосновано, если учесть поистине катастрофический уровень проваленных проектов и неудовлетворенность пользователей программных продуктов, ставшая притчей во языцех для программной индустрии).
В общем случае, существует ряд путей достижения качества программного обеспечения. В частности, эта область знаний касается статических техник, не требующих выполнения оцениваемых программных систем, в отличие от динамических техник, рассмотренных в области знаний “Тестирование” (раздел 6).
10.1 Основы качества программного обеспечения
(Software Quality Fundamentals)
Согласие, достигнутое по требованиями к качеству (quality requirements), наравне с четким доведением до инженеров того, что составляет качество получаемого продукта, требуют обсуждения и формального определения многих аспектов качества.
Инженеры должны понимать смысл, вкладываемый в концепцию качества, характеристики и значение качества в отношении разрабатываемого или сопровождаемого программного обеспечения.
Важной идеей является то, что программные требования определяют требуемые характеристики качества программного обеспечения, а также влияют на методы количественной оценки и сформулированные для оценки этих характеристик критерии приемки.
10.1.1 Культура и этика программной инженерии
(Software Engineering Culture and Ethics)
Этические аспекты могут играть значительную роль в обеспечении качества программного обеспечения, культуре и отношении инженеров к своей работе. Ожидается, что инженеры по программному обеспечению воспринимают
| SWEBOK дает ссылки на источники, описывающие здоровую культуру программной инженерии. |
10.1.2 Значение и стоимость качества
(Value and Costs of Quality)
Понятие качество, на самом деле, не столь очевидно и просто, как это может показаться на первый взгляд. Для любого инженерного продукта существует множество интерпретаций качества, в зависимости от конкретной точки зрения. Множество этих точек зрения необходимо обсудить и определить на этапе выработки требований к программному продукту. Характеристики качества могут требоваться в той или иной степени, могут отсутствовать или могут задавать определенные требования, все это может быть результатом определенного компромисса (что вполне перекликается с понятием приемлемого качества, как менее жесткой точки зрения на обеспечение качества, чем «достижение совершенства»).
Стоимость качества (cost of quality) может быть дифференцирована на стоимость предупреждения дефектов (prevention cost), стоимость оценки (appraisal cost), стоимость внутренних <сбоев>(internal failure cost), а также внешних сбоев (external failure cost).
Движущей силой программных проектов является желание создать программное обеспечение, обладающее определенной ценностью (значимое для решения определенных задач или достижения целей). Ценность программного обеспечения в может выражаться в форме стоимости, а может и нет. Заказчик, обычно, имеет свое представление о максимальных стоимостных вложениях, возврат которых ожидается в случае достижения основных целей создания программного обеспечения. Заказчик может, также, иметь определенные ожидания в отношении качества ПО. Иногда, заказчики не задумываются о вопросах качества и связанной с ними стоимостью. Является ли характеристики качества чисто декоративными (умозрительными) или, все же, это неотъемлемая часть программного обеспечения? Ответ, вероятно, находится где-то посередине, как почти всегда бывает в таких случаях, и является предметом обсуждения степени вовлечения заказчика в процесс принятия решений и полного понимания заказчиком стоимости и выгоды, связанной с достижением того или иного уровня качества. В идеальном случае, большинство такого рода решений должно приниматься процессе работы с требованиями (см. раздел 3), однако эти вопросы могут (и должны) подниматься на протяжении всего жизненного цикла программного обеспечения. Не существует каких-то <“стандартных”> правил того, как именно необходимо принимать такие решения. Однако, инженеры должны быть способны представить различные альтернативы (в достижении различного уровня качества) и их стоимость.
10.1.3 Модели и характеристики качества
(Models and Quality Characteristics)
В различных источниках (таксономиях и моделях) терминология характеристик качества программного обеспечения отличается. Каждая модель включает различное число уровней иерархии и общее число <”распознанных”> характеристик качества. Различные авторы создали разные модели качества со своим набором характеристик и атрибутов. Эти модели могут быть полезны для обсуждения, планирования, (адаптации) и оценки качества программных продуктов. ISO/IEC определяет три связанных модели качества программного обеспечения (ISO 9126-01 Software Engineering - Product Quality, Part 1: Quality Model) – внутреннее качество, внешнее качество и качество в процессе эксплуатации, а также набор соответствующих работ по оценке качества программного обеспечения (ISO14598-98 Software Product Evaluation).
10.1.3.1 Качество процессов программного обеспечения
(Software engineering process quality)
Управление качеством (software quality management) и качество процессов программной инженерии (software engineering process quality) имеют непосредственное отношение к качеству создаваемого программного продукта.
Модели и критерии оценки возможностей организаций, занимающихся разработкой программного обеспечения, прежде всего касаются рассмотрения организации проектных работ и аспектов управления. Соответственно, они рассматриваются в областях знаний “Управление программной инженерией” и “Процесс программной инженерии” (разделы 9 и 2 соответственно).
Конечно, невозможно полностью отделить качество процесса от качества продукта.
Качество процесса, обсуждаемое в области знаний “Процесс программной инженерии”, влияют на характеристики качества продукта, которые, в свою очередь, отражаются в восприятии качества продукта в процессе эксплуатации со стороны заказчика.
Существует два важнейших стандарта в области качества программного обеспечения. Приложения системы менеджмента качества ISO 9001-00 к программным проектам (и, в частности, сочетания такого взгляда с положениями стандарта жизненного цикла ISO 12207). Например, ISO 90003-04 “Software and Systems Engineering - Guidelines for the Application of ISO9001to Computer Software”.
Другой важный стандарт – CMMI, обсуждаемый в разделе 2, предоставляет рекомендации по совершенствованию процесса (здесь нельзя не упомянуть и ISO 15504 “Information Technology - Software Process Assessment” (Информационные технологии – Оценка процесса программной инженерии), известный как SPICE - Software Process Improvement and Capability dEtermination (Улучшение программного процесса и определение способностей), который также рассматривается в упомянутой области знаний). Непосредственно с управлением качеством связаны процессные области (области компетенции) CMMI: обеспечение качества процесса и продукта (process and product quality assurance, категория процессов CMMI “Support”), проверка (verification, категория “Engineering”) и аттестация (validation, категория “Engineering”). При этом, CMMI классифицирует обзор (review) и аудит (audit) в качестве методов верификации, но не как самостоятельные процессы, в отличие, например, от стандарта 12207.
Дебаты в отношении того, какой именно стандарт стоит использовать инженерам для обеспечения качества программного обеспечения – CMMI или ISO 9001, продолжаются с самого создания этих стандартов. Сегодня можно сказать о том, что данные стандарты все же рассматривают как взаимодополняющие и, что сертификация по ISO 9001 помогает в достижении старших уровней зрелости по CMMI.
Дата: 2019-02-19, просмотров: 203.