Читаем книгу «Abenteuer Software Qualität»

3788Abenteuer Softwarequalität

Kurt Schneider

ISBN: 978-3-89864-784-7

dpunkt.verlag

На немецком языке

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

Используется определение качества по ISO 8402 (Quality Management and Quality Assurance) (здесь мой вольный перевод на русский):

Качество продукта — это степень соответствия этого продукта предъявляемых к нему явных и неявных требований.

С явными требованиями всё ясно. Они заданы, описаны, их можно проверить. Здесь можно говорить о тестировании (как запуске готовой программы с целью поиска дефектов). Можно говорить о ревью или инспекции (как анализу объекта без его выполнения). Что автор и делает. Соответствующие главы вполне годятся как начальное введение в предмет.

С неявными требованиями сложнее. Можеть быть неверно называть из требованиями. Скорее это ожидания, хотя это звучит сильно неформально. Как бы там ни было, у клиента в любом случае есть представления о том, что программа будет работать довольно быстро, будет удобной в оборащении, не будет содержать дыр безопасности, не будет «падать» и т.д. И даже если эти параметры не зафиксированы ни в каких спецификациях, невозможно отрицать наличие таких требований в определенном объеме. Видимо взаимные соглашения с клиентом о конкретном объёме и есть центральный вопрос темы качества ПО.

Мало качества приводит к недовольству клиента. Много качества — к чрезмерным затратам разработчика, не покрываемым бюджетом проекта. Абсолютного качества не бывает. Качество — это контрактная величина. Об этом автор, увы, не говорит.

Дав вполне полезное определение качества, автор углубляется в анализ именно нефункциональных требований (на примере «эффективности»), и эта однобокость удивляет.

Целая глава посвящена теме накопления опыта и обмена опытом между проектами, применительно к работе «умолномоченного по качеству». Глава выглядит странной, поскольку обмен опытом — это общая тема, так же точно подходящая к работе программистов или менеджеров проектов.

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

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

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

Формальные подходы к обеспечению качества — неплохо для полноты картины (прежде всего, предполагая что это часть университетского курса). Но уж очень далеко от реальности.

Глава о констуктивных методов обеспечения качества (в противовес аналитическим — тестированию и ревью), напротив, очень нужна но получилась неубедительной. Звучит она простым перечислением разнообразных best practices.

В конце автор даёт введение в агильные методы разработки — ключевые слова XP, Scrum, Lean, Kanban. Глава неплоха как исторический анализ агильного движения. Но обещание показать, как именно агильные методы обеспечивают качество продукта остаётся невыполненным. Перечисление некоторых агильных практик как ответ этот вопрос звучит неубедительно. Не хватает также описания — для сравнения — классического подхода (не-агильного?) и как качество обеспечивается там. Если агильность обсуждается в главе 10, то вся предыдущая часть книги была в предположении не-агильной разработки? Какой же?

Путаница относительно агильных методов и их адекватного применения — это большая тема, но это другая тема.

Итого: книгу не рекомендую.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s