День 2230. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 43. Решая вопрос о качестве ПО, вы выбираете: платить немало сейчас или позже, но ещё больше
Если вы собрали требования, а на следующий день клиент позвонил и попросил кое-что изменить, это легко - достаточно обновить требование. Но если клиент позвонил через полгода, когда уже частично реализован дизайн и написан код – это гораздо дороже. У каждого изменения есть цена. Даже обсуждение возможности добавления функциональности или исправления ошибки, а затем решение не делать этого требуют времени. Стоимость исправления дефекта зависит от того, когда он был допущен в продукте и когда кто-то его исправил. Она тем больше, чем позднее дефект обнаруживается.
Порядок увеличения затрат во многом зависит от того, какой объём работы был выполнен для реализации ошибочного требования и как много теперь необходимо переделать. Исправить быстро найденную ошибку в коде почти ничего не стоит. Но если клиент звонит, чтобы сообщить об ошибке уже после релиза ПО, то её исправление обойдется намного дороже. Есть и другой важный аспект: негативное влияние на пользователей. Чем позднее обнаружится проблема, тем более широкий круг заинтересованных сторон она затронет.
Ранние действия по улучшению качества 1. Предотвращайте дефекты, а не исправляйте их Деятельность по обеспечению качества в первую очередь направлена на предотвращение дефектов. Усовершенствованные процессы, лучшие технические приёмы, более опытные специалисты и немного больше времени на тщательное выполнение работы помогают предотвратить ошибки и избежать затрат на их исправление.
2. Выполняйте контроль качества раньше На каждом этапе работы над ПО совершается микропоследовательность действий: определение требований, разработка дизайна и программирование. Устранение ошибок в требованиях максимально экономит время в будущем, поэтому используйте все имеющиеся инструменты для поиска ошибок в требованиях и проектах до того, как они превратятся в ошибочный код.
Смещение тестирования с его традиционного места в конце разработки на более ранние этапы даёт особенно сильный эффект. В числе возможных стратегий можно назвать разработку через тестирование, создание приёмочных тестов для конкретизации деталей требований и одновременное написание функциональных требований и соответствующих им тестов.
Разрабатывая тесты вскоре после определения требований, можно сразу находить ошибки как в требованиях, так и в тестах. Написание тестов бизнес-аналитиком в сотрудничестве с тестировщиком даёт положительный эффект, т.к. участвуют люди, смотрящие на одно и то же явление с разных точек зрения. Написание тестов в начале цикла разработки не увеличивает время разработки проекта, а просто перераспределяет его, перенося тестирование в точку, где оно обеспечивает наибольшее влияние на качество. Эти концептуальные тесты могут быть преобразованы в подробные тестовые сценарии и процедуры по мере разработки.
Инструменты статического и динамического анализа кода, помогут выявить многие проблемы гораздо быстрее, чем при просмотре вручную. А рецензенты-люди могут выявлять логические ошибки и упущения в коде, которые не обнаруживаются автоматическими инструментами.
3. Отслеживайте дефекты, чтобы понять их Записывайте информацию о своих ошибках вместо того, чтобы просто исправлять их. Определяйте причины происхождения каждого дефекта, чтобы понять, какие типы ошибок возникают чаще всего. Вы не поняли, чего хочет клиент? Сделали неправильное предположение о системных компонентах или интерфейсах? Ошиблись при программировании? О запросе клиента узнали не все, кто должен был об нём знать?
Обратите внимание на действия в жизненном цикле, при выполнении которых возник каждый дефект, и на то, как он был обнаружен. Так можно рассчитать, сколько дефектов переходят с этапа, на котором они появились, на более поздние этапы разработки, увеличивая стоимость их исправления. Это покажет, какие практики обнаружения дефектов наиболее эффективны и где ещё можно улучшить контроль.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
День 2230. #УрокиРазработки Уроки 50 Лет Разработки ПО
Урок 43. Решая вопрос о качестве ПО, вы выбираете: платить немало сейчас или позже, но ещё больше
Если вы собрали требования, а на следующий день клиент позвонил и попросил кое-что изменить, это легко - достаточно обновить требование. Но если клиент позвонил через полгода, когда уже частично реализован дизайн и написан код – это гораздо дороже. У каждого изменения есть цена. Даже обсуждение возможности добавления функциональности или исправления ошибки, а затем решение не делать этого требуют времени. Стоимость исправления дефекта зависит от того, когда он был допущен в продукте и когда кто-то его исправил. Она тем больше, чем позднее дефект обнаруживается.
Порядок увеличения затрат во многом зависит от того, какой объём работы был выполнен для реализации ошибочного требования и как много теперь необходимо переделать. Исправить быстро найденную ошибку в коде почти ничего не стоит. Но если клиент звонит, чтобы сообщить об ошибке уже после релиза ПО, то её исправление обойдется намного дороже. Есть и другой важный аспект: негативное влияние на пользователей. Чем позднее обнаружится проблема, тем более широкий круг заинтересованных сторон она затронет.
Ранние действия по улучшению качества 1. Предотвращайте дефекты, а не исправляйте их Деятельность по обеспечению качества в первую очередь направлена на предотвращение дефектов. Усовершенствованные процессы, лучшие технические приёмы, более опытные специалисты и немного больше времени на тщательное выполнение работы помогают предотвратить ошибки и избежать затрат на их исправление.
2. Выполняйте контроль качества раньше На каждом этапе работы над ПО совершается микропоследовательность действий: определение требований, разработка дизайна и программирование. Устранение ошибок в требованиях максимально экономит время в будущем, поэтому используйте все имеющиеся инструменты для поиска ошибок в требованиях и проектах до того, как они превратятся в ошибочный код.
Смещение тестирования с его традиционного места в конце разработки на более ранние этапы даёт особенно сильный эффект. В числе возможных стратегий можно назвать разработку через тестирование, создание приёмочных тестов для конкретизации деталей требований и одновременное написание функциональных требований и соответствующих им тестов.
Разрабатывая тесты вскоре после определения требований, можно сразу находить ошибки как в требованиях, так и в тестах. Написание тестов бизнес-аналитиком в сотрудничестве с тестировщиком даёт положительный эффект, т.к. участвуют люди, смотрящие на одно и то же явление с разных точек зрения. Написание тестов в начале цикла разработки не увеличивает время разработки проекта, а просто перераспределяет его, перенося тестирование в точку, где оно обеспечивает наибольшее влияние на качество. Эти концептуальные тесты могут быть преобразованы в подробные тестовые сценарии и процедуры по мере разработки.
Инструменты статического и динамического анализа кода, помогут выявить многие проблемы гораздо быстрее, чем при просмотре вручную. А рецензенты-люди могут выявлять логические ошибки и упущения в коде, которые не обнаруживаются автоматическими инструментами.
3. Отслеживайте дефекты, чтобы понять их Записывайте информацию о своих ошибках вместо того, чтобы просто исправлять их. Определяйте причины происхождения каждого дефекта, чтобы понять, какие типы ошибок возникают чаще всего. Вы не поняли, чего хочет клиент? Сделали неправильное предположение о системных компонентах или интерфейсах? Ошиблись при программировании? О запросе клиента узнали не все, кто должен был об нём знать?
Обратите внимание на действия в жизненном цикле, при выполнении которых возник каждый дефект, и на то, как он был обнаружен. Так можно рассчитать, сколько дефектов переходят с этапа, на котором они появились, на более поздние этапы разработки, увеличивая стоимость их исправления. Это покажет, какие практики обнаружения дефектов наиболее эффективны и где ещё можно улучшить контроль.
Источник: Карл Вигерс “Жемчужины Разработки”. СПб.: Питер, 2024. Глава 6.
