現在、実施する取引調査の評価基準を設定しています。
私たちが選択した基準の 1 つは、信頼性 (および/または堅牢性 - これらは同じですか?) です。
ソフトウェアの評価に多くの時間を費やす余裕がないにもかかわらず、ソフトウェアの信頼性をどのように評価しますか?
編集: KenG の回答に沿って、質問の焦点を絞り込む: 50 の既存のソフトウェア ソリューションから選択できます。それらをテストすることはできませんが (少なくとも最初は)、信頼性を評価する必要があります。上記の信頼性を評価するために使用できる具体的な指標やその他の指標は何ですか?
信頼性と堅牢性は、システムの 2 つの異なる属性です。
IEEE は、「システムまたはコンポーネントが、指定された期間、指定された条件下で必要な機能を実行する能力」と定義しています。
入力や計算などに異常があっても動作し続ければロバストです。
したがって、信頼できるシステムは、制約内で設計されたとおりに機能を実行します。不測の事態が発生しても、堅牢なシステムは動作し続けます。
評価しているソフトウェアの履歴にアクセスできる場合は、報告された欠陥、時間の経過に伴う「パッチ」リリースの数、さらにはコード ベースのチャーンから、信頼性についてある程度推測できます。
製品には自動化されたテスト プロセスがありますか? テスト カバレッジは、信頼度のもう 1 つの指標となる可能性があります。
アジャイル手法を使用する一部のプロジェクトは、これらの基準にうまく適合しない場合があります - 頻繁なリリースと多くのリファクタリングが予想されます
実際の情報については、ソフトウェア/製品の現在のユーザーに確認してください。
評価するソフトウェアの種類によって異なります。Web サイトの信頼性に関する主な (そしておそらく唯一の) 基準は、そのアップタイムかもしれません。 NASAは、そのソフトウェアの信頼性について、まったく異なる定義を持つことになります。あなたの定義はおそらくその中間のどこかにあるでしょう。
信頼性を評価する時間があまりない場合は、測定プロセスを自動化することが非常に重要です。継続的インテグレーションツールを使用して、手動でバグを 1 回見つけるだけで済むようにすることができます。
あなたまたはあなたの会社の誰かが継続的インテグレーション: ソフトウェア品質の向上とリスクの軽減を読むことをお勧めします。ソフトウェアの信頼性を独自に定義するのに役立つと思います。
信頼性は、何かの有効性の 3 つの側面の 1 つです。残りの 2 つは、保守性と可用性です...
興味深い論文... http://www.barringer1.com/pdf/ARMandC.pdfでこれについて詳しく説明していますが、一般的には、
信頼性は、システムが壊れる確率に基づいています。つまり、壊れる可能性が高いほど、信頼性が低くなります。他のシステム (ソフトウェア以外) では、多くの場合、平均故障間隔 (MTBF) で測定されます。 ) これは、ハードディスクなどの一般的な指標です... (10000 時間の MTBF) ソフトウェアでは、重大なシステム障害の間、またはアプリケーションのクラッシュの間、または回復不能なエラーの間、またはエラーの間の平均時間で測定できると思います通常のシステムの生産性を妨げる、または悪影響を与えるあらゆる種類の...
保守性は、問題が発生した場合に修正するのにかかる時間/費用 (工数やその他のリソースの数) の尺度です。ソフトウェアでは、この概念に、ソフトウェアを強化または拡張するのにかかる時間と費用を追加できます (それが継続的な要件である場合)。
可用性は最初の 2 つの組み合わせであり、プランナーに、これらの 100 台を 10 年間稼働させた場合、障害を把握し、障害が発生した各ユニットが修理、修理などのために利用できなかった期間を示します。平均して、100 個のうち、一度に稼働しているのは何個ですか? 20% または 98% ?
さて、「信頼できる」というキーワードはさまざまな答えにつながる可能性があります...信頼性について考えるとき、私は次の 2 つの側面を考えます。
いずれにせよ、それはいくつかの繰り返し可能なテストに要約されると思います。問題のアプリケーションが単体テストと受け入れテストの強力なスイートで構築されていない場合でも、繰り返し実行する一連の手動または自動テストを考え出すことができます。
テストが常に同じ結果を返すという事実は、側面 2 が処理されていることを示しています。側面 1 については、実際にはテスト作成者次第です。バグや不完全性を明らかにする優れたテストを考え出すことです。
申し訳ありませんが、アプリケーションが何であるかを知らずに、これ以上具体的に言うことはできません。たとえば、メッセージが常に配信され、失われることがなく、エラーが含まれないなどの場合、メッセージングシステムは信頼できます...計算機の信頼性の定義は大きく異なります。
すでに使用している人に相談してください。信頼性を自分でテストすることはできますが、それは難しく、費用がかかり、特に時間がない場合は、テストする内容によっては信頼性が非常に低くなる可能性があります。ほとんどの企業は、ソフトウェアを販売するのに役立つ場合は、現在のクライアントと連絡を取り、ソフトウェアがどのように処理されるかについて実際のアイデアを提供することができます.
何事もそうですが、何かを自分で評価する時間がない場合は、他人の判断に頼らなければなりません。
信頼性が重要な基準であり、適切に評価するためのリソースがない (または関与する意思がない) 場合、妥協が悪影響を与える可能性があることを理解し、完全に受け入れることによって、プロセスに入る必要があります。それに基づいて。
そうは言っても、ソフトウェアの信頼性を重要にする主要な要件は何かを判断し、それらの要件に基づいて評価するためのテストを考案します。
堅牢性と信頼性は互いに関連していますが、必ずしも同じではありません。
10 を超える接続を処理できないデータ サーバーがあり、100000 の接続が予想される場合、堅牢ではありません。接続数が 10 を超えると、信頼性が低下します。その同じサーバーが必要な数の接続を処理できるが、断続的に停止する場合、そのサーバーはまだ堅牢ではなく、信頼性が低いと言えます。
私の提案は、実施する研究の分野に精通している経験豊富な QA 担当者に相談することです。その人は、リソースの制約の範囲内で、重要な領域のテストを考案するのを手伝ってくれるでしょう。決定を下すためにテストする必要がある主要な機能を決定するのに役立つ、中立的なサード パーティ (ソフトウェア ライターやベンダーではなく) をお勧めします。
テストできない場合は、開発者の評判と、このアプリケーションで他のテスト済みアプリと同じプラクティスをどれだけうまく実行しているかに頼る必要があります。例: Microsoft はアプリケーションのバージョン 1 であまり良い仕事をしていませんが、3 と 4 は通常かなり良いです (Windows ME はバージョン 0.0001 でした)。
評価しているサービスの種類に応じて、信頼性メトリックまたは SLI (サービス レベル インジケーター) - サービス/製品のパフォーマンスをキャプチャするメトリックを取得できます。たとえば、リクエストの 99% を 1 秒以内に処理します。
SLI に基づいて、サービス レベル アグリーメント (サービス レベル アグリーメント) を設定することができます。これは、SLO (サービス レベル目標) について、ソフトウェア プロバイダーが提供しない場合の結果を伴う契約です。