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

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

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

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

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

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

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

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

Я рекомендую, чтобы Вы или кто-то в Вашей компании считали Непрерывную Интеграцию: Улучшение Качества программного обеспечения и Снижение Риска. Я думаю, что это поможет привести Вас к Вашему собственному определению надежности программного обеспечения.

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

Надежность является одним из трех аспектов эффективности something.. Другими двумя является Пригодность для обслуживания и Доступность...

Интересная работа... http://www.barringer1.com/pdf/ARMandC.pdf рассматривает это более подробно, но обычно,

Надежность основана на вероятности, что система повредится.. т.е. чем более вероятно это должно повредиться, тем менее надежно это... В других системах (кроме программного обеспечения) это часто измеряется в Среднее время безотказной работы (СВБР), Это - общая метрика для вещей как жесткий диск... (СВБР 10 000 часов) программное обеспечение In, я предполагаю, что Вы могли измерить его в Среднее время между критическими системными отказами, или между сбоями приложения, или между неисправимыми ошибками, или между ошибками любого вида, которые препятствуют или оказывают негативное влияние на производительность нормальной системы...

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

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

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

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

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

Если у Вас есть сервер данных, который не может обработать больше чем 10 соединений, и Вы ожидаете 100 000 соединений - это не устойчиво. Это будет ненадежно, если это умрет в> 10 соединений. Если тот же самый сервер может обработать количество соответствующих соединений, но периодически перестает работать, Вы могли бы сказать, что это все еще не устойчиво и не надежно.

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

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