登場人物
名前： スーさん。(SUさん)
仕事： 神戸のソフトウェア会社W社でSEをやっている
最近の心配事：テレビアニメ版「東京喰種トーキョーグール」のキャラクターが、マンガのイメージと違って困惑している事。実は、原作厨なんです。
名前： ター坊
仕事： 無職。仕事を探している。
最近の心配事：血糖値が上がっていて糖尿病が心配。大好きなパンケーキを食べられない事。
ある日のこと。。。。
理解が早いね。
あ、ちがった。石灰か？
雪渓（せっけい）とは、高山など標高の高い場所の谷や沢の積雪が溶けずに残った地帯。または積雪で覆われた渓谷。
(出典: https://ja.wikipedia.org/wiki/雪渓)
システム開発ライフサイクルにおけるウォーターフォールモデルにおいて、要件定義後のフェーズを設計フェーズと呼びます。
システム設計とも呼ばれることがあります。
システム開発ライフサイクルについては、以下で説明しました。
システム開発ライフサイクルを思い出してみましょう。
設計フェーズは、要件定義とシステム開発の間のフェーズであり、さらに細かく基本設計と詳細設計に分かれます。
基本設計と詳細設計の違い
基本設計は大雑把な設計、詳細設計は細かい設計だと思っている人がいますが、それは誤りです。
両者の違いは次の通りです。
- 基本設計は、システムを外から見たときどういう動きをするか（＝外部設計、What）を決めるもの。
- 詳細設計は基本設計で決められた動きを、どうやって実現するか（＝内部設計、How）を決めるもの。
仕様書と設計書の違い
もう一つ、仕様書と設計書の違いも勘違いする人が多いようです。
両者の違いは次の通りです。
- 仕様書は 、「何を作るのか？」を説明した資料
- 設計書は 、「どうやって作るの？」を説明した資料
更に詳しくは、
仕様書には「結果」が書かれており、設計書には「過程」が書かれています。
仕様書は、それを見ても作れませんが、設計書は、それを見れば作れます。
仕様書は、技術的なことを知らなくても作れますが、設計書は、技術的なことを知らないと作れません。
システム開発ライフサイクルにおけるフェーズに当てはめてみると、要件定義フェーズや基本設計フェーズで、お客さまと一緒になって作り上げるのが仕様書です。
詳細設計フェーズで作るのが設計書です。
※ただし、便宜上、要件定義フェーズでの成果物を要件定義書、基本設計フェーズでの成果物を基本設計書と呼びます。そして、詳細設計フェーズでの成果物を詳細設計書と呼びます。
それでは、基本設計を細かく見てみましょう。
基本設計 (Basic Design） または外部設計 (External Design)とは？
ソフトウェア開発における基本設計の目的、最終成果物は、お客様が理解できる設計書を作成することです。
基本設計の前工程である要件定義と基本設計は、お客様のニーズ、操作、画面、帳票などお客様の業務と密接に関連するために、通常はSEとお客さんが一体となって作業を行います。
もちろん、基本設計の最終成果物を作成するのは、システム開発を請け負ったSEです。
この工程では、要件定義でまとめたお客様の要件を、システム的に落とし込みます。
つまり、基本仕様書のインプットは要件定義書になります。
基本設計では、操作画面や操作方法、データ出力など、ユーザーから見えるインターフェース部分の仕様を決定し、セキュリティや運用規定、システム開発のスケジュールや費用などを検討し、ユーザーに向けた仕様を設計します。
具体的には、画面イメージや、アウトプットとなる帳票やデータのイメージ、システムの処理フローなど、画像やイメージ図など、ユーザーが理解できるものを使い、お客様にも理解しやすい設計書を作成します。
外部システムとの仕様調整を行うために、外部設計と呼ばれることもあります。
基本設計の目次、書き方、成果物、サンプル、例
基本設計書は、マイクロソフトエクセル (MS Excel)で作る場合が多いようです。
ただ、見やすいものであればよくて、エクセル にこだわる必要はありません。
また、テンプレートなどを見かけますが、分かりやすいもの、漏れがないものであればよく、あまり汎用的なテンプレートにこだわる必要もありません。
基本設計書は、以下のものを含むようにします。
| No | ドキュメント名 | 含まれる内容 |
|---|---|---|
| 1 | 業務フロー | 業務の流れを理解し機能を洗い出す |
| 2 | 機能一覧表 | 開発範囲となる機能の一覧 |
| 3 | ネットワーク構成図 | ネットワークの構成 |
| 4 | テーブル定義 | データベースのテーブルの定義 |
| 5 | ER図 | データベースのER図の作成 |
| 6 | 画面遷移図 | 画面遷移を図で示す |
| 7 | 画面レイアウト | 画面イメージ |
| 8 | 帳票レイアウト | 帳票イメージ |
業務ごとに含まれる内容は異なります。
帳票のような印刷するものがないプロジェクトであれば、帳票のレイアウトは不要です。
データベースに関しては論理設計だけ、基本設計で行います。
基本設計フェーズでの成果物としては、基本設計書としてまとめることが多いようです。
詳細設計 (Specific Design) または内部設計 (External Design) とは？
ソフトウェア開発における詳細設計の目的、最終成果物は、プログラマーが理解できる設計書を作成することです。
前工程である基本設計と異なり、詳細設計は通常はお客様が理解できないシステムの内部の動作、機能、データベースの設計などをデザインする工程であり、システム開発を請け負ったSEが行います。
通常は、お客様は参加しません。(もちろん、参加しても構いません。)
詳細設計のインプットは基本設計書です。
詳細設計では、システム開発における、基本設計を元にして、実際にプログラムが作れるまで細かく作業を落とし込む工程とも言えます。
この工程では「お客様に見えないところ」を考える作業で、プログラムの構造やデータの流れなどの細かい部分まで、仕様書として落とし込みます。
詳細設計は、内部設計と呼ばれることもあります。
詳細設計の目次、書き方、成果物、サンプル、例
詳細設計書も、マイクロソフトエクセル (MS Excel)で作る場合が多いようです。
詳細設計書は、以下のものを含むようにします。
| No | ドキュメント名 | 含まれる内容 |
|---|---|---|
| 1 | 機能設計書 | 機能ごとに処理を記述する フローチャートを記述する 画面の詳細項目の説明 帳票の詳細項目の説明 |
| 2 | データベースの定義書 | データベースの物理設計書 |
もちろん、詳細設計書も、基本設計書と同様に業務ごとに含まれる内容は異なります。
大事なことは、開発者がプログラムを書く上で困らない情報、迷ったりわからなくなったりしないように、漏れなく情報を書かなければなりません。
テンプレートやサンプルなどもよくありますが、それ以上に、「これでプログラムが書けるか？」ということに主眼をおいて書くようにしてみることが大切です。
詳細設計フェーズでの成果物は、詳細設計書としてまとめることが多いようです。
まとめ
設計フェーズは、要件定義フェーズ、開発フェーズの間の大事なフェーズになります。
要件定義でまとめたお客様要件を、抜け漏れなく設計する必要があります。
また、開発メンバーが齟齬なく開発できるように詳細設計書を作成する必要があります。
よく成果物の体裁を気にして、テンプレートとかを探してテンプレ通りに書こうとする人がいますが、あまり得策とは言えません。
と言うのも、プロジェクトごとに必要なものが異なるのは当然のことで、テンプレで必要なものが足りなかったり、あるいはテンプレにあってもプロジェクトでは不要なものもあるからです。
大切なことは、要件定義で定義されたことがすべて網羅されており、成果物である設計書の通りプログラムを書いて問題なく動作するなど、論理的に考えていくことです。
極端なことを言えば、分かりやすいものであれば、どのようなフォーマットであっても構いません。
設計フェーズは、要件定義よりもシステム的になり、よりエンジニアとしてのスキルが必要になります。
設計フェーズも、要件定義と同様にとても大事なフェーズですね。
赤経（せきけい/せっけい、right ascension）は、天体の位置を表す値。RA、αと略して表記される。通常、赤緯と合わせて使われる。
まず、天の北極、天の南極、天の赤道を決める（赤緯の項目を参照）。恒星の赤経・赤緯は変わらないが、太陽や他の惑星などは、天球上で位置を変えるため、赤緯の値も変わる。
太陽は、地球の北半球では夏の間は天の赤道よりも北に位置し、赤緯は+の値になる。冬の間、太陽は天の赤道よりも南に位置し、赤緯は-の値となる。そしてちょうど春分の日と秋分の日に、太陽の赤緯は0になる。
どうやら、ター坊はパソコン教室からスタートしないといけないようです。
この続きは、コチラです。