システム分析と設計-クイックガイド

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

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

システム分析

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

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

分析は指定します what the system should do。

システムデザイン

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

システム設計は焦点を当てています how to accomplish the objective of the system。

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

Systems
Processes
Technology

システムとは何ですか？

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

システムとは、「特定の目標を達成するための計画に従って、相互に依存するコンポーネントを整然とグループ化したもの」です。

システムの制約

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

システムにはいくつかが必要です structure and behavior これは、事前定義された目的を達成するように設計されています。
Interconnectivity そして interdependence システムコンポーネント間に存在する必要があります。
ザ・ objectives of the organization 持っている higher priority そのサブシステムの目的よりも。

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

システムのプロパティ

システムには次の特性があります-

組織

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

インタラクション

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

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

相互依存

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

統合

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

中心的な目的

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

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

システムの要素

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

出力と入力

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

プロセッサー

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

コントロール

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

フィードバック

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

環境

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

境界とインターフェース

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

システムの種類

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

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

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

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

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

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

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

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

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

自然および製造されたシステム

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

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

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

社会的、人間機械、機械システム

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

人工情報システム

これは、Direct Management Control（DMC）の下で、特定の組織のデータを管理するための相互接続された情報リソースのセットです。
このシステムには、組織のニーズに応じて情報を生成するためのハードウェア、ソフトウェア、通信、データ、およびアプリケーションが含まれています。

人工情報システムは3つのタイプに分けられます-
Formal Information System −経営陣のトップから下位へのメモや指示などの情報の流れに基づいています。
Informal Information System −これは従業員ベースのシステムであり、日常業務に関連する問題を解決します。
Computer Based System−このシステムは、ビジネスアプリケーションを管理するためにコンピューターに直接依存しています。たとえば、自動図書館システム、鉄道予約システム、銀行システムなど。

システムモデル

スケマティックモデル

スケマティックモデルは、システム要素とそれらのリンクを示す2Dチャートです。
情報の流れ、材料の流れ、および情報のフィードバックを示すために、さまざまな矢印が使用されています。

フローシステムモデル

フローシステムモデルは、システムをまとめる材料、エネルギー、および情報の整然とした流れを示します。
たとえば、Program Evaluation and Review Technique（PERT）は、実世界のシステムをモデル形式で抽象化するために使用されます。

静的システムモデル

これらは、アクティビティ-時間またはコスト-量などの1組の関係を表します。
たとえば、ガントチャートは、アクティビティと時間の関係の静的な図を示します。

動的システムモデル

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

情報のカテゴリー

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

戦略的情報

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

経営情報

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

運用情報

このタイプの情報は、日常の運用活動を実施するための日常および短期の計画のために、低管理者によって必要とされます。たとえば、従業員の出席記録、期限切れの発注書、現在の在庫を利用できるようにしておく。
これは、データ処理システム（DPS）を使用して実現されます。

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

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

SDLCは、アナリストが情報システムを開発するために使用します。SDLCには以下の活動が含まれます-

requirements
design
implementation
testing
deployment
operations
maintenance

SDLCのフェーズ

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

フィージビリティスタディまたは計画

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

分析と仕様

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

システムデザイン

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

実装

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

メンテナンス/サポート

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

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

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

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

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

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

主な役割

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

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

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

対人能力

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

分析能力

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

管理能力

ユーザーの専門用語と慣習を理解します。
リソースとプロジェクトの管理。
変更とリスク管理。
管理機能を十分に理解します。

技術的なスキル

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

要件決定とは何ですか？

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

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

要件決定の主な活動

要件の予測

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

要件調査

現在のシステムを研究し、さらなる分析のためにその機能を文書化しています。
これは、システム分析の中心であり、アナリストは、事実調査手法、プロトタイピング、およびコンピューター支援ツールを使用して、システム機能を文書化および説明します。

要件仕様

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

情報収集技術

事実調査手法の主な目的は、アナリストがユーザーが理解できる正確なSRSを作成するために使用する組織の情報要件を決定することです。

理想的なSRSドキュメントは-

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

さまざまな情報収集手法があります-

インタビュー

システムアナリストは、インタビューによって個人またはグループから情報を収集します。アナリストは、正式、合法、政治的、または非公式である可能性があります。インタビューの成功は、インタビュアーとしてのアナリストのスキルに依存するためです。

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

Unstructured Interview −システムアナリストは、システムの基本情報を取得するための質疑応答を行います。
Structured Interview −ユーザーがクローズ（客観的）またはオープン（記述的）形式で回答する必要がある標準的な質問があります。

Advantages of Interviewing

この方法は、定性的情報を収集するための最良の情報源であることがよくあります。
書面でのコミュニケーションがうまくいかない方や、アンケートに回答する時間がない方に便利です。
情報は簡単に検証でき、すぐにクロスチェックできます。
複雑なテーマにも対応できます。
意見を求めることで、重要な問題を簡単に見つけることができます。
それは誤解の領域のギャップを埋め、将来の問題を最小限に抑えます。

アンケート

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

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

Open-ended Questionnaires−簡単かつ正確に解釈できる質問で構成されています。彼らは問題を探求し、特定の答えの方向に導くことができます。
Closed-ended Questionnaires −これは、システムアナリストが相互に排他的なすべての可能な応答を効果的にリストするときに使用される質問で構成されます。

Advantages of questionnaires

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

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

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

Advantages

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

観察

これは、人、出来事、物に気づき、観察することで情報を収集する方法です。アナリストは組織を訪問して現在のシステムの動作を観察し、システムの要件を理解します。

Advantages

これは、情報を収集するための直接的な方法です。
収集されたデータの信頼性が問題となる状況や、システムの特定の側面が複雑であるためにエンドユーザーによる明確な説明ができない場合に役立ちます。
より正確で信頼性の高いデータを生成します。
それは不完全で時代遅れのドキュメンテーションのすべての側面を生み出します。

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

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

Advantages of JAD

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

二次研究または背景資料

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

Advantages

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

フィージビリティスタディ

フィージビリティスタディは、システムのスタディが開発に適しているかどうかを管理者が決定するのに役立つ予備調査と見なすことができます。

これは、既存のシステムを改善し、新しいシステムを開発する可能性を特定し、システムのさらなる開発のための洗練された見積もりを作成します。
これは、問題の概要を取得し、実行可能または適切な解決策が存在するかどうかを判断するために使用されます。
フィージビリティスタディの主な目的は、問題を解決するのではなく、問題の範囲を取得することです。
実現可能性調査の出力は、提案されたシステムの完全な性質と範囲を含む決定文書として機能する正式なシステム提案です。

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

実現可能性分析を実行する際は、次の手順に従う必要があります。

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

実現可能性の種類

経済的実現可能性

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

技術的実現可能性

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

運用の実現可能性

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

行動の実現可能性

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

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

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

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

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

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

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

次の属性があります-

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

構造化分析ツール

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

データフロー図
データディクショナリ
デシジョンツリー
デシジョンテーブル
構造化された英語
Pseudocode

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

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

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

DFDの基本要素

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

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

シンボル名	シンボル	意味
平方		データのソースまたは宛先
矢印		データフロー
サークル		データフローを変換するプロセス
長方形を開く		データストア

DFDの種類

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

物理DFD	論理DFD
実装に依存します。実行される機能を示します。	実装に依存しません。プロセス間のデータの流れにのみ焦点を当てています。
ハードウェア、ソフトウェア、ファイル、および人の低レベルの詳細を提供します。	システムのイベントと各イベントに必要なデータについて説明します。
これは、現在のシステムがどのように動作し、システムがどのように実装されるかを示しています。	それはビジネスがどのように運営されているかを示しています。システムの実装方法ではありません。

コンテキスト図

コンテキスト図は、システムの概要を示す1つのDFDによってシステム全体を理解するのに役立ちます。それは、ほとんど詳細のない主要なプロセスに言及することから始まり、トップダウンアプローチでプロセスの詳細を提供することに続きます。

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

データディクショナリ

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

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

シニア番号	データ名	説明	文字数
1	ISBN	ISBN番号	10
2	題名	題名	60
3	サブ	本の主題	80
4	名前	著者名	15

デシジョンツリー

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

デシジョンツリーは、各条件の関係とそれらの許容されるアクションを示します。四角いノードはアクションを示し、丸は条件を示します。これにより、アナリストは一連の決定を検討し、実際に行わなければならない決定を特定する必要があります。

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

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

デシジョンテーブル

デシジョンテーブルは、複雑な論理関係を正確に記述し、簡単に理解できる方法です。

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

デシジョンテーブルのコンポーネント

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

デシジョンテーブルのエントリは、条件の組み合わせと一連のアクションの間の関係を定義するデシジョンルールによって提供されます。ルールセクションでは、

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

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

条件	ルール1	ルール2	ルール3	ルール4
前払い	Y	N	N	N
購入金額= Rs 10,000 /-	-	Y	Y	N
常連客	-	Y	N	-
ACTIONS
5％割引	バツ	バツ	-	-
割引なし	-	-	バツ	バツ

構造化された英語

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

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

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

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を使用します。
データディクショナリを使用して、システムのデータ要件を満たすための構造を簡素化します。
ループが多く、アクションが複雑な場合は、構造化された英語を使用してください。
チェックする条件が多数あり、ロジックが複雑な場合は、デシジョンテーブルを使用します。
条件の順序付けが重要であり、テストする条件が少ない場合は、決定木を使用します。

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

これは、SRSドキュメントが実装可能な形式に変換され、システムの動作方法を決定するフェーズです。

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

システム設計への入力

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

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

システム設計の出力

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

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

システム設計の種類

論理設計

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

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

物理設計

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

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

次の手順で構成されます-

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

建築デザイン

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

詳細設計

アーキテクチャ設計に従い、各モジュールの開発に焦点を当てています。

概念データモデリング

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

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

実体関連モデル

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

ERモデルで使用される用語

ENTITY−アプリケーション内の個別の実世界アイテムを指定します。例：ベンダー、アイテム、学生、コース、教師など。
RELATIONSHIP−エンティティ間の意味のある依存関係です。たとえば、ベンダーがアイテムを供給し、教師がコースを教え、次にサプライとコースが関係します。
ATTRIBUTES−関係のプロパティを指定します。たとえば、ベンダーコード、学生名。ERモデルで使用される記号とそれぞれの意味-

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

シンボル	意味
	エンティティ
	弱いエンティティ
	関係
	アイデンティティの関係
	属性
	主な属性
	多値
	複合属性
	派生属性
	RへのE2の総参加
	RのE1：E2のカーディナリティ比1：N

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

ファイル編成

レコードがファイル内にどのように保存されるかを説明します。

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

Serial −レコードは時系列で（入力または発生順に）保存されます。 Examples −電話料金、ATMトランザクション、電話キューの記録。
Sequential −レコードは、レコードを一意に識別する値を含むキーフィールドに基づいて順番に格納されます。 Examples −電話帳。
Direct (relative)−各レコードは、デバイス上の物理アドレスまたは場所に基づいて保存されます。アドレスは、レコードのキーフィールドに格納されている値から計算されます。ランダム化ルーチンまたはハッシュアルゴリズムが変換を行います。
Indexed −レコードは、インデックスを使用して順次および非順次の両方で処理できます。

比較

ファイルアクセス

シーケンシャルアクセスまたはランダムアクセスのいずれかを使用してファイルにアクセスできます。ファイルアクセス方式では、コンピュータプログラムがファイル内のレコードを読み書きできます。

シーケンシャルアクセス

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

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

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

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

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

Master file−システムの現在の情報が含まれています。たとえば、顧客ファイル、学生ファイル、電話帳などです。
Table file−変更頻度が低く、表形式で保存されるマスターファイルの一種です。たとえば、郵便番号を保存します。
Transaction file−事業活動から生み出される日々の情報が含まれています。マスターファイルを更新または処理するために使用されます。たとえば、従業員の住所。
Temporary file −システムで必要なときにいつでも作成され、使用されます。
Mirror file−他のファイルの正確な複製です。オリジナルが使用できなくなった場合のダウンタイムのリスクを最小限に抑えるのに役立ちます。元のファイルを変更するたびに変更する必要があります。
Log files−マスターファイルに加えられた変更を記録するために、マスターレコードとトランザクションレコードのコピーが含まれています。監査を容易にし、システム障害が発生した場合の回復メカニズムを提供します。
Archive files −他のファイルの履歴バージョンを含むバックアップファイル。

ドキュメント管理

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

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

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

利点

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

ドキュメントの種類

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

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

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

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

運用ドキュメント

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

以下の情報が含まれています-

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

ユーザードキュメント

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

ユーザー、システム所有者、アナリスト、およびプログラマーはすべて、ユーザーガイドを作成するために共同で努力しています。

ユーザードキュメントには次のものを含める必要があります-

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

システムドキュメント

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

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

トップダウン戦略

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

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

ボトムアップ戦略

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

このテクニックでは、

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

構造化設計

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

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

モジュール化

構造化設計は、プログラムを小さな独立したモジュールに分割します。これらはトップダウン方式で編成されており、詳細は下に示されています。

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

Advantages

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

構造化チャート

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

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

Control Module −これは、低レベルのモジュールを指示する高レベルのモジュールであり、 subordinate modules。
Library Module −これは再利用可能なモジュールであり、チャートの複数のポイントから呼び出すことができます。

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

Transform-Centered Structured Charts −すべてのトランザクションが同じパスをたどる場合に使用されます。
Transaction–Centered Structured Charts −すべてのトランザクションが同じパスをたどらない場合に使用されます。

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

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

システムの複雑さに影響を与える要因

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

システムの複雑さを判断するのに役立つ、システム開発に関連する2つの重要な概念は次のとおりです。 coupling そして cohesion。

カップリング

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

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

高結合

これらのタイプのシステムは、相互に依存するプログラムユニットと相互接続しています。一方のサブシステムを変更すると、もう一方のサブシステムに大きな影響を与えます。

低結合

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

カップリング対策

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

凝集

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

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

最良のモジュールは、機能的にまとまりのあるモジュールです。最悪のモジュールは、偶然にまとまりのあるモジュールです。

最悪の凝集度

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

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

入力設計

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

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

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

入力設計の目的

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

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

データ入力方法

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

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

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

一般的なデータ入力方法のいくつかは次のとおりです。

一括入力方式（オフラインデータ入力方式）
オンラインデータ入力方式
コンピューターで読み取り可能なフォーム
インタラクティブなデータ入力

入力整合性制御

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

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

出力設計

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

出力設計の目的

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

意図された目的を果たし、不要な出力の生成を排除する出力設計を開発すること。
エンドユーザーの要件を満たす出力設計を開発するため。
適切な量の出力を提供するため。
適切な形式で出力を作成し、適切な人に向けること。
適切な決定を行うために、出力を時間どおりに利用できるようにすること。

さまざまなタイプの出力を見てみましょう-

外部出力

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

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

内部出力

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

経営情報によって作成されるレポートには3つのタイプがあります-

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

出力整合性制御

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

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

フォームデザイン

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

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

優れたフォームデザインの目的

次のことを確実にするために、適切なフォームデザインが必要です。

適切な順序、情報、明確なキャプションを付けて画面をシンプルに保つため。
適切なフォームを使用して、意図した目的を達成するため。
フォームを正確に完成させるため。
アイコン、反転ビデオ、またはカーソルの点滅などを使用して、フォームを魅力的に保つため。
ナビゲーションを容易にするため。

フォームの種類

Flat Forms

これは、手動または機械で作成され、紙に印刷された単一のコピーフォームです。オリジナルの追加コピーの場合、カーボンペーパーがコピーの間に挿入されます。
これは、デザイン、印刷、複製が最も簡単で安価なフォームであり、使用量が少なくて済みます。

Unit Set/Snap out Forms

これらは、手書きまたは機械で使用するために、1回限りの炭素がユニットセットにインターリーブされた紙です。
Carbons may be either blue or black, standard grade medium intensity. Generally, blue carbons are best for handwritten forms while black carbons are best for machine use.

Continuous strip/Fanfold Forms

These are multiple unit forms joined in a continuous strip with perforations between each pair of forms.
It is a less expensive method for large volume use.

No Carbon Required (NCR) Paper

They use carbonless papers which have two chemical coatings (capsules), one on the face and the other on the back of a sheet of paper.
When pressure is applied, the two capsules interact and create an image.

The software system needs to be checked for its intended behavior and direction of progress at each development stage to avoid duplication of efforts, time and cost overruns, and to assure completion of the system within stipulated time.The software system needs to be checked for its intended behavior and direction of progress at each development stage to avoid duplication of efforts, time and cost overruns, and to assure completion of the system within stipulated time.

System testing and quality assurance come to aid for checking the system. It includes −

Product level quality (Testing)
Process level quality.

Let us go through them briefly −

Testing

Testing is the process or activity that checks the functionality and correctness of software according to specified user requirements in order to improve the quality and reliability of system. It is an expensive, time consuming, and critical approach in system development which requires proper planning of overall testing process.

A successful test is one that finds the errors. It executes the program with explicit intention of finding error, i.e., making the program fail. It is a process of evaluating system with an intention of creating a strong system and mainly focuses on the weak areas of the system or software.

Characteristics of System Testing

System testing begins at the module level and proceeds towards the integration of the entire software system. Different testing techniques are used at different times while testing the system. It is conducted by the developer for small projects and by independent testing groups for large projects.

Stages of System Testing

The following stages are involved in testing −

Test Strategy

It is a statement that provides information about the various levels, methods, tools, and techniques used for testing the system. It should satisfy all the needs of an organization.

Test Plan

It provides a plan for testing the system and verifies that the system under testing fulfils all the design and functional specifications. The test plan provides the following information −

Objectives of each test phase
Approaches and tools used for testing
Responsibilities and time required for each testing activity
Availability of tools, facilities, and test libraries
Procedures and standards required for planning and conducting the tests
Factors responsible for successful completion of testing process

Test Case Design

A number of test cases are identified for each module of the system to be tested.
Each test case will specify how the implementation of a particular requirement or design decision is to be tested and the criteria for the success of the test.
The test cases along with the test plan are documented as a part of a system specification document or in a separate document called test specification or test description.

Test Procedures

It consists of the steps that should be followed to execute each of the test cases. These procedures are specified in a separate document called test procedure specification. This document also specifies any special requirements and formats for reporting the result of testing.

Test Result Documentation

Test result file contains brief information about the total number of test cases executed, the number of errors, and nature of errors. These results are then assessed against criteria in the test specification to determine the overall outcome of the test.

Types of Testing

Testing can be of various types and different types of tests are conducted depending on the kind of bugs one seeks to discover −

Unit Testing

Also known as Program Testing, it is a type of testing where the analyst tests or focuses on each program or module independently. It is carried out with the intention of executing each statement of the module at least once.

In unit testing, accuracy of program cannot be assured and it is difficult to conduct testing of various input combination in detail.
It identifies maximum errors in a program as compared to other testing techniques.

Integration Testing

In Integration Testing, the analyst tests multiple module working together. It is used to find discrepancies between the system and its original objective, current specifications, and systems documentation.

Here the analysts are try to find areas where modules have been designed with different specifications for data length, type, and data element name.
It verifies that file sizes are adequate and that indices have been built properly.

Functional Testing

Function testing determines whether the system is functioning correctly according to its specifications and relevant standards documentation. Functional testing typically starts with the implementation of the system, which is very critical for the success of the system.

Functional testing is divided into two categories −

Positive Functional Testing − It involves testing the system with valid inputs to verify that the outputs produced are correct.
Negative Functional Testing − It involves testing the software with invalid inputs and undesired operating conditions.

Rules for System Testing

To carry out system testing successfully, you need to follow the given rules −

Testing should be based on the requirements of user.
Before writing testing scripts, understand the business logic should be understood thoroughly.
Test plan should be done as soon as possible.
Testing should be done by the third party.
It should be performed on static software.
Testing should be done for valid and invalid input conditions.
Testing should be reviewed and examined to reduce the costs.
Both static and dynamic testing should be conducted on the software.
Documentation of test cases and test results should be done.

Quality Assurance

It is the review of system or software products and its documentation for assurance that system meets the requirements and specifications.

Purpose of QA is to provide confidence to the customers by constant delivery of product according to specification.
Software quality Assurance (SQA) is a techniques that includes procedures and tools applied by the software professionals to ensure that software meet the specified standard for its intended use and performance.
The main aim of SQA is to provide proper and accurate visibility of software project and its developed product to the administration.
It reviews and audits the software product and its activities throughout the life cycle of system development.

Objectives of Quality Assurance

The objectives of conducting quality assurance are as follows −

To monitor the software development process and the final software developed.
To ensure whether the software project is implementing the standards and procedures set by the management.
To notify groups and individuals about the SQA activities and results of these activities.
To ensure that the issues, which are not solved within the software are addressed by the upper management.
To identify deficiencies in the product, process, or the standards, and fix them.

Levels of Quality Assurance

There are several levels of QA and testing that need to be performed in order to certify a software product.

Level 1 − Code Walk-through

At this level, offline software is examined or checked for any violations of the official coding rules. In general, the emphasis is placed on examination of the documentation and level of in-code comments.

Level 2 − Compilation and Linking

At this level, it is checked that the software can compile and link all official platforms and operating systems.

Level 3 − Routine Running

At this level, it is checked that the software can run properly under a variety of conditions such as certain number of events and small and large event sizes etc.

Level 4 − Performance test

At this final level, it is checked that the performance of the software satisfies the previously specified performance level.

Implementation is a process of ensuring that the information system is operational. It involves −

Constructing a new system from scratch
Constructing a new system from the existing one.

Implementation allows the users to take over its operation for use and evaluation. It involves training the users to handle the system and plan for a smooth conversion.

Training

The personnel in the system must know in detail what their roles will be, how they can use the system, and what the system will or will not do. The success or failure of welldesigned and technically elegant systems can depend on the way they are operated and used.

Training Systems Operators

Systems operators must be trained properly such that they can handle all possible operations, both routine and extraordinary. The operators should be trained in what common malfunctions may occur, how to recognize them, and what steps to take when they come.

Training involves creating troubleshooting lists to identify possible problems and remedies for them, as well as the names and telephone numbers of individuals to contact when unexpected or unusual problems arise.

Training also involves familiarization with run procedures, which involves working through the sequence of activities needed to use a new system.

User Training

End-user training is an important part of the computer-based information system development, which must be provided to employees to enable them to do their own problem solving.
User training involves how to operate the equipment, troubleshooting the system problem, determining whether a problem that arose is caused by the equipment or software.
Most user training deals with the operation of the system itself. The training courses must be designed to help the user with fast mobilization for the organization.

Training Guidelines

Establishing measurable objectives
Using appropriate training methods
Selecting suitable training sites
Employing understandable training materials

Training Methods

Instructor-led training

It involves both trainers and trainees, who have to meet at the same time, but not necessarily at the same place. The training session could be one-on-one or collaborative. It is of two types −

Virtual Classroom

In this training, trainers must meet the trainees at the same time, but are not required to be at the same place. The primary tools used here are: video conferencing, text based Internet relay chat tools, or virtual reality packages, etc.

Normal Classroom

The trainers must meet the trainees at the same time and at the same place. They primary tools used here are blackboard, overhead projectors, LCD projector, etc.

Self-Paced Training

It involves both trainers and trainees, who do not need to meet at the same place or at the same time. The trainees learn the skills themselves by accessing the courses at their own convenience. It is of two types −

Multimedia Training

In this training, courses are presented in multimedia format and stored on CD-ROM. It minimizes the cost in developing an in-house training course without assistance from external programmers.

Web-based Training

In this training, courses are often presented in hyper media format and developed to support internet and intranet. It provides just–in-time training for end users and allow organization to tailor training requirements.

Conversion

It is a process of migrating from the old system to the new one. It provides understandable and structured approach to improve the communication between management and project team.

Conversion Plan

It contains description of all the activities that must occur during implementation of the new system and put it into operation. It anticipates possible problems and solutions to deal with them.

It includes the following activities −

Name all files for conversions.
Identifying the data requirements to develop new files during conversion.
Listing all the new documents and procedures that are required.
Identifying the controls to be used in each activity.
Identifying the responsibility of person for each activity.
Verifying conversion schedules.

Conversion Methods

The four methods of conversion are −

Parallel Conversion
Direct Cutover Conversion
Pilot Approach
Phase-In Method

Method	Description	Advantages	Disadvantages
Parallel Conversion	Old and new systems are used simultaneously.	Provides fallback when new system fails. Offers greatest security and ultimately testing of new system.	Causes cost overruns. New system may not get fair trail.
Direct Cutover Conversion	New system is implemented and old system is replaced completely.	Forces users to make new system work Immediate benefit from new methods and control.	No fall back if problems arise with new system Requires most careful planning
Pilot Approach	Supports phased approach that gradually implement system across all users	Allows training and installation without unnecessary use of resources. Avoid large contingencies from risk management.	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 When preferred new system involves new technology or drastic changes in performance.	Gives impression that old system is erroneous and it is not reliable.

File Conversion

It is a process of converting one file format into another. For example, file in WordPerfect format can be converted into Microsoft Word.

For successful conversion, a conversion plan is required, which includes −

Knowledge of the target system and understanding of the present system
Teamwork
Automated methods, testing and parallel operations
Continuous support for correcting problems
Updating systems/user documentation, etc

Many popular applications support opening and saving to other file formats of the same type. For example, Microsoft Word can open and save files in many other word processing formats.

Post-Implementation Evaluation Review (PIER)

PIER is a tool or standard approach for evaluating the outcome of the project and determine whether the project is producing the expected benefits to the processes, products or services. It enables the user to verify that the project or system has achieved its desired outcome within specified time period and planned cost.

PIER ensures that the project has met its goals by evaluating the development and management processes of the project.

Objectives of PIER

The objectives of having a PIER are as follows −

To determine the success of a project against the projected costs, benefits, and timelines.
To identify the opportunities to add additional value to the project.
To determine strengths and weaknesses of the project for future reference and appropriate action.
To make recommendations on the future of the project by refining cost estimating techniques.

The following staff members should be included in the review process −

Project team and Management
User staff
Strategic Management Staff
External users

System Maintenance / Enhancement

Maintenance means restoring something to its original conditions. Enhancement means adding, modifying the code to support the changes in the user specification. System maintenance conforms the system to its original requirements and enhancement adds to system capability by incorporating new requirements.

Thus, maintenance changes the existing system, enhancement adds features to the existing system, and development replaces the existing system. It is an important part of system development that includes the activities which corrects errors in system design and implementation, updates the documents, and tests the data.

Maintenance Types

System maintenance can be classified into three types −

Corrective Maintenance − Enables user to carry out the repairing and correcting leftover problems.
Adaptive Maintenance − Enables user to replace the functions of the programs.
Perfective Maintenance − Enables user to modify or enhance the programs according to the users’ requirements and changing needs.

System Audit

It is an investigation to review the performance of an operational system. The objectives of conducting a system audit are as follows −

To compare actual and planned performance.
To verify that the stated objectives of system are still valid in current environment.
To evaluate the achievement of stated objectives.
To ensure the reliability of computer based financial and other information.
To ensure all records included while processing.
To ensure protection from frauds.

Audit of Computer System Usage

Data processing auditors audits the usage of computer system in order to control it. The auditor need control data which is obtained by computer system itself.

The System Auditor

The role of auditor begins at the initial stage of system development so that resulting system is secure. It describes an idea of utilization of system that can be recorded which helps in load planning and deciding on hardware and software specifications. It gives an indication of wise use of the computer system and possible misuse of the system.

Audit Trial

An audit trial or audit log is a security record which is comprised of who has accessed a computer system and what operations are performed during a given period of time. Audit trials are used to do detailed tracing of how data on the system has changed.

It provides documentary evidence of various control techniques that a transaction is subject to during its processing. Audit trials do not exist independently. They are carried out as a part of accounting for recovering lost transactions.

Audit Methods

Auditing can be done in two different ways −

Auditing around the Computer

Take sample inputs and manually apply processing rules.
Compare outputs with computer outputs.

Auditing through the Computer

Establish audit trial which allows examining selected intermediate results.
Control totals provide intermediate checks.

Audit Considerations

Audit considerations examine the results of the analysis by using both the narratives and models to identify the problems caused due to misplaced functions, split processes or functions, broken data flows, missing data, redundant or incomplete processing, and nonaddressed automation opportunities.

The activities under this phase are as follows −

Identification of the current environment problems
Identification of problem causes
Identification of alternative solutions
Evaluation and feasibility analysis of each solution
Selection and recommendation of most practical and appropriate solution
Project cost estimation and cost benefit analysis

Security

System security refers to protecting the system from theft, unauthorized access and modifications, and accidental or unintentional damage. In computerized systems, security involves protecting all the parts of computer system which includes data, software, and hardware. Systems security includes system privacy and system integrity.

System privacy deals with protecting individuals systems from being accessed and used without the permission/knowledge of the concerned individuals.
System integrity is concerned with the quality and reliability of raw as well as processed data in the system.

Control Measures

There are variety of control measures which can be broadly classified as follows −

Backup

Regular backup of databases daily/weekly depending on the time criticality and size.
Incremental back up at shorter intervals.
Backup copies kept in safe remote location particularly necessary for disaster recovery.
Duplicate systems run and all transactions mirrored if it is a very critical system and cannot tolerate any disruption before storing in disk.

Physical Access Control to Facilities

Physical locks and Biometric authentication. For example, finger print
ID cards or entry passes being checked by security staff.
Identification of all persons who read or modify data and logging it in a file.

Using Logical or Software Control

Password system.
Encrypting sensitive data/programs.
Training employees on data care/handling and security.
Antivirus software and Firewall protection while connected to internet.

Risk Analysis

A risk is the possibility of losing something of value. Risk analysis starts with planning for secure system by identifying the vulnerability of system and impact of this. The plan is then made to manage the risk and cope with disaster. It is done to accesses the probability of possible disaster and their cost.

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

リスク分析を行う際は、以下の手順に従ってください。

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

リスク分析–主なステップ

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

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

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

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

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

OOモデルは、次の点で有益です。

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

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

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

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

オブジェクト指向システムの特徴

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

カプセル化

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

抽象化

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

関係

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

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

Aggregation −全体とその一部の関係を示します。
Association −この場合、1つのクラスが別のクラスと連携してタスクを実行したり、1つのクラスが他のクラスに作用したりするなど、2つのクラスが何らかの方法で関連付けまたは接続されます。
Generalization−子クラスは親クラスに基づいています。これは、2つのクラスが類似しているが、いくつかの違いがあることを示しています。

継承

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

ポリモーフィズムと動的バインディング

ポリモーフィズムは、さまざまな形をとる能力です。これは、オブジェクトと操作の両方に適用されます。ポリモーフィックオブジェクトは、真の型がスーパークラスまたは親クラス内に隠れているオブジェクトです。

多態的操作では、操作は、異なるクラスのオブジェクトによって異なる方法で実行される場合があります。これにより、共通のプロパティのみを知ることで、さまざまなクラスのオブジェクトを操作できます。

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

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

構造化アプローチ	オブジェクト指向アプローチ
トップダウンアプローチで動作します。	ボトムアップアプローチで動作します。
プログラムは、いくつかのサブモジュールまたは機能に分割されています。	プログラムは、クラスとオブジェクトの数を持つことによって編成されています。
関数呼び出しが使用されます。	メッセージパッシングが使用されます。
ソフトウェアの再利用はできません。	再利用が可能です。
構造化設計プログラミングは通常、最終段階まで残されます。	他のフェーズと同時に行われるオブジェクト指向設計プログラミング。
構造化設計はオフショアリングに適しています。	社内開発に適しています。
設計から実装への明確な移行を示しています。	設計から実装への移行はそれほど明確ではありません。
これは、リアルタイムシステム、組み込みシステム、およびオブジェクトが最も有用な抽象化レベルではないプロジェクトに適しています。	これは、カスタマイズまたは拡張が期待されるほとんどのビジネスアプリケーション、ゲーム開発プロジェクトに適しています。
DFD＆ER図はデータをモデル化します。	クラス図、シーケンス図、状態チャート図、およびユースケースはすべて貢献しています。
この場合、明確に識別可能なフェーズにより、プロジェクトを簡単に管理できます。	このアプローチでは、フェーズ間の移行が不確実であるため、プロジェクトの管理が困難になる可能性があります。

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

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

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

UMLの目的は、分析から実装までのシステム開発プロジェクトをモデル化するのに十分な豊富なオブジェクト指向用語とダイアグラム作成手法の共通語彙を提供することです。

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

Diagrams −これは、プロセス、システム、またはその一部を図で表したものです。
Notations −コネクタ、記号、メモなど、図で連携して機能する要素で構成されています。

クラスのUML表記の例

インスタンス図-UML表記

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

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

Constructor/Destructor−クラスの新しいインスタンスを作成し、クラスの既存のインスタンスを削除します。たとえば、新しい従業員を追加します。
Query−値を変更せずに状態にアクセスしても、副作用はありません。たとえば、特定の従業員の住所を検索します。
Update − 1つ以上の属性の値を変更し、オブジェクトの状態に影響を与えます。たとえば、従業員の住所を変更します。

UMLの使用

UMLは次の目的に非常に役立ちます-

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

静的モデル

静的モデルは、システムの構造特性を示し、そのシステム構造を記述し、システムを構成する部分に重点を置いています。

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

動的モデル

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

動的モデルは、必要なオブジェクトと、メソッドとメッセージを介してそれらがどのように連携するかを識別します。
これらは、システムのロジックと動作を設計するために使用されます。
UMLダイアグラムは、シーケンスダイアグラム、通信ダイアグラム、状態ダイアグラム、アクティビティダイアグラムを含む動的モデルを表します。

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

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

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

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

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

オブジェクト指向分析
オブジェクト指向設計
Prototyping
Implementation
インクリメンタルテスト

オブジェクト指向分析

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

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

オブジェクト指向設計

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

プロトタイピング

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

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

実装

コンポーネントベース開発（CBD）またはRapid Application Development（RAD）のいずれかを使用します。

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

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

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

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

そのタスクは、Visual Basic、Power Builderなどのツールを使用して、アプリケーションを迅速かつ段階的に実装することです。

インクリメンタルテスト

ソフトウェア開発とテストを含むそのすべての活動は、反復的なプロセスです。したがって、製品が完全に開発された後でのみテストを待つと、コストがかかる可能性があります。ここで、製品が開発のさまざまな段階でテストされる増分テストが明らかになります。