序文
時間は満たされませんし、タオも無駄にはできません。
1. ソフトウェアエンジニアリングの概念
- ソフトウェアは、コンピュータ システムが命令、データ、および関連文書の集合です。つまり、ソフトウェアはプログラム、データ、文書と同じです。
- プログラム： あらかじめ定められた機能や性能の要求に応じて、あらかじめ設計・記述された一連の命令のこと。
- データ: プログラムが情報を正常に処理できるようにするデータ構造と情報表現です。
- ドキュメンテーション: プログラムの開発、保守、および使用に関連する技術データおよびグラフィック資料。
- ソフトウェアクライシス：コンピュータソフトウェアの開発、運用、保守、管理の過程で遭遇する一連の重大な問題を指します。
ソフトウェアの開発や保守の過程では、ソフトウェア自体の特性に関係するものである一方で、ソフトウェアの開発や保守の誤った方法に関係する深刻な問題が数多くあります。 。
ソフトウェアエンジニアリングの定義
- ソフトウェアの計画、開発、運用、保守、管理のプロセスにおいて、エンジニアリングの概念、原則、技術、手法を使用し、科学的な管理と最良の技術的手法を密接に組み合わせ、適切なツールを使用してより経済的な手段を取得します。信頼性の高いソフトウェアへのさまざまなアプローチユーザーのニーズに応えます。
ソフトウェアエンジニアリングの特徴:
- ソフトウェア エンジニアリングは、ソフトウェア開発におけるエンジニアリングの原理と手法、およびソフトウェアを開発するための一連の科学的かつ現代的な手法とテクノロジの使用であり、このエンジニアリングの考え方は、ソフトウェアの開発とメンテナンスのプロセス全体に貫かれています。
目標は、ソフトウェア開発と保守の高品質、高効率化および自動化を実現することです。
ソフトウェアのライフサイクルの考え方（ソフトウェアの企画、開発、運用保守）
- ソフトウェアのライフサイクルとは、ソフトウェアの開発の開始からソフトウェアの使用の終了までの全プロセス、つまり、ユーザーの開発要求から始まり、開発、使用、保守を経て、最終的に廃棄されるまでのソフトウェア製品の全サイクルを指します。ソフトウェア ライフ サイクルまたはソフトウェア ライフ サイクルとも呼ばれます。ソフトウェア エンジニアリングにおける重要な概念です。
ソフトウェア ライフ サイクルのいくつかの概念:
- ソフトウェアの企画
- 需要分析
- アウトラインデザイン
- きめ細かなデザイン
- プログラミング
- テスト
- 運用と保守
ウォーターフォールモデル
- ウォーターフォールモデルでは、ライフサイクルの計画期間、開発期間、運用期間をいくつかの段階に細分化します。
2. 実現可能性の分析
-
実現可能性調査の目的は、最小限のコストで可能な限り最短の時間で問題を解決できるかどうかを判断することです。
-
実行可能性調査の目的は問題を解決することではなく、問題が解決する価値があるかどうかを判断することであることに留意する必要があります。
実現可能性分析は、フィージビリティスタディとも呼ばれ、ソフトウェアプロジェクトの開発に影響を与えるさまざまな要因の実現可能性、つまりソフトウェアプロジェクトが開発する価値があり、実現可能であるかどうかについて、包括的かつ体系的に分析および実証することを目的としています。
3 つの側面における実現可能性:
- 技術的な実現可能性。
- 経済的な存続可能性。
- 運用の実現可能性。
3. 需要分析
- ソフトウェア要件分析、システム要件分析、要件分析エンジニアリングなどとしても知られる要件分析は、機能、パフォーマンスなどのユーザーやプロジェクトの特定の要件を正確に理解するために、開発者が詳細かつ細心の注意を払って調査および分析するプロセスです。 、信頼性など。要件の記述が要件の完全な定義に変換されるプロセス。システムが実行する必要がある内容が決定されます。
要件分析は、ソフトウェア プロジェクトの開発決定後の主要なタスクであり、ソフトウェア開発プロセス全体の中で最も重要であり、ソフトウェア エンジニアリングの重要なリンクでもあります。
データフロー図（DFD：データフロー図）
- 記述子には、外部エンティティ、データ ストリーム、処理、およびデータ ストレージ ファイルの 4 つの主なタイプがあります。
基本単位
- モジュールとはプログラムを構成する基本的な部品であり、一般的なソフトウェアはそのモジュールとサブモジュールから構成されます。
- モジュール設計では、凝集性と結合性の両方が考慮され、モジュールの相対的な機能的独立性が維持されます。
- 凝集度:モジュール内の要素が互いに結合されている程度を示します。これは、情報の隠蔽とローカリゼーションの概念の自然な拡張です。
設計する際には、高い機能的凝集性を達成するよう努める必要があります。
功能内聚：如果模块内所有处理元素属于一个整体，完成一个单一的功能，则称为功能内聚。
機能的凝集は、最も高度な凝集です。
- 結合:結合は、ソフトウェア構造内の異なるモジュール間の相互接続の度合いを示す尺度であり、ソフトウェアの複雑さに影響を与える重要な要素です。
制御結合: モジュールが、スイッチ、フラグ、名前などの制御情報を渡すことによって、別のモジュールの機能の選択を明示的に制御する場合。
- モジュールの設計では、高い凝集性と低い結合性を最大限に追求する必要があります。
ソフトウェア構造を記述するためのツール
- 階層図
- HIPO 図: 「階層 - 入力 - 処理 - 出力」
概念的なデータモデル設計
- ER図。
- エンティティ関係モデルは、単純な E-R 図を使用して現実の理解を表現します。
- 利点:グラフィック要素が少ない、人間の思考モードに近い、ストレージ構造、アクセス方法、特定のデータベース ソフトウェアを考慮する必要がない、分析と設計が簡単、など。コンピュータ技術に詳しくないユーザーでも理解して使用することができ、データモデリングの開始ツールとして適しています。
- 長方形: エンティティ セットを表します
- 楕円：属性を示します
- 下線付きの主キーまたはコード名が付いた楕円: 主キーを示します。
- ダイヤモンド: 関係を示します。接続タイプは、ダイヤモンドとエンティティの間の線で表されます。外部キーは、外部キー名に下線が付いた楕円で表されます。複数値の属性は、二重線の楕円で表されます。派生プロパティは点線の楕円で表されます。
エンティティ関係図の設計手順は次のとおりです。まず、エンティティ タイプ、エンティティ属性、接続タイプを決定し、次に ER 図を描画します。
4. ソフトウェア詳細設計
1. 詳細設計の作業
- モジュールのアルゴリズム設計
- モジュール内のデータ構造設計
- モジュールインターフェース実装設計
- モジュールのテストケースの設計
- 詳細な設計仕様書を作成する
- 詳細な設計レビュー
2. 詳細設計用記述ツール
グラフィカルツール:
- プログラムフローチャート
- 箱ひげ図 (N - S)
- 問題分析図（PAD：問題分析図）
循環的複雑さ
- McCabe の方法で測定された結果は、プログラムの循環的複雑度と呼ばれます。
5. ソフトウェアの実装
プログラミング言語の開発
- 第一世代言語：機械ハードウェアと密接な関係にある機械語およびアセンブリ言語です。
- 第 2 世代言語: 主に、
FORTRAN、COBOL、PascalおよびなどBASIC。 - 第 3 世代言語: 構造化コンポーネントを直接サポートし、強力な処理能力とデータ構造能力を備えています。構造化プログラミング言語やオブジェクト指向言語
CなどC++/Java/Delphi。 :汎用高級言語、オブジェクト指向言語、および特殊用途言語。 - 第 4 世代言語: 超高度なプログラミング言語に属し、特徴: 強力なデータ管理機能、効率的なアクセス、クエリおよびデータベース上のその他の関連操作...
プログラムノート
- プログラムのコメントは、プロローグ コメントと機能コメントに分かれています。
- プリアンブル コメントは通常、さまざまなプログラム モジュールの先頭に配置されます。
- 機能コメントはソース プログラムの本体に埋め込まれており、多くの場合、特定のステートメントの後に配置され、ステートメントまたはプログラム セグメントによって実行される作業を説明するために使用されます。
6. ソフトウェアテスト
-
ソフトウェア テストの定義:ソフトウェア エラーを発見し、ソフトウェアの品質を測定し、設計要件を満たしているかどうかを評価するために、指定された条件下でソフトウェアを動作させるプロセス。評価を実行し、ソフトウェアが要件を満たしていることを確認するために特定のテクノロジと方法を使用することも含まれます。または動作結果を特定するプロセスであり、ソフトウェアの正確性、完全性、セキュリティ、およびソフトウェア品質をテストするための手段およびプロセスです。
-
注:ソフトウェア テストの目的は、ソフトウェアのバグを見つけることです。
ソフトウェアテストケースの設計
- ホワイトボックステストはテストの初期段階で実行され、ブラックボックステストは主にテストの後期段階で使用されます。
1. ブラックボックステスト
- プログラムの各機能が実現できるかどうか、機能上の誤りがないかを確認することを目的としており、このテスト方法をブラックボックステスト。ブラック ボックス テストは、機能テストまたはブラック ボックス テストとも呼ばれます。
- 「ブラックボックス」とは、テスターがプログラムの論理構造や内部特性を考慮せず、テスト対象のソフトウェアのインターフェースとインターフェースの外部条件だけを知り、その機能が規定の要件を満たしているかどうかだけをチェックすることを意味します。プログラムの要件分析仕様。
2. ホワイトボックステスト
- 製品の内部構造に基づいてテスト計画を立て、内部動作が規定通りに行われているか、ソフトウェア各部の機能が十分に活用されているかを確認するテスト方法をホワイトボックスと呼びます。試験方法。
- ホワイトボックス テストは主にプログラムの内部構造の実行パスのテストであり、グラス。
七、ソフトウェアメンテナンス
- ソフトウェア メンテナンスは、ソフトウェアが配信された後に、エラーを修正したり、新しいニーズに対応したりするために、ソフトウェアへの変更を管理するプロセスです。
ソフトウェア メンテナンスの種類は次の 4 種類です。
- 完璧なメンテナンス
- 適応型メンテナンス
- 事後保全
- 予防保守
8、ガントチャート
- ガント チャートは棒グラフとも呼ばれ、アクティビティの進捗状況とカレンダー テーブルを比較するグラフです。水平線分を使用してアクティビティの作業フェーズを表します。線分タスクを完了するのに必要な時間を表し、開始点と終了点はそれぞれタスクの開始時間と終了時間を表します。
- ガント チャートでは、タスクの完了基準は、対応するドキュメントの納品とレビューに合格することです。
- ガントチャートは、プロジェクトの計画的な進捗状況を明確に示し、現在の開発進捗を動的に反映することができますが、タスク間の複雑な論理関係を表現できないという欠点があります。