Введение в программную инженерию и управление жизненным циклом ПО

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

Copyright © Сергей Орлик, 2004-2005.

mailto:[email protected]

http://sorlik.blogspot.com

По мнению автора, такая идентификация возможна во многих случаях (если даже не в

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

Это – задача управления рисками, которое вполне можно было бы вынести в качестве

самостоятельной области знаний 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, пользовательские требования, скорее, не