10-software_engineering_quality (Основы программной инженерии (по SWEBOOK)), страница 3

Результатывыполнения этих задач представляются в виде отчетов для менеджеров перед тем, как будутпредприняты соответствующие корректирующие действия. Управление SQM-процессом ведетсяисходя из уверенности, что данные отчетов точны.Как описано в данной области знаний, процессы SQM тесно связаны между собой. Они могутперекрываться, а иногда даже и совмещаться. Они кажутся реактивными по своей природе, всилу того, что они рассматривают процессы в контексте полученной практики и ужепроизведенные продукты. Однако, они играют главную роль на стадии планирования, являясьпроактивными как процессы и процедуры, необходимые для достижения характеристик и уровнякачества, востребованных заинтересованными лицами <проекта> программного обеспечения.Управление рисками также может играть значительную роль для выпуска качественногопрограммного обеспечения.

Включение “регулярного” (как постоянно действующего, а непериодического; в оригинале – disciplined) анализа рисков и <соответствующих> техникуправления <рисками> в процессы жизненного цикла программного обеспечения может увеличитьпотенциал для производства качественного продукта. Более подробную информацию поуправлению рисками можно найти в области знаний “Управление программной инженерией”.2.1 Подтверждение качества программного обеспечения (Software Quality Assurance, SQA)Процессы SQA обеспечивают подтверждение того, что программные продукты и процессыжизненного цикла проекта соответствуют заданным требованиям.

Такое подтверждениепроводится на основе планирования (planning), постановки <работ> (enacting) и исполнения(performing) набора действий, направленных на то, чтобы качество стало неотъемлемой частьюпрограммного обеспечения (см. выше определения качества). Такой взгляд подразумевает ясное иточное формулирование проблемы, а также то, что определены и четко выражены (полны иоднозначно интерпретируемы) требования к соответствующему <программному> решению. SQAдобивается обеспечения качества в процессе разработки и сопровождения за счет выполненияразличных действий на всех этапах <жизненного цикла>, что позволяет идентифицироватьпроблемы еще на ранних стадиях, которые практически неизбежны в любой сложнойдеятельности.Такая идентификация возможна во многих случаях (если даже не в большинстве ситуаций), когдапроблема еще является риском и возможно ее предотвращение.

Это – задача управлениярисками, которое вполне можно было бы вынести в качестве самостоятельной области знанийCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Качество программного обеспечения.SWEBOK, в силу уже достаточно большого совокупного опыта не только индустрии ИТ илидисциплины управления проектами.

Так или иначе, можно сказать, что уже было подчеркнуто приобсуждении SQM, управление рисками (Risk Management) является серьезным дополнительныминструментом для обеспечения качества программного обеспечения. Однако, ограничиватьсяупоминанием управления рисками только в контексте SQM было бы неправильно, так каксегодняшнее понимание Risk Management включает в себя не только вопросы предупреждениярисков, но и управление процессом разрешения проблем.SQA, как это сформулировано SWEBOK, концентрируется на процессах.

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

Это, в обязательном порядке, должно быть отражено всоответствующих планах управления <проектом>, разработки и сопровождения. Подробностиможно найти в стандарте IEEE 730-02 “IEEE Standard for Software Quality Assurance Plans”.Конкретные работы и задачи по обеспечению качества структурируются с детализациейтребований по их стоимости и ассоциированным ресурсам, целям с точки зрения управления исоответствующим расписанием в контексте целей, заданных планами управления, разработки исопровождения. SQA-план должен согласовываться с планом конфигурационного управления (см.область знаний “Software Configuration Management”). План SQA идентифицирует документы,стандарты, практики и соглашения, применяемые при контроле проекта, а также то, как этиаспекты будут проверяться и отслеживаться для обеспечения достаточности и соответствиязаданному плану.

Также, SQA-план идентифицирует метрики, статистические техники, процедурыформирования сообщений о проблемах и проведения корректирующих действий, такие средства(в оригинале SWEBOK используется термин resources), как инструменты, техники и методологии,вопросы безопасности физических носителей (это, скорее, вопрос базовой инфраструктурыпроектов, а не SQA-плана), тренинги, а также формирование отчетности и документации,относящиеся к вопросам SQA. Кроме того, SQA-план касается и вопросов работ по обеспечениюкачества, относящихся к другим типам деятельности, описанным в <различных> планах посозданию программного обеспечения, к которым также относятся поставка, установка,обслуживание (поддержка и сопровождение) заказных и/или тиражируемых/готовых программныхрешений (commercial off-the-shelf, COTS), необходимых для данного проекта программногообеспечения.

Наконец, SQA-план может содержать необходимые для обеспечения качествакритерии приемки программного обеспечения и действия по формированию отчетности иуправлению <и контролю над> работами.2.2 Проверка (верификация) и аттестация (Verification and Validation, V&V)С целью краткости <изложения> (что, не мешало их детализировать достаточным образом, в видесоответствующих "подтем" в рамках формата SWEBOK, так как, будучи тесно связанными ивзаимодополняющими, проверка и аттестация все же обладают и самостоятельнымсодержанием), проверка (верификация) и аттестация – Validation and Verification (V&V) –рассмотрены в SWEBOK в рамках единой темы.

В свою очередь, они являются самостоятельнымитемами, например, в стандарте жизненного цикла программного обеспечения 12207. СтандартIEEE 1059-93 “IEEE Guide for Software Verification and Validation Plans” дает такое определениеV&V*: “Проверка и аттестация программного обеспечения – упорядоченный подход в оценкепрограммных продуктов, применяемый на протяжении всего жизненного цикла. Усилия,прилагаемые в рамках работ по проверке и аттестации, направлены на обеспечение качества какнеотъемлемой характеристики программного обеспечения и удовлетворение пользовательскихтребований” (здесь и далее, как и при обсуждении SQA, пользовательские требования, скорее, неuser requirements в понимании управления требованиями, а потребности пользователей, радиудовлетворения которых создается программное обеспечение).Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.

Качество программного обеспечения.* здесь и далее в переводе намеренно используется обозначение V&V, как общепринятое виндустрии программного обеспеченияV&V напрямую адресуется вопросам качества программного обеспечения и используетсоответствующие техники тестирования для обнаружения тех или иных дефектов. V&V можетприменяться для промежуточных продуктов, однако, в том объеме, который соответствуетпромежуточным “шагам” <соответствующих> процессов жизненного цикла.Процесс V&V определяет в какой степени продукт (результат) тех или иных работ по разработке исопровождению соответствует требованиям, сформулированным в рамках этих работ, а конечныйпродукт удовлетворяет заданным целям и пользовательским требованиям (корректнее было быговорить не только и, может быть, не столько о “требованиях”, то есть потребностях, сколько обожиданиях).

Верификация – попытка обеспечить правильную разработку продукта (продуктпостроен правильным образом; обычно, для промежуточных, иногда, для конечного продукта), втом значении, что получаемый в рамках соответствующей деятельности продукт соответствуетспецификациям, заданным в процессе предыдущей деятельности. Аттестация – попыткаобеспечить создание правильного продукта (построен правильный продукт; обычно, в контекстеконечного продукта), с точки зрения достижения поставленной цели. Оба процесса – верификацияи аттестация – начинаются на ранних стадиях разработки и сопровождения. Они обеспечиваютисследованию (экспертизу) ключевых возможностей продукта как в контексте непосредственнопредшествующих результатов (промежуточных продуктов), так и с точки зрения удовлетворениясоответствующих спецификаций.Целью планирования V&V является обеспечение процессов верификации и аттестациинеобходимыми ресурсами, четкое назначение ролей и обязанностей.

Получаемый план V&Vдокументирует и <детально> описывает различные ресурсы, роли и действия, а такжеиспользуемые техники и инструменты. Понимание различных целей каждого действия в рамкахV&V может помочь в точном планировании техник и ресурсов (включая, финансовые),необходимых для достижения заданных целей. Стандарты IEEE 1012-98 “Software Verification andValidation” и 1059-93 “IEEE Guide for Software Verification and Validation Plans” (Appendix A)определяют типичное содержание плана проверки и аттестации.План также касается аспектов управления, коммуникаций (взаимодействия), политик и процедур вотношении действий по верификации и аттестации и их взаимодействия.

Кроме того, в нем могутбыть отражены вопросы формирования отчетности по дефектам и документирования требований(конечно, с точки зрения выполнения задач по проверке и аттестации продуктов).2.3 Оценка (обзор) и аудит (Review and Audits)В целях краткости изложения, оценка (review) и аудит объединены в SWEBOK в одну тему (вданном случае, такое объединение выглядит более обоснованным, чем в случае V&V, где частьюпроцесса аттестации могут быть, например, приемо-сдаточные испытания, навернякаотсутствующие при верификации; оценка же и аудит, на практике, часто отличаются лишьстепенью детализации, акцентам в отношении исследуемых аспектов, лицом/органом,выполняющим соответствующие работы, а также степенью формализации процесса).