ソフトウェア構築

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
上のシリーズの一部
ソフトウェア開発
中心活動
パラダイムとモデル
方法論とフレームワーク
分野をサポートする
練習
ツール
知識の基準と体系
用語集
概要

ソフトウェア構築は、ソフトウェアエンジニアリングの分野です。これは、コーディング、検証、単体テスト、統合テスト、およびデバッグを組み合わせて、機能する意味のあるソフトウェアを詳細に作成することです。これは、他のすべてのソフトウェアエンジニアリング分野、最も強力にソフトウェア設計とソフトウェアテストにリンクされています。[1]

ソフトウェア構築の基礎

複雑さの最小化

複雑さを軽減する必要性は、主に、ほとんどの人が複雑な構造や情報を作業記憶に保持する能力が限られていることによって引き起こされます。複雑さの軽減は、巧妙ではなく単純で読みやすいコードの作成を強調することで実現されます。複雑さを最小限に抑えるには、標準を利用し、コーディングにおける多数の特定の手法を使用します。また、建設に焦点を当てた品質技術によってサポートされています。[2]

変化を見越して

変更を予測することは、ソフトウェアエンジニアが拡張可能なソフトウェアを構築するのに役立ちます。つまり、基盤となる構造を破壊することなく、ソフトウェア製品を強化できます。[2] 25年以上にわたる調査によると、やり直しのコストは、最初に要件を正しく満たすよりも10〜100倍（小規模なプロジェクトでは5〜10倍）高くなる可能性があります。平均的なプロジェクトの開発中に要件の25％が変化することを考えると、やり直しのコストを削減する必要性から、変化を予測する必要性が明らかになります。[3]

検証のための構築

検証のために構築するということは、ソフトウェアを作成するソフトウェアエンジニアが、独立したテストや運用活動中に、障害を簡単に突き止めることができるようにソフトウェアを構築することを意味します。検証のための構築をサポートする特定の手法には、コードレビューをサポートするためのコーディング標準に従うこと、単体テスト、自動テストをサポートするためのコードの編成、複雑または理解しにくい言語構造の使用制限などがあります。[2]

再利用

体系的な再利用により、ソフトウェアの生産性、品質、およびコストを大幅に改善できます。再利用には、密接に関連する2つの側面があります。[2]

  • 再利用のための構築：再利用可能なソフトウェア資産を作成します。
  • 再利用を伴う構築：新しいソリューションの構築でソフトウェア資産を再利用します。

建設の基準

建設問題に直接影響する、外部（国際機関によって作成された）または内部（企業レベルで作成された）のいずれの基準にも、次のものがあります。[2]

建設の管理

建設モデル

ソフトウェアを開発するために多数のモデルが作成されており、そのうちのいくつかは他のものよりも構築を強調しています。ウォーターフォールや段階的配信のライフサイクルモデルなど、一部のモデルは構築の観点からより線形です。これらのモデルは、建設を、詳細な要件作業、広範な設計作業、詳細な計画など、重要な前提条件の作業が完了した後にのみ発生するアクティビティとして扱います。進化的プロトタイピング、エクストリームプログラミング、スクラムなど、他のモデルはより反復的です。。これらのアプローチは、建設を、要件、設計、計画などの他のソフトウェア開発活動と同時に発生する活動、またはそれらと重複する活動として扱う傾向があります。[1]

建設計画

建設方法の選択は、建設計画活動の重要な側面です。建設方法の選択は、建設の前提条件（たとえば、要件分析、ソフトウェア設計など）が実行される範囲、それらが実行される順序、および建設作業の前に完了すると予想される程度に影響します。始まります。建設計画では、選択した方法に従って、コンポーネントが作成および統合される順序、ソフトウェア品質管理プロセス、特定のソフトウェアエンジニアへのタスク割り当ての割り当て、およびその他のタスクも定義されます。[1]

建設測定

コード開発、コード変更、コード再利用、コード破壊、コード複雑度、コード検査統計、障害修正および障害検出率、労力、スケジューリングなど、多数の建設活動と成果物を測定できます。これらの測定値は、建設の管理、建設中の品質の確保、建設プロセスの改善、およびその他の理由で役立ちます。[1]

実用的な考慮事項

ソフトウェアの構築は、多くの実際的な考慮事項によって推進されます。

建設設計

ソフトウェア設計の予期しないギャップを説明するために、ソフトウェアの構築中に、ソフトウェア設計の詳細を具体化するために、いくつかの設計変更を小規模または大規模に行う必要があります。[4]

低ファンアウトは、研究者によって有益であることがわかった設計特性の1つです。情報隠蔽は、大規模なプログラムで4倍の変更を容易にする有用な設計手法であることが証明されました。[5]

人工言語

人工言語には、人間がコンピューターに対して実行可能な問題の解決策を指定できるすべての形式の通信が含まれます。それらには、構成言語、ツールキット言語、およびプログラミング言語が含まれます：[6]

  • 構成言語は、ソフトウェアエンジニアが、新しいまたはカスタムのソフトウェアインストールを作成するために、事前定義されたオプションの限られたセットから選択する言語です。
  • ツールキット言語は、ツールキットからアプリケーションを構築するために使用され、構成言語よりも複雑です。
  • スクリプト言語は、コンパイルされるのではなく解釈されることが多いスクリプトをサポートする一種のアプリケーションプログラミング言語です。
  • プログラミング言語は、3つの一般的な種類の表記法を使用する最も柔軟なタイプの人工言語です。
    • 複雑なソフトウェア構造を表すために単語のようなテキストの文字列を使用すること、およびそのような単語のような文字列を文のような構文を持つパターンに組み合わせることによって特に区別される言語表記。
    • 単語やテキスト文字列の直感的で日常的な意味に依存するのではなく、正確で明確な正式な（または数学的な）定義に裏打ちされた定義に依存する正式な表記法。
    • 言語と形式の両方の構造のテキスト指向の表記法にあまり依存せず、代わりに、基盤となるソフトウェアを表す視覚エンティティの直接的な視覚的解釈と配置に依存する視覚的表記法。

3年以上使用した言語で作業するプログラマーは、言語に不慣れな同等の経験を持つプログラマーよりも生産性が約30％高くなります。C ++、Java、Smalltalk、Visual Basicなどの高水準言語は、アセンブリやCなどの低水準言語よりも5〜15倍優れた生産性、信頼性、単純さ、および理解性をもたらします。同等のコードは、低水準言語よりも高水準言語で実装されます。[7]

コーディング

ソフトウェア構築コーディングアクティビティには、次の考慮事項が適用されます。[8]

  • ネーミングやソースコードのレイアウトなど、理解しやすいソースコードを作成するためのテクニック。ある調査によると、変数の名前が10〜16文字の場合、プログラムのデバッグに必要な労力は最小限に抑えられます。[9]
  • クラス、列挙型、変数、名前付き定数、およびその他の同様のエンティティの 使用：
    • NASAが行った調査によると、コードを適切に因数分解されたクラスに入れると、機能設計を使用して開発されたコードと比較して、コードの再利用性が2倍になる可能性があります。[10] [11]
    • ある実験では、配列にランダムにではなく順次アクセスする設計では、変数と変数参照が少なくなることが示されました。[12]
  • 制御構造の使用：
    • ある実験では、exit付きループは他の種類のループよりも理解しやすいことがわかりました。[13]
    • ループと条件文のネストのレベルに関して、研究によると、プログラマーは3つ以上のレベルのネストを理解するのが難しいことがわかっています。[13] [14]
    • 制御フローの複雑さは、信頼性の低さと頻繁なエラーと相関することが示されています。[14]
  • エラー状態の処理-計画されたエラーと例外の両方（たとえば、不良データの入力）
  • コードレベルのセキュリティ違反の防止（バッファオーバーランや配列インデックスのオーバーフローなど）
  • 除外メカニズムの使用によるリソースの使用と、シリアルに再利用可能なリソース（スレッドまたはデータベースロックを含む）へのアクセスにおける規律
  • ソースコードの編成（ステートメントとルーチンへ）：[11]
    • 凝集性の高いルーチンは、凝集性の低いルーチンよりもエラーが発生しにくいことが証明されました。450のルーチンを調査したところ、凝集度の低いルーチンの18％に比べて、凝集度の高いルーチンの50％に障害がないことがわかりました。異なる450ルーチンの別の研究では、結合対凝集率が最も高いルーチンには、結合対凝集率が最も低いルーチンの7倍のエラーがあり、修正に20倍のコストがかかることがわかりました。
    • 研究では、ルーチンのサイズとそれらのエラー率との相関関係に関して決定的な結果は示されていませんが、ある研究では、コードが143行未満のルーチンは、大きなルーチンよりも修正コストが2.4倍低いことがわかりました。別の調査によると、ルーチンの平均コード行数が100〜150の場合、コードの変更は最小限で済みます。別の研究では、ルーチンの構造の複雑さとデータの量が、そのサイズに関係なくエラーと相関していることがわかりました。
    • ルーチン間のインターフェースは、プログラムで最もエラーが発生しやすい領域の一部です。ある調査によると、すべてのエラーの39％は、ルーチン間の通信エラーでした。
    • 未使用のパラメーターは、エラー率の増加と相関関係があります。ある調査では、参照されていない変数が複数あるルーチンの17〜29％のみにエラーがありませんでしたが、未使用の変数がないルーチンでは46％でした。
    • 研究によると、人々は一般に一度に約7チャンクを超える情報を追跡できないことがわかっているため、ルーチンのパラメーターの数は最大で7にする必要があります。
  • ソースコードの編成（クラス、パッケージ、またはその他の構造への）。包含を検討する場合、クラス内のデータメンバーの最大数は7±2を超えてはなりません。調査によると、この数は、他のタスクを実行しているときに覚えることができる個別のアイテムの数です。継承を検討する場合、継承ツリーのレベル数を制限する必要があります。深い継承ツリーは、障害率の増加と大きく関連していることがわかっています。クラス内のルーチンの数を検討するときは、できるだけ少なくする必要があります。C ++プログラムに関する調査では、ルーチンの数と障害の数の間に関連性があることがわかりました。[10]
  • コードドキュメント
  • コードチューニング

建設試験

構築テストの目的は、障害がコードに挿入される時間とそれらの障害が検出される時間との間のギャップを減らすことです。場合によっては、コードが記述された後に構築テストが実行されます。テストファーストプログラミングでは、コードを記述する前にテストケースを作成します。構築には2つの形式のテストが含まれ、コードを作成したソフトウェアエンジニアによって実行されることがよくあります。[1]

再利用

ソフトウェアの再利用を実装するには、アセットのライブラリを作成して使用するだけでは不十分です。再利用のプロセスとアクティビティをソフトウェアのライフサイクルに統合することにより、再利用の実践を形式化する必要があります。コーディングおよびテスト中のソフトウェア構築での再利用に関連するタスクは次のとおりです。[1]

建設品質

構築時にコードの品質を保証するために使用される主な手法は次のとおりです。[15]

  • 単体テストと統合テスト。ある調査によると、単体テストと統合テストの平均欠陥検出率は、それぞれ30％と35％です。[16]
  • テストファースト開発
  • アサーションと防御プログラミングの使用
  • デバッグ
  • 検査。ある調査によると、正式なコード検査の平均欠陥検出率は60％です。欠陥を見つけるためのコストに関して、ある調査によると、コードの読み取りでは、テストよりも1時間あたり80％多くの障害が検出されました。別の研究では、検査を使用するよりもテストを使用して設計上の欠陥を検出するのに6倍のコストがかかることが示されました。IBMの調査によると、コード検査で欠陥を見つけるのに必要な時間はわずか3.5時間でしたが、テストでは15〜25時間でした。Microsoftは、コード検査を使用して欠陥を見つけて修正するのに3時間かかり、テストを使用して欠陥を見つけて修正するのに12時間かかることを発見しました。70万行のプログラムでは、コードレビューはテストの数倍の費用対効果が高いと報告されました。[16] 調査によると、検査の結果、コード1000行あたりの欠陥は正式なレビュー手法よりも20％〜30％少なくなり、生産性が約20％向上します。正式な検査は通常、プロジェクト予算の10％〜15％を要し、プロジェクト全体のコストを削減します。研究者は、正式な検査に2〜3人以上のレビューアがいても、検査対象の材料の種類によって結果は異なるように見えますが、検出される欠陥の数は増えないことを発見しました。[17]
  • テクニカルレビュー。ある調査によると、非公式のコードレビューとデスクチェックの平均欠陥検出率はそれぞれ25％と40％です。[16] ウォークスルーの欠陥検出率は20％〜40％であることがわかりましたが、プロジェクトの圧力が高まると、特に費用がかかることもわかりました。NASAは、コードの読み取りにより、1時間あたり3.3の欠陥を検出したのに対し、テストでは1時間あたり1.8の欠陥を検出しました。また、さまざまな種類のテストよりも、プロジェクトの存続期間中に20％〜60％多くのエラーが検出されます。レビュー会議に関する13件のレビューを調査したところ、レビュー会議の準備中に欠陥の90％が検出されましたが、会議中には約10％しか検出されませんでした。[17]
  • 静的分析（IEEE1028）

研究によると、高い欠陥検出率を達成するには、これらの手法を組み合わせて使用​​する必要があります。他の研究は、異なる人々が異なる欠陥を見つける傾向があることを示しました。ある研究によると、ペアプログラミング、デスクチェック、単体テスト、統合テスト、および回帰テストのエクストリームプログラミング手法では、90％の欠陥検出率を達成できます。[16] 経験豊富なプログラマーが参加した実験では、テストによって15個のエラーから平均して5個のエラー（せいぜい9個）を見つけることができたことがわかりました。[18]

エラーの80％は、プロジェクトのクラスとルーチンの20％に集中する傾向があります。エラーの50％は、プロジェクトのクラスの5％で見つかります。IBMは、425クラスのうち31のみを修復または書き換えることにより、お客様から報告された欠陥を10分の1に削減し、IMSシステムの保守予算を45％削減することができました。プロジェクトのルーチンの約20％が、開発コストの80％に貢献しています。IBMによる古典的な調査によると、OS / 360のエラーが発生しやすいルーチンのほとんどが最も高価なエンティティでした。1000行のコードあたり約50の欠陥があり、それらを修正するには、システム全体の開発にかかるコストの10倍のコストがかかります。[18]

統合

構築中の重要なアクティビティは、個別に構築されたルーチン、クラス、コンポーネント、およびサブシステムの統合です。さらに、特定のソフトウェアシステムを他のソフトウェアまたはハードウェアシステムと統合する必要がある場合があります。建設統合に関連する懸念事項には、コンポーネントを統合する順序の計画、ソフトウェアの中間バージョンをサポートするための足場の作成、コンポーネントを統合する前にコンポーネントに対して実行されるテストと品質作業の程度の決定、およびプロジェクトのポイントの決定が含まれます。暫定ソフトウェアのバージョンがテストされます。[1]

建設技術

オブジェクト指向のランタイムの問題

オブジェクト指向言語は、データの抽象化、カプセル化、モジュール性、継承、ポリモーフィズム、リフレクションなどのプログラムの柔軟性と適応性を高める一連のランタイムメカニズムをサポートしています。[19] [20]

データの抽象化は、実装の詳細を隠しながら、データとプログラムをその意味に似た形式の表現で定義するプロセスです。[21]学術研究によると、データの抽象化により、プログラムは機能的なプログラムよりも約30％理解しやすくなります。[10]

アサーション、契約による設計、および防御プログラミング

アサーションは、プログラムの実行時チェックを可能にするプログラムに配置される実行可能述語です。[19] 契約による設計は、各ルーチンに前提条件と事後条件が含まれる開発アプローチです。防御プログラミングは、ルーチンが無効な入力によって壊されるのを防ぐためのものです。[22]

エラー処理、例外処理、およびフォールトトレランス

エラー処理とは、プログラムの実行時に発生する可能性のあるエラー状態を予測してコーディングするプログラミング手法を指します。例外処理は、プログラム実行の通常のフローを変更する特別な条件である例外の発生を処理するように設計されたプログラミング言語の構造またはハードウェアメカニズムです。[23] フォールトトレランスは、エラーを検出し、可能であればエラーから回復するか、回復が不可能な場合はその影響を封じ込めることにより、ソフトウェアの信頼性を高める技術の集まりです。[22]

状態ベースおよびテーブル駆動の構築手法

状態ベースのプログラミングは、有限状態マシンを使用してプログラムの動作を記述するプログラミングテクノロジです。[22] テーブル駆動型メソッドは、論理ステートメント（ifやcaseなど）を使用するのではなく、テーブルを使用して情報を検索するスキーマです。[24]

ランタイム構成と国際化

ランタイム構成は、プログラムの実行時に変数値とプログラム設定をバインドする手法であり、通常はジャストインタイムモードで構成ファイルを更新および読み取ります。 国際化とは、複数のロケールをサポートするためのプログラム（通常は対話型ソフトウェア）を準備する技術的な活動です。対応するアクティビティであるローカリゼーションは、特定のローカル言語をサポートするようにプログラムを変更するアクティビティです。[24]

も参照してください

メモ

  1. ^ a b c d e f gSWEBOK ピエールボーク; ロバート・デュプイ; アラン・アブラン; ジェームズ・W・ムーア編 （2004）。「第4章：ソフトウェアの構築」。ソフトウェア工学知識体系へのガイド。IEEE ComputerSociety。pp。4–1–4–5。ISBN 0-7695-2330-7。
  2. ^ a b c d e SWEBOK 2014、p。3-3。
  3. ^ McConnell 2004、第3章。
  4. ^ SWEBOK 2014、p。3-5。
  5. ^ McConnell 2004、第5章。
  6. ^ SWEBOK 2014、p。3-5-3-6。
  7. ^ McConnell 2004、第4章。
  8. ^ SWEBOK 2014、p。3-6。
  9. ^ McConnell 2004、第11章。
  10. ^ a b c McConnell 2004、第6章。
  11. ^ a b McConnell 2004、第7章。
  12. ^ McConnell 2004、第12章。
  13. ^ a b McConnell 2004、第16章。
  14. ^ a b McConnell 2004、第19章。
  15. ^ SWEBOK 2014、p。3-7。
  16. ^ a b c d McConnell 2004、第20章。
  17. ^ a b McConnell 2004、第21章。
  18. ^ a b McConnell 2004、第22章。
  19. ^ a b SWEBOK 2014、p。3-8。
  20. ^ Thayer 2013、pp。140–141。
  21. ^ Thayer 2013、p。140。
  22. ^ a b c SWEBOK 2014、p。3-9。
  23. ^ Thayer 2013、p。142。
  24. ^ a b SWEBOK 2014、p。3-10。

参考文献

外部リンク

Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_construction&oldid=1068412825"