記事ディレクトリ
参考
ソフトウェアエンジニアリング短期集中コース（期末＋大学院入試再試験＋ソフトウェア試験）に適用 4K対応
概要
ソフトウェアエンジニアリングの概要
定義: エンジニアリングの概念、原則、技術、および方法を使用してソフトウェアを開発および保守すること。
3 つの要素:
- メソッド: ソフトウェア開発のさまざまなタスクを完了するための技術的手法であり、「それをどのように行うか」に答えます。
- ツール: メソッドを適用するための自動または半自動のソフトウェア エンジニアリング サポート環境。
- プロセス: 高品質のソフトウェアを入手するために「いつ」完了する必要がある一連のタスクの枠組み。
ソフトウェアのライフサイクルには 3 つの期間と 8 つの段階があります。
- ソフトウェア・デファインドの時代。含まれるステージは次のとおりです。
問題定義ステージ: ユーザーはどのような種類の問題を解決する必要があるか?
実現可能性検討段階：ソフトウェア開発が実現可能かどうか。
需要分析：顧客ニーズを明確にし、標準化された需要仕様を出力します。 - ソフトウェア開発期間には、次の段階が含まれます。
全体設計: 全体構造の設計と包括的なテスト目標の決定、
詳細設計、
コーディングと単体テスト、および
総合テスト。 - ソフトウェア保守期間（期間が最も長く、費用が最もかかる）
ソフトウェアの運用と保守
ソフトウェアプロセス
主にタスクフレームワークであるウォーターフォールモデル、インクリメンタルモデル、スパイラルモデル、ファウンテンモデルなどが含まれます。
-
ウォーターフォール モデルの
特徴: 最も基本的なソフトウェア開発ライフ サイクル モデルです。
利点: 組織と管理が容易になり、大規模なソフトウェア開発の品質と効率が向上します。
短所: 開発プロセスは厳格で、変更が不便で、実践が困難です。 -
インクリメンタルモデルのメリット
：人員配置が柔軟で、一部の機能を先に顧客にリリースできる。
短所: 並行開発には統合が困難になるリスクがあります。 -
スパイラルモデルの特徴
：リスク分析が導入されており、各スパイラルサイクルはおおよそウォーターフォールモデルとなっています。
利点: 設計は柔軟で変更が容易で、サイクルごとにユーザーによる評価が必要です。
短所: 反復が多すぎるとコストが高くなります。 -
噴水モデルの
特徴: 複数の段階に分かれていますが、明確な境界はなく、繰り返し通過することができます。
実行可能性分析
実現可能性分析の概要
実現可能性分析: 問題を最小限のコストで最短時間で解決できるかどうかを判断します。
実現可能性調査: 顧客の要件を理解し、技術的、経済的、社会的要因などから実現可能性を実証します。
データフロー図
データ フロー図 (データ フロー図 DFD とも呼ばれる) は、ユーザーがシステム データ フローを理解し、分析することを容易にするグラフィカル ツールです。その基本要素には次のものが含まれます。
- 外部エンティティ: データの送信元と宛先を表し、ソフトウェア システムの外部にある人または組織です。
- 処理: データの処理。
- データストレージ: 情報の静的ストレージ。
- データ フロー: どのようなデータが移動されるか。
例：部品の倉庫への入庫・出庫をトランザクションと呼び、倉庫に設置されたCAT端末を通じて受発注システムに報告されます。特定の部品の在庫数量がしきい値を下回った場合、その部品を再発注する必要があります。購買部門は毎日発注レポートを必要としています。レポートは部品番号でソートされています。表には再注文が必要なすべての部品がリストされています。これらの部品には次のデータがあります (部品番号、部品名、注文数量、現在の価格、主要サプライヤー) 、二次サプライヤー）。
問題解決:
1. 問題の説明からデータ フローの 4 つのコンポーネントを抽出します。
- ソースポイントとエンドポイント: 取引は倉庫のCAT端末を介して発注システムに報告され、その後購買部門に報告されます。ソースポイントは倉庫管理者、エンドポイントは購買担当者です。
- 処理: 購買部門は発注レポートを必要とするため、発注レポートを生成する必要があります。倉庫に出入りする部品の数量を変更するのもプロセスです。
- データ フロー: 1 つ目は、倉庫から発注システムへの入出荷トランザクションのレポートであり、2 つ目は発注レポートを購買部門に送信することです。
- データ保管：発注する部品の情報や在庫情報。
2. ラフモデルを描く
3. さらなる改良
データディクショナリ
データフロー図はシステムの分解を記述したもので、データディクショナリはデータフロー図内の各データの流れ、ファイル、処理、データ項目などを記述するために使用され、エントリには以下の4種類があります。
- データ フロー エントリ: データ コンポーネントを説明します (例: 内部番号 = ゼロ以外の数値 + 3{数値}3)
- データ ストレージ エントリ:
- データ項目の入力:
- エントリを処理しています:
需要分析
要件分析の概要
定義: 要件分析とは、開発者が顧客の要件を正確に理解し、詳細な調査と研究を実施し、ユーザーの非公式の需要説明を完全な需要定義に変換し、ソフトウェア要件仕様を生成するプロセスを指します。
ER図
エンティティの種類、属性、および関係を表すメソッドを提供します。
状態遷移図
システムの動作は、システム状態と、システム状態の遷移を引き起こすイベントを記述することで表されます。そのシンボルには次のようなものがあります。
- 初期状態: 黒丸で表されます。
- 中間状態: 丸い長方形で表され、上部、中央、下部の 3 つの部分に分割できます。それぞれ、状態の名前、変数の説明 (オプション)、およびアクティビティ テーブル (オプション) を表します。
- 最終状態: 一対の同心円で表されます。
- 状態遷移: 矢印で表されます。遷移がイベントによってトリガーされる場合は、矢印上にマークが付けられますが、マークが付けられていない場合は、元の状態の内部アクティビティが実行された後に自動的にトリガーされることを意味します。
