1. 開発方法
1.1 開発スタイルによる
- トップアップ: 大きな問題を小さな問題に分割し、一つずつ解決する
- ボトムダウン: 具体的なコンポーネントから開始し、デザイナーのスキルをつなぎ合わせて相互接続、変更、拡張します。
1.2. 性質による
- 形式化: クリーン ルーム エンジニアリングを表すデータ推論方法 (通常はテストされていません)
- 非公式化: さまざまな開発モデル
1.3 適用範囲
- 総合的なアプローチ: ソフトウェア開発のプロセス全体に対するアプローチ
- ローカルアプローチ: ソフトウェアの特定のフェーズへのアプローチ
ps: クリーン ルーム エンジニアリング (CSE)
- ボックス構造仕様を使用した分析ボックスモデリング
- 誤りを排除するための正当性検証
- 統計誤差
- 品質管理
2.非公式開発手法
2.1. プロトタイプ手法
機能点の実現に従って:
- 水平プロトタイプ: 動作プロトタイプ。インターフェースの要件を絞り込むために使用されますが、機能は実現されません。
- 垂直プロトタイプ: 複雑なアルゴリズムの実現を考慮して、いくつかの機能を実現した構造化プロトタイプ
最終結果によると:
- 使い捨て: 探索的なプロトタイプ、需要の不確実性、あいまいさ、不完全性、あいまいさを解決する
- 進化的: アップグレードと最適化が容易な状況に合わせて、最終システムに徐々に進化します。
2.2. 構造化された開発
利点: 明確な開発目標、段階的な開発プロジェクト、標準化された開発文書、構造化された設計文書
短所: 開発サイクルが長く、要件の変化に適応するのが難しく、データ構造がほとんど考慮されない
2.3. アジャイル開発手法
人間指向、ユーザーとの緊密なコラボレーション、対面でのコミュニケーション、できるだけ早いリリース増分、小規模で独立した開発チーム、小規模プロジェクトに適しています。
2.4. オブジェクト指向開発
Coad/Yourdon 法: OOA と OOD はまったく同じ概念と表記法を採用しており、期間分析と設計の間で表記法を変換する必要はありません。
Booch 法: 静的モデルは、論理モデル、物理モデルに分けられるシステムの構成と構造を記述します。動的モデルは、状態図やシーケンス図を含む、オブジェクトの状態変化と相互作用プロセスを記述します。
OMT手法：モデリングの考え方を利用し、オブジェクトモデル（オブジェクト図）、動的モデル（状態図）、関数モデル（DFD）を使用
OOSE メソッド: 要件分析と機能モデリングのために DFD を置き換えるユースケース
2.5. サービス指向の開発手法
抽象化のレベル
- 操作: トランザクションの単一の論理単位を表す最下層には、特定の構造化インターフェイスが含まれ、構造化応答を返します。
- サービス: 操作の論理グループを表します。
- ビジネス プロセス: 最も高いレベルで、特定のビジネス目標を達成するために実行される長期にわたる一連のアクションまたはアクティビティ
2.6. コンポーネント指向のソフトウェア開発
コンポーネントの取得:
- 既存のコンポーネントを使用します。
- レガシーエンジニアリングアーティファクトを抽出する
- 買う
- 開発する
コンポーネントの再利用方法:
- コンポーネントの取得と抽出
- コンポーネントの理解と評価
- コンポーネントを変更する
- コンポーネントのアセンブリ
カテゴリを作成します。
- キーワード分類: アプリケーションの概念をツリーまたは有向非巡回グラフ構造に分割し、キーワードで表します。
- ファセット分類: ファセットを使用して、コンポーネントによって実行される機能、操作されるデータ、コンポーネントが適用されるコンテキスト、またはその他の特性を記述します。
- ハイパーテキスト方式: 人間の連想思考に従って、関連する概念やコンポーネントを含むドキュメントに任意にジャンプできます。
3. 開発モデル
ウォーターフォール モデル: 構造化されたアプローチ、段階的な開発、明確な要件、完全な文書化、弱いリスク管理
プロトタイプモデル：反復手法、オリジナル開発とターゲットソフトウェア開発に分かれており、要件が明確ではない
スパイラル モデル: ベルト法、ウォーターフォール、プロトタイプ開発モデルを組み合わせたもので、大規模で複雑でリスクの高いプロジェクトに適しています。
ファウンテン モデル: オブジェクト指向の手法、優れた再利用、開発プロセスにギャップがなく、スペースを節約します。
V モデル: 開発とテストの組み合わせ
変換モデル: 正式な開発に適しています
迅速なアプリケーション開発 RAD: コンポーネントベースの開発手法、ユーザー参加、コンポーネントの開発または再利用、高度なモジュール要件、新しいテクノロジには適さない
RUP/UP: ユースケース主導、アーキテクチャ中心、反復的、増分的。
4. システム分析
4.1. 構造解析
- 機能モデル: DFD データ フロー図、データ フローは外部エンティティからストレージに直接流れることはできず、処理には入力と出力が必要です
- データモデル: ER図
- 動作モデル: STD 状態遷移図
4.2. オブジェクト指向分析:
- 機能モデル: ユース ケース図。ユース ケース間には包含、拡張、一般化を含む 3 つの関係があります。コンポーネント ユース ケース モデルは通常、参加者の特定、ユース ケースを取得するための要件の結合、使用の調整の 4 つの段階で管理する必要があります。ケースの説明、ユースケースモデルの調整、これらの段階のうち 3 つが必要です。
- データモデル: クラス図
- 動作モデル: アクティビティ図、シーケンス図、状態図
オブジェクト指向分析コンポーネントを通じてモデルを分析するプロセス: 分析モデルを確立するプロセスには、通常、概念の定義、クラス間の関係 (依存、一般化、結合、集約、実現) の決定、クラスへの責任の追加、相互作用の確立が含まれます。図など
5. システム設計
5.1. 構造設計:
- 概要設計：アーキテクチャ設計、インターフェース設計、データ設計を含む、SCシステム構成図を使用
- 詳細設計: プロセス設計、プログラム フローチャート、IPO 図、ボックス図、問題分析図、デシジョン ツリー、およびデシジョン テーブルを含みます。
5.2 オブジェクト指向設計
アーキテクチャ図（パッケージ図）、ユースケース実現図、クラス図、その他（状態、アクティビティ図）