Конкуренція про стійкість та коректність [закрито]

Читаючи "Кодекс завершений 2" в абзаці якості вимог, я виявив таке:

Чи вказуються прийнятні компроміси між конкуруючими атрибутами - наприклад, між надійністю та правильністю?

(це вище є великим списком прапорців для перевірки якості вимог)

Отже, я знайшов багато визначень надійності та коректності в Інтернеті, наукових книгах тощо.

наприклад:

У книзі "Об'єктно-орієнтована побудова програмного забезпечення, 2-е видання, Бертран Мейєр, Prentice-Hall, 1997":

• Правильність: ступінь, в якій система не має [дефектів] в її специфікації, дизайні та реалізації.
• Міцність: ступінь, в якій система продовжує функціонувати за наявності недійсних входів або стресових екологічних умов.

Незважаючи на це, не ясно, чому і в яких ситуаціях ці двоє можуть конфліктувати.

Моє запитання: чому ці два атрибути є конкуренцією ?

Є багато ситуацій, в яких ці двоє можуть конфліктувати. Наприклад, міцність може спричинити стійкість при великому навантаженні. Якщо приблизну (тобто неправильну) відповідь на запит можна обчислити набагато швидше, ніж точну (правильну) відповідь, важливо знати, чи повинна система надати приблизний результат, або не виконати доставку взагалі.

Ці два - лише приклади, як ви сказали. Насправді, всі нефункціональні вимоги такого роду можуть потенційно конфліктувати між собою. У книзі "Будівля еволюційних архітектур" є таблиця приблизно з сотні цих "-літей" (як їх також часто називають).

Це свого роду вправа для архітекторів програмного забезпечення розглянути потенційний конфлікт між будь-якими двома з них. Ви в основному можете вирішити, які з них важливі для ваших проектів, а потім слідкувати за цими конфліктами.

Щоб повернутися до вашого точного прикладу та ознайомитись з визначенням цього терміна robustnessу Вікіпедії:

В інформатиці надійність - це здатність комп'ютерної системи справлятися з помилками під час виконання [1] [2] та справлятися з помилковим введенням даних.

Як видно з визначення, надійність передбачає помилки . З іншого боку, ви хочете мати правильність, що в основному означає відсутність помилок.

Щоб зробити конфлікт більш очевидним, розглянемо просте поле введення. З вимоги щодо правильності найпростіше відхилити будь-який помилковий вклад, зроблений користувачем. Але надійність вимагає, щоб ви могли працювати з цим входом, що може бути не зовсім коректно.

Щоб донести все це до вашої книги: яка прийнятна компромісія зараз? Скажімо, ви пишете наукову програму, в якій користувач може вводити величину напруги, включаючи величину. Тож правильні входи були б на кшталт "10 кВ" або "200 мВ". Допустимі компроміси можуть включати в себе вхідні джерела типу "10 кВ", "10 кВольт" або навіть просто "10" і для коректності відображають їх на дійсне значення напруги. Зауважте, що це все-таки компроміс, а не «найкращий з обох світів». Розглянемо великі регістри та малі регістри: "10 кВ" та "10 КВ" можуть бути нормальними, але "10 мВ" та "10 МВ" можуть бути. Правильність стає сумнівною, оскільки ви не впевнені, чи зараз це мілі, чи мега,

Практичний приклад - XHTML проти HTML .

• Браузери (у суворому режимі) відкидають XHTML, у якому є синтаксичні помилки. Це гарантує, що неправильні результати не відображаються користувачеві, а також допомагає знаходити помилки.
• Браузери намагаються продовжити розбір HTML-коду, навіть якщо він має дуже очевидні проблеми. Це часто дозволяє користувачеві переглядати сторінку, навіть якщо вміст трохи змінено.

Таким чином, XHTML має на меті коректність, а HTML - на надійність. В даний час HTML здається більш популярним, але обидві сторони мають хороші аргументи.