いままで、
・要件から、クラス図までに落とし込む流れ
・MVCで要件→モデルのクラス図から、コントローラーに落とし込む
・MVCで要件→画面に落とし込むまで
とまとめてきたので、それから先のプログラミングやテストまでも含めて、全部
一気に開発の最初から最後まで、書いてみました。
■要件から要求仕様まで
（１）要件の動詞部分に着目し、抜き出す
（２）動詞の主語、目的語を取り出し、
「何々が、何々を、なんとかする」という単文の形にする
→もし～ならば、「何々が、何々を、なんとかする」と、
条件がつく場合もある
（３）データ分析（クラス図の属性部分）
・（２）の名詞、目的語は、「モノ」なので、これをエンティティとする
・使っている帳票などを、
・第一正規形
・第二正規形（トップダウン方式、エンティティは上記クラス）
・第三正規形
まで行い、ER関係を明確にする（ER図、クラス図の属性作成など）
（４）機能要件の抽出（クラス図のメソッド部分）
・（２）の動詞部分に着目し、現状のアクティビティ図を作成する
・アクティビティをコンピューター化するとどうなるか考える
・開発システムのアクティビティ図に書き換える
・アクティビティ図のアクティビティをユースケースとして
ユースケース図に書き換える（やらなくても可）
・（２）の名詞、つまり、主語か、目的語のクラスのメソッドに、
開発システムのアクティビティ図のアクティビティを埋める
（５）アクティビティの引数を（２）の要件から確認し、
（動詞＝アクティビティ、名詞等は引数、返り値は目的とする結果）
アクティビティと引数から、ユースケースシナリオを作成する
（必要があれば）
（６）性能などの非機能要件をまとめる。
■外部設計－機能要件分析
（７）モデル部分のクラス図を作成する
・（３）でER図を作成していた場合、エンティティをクラスとすると、
クラスと属性が埋まる
（クラス図を作っている場合も、ここまで埋まっている）
・そのクラスに対して、（４）、（５）の操作で抽出したメソッドを
適当に割り振って入れる
割り振り方は、メソッドに対応する（２）の要件の、主語または目的語
に対応するクラスに、入れる。
（８）フレームワークに何を採用するか決定する
・サーブレット、struts等
（９）（７）のモデルのメソッドを以下のように用途別に分類する
・ユーザーが能動的に動かすもの
画面を使ってアクションを起こす
画面以外を使ってアクションを起こす
・ユーザーが意識しないけど動くもの
自動的に条件がそろうと動く
他アクションから呼び出し、直後に自動的に実行
（１０）フレームワークを元に、（９）のモデルに対応する（呼び出す）
コントローラーを決める
・画面の場合、サーブレットを利用するなら、モデルの１メソッド
１サーブレットクラスになる
（strutsでも１メソッド１アクションクラス）
■外部設計－外部入出力（画面）
（１１）画面割りをきめる
・比較的自由に決められるが、こういう決め方もある
（２）の要件は、
主語（＝人）、目的語（＝対象物）、動詞（アクティビティ）
の形なので、
・まず、主語を確定する
＝＞ログイン画面で、操作している人を決定
＝＞この人が主語
・目的語の画面を作成する
このとき、目的語が、複数あり、検索が必要な場合は、
（検索）一覧画面（検索は画面をわけることもある）
詳細画面
検索が必要ない場合は、
詳細画面
・１クラスに対し、CRUD(作成、（一覧）検索、更新、削除）は、
かならず必要なので、もし、メソッドがなければ補う
（１２）画面に、（１０）で決めたコントローラーを割り振る。
画面でイベントが起きたら、そのイベントが（１０）のコントローラー
を呼び出すことになるので、何らかの画面イベントにより、（１０）の
コントローラーがすべて呼び出されないとまずい。
多くは、画面にボタンをつけて、そこから呼び出されるようにする
たいていの場合、以下のようにボタン割をするとうまくいく。
・検索入力箇所（独立の画面または一覧画面と共有）：検索実行
・一覧画面：新規入力（追加）、編集、削除
・詳細画面：新規入力や編集の登録、キャンセル
承認、承認拒否などの場合、一覧画面につけることも、詳細につける
ことも考えられる。
編集は、一覧の該当レコードのダブルクリックというケースもある。
（１３）画面遷移図をまとめる
呼び出されたコントローラーが、どの画面を表示するかを確認し、
画面を遷移させる。遷移しない画面が出たら、ボタンを付けて遷移
させる
（１４）画面詳細をきめる
モデルの引数は、すべて呼び出しコントロールあるいは、それ以前の
画面において入力されていないといけない。
それらをみたすように、画面項目をおいていき、値の範囲を決めて、
画面詳細設計書にまとめる。
（１５）画面定義書の作成
（１３）、（１４）をまとめると、画面定義が出来る
■外部設計－外部入出力（DB）
（１６）DB定義書をまとめる
（３）のER図を書き換えると、DB定義書が出来る
■外部設計－機能要件分析 PART2（まとめ）
（１７）MVCにしたがい、各クラスを定義する
Mについては、（７）、
Vについては、（１５）で画面が決まっている
→画面から必要なクラスはフレームワークで決まる
Cについては、（１０）でクラスが決まっている
ので、その各クラスについて、内容を定義する。
内容は、以下のとおりになる
・M（モデル部分）
コントローラーからの値をうけとり、基本的な処理をする
DBアクセスを行う
帳票、ファイル等外部入出力の操作もある。
・V（ビュー：画面部分）
イベントにおけるチェックなどの処理と、
コントローラーの呼び出し
・C（コントローラー部分）
引数を受け取り（処理することあり）、
モデルを呼び出し、
モデルから受け取った値を次の画面用に編集、セットする
次の画面を呼び出したり、書き出したりする
■内部詳細設計・プログラミング
（１８）（１７）できめたMVCの定義をもとに、
プログラム化していく
DBアクセスはJDBC
サーブレットにおける値の操作は、session操作、getParam,getWriter等
など、大体決まっているので（もしくはプロジェクトで決めているので）
それにしたがって、プログラムに落とし込む
■単体テスト
（１９）テスト仕様書の作成
仕様上にでている条件を、
IF文ならば、その条件を満たす場合と満たさない場合で
switch文なら挙げられているケースで
組み合わせを考え、同値条件を決める
→ある条件が成立すると、自動的に他のじょうけんが成立する場合ははずす
それと、境界値も考え、テストケースを仕様書に記入する
（２０）テストデータの作成
テスト仕様書にそって、テストデータが必要なら作成する
（２１）テストに必要なプログラムを用意する
テストプログラムは単体で動かない場合、
テストプログラムを呼び出すプログラムがドライバ、
テストプログラムから呼び出されるプログラムがスタブ、
これら、スタブ、ドライバを必要なら作成する
→ドライバとしてJUnitを使うと、きれいにテストできる
（２２）テスト実施
テストを実施する。
テスト仕様書にそって行い、エビデンスをとる。
このとき、OKなら報告書にOKとする
（２３）（NGの場合）バグ票の記入
もし、テストがNGだったら、バグ票に記入して、
プロジェクトで決まっている人に渡す
（２４）（NGの場合）修正
バグの担当者がバグ票を受け取り、修正
（２５）（NGの場合）修正確認
バグ票を発行した人が、（２４）の修正した旨のバグ票をもらったら、
バグが直っているかどうか確認し、確認したら、テストOKとして、
（２６）へ、NGなら、再度修正（２４）へ、
（２６）リグレッションテスト（回帰テスト）
修正の際、新たなバグを入れている（デグレード）可能性もあるので、
もう一度、バグの箇所以外もテストしなおすことがある。
これをリグレッションテストという。
■結合テスト
（２７）テスト仕様書の作成
・画面設計書などにでてくる入力（入出力）項目に対し、
指定された範囲の境界値のテスト、
字種等のテスト、
SQLインジェクション、エスケープ文字、0、スペース、
入力しないケースなどの項目を挙げる
・入力項目の組み合わせを行なう
・要件を満たす場合についてのチェックを行う
それ以降は、（２０）～（２６）と同様である
■総合テスト
（２８）テスト仕様書の作成
・要件仕様に書かれた、機能要件（業務）（１）にそって
その条件を満たしているかテスト項目をあげ、仕様書に記述する
・要件仕様に書かれた、非機能要件（性能など）（６）に関して、
その条件を満たしているかテスト項目をあげ、仕様書に記述する
それ以降は、（２０）～（２６）と同様である
■運用
（２９）オペレーションマニュアルの作成
・要件仕様書の業務内容（１）にそって、業務手順を記述する
（３０）データ作成
・運用するためのデータを作成する
既存のシステムからの移行の場合、データクレンジングを行ってから、
新規システムへのデータ移行をする場合もある
（３１）移行手順・導入手順等の作成
移行の場合、どのように移行をおこなうかの手順を作成する
新規システムの場合、いつ、どのマシンを搬入し、どのソフトを入れるか計画
する。
（３２）納品（搬入）
納品書を作成し、納品する。あるいはシステムを搬入する
（３３）運用
（３１）の導入手順、移行手順に従い、実行し、
（２９）のオペレーションマニュアルに従い運用する。
以上っす。
アクセス
トータル
ランキング
