Что обычно подразумевается под термином «качество программного обеспечения»? Одним из примеров модели качества программного обеспечения является предложенная Hewlett-Packard идеология FURPS (Functionality, Usability, Reliability, Performance, Supportability, т.е. функциональность, юзабилити, надежность, производительность, поддерживаемость). Хотя модель FURPS применима ко всем видам программного обеспечения, ее можно дополнить атрибутами качества, относящимися к веб-приложениям, а именно: находимость, доступность и правовое соответствие.
Как замечает Питер Лиггисмеер (Peter Liggesmeyer), обеспечение качества компьютерных программ является многогранной темой: «Каждая компания, разрабатывающая программное обеспечение, будет пытаться достигнуть максимально возможного качества. ПО многогранно, то есть, понятие «качество программного обеспечения» включает в себя многие стороны. Не все из них одинаково важны для пользователей и производителей программного обеспечения». Таким образом, взгляд пользователя на качество программы, отличается от взгляда производителя. Можно согласиться с точкой зрения Нила Бевана (Nigel Bevan), определяющего наличие разницы между внешним и внутренним качеством программ.
Клиенты или конечные пользователи приложения, сосредотачивают свое внимание на тех аспектах достоинства программы, которые имеют для них существенное значение. Согласно мнению Себастьяна Бергмана (Sebastian Bergmann) эти аспекты являются показателями внешнего качества приложений:
• Функциональность означает, что приложение фактически может выполнять предлагаемые задачи.
• Юзабилити означает, что пользователь может работать эффективно, удобно и при этом еще получать удовлетворение от работы приложения. Доступность является частью юзабилити.
• Ре-активность (reactivity) подразумевает короткое время отклика программы. Это особенно важно, если производитель желает, чтобы пользователь был удовлетворен работой программы.
• Безопасность приложения является одним из наиболее важных факторов для востребованности программы. Она подразумевает высокую степень защищенности критически-важных данных, как пользовательских, так и кода самого приложения.
• Доступность и надежность особенно важны для веб-приложений с большим количеством пользователей. Приложения должны быть способны выдерживать большие нагрузки и обязаны работать даже в нестандартных ситуациях.
Все аспекты внешнего качества могут быть проверены путем тестирования приложения в целом, с использованием, так называемых, «непрерывных» (end-to-end) тестов. Применение тестирования позволяет в автоматическом режиме проверять, что программный продукт выполняет все свои функциональные требования.
Для повышения реактивности приложения, мы должны измерять время отклика. Необходимо использовать специальные инструменты и техники, чтобы оптимизация программы давала максимальный выигрыш производительности при минимальном объеме работы и сохранении низкой стоимости. Еще на этапе планирования мощностей, разработчики и администраторы должны определить потенциально опасные места в приложении, если вдруг изменится программное окружение или увеличится трафик. Необходимо изначально обладать этими данными, чтобы гарантировать качество приложения с учетом его доступности и надежности в долгосрочной перспективе.
Внутреннее качество определяется нуждами разработчиков и администраторов приложения. Разработчики в первую очередь фокусируются на читаемости кода, который легко понять, адаптировать и расширять. Если они не сделают этого, реализация последующих требований клиента становится более сложной и, следовательно, более дорогой с течением времени. Это повышает риск того, что даже небольшие изменения в программном обеспечении могут привести к неожиданным побочным эффектам.
Внутреннее качество программы практически незаметно для клиентов и конечных пользователей. Конечные пользователи ожидают, что программа будет удовлетворять всем или, по крайней мере, большинству их функциональных ожиданий, а также быть простой в использовании. Фактически, если при использовании продукт работает достаточно быстро, большинство клиентов будут удовлетворены.
Однако недостатки внутреннего качества программы проявляются во временной перспективе. Требуется больше времени для исправления даже элементарных ошибок. Любые изменения или дополнения к программе требует все больших усилий. В итоге, разработчик рано или поздно начинает просить увеличить бюджет на чистку и рефакторинг кода. А так как клиенты или начальство обычно не понимают в чем польза рефакторинга, эти запросы чаще всего остаются без внимания.
Автоматизированные тесты индивидуальных программных модулей (модульные тесты) позволяют немедленно отслеживать появление новых ошибок, которые могут возникнуть при изменении кода. Без автоматизированных тестов рефакторинг кода был бы очень трудной работой.
Основная цель обеспечения качества, а точнее, управления качеством программного приложения, – сделать затраты и выгоды прозрачными для всех сторон, участвующих в создании ПО. Низкое внутреннее качество программы в долгосрочной перспективе вызывает дополнительные затраты. Если эти затраты могут быть определены количественно, то нужно сделать вывод, что достижение лучшего внутреннего качества приведет к снижению затрат. Это, видимо, единственный способ заставить начальство или клиента рассмотреть вопрос о выделении бюджета для рефакторинга кода.
Как замечает Питер Лиггисмеер (Peter Liggesmeyer), обеспечение качества компьютерных программ является многогранной темой: «Каждая компания, разрабатывающая программное обеспечение, будет пытаться достигнуть максимально возможного качества. ПО многогранно, то есть, понятие «качество программного обеспечения» включает в себя многие стороны. Не все из них одинаково важны для пользователей и производителей программного обеспечения». Таким образом, взгляд пользователя на качество программы, отличается от взгляда производителя. Можно согласиться с точкой зрения Нила Бевана (Nigel Bevan), определяющего наличие разницы между внешним и внутренним качеством программ.
Внешнее качество
Клиенты или конечные пользователи приложения, сосредотачивают свое внимание на тех аспектах достоинства программы, которые имеют для них существенное значение. Согласно мнению Себастьяна Бергмана (Sebastian Bergmann) эти аспекты являются показателями внешнего качества приложений:
• Функциональность означает, что приложение фактически может выполнять предлагаемые задачи.
• Юзабилити означает, что пользователь может работать эффективно, удобно и при этом еще получать удовлетворение от работы приложения. Доступность является частью юзабилити.
• Ре-активность (reactivity) подразумевает короткое время отклика программы. Это особенно важно, если производитель желает, чтобы пользователь был удовлетворен работой программы.
• Безопасность приложения является одним из наиболее важных факторов для востребованности программы. Она подразумевает высокую степень защищенности критически-важных данных, как пользовательских, так и кода самого приложения.
• Доступность и надежность особенно важны для веб-приложений с большим количеством пользователей. Приложения должны быть способны выдерживать большие нагрузки и обязаны работать даже в нестандартных ситуациях.
Все аспекты внешнего качества могут быть проверены путем тестирования приложения в целом, с использованием, так называемых, «непрерывных» (end-to-end) тестов. Применение тестирования позволяет в автоматическом режиме проверять, что программный продукт выполняет все свои функциональные требования.
Для повышения реактивности приложения, мы должны измерять время отклика. Необходимо использовать специальные инструменты и техники, чтобы оптимизация программы давала максимальный выигрыш производительности при минимальном объеме работы и сохранении низкой стоимости. Еще на этапе планирования мощностей, разработчики и администраторы должны определить потенциально опасные места в приложении, если вдруг изменится программное окружение или увеличится трафик. Необходимо изначально обладать этими данными, чтобы гарантировать качество приложения с учетом его доступности и надежности в долгосрочной перспективе.
Внутреннее качество
Внутреннее качество определяется нуждами разработчиков и администраторов приложения. Разработчики в первую очередь фокусируются на читаемости кода, который легко понять, адаптировать и расширять. Если они не сделают этого, реализация последующих требований клиента становится более сложной и, следовательно, более дорогой с течением времени. Это повышает риск того, что даже небольшие изменения в программном обеспечении могут привести к неожиданным побочным эффектам.
Внутреннее качество программы практически незаметно для клиентов и конечных пользователей. Конечные пользователи ожидают, что программа будет удовлетворять всем или, по крайней мере, большинству их функциональных ожиданий, а также быть простой в использовании. Фактически, если при использовании продукт работает достаточно быстро, большинство клиентов будут удовлетворены.
Однако недостатки внутреннего качества программы проявляются во временной перспективе. Требуется больше времени для исправления даже элементарных ошибок. Любые изменения или дополнения к программе требует все больших усилий. В итоге, разработчик рано или поздно начинает просить увеличить бюджет на чистку и рефакторинг кода. А так как клиенты или начальство обычно не понимают в чем польза рефакторинга, эти запросы чаще всего остаются без внимания.
Автоматизированные тесты индивидуальных программных модулей (модульные тесты) позволяют немедленно отслеживать появление новых ошибок, которые могут возникнуть при изменении кода. Без автоматизированных тестов рефакторинг кода был бы очень трудной работой.
Основная цель обеспечения качества, а точнее, управления качеством программного приложения, – сделать затраты и выгоды прозрачными для всех сторон, участвующих в создании ПО. Низкое внутреннее качество программы в долгосрочной перспективе вызывает дополнительные затраты. Если эти затраты могут быть определены количественно, то нужно сделать вывод, что достижение лучшего внутреннего качества приведет к снижению затрат. Это, видимо, единственный способ заставить начальство или клиента рассмотреть вопрос о выделении бюджета для рефакторинга кода.