ソフトウェア工学シリーズ記事その2
ソフトウェアのライフサイクル
- 実現可能性分析とプロジェクト開発計画
- 要件分析
- 概要設計
- 詳細設計
- コーディング
- テスト
- 保守
ソフトウェア要件
要件をヒアリングする前に、まず「何をヒアリングする必要があるのか」、つまり「要件にどんな内容が含まれるのか」を明確にしとこうね。ソフトウェア要件っていうのは、ユーザーが目標とするソフトウェアシステムに対して機能、振る舞い、性能、設計上の制約なんかに関して期待してることだよ。
- 機能要件。システムが何をすべきか、いつ行うか、いつ、どのように修正またはアップグレードするかを考えるよ。
- 性能要件。ソフトウェア開発における技術的な指標を考えるんだ。例えば、記憶容量の制限、実行速度、応答時間、スループットなんかだね。
- ユーザーまたは人的要因。ユーザーのタイプを考えるよ。例えば、様々なユーザーのコンピューター使用の習熟度、必要なトレーニング、システムの理解・使用の難しさ、ユーザーによるシステム誤操作の可能性なんかがこれに当たるね。
- 環境要件。将来のソフトウェアが使われる環境、つまりハードウェアとソフトウェアの両方を考えるよ。ハードウェアデバイスへの要件としては、機種、周辺機器、インターフェース、場所、配置、湿度、磁場干渉なんかがある。ソフトウェアへの要件は、OS、ネットワーク、データベースなんかがそうだね。
- インターフェース要件。他のシステムからの入力、他のシステムへの出力、データ形式に関する特別な規定、データ記憶媒体に関する規定を考えるよ。
- ドキュメント要件。どんなドキュメントが必要で、どの読者を対象にするかを考えるんだ。
- データ要件。入出力データの形式、データの送受信頻度、データの正確性と精度、データトラフィック、データを保持する必要がある期間なんかを考えるんだ。
- リソース使用要件。ソフトウェア実行時に必要となるデータ、他のソフトウェア、メモリ空間なんかのリソース。それに、ソフトウェア開発・保守に必要な人材、サポートソフトウェア、開発設備なんかも考慮するよ。
- セキュリティ・機密保持要件。システムやシステム情報へのアクセスを制御する必要があるか、ユーザーデータを隔離する方法、ユーザープログラムが他のプログラムやOSからどのように隔離されるか、システムバックアップ要件なんかを考えるんだ。
- 信頼性要件。システムの信頼性要件を考えるよ。システムがエラーを検出・隔離する必要があるか、エラー発生後にシステムを再起動するまでの許容時間なんかもそうだね。
- ソフトウェアコストと開発進捗要件。開発に定められたスケジュールがあるか、ソフトウェア/ハードウェア投資に制限があるかなどを考えるよ。
- その他の非機能要件。例えば、特定の開発モデルの採用、品質管理基準、マイルストーンとレビュー、受け入れ基準、様々な品質要件の優先順位の決定、保守性に関する要件なんかがこれに当たるね。
システム設計
システム設計の主な目的は、システムの青写真を描くことなんだ。様々な技術や実装方法のメリット・デメリットを比較検討し、慎重に設計して、様々なリソースを合理的に使いながら、最終的に新しいシステムの詳細な設計案を練り上げていくんだよ。
概要設計
開発者は、確定した各機能要件を必要なアーキテクチャに変換するんだ。
1. ソフトウェアシステム全体構造の設計
その基本的な任務は、ある設計手法を使って、複雑なシステムを機能ごとにモジュールに分割することだよ。各モジュールの機能を決めたり、モジュール間の呼び出し関係、モジュール間のインターフェース（つまりモジュール間でやり取りされる情報）を決めたり、モジュール構造の品質を評価したりするんだ。
ソフトウェアシステム全体構造の設計は、概要設計における重要なステップで、次の詳細設計やコーディング作業に直接影響するんだ。ソフトウェアシステムの品質や全体的な特性は、この全体構造の設計段階で決まるんだよ。
2. データ構造とデータベース設計
(1) データ構造の設計
データ構造の設計にも、段階的に詳細化していく方法が当てはまるんだ。要件分析の段階で、データ辞書を使ってデータの構成、操作制約、データ間の関係なんかを記述して、データ構造の特性を確定したよね。概要設計段階ではそれをさらに詳細化し、詳細設計段階で具体的な実装の詳細を規定するんだ。概要設計段階では、抽象データ型を使うのがおすすめだよ。
(2) データベースの設計
データベースの設計っていうのは、データ記憶ファイルのデザインのことで、主に次の側面の設計を行うよ。
- 概念設計。データ分析に基づいて、ボトムアップ方式でユーザー視点からビュー設計を行うんだ。一般的にはE-Rモデルを使ってデータモデルを表現するよ。E-Rモデルはデータベース設計の基礎であると同時に、データ構造設計の基礎でもあるんだ。
- 論理設計。E-Rモデルはデータベース管理システム（DBMS）とは独立してるから、具体的なDBMSの特性に合わせてデータベースの論理構造を構築する必要があるんだ。
- 物理設計。異なるDBMSでは、物理環境が異なり、提供されるストレージ構造やアクセス方法もそれぞれ違うんだ。物理設計っていうのは、データ項目の記憶要件、アクセス方法、インデックスの作成なんかといったデータモデルの物理的な詳細を設計することだよ。
3. 概要設計ドキュメントの作成
ドキュメントには主に、概要設計説明書、データベース設計説明書、ユーザーマニュアル、そして改訂版テスト計画があるよ。
4. レビュー
設計部分が要件で規定された機能、性能なんかを完全に実現しているか、設計方法の実現可能性、重要な処理や内外インターフェース定義の正確性、有効性、各部分間の一貫性なんかを一つ一つレビューするんだ。
詳細設計
- 各モジュールについて詳細なアルゴリズム設計を行うよ。ある種の図形、表、言語なんかを使って、各モジュールの処理過程の詳細なアルゴリズムを記述するんだ。
- モジュール内のデータ構造を設計するよ。
- データベースの物理設計を行う、つまりデータベースの物理構造を決定するんだ。
- その他の設計。ソフトウェアシステムの種類によっては、さらに以下の設計が必要になることもあるよ。
- コード設計。データの入力、分類、保存、検索などの操作を効率化し、メモリ空間を節約するために、データベース内の特定データ項目の値についてコード設計を行うんだ。
- 入出力フォーマット設計
- ユーザーインターフェース設計
- 詳細設計説明書を作成するよ。
- レビュー。処理過程のアルゴリズムとデータベースの物理構造の両方をレビューするんだ。
システム設計の結果は、一連のシステム設計ファイルだよ。これらのファイルは、情報システム（ハードウェア機器やソフトウェアプログラムの作成を含む）を物理的に実装するための重要な基礎となるんだ。