実現可能性調査: 実現可能性調査とは、簡単に言うと、設計したいソフトウェアが現在の技術を使用して完成できるかどうか、完成までに消費される時間と資本が妥当な範囲内であるかどうか、ソフトウェアの機能が現在存在する問題を解決できるかどうか、現在のソフトウェアが完成できるかどうか、その開発が会社にプラスの利益をもたらすことができるかどうか。

要件分析: ソフトウェア全体の開発において決定的な役割を果たすソフトウェアの機能と効率を分析し、最終的にソフトウェアの機能と効率に従ってソフトウェア要件仕様を生成します。

概要設計：各機能の詳細な実装には関わらず、主にプログラム全体の設計を目的として、インターフェース、プロトコル、コンストレイント（全体制約）などソフトウェアの公開部分を設計します。

詳細設計：各業務の具体的な運用や設計を含む、ソフトウェアの各業務やプロセスの詳細設計

実現：各事業の実現

アセンブリ (統合) テスト: ソフトウェアを展開し、すべての機能をテストします。

確認テスト: すべての機能が期待どおりであるかどうかをユーザーに確認させ、ソフトウェア全体を受け入れます。

メンテナンス：必要なさまざまなメンテナンス活動を通じて、システムはユーザーのニーズに長期間対応します。

廃止:ソフトウェア製品のサポート終了、ソフトウェアの廃止

2. プロジェクトアーキテクチャの分類

一般的なプロジェクトのアーキテクチャは主にC/SアーキテクチャとB/Sアーキテクチャの2種類に分けられます。

C/S アーキテクチャはクライアント/サーバーラックです

B/S アーキテクチャはブラウザ/サーバーラックです

C/Sアーキテクチャ

C/S アーキテクチャの正式名称はクライアント/サーバー (Client / Server) アーキテクチャであり、一般的に使用される 2 層アーキテクチャです。クライアントはクライアントをインストールする必要があります

クライアントソフトウェア、サーバープログラムはサーバー上で実行され、ソケットサービスまたはデータベースサービスを提供します。

アドバンテージ：

•ビジネスのほとんどをクライアント側で実行できるため、ローカルのコンピュータリソースを最大限に活用できます。

•素早い応答

•強力なカスタマイズ能力

•比較的固定されたユーザーグループに直面しているため、情報セキュリティを制御する能力が高い

欠点:

•使用するにはクライアントをインストールする必要があります

•メンテナンスコストが高く、どのコンピュータでもクライアントに問題がある場合はメンテナンスが必要で、アップグレードプロセスが煩雑です

B/S構造

B/S アーキテクチャの正式名称はブラウザ/サーバー (Browser/Server) 構造で、Web ブラウザ、サーバープログラム、データベースサーバーに分かれます。

これは、C/S アーキテクチャの改良として理解できます。ビジネスロジックはすべてサーバープログラムで処理されるため、クライアントはブラウザのみですべての操作を完了でき、クライアントの保守コストを大幅に削減できます。

現在 Java を使用して設計しているプログラムは BS アーキテクチャに属しています。

アドバンテージ：

•クライアント側のメンテナンスは不要、ブラウザをインストールするだけで済みます。

•すべての業務がサーバー側に集中しているため、ビジネスの拡張が非常に便利です

•保守コストが低いため、サーバーの保守のみが必要です

欠点:

•ネットワーク経由でリクエストを送信し、レスポンスを受信するため、ネットワークの影響を大きく受けます。

•サーバーのセキュリティとビジネス処理機能には多大な労力とコストが必要です

•さまざまなブラウザのサポートが不十分

3. ソフトウェア要件の詳細説明

ニーズの分類

a.ビジネス要件: システムに対する企業または顧客のターゲット要件を指し、通常は企業内、つまりソフトウェアの主要なビジネス内からのものです。

b.ユーザー要件: ユーザーの具体的な目標、またはユーザーがシステムに実行できるように要求するタスクを説明します。（ビジネスニーズ以外のユーザー自身のニーズ）

c.システム要件：機能要件（システムが実現しなければならない機能）、非機能要件など、システムの観点からソフトウェアの要件を記述します。

(ソフトウェアの品質、保守性、効率など) および設計上の制約 ( 独立した知的財産権を持つデータベースを使用する必要があり、特定のオペレーティングシステムで実行する必要がある

需要の獲得

要件を取得するには主に次の方法があります。

a.ユーザーインタビュー: 最も基本的な方法。

b.アンケート調査：ユーザーを一人一人インタビューするのは時間がかかり、ユーザーの時間の関係でタイムリーにインタビューに参加できない可能性があるため、ユーザーに記入してもらうためのアンケートを 事前に結果に基づいた小規模なインタビュー。これはユーザーインタビューの 最適化。

c.サンプリング: 特定の母集団をサンプリングし、選択したサンプルを研究し、有用な情報を取得します。情報システムの開発では、 ドキュメントがサンプリング母集団となります。

d.ストーリーボード: システムの画像とスライドを通じて、システムがどのように動作するかを説明します。

需要分析

要件を取得した後、具体的な要件分析作業を実施し、最終的にソフトウェア要件仕様書を作成し、次の段階に納品します。

成果

a.システムコンテキストダイアグラムを描画します: 要件に応じて、システムとシステムの外部エンティティの間の境界とインターフェイスを定義するために使用される単純なモデル

範囲を決定します。

b.ユーザーインターフェイスプロトタイプの作成: 迅速な開発ツールを使用してプロトタイプを開発したり、 スライドショーや Flash などのプレゼンテーションツールを使用してデモプロトタイプを作成したりユーザーは解決すべき問題をより深く 理解し、システムを理解することができます。

c.要件の実現可能性分析: 取得した要件について、コスト、性能、技術的実現の観点、他の要件 との。

d.要件の優先順位の決定: これは反復計画を策定するための重要な基礎であり、満足度および不満足度の指標を使用して 説明。満足は要件が実現された場合のユーザーの満足を示し、不満足は要件が実現されなかった場合のユーザーの 不満。

e.要件のモデルを構築します: 主な表現形式は図と少量のテキスト説明であり、図による説明により要件がより明確になり理解しやすくなります 。要件分析モデルは、主にシステムのデータ、機能、ユーザーインターフェイス、および外部動作を記述し、 ソフトウェア

f.データディクショナリの作成: システムで使用されるすべてのデータ項目と構造を定義し、開発者が統一されたデータ 定義

4. オブジェクト指向分析(OOA)の詳細説明

概念の理解:

1オブジェクト指向分析 (OOA)

「何をすべきか」問題を解決するための要件分析段階で発生します。主なタスクは、オブジェクト、オブジェクト、およびオブジェクトの属性とメソッドを決定することです。

各操作間の関係、各操作の特定のプロセス。ただし、システムの特定の実装に関連する要素は考慮されていません。

2.2オブジェクト指向設計 (OOD)

システムの設計段階で発生し、「どうやって行うか」という問題を解決します。その基本的な考え方には、抽象化、カプセル化、スケーラビリティが含まれます。

中程度のスケーラビリティは、主に継承とポリモーフィズムによって実現されます。主なタスクは、実装オブジェクトのエンジニアリングを標準化し、プログラム内のさまざまな部分の相互依存性を管理し、オブジェクト指向プログラミングのガイダンスと基礎を提供することです。

2.3オブジェクト指向プログラミング (OOP) は、システム開発中に発生します。

統一モデリング言語 UML

UML (統一モデリング言語) は、表現が簡単で強力な、普遍的に適用可能なモデリング言語です。

この機能はOOAやOODのサポートにとどまらず、要件分析から始まるソフトウェア開発のプロセス全体をサポートします。

UML の重要なコンポーネント:

◦ モノ: モノはモデリング要素とも呼ばれ、構造的なもの、動作的なもの、階層的なもの、注釈的なものなど、 UML モデルの最も基本的な OO 構成要素です。

◦関係: UML は関係を使用してさまざまなものを組み合わせます。主な関係は、依存関係、関連性です。

(関連付け)、一般化、実現。

◦図: 主にクラス図、オブジェクト図、コンポーネント図、複合構造図、ユースケース図、シーケンス図、通信 図。

ユーザーの観点から見ると、システムの内部構造や設計を理解したいのではなく、システムが提供できるサービスが重要です。

ユーザーから得た要件を記録し、それらを統合および洗練して、ユースケースモデルを確立します。OOA 手法では、ユースケースモデルの構築には通常、参加者の特定、ユースケースを取得するための要件の結合、ユースケースの説明の洗練、およびユースケースモデルの調整という各段階を経る必要があり、そのうち最初の 3 つの段階が必要です。。

ユースケース図の要素

ユースケースはシステム要件を記述する方法であり、ユースケース図には主にアクター、ユースケース、通信の関連付けという 3 つの要素が含まれます。

図に示すように:

アクター: 参加者とは、システムの外部に存在し、システムと対話するあらゆるものであり、システムを使用するユーザーの場合もあります。

ユーザー、または他の外部システムやデバイスなど。

ユースケース: アクターに見える結果をもたらす、システム内で実行されるアクションを指します。つまり、ユースケースは、 システムが提供するサービスを表し、参加者によるシステムの使用方法を定義し、 システムが提供するサービスと使用方法を使用するための参加者間の対話を記述します。

コミュニケーションの関連付け: アクターとユースケースの関係、またはユースケースとユースケースの関係を表します。矢印が指す当事者は 対話、矢印の尾が指す当事者は対話の積極的な開始者です。対話における能動と受動の関係を強調したくない場合は、次のように することができます。矢印のない実線の関係線を使用してください。

参加者を特定する

参加者はシステムと対話するすべてのものであり、人間だけでなく、他のシステムやハードウェアデバイスも参加できます。注意してください。

さらに、参加者はシステムの一部ではなく、システムの外部にいる必要があります。複数の参加者が優先順位を付けてシステム機能を実行する場合があります。

同時に、ユースケースを開発する主な目的は、主要なプレーヤーを見つけることです。

システムアクターの分析と発見は、次の質問をすることで役立ちます。システムを使用するのは誰ですか? このシステムを設置したのは誰ですか? 誰が始めたのか

システムを動かす？このシステムを維持しているのは誰ですか? このシステムをシャットダウンするのは誰ですか? どのシステムがこのシステムを使用していますか? このシステムから手紙を受け取るのは誰ですか

興味？このシステムの情報は誰が提供しますか?

◦ ⽰例：

現在開発中のフォーラムシステムを例に挙げると、初期段階で次のようなユーザー要件を取得しています。

▪登録してログインする

▪投稿一覧、投稿投稿、投稿削除、投稿返信などの機能。

▪個人ホームページの表示/編集をサポートし、アバターのアップロードをサポートします。

▪フォーラムによる投稿の分類をサポートします。

▪画像絵文字の投稿をサポート

▪サイト内でのプライベートメッセージのサポート

▪管理者はセクションを追加/削除/変更できます。

▪管理者はすべての投稿を管理できます

上記の要件の説明に基づいて、2 人の参加者、1 人は管理者、もう 1 人は一般ユーザーであることが明確にわかります。

要件をマージしてユースケースを取得する

アクターが見つかったら、次のステップはアクターを調べて、各アクターのユースケースを特定することです。

まず、一般ユーザーでも登録、ログイン、個人情報の編集ができるなど、取得した要件を参加者に割り当てます。

管理者は情報提供、投稿、自己公開投稿の修正、内部メッセージの送信など、一般ユーザーの操作だけでなく、掲示板などの管理も行うことができます。

次に、要件のマージ操作を実行し、ユースケースを生成します。たとえば、投稿の場合、投稿の公開、投稿の変更、投稿の削除があり、これらは ここで操作投稿にマージされます。注: ユースケースには特定の操作プロセス (イベントフロー) を含める必要はありません。イベントフローは ユースケースの詳細な説明に反映されます。

次に、特定された参加者とマージされたユースケースをユースケース図の形式で表現し、ユースケースモデル の。以下の図に示すように:

使用例の詳細な説明

ユースケースの説明は繰り返して完成させることができます。まず、いくつかの重要なユースケースについては比較的詳細な説明を準備します。重要でないユースケースについては、次のようにします。

後で補足しますが、ユースケースの説明には通常、ユースケース名、簡単な説明、イベントフロー、非機能要件、事前および事後が含まれます。

設定条件、拡張ポイント、優先度。

運用後のユースケースにおけるポスト投稿を例に説明すると以下のようになります。

1. ⽤例名称	投稿を公開する
2.簡単な説明	ユーザーは新しい投稿を公開し、同時に対応するフォーラムの投稿数を増やします。
3.イベントの流れ	1. ユーザーはシステムに新しい投稿を投稿するリクエストを送信します。 2. システムは新しい投稿を編集するためのインターフェイスを表示します 3. ユーザーは、対応するフォーラムカテゴリを選択し、投稿のタイトルと本文を書いて送信します。 4. システムはブロックのカテゴリ、タイトル、テキストが有効かどうかをチェックします。 5. システムは入力された情報を保存およびアーカイブし、投稿は正常に公開されます。
4. 代替イベントフロー	なし
5. 非機能要件	特別な要件はありません
6.前提条件	ユーザーは権限を確認するためにシステムにログインする必要があります
7.事後条件	対応するフォーラムの投稿数を変更します
8.拡張ポイント	⽆
9.優先順位	最高（満足5、不満5）

上記のユースケースの詳細な記述例によれば、ユーザーは投稿前にログイン状態を確認する必要があり、投稿操作には本人確認が含まれることがわかります。

ID 検証は他の操作にも関与するため、ユースケース図を使用して ID 検証のユースケースを抽象化し、ユースケースを説明します。

例間の関係は次のとおりです。

概念クラスを定義する

Concept クラス: 物や概念を表現できるモデル内のオブジェクト。

OOA の主なタスクは、システム内のオブジェクトとクラスを検索することです。これらのクラスは、OOD のソフトウェアクラスと OOP の特定の実装クラスに反映されます。

現在のクラス。

クラスを検出するにはさまざまな方法がありますが、その中で名詞句構文が最も広く使用されており、具体的な手順は次のとおりです。

▪要件文書またはユースケースの説明を読んで理解する

▪名詞または名詞句を選別し、初期クラスリスト（候補クラス）を作成する

▪候補クラスを明らかなクラス、明らかに意味のないクラス、不確実なクラスの 3 つのカテゴリに分類します。

▪明らかに無意味なカテゴリのクラスを破棄する

グループは、不定のカテゴリのクラスについて、他の 2 つのカテゴリに統合または調整されるまで話し合います。

セクション 4.2.4 によると、次のように、ポストユースケースのイベントフローを使用して、候補概念クラスのリストを取得できます。

簡単な分析の後: 「フォーラムカテゴリ」と「フォーラム投稿数」の両方が、「フォーラム」カテゴリとして「フォーラム」カテゴリに帰属することができます。

属性; 「投稿タイトル」と「投稿本文」は、「投稿」クラスの属性として「投稿」クラスに帰属させることができます。

「User」クラスの属性として、「Limit」を「User」クラスに帰属させることができます。投稿を公開するユースケースでは、これまでのところ、3つ

カテゴリはユーザー、フォーラム、投稿です。

クラス間の関係を特定する

クラス検索作業が完了したら、これらのクラス間の関係を明確にする必要があります。クラス間の関係には、関連性、依存性、汎用性が含まれます。

これらは UML では次のように表現されます。

関連付け関係: クラス間の関係ではなく、異なるクラスのオブジェクト間の構造的な関係を提供します。2 つのオブジェクトは通常、 動詞 (例: user-publish-post) によって接続されます。矢印がない場合は、双方向の関係または未定義の関連と みなされます。

依存関係: 2 つのクラス A と B、B の変更が A の変更を引き起こす可能性がある場合、クラス A は B に依存していると言われます。たとえば、あるクラスは別のクラスのデータメンバーであり、あるクラスは別のクラスです 。クラスなどの演算のパラメータ。

◦ 集約関係: 共有集約関係は通常、集約関係と呼ばれ、クラスの全体と一部の間の関係を表します。

「部品」は異なる「全体」に属することができ、「部品」と「全体」のライフサイクルは異なる場合があります（たとえば、車と車輪）

車には複数の車輪があり、車が壊れてもその車輪は使える、車輪が壊れても別の車輪に取り替えられる、車には複数の車輪がある、という集合関係です。

◦複合関係: 組み合わせ集計関係は、通常、組み合わせ関係と略して呼ばれます。また、クラス間の全体と部分の関係を表します。 集計関係との違いは、組み合わせ関係の「部分」が可能であることです。一つの「全体」にのみ属する「部分」と「全体」の生命

例えば、会社には複数の部門があり、それらの間には結合関係があり、会社が廃業すれば消滅する部分もあれば、消滅する部分もあるというサイクルも同じです。

実装関係: クラスとインターフェイスの間の関係を説明します。クラスはインターフェイスで宣言されたメソッドを実装できます。

汎化関係: 親クラスとサブクラスの関係を記述します。継承関係は汎化関係の逆の関係です。つまり、サブクラスは親クラス を継承し。

ユーザーが投稿を公開するユースケースでは、次の図に示すように、クラス間の関係を決定した後、UML クラス図を使用してこれらの関係 を

クラスに責任を追加する

概念クラスを見つけてそれらの間の関係を整理した後、主に次の 2 つの側面を含む責任をクラスに追加できます。

▪クラスによって維持される知識、つまりメンバー変数またはプロパティ

•属性をシンプルに保つように注意してください。つまり、システムの責任と目標に関連する属性のみを定義し、単純なデータクラスを使用してください。

型の定義。クラスの関連付けには属性が定義されていません。

▪クラスが実行できる動作、つまりメンバーのメソッドまたは責任

•動詞に従って判断し、スクリーニングすることができます。これはカテゴリを識別するプロセスと似ています。

この段階では、いくつかの主要な明白なビジネスルール関連の部分のみが見つかります。この段階ではこれ以上改良しないでください。

クラスの責任を分析すると、クラス図で次のように表現されます。

インタラクション図を作成する

複数のオブジェクトの動作は通常、相互作用図によって表されます。UML で最も一般的に使用されるのはシーケンス図であり、ほぼすべてのシステムで使用できます。

シーン。

シーケンス図の基本要素は、オブジェクト、参加者、ライフライン、アクティベーションボックス、メッセージ、およびメッセージラインであり、その中でメッセージがシーケンス図のインスピレーションとなります。

魂。ユーザーのログインプロセスを例として、シーケンス図は次のように説明されます。

ソフトウェア要件仕様

参加者を特定し、要件を結合し、ユースケースの説明を洗練し、概念的なクラスを定義し、クラス間の関係を決定し、追加することによってユースケースを取得します。

責任の追加や相互作用図の作成などの手順で要件定義が完了し、現実世界にあるものをオブジェクト指向のクラスに抽象化するとともに、システムの主な機能と範囲を決定します。これらの要件が集約されてソフトウェア要件仕様の要件部分を形成する場合に限り、ソフトウェア要件仕様を作成するための基礎となります。

要件分析段階で得られる結果として、ソフトウェア要件仕様はシステム設計とシステム開発にとって重要な指針となります。

範囲、参照文書、要件、資格規定、要件のトレーサビリティ、未解決の問題、メモ、付録、およびその他の関連コンテンツなど、その具体的な構成要素については、ここでは説明しません。興味があれば、学生は本書の関連する章を参照してください。国家標準

国家規格|GB/T 8567-2006

ソフトウェア開発の標準プロセス（ライフサイクル）を詳しく解説：標準に従って安心して設計

1. ソフトウェア開発ライフサイクルの概要