ソフトウェアの信頼性をどのように評価しますか？

StackOverflow https://stackoverflow.com/questions/272345

  •  07-07-2019
  •  | 
  •  

質問

現在、実施する貿易調査の評価基準を設定しています。

選択した基準の1つは信頼性です（および/または堅牢性-これらは同じですか？）。

ソフトウェアの評価に多くの時間を費やすことなく、ソフトウェアの信頼性をどのように評価しますか？

編集：質問の焦点を絞り込むために、KenGによって与えられた回答の行に沿って： 50の既存のソフトウェアソリューションから選択できます。それらをテストすることなく（少なくとも最初は）、それらの信頼性を評価する必要があります。上記の信頼性を評価するために、どのような有形のメトリックスまたはその他を使用できますか？

役に立ちましたか？

解決

信頼性と堅牢性は、システムの2つの異なる属性です。

信頼性

  

IEEEは、それを＆quot;として定義しています。 。 。その   システムまたはコンポーネントの能力   必要な機能を実行します   指定された条件   期間＆quot;

堅牢性

  

入力、計算などの異常にもかかわらず動作し続ける場合、堅牢です

したがって、信頼性の高いシステムは、制約内で設計されたとおりに機能を実行します。予期しない/予期しないことが発生した場合、堅牢なシステムは引き続き動作します。

評価しているソフトウェアの履歴にアクセスできる場合、報告された欠陥、時間の経過に伴う「パッチ」リリースの数、さらにはコードベースの解約から信頼性のアイデアを推測できます。

製品には自動テストプロセスがありますか？テストカバレッジは、信頼性のもう1つの指標になります。

アジャイル手法を使用するプロジェクトの中には、これらの基準に適合しないものがあります-頻繁なリリースと多くのリファクタリングが予想されます

実際の情報については、ソフトウェア/製品の現在のユーザーに確認してください。

他のヒント

まあ、キーワード「信頼できる」は異なる答えにつながる可能性があります...信頼性を考えるとき、私は2つの側面を考えます： 1〜常に正しい答え（または最良の答え）を出す 2〜常に同じ答えを返す

どちらの方法でも、繰り返し可能なテストに要約されると思います。問題のアプリケーションが一連の単体テストと受け入れテストで構築されていない場合でも、手動または自動テストのセットを繰り返して実行できます。

テストが常に同じ結果を返すという事実は、側面＃2が処理されていることを示します。アスペクト＃1については、実際にテスト作成者次第です。バグや欠陥を明らかにする適切なテストを考え出します。

アプリケーションが何であるかを知らなければ、より具体的には言えません。申し訳ありません。たとえば、メッセージが常に配信され、失われず、エラーが含まれないなどの場合、メッセージングシステムは信頼性が高くなります。計算機の信頼性の定義は大きく異なります。

既にそれを使用している人々と話してください。信頼性については自分でテストできますが、それは難しく、高価で、テストする内容によっては、特に時間が短い場合は非常に信頼性が低くなる可能性があります。ほとんどの企業は、ソフトウェアの販売に役立つ場合、現在のクライアントと連絡を取り、ソフトウェアがどのように処理するかについての現実的なアイデアを提供できるようになります。

評価するソフトウェアの種類によって異なります。 Webサイトの信頼性に関する主要な（そしておそらく唯一の）基準は、稼働時間です。 NASA には、ソフトウェアの信頼性に関するまったく異なる定義があります。あなたの定義はおそらく中間のどこかにあるでしょう。

信頼性を評価する時間があまりない場合、測定プロセスを自動化することは絶対に重要です。 継続的統合ツールを使用して、手動でバグを1回だけ見つける必要があることを確認できます。 。

あなたまたはあなたの会社の誰かが継続的な統合：ソフトウェア品質の改善とリスクの軽減。ソフトウェアの信頼性に関する独自の定義に導くのに役立つと思います。

何でもそうですが、自分で何かを評価する時間がない場合は、他人の判断に頼らなければなりません。

信頼性は、何かの有効性の3つの側面の1つです。他の2つは、保守性と可用性です...

興味深い論文... http://www.barringer1.com/pdf/ARMandC .pdf ではこれについて詳しく説明していますが、一般的には

信頼性は、システムが破損する確率に基づいています。つまり、破損する可能性が高いほど、信頼性が低くなります。他のシステム（ソフトウェア以外）では、平均時間間隔で測定されることがよくあります。障害（MTBF）これは、ハードディスクなどの一般的な指標です...（10000時間MTBF）ソフトウェアでは、重大なシステム障害の間、アプリケーションのクラッシュの間、または回復不能なエラーの間の平均時間で測定できると思います。または、通常のシステム生産性を妨げるまたは悪影響を与えるあらゆる種類のエラーの間に...

保守性とは、破損した場合に修正するのにかかる時間/費用（工数やその他のリソースの数）の尺度です。ソフトウェアでは、この概念に、ソフトウェアを強化または拡張するのにどれだけの時間/費用がかかるかを追加できます（継続的な要件である場合）。

可用性は最初の2つを組み合わせたものであり、故障の数と、故障した各ユニットが修理中に使用不能になった時間を把握した後、これらの100個を10年間実行した場合、プランナーに示します、どのような場合でも、一度に平均100台のうち何台が稼働しますか？ 20％または98％？

信頼性が重要な基準であり、リソースを持っていない（またはコミットしたくない）場合、悪影響を与える可能性があることを理解して完全に受け入れて、プロセスに入る必要がありますそれに基づいて適切に評価する。

と言って-ソフトウェアの信頼性を重要にする重要な要件を特定し、それらの要件に基づいて評価するテストを考案します。

堅牢性と信頼性は互いに関係が交差していますが、必ずしも同じではありません。

10を超える接続を処理できないデータサーバーがあり、100000の接続が予想される場合、堅牢ではありません。 ＆gt;で死亡した場合は信頼性が低くなります。 10接続。同じサーバーが必要な接続数を処理できても断続的に停止する場合、それはまだ堅牢ではなく信頼性がないと言えます。

私の提案は、あなたが実施する研究の分野で知識のある経験豊富なQA担当者に相談することです。その人は、あなたが重要な領域のためのテストを考案するのを手伝うことができます-できればあなたのリソースの制約内で。判断を下すためにテストする必要がある主要な機能の決定を支援するために、（ソフトウェアライターやベンダーではなく）中立なサードパーティをお勧めします。

テストできない場合は、開発者の評判と、このアプリケーションでテストされた他のアプリと同じプラクティスをどの程度順守しているかに依存する必要があります。例：マイクロソフトは、アプリケーションのバージョン1ではあまり良い仕事をしていませんが、3＆amp; 4は通常かなり良いです（Windows MEはバージョン0.0001）。

評価しているサービスのタイプによっては、信頼性メトリックまたはSLI（サービスレベルインジケータ）が得られる場合があります。これは、サービス/製品のパフォーマンスをキャプチャするメトリックです。たとえば、リクエストの99％を1秒未満で処理します。

SLIに基づいて、サービスレベル契約を設定する場合があります。サービスレベル契約は、SLO（サービスレベル目標）をお客様とソフトウェアプロバイダーとの間で契約するものです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top