ソフトウェア工学
- ソフトウェアのライフサイクルとソフトウェアのプロセス
1.1 ソフトウェアのライフサイクル
ソフトウェアが最初から最後まで通過する段階とプロセスは、ソフトウェア開発とメンテナンスのプロセス全体です。
1.1.1 ソフトウェアのライフサイクルには次の段階が含まれます。
① 要件分析フェーズ: この段階では、ソフトウェア開発者は顧客とコミュニケーションをとって顧客のニーズや期待を理解し、それらのニーズをソフトウェア仕様に変換して、ソフトウェアが達成する必要のある機能や性能の要件を明確にする必要があります。
②設計フェーズ：ソフトウェア開発者は、要求仕様をソフトウェア設計書に変換し、ソフトウェアの構造やモジュールを設計し、ソフトウェアのアルゴリズムやデータ構造を決定するなどの作業を行い、ソフトウェアの保守性も考慮する必要があります。ソフトウェアのパフォーマンス、拡張性、移植性。
③コーディングフェーズ：このフェーズでは、ソフトウェア開発者は特定のプログラミング言語とツールを使用して、ソフトウェア設計文書の要件に従ってソフトウェアコードを記述し、ソフトウェアの正確性と安定性を確認するためにテストとデバッグを実施する必要があります。
④テストフェーズ：このフェーズでは、ソフトウェアテスターは、ソフトウェアのエラーや欠陥を発見して修復し、ソフトウェアの品質を保証するために、単体テスト、結合テスト、システムテストなどを含むソフトウェアのさまざまなテストを実行する必要があります。安定性。
⑤導入フェーズ：このフェーズでは、ソフトウェア開発者は、ソフトウェアを実際の使用環境に導入し、ソフトウェアが正しく実行および使用できることを確認するために必要な設定およびインストール作業を実行する必要があります。
⑥保守フェーズ：ソフトウェア開発者は、ソフトウェアの使用開始後、ソフトウェアのエラーや欠陥を修正したり、新しい機能や性能を追加したりして、ソフトウェアが引き続きユーザーのニーズを満足できるように、ソフトウェアを保守および更新する必要があります。そして期待。
- ソフトウェアプロセス
ソフトウェア プロセスとは、ソフトウェア開発をソフトウェア ライフ サイクルのさまざまな段階に分割し、各段階で特定のタスクとアクティビティを実行すること、およびこれらのタスクとアクティビティを実行するための方法、テクノロジ、ツール、および仕様を指す一般用語を指します。ソフトウェア開発において、ソフトウェア プロセスはソフトウェア エンジニアリングの中核であり、ソフトウェア開発プロセスの各段階でのタスクとアクティビティ、およびこれらのタスクとアクティビティの実行方法を決定します。
2.1 ソフトウェア プロセスには通常、次の手順が含まれます。
① 要件分析: 要件分析段階では、ソフトウェア開発者は顧客とコミュニケーションをとり、顧客のニーズと期待を理解し、これらのニーズをソフトウェア仕様に変換して、ソフトウェアが達成する必要がある機能と性能の要件を明確にする必要があります。
②設計：設計段階では、ソフトウェア開発者は要求仕様をソフトウェア設計書に変換し、ソフトウェアの構造やモジュールを設計し、ソフトウェアのアルゴリズムやデータ構造などを決定する必要があり、保守性や拡張性も考慮する必要があります。ソフトウェアの性能と移植性。
③コーディング：コーディング段階では、ソフトウェア開発者は特定のプログラミング言語とツールを使用して、ソフトウェア設計文書の要件に従ってソフトウェアコードを記述し、ソフトウェアの正確性と安定性を確認するためにテストとデバッグを実施する必要があります。
④テスト：テスト段階では、ソフトウェアテスターは、ソフトウェアのエラーや欠陥を発見して修復し、ソフトウェアの品質と安定性を確保するために、単体テスト、結合テスト、システムテストなど、ソフトウェアのさまざまなテストを実行する必要があります。 。
⑤ 導入：導入フェーズでは、ソフトウェア開発者は、ソフトウェアを実際の使用環境に導入し、ソフトウェアが正しく実行および使用できることを確認するために必要な設定およびインストール作業を実行する必要があります。
⑥メンテナンス：ソフトウェア開発者は、ソフトウェアの使用開始後、ソフトウェアが引き続きユーザーのニーズや期待に応えられるように、ソフトウェアのエラーや欠陥を修正したり、新しい機能や性能を追加したりするために、ソフトウェアを保守および更新する必要があります。 。
⑦ 廃止: ソフトウェアのバックアップとアーカイブ、ソフトウェアのアンインストールとクリーンアップ、ソフトウェアの評価とレポート、リソースのリサイクルと再利用は、ソフトウェアに隠れた危険や機密情報が残らないようにし、後続のソフトウェア開発プロジェクトで再利用できるようにするために必要です。廃止フェーズはソフトウェア プロセスの重要な部分であり、ソフトウェアの安全性と信頼性を確保する上で重要な役割を果たします。
- データ フロー図 (DFD)
(1) システム内のデータの流れと処理を説明するために使用されるグラフィカルな分析ツールであり、アナリストが明確に理解するのに役立ちます。
システム内のデータの送信元、送信先、および処理プロセスを理解します。
(2) データ フロー図には、次の 3 つの基本要素が含まれています。
① エンティティ: システムが対話する外部オブジェクトを表し、人、組織、機器、その他のシステムなどが考えられます。
② プロセス：計算、並べ替え、フィルタリング、変換などのデータを処理する操作を表します。
③データフロー：システム内の入力、出力、送信、保存などのデータの流れを表します。
- データ フロー図は次のレベルに分類できます。
① レベル 0 データ フロー図: コンテキスト データ フロー図とも呼ばれ、システム内の最上位の図であり、システムと外部世界との間の相互作用を記述し、外部エンティティ、データ フロー、およびシステムを表示するために使用されます。
② レベル 1 データフロー図：レベル 0 データフロー図をベースに、システムの内部詳細をさらに拡張し、システム内の主要なプロセスを記述します。通常、3 ～ 7 つのプロセスで構成されます。
③レベル2データフロー図：レベル1データフロー図をベースに、システムの内部詳細をさらに拡張し、通常3～7個のサブプロセスで構成されるレベル1プロセスの内部処理を記述します。
- データ フロー図には次の利点があります。
①理解しやすく、使いやすい：データフロー図は、システム内のデータの流れと処理をグラフィカルな手法で明確に記述しており、理解しやすく、使いやすくなっています。
② 分析と最適化の促進: データ フロー図は、分析者がシステムの機能とプロセスを深く理解し、問題やボトルネックを発見し、システムを最適化して改善するのに役立ちます。
③コミュニケーションとコミュニケーションが容易：データフロー図は、さまざまな人々に共通の視点と言語を提供し、コミュニケーションとコミュニケーションを促進することができる普遍的なグラフィカル分析ツールです。
④保守・更新が容易：データフロー図によりシステム内のデータの流れや処理プロセスを明確に記述できるため、その後の保守・更新が容易になります。
- ただし、データ フロー図には次の欠点もあります。
①複雑さ: データ フロー図は、特に大規模なソフトウェア システムでは非常に複雑になる可能性があります。これにより、データ フロー図の理解と維持がより困難になる可能性があります。
②抽象化レベル: データフロー図は抽象化レベルが高く、直感的に十分ではない可能性があります。このため、一部のユーザーはデータ フロー図の意味を理解することが困難になる可能性があります。
③詳細の欠如: データ フロー図は通常、システム内の高レベルのプロセスのみを示し、特定の詳細は無視されます。これにより、開発者がプロセスを実装する際に困難が生じる可能性があります。
④一部のシステムには適用不可：データフロー図は、並行システムやリアルタイムシステムなど一部のシステムには適用できない場合があります。これらのシステムの特殊な性質により、データ フロー図の設計が困難または実行不可能になる場合があります。
- オブジェクト指向の要件分析
- オブジェクト指向要求分析手法とは、オブジェクト指向の考え方に基づいた要求分析手法であり、問題領域における実体、属性、動作、およびそれらの間の関係を、オブジェクト、プロパティ、メソッド、メッセージなどの概念として表現し、理解を深めます。そして問題の領域を説明します。
- 具体的には、オブジェクト指向の要件分析方法には次の手順が含まれます。
①概念モデリング: 概念モデリングは、問題領域内のエンティティ、属性、関係を特定し、記述するプロセスです。これは、UML クラス図や ER 図などのグラフィカル ツールを使用して概念モデルを構築することで実行できます。概念モデルには、問題領域内のすべてのエンティティ、それらの関係および属性が含まれている必要があります。
② 機能モデリング: 機能モデリングは、概念モデルに基づいてシステムが完了する必要がある機能を特定し、記述することです。これは、ユースケース図やアクティビティ図などのグラフィカル ツールを使用して機能をモデル化することで実行できます。機能モデルには、システムのすべての機能要件とそれらの間の関係が含まれている必要があります。
③ 動作モデリング: 動作モデリングは、機能モデルに基づいてシステムの動作を特定し、記述することです。これは、状態図やシーケンス図などのグラフィカル ツールを使用して動作をモデル化することで実行できます。動作モデルには、システムのすべての状態、状態間の遷移、およびシステム内のすべてのオブジェクトの動作が含まれている必要があります。
④インターフェースモデリング：インターフェースモデリングとは、機能モデルと動作モデルに基づいてシステムのユーザーインターフェースを特定し、記述することです。これは、インターフェイス プロトタイプや UI フローチャートなどのグラフィカル ツールを使用してインターフェイス モデルを構築することで実行できます。インターフェイスのモックアップには、すべてのユーザー インターフェイスのデザインとレイアウトが含まれている必要があります。
⑤検証と検証：検証と検証は、システム要件を検証して確認するプロセスです。これは、プロトタイピング システム、シミュレーター、テスト ツールなどを使用して実行できます。検証と妥当性検査の結果は、すべての要件の確認とシステムの実現可能性分析になります。
- 上記の手順を通じて、オブジェクト指向の要件分析手法は、開発者が問題領域をよりよく理解して説明し、これらの要件を達成可能なソフトウェア システムに変換するのに役立ちます。さらに、オブジェクト指向の要件分析手法により、ソフトウェア システムの保守や、変化するニーズに合わせた拡張も容易になります。
- ホワイトボックステスト手法
- ホワイト ボックス テストは、システムの内部ロジックの理解、テスト ケースの設計と実行に基づいて、システムが期待どおりに動作するかどうかを検証するソフトウェア テスト方法です。ホワイトボックス テスト方法は、構造テストまたはロジック駆動テストとも呼ばれ、開発者が開発プロセス中に潜在的な問題をタイムリーに発見して修復し、ソフトウェアの品質と信頼性を向上させるのに役立ちます。
- ホワイトボックステスト法の主な手順は次のとおりです。
① プログラムコードのレビュー：ホワイトボックステスト手法の最初のステップは、プログラムコードをレビューし、システムの内部ロジックとデータ構造を理解することです。これには、システムの構造と機能をより深く理解するために、ソース コード、ドキュメント、コメント、およびその他の関連情報をレビューすることが含まれます。
② テストケースの設計：プログラムコードのレビュー結果をもとに、システムが期待される機能・性能要件を満たしているかを確認するテストケースを設計します。テスト ケースは、通常の状況下でのコード パスと異常な状況でのコード パスを含む、すべてのコード パスをカバーする必要があります。
③テストケースの実行：テストケースの設計に従ってテストを実行し、テスト結果と問題点を記録します。テストプロセスでは、システムの動作状態をより深く理解するために、入力、出力、状態変化などのシステムの動作を注意深く観察する必要があります。
④ テスト結果の分析：テスト結果を分析し、問題の原因を特定します。テスト結果が期待どおりでない場合は、コードとテスト ケースを詳しく調べて問題の原因を特定する必要があります。テスト結果が期待どおりであれば、テスト ケースとコードをさらに最適化して改善できます。
⑤ 問題を修正する: テスト結果に従って問題を修正し、問題が解決されたことを確認するために再テストします。
(3) ホワイトボックステスト手法の利点は、潜在的な問題やエラーを発見し、ソフトウェアの品質と信頼性を向上できることです。また、開発者がシステムの内部ロジックとデータ構造をより深く理解し、コードの作成とデバッグを改善するのにも役立ちます。ただし、ホワイトボックス テスト方法では、プログラム コードの構造とロジックを深く理解する必要があり、開発者に高いスキルが要求され、テスト コストが比較的高くなります。
- ブラックボックステスト手法
(1) ブラックボックステストは、システムの内部ロジックを考慮せず、システムの入出力のみに焦点を当て、システムが期待どおりに動作するかどうかを検証するソフトウェアテスト手法です。ブラック ボックス テスト方法は、機能テストまたはデータ駆動テストとも呼ばれ、テスターがシステムの具体的な実装を知らなくてもテストを実施し、システムの欠陥や問題を発見し、システムの機能とパフォーマンスが期待される要件を満たしていることを確認するのに役立ちます。
(2) ブラックボックステスト法の主な手順は次のとおりです。
① テスト要件の決定：テストの目的、範囲、テスト要件を決定します。これには、テスト ケースをより適切に設計および実行するための、テストの入力、期待される出力、およびテスト条件を決定することが含まれます。
② テストケースの設計：テスト要件に従って、システムが期待どおりに動作するかどうかを検証するテストケースを設計します。テスト ケースは、潜在的な問題やエラーを検出するために、考えられるすべての入力状況と境界条件をカバーする必要があります。
③テストケースの実行：テストケースの設計に従ってテストを実行し、テスト結果と問題点を記録します。テストプロセスでは、システムの動作状態をより深く理解するために、入力、出力、状態変化などのシステムの動作を注意深く観察する必要があります。
④ テスト結果の分析：テスト結果を分析し、問題の原因を特定します。テスト結果が期待どおりでない場合は、テスト ケースとテスト条件を詳しく調べて問題の原因を特定する必要があります。テスト結果が期待どおりであれば、テスト ケースをさらに最適化して改善できます。
⑤ 問題を修正する: テスト結果に従って問題を修正し、問題が解決されたことを確認するために再テストします。
- ブラックボックステスト手法の利点は、システムの実装内容を知らなくてもシステムの機能や性能をテストできること、テスト担当者のスキル要件が比較的低く、テストコストも低いことです。ただし、ブラック ボックス テスト手法ではシステム内の問題やエラーを捉えることができない場合があり、テスト ケースの設計ではシステムの入出力を慎重に考慮する必要があり、そうしないと抜け穴だらけになる可能性があります。したがって、より包括的なテスト範囲とより高いテスト品質を得るには、ブラック ボックス テスト手法を他のテスト手法と組み合わせて使用する必要があります。
- ソフトウェアプロジェクト管理
- ソフトウェア プロジェクト管理とは、ソフトウェア プロジェクトの目標と要件を達成するために、ソフトウェア開発プロセスにおけるさまざまな活動を計画、組織、指示、制御、評価することを指します。
- ソフトウェア プロジェクト管理のプロセスと内容には、次の側面が含まれます。
①プロジェクト開始段階：プロジェクトの目標、範囲、要件、リソース、スケジュール、リスクなどを決定し、プロジェクト計画と組織構造を策定し、プロジェクトの実行プロセスと品質基準を明確にします。
② 要求分析段階：ユーザーの要求を収集、分析、明確にし、要求仕様を作成し、要求変更管理計画を策定し、プロジェクトの要求がユーザーの要求と期待を満たしていることを確認します。
③設計段階：要求仕様に従ってシステム設計、モジュール設計、インターフェース設計を実施し、設計書とテスト計画を作成し、システム設計が要求仕様と品質基準を満たしていることを確認します。
④ コーディングとテスト段階：設計書とテスト計画に従ってソフトウェアのコーディングとテスト活動を実行し、ソフトウェアのコードの品質と機能が設計書とテスト計画の要件を満たしていることを確認します。
⑤統合および受け入れ段階：各モジュールを統合およびシステムテストし、システム受け入れを実施して、ソフトウェアシステムの機能、性能、品質がユーザーの要件と期待を満たしていることを確認します。
⑥プロジェクト終了段階：プロジェクトの受諾、文書のアーカイブ、ナレッジ管理と経験の要約などを含む、プロジェクトの納品、終了および要約作業を完了します。
- ソフトウェア プロジェクト管理の集合的な内容には、次の側面が含まれます。
①プロジェクト計画管理：プロジェクトの進捗状況を含めたプロジェクト計画の策定
プロジェクトが計画どおりに実行されることを保証するための、程度、コスト、品質、範囲、リソースおよびリスク管理計画など。
②品質管理：ソフトウェアシステムの品質がユーザーの要求と期待を確実に満たすことを保証するために、品質基準とテスト計画を策定し、ソフトウェアシステムの機能、パフォーマンス、信頼性、セキュリティをテストおよび評価します。
③変更管理：ソフトウェアシステムへの変更が品質基準と安全要件に準拠していることを確認するために、要件、設計、コード、テストを管理および制御するための変更管理計画を作成します。
④リスク管理：プロジェクトのリスクを特定、評価、制御し、リスク管理計画を策定し、プロジェクトのリスクが効果的に管理および制御されていることを確認します。
⑤人的資源管理：プロジェクトチームの人的資源が効果的に管理・活用されるよう、プロジェクトの組織構造、人材採用、研修、評価などを含む人的資源管理計画を策定します。
⑥コミュニケーション管理：プロジェクト組織内外の円滑なコミュニケーション、タイムリーかつ正確な情報伝達とフィードバックを確保するためのコミュニケーション管理計画を策定します。
⑦ 調達管理: プロジェクト調達の品質とコストが要件と期待を確実に満たすように、購入したソフトウェアとハードウェアを管理および制御するための調達管理計画を作成します。
(4) ソフトウェア プロジェクトの管理プロセスとその内容は、ソフトウェア プロジェクトが計画された必要な目標と期待に従って確実に達成されるようにするために、あらゆる要素の包括的かつ体系的な考慮を必要とする複雑なシステム エンジニアリングです。