Loading article…
ソフトウェア構築はソフトウェアエンジニアリングの分野です。コーディング、検証、単体テスト、統合テスト、デバッグを組み合わせて、機能する意味のあるソフトウェアを詳細に作成します。ソフトウェア構築は他のすべてのソフトウェアエンジニアリング分野と関連していますが、最も強く関連しているのはソフトウェア設計とソフトウェアテストです。[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]
- 制御構造の使用:
- ある実験では、終了を伴うループは他の種類のループよりも理解しやすいことがわかった。[13]
- ループや条件文のネストレベルに関しては、プログラマーが3レベル以上のネストを理解するのが難しいことが研究で示されています。[13] [14]
- 制御フローの複雑さは信頼性の低さとエラーの多発と相関関係にあることが示されています。[14]
- エラー条件の処理 - 計画されたエラーと例外（たとえば、不正なデータの入力）の両方
- コードレベルのセキュリティ侵害の防止（バッファオーバーランや配列インデックスオーバーフローなど）
- 排他メカニズムの使用と、連続的に再利用可能なリソース（スレッドやデータベースロックを含む）へのアクセスにおける規律によるリソースの使用
- ソースコードの構成（ステートメントとルーチンに分割）: [11]
- 凝集度の高いルーチンは凝集度の低いルーチンよりもエラーが発生しにくいことが証明されました。450 個のルーチンを調査したところ、凝集度の高いルーチンの 50 % にエラーがなかったのに対し、凝集度の低いルーチンではエラーが 18 % にとどまりました。別の 450 個のルーチンを調査したところ、結合度と凝集度の比率が最も高いルーチンは、結合度と凝集度の比率が最も低いルーチンよりもエラーが 7 倍多く、修正コストも 20 倍高いことがわかりました。
- 研究では、ルーチンのサイズとエラー率の相関関係については決定的な結果は示されていませんが、ある研究では、143 行未満のコードを持つルーチンは、それより大きいルーチンよりも修正コストが 2.4 倍低いことがわかりました。別の研究では、ルーチンの平均コードが 100 ～ 150 行の場合、コードを変更する必要が最も少ないことがわかりました。別の研究では、ルーチンの構造の複雑さとデータ量は、サイズに関係なく、エラーと相関関係にあることがわかりました。
- ルーチン間のインターフェースは、プログラムの中で最もエラーが発生しやすい領域の 1 つです。ある調査によると、すべてのエラーの 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]
参照
注記
- ^ abcdefg SWEBOK Pierre Bourque、Robert Dupuis、Alain Abran、James W. Moore編 (2004)。「第 4 章: ソフトウェア構築」。ソフトウェア エンジニアリング知識体系ガイド。IEEE Computer Society。pp . 4–1–4–5。ISBN 0-7695-2330-7。
- ^ abcde SWEBOK 2014、p.3-3。
- ^ マコーネル 2004、第3章。
- ^ SWEBOK 2014、3-5ページ。
- ^ マコーネル 2004、第5章。
- ^ SWEBOK 2014、3-5～3-6頁。
- ^ マコーネル 2004、第4章。
- ^ SWEBOK 2014、3-6ページ。
- ^ マコーネル 2004、第11章。
- ^ abc McConnell 2004、第6章。
- ^ McConnell 2004、第7章より。
- ^ マコーネル 2004、第12章。
- ^ McConnell 2004、第16章より。
- ^ McConnell 2004、第19章より。
- ^ SWEBOK 2014、3-7ページ。
- ^ abcd McConnell 2004、第20章。
- ^ McConnell 2004、第21章より。
- ^ McConnell 2004、第22章より。
- ^ SWEBOK 2014、p.3-8より。
- ^ セイヤー2013、140-141頁。
- ^ セイヤー2013、140頁。
- ^ abc SWEBOK 2014、p.3-9。
- ^ セイヤー2013、142頁。
- ^ SWEBOK 2014、p.3-10より。
参考文献
- Pierre Bourque、Richard E. Fairley 編 (2014)。「第 3 章: ソフトウェア構築」。ソフトウェア エンジニアリング知識体系バージョン 3.0 ガイド。IEEE Computer Society。ISBN 978-0-7695-5166-1。
- マコーネル、スティーブン (2004)。コード コンプリート(第 2 版)。マイクロソフト プレス。ISBN 978-0-7356-1967-8。
- Thayer, Richard; Dorfman, Merlin (2013)。ソフトウェア エンジニアリングの基礎。第 1 巻: 開発プロセス (第 4 版)。Software Management Training Press、カリフォルニア州カーマイケル。ISBN 978-0-9852707-0-4。
外部リンク
- ソフトウェア エンジニアリング知識体系ガイド - 2004 年版 IEEE コンピュータ ソサエティ
- ソフトウェア エンジニアリング知識体系ガイド、バージョン 3.0、IEEE コンピュータ ソサエティ、2014 年