Управление качеством ПО в Agile

Ссылки сюда (1) →

Всеволод Коньков

ведущий разработчик компании CUSTIS, сертифицированный Scrum-мастер

Статья опубликована в журнале Intelligent Enterprise, № 5 (май) 2011, стр 42-45

Управление качеством продукции и услуг — одна из важнейших составляющих любого бизнеса, в том числе и информационных технологий, где вопрос качества стоит особенно остро. С чем это связано?

Дело в том, что порог входа на рынок разработки ПО относительно низок. Иными словами, чтобы стать поставщиком ИТ-решений, не нужны огромные инвестиции. По этой причине на рынке нет недостатка в предложениях по разработке ИТ‑систем для бизнеса. Однако часто предлагаемое ПО имеет неприемлемое качество, и это заставляет заказчиков очень внимательно подходить к выбору исполнителя.

В данной статье рассматривается достижение высокого качества ПО с помощью гибких, или Agile-методологий, которые в последнее десятилетие становятся все более популярными и среди небольших производителей, и у крупных вендоров (таких как Nokia и Microsoft). Agile позволяет добиться высокого качества ПО при относительно низких затратах, так как в гибких методологиях используются те же практики, что и в бережливом производстве (lean production).

Качественные процессы — залог качественного ПО

Что такое качество ПО? Вопрос совсем не прост. Дело в том, что существует множество различных желаемых показателей качества, значение которых зависит от конкретного проекта. Однако специалисты по программной инженерии сходятся в том, что качественное ПО должно соответствовать следующим показателям:

• функциональная надежность (dependability);
• ошибкоустойчивость (robustness);
• функциональная выполнимость (performance);
• удобство использования (usability);
• сопровождаемость (supportability);
• повторная используемость (reusability);
• интероперабельность (interoperability).

Перечисленные свойства характеризуют ПО как изделие. С точки зрения теории управления качеством нельзя произвести качественное изделие, не выстроив качественные процессы по его созданию.

К показателям качества процессов относят:

• производительность (productivity);
• своевременность (timeliness);
• прозрачность (visibility).

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

Показатели качества ПО как продукта

Функциональная надежность. Это свойство означает, что ПО ведет себя так, как от него ожидают пользователи, и обеспечивает их уверенность в правильности его работы.

Есть более строгий показатель того, насколько ИТ‑система удовлетворяет пользовательским ожиданиям, — корректность (correctness). Он подразумевает соответствие между ПО и его формальными функциональными спецификациями. Однако здесь следует иметь в виду, что ИТ‑система — очень сложный продукт, и ее функциональные требования редко можно определить с достаточной точностью. Кроме того, сами спецификации могут содержать ошибки и быть нестабильными. Потому показатель корректности не столь необходим, так как пользователю нужно надежное, правильно работающее ПО, а не формальное соответствие ИТ‑системы требованиям.

Ошибкоустойчивость. Под ошибкоустойчи­востью понимается: вероятность того, что ПО подведет, испортится или безвозвратно разрушится, ничтожно мала. Это свойство очень важно, ведь в совокупности с функциональной надежностью оно определяет, насколько ИТ‑система соответствует ожиданиям. Нужно понимать, что удовлетворение этому критерию бессмысленно для функционально ненадежного ПО, поскольку ошибкоустойчивая система, которая делает не то, что нужно, вряд ли будет эксплуатироваться.

Функциональная выполнимость. Под функциональной выполнимостью подразумевается производительность ПО, то есть способность ИТ‑системы выполнять заданные функции за приемлемое для эксплуатации время.

Удобство использования. Как правило, это свойство подразумевает дружественность пользовательского интерфейса, разработке которого в последнее время стало уделяться достаточно много внимания.

Сопровождаемость. Этот показатель многогранен. В первую очередь под ним понимается ремонтопригодность (repairability), то есть возможность простого исправления ошибок или недочетов в эксплуатируемом ПО. Кроме того, он означает, что существующая ИТ‑система может быть эффективно подстроена под новые требования. Сопровождаемость также подразумевает масштабируемость (scalability) и способность к развитию (evolvability): это значит, что ПО может быть с легкостью развито в ответ на увеличение требований к его функциональным возможностям.

Повторная используемость. Эта свойство означает, что различные составляющие ИТ‑системы могут быть использованы для конструирования другого ПО. Оно позволяет создавать более надежное ПО быстрее и с меньшими затратами.

Интероперабельность. Под данной характеристикой понимается способность эксплуатируемой ИТ‑системы легко взаимодействовать с другим ПО для выполнения требований, стоящих перед ИТ-инфраструктурой в целом. Показатель очень важный, потому что ИТ-инфраструктура предприятия редко состоит из одной изолированной программы. В большинстве случаев эксплуатируется целый набор программ, и появляется необходимость интегрировать эти системы между собой. Показатели качества процессов разработки ПО

Показатели качества процессов разработки ПО

Производительность. Это свойство показывает, насколько эффективно поставщик может разработать новую функциональность. Производительность может быть измерена во времени при ограниченном ресурсе, задействованном в разработке.

Своевременность. Этот показатель иллюстрирует, могут ли запрашиваемые функциональные возможности быть реализованы в требуемые сроки. Процесс разработки, не позволяющий достичь своевременного результата даже при существенном увеличении ресурсов, считается неприемлемым.

Прозрачность. Прозрачность процессов разработки подразумевает наличие явных стадий и операций, которые видны заинтересованным лицам. Заказчику важно видеть, как разрабатывается ИТ‑система: это позволит ему понимать и контролировать возможные риски.

Стандарты и методологии обеспечения качества

Поскольку качество ИТ‑системы напрямую зависит от качества процессов ее разработки, управление качеством ПО означает прежде всего создание качественных процессов.

Предполагается, что качественный процесс разработки должен включать определенные организационные процедуры и действия. Поэтому поставщика ПО традиционно оценивают по набору производимых формальных процедур, которые считаются необходимыми для обеспечения высокого качества ИТ‑системы. Например, такой крупный заказчик информационных систем, как министерство обороны США, при выборе поставщика ПО аттестовал кандидатов на соответствие так называемой модели технологической зрелости (Capability Maturity Model — CMM). Не вдаваясь в подробности, CMM делит организации разработчиков ИТ на пять уровней зрелости в зависимости от формального наличия организационных процедур. CMM — это стандарт на процессразработки качественного ПО. К таким стандартам относятся также ISO 9000 и ITIL (IT Infrastructure Library). Общее в них то, что они требуют наличия календарных планов, четко регламентированных процедур по выпуску версий и подробно оформленной документации как на процессы, так и на продукцию.

Необходимо отличать стандарты на процессы от методологий по построению качественных процессов. К таким методикам относятся RUP (Rational Unified Process), MSF (Microsoft Solution Framework) и подмножество Agile. Причем ни один из этих подходов не конфликтует с существующими стандартами.

Многие практики обеспечения качества, используемые в разных методологиях, совпадают (например, составление тестовых примеров и тестирование по ним). Однако каждая методология по‑разному отвечает на вопросы о том, кто и когда должен обеспечивать качество и какие практики для этого лучше всего подходят. Пришло время поговорить о том, каким практикам отдается предпочтение в Agile и как это позволяет обеспечить высокое качество ПО, не делая его дорогостоящим.

Достижение качества в Agile

Agile — это методология разработки ПО, представляющая альтернативу «тяжеловесным» подходам к выстраиванию качественных процессов. В Agile-манифесте, сформулированном основателями данного подхода в 2001 г., говорится:

«Для нас важнее:

• люди и их взаимодействие, чем процессы и средства;
• работающее ПО, чем исчерпывающая документация;
• сотрудничество с заказчиком, чем обсуждение условий контракта;
• реагирование на изменения, чем следование плану.

То есть мы не ставим под сомнение важность пунктов справа, но в то же время для нас гораздо важнее записанное слева».

Таким образом, Agile не отрицает важности качественных процессов и инструментов для их обеспечения, различного рода документации, планирования работ и следования плану, просто для успешного проекта это не считается главным. На первый план выходят люди, участвующие в процессе разработки ПО, коммуникации между ними и сам результат — работающая ИТ‑система, способная функционировать в условиях меняющихся требований. То есть Agile — это гуманистический подход к разработке, учитывающий человеческий и социальный факторы и предполагающий командную работу, опору на коллективный опыт и вовлеченность всех сотрудников в процесс разработки.

Основные практики Agile и их вклад в достижение показателей качества показаны в таблице.

Достижение показателей качества с помощью практик Agile

Следует отметить, что ни одна практика, внедренная изолированно от всех остальных, не даст заметного эффекта в обеспечении качества. Именно система практик дает кумулятивный эффект и позволяет добиться высокого качества ПО.

Далее подробно остановимся на некоторых практиках, которые будут рассмотрены на опыте проектов, в которых участвовал автор статьи.

Частые демонстрации системы заказчику. В Scrum — самой популярной из Agile-методологий в настоящее время — команды ведут разработку короткими итерациями (так называемыми спринтами) продолжительностью 2—4 недели. Каждый спринт завершается демонстрацией проделанной работы, в процессе которой представители заказчика высказывают свои замечания и пожелания. Эта практика дает возможность получить быструю обратную связь от пользователей, что, в свою очередь, благоприятно сказывается на обеспечении высокой функциональной надежности ПО и удобстве его использования. К тому же это помогает справиться с проблемой отсутствия ясных требований, когда заказчик «сам не знает, чего хочет».

Частые выпуски версий. Если замечания и пожелания, высказанные заказчиком во время демонстрации, легко реализовать, это делается до выпуска версии, в противном случае они откладываются на следующие итерации. После внесения этих правок инженеры-аналитики (так у нас называются специалисты, которые занимаются анализом требований к ПО и тестированием) проводят регрессионное тестирование по комплекту разработанных тестовых примеров. Если тестирование проходит успешно, производится выпуск новой версии и ее разворачивание на серверах заказчика. Затем заинтересованные лица на стороне заказчика могут эксплуатировать новую версию программы, чтобы понять, действительно ли ее возможности соответствуют ожиданиям. Представитель заказчика может высказать свои замечания и пожелания через Bugzilla (систему отслеживания дефектов и ведения задач) и MediaWiki (базу знаний, к которой имеют доступ как разработчики, так и представители заказчика), после чего они попадают в список задач проекта.

Благодаря раннему получению работающего функционала и его постепенному развитию заказчику не нужно мыслить абстрактными категориями: он всегда имеет перед глазами работающее ПО и может внятно объяснить разработчикам, как именно должна работать программа.

Разработка через приемочное тестирование. Инженеры-аналитики собирают требования заказчика и разрабатывают тестовые примеры для приемочного тестирования, покрывающие новый, еще не разработанный функционал. Мы используем большое количество ручных приемочных тестов на пользовательский интерфейс. Небольшая часть приемочных тестов, интегрально проверяющих логику, автоматизируется с помощью тестовых сценариев, запускаемых через инструмент модульного тестирования NUnit.

Описания разработанных функциональных приемочных тестов выкладываются в MediaWiki. Иногда представители заказчика смотрят разработанный тест еще до начала реализации, чтобы оценить, правильно ли инженеры-аналитики поняли требования к новому функционалу.

Получение приемочных тестов перед реализацией функционала позволяет программистам лучше понять, что от них требуется. Это повышает функциональную надежность ПО и делает его разработку более эффективной.

Кроме того, приемочное тестирование позволяет гарантировать качество ПО при внесении существенных изменений, затрагивающих архитектуру программы.

Разработка через модульное тестирование. Решение о том, какой будет архитектура ИТ‑системы, принимается командой на совместной дизайн‑сессии. В ходе этого обсуждения выявляются составляющие системы — модули — и требования к их поведению.

Опираясь на эти требования, программисты сначала пишут автоматические модульные тесты и только затем, разрабатывая функционал, добиваются их выполнения.

Благодаря модульному тестированию существенно снижается риск появления ошибок, а разрабатываемое ПО становится более устойчивым и качественным. Кроме того, система приобретает гибкую слабосвязанную архитектуру с хорошим дизайном, поскольку для использования модульных тестов программа должна быть разбита на слабосвязанные куски кода с небольшим набором функциональности. А такой код готов к любым изменениям и прост в сопровождении.

У модульного тестирования есть еще одно достоинство: понятные и лаконичные модульные тесты могут с успехом заменить проектную докумен­тацию.

Ретроспектива спринта. Эта практика не указана в таблице, поскольку она является универсальным инструментом, позволяющим улучшать качество всех процессов разработки.

На ретроспективе, которая проводится после каждого спринта, собирается вся команда для обсуждения возникающих проблем и поиска путей их решения. Например, могут быть внесены предложения об исключении неэффективных практик и внедрении новых.

Заключение

Гибкие методологии разработки позволяют обеспечить высокое качество ПО без лишних затрат. В Agile заказчик оплачивает только те процедуры, которые ему действительно нужны в конкретном проекте. К примеру, ведение проектной документации оплачивается из бюджета заказчика, хотя во многих проектах она на самом деле не нужна.

При этом благодаря Agile-подходу код программы буквально «пропитан» качеством, поскольку разработка через тестирование (test-drivendevelopment) заставляет разработчиков еще на этапе формулирования функциональных требований думать о тестах. А с помощью непрерывной интеграции разрабатываемая программа постоянно проходит полную автоматическую верификацию.

Agile-практики делают ИТ‑систему гибкой и легко сопровождаемой. Это во многом связано с использованием модульного тестирования, которое буквально «вынуждает» разработчиков создавать гибкую слабосвязанную архитектуру программы.

Слаженная работа команды, включающая совместное планирование задач, ежедневные совещания, совместные дизайн‑сессии и рецензирование кода, существенно повышает качество ИТ‑системы. А практики тесного взаимодействия с заказчиком позволяют быстро выявлять недостатки в разрабатываемом ПО и так же быстро устранять их.

Итак, секрет обеспечения качества в Agile прост — качеством занимаются все и всегда.

Ссылки

---

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Управление качеством ПО в Agile»