Как вы оцениваете надежность программного обеспечения?

Question

В настоящее время мы устанавливаем критерии оценки для торгового исследования, которое мы будем проводить.

Одним из выбранных нами критериев является надежность (и / или надежность - это одно и то же?).

Как вы оцениваете надежность программного обеспечения, не затрачивая много времени на его оценку?

Изменить: В соответствии с ответом, данным Кенгом, чтобы сузить фокус вопроса: Вы можете выбрать один из 50 существующих программных решений. Вам нужно оценить, насколько они надежны, не имея возможности их протестировать (по крайней мере, на начальном этапе). Какие материальные метрики или другие данные вы можете использовать для оценки указанной надежности?

Answer 1

Надежность и надежность - два разных атрибута системы:

Надежность

IEEE определяет его как "... способность системы или компонента выполнять свои необходимые функции под заявленные условия для указанного период времени. "

Надежность

устойчив, если он продолжает работать, несмотря на отклонения во входных данных, вычислениях и т. Д.

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

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

Имеет ли продукт автоматизированные тестовые процессы? Тестовое покрытие может быть еще одним показателем уверенности.

Некоторые проекты, использующие гибкие методы, могут не соответствовать этим критериям - ожидаются частые выпуски и большой рефакторинг

Проверьте с текущими пользователями программного обеспечения / продукта для реальной информации.

Answer 2

Надежность - это один из трех аспектов эффективности чего-то. Два других - это ремонтопригодность и доступность ...

Интересная статья ... http://www.barringer1.com/pdf/ARMandC.pdf обсуждает это более подробно, но, как правило,

Надежность основана на вероятности того, что система сломается. То есть, чем выше вероятность ее поломки, тем менее надежной она является ... В других системах (кроме программного обеспечения) она часто измеряется в среднем времени между Отказ (MTBF) Это общая метрика для таких вещей, как жесткий диск ... (MTBF 10000 часов) В программном обеспечении, я думаю, вы могли бы измерить его в среднем времени между критическими сбоями системы, или между сбоями приложений, или между неисправимыми ошибками, или между ошибками любого рода, которые мешают или отрицательно влияют на нормальную производительность системы ...

Ремонтопригодность - это мера того, сколько времени / как дорого (сколько человеко-часов и / или других ресурсов) требуется, чтобы починить его, когда он сломается. В программном обеспечении вы можете добавить к этой концепции, как долго / как дорого стоит усовершенствовать или расширить программное обеспечение (если это постоянное требование)

Доступность представляет собой комбинацию первых двух и указывает планировщику, если у меня было 100 таких вещей, работающих в течение десяти лет, после определения отказов и того, как долго каждый неисправный блок был недоступен, пока его ремонтировали, ремонтировали Сколько бы из 100, в среднем, работало бы одновременно? 20% или 98%?

Answer 3

Как и во всем, если у вас нет времени, чтобы оценить что-то самостоятельно, тогда вы должны полагаться на мнение других.

Answer 4

Это зависит от того, какой тип программного обеспечения вы оцениваете. Основным (и, возможно, единственным) критерием надежности сайта может быть его время безотказной работы. НАСА будет иметь совершенно иное определение надежности своего программного обеспечения. Ваше определение, вероятно, будет где-то посередине.

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

Я рекомендую вам или сотруднику вашей компании прочитать Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков . Я думаю, что это поможет привести вас к определению надежности программного обеспечения.

Answer 5

Поговорите с людьми, которые уже используют его. Вы можете проверить себя на надежность, но это сложно, дорого и может быть очень ненадежно, в зависимости от того, что вы тестируете, особенно если у вас мало времени. Большинство компаний захотят связать вас с текущими клиентами, если это поможет продать вам их программное обеспечение, и они смогут дать вам реальное представление о том, как оно работает.

Answer 6

Ну, ключевое слово «надежный» может привести к разным ответам ... Когда я думаю о надежности, я думаю о двух аспектах: 1 ~ всегда дает правильный ответ (или лучший ответ) 2 ~ всегда дает один и тот же ответ

В любом случае, я думаю, что все сводится к повторяющимся тестам. Если рассматриваемое приложение не построено с использованием строкового набора модульных и приемочных тестов, вы все равно можете предложить набор ручных или автоматических тестов для повторного выполнения.

Тот факт, что тесты всегда возвращают одни и те же результаты, покажет, что аспект № 2 позаботился. Что касается аспекта № 1, то это действительно зависит от авторов тестов: придумать хорошие тесты, которые выявили бы ошибки или недостатки.

Я не могу быть более конкретным, не зная, о чем приложение, извините. Например, система обмена сообщениями была бы надежной, если бы сообщения всегда доставлялись, никогда не терялись, никогда не содержали ошибок и т. Д. И т. Д. Определение надежности калькулятора было бы сильно другим.

Answer 7

В зависимости от типа услуги, которую вы оцениваете, вы можете получить метрики надежности или SLI - индикаторы уровня сервиса - метрики, показывающие, насколько хорошо работает сервис / продукт. Например - обработать 99% запросов за 1 сек.

Исходя из SLI, вы можете заключить соглашения об уровне обслуживания - договор между вами и поставщиком программного обеспечения о том, какой SLO (цели уровня обслуживания) вы бы хотели получить, а не отказываться от них.

Answer 8

Если вы не можете протестировать его, вам придется полагаться на репутацию разработчика (-ов) и то, насколько хорошо они следовали тем же правилам в этом приложении, что и другие протестированные приложения. Пример: Microsoft не очень хорошо работает с версией 1 своих приложений, но обычно 3 и 4 довольно хороши (Windows ME была версией 0.0001).

Answer 9

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

Сказав это - определите, какие ключевые требования делают критически важной надежность программного обеспечения, а затем разработайте тесты для оценки на основе этих требований.

Надежность и надежность пересекаются в их отношениях друг с другом, но не обязательно одинаковы.

Если у вас есть сервер данных, который не может обрабатывать более 10 соединений, и вы ожидаете 100000 соединений - он не устойчивый. Это будет ненадежно, если он умрет при> 10 соединениях. Если тот же сервер может обработать количество требуемых соединений, но периодически умирает, вы можете сказать, что он все еще не устойчив и ненадежен.

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