システム分析と設計-概要

システム開発は、計画、分析、設計、展開、保守などのフェーズを含む体系的なプロセスです。ここで、このチュートリアルでは、主に焦点を当てます-

システム分析
システム設計

システム分析

これは、事実を収集して解釈し、問題を特定し、システムをそのコンポーネントに分解するプロセスです。

システム分析は、目的を特定するために、システムまたはその部品を調査する目的で実施されます。これは、システムを改善し、システムのすべてのコンポーネントが目的を達成するために効率的に機能することを保証する問題解決技術です。

分析では、*システムが行うべきこと*を指定します。

システム設計

特定の要件を満たすためにコンポーネントまたはモジュールを定義することにより、新しいビジネスシステムを計画したり、既存のシステムを置き換えたりするプロセスです。計画する前に、古いシステムを完全に理解し、効率的に動作するためにコンピューターを最適に使用する方法を決定する必要があります。

システム設計は、*システムの目的を達成する方法*に焦点を当てています。

システム分析と設計（SAD）は主に焦点を当てています-

システム
プロセス
技術

システムとは何ですか？

「システム」という言葉はギリシャ語の「Systema」に由来します。これは、何らかの共通の原因または目的を達成するためのコンポーネントのセット間の組織的な関係を意味します。

_システムとは、「特定の目標を達成するための計画に従って相互にリンクされた相互依存コンポーネントの秩序あるグループ化」です。

システムの制約

システムには3つの基本的な制約が必要です-

システムには、事前定義された目標を達成するために設計された*構造と動作*が必要です。
*相互接続性*と*相互依存性*は、システムコンポーネント間に存在する必要があります。
*組織の目的*は、サブシステムの目的より*高い優先度*を持っています。

たとえば、交通管理システム、給与計算システム、自動図書館システム、人事情報システム。

システムのプロパティ

システムには、次のプロパティがあります-

組織

組織は構造と順序を意味します。所定の目的を達成するのに役立つのは、コンポーネントの配置です。

インタラクション

コンポーネントが相互に動作する方法によって定義されます。

たとえば、組織では、購買部門は生産部門と対話し、給与は人事部門と対話する必要があります。

相互依存

相互依存とは、システムのコンポーネントが互いに依存する方法を意味します。適切に機能するために、コンポーネントは調整され、指定された計画に従って一緒にリンクされます。 1つのサブシステムの出力は、他のサブシステムの入力として必要です。

統合

統合は、システムコンポーネントが相互に接続される方法に関係します。これは、各部分が固有の機能を実行する場合でも、システムの各部分がシステム内で連携して機能することを意味します。

中央目標

システムの目的は中心的でなければなりません。それは現実のものであるか、述べられている場合があります。組織が目標を述べ、別の目標を達成するために活動することは珍しくありません。

ユーザーは、設計と変換を成功させるために、分析の早い段階でコンピューターアプリケーションの主な目的を知る必要があります。

システムの要素

次の図は、システムの要素を示しています-

システム要素

出力と入力

システムの主な目的は、ユーザーに役立つ出力を生成することです。
入力は、処理のためにシステムに入力される情報です。
出力は処理の結果です。

プロセッサー

プロセッサは、入力から出力への実際の変換を伴うシステムの要素です。
システムの運用コンポーネントです。プロセッサは、出力仕様に応じて、入力を全体的または部分的に変更できます。
出力仕様が変わると、処理も変わります。場合によっては、プロセッサが変換を処理できるように入力も変更されます。

コントロール

制御要素はシステムをガイドします。
入力、処理、および出力を管理するアクティビティのパターンを制御するのは、意思決定サブシステムです。
コンピューターシステムの動作は、オペレーティングシステムとソフトウェアによって制御されます。システムのバランスを保つために、必要な入力の量と量は出力仕様によって決定されます。

フィードバック

フィードバックは、動的システムの制御を提供します。
正のフィードバックは本質的に日常的なものであり、システムのパフォーマンスを促進します。
ネガティブフィードバックは、本質的に情報提供であり、コントローラーにアクションの情報を提供します。

環境

環境は、組織が運営される「スーパーシステム」です。
これは、システムを攻撃する外部要素のソースです。
システムの機能方法を決定します。たとえば、組織の環境のベンダーや競合他社は、ビジネスの実際のパフォーマンスに影響を与える制約を提供する場合があります。

境界とインターフェース

システムは、その境界によって定義される必要があります。境界は、別のシステムとインターフェイスするときに、コンポーネント、プロセス、および相互関係を識別する制限です。
各システムには、影響範囲と制御範囲を決定する境界があります。
特定のシステムの境界に関する知識は、設計を成功させるために他のシステムとのインターフェースの性質を決定する上で重要です。

システムの種類

システムは、次のタイプに分けることができます-

物理システムまたは抽象システム

物理システムは具体的なエンティティです。それらに触れて感じることができます。
物理システムは、本質的に静的または動的です。たとえば、机と椅子はコンピューターセンターの静的な物理的な部分です。プログラムされたコンピューターは、ユーザーのニーズに応じてプログラム、データ、およびアプリケーションを変更できる動的システムです。
抽象システムは、実際のシステムの式、表現、またはモデルである可能性がある非物理エンティティまたは概念です。

オープンまたはクローズドシステム

オープンシステムは、その環境と対話する必要があります。システムからの入力を受け取り、システムの外部に出力を配信します。たとえば、変化する環境条件に適応しなければならない情報システム。
閉じたシステムは、その環境と相互作用しません。環境の影響から隔離されています。完全に閉じたシステムは、実際にはまれです。

適応および非適応システム

アダプティブシステムは、環境の変化に対応して、パフォーマンスを向上させ、存続させます。たとえば、人間、動物。
非適応システムは、環境に応答しないシステムです。たとえば、マシン。

恒久的または一時的なシステム

恒久システムは長時間持続します。たとえば、ビジネスポリシー。
一時的なシステムは指定された時間のために作られ、その後取り壊されます。たとえば、DJシステムはプログラム用にセットアップされ、プログラムの後に分解されます。

天然および製造システム

自然システムは自然によって作成されます。たとえば、太陽系、季節系。
製造システムは人工システムです。たとえば、ロケッツ、ダム、列車。

決定論的または確率的システム

確定的システムは予測可能な方法で動作し、システムコンポーネント間の相互作用は確実にわかっています。たとえば、水素2分子と酸素1分子が水を作ります。
確率システムは不確実な動作を示します。正確な出力は不明です。たとえば、天気予報、メール配信。

ソーシャル、ヒューマンマシン、マシンシステム

社会システムは人で構成されています。たとえば、ソーシャルクラブ、社会。
Human-Machine Systemでは、特定のタスクを実行するために人間と機械の両方が関与します。たとえば、コンピュータープログラミング。
機械システムは、人間の干渉が無視される場所です。すべてのタスクはマシンによって実行されます。たとえば、自律ロボット。

人工情報システム

これは、Direct Management Control（DMC）の下で、特定の組織のデータを管理するために相互接続された情報リソースのセットです。
このシステムには、組織の必要に応じて情報を生成するためのハードウェア、ソフトウェア、通信、データ、およびアプリケーションが含まれます。 +人工情報システムは3つのタイプに分けられます-
正式な情報システム-メモ、指示などの形での情報の流れに基づいて、トップレベルから下位レベルの管理まで。
非公式情報システム-これは、日々の仕事関連の問題を解決する従業員ベースのシステムです。
コンピュータベースのシステム-このシステムは、ビジネスアプリケーションを管理するためにコンピュータに直接依存しています。たとえば、自動図書館システム、鉄道予約システム、銀行システムなど。

システムモデル

回路図モデル

スケマティックモデルは、システム要素とそのリンケージを示す2次元グラフです。
情報フロー、マテリアルフロー、および情報フィードバックを示すために、さまざまな矢印が使用されます。

フローシステムモデル

フローシステムモデルは、システムを一緒に保持する材料、エネルギー、および情報の整然としたフローを示します。
たとえば、プログラム評価とレビュー手法（PERT）は、モデル形式で実世界のシステムを抽象化するために使用されます。

静的システムモデル

これらは、_activity–time_や_cost–quantity_などの関係のペアを表します。
たとえば、ガントチャートは、アクティビティと時間の関係の静的な図を提供します。

動的システムモデル

ビジネス組織は動的なシステムです。動的モデルは、アナリストが扱う組織またはアプリケーションのタイプを概算します。
システムの進行中の絶えず変化するステータスを示します。それはで構成されています-
システムに入る入力
変換が行われるプロセッサ
処理に必要なプログラム
処理の結果としての出力。

情報のカテゴリ

管理レベルに関連する情報には3つのカテゴリがあり、意思決定マネージャが作成します。

情報カテゴリ

戦略情報

この情報は、今後数年間の長期計画ポリシーの最上位の管理者に必要です。たとえば、収益、金融投資、人的資源、および人口増加の傾向。
このタイプの情報は、意思決定支援システム（DSS）を使用して実現されます。

経営情報

このタイプの情報は、月単位の短期および中期計画のために中間管理職が必要とします。たとえば、売上分析、キャッシュフロー予測、年次財務諸表。
管理情報システム（MIS）の助けを借りて達成されます。

運営情報

このタイプの情報は、日々の運用活動を実施するための日次および短期計画のために、低い管理職が必要とします。たとえば、従業員の出勤記録、期限切れの注文書、および現在の在庫を利用可能に保つ。
これは、データ処理システム（DPS）を使用して実現されます。

システム開発ライフサイクル

効果的なシステム開発ライフサイクル（SDLC）は、顧客の期待に応え、時間とコストの評価内で完了し、現在および計画中の情報技術インフラストラクチャで効果的かつ効率的に機能する高品質のシステムになります。

システム開発ライフサイクル（SDLC）は、ライフサイクル全体を通してシステムを開発または変更するためのポリシーと手順を含む概念モデルです。

SDLCは、情報システムを開発するためにアナリストによって使用されます。 SDLCには次のアクティビティが含まれます-

必要条件
設計
実装
テスト中
配備
オペレーション
メンテナンス

SDLCのフェーズ

システム開発ライフサイクルは、新しい情報システムまたは変更された情報システムの実装に必要なフェーズに作業を明示的に分割する体系的なアプローチです。

SDLCフェーズ

実現可能性調査または計画

既存のシステムの問題と範囲を定義します。
新しいシステムの概要を確認し、その目的を決定します。
プロジェクトの実行可能性を確認し、プロジェクトスケジュールを作成します。
このフェーズでは、システムの脅威、制約、統合、セキュリティも考慮されます。
プロジェクト全体の実行可能性レポートは、このフェーズの終わりに作成されます。

分析と仕様

情報を収集、分析、および検証します。
新しいシステムの要件とプロトタイプを定義します。
代替案を評価し、要件に優先順位を付けます。
エンドユーザーの情報ニーズを調べ、システムの目標を高めます。
システムのソフトウェア、ハードウェア、機能、およびネットワークの要件を指定するソフトウェア要件仕様（SRS）ドキュメントは、このフェーズの最後に準備されます。

システム設計

アプリケーション、ネットワーク、データベース、ユーザーインターフェイス、およびシステムインターフェイスの設計が含まれます。
SRSドキュメントを論理構造に変換します。論理構造には、プログラミング言語で実装できる詳細かつ完全な仕様セットが含まれています。
不測事態、トレーニング、メンテナンス、および運用計画を作成します。
提案された設計を確認します。最終設計がSRS文書に記載されている要件を満たしている必要があります。
最後に、次のフェーズで使用される設計ドキュメントを準備します。

実装

コーディングを通じてデザインをソースコードに実装します。
すべてのモジュールを組み合わせて、エラーと欠陥を検出するトレーニング環境にします。
エラーを含むテストレポートは、テストケース生成、テスト基準、テスト用のリソース割り当てなどのテスト関連タスクを含むテスト計画を通じて作成されます。
情報システムをその環境に統合し、新しいシステムをインストールします。

メンテナンス/サポート

電話のサポートや、システムのインストール後に必要なユーザー向けの物理的なオンサイトサポートなどのすべてのアクティビティを含めます。
ソフトウェアが一定期間にわたって受ける可能性のある変更を実装するか、ソフトウェアが顧客の場所に展開された後に新しい要件を実装します。
また、残留エラーの処理と、テスト段階の後でもシステムに存在する可能性のある問題の解決も含まれます。
大規模システムではより長い時間、小規模システムでは短時間で保守とサポートが必要になる場合があります。

システム分析と設計のライフサイクル

次の図は、分析および設計段階におけるシステムの完全なライフサイクルを示しています。

ライフサイクル

システムアナリストの役割

システムアナリストは、システムを十分に認識し、適切な指示を与えることでシステム開発プロジェクトを指導する人です。彼は、各フェーズで必要な開発タスクを実行するための技術的スキルと対人スキルを持つ専門家です。

彼は、情報システムの目的と組織の目標を一致させることを追求しています。

主な役割

さまざまなファクト検索手法を使用して、ユーザーの要件を定義および理解します。
ユーザーの合意を得て、要件を優先します。
事実または情報を収集し、ユーザーの意見を収集します。
より使いやすい適切なシステムに到達するための分析と評価を維持します。
多くの柔軟な代替ソリューションを提案し、最適なソリューションを選択し、コストとメリットを定量化します。
ユーザーおよびプログラマーが正確かつ詳細な形式で容易に理解できる特定の仕様を作成します。
モジュラーでなければならないシステムの論理設計を実装しました。
しばらく使用した後の評価の周期性を計画し、必要に応じてシステムを変更します。

システムアナリストの属性

次の図は、システムアナリストが持つべき属性を示しています-

アナリストの属性

対人能力

ユーザーおよびプログラマーとのインターフェース。
グループを促進し、小規模なチームをリードします。
期待を管理する。
十分な理解、コミュニケーション、販売、教育能力。
クエリを解決する自信を持っている動機。

分析能力

システム研究と組織知識
問題の特定、問題分析、および問題解決
健全な常識
トレードオフにアクセスする機能
新しい組織について学ぶ好奇心

管理能力

ユーザーの専門用語と実践を理解する。
リソースおよびプロジェクト管理。
変更およびリスク管理。
管理機能を完全に理解します。

技術的なスキル

コンピューターとソフトウェアの知識。
最新の開発に遅れないようにしてください。
システム設計ツールを知っている。
新技術に関する幅広い知識。

システム分析と設計-システム計画

要件決定とは何ですか？

要件は、データの処理またはキャプチャ、ビジネスアクティビティの制御、情報の生成、管理のサポートなど、新しいシステムの重要な機能です。

要件の決定には、既存のシステムを調査し、詳細を収集して、要件とは何か、それがどのように機能するか、どこで改善を行うべきかを調べることが含まれます。

要件決定における主要な活動

要件の予測

新しいシステムの特定の問題や機能、要件など、以前の経験に基づいてシステムの特性を予測します。
そうしないと、経験の浅いアナリストが気付かない領域の分析につながる可能性があります。しかし、調査を実施する際にショートカットが取られ、バイアスが導入された場合、要件予測は中途半端になります。

要件調査

現在のシステムを調査し、さらなる分析のためにその機能を文書化しています。
アナリストがファクトファインディング技術、プロトタイピング、コンピューター支援ツールを使用してシステム機能を文書化および説明するシステム分析の中心です。

要件仕様

これには、要件仕様を決定するデータの分析、新しいシステムの機能の説明、および提供される情報要件の指定が含まれます。
これには、事実データの分析、必須要件の特定、および要件達成戦略の選択が含まれます。

情報収集技術

事実発見技術の主な目的は、ユーザーが理解する正確なSRSを準備するためにアナリストが使用する組織の情報要件を決定することです。

理想的なSRS文書は-

完全で、明確で、専門用語がないこと。
運用、戦術、および戦略の情報要件を指定します。
ユーザーとアナリストの間で起こりうる紛争を解決します。
理解と設計を簡素化するグラフィカルな支援を使用します。

さまざまな情報収集技術があります-

インタビュー

システムアナリストは、面接により個人またはグループから情報を収集します。アナリストは、フォーマル、法的、政治的、または非公式のいずれかです。インタビューの成功は、インタビュアーとしてのアナリストのスキルに依存するためです。

それは2つの方法で行うことができます-

非構造化インタビュー-システムアナリストは、システムの基本情報を取得するために質疑応答セッションを実施します。
構造化されたインタビュー-クローズ（客観的）またはオープン（記述的）形式で回答する必要がある標準的な質問があります。

面接の利点

多くの場合、この方法は質的情報を収集する最適なソースです。
書面で効果的にコミュニケーションをとらない人や、アンケートに回答する時間がない人にとっては便利です。
情報は簡単に検証され、すぐにクロスチェックできます。
複雑なテーマを処理できます。
意見を求めれば、重要な問題を簡単に発見できます。
誤解のある分野のギャップを埋め、将来の問題を最小限に抑えます。

アンケート

この方法は、多くの人からシステムのさまざまな問題に関する情報を収集するためにアナリストによって使用されます。

アンケートには2種類あります-

自由回答形式の質問票-簡単に正しく解釈できる質問で構成されています。問題を調査し、特定の回答の方向に導くことができます。
クローズドエンドのアンケート-システムアナリストがすべての可能な回答を効果的にリストするときに使用される質問で構成されます。これらは相互に排他的です。

アンケートの利点

同じ場所にいないユーザーの興味、態度、感情、信念を調査するのに非常に効果的です。
特定のグループのどの割合が提案されたシステムの特定の機能を承認または不承認にするかを知ることは、状況において役立ちます。
システムプロジェクトに特定の方向性を示す前に、全体的な意見を判断することが役立ちます。
より信頼性が高く、正直な回答の高い機密性を提供します。
事実情報を選択し、メールで送信して郵送できる統計データの収集に適しています。

記録、手順、およびフォームのレビュー

既存の記録、手順、およびフォームのレビューは、現在のシステム機能、その操作、またはアクティビティを記述するシステムへの洞察を見つけるのに役立ちます。

メリット

ユーザーが他の人に課す前に、ユーザーが自分で組織または運用に関する知識を得るのに役立ちます。
手順マニュアルとフォームが現在のシステムの形式と機能を説明しているため、短時間で現在の操作を文書化するのに役立ちます。
組織で処理されるトランザクションについて明確に理解し、処理のための入力を識別し、パフォーマンスを評価できます。
アナリストがサポートする必要のある操作に関してシステムを理解するのに役立ちます。
問題、その影響を受ける部分、および提案された解決策について説明します。

観察

これは、人、イベント、オブジェクトに気づき、観察することで情報を収集する方法です。アナリストは、組織を訪問して現在のシステムの動作を観察し、システムの要件を理解します。

メリット

これは、情報を収集するための直接的な方法です。
収集されたデータの信頼性に問題がある場合、またはシステムの特定の側面の複雑さがエンドユーザーによる明確な説明を妨げる場合に役立ちます。
より正確で信頼性の高いデータが生成されます。
不完全で古くなったドキュメントのあらゆる側面を生成します。

共同アプリケーション開発（JAD）

IBMによって開発された新しい手法であり、所有者、ユーザー、アナリスト、デザイナー、およびビルダーが、組織化された集中的なワークショップを使用してシステムを定義および設計します。 JADは、専門的なスキルを備えたワークショップのファシリテーターとして、アナリストを訓練しました。

JADの利点*
従来のインタビューとフォローアップ会議の数か月を置き換えることにより、時間とコストを節約します。
共同の問題解決をサポートする組織文化で役立ちます。
複数レベルの従業員間の正式な関係を促進します。
それは創造的にデザインの開発につながる可能性があります。
迅速な開発を可能にし、情報システムの所有権を改善します。

二次研究またはバックグラウンドリーディング

この方法は、収集された情報にアクセスして情報を収集するために広く使用されています。これには、マーケティング担当者が内部または外部ソースから使用した以前に収集された情報が含まれます。

メリット

インターネットが利用できるため、よりオープンにアクセスできます。
低コストと時間で貴重な情報を提供します。
一次研究の先駆けとして機能し、一次研究の焦点を調整します。
研究者は、使用する手順とそれらを収集する際に問題があるため、研究に価値があるかどうかを結論付けるために使用します。

実現可能性調査

実現可能性調査は、システムの調査が開発に適しているべきかどうかを経営者が決定するのに役立つ予備調査と考えることができます。

既存のシステムの改善、新しいシステムの開発の可能性を特定し、システムのさらなる開発のための洗練された推定値を生成します。
問題の概要を取得し、実行可能または適切な解決策が存在するかどうかを判断するために使用されます。
実行可能性調査の主な目的は、問題を解決するのではなく、問題の範囲を取得することです。
実現可能性調査の結果は、提案されたシステムの完全な性質と範囲を含む決定文書としての正式なシステム提案行為です。

実行可能性分析に含まれるステップ

実行可能性分析を実行しながら、次の手順に従う必要があります-

プロジェクトチームを編成し、プロジェクトリーダーを任命します。
システムのフローチャートを作成します。
現在のシステムの欠陥を特定し、目標を設定します。
目標を達成するために、代替ソリューションまたは潜在的な候補システムを列挙します。
技術的な実現可能性、運用上の実現可能性など、各代替案の実現可能性を判断する
各候補システムのパフォーマンスと費用対効果を重視します。
他の選択肢をランク付けし、最適な候補システムを選択します。
承認のために経営陣に最終プロジェクトディレクティブのシステム提案を準備します。

フィージビリティ分析

実現可能性のタイプ

経済的実現可能性

費用/便益分析法を使用して、候補システムの有効性を評価しています。
これは、組織にとってのメリットとコストの点で、候補システムからの最終的なメリットを示しています。
経済的実現可能性分析（EFS）の主な目的は、投資ファンドが提案にコミットする前に候補システムの経済的要件を推定することです。
候補システムの開発に伴う最低レベルのリスクに加えて、早期かつ最高の資金回収により組織の純資産を最大化する代替案を好みます。

技術的実現可能性

各実装の代替案の技術的実現可能性を調査します。
ソリューションを既存のテクノロジーでサポートできるかどうかを分析および決定します。
アナリストは、新しい要件を満たす現在の技術リソースをアップグレードするか追加するかを決定します。
候補システムは、技術的な拡張をサポートできる範囲で適切な応答を提供します。

運用可能性

システムが開発および実装されると、システムが効果的に動作しているかどうかを判断します。
管理者は、提案されたシステムと、現在の組織環境で実行可能なそのシステムをサポートする必要があります。
ユーザーが影響を受けるかどうかを分析し、システムのメリットに影響する可能性のある変更または新しいビジネス手法を受け入れます。
また、候補システムのコンピューターリソースとネットワークアーキテクチャが実行可能であることを保証します。

行動の実現可能性

新しいシステムの開発に対するユーザーの態度または行動を評価および推定します。
システムが、ビジネスを行う新しい方法について従業員の職務状況を教育、再訓練、異動、変更するために特別な努力を必要とするかどうかを判断するのに役立ちます。

スケジュールの実現可能性

これにより、プロジェクトは所定の時間制約またはスケジュール内で完了する必要があります。
また、プロジェクトの期限が妥当かどうかを検証および検証します。

構造化分析

アナリストはさまざまなツールを使用して、情報システムを理解および説明します。方法の1つは、構造化分析を使用することです。

構造化分析とは何ですか？

構造化分析は、分析者がシステムとそのアクティビティを論理的に理解できるようにする開発方法です。

これは、既存のシステムの目的を分析および改善し、ユーザーが簡単に理解できる新しいシステム仕様を開発するグラフィカルツールを使用する体系的なアプローチです。

次の属性があります-

アプリケーションのプレゼンテーションを指定するグラフィックです。
システムフローを明確に把握できるように、プロセスを分割します。
物理的ではなく論理的です。つまり、システムの要素はベンダーやハードウェアに依存しません。
これは、高レベルの概要から低レベルの詳細まで機能するアプローチです。

構造化分析ツール

構造化分析では、さまざまなツールと手法がシステム開発に使用されます。彼らは-

データフロー図
データ辞書
決定木
決定表
構造化された英語
疑似コード

構造化ツール

データフロー図（DFD）またはバブルチャート

これは、システムの要件をグラフィカルな形式で表現するために、Larry Constantineによって開発された手法です。

システムのさまざまな機能間のデータの流れを示し、現在のシステムの実装方法を指定します。
これは、要件仕様を最低レベルの詳細に機能的に分割する設計段階の初期段階です。
そのグラフィカルな性質により、ユーザーとアナリスト、またはアナリストとシステム設計者の間の優れたコミュニケーションツールになります。
システムが処理するデータ、実行される変換、保存されるデータ、生成される結果、およびそれらが流れる場所の概要を示します。

DFDの基本要素

DFDは理解しやすく、必要な設計が明確ではなく、ユーザーがコミュニケーションに表記言語を使用する場合に非常に効果的です。ただし、最も正確で完全なソリューションを得るには、多数の反復が必要です。

次の表は、DFDの設計に使用される記号とその重要性を示しています-

Symbol Name	Symbol	Meaning
Square	Square	Source or Destination of Data
Arrow	Arrow	Data flow
Circle	Circle	Process transforming data flow
Open Rectangle	Rectangle	Data Store

DFDのタイプ

DFDには、物理DFDと論理DFDの2つのタイプがあります。次の表に、物理DFDと論理DFDを区別するポイントを示します。

Physical DFD	Logical DFD
It is implementation dependent. It shows which functions are performed.	It is implementation independent. It focuses only on the flow of data between processes.
It provides low level details of hardware, software, files, and people.	It explains events of systems and data required by each event.
It depicts how the current system operates and how a system will be implemented.	It shows how business operates; not how the system can be implemented.

コンテキスト図

コンテキスト図は、システムの概要を示す1つのDFDによってシステム全体を理解するのに役立ちます。まず、主要なプロセスについてはほとんど説明せずに言及し、次にトップダウンアプローチでプロセスの詳細を説明します。

混乱管理のコンテキスト図を以下に示します。

コンテキスト図

データ辞書

データディクショナリは、システム内のデータ要素の構造化されたリポジトリです。すべてのDFDデータ要素の説明、つまりデータフロー、データストア、データストアに格納されているデータ、およびプロセスの詳細と定義が格納されます。

データディクショナリは、アナリストとユーザー間のコミュニケーションを改善します。データベースの構築において重要な役割を果たします。ほとんどのDBMSには、標準機能としてデータディクショナリがあります。たとえば、次の表を参照してください-

Sr.No.	Data Name	Description	No. of Characters
1	ISBN	ISBN Number	10
2	TITLE	title	60
3	SUB	Book Subjects	80
4	ANAME	Author Name	15

決定木

決定木は、意思決定を記述し、コミュニケーションの問題を回避することにより、複雑な関係を定義する方法です。デシジョンツリーは、水平ツリーフレームワーク内の代替のアクションと条件を示す図です。したがって、最初に考慮すべき条件、2番目などを示します。

デシジョンツリーは、各条件とそれらの許容されるアクションの関係を表します。正方形のノードはアクションを示し、円は条件を示します。アナリストに決定のシーケンスを考慮させ、実際に行わなければならない決定を特定させます。

デシジョンツリー

デシジョンツリーの主な制限は、テストに使用できる条件の他の組み合わせを記述するための形式の情報がないことです。これは、条件とアクション間の関係の単一の表現です。

たとえば、次の決定木を参照してください-

決定例

決定表

決定表は、複雑な論理関係を正確に記述し、簡単に理解できる方法です。

結果のアクションが、独立した条件の1つまたは複数の組み合わせの発生に依存する状況で役立ちます。
問題とアクションを定義するための行または列を含むマトリックスです。

決定表のコンポーネント

条件スタブ-チェック対象のすべての条件をリストする左上の象限にあります。
アクションスタブ-このような条件を満たすために実行されるすべてのアクションを概説する左下の象限にあります。
条件エントリ-右上の象限にあり、条件スタブ象限で尋ねられた質問への回答を提供します。
アクションエントリ-条件入力象限の条件への回答から生じる適切なアクションを示す右下の象限にあります。

決定テーブルのエントリは、条件の組み合わせとアクションのコース間の関係を定義する決定ルールによって与えられます。ルールセクションで、

Yは条件の存在を示します。
Nは満たされていない条件を表します。
空白-アクションに対して、それは無視されることになっています。
実行されるアクション状態に対してX（またはチェックマークが付きます）。

たとえば、次の表を参照してください-

CONDITIONS	Rule 1	Rule 2	Rule 3	Rule 4
Advance payment made	Y	N	N	N
Purchase amount = Rs 10,000/-	-	Y	Y	N
Regular Customer	-	Y	N	-
ACTIONS
Give 5% discount	X	X	-	-
Give no discount	-	-	X	X

構造化された英語

構造英語は、プロセスをより理解しやすく正確に記述する構造化プログラミング言語から派生しています。これは、アクションの操作を実行するように設計された構造と命令文を使用する手続き型ロジックに基づいています。

プログラム内のシーケンスとループを考慮する必要があり、問題に決定を伴う一連のアクションが必要な場合に最適です。
厳密な構文規則はありません。順次決定構造と反復の観点からすべてのロジックを表現します。

たとえば、アクションの次のシーケンスを参照してください-

if customer pays advance
   then
      Give 5% Discount
   else
      if purchase amount >=10,000
         then
            if  the customer is a regular customer
               then Give 5% Discount
            else  No Discount
         end if
      else No Discount
   end if
end if

疑似コード

疑似コードはどのプログラミング言語にも適合せず、ロジックを平易な英語で表現します。

物理設計中および物理設計後に実際のコーディングなしで物理プログラミングロジックを指定できます。
構造化プログラミングと組み合わせて使用されます。
プログラムのフローチャートを置き換えます。

適切なツールを選択するためのガイドライン

次のガイドラインを使用して、要件に合った最適なツールを選択してください-

優れたシステムドキュメントを提供するには、高レベルまたは低レベルの分析でDFDを使用します。
データディクショナリを使用して、システムのデータ要件を満たすための構造を簡素化します。
ループが多く、アクションが複雑な場合は、構造化された英語を使用してください。
チェックする条件が多数あり、ロジックが複雑な場合は、意思決定表を使用します。
条件の順序付けが重要であり、テストする条件が少ない場合は、決定木を使用します。

システム分析と設計-システム設計

システム設計*は、問題のあるドメインと既存のシステムとの間のギャップを管理可能な方法で埋めるフェーズです。このフェーズでは、ソリューションドメイン、つまり 「実装方法」

これは、SRSドキュメントを実装可能な形式に変換し、システムの動作を決定する段階です。

このフェーズでは、システム開発の複雑なアクティビティがいくつかの小さなサブアクティビティに分割され、これらが互いに連携してシステム開発の主な目的を達成します。

目的設計

システム設計への入力

システム設計は、次の入力を取ります-

作業明細書
要件決定計画
現状分析
概念的なデータモデル、修正されたDFD、およびメタデータ（データに関するデータ）を含む提案されたシステム要件。

システム設計の出力

システム設計は、以下の出力を提供します-

提案されたシステムのインフラストラクチャと組織の変更。
多くの場合、リレーショナルスキーマであるデータスキーマ。
テーブル/ファイルおよび列/データ項目を定義するメタデータ。
プログラム構造をグラフィカルに説明する機能階層図またはWebページマップ。
プログラム内の各モジュールの実際のコードまたは擬似コード。
提案されたシステムのプロトタイプ。

システム設計の種類

論理設計

論理設計は、システムのデータフロー、入力、および出力の抽象的な表現に関係します。入力（ソース）、出力（宛先）、データベース（データストア）、手順（データフロー）をすべてユーザー要件を満たす形式で記述します。

システムの論理設計の準備中に、システムアナリストは、システムに出入りする情報の流れと必要なデータソースを仮想的に決定する詳細レベルでユーザーのニーズを特定します。データフロー図、E-R図モデリングが使用されます。

フィジカルデザイン

物理設計は、システムの実際の入出力プロセスに関連しています。データがシステムに入力され、検証され、処理され、出力として表示される方法に焦点を当てています。

候補システムの動作を正確に指定する設計仕様を定義することにより、作業システムを作成します。ユーザーインターフェイスデザイン、プロセスデザイン、およびデータデザインに関係します。

それは次のステップで構成されています-

入出力メディアの指定、データベースの設計、およびバックアップ手順の指定。
計画システムの実装。
テストおよび実装計画を策定し、新しいハードウェアとソフトウェアを指定します。
コスト、メリット、変換日、システムの制約を更新します。

建築デザイン

また、システムアーキテクチャの設計に焦点を当てた高レベル設計としても知られています。システムの構造と動作を説明します。システム開発プロセスのさまざまなモジュール間の構造と関係を定義します。

きめ細かなデザイン

それは建築設計に従い、各モジュールの開発に焦点を当てています。

概念的なデータモデリング

これは、すべての主要なエンティティと関係を含む組織データの表現です。システムアナリストは、提案されたシステムの範囲と要件をサポートする現在のシステムの概念データモデルを開発します。

概念的なデータモデリングの主な目的は、可能な限り多くのデータの意味を把握することです。今日、ほとんどの組織は、特別な表記法を使用してデータに関する可能な限り多くの意味を表すE-Rモデルを使用した概念データモデリングを使用しています。

エンティティ関係モデル

これは、組織のさまざまなエンティティ間の関係を記述するのに役立つデータベース設計で使用される手法です。

E-Rモデルで使用される用語

ENTITY -アプリケーション内の異なる現実世界のアイテムを指定します。例：ベンダー、アイテム、学生、コース、教師など。
関係-エンティティ間の意味のある依存関係です。たとえば、ベンダーはアイテムを提供し、教師はコースを教え、その後、サプライとコースは関係になります。
属性-関係のプロパティを指定します。たとえば、ベンダーコード、学生名。 E-Rモデルで使用される記号とそれぞれの意味-

次の表は、E-Rモデルで使用される記号とその重要性を示しています-

Symbol	Meaning
Entity	Entity
Weak Entity	Weak Entity
Relationship	Relationship
Identity Relationship	Identity Relationship
Attributes	Attributes
Key Attributes	Key Attributes
Multivalued	Multivalued
Composite Attribute	Composite Attribute
Derived Attribute	Derived Attributes
Participation	Total Participation of E2 in R
Cardinality	Cardinality Ratio 1:N for E1:E2 in R

2つのデータセットの間には、1対1、1対多、および多対多の3種類の関係が存在します。

ファイル編成

レコードがファイル内に保存される方法を説明します。

4つのファイル編成方法があります-

シリアル-レコードは時系列順に（入力または発生順に）保存されます。例-電話料金、ATMトランザクション、電話キューの記録。
Sequential -レコードは、レコードを一意に識別する値を含むキーフィールドに基づいた順序で格納されます。例-電話帳。
直接（相対）-各レコードは、デバイスの物理アドレスまたは場所に基づいて保存されます。住所は、レコードのキーフィールドに保存されている値から計算されます。ランダム化ルーチンまたはハッシュアルゴリズムが変換を行います。
インデックス付き-レコードは、インデックスを使用して連続的および非連続的に処理できます。

比較

ファイルアクセス

シーケンシャルアクセスまたはランダムアクセスを使用してファイルにアクセスできます。ファイルアクセスメソッドを使用すると、コンピュータープログラムでファイルのレコードを読み書きできます。

シーケンシャルアクセス

ファイルのすべてのレコードは、ファイルの終わり（EOF）に達するまで最初のレコードから処理されます。いつでもファイル上の多数のレコードにアクセスする必要がある場合に効率的です。テープに格納されたデータ（シーケンシャルアクセス）は、シーケンシャルにのみアクセスできます。

直接（ランダム）アクセス

記録は、他の記録との相対的な位置ではなく、デバイス上の物理的な位置または住所を知ることで特定されます。 CDデバイスに保存されているデータ（直接アクセス）には、連続的またはランダムにアクセスできます。

組織システムで使用されるファイルの種類

組織システムで使用されるファイルの種類は次のとおりです-

マスターファイル-システムの現在の情報が含まれています。たとえば、顧客ファイル、学生ファイル、電話帳。
テーブルファイル-まれにしか変更されず、表形式で保存されるマスターファイルの一種です。たとえば、郵便番号を保存します。
トランザクションファイル-ビジネスアクティビティから生成された日々の情報が含まれています。マスターファイルの更新または処理に使用されます。たとえば、従業員の住所。
一時ファイル-システムが必要とするときに作成され、使用されます。
ミラーファイル-他のファイルとまったく同じです。オリジナルが使用できなくなった場合のダウンタイムのリスクを最小限に抑えます。元のファイルが変更されるたびに変更する必要があります。
ログファイル-マスターファイルに加えられた変更を記録するために、マスターおよびトランザクションレコードのコピーが含まれます。監査を容易にし、システム障害が発生した場合の回復メカニズムを提供します。
アーカイブファイル-他のファイルの履歴バージョンを含むバックアップファイル。

ドキュメント管理

文書化は、参照または運用目的で情報を記録するプロセスです。それは、それを必要とするユーザー、マネージャー、およびITスタッフを支援します。システムの進捗を簡単に追跡するには、準備されたドキュメントを定期的に更新する必要があります。

システムの実装後、システムが正常に機能していない場合、ドキュメントは管理者がシステム内のデータの流れを理解して欠陥を修正し、システムを機能させるのに役立ちます。

プログラマーまたはシステムアナリストは通常、プログラムとシステムのドキュメントを作成します。通常、システムアナリストは、ユーザーがシステムを学習できるようにドキュメントを準備する責任があります。大企業では、テクニカルライターを含むテクニカルサポートチームが、ユーザードキュメントとトレーニング資料の準備を支援する場合があります。

利点

システムのダウンタイムを削減し、コストを削減し、メンテナンスタスクをスピードアップできます。
現在のシステムの正式なフローを明確に説明し、入力データのタイプと出力の生成方法を理解するのに役立ちます。
システムに関する技術ユーザーと非技術ユーザーの間の効果的かつ効率的な通信方法を提供します。
新しいユーザーのトレーニングを容易にし、システムの流れを簡単に理解できるようにします。
ユーザーがトラブルシューティングなどの問題を解決するのに役立ち、管理者が組織システムのより良い最終決定を下すのに役立ちます。
システムの内部または外部の動作をより適切に制御できます。

ドキュメントの種類

システム設計に関しては、次の4つの主要なドキュメントがあります-

プログラムのドキュメント
システムのドキュメント
操作ドキュメント
ユーザードキュメント

プログラムのドキュメント

すべてのプログラムモジュールの入力、出力、および処理ロジックについて説明します。
プログラムの文書化プロセスは、システム分析フェーズで開始され、実装中も継続されます。
このドキュメントは、内部および外部のコメントと説明によって十分にサポートされ、理解および保守が容易なモジュールを構築するプログラマーをガイドします。

運用ドキュメント

操作ドキュメントには、オンラインおよび印刷出力の処理と配布に必要なすべての情報が含まれています。運用文書は、明確で簡潔で、可能であればオンラインで入手できるようにしてください。

次の情報が含まれています-

プログラム、システムアナリスト、プログラマー、およびシステム識別。
レポート、実行頻度、期限などの印刷出力のスケジューリング情報。
入力ファイル、そのソース、出力ファイル、およびその宛先。
電子メールおよびレポート配布リスト。
オンラインフォームを含む特別なフォームが必要です。
オペレーターおよび再起動手順へのエラーおよび情報メッセージ。
セキュリティ要件などの特別な指示。

ユーザードキュメント

システムと対話するユーザーへの指示と情報が含まれています。たとえば、ユーザーマニュアル、ヘルプガイド、チュートリアルなどです。ユーザーのドキュメントは、ユーザーのトレーニングや参照目的に役立ちます。すべてのレベルのユーザーが明確で理解しやすく、すぐにアクセスできる必要があります。

ユーザー、システム所有者、アナリスト、プログラマーはすべて、ユーザーガイドの作成に力を入れています。

ユーザードキュメントには、次のものが含まれます。

すべての主要なシステム機能、機能、および制限を明確に説明するシステム概要。
ソースドキュメントの内容、準備、処理、およびサンプルの説明。
メニューおよびデータ入力画面のオプション、内容、および処理手順の概要。
サンプルなど、定期的に作成されるレポートまたはユーザーのリクエストに応じて利用できるレポートの例。
セキュリティおよび監査証跡情報。
特定の入力、出力、または処理要件に対する責任の説明。
変更を要求し、問題を報告するための手順。
例外とエラー状況の例。
よくある質問（FAQ）。
ユーザーマニュアルを更新するためのヘルプと手順の入手方法の説明。

システムドキュメント

システム文書は、ISの技術仕様およびISの目的の達成方法として機能します。ユーザー、管理者、IS所有者は、システムのドキュメントを参照する必要はありません。システム文書は、変更が行われたときのISの技術的側面を理解するための基礎を提供します。

IS内の各プログラムとIS全体を説明しています。
システムの機能、実装方法、実行順序に関するIS全体の各プログラムの目的、プログラムとの間でやり取りされる情報、およびシステム全体の流れについて説明します。
データディクショナリエントリ、データフロー図、オブジェクトモデル、画面レイアウト、ソースドキュメント、およびプロジェクトを開始したシステム要求が含まれます。
システムのドキュメントのほとんどは、システム分析およびシステム設計の段階で作成されます。
システムの実装中に、アナリストはシステムのドキュメントを確認して、それが完全で正確で最新であること、および実装プロセス中に行われた変更を含めていることを確認する必要があります。

設計戦略

トップダウン戦略

トップダウン戦略では、モジュール方式を使用してシステムの設計を開発します。最上位または最上位のモジュールから始まり、最下位のモジュールに向かって移動するため、そう呼ばれます。

この手法では、ソフトウェアを開発するための最高レベルのモジュールまたはメインモジュールが識別されます。メインモジュールは、各モジュールによって実行されるタスクに基づいて、いくつかのより小さくシンプルなサブモジュールまたはセグメントに分割されます。次に、各サブモジュールは、さらに下位レベルのいくつかのサブモジュールにさらに分割されます。各モジュールを複数のサブモジュールに分割するこのプロセスは、さらに細分化できない最下位レベルのモジュールが識別されなくなるまで続きます。

トップダウン

ボトムアップ戦略

ボトムアップ戦略は、モジュール方式に従ってシステムの設計を開発します。最下部または最も基本的なレベルのモジュールから始まり、最上位のモジュールに向かって移動するため、そう呼ばれます。

この手法では、

最も基本的なレベルまたは最も低いレベルのモジュールが識別されます。
これらのモジュールは、各モジュールで実行される機能に基づいてグループ化され、次のより高いレベルのモジュールを形成します。
次に、これらのモジュールをさらに組み合わせて、次の上位モジュールを形成します。
いくつかのより単純なモジュールをグループ化してより高いレベルのモジュールを形成するこのプロセスは、システム開発プロセスのメインモジュールが達成されるまで続きます。

ボトムアップ

構造化設計

構造化設計は、開発システムの入力と出力の識別に役立つデータフローベースの方法論です。構造化設計の主な目的は、複雑さを最小限に抑え、プログラムのモジュール性を高めることです。構造化された設計は、システムの機能面を記述するのにも役立ちます。

構造化設計では、システム仕様は、DFDの助けを借りてソフトウェア開発に含まれるデータの流れとプロセスのシーケンスをグラフィカルに表現するための基礎として機能します。ソフトウェアシステムのDFDを開発したら、次のステップは構造図を開発することです。

構造化設計

モジュール化

構造化設計は、プログラムを小さな独立したモジュールに分割します。これらは、下に詳細が示された上から下に向かって構成されています。

したがって、構造化設計では、モジュール化または分解と呼ばれるアプローチを使用して、複雑さを最小限に抑え、問題をより小さなセグメントに分割することで問題を管理します。

メリット

重要なインターフェースが最初にテストされます。
抽象化を提供します。
複数のプログラマーが同時に作業することができます。
コードを再利用できます。
コントロールを提供し、士気を向上させます。
構造の識別が容易になります。

構造化チャート

構造化チャートは、システム開発のさまざまなモジュールと各モジュール間の関係を定義するモジュール式のトップダウンシステムを設計するための推奨ツールです。システムモジュールとそれらの間の関係を示しています。

モジュール、接続矢印、または線を表す長方形のボックスで構成される図で構成されます。

制御モジュール-*下位モジュール*と呼ばれる、下位レベルのモジュールを指示する上位レベルのモジュールです。
ライブラリモジュール-再利用可能なモジュールであり、チャートの複数のポイントから呼び出すことができます。

グラフ

構造化チャートを設計するには、2つの異なるアプローチがあります-

Transform-Centered Structured Charts -すべてのトランザクションが同じパスをたどるときに使用されます。
トランザクション-中心構造化チャート-すべてのトランザクションが同じパスをたどらない場合に使用されます。

構造フローチャートを使用する目的

トップダウン設計を奨励するため。
モジュールの概念をサポートし、適切なモジュールを識別するため。
システムのサイズと複雑さを表示します。
各機能内の容易に識別可能な機能およびモジュールの数を特定するため。
特定可能な各機能が管理可能なエンティティであるか、またはより小さなコンポーネントに分割する必要があるかを示します。

システムの複雑さに影響する要因

良質のシステムソフトウェアを開発するには、優れた設計を開発する必要があります。したがって、システムの設計を開発する際の主な焦点は、ソフトウェア設計の品質です。優れた品質のソフトウェア設計は、ソフトウェア開発の複雑さとコスト支出を最小限に抑えるものです。

システムの複雑さを判断するのに役立つシステム開発に関連する2つの重要な概念は、*カップリング*と*凝集*です。

カップリング

結合は、コンポーネントの独立性の尺度です。システム開発の各モジュールの依存関係の度合いを定義します。実際には、これは、システム内のモジュール間の結合が強いほど、システムの実装と保守が難しくなることを意味します。

各モジュールには、他のモジュールとのシンプルでクリーンなインターフェースが必要です。また、最小限のデータ要素をモジュール間で共有する必要があります。

高カップリング

これらのタイプのシステムには、相互に依存するプログラム単位との相互接続があります。 1つのサブシステムを変更すると、他のサブシステムに大きな影響を与えます。

高度に結合

低カップリング

これらのタイプのシステムは、独立した、またはほぼ独立したコンポーネントで構成されています。 1つのサブシステムを変更しても、他のサブシステムには影響しません。

低結合

カップリング対策

コンテンツカップリング-あるコンポーネントが実際に別のコンポーネントを変更する場合、変更されたコンポーネントは変更に完全に依存します。
共通結合-共通データストアからデータにアクセスできるようにシステム設計を整理することにより、結合の量がいくぶん削減される場合。
Control Coupling -あるコンポーネントが別のコンポーネントのアクティビティを制御するためにパラメータを渡すとき。
スタンプカップリング-あるコンポーネントから別のコンポーネントに情報を渡すためにデータ構造が使用される場合。
データ結合-データのみが渡される場合、コンポーネントはこの結合によって接続されます。

凝集

凝集度は、そのコンポーネント間の関係の近さの尺度です。モジュールのコンポーネントの依存関係の量を定義します。実際には、これはシステム設計者が次のことを確認する必要があることを意味します-

重要なプロセスを断片化されたモジュールに分割しません。
DFD上のプロセスとして表される無関係なプロセスを無意味なモジュールにまとめません。

最適なモジュールは、機能的に凝集したモジュールです。最悪のモジュールは、偶然にまとまりのあるものです。

最悪の凝集度

偶発的な凝集は、部品が他の部品と無関係であるコンポーネントに見られます。

論理的結合-論理的に関連するいくつかの機能またはデータ要素が同じコンポーネントに配置される場所です。
Temporal Cohesion -システムの初期化または変数の設定に使用されるコンポーネントがいくつかの機能を順番に実行しますが、機能は関連するタイミングによって関連付けられます。
手続き的に結合-この順序を保証するためだけに、関数がコンポーネントにグループ化される場合です。
Sequential Cohesion -コンポーネントのある部分からの出力が、その次の部分への入力である場合です。

入力/出力およびフォーム設計

入力デザイン

情報システムでは、入力は、出力を生成するために処理される生データです。入力設計中、開発者はPC、MICR、OMRなどの入力デバイスを考慮する必要があります。

したがって、システム入力の品質がシステム出力の品質を決定します。適切に設計された入力フォームと画面には、次のプロパティがあります-

情報の保存、記録、取得など、特定の目的を効果的に果たす必要があります。
これにより、正確で適切な完了が保証されます。
簡単に記入できるようにする必要があります。
ユーザーの注意、一貫性、シンプルさに焦点を当てる必要があります。
これらの目的はすべて、次に関する基本的な設計原則の知識を使用して得られます-
システムに必要な入力は何ですか？
エンドユーザーがフォームおよび画面のさまざまな要素にどのように対応するか。

入力設計の目的

入力設計の目的は次のとおりです-

データ入力および入力手順を設計するには
入力音量を下げるには
データキャプチャ用のソースドキュメントを設計したり、他のデータキャプチャ方法を考案したりするには
入力データレコード、データ入力画面、ユーザーインターフェイス画面などを設計するため
検証チェックを使用し、効果的な入力コントロールを開発するため。

データ入力方法

データ入力中のエラーを防ぐために、適切なデータ入力方法を設計することが重要です。これらの方法は、顧客が手動でフォームにデータを入力し、後でデータ入力オペレーターが入力するか、ユーザーがPCでデータを直接入力するかによって異なります。

システムは、ユーザーが間違いを犯さないようにする必要があります-

読みやすいように十分なスペースを残して、フォームデザインを明確にします。
フォームに記入する指示をクリアします。
明確なフォームデザイン。
キーストロークを減らします。
即時エラーフィードバック。

一般的なデータ入力方法のいくつかは-

バッチインプットメソッド（オフラインデータインプットメソッド）
オンラインデータ入力方法
コンピューター読み取り可能なフォーム
インタラクティブなデータ入力

入力整合性制御

入力整合性制御には、エンドユーザーによる一般的な入力エラーを排除するための多くの方法が含まれています。また、個々のフィールドの値のチェックも含まれます。フォーマットとすべての入力の完全性の両方について。

データ入力およびその他のシステム操作の監査証跡は、トランザクションログを使用して作成され、データベースに導入されたすべての変更の記録を提供して、障害が発生した場合のセキュリティと復旧手段を提供します。

出力設計

出力の設計は、どのシステムでも最も重要なタスクです。出力設計時に、開発者は必要な出力の種類を特定し、必要な出力コントロールとプロトタイプレポートレイアウトを検討します。

出力設計の目的

入力設計の目的は次のとおりです-

意図した目的に役立ち、不要な出力の生成を排除する出力設計を開発すること。
エンドユーザーの要件を満たす出力設計を開発する。
適切な量の出力を提供するため。
適切な形式で出力を形成し、適切な人に送信します。
適切な決定を下すために出力を時間通りに利用できるようにする。

ここで、さまざまな種類の出力を見てみましょう-

外部出力

メーカーは、プリンターの外部出力を作成および設計します。外部出力により、システムは受信者側でトリガーアクションを残すか、受信者にアクションを確認できます。

一部の外部出力はターンアラウンド出力として設計されており、フォームとして実装され、入力としてシステムに再入力されます。

内部出力

内部出力はシステム内にあり、エンドユーザーとマネージャーによって使用されます。彼らは意思決定と報告の管理をサポートします。

管理情報によって生成されるレポートには3種類あります-

詳細レポート-管理の計画と制御を支援するために生成されたフィルタリングや制限がほとんどない現在の情報が含まれています。
概要レポート-詳細を必要としない管理者向けに生成され、分類および要約された傾向と潜在的な問題が含まれます。
例外レポート-例外として、情報としてマネージャーに提示する前に、何らかの条件または標準にフィルター処理されたデータが含まれます。

出力整合性制御

出力整合性制御には、受信システムを識別するためのルーティングコード、およびネットワークプロトコルによって処理されるメッセージの正常な受信を確認するための検証メッセージが含まれます。

印刷または画面形式のレポートには、レポート印刷の日付と時刻とデータを含める必要があります。複数ページのレポートには、レポートのタイトルまたは説明、およびページネーションが含まれます。通常、事前印刷フォームにはバージョン番号と発効日が含まれています。

フォームデザイン

フォームとレポートは、どちらも入力および出力設計の成果物であり、指定されたデータで構成されるビジネスドキュメントです。主な違いは、フォームはデータ入力用のフィールドを提供しますが、レポートは読み取り専用に使用されることです。たとえば、注文フォーム、雇用およびクレジット申請など。

フォームの設計中に、設計者は知っておく必要があります-
誰がそれらを使用しますか
彼らはどこに届けられますか
フォームまたはレポートの目的
フォームの設計中に、自動化された設計ツールは、フォームとレポートのプロトタイプを作成し、評価のためにエンドユーザーに提示する開発者の能力を強化します。

グッドフォームデザインの目的

良いフォームデザインは、次のことを保証するために必要です-

適切なシーケンス、情報、および明確なキャプションを提供することにより、画面をシンプルに保つため。
適切なフォームを使用して、目的を達成する。
正確にフォームを完成させるため。
アイコン、反転ビデオ、点滅カーソルなどを使用して、フォームを魅力的に保つため
ナビゲーションを容易にするため。

フォームの種類

フラットフォーム

これは、手動または機械で作成され、紙に印刷された単一のコピーフォームです。オリジナルの追加コピーの場合、カーボンペーパーがコピーの間に挿入されます。
これは、設計、印刷、および複製が最も簡単で安価な形式であり、使用するボリュームが少なくなります。

ユニットセット/スナップアウトフォーム

これらは、手書きまたは機械で使用するために、1回限りの炭素がユニットセットにインターリーブされた用紙です。
炭素は、標準グレードの中強度の青または黒のいずれかです。一般に、ブルーカーボンは手書きのフォームに最適で、ブラックカーボンは機械での使用に最適です。

連続ストリップ/ファンフォールドフォーム

これらは、フォームの各ペア間にミシン目が付いた連続したストリップで結合された複数のユニットフォームです。
大量に使用する場合は安価な方法です。

カーボン不要（NCR）用紙

彼らは、1枚の紙の表面と裏面に2つの化学コーティング（カプセル）があるカーボンレス紙を使用しています。
圧力が加えられると、2つのカプセルが相互作用して画像を作成します。

テストと品質保証

ソフトウェアシステムは、各開発段階で意図された動作と進行方向をチェックして、作業の重複、時間とコストのオーバーランを回避し、規定の時間内にシステムの完了を保証する必要があります。各開発段階での意図された動作と進行方向により、作業の重複、時間とコストのオーバーランを回避し、規定の時間内にシステムを確実に完了させることができます。

システムのテストと品質保証は、システムのチェックに役立ちます。それが含まれています-

製品レベルの品質（テスト）
プロセスレベルの品質。

それらを簡単に見てみましょう-

テスト

テストとは、システムの品質と信頼性を向上させるために、指定されたユーザー要件に従ってソフトウェアの機能と正確性をチェックするプロセスまたはアクティビティです。これは、システム開発における高価で時間のかかる重要なアプローチであり、テストプロセス全体の適切な計画が必要です。

テストが成功すると、エラーが検出されます。エラーを見つけるという明示的な意図でプログラムを実行します。つまり、プログラムを失敗させます。これは、強力なシステムを作成することを目的としてシステムを評価するプロセスであり、主にシステムまたはソフトウェアの脆弱な領域に焦点を当てています。

システムテストの特徴

システムテストはモジュールレベルで開始され、ソフトウェアシステム全体の統合に進みます。システムをテストしている間、異なる時間に異なるテスト手法が使用されます。これは、小規模プロジェクトの場合は開発者によって、大規模プロジェクトの場合は独立したテストグループによって実施されます。

システムテストの段階

次の段階がテストに関与しています-

テスト戦略

これは、システムのテストに使用されるさまざまなレベル、方法、ツール、および手法に関する情報を提供するステートメントです。組織のすべてのニーズを満たす必要があります。

テスト計画

システムをテストするための計画を提供し、テスト中のシステムがすべての設計および機能仕様を満たしていることを検証します。テスト計画は、次の情報を提供します-

各テスト段階の目的
テストに使用されるアプローチとツール
各テスト活動に必要な責任と時間
ツール、機能、およびテストライブラリの可用性
テストの計画と実施に必要な手順と基準
テストプロセスが正常に完了した要因

テストケースデザイン

テストケースは、システム内の可能な限り多くのエラーを発見するために使用されます。
テストするシステムの各モジュールについて、多数のテストケースが識別されます。
各テストケースでは、特定の要件または設計決定の実装をテストする方法と、テストの成功の基準を指定します。
テスト計画とテストケースは、システム仕様文書の一部として、または*テスト仕様*または*テスト記述*と呼ばれる別の文書に文書化されています。

テスト手順

これは、各テストケースを実行するために従うべき手順で構成されています。これらの手順は、テスト手順仕様と呼ばれる別のドキュメントで指定されています。このドキュメントでは、テストの結果を報告するための特別な要件と形式も指定しています。

テスト結果のドキュメント

テスト結果ファイルには、実行されたテストケースの総数、エラーの数、およびエラーの性質に関する簡単な情報が含まれています。これらの結果は、テスト仕様の基準に照らして評価され、テストの全体的な結果が決定されます。

テストの種類

テストにはさまざまなタイプがあり、発見しようとするバグの種類に応じてさまざまなタイプのテストが行われます-

単体テスト

プログラムテストとも呼ばれ、アナリストが各プログラムまたはモジュールを個別にテストまたは集中するタイプのテストです。モジュールの各ステートメントを少なくとも1回実行することを意図して実行されます。

単体テストでは、プログラムの正確性は保証されず、さまざまな入力の組み合わせを詳細にテストすることは困難です。
他のテスト手法と比較して、プログラムの最大エラーを特定します。

統合テスト

統合テストでは、アナリストが複数のモジュールが連携してテストします。これは、システムとその元の目的、現在の仕様、およびシステムのドキュメントとの間の矛盾を見つけるために使用されます。

ここで、アナリストは、データ長、タイプ、データ要素名の異なる仕様でモジュールが設計されている領域を見つけようとします。
ファイルサイズが適切であり、インデックスが適切に構築されていることを確認します。

機能テスト

機能テストは、システムの仕様および関連する標準文書に従って、システムが正しく機能しているかどうかを判断します。機能テストは通常、システムの実装から始まります。これは、システムの成功にとって非常に重要です。

機能テストは2つのカテゴリに分けられます-

正の機能テスト-生成された出力が正しいことを確認するために、有効な入力でシステムをテストします。
負の機能テスト-無効な入力と望ましくない動作条件でソフトウェアをテストすることを含みます。

システムテストのルール

システムテストを正常に実行するには、所定のルールに従う必要があります-

テストはユーザーの要件に基づいている必要があります。
テストスクリプトを記述する前に、ビジネスロジックを完全に理解する必要があります。
テスト計画はできるだけ早く行う必要があります。
テストは第三者が行う必要があります。
静的ソフトウェアで実行する必要があります。
有効な入力条件と無効な入力条件をテストする必要があります。
コストを削減するために、テストをレビューおよび調査する必要があります。
静的テストと動的テストの両方をソフトウェアで実行する必要があります。
テストケースとテスト結果の文書化を行う必要があります。

品質保証

システムまたはソフトウェア製品のレビューと、システムが要件と仕様を満たしていることを保証するためのドキュメントです。

QAの目的は、仕様に従って製品を継続的に配送することにより、顧客に自信を与えることです。
ソフトウェア品質保証（SQA）は、ソフトウェアの意図された使用とパフォーマンスについて指定された標準を満たすことを保証するために、ソフトウェアの専門家によって適用される手順とツールを含む技術です。
SQAの主な目的は、ソフトウェアプロジェクトとその開発製品の適切かつ正確な可視性を管理者に提供することです。
システム開発のライフサイクル全体でソフトウェア製品とそのアクティビティをレビューおよび監査します。

品質保証の目的

品質保証を実施する目的は次のとおりです-

ソフトウェア開発プロセスと開発された最終ソフトウェアを監視するため。
ソフトウェアプロジェクトが管理者によって設定された標準と手順を実装しているかどうかを確認する。
SQAアクティビティおよびこれらのアクティビティの結果についてグループおよび個人に通知する。
ソフトウェア内で解決されていない問題が、上級管理職によって確実に対処されるようにするため。
製品、プロセス、または標準の欠陥を特定し、修正するため。

品質保証のレベル

ソフトウェア製品を認証するために実行する必要があるQAとテストにはいくつかのレベルがあります。

レベル1-コードウォークスルー

このレベルでは、オフラインソフトウェアが公式のコーディングルールの違反について検査またはチェックされます。一般に、ドキュメントの検討とコード内コメントのレベルに重点が置かれます。

レベル2-コンパイルとリンク

このレベルでは、ソフトウェアがすべての公式プラットフォームとオペレーティングシステムをコンパイルおよびリンクできることを確認します。

レベル3-定期的な実行

このレベルでは、特定の数のイベント、小規模および大規模なイベントサイズなど、さまざまな条件下でソフトウェアが適切に実行できることを確認します。

レベル4-パフォーマンステスト

この最終レベルでは、ソフトウェアのパフォーマンスが以前に指定されたパフォーマンスレベルを満たしているかどうかがチェックされます。

システムの実装とメンテナンス

実装とは、情報システムが機能していることを確認するプロセスです。それが含まれます-

新しいシステムをゼロから構築する
既存のシステムから新しいシステムを構築します。

実装により、ユーザーは操作を引き継いで使用および評価できます。システムを処理し、スムーズな変換を計画するためのユーザーのトレーニングが含まれます。

トレーニング

システムの担当者は、自分の役割が何であるか、システムをどのように使用できるか、およびシステムが何をするかしないかを詳細に知る必要があります。適切に設計され、技術的に洗練されたシステムの成功または失敗は、それらの操作および使用方法に依存します。

トレーニングシステムオペレーター

システムオペレーターは、日常的な操作と異常な操作の両方の可能な操作をすべて処理できるように、適切にトレーニングする必要があります。オペレータは、一般的な誤動作が発生する可能性のあるもの、それらを認識する方法、および発生したときに実行する手順についてトレーニングする必要があります。

トレーニングでは、トラブルシューティングリストを作成して、考えられる問題とその解決策、および予期しないまたは異常な問題が発生したときに連絡する個人の名前と電話番号を特定します。

トレーニングには、新しいシステムを使用するために必要な一連のアクティビティを実行することを含む、実行手順の習熟も含まれます。

ユーザートレーニング

エンドユーザートレーニングは、コンピューターベースの情報システム開発の重要な部分であり、従業員が自分で問題を解決できるようにするために提供する必要があります。
ユーザートレーニングには、機器の操作方法、システムの問題のトラブルシューティング、発生した問題の原因が機器またはソフトウェアにあるかどうかの判断が含まれます。
ほとんどのユーザートレーニングでは、システム自体の操作を扱います。トレーニングコースは、ユーザーが組織を迅速に動員できるように設計する必要があります。

トレーニングガイドライン

測定可能な目標の確立
適切なトレーニング方法を使用する
適切なトレーニングサイトの選択
わかりやすいトレーニング資料を採用する

トレーニング方法

インストラクター主導のトレーニング

トレーナーとトレーニーの両方が参加しますが、同時に会う必要がありますが、必ずしも同じ場所で会う必要はありません。トレーニングセッションは、1対1または共同で行うことができます。それは2つのタイプです-

仮想教室

このトレーニングでは、トレーナーは同時に研修生に会う必要がありますが、同じ場所にいる必要はありません。ここで使用される主なツールは、ビデオ会議、テキストベースのインターネットリレーチャットツール、または仮想現実パッケージなどです。

通常の教室

トレーナーは、同時に同じ場所で研修生に会わなければなりません。ここで使用される主なツールは、黒板、オーバーヘッドプロジェクター、LCDプロジェクターなどです。

自習型トレーニング

それは、同じ場所で、または同時に会う必要のないトレーナーと研修生の両方を含みます。研修生は、自分の都合の良いときにコースにアクセスして、自分でスキルを学びます。それは2つのタイプです-

マルチメディアトレーニング

このトレーニングでは、コースはマルチメディア形式で提示され、CD-ROMに保存されます。外部プログラマーの支援なしで社内トレーニングコースを開発するコストを最小限に抑えます。

ウェブベースのトレーニング

このトレーニングでは、コースはしばしばハイパーメディア形式で提示され、インターネットおよびイントラネットをサポートするために開発されます。エンドユーザーにジャストインタイムのトレーニングを提供し、組織がトレーニング要件を調整できるようにします。

変換

これは、古いシステムから新しいシステムに移行するプロセスです。理解しやすく構造化されたアプローチを提供し、管理チームとプロジェクトチーム間のコミュニケーションを改善します。

変換計画

これには、新しいシステムの実装中に発生し、運用する必要があるすべてのアクティビティの説明が含まれています。考えられる問題とそれらに対処する解決策を予測します。

次のアクティビティが含まれています-

変換するすべてのファイルに名前を付けます。
変換中に新しいファイルを開発するためのデータ要件を特定します。
必要なすべての新しいドキュメントと手順をリストします。
各アクティビティで使用されるコントロールを特定します。
各アクティビティに対する人の責任を特定します。
変換スケジュールの検証。

変換方法

変換の4つの方法は次のとおりです-

並列変換
直接カットオーバー変換
パイロットアプローチ
段階的導入方法

Method	Description	Advantages	Disadvantages
Parallel Conversion	Old and new systems are used simultaneously.	Provides fallback when new system fails. 最高のセキュリティを提供し、最終的に新しいシステムのテストを行います。 a	コスト超過を引き起こします。新しいシステムは公平な道を歩まないかもしれません。
Direct Cutover Conversion	New system is implemented and old system is replaced completely.	Forces users to make new system work 新しい方法と制御からすぐに利益が得られます。 a	新しいシステムで問題が発生してもフォールバックしない最も慎重な計画が必要
Pilot Approach	Supports phased approach that gradually implement system across all users	Allows training and installation without unnecessary use of resources. リスク管理による大きな偶発事態を避けます。	A long term phasein causes a problem of whether conversion goes well or not.
Phase-In Method	Working version of system implemented in one part of organization based on feedback, it is installed throughout the organization all alone or stage by stage.	Provides experience and line test before implementation 優先される新しいシステムが新しいテクノロジーまたはパフォーマンスの大幅な変更を伴う場合。	Gives impression that old system is erroneous and it is not reliable.

ファイル変換

これは、あるファイル形式を別のファイル形式に変換するプロセスです。たとえば、WordPerfect形式のファイルをMicrosoft Wordに変換できます。

変換を成功させるには、次を含む変換計画が必要です-

ターゲットシステムの知識と現在のシステムの理解
チームワーク
自動化されたメソッド、テストおよび並列操作
問題を修正するための継続的なサポート
システム/ユーザードキュメントなどの更新

多くの一般的なアプリケーションは、同じタイプの他のファイル形式を開いたり保存したりすることをサポートしています。たとえば、Microsoft Wordは他の多くのワープロ形式でファイルを開いて保存できます。

実装後評価レビュー（PIER）

PIERは、プロジェクトの結果を評価し、プロジェクトがプロセス、製品、またはサービスに期待される利益を生み出しているかどうかを判断するためのツールまたは標準アプローチです。これにより、ユーザーはプロジェクトまたはシステムが指定された期間と計画コスト内で望ましい結果を達成したことを確認できます。

PIERは、プロジェクトの開発および管理プロセスを評価することにより、プロジェクトが目標を達成したことを確認します。

PIERの目的

PIERを持つ目的は次のとおりです-

予測されるコスト、利益、およびタイムラインに対してプロジェクトの成功を判断する。
プロジェクトに付加価値を加える機会を特定するため。
将来の参照と適切なアクションのためにプロジェクトの長所と短所を決定する。
コスト見積もり手法を改良することにより、プロジェクトの将来に関する推奨事項を作成する。

次のスタッフはレビュープロセスに含まれるべきです-

プロジェクトチームと管理
ユーザースタッフ
戦略的管理スタッフ
外部ユーザー

システムのメンテナンス/強化

メンテナンスとは、何かを元の状態に復元することです。拡張とは、ユーザー仕様の変更をサポートするためにコードを追加、変更することを意味します。システムメンテナンスはシステムを元の要件に適合させ、新しい要件を組み込むことでシステムの機能を強化します。

したがって、メンテナンスは既存のシステムを変更し、拡張機能は既存のシステムに機能を追加し、開発は既存のシステムを置き換えます。これは、システム設計および実装のエラーを修正し、ドキュメントを更新し、データをテストするアクティビティを含むシステム開発の重要な部分です。

メンテナンスの種類

システムのメンテナンスは3つのタイプに分類することができます-

修正メンテナンス-ユーザーが残りの問題の修復と修正を実行できるようにします。
アダプティブメンテナンス-ユーザーがプログラムの機能を交換できるようにします。
完全なメンテナンス-ユーザーは、ユーザーの要件と変化するニーズに応じてプログラムを変更または強化できます。

システムのセキュリティと監査

システム監査

運用システムのパフォーマンスを確認する調査です。システム監査を実施する目的は次のとおりです-

実際のパフォーマンスと計画されたパフォーマンスを比較します。
システムの規定された目的が現在の環境でまだ有効であることを確認するため。
定められた目標の達成を評価する。
コンピューターベースの財務およびその他の情報の信頼性を確保するため。
処理中にすべてのレコードが含まれるようにします。
詐欺から保護するため。

コンピュータシステムの使用状況の監査

データ処理監査員は、コンピューターシステムを制御するために、その使用状況を監査します。監査人は、コンピューターシステム自体によって取得される制御データを必要とします。

システム監査役

監査人の役割は、システム開発の初期段階で開始されるため、結果のシステムは安全です。記録できるシステムの利用のアイデアを説明し、負荷計画とハードウェアとソフトウェアの仕様の決定に役立ちます。コンピュータシステムの賢明な使用とシステムの誤用の可能性を示します。

監査トライアル

監査トライアルまたは監査ログは、誰がコンピュータシステムにアクセスしたか、および特定の期間に実行された操作で構成されるセキュリティレコードです。監査トライアルは、システム上のデータがどのように変更されたかを詳細にトレースするために使用されます。

トランザクションが処理中に対象となるさまざまな制御技術の証拠を提供します。監査トライアルは独立して存在しません。これらは、失われたトランザクションを回復するためのアカウンティングの一部として実行されます。

監査方法

監査は2つの異なる方法で行うことができます-

コンピューター周辺の監査

サンプル入力を取得し、処理ルールを手動で適用します。
出力をコンピューター出力と比較します。

コンピューターを介した監査

選択した中間結果を検査できる監査トライアルを確立します。
制御合計は中間チェックを提供します。

監査の考慮事項

監査の考慮事項は、ナラティブとモデルの両方を使用して分析の結果を調べ、機能の誤配置、プロセスまたは機能の分割、データフローの破損、データの欠落、冗長または不完全な処理、およびアドレス指定されていない自動化の機会に起因する問題を特定します。

このフェーズでの活動は次のとおりです-

現在の環境問題の特定
問題の原因の特定
代替ソリューションの特定
各ソリューションの評価と実現可能性分析
最も実用的で適切なソリューションの選択と推奨
プロジェクト費用の見積もりと費用便益分析

セキュリティ

システムのセキュリティとは、盗難、不正なアクセスと変更、偶発的または意図しない損傷からシステムを保護することです。コンピュータ化されたシステムでは、セキュリティには、データ、ソフトウェア、ハードウェアを含むコンピュータシステムのすべての部分の保護が含まれます。システムのセキュリティには、システムのプライバシーとシステムの整合性が含まれます。

*システムプライバシー*は、関係する個人の許可/知識なしに個人のシステムがアクセスおよび使用されるのを防ぐことを扱います。
*システムの整合性*は、システム内の生データおよび処理済みデータの品質と信頼性に関係しています。

管理策

次のように広く分類することができるさまざまな制御手段があります-

バックアップ

時間の重要度とサイズに応じて、データベースを毎日/毎週定期的にバックアップします。
短い間隔で増分バックアップ。
バックアップコピーは、災害復旧に特に必要な安全な遠隔地に保管されます。
重複したシステムが実行され、非常に重要なシステムであり、ディスクに保存する前に中断を許容できない場合、すべてのトランザクションがミラーリングされます。

施設への物理的アクセス管理

物理ロックと生体認証。たとえば、指紋
IDカードまたは入場券は、セキュリティスタッフによってチェックされます。
データを読み取りまたは変更し、ファイルに記録するすべての人の識別。

論理制御またはソフトウェア制御の使用

パスワードシステム。
機密データ/プログラムの暗号化。
データのケア/処理およびセキュリティに関する従業員のトレーニング。
インターネットに接続中のウイルス対策ソフトウェアとファイアウォール保護。

リスク分析

リスクとは、価値のあるものを失う可能性です。リスク分析は、システムの脆弱性とその影響を特定することにより、安全なシステムを計画することから始まります。その後、リスクを管理し、災害に対処するための計画が作成されます。災害の可能性とそのコストにアクセスするために行われます。

リスク分析は、化学物質、ヒューマンエラー、プロセス機器などのさまざまな背景を持つ専門家のチームワークです。

リスク分析を実施しながら、次の手順に従う必要があります-

コンピューターシステムのすべてのコンポーネントの識別。
各コンポーネントが直面するすべての脅威と危険の識別。
リスクの定量化脅威が現実となった場合の損失の評価。

リスク分析-主な手順

リスクまたは脅威が変化し、潜在的な損失も変化しているため、リスクの管理は上級管理者が定期的に実行する必要があります。

リスク分析

リスク管理は継続的なプロセスであり、次の手順が含まれます-

セキュリティ対策の識別。
セキュリティ対策の実装コストの計算。
セキュリティ対策のコストと脅威の損失および確率の比較。
セキュリティ対策の選択と実装。
セキュリティ対策の実施のレビュー。

オブジェクト指向アプローチ

オブジェクト指向のアプローチでは、情報システムの構造と動作をデータとプロセスの両方を組み合わせた小さなモジュールにキャプチャすることに焦点が当てられています。オブジェクト指向設計（OOD）の主な目的は、システムの分析と設計をより使いやすくすることで、品質と生産性を向上させることです。

分析フェーズでは、オブジェクト指向モデルを使用して、問題と解決策の間のギャップを埋めます。システムが継続的な設計、適応、およびメンテナンスを受けている状況で良好に機能します。問題領域内のオブジェクトを識別し、データと動作の観点から分類します。

オブジェクト指向モデルは、次の点で有益です-

低コストでシステムの変更を容易にします。
コンポーネントの再利用を促進します。
コンポーネントを統合して大規模システムを構成する問題を簡素化します。
分散システムの設計を簡素化します。

オブジェクト指向システムの要素

オブジェクト指向システムの特徴を見てみましょう-

オブジェクト-オブジェクトは問題のドメイン内に存在するものであり、データ（属性）または動作によって識別できます。すべての有形のエンティティ（学生、患者）と一部の無形のエンティティ（銀行口座）はオブジェクトとしてモデル化されます。
属性-オブジェクトに関する情報を記述します。
動作-オブジェクトができることを指定します。オブジェクトに対して実行される操作を定義します。
クラス-クラスはデータとその動作をカプセル化します。類似した意味と目的を持つオブジェクトは、クラスとしてグループ化されます。
メソッド-メソッドはクラスの動作を決定します。それらは、オブジェクトが実行できるアクションにすぎません。
メッセージ-メッセージは、あるオブジェクトから別のオブジェクトへの関数またはプロシージャの呼び出しです。これらは、メソッドをトリガーするためにオブジェクトに送信される情報です。基本的に、メッセージは、あるオブジェクトから別のオブジェクトへの関数またはプロシージャの呼び出しです。

オブジェクト指向システムの機能

オブジェクト指向システムには、以下で説明するいくつかの優れた機能が付属しています。

カプセル化

カプセル化は、情報を隠すプロセスです。これは、プロセスとデータを単一のエンティティに単純に組み合わせたものです。オブジェクトのデータはシステムの他の部分から隠されており、クラスのサービスを通じてのみ利用可能です。システムの他の部分に影響を与えることなく、オブジェクトが使用するメソッドを改善または変更できます。

抽象化

これは、オブジェクトを指定するために必要なメソッドと属性を取得または選択するプロセスです。ユーザーの視点から見たオブジェクトの本質的な特性に焦点を当てています。

関係

システム内のすべてのクラスは互いに関連しています。オブジェクトは孤立して存在するのではなく、他のオブジェクトとの関係で存在します。

オブジェクトの関係には3つのタイプがあります-

集約-全体とその部分の関係を示します。
関連付け-これでは、1つのクラスが別のクラスと連携してタスクを実行したり、1つのクラスが他のクラスに作用するなど、何らかの方法で2つのクラスが関連付けられます。
一般化-子クラスは親クラスに基づいています。 2つのクラスが似ているが、いくつかの違いがあることを示しています。

継承

継承は、既存のクラスの属性や操作を継承することで、既存のクラスからサブクラスを作成できる優れた機能です。

多態性と動的バインディング

多態性とは、さまざまな形をとる能力です。オブジェクトと操作の両方に適用されます。ポリモーフィックオブジェクトとは、スーパークラスまたは親クラス内で真のタイプが隠れるオブジェクトです。

ポリモーフィック操作では、オブジェクトのクラスによって操作が異なる場合があります。共通のプロパティのみを知ることで、異なるクラスのオブジェクトを操作できます。

構造化アプローチ対オブジェクト指向アプローチ

次の表は、オブジェクト指向アプローチが従来の構造化アプローチとどのように異なるかを説明しています-

Structured Approach	Object Oriented Approach
It works with Top-down approach.	It works with Bottom-up approach.
Program is divided into number of submodules or functions.	Program is organized by having number of classes and objects.
Function call is used.	Message passing is used.
Software reuse is not possible.	Reusability is possible.
Structured design programming usually left until end phases.	Object oriented design programming done concurrently with other phases.
Structured Design is more suitable for offshoring.	It is suitable for in-house development.
It shows clear transition from design to implementation.	Not so clear transition from design to implementation.
It is suitable for real time system, embedded system and projects where objects are not the most useful level of abstraction.	It is suitable for most business applications, game development projects, which are expected to customize or extended.
DFD & E-R diagram model the data.	Class diagram, sequence diagram, state chart diagram, and use cases all contribute.
In this, projects can be managed easily due to clearly identifiable phases.	In this approach, projects can be difficult to manage due to uncertain transitions between phase.

統一モデリング言語（UML）

UMLは、プロセス、ソフトウェア、およびシステムをモデル化して、システムアーキテクチャの設計を表現できるビジュアル言語です。これは、技術設計者が開発者と通信できるようにするオブジェクト指向の方法でシステムを設計および文書化するための標準言語です。

これは、Object Management Groupによって作成および配布される一連の仕様として定義されます。 UMLは拡張可能でスケーラブルです。

UMLの目的は、分析から実装までのあらゆるシステム開発プロジェクトをモデル化するのに十分な豊富なオブジェクト指向用語と図表化技術の共通語彙を提供することです。

UMLはで構成されています-

図-プロセス、システム、またはその一部の図的表現です。
表記-コネクタ、シンボル、メモなどの図で一緒に機能する要素で構成されます。

クラスのUML表記の例

クラス表記

インスタンス図-UML表記

UML表記法

オブジェクトに対して実行される操作

次の操作がオブジェクトに対して実行されます-

コンストラクタ/デストラクタ-クラスの新しいインスタンスを作成し、クラスの既存のインスタンスを削除します。たとえば、新しい従業員を追加します。
クエリ-値を変更せずに状態にアクセスすると、副作用はありません。たとえば、特定の従業員の住所を検索します。
更新-1つまたは複数の属性の値を変更し、オブジェクトの状態に影響します。たとえば、従業員の住所を変更します。

UMLの使用

UMLは次の目的のために非常に便利です-

ビジネスプロセスのモデリング
システムアーキテクチャの説明
アプリケーション構造の表示
システム動作のキャプチャ
データ構造のモデリング
システムの詳細な仕様を作成する
アイデアのスケッチ
プログラムコードの生成

静的モデル

静的モデルは、システムの構造特性を示し、そのシステム構造を記述し、システムを構成する部分を強調します。

クラス名、属性、メソッド、署名、パッケージを定義するために使用されます。
静的モデルを表すUML図には、クラス図、オブジェクト図、ユースケース図が含まれます。

動的モデル

動的モデルは、システムの動作特性、つまり外部イベントに応答してシステムがどのように動作するかを示します。

動的モデルは、必要なオブジェクトと、メソッドとメッセージを介してどのように連携するかを特定します。
システムのロジックと動作を設計するために使用されます。
UMLダイアグラムは、シーケンス図、コミュニケーション図、状態図、アクティビティ図などの動的モデルを表します。

オブジェクト指向システム開発のライフサイクル

それは3つのマクロプロセスで構成されています-

オブジェクト指向分析（OOA）
オブジェクト指向設計（OOD）
オブジェクト指向実装（OOI）

オブジェクト指向ライフサイクル

オブジェクト指向システム開発活動

オブジェクト指向システムの開発には、次の段階が含まれます-

オブジェクト指向分析
オブジェクト指向設計
プロトタイピング
実装
増分テスト

オブジェクト指向分析

このフェーズでは、システム要件を決定し、システム要件を理解して*ユースケースモデル*を構築します。ユースケースは、ユーザーとコンピューターシステム間の相互作用を説明するシナリオです。このモデルは、システムのユーザーニーズまたはユーザービューを表します。

また、アプリケーションを構成するクラスと、問題ドメイン内の他のクラスとの関係を識別することも含まれます。

オブジェクト指向設計

このフェーズの目的は、分析フェーズ、ユーザーインターフェイス、およびデータアクセス中に識別されるクラス、属性、メソッド、および構造を設計および改良することです。このフェーズでは、要件の実装をサポートする追加のクラスまたはオブジェクトも識別および定義します。

プロトタイピング

プロトタイピングにより、システムの一部の機能を実装することがどれだけ簡単か難しいかを完全に理解できます。

また、ユーザーにデザインの使いやすさと有用性についてコメントする機会を与えることができます。さらに、ユースケースを定義し、ユースケースのモデリングをはるかに簡単にすることができます。

実装

コンポーネントベース開発（CBD）または高速アプリケーション開発（RAD）のいずれかを使用します。

コンポーネントベースの開発（CBD）

CODDは、CASEツールなどのさまざまな技術を使用したソフトウェア開発プロセスへの工業化されたアプローチです。アプリケーション開発は、カスタム開発から、相互に動作するビルド済み、テスト済み、再利用可能なソフトウェアコンポーネントのアセンブリに移行します。 CBD開発者は、コンポーネントを組み立てて完全なソフトウェアシステムを構築できます。

迅速なアプリケーション開発（RAD）

RADは、従来の方法で通常可能であったよりも高速にアプリケーションを構築するために使用できるツールとテクニックのセットです。 SDLCに代わるものではなく、プロセス記述に重点を置いており、オブジェクト指向アプローチと完全に組み合わせることができるため、SDLCを補完します。

そのタスクは、Visual Basic、パワービルダーなどのツールを使用して、ユーザー要件設計を迅速かつ段階的に実装することです。

増分テスト

ソフトウェア開発とテストを含むすべてのアクティビティは、反復プロセスです。したがって、製品が完全に開発されて初めてテストを待つと、費用のかかる事態になる可能性があります。ここでは、開発のさまざまな段階で製品がテストされる段階的なテストが行われます。

System-analysis-and-design-quick-guide

システム分析と設計-概要