Читая «Код завершен 2» в параграфе « Качество требований», я нашел это:
Определены ли приемлемые компромиссы между конкурирующими атрибутами, например, между надежностью и правильностью?
(это выше пункт большого списка флажков, чтобы проверить качество требований)
Итак, я нашел много определений робастности и корректности в Интернете, научных книгах и т. Д.
например:
В книге «Построение объектно-ориентированного программного обеспечения, 2-е издание, Бертран Мейер, Прентис-Холл, 1997»:
- Правильность: степень, в которой система свободна от [дефектов] в ее спецификации, дизайне и реализации.
- Надежность: степень, в которой система продолжает функционировать при наличии недопустимых входных данных или стрессовых условий окружающей среды.
Несмотря на это, неясно, почему и в каких ситуациях эти двое могут конфликтовать.
Мой вопрос: почему эти два атрибута в соревновании ?
development-process
requirements
quality-attributes
преодолевающим
источник
источник
Ответы:
Есть много ситуаций, в которых эти два могут быть в конфликте. Например, надежность может включать устойчивость при большой нагрузке. Если приблизительный (то есть, неправильный) ответ на запрос может быть вычислен намного быстрее, чем точный (правильный) ответ, важно знать, должна ли система выдавать приблизительный результат или вообще не доставить.
источник
Эти два примера, как вы сказали. Фактически, все нефункциональные требования такого рода могут потенциально конфликтовать друг с другом. В книге «Построение эволюционных архитектур» есть таблица из примерно сотни этих «способностей» (как их часто называют).
Для разработчиков программного обеспечения это своего рода упражнение по рассмотрению потенциального конфликта между любыми двумя из них. Вы можете решить, какие из них важны для ваших проектов, а затем отслеживать эти конфликты.
Чтобы вернуться к своему точному примеру и взглянуть на определение термина
robustness
в Википедии:Как видно из определения, устойчивость связана с ошибками . С другой стороны, вы хотите иметь правильность, что в основном означает отсутствие ошибок.
Чтобы сделать конфликт более очевидным, давайте рассмотрим простое поле ввода. Исходя из требования корректности, любой ошибочный ввод, сделанный пользователем, проще всего отклонить. Но надежность требует от вас возможности работать с этим входом, что может быть не совсем правильно.
Чтобы привести все это к вашей книге: каков сейчас приемлемый компромисс ? Допустим, вы пишете научное приложение, в котором пользователь может ввести величину напряжения, включая величину. Таким образом, правильные входные значения будут примерно такими: «10 кВ» или «200 мВ». Приемлемые компромиссы могут включать разрешение входов, таких как «10 кВ», «10 кВ» или даже просто «10», и для корректности сопоставьте их с действительным значением напряжения. Обратите внимание, что это все еще компромисс, а не «лучшее из двух миров». Рассмотрим прописные и строчные буквы: «10 кВ» и «10 кВ» могут быть хорошими, но «10 мВ» и «10 МВ» могут не быть. Корректность становится сомнительной, так как вы не уверены, сейчас она милли или мега,
источник
Практический пример - XHTML против HTML .
Таким образом, XHTML стремится к корректности, а HTML - к надежности. В настоящее время HTML кажется более популярным, но у обеих сторон есть веские аргументы.
источник