良い仕事を知識ベースに提出するのは簡単です。 以下のフォームを使用してください

学生、大学院生、研究や仕事で知識ベースを使用している若い科学者はあなたにとても感謝しています。

に投稿 http://www.allbest.ru/

に投稿 http://www.allbest.ru/

最新のソフトウェア品質モデル

はじめに

ソフトウェア品質ループ

現代のソフトウェア業界は非常に高度な競争を特徴としているため、ソフトウェア市場で会社の競争力を確保する条件の1つは、高品質のプログラムのリリースです。

現代のソフトウェアの複雑さとサイズの急速な増加、それらによって実行される機能の責任の増加により、ソフトウェアの効率と信頼性、およびその使用の安全性に対するユーザーの要件が急激に増加しています。

ソフトウェア製品の品質を評価する際に使用される主な基準の1つは、ユーザーの期待をどの程度満たすか、確立または予想されるニーズをどの程度満たすことができるかです。

これらのステートメントの妥当性を検証するために、プロジェクトの成功を判断する2つのアプローチを比較します。

上記のソフトウェアプロジェクトの成功の定義は、より実用的であるため、プロジェクトの成功を決定することとは多少異なります。 成功する最終結果を達成することを目的とした組織の管理に焦点を当てており、定義では「消費者の要件を満たす」という言葉で表されています。 最終的なソフトウェア製品が当初計画されていたすべての機能を備えていないという事実は、それが会社の管理部門、マーケティング部門、販売部門、そして最も重要なユーザーを満足させる場合、重要ではありません。

このスローガンを実際に適用するには、ソフトウェアプロジェクトのリーダーと参加者が、消費者のニーズを理解し、ソフトウェアの品質レベルを評価し、プロジェクトを確立された時間と財務の枠組み内に維持する方法を知っている必要があります。

ソフトウェア開発者に加えて、ソフトウェアプロジェクトの参加者には3つの主要なカテゴリが含まれます。 これらは、買い手、ユーザー、投資家です。 これらの各当事者は、独自の利益を追求しています。 さらに、各個人または組織は1つまたは複数のカテゴリに分類でき（たとえば、ユーザーはバイヤーになり、バイヤーは投資家になります）、プロジェクト自体にいずれかの種類のソフトウェアの開発が含まれる場合があります。

・消費者向けソフトウェア。小売販売用に設計されたプログラム（コンピューターゲーム、トレーニングプログラムなど）を意味します。 この場合のユーザーは、原則として買い手であり、会社の開発者は投資家です。

・プロダクションソフトウェア、つまり 企業や組織が変更することなく取得できるように設計された大規模システム（CADや公開システムなど）。 通常、買い手は情報技術組織であり、開発者は投資家です。

・カスタムソフトウェア-特定の契約に従って開発されたシステム。 顧客の役割は、政府組織または大企業です。 特定の注文に応じて、投資家の役割は会社の開発者、会社の顧客、またはこれらの当事者の両方が果たすことができます。

・特定の顧客の仕様に従ってインストールされる再利用可能なコンポーネントで構成される独自のシステムを構築できる、特別注文により作成されたコンポーネント。 バイヤーは顧客企業の情報技術部門であり、消費者は他の部門の従業員です。 投資家は開発会社です。

・ファームウェア。 このようなソフトウェアの購入者は、ほとんどの場合、このプログラムを自社製品に実装したい消費財、玩具などのメーカーです。 これらの製品の購入者もユーザーです。

現在、顧客とソフトウェア開発者の間にはいくつかの相互作用スキームがあります。

「自社」顧客

開発チームが長期間にわたって単一の顧客にサービスを提供する状況。 通常、このオプションは、顧客と開発者の間の合理化された関係によって特徴付けられます。 多くの場合、そのようなチームは顧客の領域に配置されます。 このタイプのプロジェクトの主な特徴：

・いつでも利用できる顧客。

・顧客のニーズと要件に関する安定したアイデア。長年にわたる協力の中で形成されました。

・ソフトウェアの品質に関する十分に柔軟な要件。

・製品の継続的なサポート、改良と改善。

・顧客と開発者の間の持続可能な金融関係。

・長期的な協力計画。

カスタム製品

開発チームがサードパーティの顧客を見つけ、特定の顧客の問題を解決するために設計されたソフトウェア製品の開発について彼に同意する状況。 このタイプのプロジェクトの主な特徴：

・顧客の可用性は「定期的」と説明できます。

・調査に基づいて、顧客のニーズと要件のアイデアが形成されます。

・ソフトウェア要件は事前に指定されており、それに応じて完成品の受け入れが行われます。

・財務関係は、1回限りの契約の形で実行されます。

・さらなる協力の計画は、開発者が顧客に提供した製品の品質と持続可能性に大きく依存します。

複製製品

開発チームが特定の顧客（「箱入り製品」）をまったく持たないか、同じ製品に対してかなり多くの顧客を抱える状況。 このタイプのプロジェクトの主な特徴：

・製品の要件を形成する特定の顧客はありません。

・現在および潜在的なユーザーのニーズと要件のアイデアは、市場分析と一般的なユーザーの代表者との接触に基づいて形成されます。 製品のユーザーからのフィードバックは、主に電子メールまたはホットラインで行われます。

・ソフトウェアの品質は、内部品質部門とユーザーフィードバックによってのみ制御されます。 ベータテストは広く使用されています。

・開発者は、提供された製品を所定の期間サポートします。

・金融関係は、製品の固定価格の形で存在します。

・製品開発計画は、市場分析に基づいて作成されます。

アウトソーシング

最も若いソフトウェア生産モデル。 ロシアのプログラマーは、欧米のプログラマーと比較して仕事の質が高く安価であることから登場し、その後、ロシアの大手ソフトウェア会社でも使用されました。 このようなモデルの本質は、大規模なソフトウェア会社と小規模な開発組織との間で下請けが締結されることです。 このタイプのプロジェクトの主な特徴：

・開発者は、製品の最終消費者に連絡しません。 すべての情報は、大規模な請負業者から技術仕様の形式で取得されます。

・顧客のニーズと要件のアイデアは、請負業者から提供された情報に基づいてのみ形成されます。

・請負業者は、ソフトウェア生産プロセスとその品質に関する要件を提供します。

・通常、製品サポートは請負業者によって実施されます。

・財務関係は、開発チームのメンバーと請負業者の間の個々の契約という形で存在します。 選択肢は、請負業者と開発チームを代表して活動する法人との間で合意を締結することです。

ソフトウェア品質保証の最も重要な問題の1つは、品質特性の定式化と評価の方法論です。 同時に、ソフトウェア開発の技術仕様を準備するとき、それらはしばしば沈黙しているか、ソフトウェア製品の品質特性の要件が明確に定義されていないため、それらをどのように測定し、契約および仕様に反映されている要件と比較するかが決定されていません。 結果として、これは、同じ特性の異なる解釈のために、顧客/ユーザーと開発者/サプライヤーの間に競合を引き起こします。

これらの矛盾を排除するには、ソフトウェアライフサイクルのプロセスと製品を管理する国際標準の知識と正しい適用が必要です。 ただし、これらの標準に従うことは純粋に機械的であってはなりません。特定のソフトウェアプロジェクトの条件に適合させる必要があります。

1.ソフトウェア品質基準

現在、一般に相互に互換性のあるいくつかの品質定義があります。 最も一般的なものは次のとおりです。

ISOの定義：品質とは、明示的または暗黙的なニーズを満たす能力を提供する製品、プロセス、またはサービスの特性と特性の完全性です。

IEEEの定義：ソフトウェアの品質とは、必要なプロパティの組み合わせがどの程度あるかです。

ソフトウェアエンジニアリングの主な品質基準は、現在ISO / IEC 9126：1-4：2002（GOST R ISO / IEC 9126-93）です。 それに加えて、品質特性の評価方法を規定するISO / IEC 14598標準のセットが発行されました。 一緒に、SQuaRE（ソフトウェア品質要件と評価）として知られる品質モデルを形成します。

ISO 9126に従って、ソフトウェアの品質（PS）の一般的な考え方は、相互に依存し相互に依存する品質特性の3つのメトリックによって記述されることが推奨されます。

・仕様の顧客要件によって指定され、最終製品の特性に反映される外部品質。

・PSのライフサイクルの開発プロセスおよびその他の中間段階で明らかにされる内部品質。

・リソースのコストを考慮した、通常の操作中に使用される場合の品質とユーザーニーズの達成の有効性。

外部および内部の品質特性は、ソフトウェアシステム自体の特性に関連し、顧客および開発者の意見を反映しています。 ただし、エンドユーザーは、PSの使用により最大の累積効果が得られることを期待しています。これは、ソフトウェア製品に対する生産性と全体的な満足度を高めるためです。 ソフトウェアシステムの品質に関するこの見解は、ソフトウェアの「使用品質」または「運用品質」という用語で表されます。

品質を特徴付けるソフトウェアシステムの属性は、品質メトリックを使用して測定されます。 メトリックは、特定の測定方法（値を取得する方法）、エンティティ属性、および測定スケール（取得した値の構造化に使用されるツール）の組み合わせです。 メトリックは、属性の測定値（測定の結果として値が割り当てられる変数）を定義します（図3.1を参照）。

品質要件の定義は通常、機能するソフトウェア製品の要件を反映する外部品質特性のリストから始まります。 さらに、システムがその要件を満たすためにシステムをチェックおよび確認する品質基準を定量的に決定するために、ソフトウェアシステムの適切な外部測定可能プロパティ（外部属性）および属性を評価するためのモデルである関連メトリックも受け入れられます 対応する属性の値（測定値）の変化の範囲（図3.1を参照）。

テストの段階にある、またはシステムの一部として機能しているコンピューターで実行されているソフトウェアに対してのみ定義と適用が可能なメトリックは、外部メトリックと呼ばれます。 外部メトリックは、テスト、試用中にソフトウェア品質を追跡および分析する機能を顧客、ユーザー、および開発者に提供します。

図 3.1。 品質測定システム

外部メトリックの要件を決定した後、PSの内部品質特性と内部属性が指定されます。 これらは、最終ソフトウェア製品の必要な外部品質特性の達成と、開発中の中間（動作中）PS製品への統合を計画するために使用されます。 次に、内部品質メトリックが定義されます。 内部品質特性、属性、およびメトリックの概念は、テスト（要件の決定、設計、コーディング）の前の開発段階で取得したコンピューター（ドキュメント、コードテキスト、テストなど）で動作しないPS作業成果物に関連付けられています。

内部メトリックは、ソフトウェアが製品を使用する準備が整う前に、開発者、テスター、および顧客がプログラムのライフサイクルの品質を予測し、技術的な品質保証の問題に対処する機会を提供します。 内部メトリックは、設計およびプログラミング中に、仕様、ソースコード、ドキュメントなどのソフトウェアシステムのコンポーネントに適用できます。 内部メトリックを適用する主な目的は、必要な外部品質を提供することです。

使用中の品質指標は、製品が特定のユーザーの目標を達成するためのニーズを満たす度合いを反映しています。 これらのメトリックは、共通性のためにISO 9126-1規格で規制されている6つの基本特性には反映されていませんが、ISO 9126-4規格のソフトウェアシステムの機能とアプリケーションの統合評価に推奨されます。

ソフトウェア品質をモデル化する一般的なアプローチは、最初に最高レベルの抽象化の品質属性（特性）の小さなセットを特定し、次にこれらの属性を「トップダウン」方向の従属属性セットに分解することです。 ISO / IEC 9126標準は、このアプローチの典型的な例です。 ソフトウェアの品質を評価するために、基本的なインジケータの6つのグループが使用されます。各グループは、いくつかの規範的なサブ特性によって詳述されます。 標準の特性およびサブ特性は、特定のシステムおよびプロジェクトへの適用に関するコメントおよび詳細な推奨事項なしに、簡潔に定義されています。 プレゼンテーションは本質的に概念的なものであり、オブジェクト、開発環境、メンテナンス、およびアプリケーションの特性に応じて、優先順位の選択と順序に関する推奨事項、および必要な最小基準は含まれていません。 標準の最初の部分-ISO 9126-1-は、標準の残りで使用される6つの特性によってソフトウェア品質の属性を配布します。 これらの測定の基本的な可能性に基づいて、すべての特性を3つのグループに結合し、異なるカテゴリのメトリックを適用することができます。 タスクと仕様、およびその測定値は客観的で再現可能です。 ：

・ソフトウェアの機能を評価するために、カテゴリーまたは記述（名義）メトリックが使用されます。

・定量的メトリックは、複雑なソフトウェアシステムの信頼性と有効性の測定に適用できます。

・高品質のメトリックは、ソフトウェアの実用性、保守性、およびモビリティと最も一貫しています。

標準の2番目と3番目の部分（ISO 9126-2およびISO 9126-3）は、それぞれ複雑なソフトウェアツールの品質特性の外部および内部メトリックの形式化に当てられています。 すべてのテーブルには、メトリックの名前と目的を反映した統一されたルーブレーションが含まれています。 その適用方法; 測定方法、メートルスケールの種類; 測定値のタイプ。 測定および比較の初期データ。 およびソフトウェアツールのライフサイクルの段階（ISO 12207に準拠）。これには、メトリックが適用されます。 標準の4番目の部分であるISO 9126-4は、バイヤー、サプライヤー、開発者、ソフトウェアサポートサービス、ユーザー、品質管理者を対象としています。 ソフトウェアの使用範囲の選択された指標およびユーザーの選択されたメトリックのグループを実証し、コメントします。 ソフトウェアの品質を評価するために使用される特性、およびそれらを指定するサブ特性を表3.1に要約します。

タブ。 3.1。 ソフトウェア品質特性

2. ライフサイクルの段階でのソフトウェア品質管理

ソフトウェアツールのライフサイクルの各段階で品質を適切に管理するには、品質のさまざまな側面を考慮し、開発プロセス中の品質に対する認識の変化を考慮する必要があります。 ISO / IEC 9126規格は、ライフサイクルの段階ごとに製品品質に関する見解を次のように変更することを提案しています。

・ターゲット品質-ユーザーの実際のニーズを反映する必要十分な品質。 顧客が述べたニーズは、ソフトウェア製品の品質に関するユーザーの実際のニーズを常に反映するわけではなく、これらのニーズはプロジェクトのドキュメントに記録された後に変更される可能性があるため、開発者はプロジェクトの開始時に完全に定義できない概念的なエンティティとして目標品質を検討し、 ガイドとして使用する必要があります。 目標品質の要件は、可能な限り変電所の品質の要件の仕様に含め、ソフトウェア製品の開発の最後に運用品質を測定することで評価する必要があります。

・製品の必要な（確立された）品質とは、品質要件の仕様に実際に記載されている外部品質特性の値のレベルであり、チェックの目標として使用する必要があります。 すべてまたは一部の品質特性の要件は、PSの要件の仕様に示されています。 特性の最適値とともに、最小値も示す必要があります。これは、顧客と開発者が開発のコストと条件を不必要に超えないようにするのに役立ちます。

・ソフトウェアプロジェクトの品質-たとえば、ソフトウェアアーキテクチャ、プログラム構造、ユーザーインターフェイス設計戦略など、主要部分またはプロジェクト全体の説明で示されるソフトウェアツールの内部品質 プロジェクトの品質はソフトウェア製品の品質の基礎であり、コーディングおよびテスト中にわずかに改善することができます。

・推定（または予測）製品品質-ソフトウェアプロジェクトの品質特性に基づいて、開発の各段階で最終ソフトウェア製品の品質として評価または予測される品質。

・供給された製品の品質は、原則として、シミュレートされたデータを使用してシミュレートされた環境でテストされた、出荷可能な製品の品質です。

・運用品質-プロパティではなく、使用結果の観点から測定されたソフトウェアシステムの品質。 ユーザーは、実際の使用中に目に見えるPSの品質の属性のみを評価します。したがって、ユーザー環境のソフトウェアの品質は、環境機能とアプリケーションシナリオの過小評価のため、開発環境の品質とは異なる場合があり、結果として不十分なテストになります。

さらに、各品質特性には、特定の適用分野および対応するユーザーコミュニティに対して特定の重み（重要性）があり、品質に対する視点を反映していることに留意する必要があります。

ソフトウェアプロジェクトのさまざまな参加者のソフトウェア品質の認識

ソフトウェアの品質について言えば、特定の品質特性を達成することの重要性に関するソフトウェアプロジェクトのさまざまな参加者の見解は大きく異なることに留意する必要があります。

ユーザーは、特定のタスクを実行するためにソフトウェアと直接対話する人です。 ユーザーの観点から見ると、ソフトウェアのタスクは、その作業の効率を高め、より便利にすることです。

ユーザーは、ソフトウェアの内部的な側面やソフトウェアの作成方法を検討せずにソフトウェアを評価します。 ユーザーにとって、ソフトウェア品質の最も重要な属性は機能性と実用性です。 これを行うには、ソフトウェアを開発するときに、2つの主要なポイントに注意を払う必要があります。必要な機能を提供することと、ユーザーインターフェイスを設計することです。

適切な機能は、ユーザーの満足度にとって重要です。 ただし、購入者とユーザーは、ソフトウェアシステムの要件を正確に定式化できない場合や、初期段階では単にそれらを知らない場合があります。 したがって、ソフトウェア開発会社が解決すべき最も重要な問題の1つは、顧客またはユーザーがこの製品を使用する方法を理解することです。

2番目の重要な問題は、便利でプロフェッショナルなユーザーインターフェイスの開発です。 インターフェイスの設計を開始するとき、インターフェイスに反映されないプログラムの機能は単に存在しないことに注意してください！ わかりにくいインターフェースのようにユーザーを悩ませるものはありません。 システムの機能がどのように提供されるかは関係ありません-ユーザーがアクセスできない場合、これはすべて役に立ちません。MSDOSまたは初期のMSプロジェクトのインターフェースを覚えておいてください。 。 優れたユーザーインターフェイスを備えたシステムは、常にユーザーの期待どおりに動作します。

ソフトウェアを作成するとき、開発チームは機能だけでなく、プログラムの動作条件（たとえば、Webページを同時に表示できるユーザー数、データベース内のレコードの最大数、特定のタスクを実行するためのシステムの最小応答時間など）についても仮定する必要があります。 .p。）。 これらの条件は明示的な場合もあれば、隠されている場合もあります。 したがって、ユーザーにとって、信頼性などの品質属性は非常に重要です。 信頼性のある（フォールトトレラント）製品は、開発中に採用された仮定を超える条件でも機能するように作成されます。

ソフトウェアの信頼性を特徴付ける重要な要素は、平均故障間隔です。 障害は、プログラムのフリーズ、データ破損、またはプログラムがその機能を実行するのを妨げる何かとして理解できます。 平均故障間隔は、プログラムで残留欠陥が検出される可能性を決定します。 その値が大きい場合、残留欠陥を見つけるコストは正当化されません。

ソフトウェアの信頼性を証明するもう1つの要因は、アップタイムです。これは、ユーザーがソフトウェアを使用できる時間の割合です。

システムが動作するためには、MTBFの値が大きい必要があります。 高いパフォーマンスインジケータを達成するには、長時間のテストとかなりのリソースが必要になるため、プロジェクトマネージャーのタスクは、ソフトウェア開発のコスト、システムの配信時間、およびそのパフォーマンスの妥協点を見つけることです。

表3.2：さまざまなヘルスメトリックのソフトウェアダウンタイム

購入者は、ソフトウェアを購入し、それを使用するライセンスを所有している個人または組織です。 多くの場合、ソフトウェア購入者はユーザーではありません。 購入者の主な問題は、ユーザーのニーズを満たすことと、ソフトウェアの取得と実装に関連するコストを最適化することです。

実装の実際のコストは、ソフトウェアの初期コストには含まれていません。 これらは、ソフトウェアのインストールと構成、定期的なメンテナンスの実行、アドオンとアップデートのインストールなどのコストです。 したがって、買い手はまず、機能、信頼性、保守性、モビリティなどのソフトウェア品質のパラメーターに注意を払います。

オンサイトメンテナンスの容易さ、アドオンと更新プログラムのインストールの容易さ（プログラムの新しいバージョンをインストールするために1週間システムをオフにする必要がある場合、これはユーザーに大きな不便をもたらします）-これはソフトウェアを選択する際の買い手にとって大きなプラスです。 さらに、特定のタスクを実行するようにソフトウェアを調整できる必要があります。 購入者は、取得したソフトウェアアプリケーションにハードウェアインフラストラクチャを適合させたくない場合があります。 彼はその環境でうまく機能するようにソフトウェアを構成することを好みます。

そしてもちろん、購入者はソフトウェアのコストを気にします。 価格には、ソフトウェア製品の購入コストだけでなく、 これには、年間ライセンス料金、インストール、構成および内部サポートのコスト、追加および更新のコスト、プログラムの動作に必要な追加ハードウェアのコストが含まれる場合があります。 多くの（特に設計が不十分な）システムでは、所有コストが元の購入価格を大幅に上回る可能性があります。

投資家は、開発にお金を払う個人または組織です。 投資家は彼の投資が収入をもたらすと期待しています。 この収入は、ソフトウェア製品の販売から直接得られるか、この製品が意図された組織の効率を高めることになります。 ソフトウェアの品質に多くの注意を払う場合、投資家は通常、電話で技術サポートを提供し、現場に出向く人員のコストを含む運用コストを支払い、プログラムの使用中に発生した問題に関するレポートを収集し、欠陥を検索して修正し、アドオンを作成して配信します ソフトウェアの更新。 カスタムプログラムおよび長期使用向けに設計されたプログラムの場合、運用コストが開発コストを上回ることがよくあります。 したがって、低開発コストよりも限られた運用コストで製品を作成することが重要です。 ソフトウェアの運用コストに影響を与える主な要因の1つはその信頼性であり、もう1つはプログラムコードの欠陥や現場でのその他の誤動作を特定して排除するための保守性とコストです。

ソフトウェアプロジェクトの投資家は通常、新しい開発が市場競争力を維持するための基礎になることを望んでいます。 近年、ソフトウェア（特にカスタム）の開発では、生成されたソフトウェアコードを再利用してシステムの次のバージョンのコストを削減する可能性を考慮しています。 さらに、ソフトウェア製品の開発は通常、販売可能な知的財産をもたらします。

そのため、投資家は主に次の3つの側面に関心を持っています。

・ユーザーと購入者に対するソフトウェア製品の実用性。これにより、製品の需要が確保され、結果として収益が増加します。

・運用コスト。これによりコストが増加し、利益の低下につながる可能性があります。

・知的財産の価値。

プログラムプロジェクトの各参加者の主要な品質特性の重要性は、表3.3に概略的に反映されています。

開発者は、ソフトウェアを直接作成する個人または組織です。 開発者は、作成されたソフトウェア製品が実際に指定された要件を満たしていることを確認する責任があるため、最終製品の品質よりも中間成果物の品質に関心があります。 さらに、開発サイクルの各中間フェーズの結果を評価する場合、開発者は同じ品質特性に対して異なるメトリックを使用する必要があります。 たとえば、ユーザーは応答時間の観点から有効性を理解しますが、開発者は設計仕様でルートの長さとレイテンシーおよびアクセスの用語を使用します。 同時に、開発者と顧客および/またはユーザーは、最終製品を受け入れるときに同じ品質特性を使用する必要があります。

プログラムプロジェクトマネージャーは、特定の品質プロファイルよりも全体的な品質に関心がある場合があります。そのため、個々の特性のビジネス要件を反映する値の重要性を判断する必要があります。

また、マネージャーは、限られたコスト、利用可能な労働リソース、および設定時間内で品質を最適化するため、品質改善のレベルを計画遅延やコストオーバーランなどの管理容易性の基準と比較する必要があります。

ユーザーは時々、ソフトウェアをカスタマイズする方法を見つけます。 これにより生じるエラーは、発見および除去がより困難です。 実際には、優れたソフトウェアでは、テストの初期段階で欠陥を簡単に検出できます。 テストを継続すると、システムの信頼性が向上し、その後の各欠陥の検出がより難しくなります。 さらに、研究は、欠陥を見つけるコストが指数関数的に増加することを示しています。 その結果、管理者はいつ停止するか、つまり どの時点で、テストコストと市場損失が、予想される運用コストと釣り合うか。 この時点で、製品は市場に参入する準備ができていると見なされます。

プログラムプロジェクトマネージャーは、高品質のソフトウェアを開発するためのコストと、そのようなコストを支払う余裕があるかどうかに関心を持つ必要があります。 特定の開発において、どのレベルの品質が「手頃な価格」になりますか？

この質問に答えるには、まず、この開発に関心のある各当事者にとってどの品質属性が優先されるかを判断し、妥協案を見つける必要があります。 品質が不十分であると、コストが増加するだけでなく（運用サービスや保証サービスなど）、とりわけ市場が失われるため、設計と科学研究のコストが最大50％増加することを念頭に置いておく必要があります 品質は商業的な意味で正当化される以上のものです。 最も一般的な誤解は、高品質のソフトウェアは要件を完全に満たし、欠陥がないソフトウェアであるという仮定です。 一般に、最後の欠陥を見つけて、欠陥のないプログラムをリリースすることは不可能です。 この目標を達成するには、組織に余裕のないテストが必要です。 さらに、品質を達成する手段としてのテストには、機能が制限されています。 集中的なテストと数千時間の使用後に特別な安全要件を備えたシステムで残留エラーが見つかった場合の例が文献に示されています。 欠陥の検出と修復は重要なタスクですが、ソフトウェアツールは開発上の欠陥のために使用できないことがよくあります。 プログラムはプログラマーが計画したとおりに機能し、すべてのテストに合格できますが、開発者はユーザーが必要とするものを理解していなかったため使用できません。 開発したソフトウェアが十分かどうかを判断するには、ソフトウェア製品を提供しない場合のコストと、提供する場合の運用コストを比較する必要があります。

3.最新のソフトウェア品質モデル

ソフトウェアの品質は、特定の品質モデルに基づいて評価する必要があります。 品質モデルの選択は、さまざまな要因の影響を受けます。

シミュレーションの目的に応じて、品質モデルは、程度の差はあれ、ソフトウェアプロジェクトのさまざまなカテゴリの参加者（マネージャー、開発者、サポートスタッフ、ユーザー）の期待を反映し、関心が一貫していることを保証する順序付けられた特性のセットを含むことができます。 これらの利益の優先順位（重要性、満足時間）を考慮することは、品質保証戦略の開発の基礎です。 前述のように、ほとんどの場合、プログラムプロジェクト参加者の観点からの優先順位は、プロジェクトマネージャーと、起こりうるリスクを最小限に抑えることへの関心です。

非常に単純なプロジェクトを除いて、変電所のさまざまなコンポーネントには通常、品質特性に対するまったく異なる要件があります。 たとえば、ユーザーインターフェイスを提供するコンポーネントは、使いやすさの要件が高く、整合性の要件が高いデータベースが特徴です。 単一のソフトウェア製品を同じ品質要件を特徴とするコンポーネントに概念的に分離することにより、異なる要件間の競合を減らすことができます。

1つの組織内で、開発プロセスは異なるコンテンツを持つことができ、プロジェクトおよび統合ツールで使用される方法論によって異なります。 これらの違いにより、異なるプロジェクトで同じメトリックセットを使用する機能が制限されます。 たとえば、構造メソッドを使用して開発されたコードの行数とオブジェクト指向メソッドによって開発された行の数を比較することは意味がありません。

組織開発者が同じタイプのソフトウェア製品の生産に特化している場合、従業員のトレーニング、設計およびプログラミング戦略、あらゆる種類のデータを収集および記録する手法、測定方法などに対する特定のアプローチを徐々に開発します。 これにより、同様の特性を持つソフトウェアシステムの開発に私たち自身の経験を活用し、品質に関連するプロジェクトに関する有用な履歴情報を蓄積することができます。 その結果、このような組織は、品質モデルをより正確に構築し、適切なメトリックを選択し、すべての品質特性の定量的尺度を確立し、開発の初期段階ですでに達成を予測できます。

したがって、品質モデルは、品質要件の仕様とソフトウェアの品質評価の基礎となる相互に関連する特性のセットです。

ソフトウェアの品質を確保するためのさまざまなアプローチがあり、それぞれに長所と短所があります。 最初の品質モデルの1つはISO 9000シリーズ標準で、その最初のバージョンは1987年にリリースされました。 それ以来、ISO 9000シリーズの証明書の人気は変わらず、世界中で認められています。

しかし、時間が止まらず、ISO 9001規格の基礎となる技術は徐々に時代遅れになりつつあります。 その最大の欠点は次のとおりです。

・監査人の見解に応じて、標準の詳細が不十分であり、その最も多様な解釈の可能性。

・ソフトウェアの作成と実装に関係するプロセスの品質評価の不正確さ。

・既存のプロセスの改善に寄与する標準メカニズムの欠如。

これらの問題により、プログラマーのプロフェッショナルコミュニティは品質保証の分野でより良いソリューションを開発することを余儀なくされ、1990年代初期に多くの新しい標準と方法論が作成されました。 最も成功し意味のある標準の例は、Capability Maturity Model（CMM）およびISO / IEC 15504（SPICE）です。

能力成熟度モデル

CMM Capability Maturity Modelの公式の歴史は通常、「ソフトウェア開発プロセスの成熟度モデル」として翻訳されますが、「機能を改善するためのモデル」の意味はより正確です。 カーネギーメロン大学にある米国ソフトウェア工学研究所SEIがこの標準の最初のバージョンを発行した1991年に始まります。

この標準の最初の目標は、米国の大規模な政府機関が最適なソフトウェアベンダーを選択できる方法論を作成することでした。 これを行うために、ソフトウェア開発プロセスとそれらのさらなる改善のための方法を評価する方法の徹底的な説明を作成することになっていた。 その結果、著者は、既存のプロセスの改善を望む通常の開発会社に標準が適していることが判明したほどの詳細度と詳細度を達成することができました。

SMMモデルの基本概念は、開発会社の成熟度です。 ソフトウェア開発プロセスが特定の実行者と管理者のみに依存している組織は未熟であると見なされ、多くの場合、決定は単に「外出先で」即興で行われます。 その結果、予算を超過したり、プロジェクトの完了期限が中断したりする可能性が高くなります。

それどころか、成熟した企業には、プロジェクト管理とソフトウェア製品の構築のための明確な手順があります。 必要に応じて、これらの手順は洗練され開発されます。 開発時間とコストの見積もりは、経験に基づいて正確です。 同社は、ソフトウェアの開発、テスト、実装のプロセス、および顧客とのやり取りのプロセスに関する基準を持っています。 最終的なプログラムコード、コンポーネント、インターフェイスなどを設計するためのルールを明確に定義しています。 これはすべて、高品質のソフトウェア開発を提供する環境を作成します。

標準は全体として、組織の成熟度を評価するための基準と、既存のプロセスを改善するためのレシピで構成されていると言えます。 ISO 9001ではプロセスの特定の最小レベルの組織を達成するために必要な条件のみが定式化されており、さらなる改善のための推奨事項はないため、ISO 9001で採用されたモデルとは根本的な違いがあります。

CMMは、組織の成熟度の5つのレベルを定義します。 認定の結果、会社には特定のレベルが割り当てられ、将来的には増加または（理論的に）減少する可能性があります。 図3.2は、さまざまなレベルの組織の成熟度を達成するために実装が必要ないくつかのテクノロジを示しています。 次の各レベルには、前のレベルのすべての主要な特性が含まれていることに注意してください。

図 3.2。 CMMモデルの5つの成熟レベル。

初期レベルは、次のレベルと比較するための基準として規格に記載されています。 開発会社が組織の初期レベルにいる場合、実際には、高品質のソフトウェアを作成するための安定した条件はありません。 プロジェクトの結果は、マネージャーの個人的な資質とプログラマーの経験に完全に依存し、同じマネージャーとプログラマーが次のプロジェクトに割り当てられた場合にのみ、1つのプロジェクトの成功を繰り返すことができます。 さらに、そのようなマネージャーまたはプログラマーが会社を辞めた場合、彼らの退任に伴い、生産されるソフトウェア製品の品質は急激に低下します。 ストレスの多い状況では、開発プロセスはコードの記述とその最小限のテストに限定されます。

反復可能なレベルを実現するには、プロジェクト管理テクノロジーを企業に実装する必要があります。 同時に、プロジェクトの計画と管理は蓄積された経験に基づいており、開発中のソフトウェアには標準があり（これらの標準への準拠が保証されています！）、特別な品質保証グループがあります。 適用された計画および管理ツールにより、以前に達成された成功を繰り返すことができます。 必要に応じて、組織は下請業者と対話できます。 ただし、危機的な状況では、プロセスは初期レベルにスライドする傾向があります。

その後、一定のレベルに従います。これは、ソフトウェアの作成および保守の標準プロセスが文書化されているという事実によって特徴付けられます（ソフトウェア開発およびプロジェクト管理を含む）。 標準化プロセスでは、最も効果的なプラクティスとテクノロジーへの移行があることが理解されています。 このような標準を作成および維持するには、組織は特別なグループを作成する必要があります。 最後に、このレベルを達成するための前提条件は、企業の従業員の継続的な専門能力開発とトレーニングのプログラムの存在です。 このレベルから始めて、組織は特定の開発者の個人的および専門的な資質に依存することをやめ、ストレスの多い状況で1レベル下にスライドする傾向はありません。

管理レベルでは、ソフトウェア製品とプロセス全体の両方について、定量的な品質指標が組織に設定されます。 これにより、より正確なプロジェクト計画と結果の品質管理が可能になります。 前のレベルとの主な違いは、製品とプロセスのより客観的で定量的な評価です。 したがって、さまざまなプロジェクト指標の偏差を減らすことにより、より高度なプロジェクト管理が実現されます。 同時に、特によく発達した地域では、プロセスパフォーマンスの有意な変動をランダムな変動（ノイズ）と区別することができます。

最後に、最適化レベルは、既存のプロセスだけでなく、新しい技術の導入の有効性を評価するためにも改善策が適用されるという事実によって特徴付けられます。 このレベルの組織全体の主な目的は、既存のプロセスを継続的に改善することです。 同時に、プロセスの改善は、潜在的なエラーや欠陥の防止に理想的に役立つはずです。 さらに、コンポーネントの作成や再利用などにより、ソフトウェア開発のコストを削減するための作業を行う必要があります。

SMMの各レベルは、キープロセスの領域（OKP）によって特徴付けられ、後続の各レベルには、以前のレベルのすべての特性が含まれると考えられています。 つまり、3番目の成熟レベルでは、3番目のレベルのOKP、2番目のレベルのOKP、および1番目のレベルのOKPが考慮されます。 主要プロセスの領域は、共同で実行されると、特定の目標セットの達成につながるプロセスによって形成されます。 OKPのすべての目標が達成された場合、会社はこの成熟度レベルの証明書を授与されます。 少なくとも1つの目標が達成されない場合、会社はこのレベルのSMMを達成できません。

認証時に、すべての主要分野の適合性評価が10段階で実施されます。 この重要な分野の認定を成功させるには、少なくとも6ポイントを獲得する必要があります。 重要な分野の評価は、次の指標に基づいています。

類似文書

顧客とソフトウェア開発者間の相互作用のスキーム。 ソフトウェアの品質と、現在の段階での評価の主な基準の定義、ライフサイクルの段階での管理機能、十分性の分析。

プレゼンテーション、2013年8月14日追加


実際の情報技術システムを実装する際にSDLC（ソフトウェア開発ライフサイクル管理）方法論を使用するタスクの実現。 出展者の自動登録システムを導入するプロジェクトの説明。

要約、2010年9月10日に追加


ソフトウェアの概念、その開発と使用の問題。 システムソフトウェアの一般的な特性とオペレーティングシステムの動作。 ソフトウェア開発管理プロセスとその機能の詳細。

2011年8月23日追加の学期論文


複雑なシステムの開発、取得、実装の主なプロセス。 ISO 9000ファミリーファミリ成熟した未熟なソフトウェア開発組織。 コンピュータプログラムを評価するためのメトリックの形成の主な方向。

論文、2012年11月27日追加


SMSS用の最新のソフトウェア開発ツール。 ユニバーサルプログラミング言語とSCADAシステムとの比較。 マルチチャンネル測定トランスデューサを使用したソフトウェア開発Ш9327。

論文、2011年7月13日追加


技術仕様の開発の段階。 構造的アプローチによるソフトウェア仕様。 チャートツリー、ネットワークデータモデルの基本概念。 ユーザーインターフェイスデザイン。 画面形式に基づいた対話用のスクリプトの開発。

学期論文、2012年6月24日追加


ソフトウェアエンジニアリングの目標と目的。 ソフトウェアの概念。 ソフトウェアを効果的に使用するための6つの原則。 ソフトウェアの種類：システム全体、ネットワーク、アプリケーション。 ソフトウェア構築の原則。

学期末レポート、2010年6月29日追加


ソフトウェア開発の基本原則：その古典的なライフサイクル、プロトタイピング、設計戦略、開発プロセスの品質モデル。 並列アルゴリズムとCASEシステムの適用、それらの有効性を評価するための基準。

2015年7月7日追加の学期論文


ソフトウェアの脅威の主な種類を調査する。 ソフトウェア保護の最も効果的な手段と方法の特定。 彼らの長所と短所の分析。 ライセンスおよび特許ソフトウェアの機能の説明。

学期論文、2013年5月29日追加


ソフトウェアプロジェクトの段階の実装の一般的なスケジュール。 従来のカスケードモデルに従った開発シーケンス。 Boheによるスパイラルモデルの進捗状況の画像。 製品仕様、WBS構造。

ソフトウェア品質   -要件への準拠の程度としてのソフトウェア（ソフトウェア）の特性。 さらに、要件は非常に広く解釈できるため、多数の独立した概念の定義が生じます。 最も一般的に使用される定義はISO 9001であり、品質は「固有の特性が要件に準拠する度合い」です。

ソースコード品質

コードの品質は、さまざまな基準によって決定できます。 それらのいくつかは、人間の観点からのみ重要です。 たとえば、プログラムテキストの書式設定方法はコンピューターにとってまったく重要ではありませんが、その後のメンテナンスでは非常に重要です。 言語固有の規則を定義し、コードの読みやすさを向上させる多数のルールを設定する既存のコード設計標準の多くは、デバッグや更新を含む将来のソフトウェアメンテナンスを容易にすることを目的としています。 コードが「適切に」記述されているかどうかを判断する基準は他にもあります。たとえば、構造性（コードが管理可能な複数のブロックに論理的に分割される程度）などです。

• コードの読みやすさ
• サポート、テスト、デバッグ、バグ修正、変更、移植性の容易さ
• 低いコードの複雑さ
• 低リソース使用率：メモリとCPU時間
• 正しい例外処理
• コンパイルおよびリンク時の少数の警告

コード品質を改善する方法：リファクタリング。

品質要因

ソフトウェア品質係数は、プログラムの非機能要件であり、通常は顧客との契約には記載されていませんが、それでもプログラムの品質を向上させる望ましい要件です。

品質要因の一部：

理解ソフトウェアの目的は、プログラム自体とドキュメントから明確でなければなりません。 完全性プログラムのすべての必要な部分を提示し、完全に実装する必要があります。 簡潔さ冗長な重複情報の欠如。 コードの重複部分は、共通のプロシージャの呼び出しに変換する必要があります。 ドキュメントについても同じことが言えます。 移植性異なるアーキテクチャ、プラットフォーム、オペレーティングシステム、またはバージョンなど、異なる環境にプログラムを簡単に適合させることができます。 一貫性プログラム全体およびドキュメントでは、同じ規則、形式、表記法を使用する必要があります。 保守性新しい要件を満たすためにプログラムを変更することはどれほど困難ですか。 また、この要件は、プログラムが適切に文書化されており、混乱しすぎず、リソース（メモリ、プロセッサ）の使用のための成長予備があることを示しています。 テスト容易性プログラムは、受け入れ特性を確認できますか、パフォーマンスを測定することは可能ですか。 ユーザビリティプログラムのシンプルさと使いやすさ。 この要件は、主にユーザーインターフェイスに適用されます。 信頼性、プログラム作業における障害と誤動作の欠如、および欠陥とエラーの修正の単純さ：構造化された効率プログラムがタスクを実行するときのリソース（メモリ、プロセッサ）との合理的な関係。 安全性

ユーザーの視点から

ソフトウェアの品質に関する技術的な見解に加えて、ユーザーの観点からの品質評価もあります。 使いやすさという用語は、品質のこの側面に時々使用されます。 特定のソフトウェア製品のユーザビリティ評価を取得することは非常に困難です。 評価に影響する最も重要な問題：

• ユーザーインターフェイスは直感的ですか？
• 簡単で頻繁な操作はどれくらい簡単ですか？
• 複雑な操作はどれくらい簡単ですか？
• プログラムは明確なエラーメッセージを出しますか？
• プログラムは常に期待どおりに動作しますか？
• ドキュメントはありますか？
• ユーザーインターフェイスは自己記述的/自己文書化ですか？
• プログラムの応答遅延は常に許容されますか？

こちらもご覧ください

参照資料

ウィキメディア財団。 2010年。

他の辞書にある「ソフトウェア品質」をご覧ください。

ユーザーが受け取りたい特性に仕様が集中している場合、その仕様を確認するソフトウェア製品の能力。 関連項目：ソフトウェア品質金融ソフトウェア... ... 金融語彙

グレイス・ホッパーがハーバード大学のハーバードマークIIコンピューターで作業していたとき、同僚はこのほくろがリレーに引っかかっており、デバイスの操作を妨害していることを発見し、その後システムを「デバッグ」していることに気づきました... ... Wikipedia

ソフトウェア開発ソフトウェア開発プロセスプロセスステップ分析プログラミングドキュメントの設計…Wikipedia

ソフトウェア開発（英語のソフトウェアエンジニアリング、ソフトウェア開発）は、アクティビティ（職業）の一種であり、ソフトウェアを使用してソフトウェアの作業能力、品質、および信頼性を作成および維持することを目的としています。

  -「ソフトウェアの危機」とは、コンピューターの計算能力の急速な増加の結果と、彼らの助けを借りて解決できる問題の複雑さを説明するためにコンピューターサイエンスでかつて使用された用語です。 本質的に、これは... ...ウィキペディア

新しいエアバスA 380は、かなりのソフトウェアを使用して、飛行機のモダンなキャビンを作成します。 ソフトウェアエンジニアリング手法により、数百万行に及ぶ飛行機ソフトウェアの作成が可能になりました...ウィキペディア

さまざまなハードウェアプラットフォームまたはさまざまなオペレーティングシステムで実行するソフトウェアの機能。 同義語：ソフトウェアの移植性参照：ソフトウェア品質のオープンシステム... ... 金融語彙

ソフトウェア製品の特性：初期データを準備し、ソフトウェア製品を使用して結果を評価するユーザーの労力を最小限に抑え、ポジティブな感情を呼び起こすことができます... ... 金融語彙

変更を加える労力を最小限に抑えるためのソフトウェア製品の特性：エラーを排除する。 または、ユーザーのニーズの変化に応じて変更します。 関連項目：ソフトウェア品質... ... 金融語彙

一連の機能を実行するソフトウェア製品の機能：外部記述で定義されます。 ユーザーの特定または暗黙のニーズを満たす。 同義語：ソフトウェアの相互運用性関連項目：品質... ... 金融語彙

本

• The Perfect Code：A Practical Guide to Software Development、McConnell S. 10年以上にわたり、この本の初版は、最も実用的なプログラミングガイドの1つと見なされてきました。 現在、この本は最新のトレンドとテクノロジーを考慮して完全に更新されています...

質の高いソフトウェアとは何かについて意見を述べるように人々のグループに依頼すると、次の答えが得られます。

• 使い方は簡単です。
• いいね 性能.
• エラーはありません。
• クラッシュ時にユーザーデータを損なうことはありません。
• さまざまなプラットフォームで使用できます。
• 1日24時間、週7日稼働できます。
• 新しい機能を簡単に追加できます。
• ユーザーのニーズを満たします。
• 十分に文書化されています。

これらはすべて、ソフトウェアの品質に直接関係しています。 しかし、これらの回答は、特定のユーザー、開発者、またはそのような個人のグループにとって重要な特性を強調しています。 すべての関係者（エンドユーザー、顧客、開発者、それが機能するシステムの管理者、規制機関など）のニーズを満たすために、市場で開発されたソフトウェアの強力な地位を獲得し、開発の可能性を高めるために、ソフトウェア特性の全体を考慮する必要があります すべての利害関係者にとって重要です。

上記の回答は、ソフトウェアの品質が広範囲の異種特性によって記述できることを示しています。 複雑な概念を記述するこのアプローチは、 全体的な   （ギリシャ語の単語????、全体から）。 提起された問題に対処するための単一の概念的基盤を提供するものではありません。 全体的なシステム   アイデア（たとえば、物理学のNtonian力学やチューリングマシンに基づく古典的な計算可能性理論）が、少なくとも重要なものを見逃さないようにします。

経済のすべての部門で生産プロセスの品質を確保するための一般原則は、ISO 9000規格のセットによって管理されています。 ソフトウェア開発の最も重要な標準は次のとおりです。

• ISO 9000：2000品質管理システム-基礎と語彙 .

  品質管理システム-基礎と辞書。 （アナログ-GOST R-2001）。

• ISO 9001：2000品質管理システム-要件。 設計、開発、生産、設置、サービスの品質保証のためのモデル .

  品質管理システム-要件。 設計、開発、商業化、設置、保守の品質保証のためのモデル。

  すべてのライフサイクルプロセスで結果の品質を確保するための一般的なルールを定義します。 （アナログ-GOST R-2001）。

  • この標準は、次のプロセスを区別します。
    • 品質管理。
    • リソース管理。
    • 管理システムの開発。
    • 市場調査。
    • 製品デザイン。
    • 買収。
    • 生産。
    • サービスの提供。
    • 製品の保護。
    • 顧客の評価が必要です。
    • 顧客とのコミュニケーションをサポートします。
    • 内部コミュニケーションのサポート。
    • ドキュメント管理。
    • 活動の記録を保持します。
    • 計画中。
    • スタッフのトレーニング。
    • 内部監査。
    • 経営評価。
    • 監視および測定。
    • 不適合管理。
    • 継続的な改善。
    • システム全体の管理と開発。
  • プロセスごとに、少なくとも次のセクションで構成されるプロセスの開発計画が必要です。
    • プロセス設計。
    • プロセスの文書化。
    • プロセスの実装。
    • プロセスのサポート。
    • プロセス監視。
    • プロセス管理。
    • プロセスの改善。
  • 顧客とユーザーのニーズを満たすことを目的としたプロセスのシステムのサポートと開発に加えて、

実行される機能の責任を増大させる一方で、最新のソフトウェアシステムの複雑さとサイズの急速な増加により、顧客とユーザーの品質と使用の安全性に対する要件が急激に増加しました。 プログラムとソフトウェアシステムの機能の高い効率と品質を保証する実証済みの手段は、業界の主要企業の代表者が参加して開発された国際標準です。

情報システムのアプリケーションと複雑さが拡大するにつれて、エラーが発生したり、プログラムやデータの品質が不十分だったりして、使用によるプラスの効果を大幅に超える損害を引き起こす可能性のある領域が特定されました。

多くの場合、情報システムの必要な機能と品質特性に関する顧客と開発者の非公式の表現に基づいて、情報システム用の複雑なソフトウェアツールとデータベースを作成するための契約と予備計画が無条件に作成および評価されます。 必要な品質指標の決定、ソフトウェアツールの作成の複雑さ、コスト、期間の評価における重大なシステムエラーは、かなり大きな現象です。 多くの情報システムは、品質が保証された完全に必要な機能タスクを実行することができず、長時間の変更が必要になる場合があります。必要な品質と操作の信頼性を達成するには、さらに多くの時間と費用がかかります。 その結果、多くの場合、情報システムのプロジェクトは、最初に宣言された品質特性の目的と要件に対応せず、スケジュールと開発予算に適合しません。

情報システムの参照プロジェクトおよび実装プロジェクトに関しては、ソフトウェア製品の品質の概念と価値に関する情報、それらが記述されている特性、測定方法、契約に反映されている要件との比較方法に関する情報、参照条件または仕様は、多くの場合黙っていないか、形式化が不十分です。 さらに、ソフトウェアツールの要件にはいくつかの特性が欠けていることが多く、テスト中に任意のアカウンティングや省略が発生します。 概念の文書における曖昧な宣言とソフトウェアの品質の特性に必要な値は、同じ特性の異なる解釈のために、顧客ユーザーと開発者、サプライヤーの間で競合を引き起こします。 この点で、現代の情報システムのライフサイクルにおける戦略的タスクは、ソフトウェアとデータベースの必要な品質を確保することでした。

過去数年にわたって、ソフトウェアとデータベースのライフサイクルのプロセスと製品を規制する多くの国際標準が作成されました。 これらの標準の適用は、ソフトウェア品質保証システムの基礎として機能しますが、標準の一部の規定は、このタイプの製品の技術および特性の基本的な特徴に適用されるように調整、適合、または削除する必要があります。 同時に、多くの顧客は、設計技術、生産、および製品品質が現代の国際基準に準拠することを要求しています。これは、世界市場で製品の競争力を確保するためにマスターおよび適用する必要があります。

品質標準化

ソフトウェア品質保証の最も重要な問題の1つは、品質特性の定式化と評価の方法論です。 機能の品質の妥当性、相互作用、改善、開発のためのソフトウェアの技術的能力の可用性を判断するには、その品質の特性を評価する分野で標準を使用する必要があります。 以前は、国際規格ISO 9126：1991（GOST R ISO / IEC 9126-93）「情報技術。ソフトウェア製品の評価。アプリケーションの品質特性とガイドライン」は、ソフトウェア品質指標の規制の基礎でした。 開発は完了しており、4部構成の標準ISO 9126-1-4の最後のドラフトは、1991年の小規模版に代わるものとして正式化されています。 プロジェクトは、一般的な見出し「情報技術-ソフトウェア品質の特性とメトリック」の下の次の部分で構成されています。「パート1.品質の特性とサブ特性」パート2.外部品質メトリック「パート3.内部品質メトリック」「パート4.品質メトリック 使用中です。」

ロシアでは、複雑なソフトウェアコンプレックスのライフサイクルと品質を保証する分野で、世界レベルから5〜10年遅れている古いGOSTのグループが主に使用されています。

標準の最初の部分-ISO 9126-1-は、標準の残りで使用される6つの特性によってソフトウェア品質の属性を配布します。 それらを測定する基本的な可能性に基づいて、すべての特性を3つのグループにまとめることができます。これらのグループには、異なるカテゴリのメトリックが適用されます。

• カテゴリまたは記述（名義）メトリックは、ソフトウェアの機能に最も適しています。
• 定量的メトリックは、複雑なソフトウェアシステムの信頼性と有効性を測定するために適用できます。
• 高品質のメトリックは、ソフトウェアの実用性、保守性、およびモビリティと最も一貫しています。

標準ISO 9126-1の一部では、ソフトウェアの各特性、および品質のサブ特性の残りの部分からの明確化とともに定義が与えられています。

過去数年にわたって、ソフトウェアツールとデータベースのライフサイクルのプロセスと製品を規制する多くのISO標準が作成されており、ソフトウェア製品の品質保証システムの基礎として使用できます。

標準の2番目と3番目の部分（ISO 9126-2およびISO 9126-3）は、それぞれ複雑なソフトウェアツールの品質特性の外部および内部メトリックの形式化に当てられています。 すべてのテーブルには、メトリックの名前と目的を反映した統一されたルーブレーションが含まれています。 その適用方法; 測定方法、メートルスケールの種類; 測定値のタイプ。 測定および比較の初期データ。 およびソフトウェアツールのライフサイクルの段階（ISO 12207に準拠）。これには、メトリックが適用されます。

標準の4番目の部分であるISO 9126-4は、ソフトウェアのバイヤー、サプライヤー、開発者、メンテナー、ユーザー、および品質マネージャーを対象としています。 ソフトウェアの使用範囲（コンテキスト）の選択された指標と、ユーザーの選択されたメトリックのグループを実証し、コメントします。

品質指標の選択

ほとんどの場合、品質指標を選択する際の初期データと最優先事項は、対応するソフトウェアの目的、機能、機能の適合性です。 これらのプロパティの十分かつ完全な説明は、他のほとんどの特性と品質属性の値を決定するための基礎として役立つはずです。 品質特性の属性値の測定の基本的および技術的能力と精度は、その内容に応じて常に制限されます。 これは、常識に基づいて選択できる各属性の値の合理的な範囲を決定するだけでなく、実際のプロジェクトの要件の仕様の前例を分析することによって決定します。

ソフトウェアの品質特性を記述するためのメトリックとスケールを選択および確立するプロセスは、2つの段階に分けることができます。

• ソフトウェアプロジェクトとその消費者のライフサイクルの一般的な特徴と段階を反映する初期データセットの選択と正当化。これらはそれぞれ、プログラムパッケージの品質の特定の特性に影響を与えます。
• プロジェクトの特性と品質属性を測定するための特定のメトリクスとスケールの選択、確立、承認。その後の評価と、ソフトウェアツールのライフサイクルの特定の段階での認定テストまたは認証のプロセスにおける仕様の要件との比較。

最初の段階では、ISO 9126で標準化された特性、サブ特性、および属性の基本的な命名法全体を基礎とする必要があります。特定のソフトウェアプロジェクトの目的と範囲を考慮して、優先度によって説明を優先することをお勧めします。 次に、ソフトウェアプロジェクトの品質の特定の指標を必要とする消費者を、その専門性と職業上の関心を考慮して強調表示し、優先順位を付ける必要があります。 初期データの準備は、特定の消費者に対するソフトウェアの機能的適合性を決定する基本的な優先品質指標の範囲を強調することにより完了します。

第2段階では、品質評価の消費者が実行する必要がある初期データを修正した後、アイテムとメトリックを選択するプロセスは、特定のプロジェクトとその消費者の特性とサブ特性のランク付けから始まります。 さらに、選択した各指標のこれらの専門家は、プロジェクトと分析結果の消費者のサブ特性とその属性を評価するためのメトリックとスケールを確立し、合意する必要があります。 定性的特徴によって表される指標については、この特性がソフトウェアツールに実装されていると見なされるべき条件の仕様記述を定義および修正することが望ましい。 品質特性とその属性の選択された値は、特定のプロジェクトの利用可能なリソースを考慮に入れ、必要に応じて調整され、実行可能性について開発者が事前に確認する必要があります。

品質評価

6つの部分で構成される国際標準ISO 14598は、ライフサイクルのさまざまな段階で完成したソフトウェアとそのコンポーネント（ソフトウェア製品）の品質特性を評価する方法論と標準化に当てられています。 プログラムの品質特性を評価するプロセスの次の一般的な概要が推奨されます。

• 評価の初期要件の設定-テストの目的の決定、ソフトウェアメトリックの種類の識別、適切な指標と品質属性の必要な値の強調
• 品質指標の選択、副特性と属性の指標の評価と優先度の設定、検査と測定の基準の選択。
• ソフトウェアツールのライフサイクルにおける品質の特性と属性を評価するためのプロセスの計画と設計。
• 評価するために測定を行い、結果を基準および要件と比較し、結果を要約して評価します。

品質特性ごとに、必要な許容値と不満足値を強調してメジャーと測定スケールを策定することをお勧めします。 評価プロセスの実装は、ISO 12207規格の適用可能な適応バージョンに従って、特定のソフトウェアプロジェクトのライフサイクルの段階と相関する必要があります。

機能的適合性   -最も曖昧で客観的に困難なサブ特性ソフトウェアの評価。 プログラム複合体のアプリケーション、命名法、および機能の分野は、さまざまなプログラム複合体でこのサブ特性を評価および比較するための少数の属性を選び出し、統一することが不可能な人間活動の多様な領域をカバーしています。

ソフトウェアの正確性評価   実装されたプログラムの複合体が、契約の初期要件、技術仕様、およびソフトウェアとそのコンポーネントの仕様に適合している度合いを正式に決定することで構成されます。 検証により、プログラム複合体のコンポーネント全体の初期要件、プログラムおよびデータ記述のモジュールおよびテキストまでのコンプライアンスを決定する必要があります。

相互運用性評価   は、ソフトウェアコンポーネントとデータベースと他のアプリケーションシステムやさまざまなコンピューティングプラットフォーム上のコンポーネントとのコラボレーションの品質を決定することと、同様の機能を持つコンピューティングシステム間での移動に便利なスタイルでユーザーと対話することです。

ソフトウェアセキュリティ評価 潜在的な脅威からソフトウェアを保護する利用可能な方法と手段の使用の完全性、および達成された情報システムの機能のセキュリティの決定を含む。 情報システムの統合保護を評価するための最も広く詳細な方法論的および体系的なタスクは、標準ISO 15408の3つの部分で定められています。1999-1-3「セキュリティを確保する方法と手段。情報技術のセキュリティを評価する基準」

信頼性評価   -使用中のサブ特性の属性の定量的指標の測定：完全性、欠陥に対する耐性、回復性、可用性/可用性。

メモリとパフォーマンスの要件   問題を解決する過程でのコンピューターは、ソースデータの構成と量によって大きく異なります。 このソフトウェアを使用して情報システムの最大スループットを正確に決定するには、プログラムの機能グループの実行時間の極値と平均値、およびそれらが到達するルートを測定する必要があります。 以前に設計プロセス中にコンピューターのパフォーマンスが評価されなかった場合、多くの改良が必要になるか、コンピューターをより高速のものに交換する必要さえあります。

実用性評価   ソフトウェアツールは専門家によって実施され、ソフトウェアツールの理解度、使いやすさ、学習可能性、魅力を判断することが含まれます。 基本的に、これはポイントの定性的（および主観的）評価ですが、一部の属性は、ソフトウェアを使用する際の操作の複雑さと期間、およびそれらを調査するために必要な文書の量によって定量化できます。

護衛   ソフトウェアとそのコンポーネントのステータス、予想されるすべての変更、およびプログラムのバージョンの現在の状態とその開発の履歴を確立できるすべての変更に関するドキュメントの完全性と信頼性を評価できます。 文書を作成、変更、およびプログラムとデータに適用するための戦略、標準、手順、リソース割り当て、および計画を決定する必要があります。

モビリティ評価 -適応性、インストールの容易さ、プログラムの互換性および交換可能性の専門家による定性的決定。ポイントで表されます。 定量的に、ソフトウェアツールのこの特性とその属性の全体性は、経済指標で評価（および適切）できます：コスト、面倒さ、および特定のプログラムとデータのセットを異なるプラットフォームに転送するための手順の実装期間。

品質管理システム

ソフトウェアの特性の選択と品質の評価は、ソフトウェア開発会社が製造する製品の品質を保証する分野のタスクの1つにすぎません。 ソフトウェアの品質を確保するという問題に対する包括的なソリューションは、1つまたは別の品質管理システムの開発と実装を意味します。 世界で最も広く使用されているシステムは、ソフトウェア品質保証を管理する標準（ISO 9000/3）を含む多数のドキュメントを含むISO 9000シリーズの国際標準に基づいています。 これらの標準は、カスタムソフトウェア会社の主要な専門家向けのガイドとして役立つはずです。

品質の特性とサブ特性の定義（ISO 9126-1）

機能性   -特定の条件で一連のプログラムを使用する場合に、顧客とユーザーのニーズによって定式化された問題の解決策を提供するソフトウェアの能力。

機能的適合性   -顧客または潜在的なユーザーの要件の技術仕様および仕様に対応する、ソフトウェアの目的、命名法、基本的、必要かつ十分な機能を決定するサブ特性とその属性のセットと説明。

正しさ（正しさ）   -ユーザーおよび外部効果に対して正しいまたは許容可能な結果を\u200b\u200b提供するソフトウェアの能力。

相互運用性   -内部および外部環境の1つまたは複数のコンポーネントと対話するためのソフトウェアツールとそのコンポーネントのプロパティ。

セキュリティ   -プログラムおよび情報を悪影響から保護するソフトウェアコンポーネントの能力。

ソフトウェア開発は、ライフサイクルのすべての段階で設計結果を評価し、計画された品質指標とそのメトリック分析の達成度を制御し、リスクと完成したコンポーネントの使用度を評価して新しいプロジェクトの開発コストを削減するためにエンジニアリング手法を使用する必要があるほどの開発レベルに達しました。 プログラミングにおける工学的手法の基礎は、ソフトウェアの品質を向上させることですこれを達成するために、品質要件の決定方法、品質指標のメトリック分析のためのモデルの選択と改善へのアプローチ、およびライフサイクルのすべての段階での品質指標の定量的測定方法が形成されました。 ソフトウェアの品質を評価する静的な手法を図に示します。 9.1。 動的な手法は、ソフトウェアテストに何らかの形で関連しています。

品質要件について合意に達し、結果として得られる製品の品質を構成するものについてのエンジニアへの明確なコミュニケーションとともに、多くの側面の議論と正式な定義が必要です。 エンジニアは、開発または保守されているソフトウェアに関する品質の概念の意味、品質の特性および価値を理解する必要があります。 ソフトウェア要件は、ソフトウェアの品質に必要な特性を決定し、定量的評価の方法およびこれらの特性を評価するために策定された対応する受け入れ基準にも影響を与えることに注意してください。

ソフトウェアの品質は標準化の対象です。 GOST 2844-94によると ソフトウェア品質   ソフトウェアには、目的に応じて顧客のニーズを満たす能力を提供する一連のプロパティ（品質インジケータ）があります。 この規格は、基本的な品質モデルと指標を規制していますが、その主なものは信頼性です。 標準180 / 1ES12207が定義されています

図 9.1。

lCソフトウェア開発の主要プロセスだけでなく、エンジニアリング、計画、ソフトウェア品質管理を管理する組織的および追加のプロセスも共有しました。

この標準によれば、ソフトウェア開発のライフサイクルのすべての段階で、次のソフトウェア品質管理を実行する必要があります。

•   設計されたソフトウェア製品の要件とその達成基準に対するコンプライアンスの検証。
•   ライフサイクルの段階でのソフトウェアの中間結果の検証と認証（検証）および達成された指標の満足度の測定。
•   完成したソフトウェアのテスト、システムで検出された障害、欠陥、その他のエラーに関するデータの収集。
•   テスト結果（欠陥、故障など）に応じて信頼性を評価するための信頼性モデルの選択。
•   ソフトウェア開発の要件で指定された品質指標の評価。

品質検査-   開発チームに焦点を合わせた品質管理プロセスです。 ソフトウェア開発のすべての段階で使用されます。

正当性の証明- プログラムがすべきことを自分自身や他の人に説得するために使用される数学的または論理的な手法です。 このような証明は、正式な（厳密な）方法です。

エンジニアリング製品には、品質に関する多くの解釈があります。 品質指標は、ある程度必要とされるか、存在しないか、消費者やその他の利害関係者の特定の要件を反映する場合があり、特定の妥協の結果である場合があります（「許容可能な品質」の理解と一致しており、優れた品質を達成するための品質保証の観点はそれほど厳格ではありません）。

品質のコスト   欠陥防止コスト、評価コスト、内部障害と外部障害のコストで区別できます。 ソフトウェアプロジェクトの背後にある推進力は、特定の価値を持つソフトウェアを作成することです（特定の問題を解決したり、目標を達成したりすることを意味します）。 ソフトウェアの価値は、価値の形式または他の形式で表現できます。 顧客は通常、最大コストの投資について独自の考えを持っています。ソフトウェアを作成するという主要な目標が達成された場合、その投資の見返りが期待されます。 また、顧客はソフトウェアの品質に関して一定の期待を持っているかもしれません。 顧客は品質の問題と関連コストについて考えない場合があるため、この段階での議論の主題は、特定レベルの品質の達成に関連するコストと利点、および顧客が意思決定プロセスに関与する度合いについて顧客が完全に理解することの問題かもしれません。 理想的なケースでは、これらの決定の大部分は要件を伴う作業の段階で行われるべきですが、これらの問題はLCソフトウェア全体で提起される可能性があります（そしてそうすべきです）。 そのような決定を行う方法に関する「標準」ルールはありません。 ただし、エンジニアは、さまざまなレベルの品質とコストを達成する方法のさまざまな選択肢を提示できる必要があります。

ソフトウェアの品質は、その使用の実際の条件を考慮した場合にのみ意味をなす相対的な概念であり、品質の要件はこれらの条件およびアプリケーションの特定の領域と相関させる必要があります。

ソフトウェアの品質は、ソフトウェアの品質、ライフサイクルプロセスの品質、保守または実装の品質という3つの側面によって特徴付けられます（図9.2）。

品質品質品質

製品サポートプロセス

図 9.2。

関連する側面 ライフサイクルソフトウェアプロセス、 形式化の程度、ソフトウェア開発自体のライフサイクルプロセスの信頼性、およびこれらのプロセスの中間結果の検証と検証（簡単に-V＆V）を決定します。 完成したソフトウェアのエラーの検索と除去は、エラーの数を減らし、この製品の品質を向上させるテスト方法によって実行されます。

PP品質   ライフサイクルのすべての段階で中間製品の管理手順を使用し、それらをチェックして必要な品質を達成すること、およびソフトウェア追跡方法を使用することにより達成されます。 実装の効果   ソフトウェアツールは、製品機能のスタッフの知識とその実装のルールに大きく依存しています。

ソフトウェア品質モデル4つのプレゼンテーションレベルがあります。

最初のレベル   ソフトウェア品質の特性（インジケータ）の定義に対応します。各特性は、品質に関するユーザーの個別の視点を反映しています。 既存の標準（ISO / IEC9126、DSTU 2844-1994、DSTU 2850-1994、DSTU 3230-1995）によると、品質モデルには6つの特性または 六つの品質指標   （図9.3）：機能性（機能性）、信頼性（現実性）、利便性（使いやすさ）、効率（効率性）、保守性（持続性）、移植性（移植性）。

に セカンドレベル   さまざまな側面を詳述する特定の品質特性ごとに属性を定義します。 これらの属性のセットは、ソフトウェアの品質の評価に使用されます。

第三レベル   品質を測定するように設計されています 指標   標準の1SO / IEC9126によると、それぞれは、属性の測定方法とその値を測定するためのスケールの組み合わせとして定義されています。 LCソフトウェアの段階で品質属性を評価するために（文書やプログラム、およびプログラムのテスト結果を表示する場合）、特定の

性能特性

属性

特定の指標と品質全体の集約属性のメトリック分析の結果を平準化するための重み。 品質属性は、LCソフトウェアの段階および開発の最終段階で1つ以上の評価方法を使用して決定されます。

に 第四レベル   個々の属性の定量的または定性的な値を評価するために、メトリックの評価要素である重みが使用されます。 ソフトウェア保守の目的、機能、条件に応じて、最も重要な品質特性とその属性が選択されます（図9.3を参照）。

選択した属性とその優先順位は、システムの開発要件に反映されるか、このソフトウェアが属するソフトウェアクラスの標準の対応する優先順位が使用されます。

もっと詳しく考えてみましょう ソフトウェア品質指標。

機能性これは、処理要件およびシステム全体のツールの要件に従って、特定の環境で機能のリストを実行するソフトウェアの能力を決定する一連のプロパティです。 関数は、ソフトウェアの消費者特性を満たすためのアクションの順序付けられたシーケンスとして理解されます。 機能はターゲット（プライマリ）および補助です。 機能に関連する属性は次のとおりです。

機能の完全性   -ソフトウェアコンポーネントのプロパティ。ソフトウェアの目的に応じて問題を解決するための基本機能の妥当性の程度を示します。

正しさ （精度）   -正しい結果が達成された度合いを示す属性。

相互運用性-   特殊なシステムおよび環境（OS、ネットワークなど）上のソフトウェアコンポーネント間の相互作用の可能性を示す属性。

セキュリティ-   プログラムおよびデータへの不正アクセス（偶発的または意図的）を防止するソフトウェアの能力を決定する属性。

信頼性これは、ソフトウェアの寿命の期間に依存する条件下でソースデータを結果に変換するソフトウェアの能力を決定する属性のセットです（磨耗および老化はカウントされません）。 ソフトウェアの信頼性の低下は、要件、設計、および実行のエラーにより発生します。 プログラムの失敗とエラーは、特定の時間間隔で表示されます。

ソフトウェアの信頼性のサブ特性（サブ特性）には、次のものが含まれます。

信頼性-   （プログラムとハードウェアの両方の）障害なしに機能するソフトウェアの能力を決定する属性。

許容誤差   -異常な状態（ハードウェア障害、データとインターフェースのエラー、オペレーターのアクションの違反など）で機能を実行するソフトウェアの能力を示す属性。

回復性-   ソフトウェアが再起動してデータを再実行し、障害から回復する能力を示す属性。

高い信頼性（エラーの許容性、精度、信頼性、使いやすさなど）を確保するには、いくつかの種類の「クリティカルシステム」（リアルタイム、レーダー、セキュリティシステム、通信など）が必要です。 ソフトウェアの信頼性は、ライフサイクルの各段階での開発中に残っている未解決のエラーの数に大きく依存します。 操作中にエラーが検出され、除去されます。 エラーの修正中に新しいエラーが導入されない場合、または少なくとも新しいエラーが排除されるよりも少ない場合、動作中にソフトウェアの信頼性が継続的に向上します。 操作が集中的に実行されるほど、エラーがより集中的に検出され、ソフトウェアの信頼性がより速く向上します。

次の要因がソフトウェアの信頼性に影響します。

•   システムまたはその動作環境への悪影響と損害をもたらす脅威の全体。
•   システムセキュリティ違反の兆候としての脅威。
•   安定性を維持し、リスクがないシステムの能力としての整合性。

検出されたエラーは、外部の脅威または障害の結果である可能性があり、リスクを高め、システムの信頼性の一部の特性を低下させます。

信頼性は現代のソフトウェアシステムの重要な問題の1つであり、コンピューターシステムの品質に対する要件が絶えず増大するにつれて、その役割は絶えず増大しています。 新しい方向- ソフトウェア信頼性工学（ソフトウェア信頼性エンジニアリング）-信頼性の高いシステム運用を期待しているユーザーに関連するシステムコンポーネントの動作挙動の定量的研究に焦点を当てており、次の側面が含まれています。

信頼性測定、つまり 予測を使用した定量的評価の実施、システムの動作に関するデータの収集

動作中、および信頼性の最新モデル。

• 戦略と指標   既製のコンポーネントの設計と選択、コンポーネントシステムの開発プロセス、およびシステムの信頼性に影響を与える機能環境。
•   現代の応用 検査方法, 検証, 検証とテスト   システムの開発中および運用中。

検証   完成したソフトウェアが確立された仕様に準拠しているかどうかを判断するために使用されます。 検証-   顧客から提示されたユーザー要件へのシステムのコンプライアンスを確立します。

信頼性工学では、用語 適合性 （信頼性）は、要件で指定された機能の品質パフォーマンスに自信があるユーザーにとって望ましいプロパティを持つシステムの能力を示します。 この用語は、システムが所有しなければならない属性の追加数によって決定されます。

•   使用準備（可用性）;
•   連続操作の準備（信頼性）;
•   環境安全、すなわち 障害（安全性）の場合に壊滅的な結果を引き起こさないシステムの能力。
•   情報の機密性と安全性（機密）;
•   システムを維持する能力と、その自然な変化（完全性）に対する抵抗。
•   ソフトウェアの操作能力、メンテナンス操作の実行の容易さ、エラーの除去、エラーが除去された後のシステムの復元（保守性）
•   情報の準備と安全性（セキュリティ）など。システムの信頼性の実現が提供されます。 故障防止   （障害防止）またはその 排除   （障害の除去）、および新しい障害の出現の可能性の評価とそれらに対処するための手段。

確率論的手法は、信頼性を数値的に評価するために使用されます。 各ソフトウェアコンポーネント、その操作、およびデータは、5、28、...などの個別の時点で処理されます bj

間に合わせよう T   最初に失敗したシステムコンポーネントの処理後、式が真である障害が発生した

P（T\u003e n）   \u003d（1-L.）そして、ここで、L。は失敗の確率であり、平均は

待ち時間は等しくなります T \u003d-。

値5が減少し、時間が T   固定されたまま、その後

R（T\u003e t）\u003d

どこで t-   失敗するまでの時間、この場合は指数関数的に分布する連続値。

したがって、ソフトウェアの信頼性を確保することは、ソフトウェア障害に関連する安定したシステムの作成を必要とする面倒なプロセスです。 障害が発生した後のある時点でシステムが自然に回復する十分に高い確率を保証します。

使いやすさ。このインジケータは、特定のユーザーサークルがソフトウェアを使用して対応する結果を取得するために必要な適切な条件（インタラクティブ、非インタラクティブなど）を決定する多くの属性によって特徴付けられます。 標準のDSTU 2850-1994では、使いやすさは、その人間工学を特徴付けるソフトウェアの属性のセットとして定義されています。

• わかりやすさ-   論理的な概念とソフトウェアアプリケーションの条件の認識に費やされる労力を定義する属性。
• 勉強しやすい   （研究のしやすさ）-運用管理、診断、および確立された手順、ドキュメントに記載されている規則を使用して、ソフトウェアの適用可能性の判断に費やしたユーザーの努力を判断する属性。
• 効率-   操作および操作制御を実行するときのシステムの応答を決定する属性。
• 一貫性-   標準、契約、規則、法律、規制の要件に対する開発のコンプライアンスを示す属性。

効率性これは、ソフトウェアの実行レベル、リソースの使用度（手段、機器、材料-印刷デバイス用の用紙など）と定期的な保守要員が実行するサービスとの関係を決定する属性のセットです。 ソフトウェアパフォーマンスの属性は次のとおりです。

• 反応性-   関数の応答時間、処理、実行を示す属性。
• リソース効率-   ソフトウェア機能の実行に使用されるリソースの量と期間を示す属性。
• 一貫性-   属性。指定された標準、規則、規制へのこの属性の準拠を示します。 付随する。これらは、環境、要件、または機能仕様を変更する際のソフトウェアの更新、改善、適応など、変更を行うのに必要な労力を決定するプロパティの多くです。 付随性は、次の属性によって決定されます。
• 分析可能性-   障害を診断したり、修正される部品を特定するために必要な努力を定義する属性。
• 可変性-   ソフトウェアのエラーを除去または変更してエラーを排除する能力、およびソフトウェアまたは動作環境に新機能を導入する能力を決定する属性。
• 安定性-   構造の不変性とその変更のリスクを示す属性。
• テスト容易性-   要件の違反、およびソフトウェアとその認証を変更する必要性を検出するための、ソフトウェアの検証と検証中の作業を定義する属性。
• 一貫性-   属性。この属性が標準の規則、規則、規制に準拠していることを示します。 移植性。これらは、ランタイム環境の新しい条件で動作するようにソフトウェアが適応する能力を決定する多くの指標です。 環境は、組織、ハードウェア、およびソフトウェアにすることができます。 新しいランタイム環境へのソフトウェアの転送は、新しいソフトウェア、組織、および技術的な能力を考慮に入れて、作成された環境以外の環境で機能することを目的とした一連のアクションに関連付けられます。 移植性には次の属性が含まれます。
• 順応性   -さまざまな環境への適応に費やされる努力を定義する属性。
• カスタマイズ可能性   （インストールの容易さ）-このソフトウェアを特別な環境で実行するために必要な努力を決定する属性。
• 共存   -現在のシステムの環境で特別なソフトウェアを使用する可能性を決定する属性。
• 交換可能   -必要なソフトウェアのインストールまたは適応を伴う他のプログラムと連携するときに相互運用性の可能性を提供する属性。
• 一貫性-   ソフトウェア移行の標準または契約への準拠を決定する属性。