データベース
第 12 回 RDB の実際 (2)
鈴木幸市
今日の内容
なぜ工程管理が必要か
システムの企画から運転開始までの工程
全体像
基本設計
方式設計
ハードウェアの選定
機能設計
機能の記述
インタフェースの記述
画面設計
データベース論理設計
詳細設計
アプリケーションのロジックと詳細なインタフェース設計
データベース物理設計
製造
アプリケーション、 SQL のコーディング
単体試験
結合試験
総合試験
総合運転試験
なぜ工程管理が必要か
多くのプログラムからできているシステムの場合
多くの約束事が必要
プログラム間のインタフェースの規約
なぜそのように決めたのか
データベース設計を行った際の業務分析
業務の機能要件
性能要件
後の始末も大事： 設計情報、試験情報を残す
ソフトウェアは後で手直しがある
10 年も同じプログラムでは動けない
業務要件、法律・規制の変更、会計規則の変更
ハードウェアの寿命
手直しするには元の設計情報が必須
ソースコードにすべて書けるわけではない
手直し後の試験項目の再利用
試験項目設計も工数（期間、お金）がかかる
基本設計から運転開始までの概要
ウォーターフォール 型と呼ばれる形態
各工程の終わりには 必ずレビュを行って 次の工程に進めるこ とを確認する
ハードウェアの調達 には時間がかかる 後になってスペック不
足にならないように ハードウェア導入
比較的大規模な開発 に向いている
基本設計
基本設計のゴール
基本的な処理方式を決定
ハードウェアプラットフォーム
サーバ
ストレージ
ルータなどのネットワーク機器
基本ソフトウェア
OS
DBMS
その他ミドルウェア
ネットワーク
プロトコル
セキュリティ
認証方式
信頼性・可用性の実現方式
高信頼クラスタ構成
遠隔バックアップサーバの設置
アプリケーションの大まかな要件
大まかなアプリケーションの構造
どんなモジュール（プログラムの集まり）を作るか
モジュール間のインタフェース
使用言語
性能・品質要件
性能はどのくらい出ればいいか
どのくらいのバグをどこで検出するか
開発規模の見積もり
必要なマンパワー
基本設計書
ユーザ ( お客様 ) を交 えてレビュー
合格したら機能設計に ハードウェアの手配
（実際には前倒しすることも多い）
機能設計
機能設計のゴール
システムの外観を決める
画面構成
画面の遷移ソフトウェアの構成
どのようなモジュールがあるのか
各モジュールの機能の記述
なにができなければならないか
具体的な処理ロジック
使うアルゴリズムなども規定するこ ともある
エラー処理
モジュール間のインタフェース
呼び出し形式
プロトコル（ネットワークの場合）
データベース設計
論理設計とインデックス設計までは
行っておく
機能設計書
ユーザ ( お客様 ) を交 えてレビュー
合格したら機能設 計に
機能設計を進めるで
まずは詳細なスケジュールを決める
どんな順序で何を設計していくか
いつまでやるのか
誰がやるか
設計者の間での情報共有
定期的なミーティングや情報交換
インタフェース条件などでの誤解がないように
問題がないかを常に監視
なるべく早いうちに解決
後回しにすると解決が難しくなる
遅れが生じるのが一番問題
追加で体制増強してもうまくいかないケースが 多い
新人には勉強が必要
かえって遅れが広がることも
機能を削減する、代替手段を考えるなど
問題と対応策が見 つかったらこの後 の開発で再発防止
詳細設計
詳細設計のゴール
実装方式の詳細を決める
ルーチン、関数単位での処理
ロジック
ルーチン・関数の呼び出し方
式
引数、戻り値
副作用
SQL 設計
製造工程で行うこともあるが、
早めにやっておいたほうが後が
楽
詳細設計書
レビュー
合格したら製造工 程に
詳細設計と製造を平行して行う場合もある
詳細設計を行うにあたって
まずは詳細なスケジュールを決める
どんな順序で何を設計していくか
いつまでやるのか
誰がやるか
設計者の間での情報共有
定期的なミーティングや情報交換
インタフェース条件などでの誤解がないように
問題がないかを常に監視
遅れが生じないように
機能設計と異なり、応援が効果があることが多 い
なるべく早いうちに解決
原因を突き止めて解決
他の部分にも適用を図る
後回しにすると解決が難しくなる
問題と対策が見 つかったら後の 開発で再発防止
レビューが必要な理由
誤りの早期訂正
モジュール間のインタフェースなど不整合の防
止
ユーザを交えた要件の確認
誤りは最初に見つけておく
後になるほど訂正・改善が高くつく
レビューの結果 は品質の指標に
使える
製造
製造
ひたすら書く
構文ミスのないプログラムを作る
スケジュールを前もって作って
おいて遅れや進み具合を監視
遅れの原因も究明しておく
詳細設計での設計漏れ
新たな技術的な問題点が見つかっ
た
他の部分にも問題解決を適用する
情報共有
問題解決と情報共有が鍵
製造工程はシステム作り全体の
ほんの一部
問題と対策が見つ かったら後の開発で
再発防止
単体試験
単体試験
関数単位での機能試験
詳細設計書に書いたことが実装されているか
データベースや他の関数は擬似環境を作って試験
まず試験項目を書いてから
どの機能を
どのようにして試験するのか
その結果はどう予想されるか
不具合（バグ）の検出目標（基本設計）
各項目を試験していく
必ず記録を残す
いつ試験を行ったか
不具合は見つかったか
不具合の原因
不具合を見つけるべき工程
不具合の修正方法
いつ試験を完了したか
全体のスケジュールを作って進み具合を監視
送れそうなら、進んでいるところから人員をまわす など
最後に不具合の出方を見て品質を判断し、結合試験 へ
単体試験設計書
単体試験項目表
試験実施はこのレ ビューが終わってから
品質判定会議
結合試験
結合試験
プログラムモジュールに組み上
げて試験を行う
単体試験と要領は同じ
データベースの構築をここで行
うケースもある
ほとんどのバグはこの時点で発
見して修正する必要がある
この工程での遅れがよく見られ
る
単体試験が不十分
機能設計のバグ（インタフェース
設計ミス、データベース設計ミ
ス）がここで検出される
等々、、、、
結合試験設計書
結合試験項目表
品質判定会議
試験項目の見直し 試験実施の効率向上策 一部機能の設計・コー
ドレビュの実施
手戻りは避けたいが、デス マーチはもっと避けたい
総合試験
総合試験
本番環境ですべての部品を組み上げて試験
ハードウェア、 OS 、データベースその他のミド ルウェアのインストール
データベースの構築
テーブル、インデックス等の枠組み
試験データの投入
開発担当者が行う最後の試験
本番の運転条件で試験する
バックアップなどの運用機能の試験もここで行う
性能確認、故障対応の機能などもここで試験する
データベースチューニングもこの工程で
試験項目表の作成、進捗管理、品質管理、及び最終 的な品質確認のやり方は単体試験・結合試験と同様
ここで重大なバグが出るようでは困る
他に同様な問題はないか、レビューを行ったり、 総合的な対策を立案したりする必要がある
総合試験設計書
総合試験項目表
試験実施はこのレ ビューが終わってから
品質判定会議
総合運転試験
祝！ 運転開始
祝！ 運転開始
総合運転試験
ユーザが行う試験
ユーザの訓練を兼ねることもある
最終的な長期間の連続運転試験はこの工程
で行う
ユーザにシステムを引き渡すための最後の
工程
システム作りとデータベース (1)
システム作りの要点
計画（段取り）
仕事と仕事の間の関連の整理
何が終わったら何が始まるのかがわかる
どこかでうまくいかなくなったらどのような影響があるかがわかる
スケジュール、担当する人、投入する資材（コンピュータやネットワー クなど）を決める
管理
うまくいっていないところはないか
問題点はないか
問題解決
知恵を出すところ
早い時点で問題解決した方が時間の短縮
問題を先送りするとだんだん解決が難しくなる
新・ソフトウェア開発の神話 成功するプロジェクトチームの科学と文化
システム作りとデータベース (2)
データベースの設計、構築、チューニングは、開発の初期工程と後期工 程でしっかりやる必要がある
システムの性能はデータベースが左右することが多い
影響が大きそうな部分はあらかじめベンチマークを実施するなどし て総合試験以降への影響が出ないよう配慮が必要
管理と監視が非常に重要
スケジュール通りに運んでいるか
問題はないか
あったらできる限り早期に解決
他の部分にも同じ問題がないかを調べ、解決方法を展開
試験工程が長い、人手もかかる
品質管理を考えること
どのくらいバグが予測されるか
実際どのくらい見つかったのか
試験工程を完了しても問題ないのか
問題や品質情報は次回以降の開発に応用していく
これがシステム作りのノウハウになる
