このコラムはブロガーの個人的なメモであり、主な目的は、断片的な時間を利用してソフトエンジニアリングの知識ポイントを暗記することです、ここに宣言します!
記事ディレクトリ
3. ロジックモデルの解決可能性をどのような側面から検討しますか?
5. 予想される総プロジェクト費用に対する実現可能性調査費用の割合はどれくらいですか?
7. システムフローチャートの基本的な考え方と機能は何ですか?
8. 複雑なシステムに直面した場合、システムを記述するために一般的にどのような方法が使用されますか?
9. データ フロー ダイアグラム (DFD) とは何ですか?
10. データ フロー図におけるデータ ストレージとデータ フローの類似点と相違点は何ですか?
11. データ フロー グラフの 4 つのコンポーネントは何ですか?
15. システム ロジック モデルの形成にデータ フロー図とデータ ディクショナリが不可欠なのはなぜですか?
16. データディクショナリは 4 種類の要素の定義で構成されていますか?
19. B/S アーキテクチャと C/S アーキテクチャとは何ですか?
20. シナリオと、考えられるすべてのアクションのシーケンスを記述する状態図との関係は何ですか?
21. データ フロー グラフには、プログラム フローチャートのようなノード間の到達可能性に関する関連ルールがないのはなぜですか?
1. 実現可能性調査の目的は何ですか?
問題を最小限のコストで最短時間で解決できるかどうかを判断する
2. 実現可能性調査の本質は何ですか?
実現可能性調査は本質的に、システム分析および設計の大幅に圧縮および簡略化されたプロセス、つまり、より高い抽象化レベルで比較的抽象的な方法でシステム分析および設計を行うプロセスです。
3. ロジックモデルの解決可能性をどのような側面から検討しますか?
- 技術的な実現可能性
- 経済的実現可能性
- 運用可能性
- 社会的実現可能性
4. 実現可能性調査の最も基本的なタスクは何ですか?
将来の行動方針についての推奨事項を作成する
5. 予想される総プロジェクト費用に対する実現可能性調査費用の割合はどれくらいですか?
5%~10%
6. 実現可能性調査の手順は何ですか?
- システムの規模と目標を確認する
- 現在使用されている研究システム
- 新しいシステムの高レベルの論理構造の導出: つまり、既存の物理システム --> 既存システムの論理モデル --> ターゲット システムの論理モデル --> ターゲット物理システム
- 問題をさらに定義する
- 代替ソリューションの導出と評価
- 推奨される行動方針
- 開発計画の草案
- 文書を作成し、レビューのために提出する
7. システムフローチャートの基本的な考え方と機能は何ですか?
システム フローチャートの基本的な考え方は、システムを構成する各コンポーネント (プログラム、ドキュメント、データベース、人間のプロセスなど) をグラフィック シンボルを使用してブラック ボックスの形式で記述することです。
システム フローチャートの機能は、既存のシステムを理解して分析することです。これは、物理システムを一般的な方法で記述するための伝統的なツールです。制御プロセスではなく、システムのさまざまなコンポーネント間のデータの流れを表現します。データを処理するため。
8. 複雑なシステムに直面した場合、システムを記述するために一般的にどのような方法が使用されますか?
層状の
9. データ フロー ダイアグラム (DFD) とは何ですか?
データ フロー ダイアグラム (DFD) は、ソフトウェア内で流れ、処理されるデータの論理プロセスのみを記述するグラフィカルな手法です。データ フロー図のデータ フローは、プログラム フローチャートの矢印で表される制御フローとは本質的に異なります。. .
10. データ フロー図におけるデータ ストレージとデータ フローの類似点と相違点は何ですか?
データ ストレージとデータ フローはどちらもデータですが、状態が異なります。データ ストレージは静止データですが、データ ストリーミングは移動中のデータです。
11. データ フロー グラフの 4 つのコンポーネントは何ですか?
ソースまたは宛先、処理、データストレージ、データフロー
12. データ フロー図の階層化の原理は何ですか?
- データ フロー グラフの階層化により、情報の連続性が確保される必要があります。つまり、プロセスを一連のプロセスに分解する場合、分解前と分解後の入力データ ストリームと出力データ ストリームが同じである必要があります。
- データフロー図の適切な処理数は5～9です。
[注意] データフローグラフの命名順は、最上位レイヤ、レイヤ0、レイヤ1です。グラフがより複雑な場合は、次のようにレイヤ0とレイヤ1の処理に通し番号を付けることができます。形：
13. データ フロー図の目的は何ですか?
- 情報交換のツールとしてご利用いただけます。データフロー図は 4 つの基本的な表記のみを使用し、物理的な実装の詳細が含まれていないため、ほとんどのユーザーが理解して評価できます。
- 分析や設計のためのツールとして使用できます。データ フロー指向の設計手法の基礎となるのはデータ フロー図です
14. データディクショナリとは何ですか?
データ ディクショナリは、データに関する情報のコレクション、つまり、データ フロー図に含まれるすべての要素の定義のコレクションです。
15. システム ロジック モデルの形成にデータ フロー図とデータ ディクショナリが不可欠なのはなぜですか?
データ フロー グラフとデータ フィールドが一緒になってシステムの論理モデルを形成するためです。データ ディクショナリがなければ、データ フロー図は厳密なものではなくなり、データ フロー図がなければ、データ ディクショナリが役割を果たすことも難しくなります。
16. データディクショナリは 4 種類の要素の定義で構成されていますか?
- データフロー
- ストリームコンポーネント
- データストレージ
- 対処する
17. データ ディクショナリの目的は何ですか?
- 分析フェーズのツールとして
- アナリストとユーザー間のコミュニケーションの向上に役立ちます
- 異なる開発者または異なる開発グループ間のコミュニケーションの向上に役立ちます
- 各データ要素の貴重な制御情報が含まれています
- データ ディクショナリはデータベース開発の最初のステップです
18. MVC パターンの概念と利点は何ですか?
MVC の正式名称はModel View Controllerで、Model (Model)-View (View)-Controller (Controller) の略であり、ソフトウェア設計のモデルであり、ビジネス ロジック、データ、インターフェイスを分離する手法を使用します。コードを整理するための表示ビジネス ロジックを 1 つのコンポーネントにまとめ、インターフェイスとユーザー インタラクションを改善およびカスタマイズしながら、ビジネス ロジックを書き直す必要はありません。
利点は、アプリケーションのさまざまなビューを処理できることです。実際、データがオンラインで保存されているか、従業員のリストで保存されているかに関係なく、ビューでは実際の処理は行われません。ビューはデータを出力し、ユーザーがそれを操作できるようにする単なる方法です。
19. B/S アーキテクチャと C/S アーキテクチャとは何ですか?
B/S アーキテクチャ、正式名はBrowser/Server、つまりブラウザとサーバーのアーキテクチャ モードです。このアーキテクチャでは、ユーザーの作業インターフェイスはブラウザを通じて実装され、さまざまな Web アドレス (URL) にアクセスすることでさまざまなサーバー側プログラムにアクセスできます。
C/S アーキテクチャ、正式名はClient/Server、つまりクライアントとサーバーのアーキテクチャ モードです。このアーキテクチャでは、ユーザーはローカル クライアント プログラムを使用してネットワーク要求を送信し、リモート サーバー プログラムがその要求に応答して処理します。
【注意】詳しくは下記の記事「Web開発の基礎入門」をご覧ください。
20. シナリオと、考えられるすべてのアクションのシーケンスを記述する状態図との関係は何ですか?
シナリオは状態図の一部またはすべてを通過するパスにすぎません。つまり、シナリオはシステムの典型的な動作のみを記述しますが、状態図はシステムのすべての動作を記述するため、状態図にはシナリオが含まれます。
[注] 以下の電話システムの状態図に示すように、ダイヤルは単なるシナリオであり、電話システムの典型的な動作です。
21. データ フロー グラフには、プログラム フローチャートのようなノード間の到達可能性に関する関連ルールがないのはなぜですか?
データフロー図は制御を記述していないため、データフロー図内の 2 つの「プロセス」の間にパスが存在しない場合があります。各プロセスが異なる入力データを使用し、異なる出力データを生成し、あるプロセスの出力が別のプロセスの入力として使用されない場合、それらの間にアークは存在しません。
章の最後にまとめ
実現可能性調査では、問題定義フェーズで特定された問題に対する実現可能な解決策があるかどうかをさらに調査します。
問題の正しい定義に基づいて、問題を分析することで (多くの場合、現在使用しているシステムを調査する必要があります)、暫定的な解決策を導き出し、次に
問題の定義を見直して修正し、提案された解決策を改善するために問題を再度分析します。問題の定義、問題の分析、解決策の提案という
反復プロセス最終的にシステムの目標を満たす高レベルの論理モデルが提案されます。そして、このシステムの論理モデルに従って、
考えられるさまざまな物理システムを想像し、
それらの物理システムの実現可能性を技術、経済性、運用などのさまざまな側面から分析します。最後に、システム アナリストは、
ユーザーおよびクライアント組織の責任者によるレビューと承認のために推奨される行動方針を提案します。システム フローチャートは、
既存のシステムに対する分析者の認識を表現し、将来の物理システムのビジョンを説明するための優れたツールです。システム フロー図は、本質的には、システムを構成する主要な物理要素と、これらの要素間で情報がどのように流れ、処理されるかを示す物理データ フロー図です。 データ フロー図には基本的なシンボルが 4 つしかなく、システムの論理モデルを記述する優れたツールです。通常、データ ディクショナリとデータ フロー図は一緒になってシステムの論理モデルを構成します。データ フロー図の各要素を正確に定義するデータ ディクショナリがなければ、データフロー図は十分に厳密ではありません。
; ただし、データ フロー図がなければデータ ディクショナリも役割を果たすことが難しく、この 2 つは不可欠です。
費用/便益分析は実現可能性調査の重要な部分であり、クライアント組織の責任者が経済的な観点からプロジェクトへの投資を継続するかどうかを判断する主な基礎となります
。読者の皆様には、フィージビリティスタディの必要性とその基本的な作業と基本的な手順を
再理解していただく必要があります。これに基づいて、具体的な方法やツールをさらに検討します。特定の方法やツールを深く理解することで、実現可能性調査のプロセスへの理解も深まります。ただし、特定の方法やツールの詳細に囚われて、ソフトウェア エンジニアリングの基本原理や概念の学習を無視しないでください。
次の章:ソフトウェアエンジニアリング —— 第 3 章 要件分析 知識ポイントの整理
繰り返し、地に足を着いて、決して忘れることなく、響き渡るでしょう！