「開発プロセスサンプル」の編集履歴（バックアップ）一覧はこちら
開発プロセスサンプル - (2009/08/17 (月) 02:08:21) の最新版との変更点
追加された行は緑色になります。
削除された行は赤色になります。
このwikiのメインではないのでここは非常にシンプルに書いておきます。
&bold(){（ただいま作成中です。）}&italic(){}
**1.基本的な考え方：
レイアウト・配色・画面遷移・動作の全てについて、規約でパターン化を行い、
個別の機能でカスタマイズは不可とします。
パターンに従う事が出来ない場合は、規約改定について協議する事とします。
こうすることで、システム内の全機能の操作性・デザインの統一を図るとともに、
フレームワークによる開発支援を容易にし生産性・保守性の向上を図ります。
**2.画面種類
画面には大きく下記の5種類を定める。
①業務画面
⇒ユーザーが業務を行う中心となる画面。
②入力支援ダイアログ
⇒業務画面への入力を支援する画面。
（商品コードを検索して、業務画面のテキストボックスに埋めたりする画面）
③確認ダイアログ
⇒ポップアップして「はい」「いいえ」を選択させる。
④エラー通知ダイアログ
⇒ポップアップしてエラーを通知する。
⑤メッセージ通知ダイアログ
⇒ポップアップしてエラー以外の情報を通知する。
⑥ログイン画面
⇒ID、passwordを入力してログインする画面。
⑦メニュー画面
⇒このシステムの機能一覧を表示しユーザに選ばせる画面。
⑧パスワード変更画面
⇒パスワードを変更する画面。
**3.画面種類毎のデザイン
①業務画面
・画面ID、画面名、システム日付、ユーザー名をヘッダーに表示。
・フッター部分にボタン及び、メッセージ表示領域を配置。
・Window初期サイズは◎◎×◎◎。（後で決めます。今は細かく書かない）
・ユーザによるWindowサイズ変更は可能だが、
レイアウトが崩れないことは保障しない。
・アドレスバー、ブラウザメニュなどブラウザ標準機能は非表示。
・フォントXX、背景色。。。（後で決めます。今は細かく書かない）
**4.画面遷移
前提：
・メニュー画面は複数同時に起動される可能性があるものとします。
・業務画面は複数同時に起動される可能性があるものとします。
・同一の業務画面が多重起動される可能性もあるものとします。
①業務画面表示までの流れ
・通常ログインパターン
ログイン画面でログインボタンをクリック
↓
（同一ウィンドウ内で遷移）メニュー画面表示
↓
メニュー画面で機能名をクリック
↓
（別ウィンドウをポップアップ）業務画面表示
・シングルサインオンパターン
社内ポータルサイトのログインでログインボタンをクリック
↓
（同一ウィンドウ内で遷移）社内ポータルトップ画面表示
↓
社内ポータルサイトのログインでログインボタンをクリック
↓
（同一ウィンドウ内で遷移）社内ポータルトップ画面表示
②業務画面表示後の画面遷移
・参照パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
（同一ウィンドウ内で遷移）検索結果を一覧形式で初期画面に表示
↓
検索結果の１行を選択し、参照ボタンをクリック
↓
（同一ウィンドウ内で遷移）参照画面を表示
↓
参照画面で戻るボタンをクリック
↓
（同一ウィンドウ内で遷移）初期画面を表示
・新規登録パターン
初期画面で、登録ボタンをクリック
↓
（同一ウィンドウ内で遷移）登録画面を表示
↓
登録画面で確認ボタンをクリック
↓
（同一ウィンドウ内で遷移）確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
（同一ウィンドウ内で遷移）完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
（同一ウィンドウ内で遷移）初期画面を表示
※完了画面で連続登録ボタンをクリックすると、再度登録画面へ遷移
・更新パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
（同一ウィンドウ内で遷移）検索結果を一覧形式で初期画面に表示
↓
検索結果の１行を選択し、更新ボタンをクリック
↓
（同一ウィンドウ内で遷移）更新画面を表示
↓
更新画面で確認ボタンをクリック
↓
（同一ウィンドウ内で遷移）確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
（同一ウィンドウ内で遷移）完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
（同一ウィンドウ内で遷移）登録画面を表示
・削除パターン
初期画面で、検索条件を入力し検索ボタンをクリック
↓
（同一ウィンドウ内で遷移）検索結果を一覧形式で初期画面に表示
↓
検索結果の１行を選択し、削除ボタンをクリック
↓
（同一ウィンドウ内で遷移）削除画面を表示
↓
削除画面で確認ボタンをクリック
※この画面では何も編集できないが削除には慎重を期すため、
登録、更新と同じ手数にしておく。
↓
（同一ウィンドウ内で遷移）確認画面を表示
↓
確認画面で実行ボタンをクリック
↓
（同一ウィンドウ内で遷移）完了画面を表示
↓
完了画面で完了ボタンをクリック
↓
（同一ウィンドウ内で遷移）登録画面を表示
・ファイルアップロードパターン
初期画面、登録画面、変更画面では必要に応じファイルのアップロードが可能。
・ファイルダウンロードパターン
初期画面、参照画面では必要に応じファイルのダウンロードが可能。
・PDF表示／印刷指示パターン
初期画面、参照画面では必要に応じPDF表示、
特定のサーバプリンタへの印刷指示が可能。
**5.ボタン一覧
①前提
・ボタンの種類は標準で定める。これ以外のボタンは作らない。
・ボタン種類毎に標準で定めたファンクションキーを割り当てる。
・ブラウザに予約されているファンクションー動作（F5で更新等）は無効化し、システム内のボタン操作に割り当てる。
②業務画面フッターボタン一覧表
|ボタン名|動作|使用可能画面|
|F1:閉じる|業務画面を閉じる|初期画面|
|F3:再取得|DBからデータを再取得して表示|更新画面、削除画面|
|F3:クリア|入力内容をクリアする|初期画面、登録画面|
|F5:参照|参照画面に移る|初期画面|
|F6:登録|登録画面に移る|初期画面|
|F6:連続登録|登録画面に移る|完了画面（登録パターンのみ）|
|F7:更新|更新画面に移る|初期画面|
|F8:削除|削除画面に移る|初期画面|
|F9:印刷指示|印刷指示を実行|初期画面、参照画面|
|F9:PDF出力|PDF出力を実行|初期画面、参照画面|
|F9:ファイルアップロード|ファイルアップロード|初期画面、登録画面、編集画面|
|F9:ファイルダウンロード|ファイルダウンロード|初期画面、参照画面|
|F10:検索|検索を実行|初期画面|
|F11:確認|確認画面に移る|参照画面、登録画面、編集画面、削除画面|
|F11:実行|完了画面に移る|確認画面|
|F11:完了|初期画面に移る|完了画面|
|F12:戻る|1つ前の画面に戻る|参照画面、登録画面、編集画面、削除画面|
|F12:再入力|1つ前の画面に戻る|確認画面|
③業務画面フッター以外のボタン
フッター以外のボタンはファンクションキーを割り当てない
|ボタン名|動作|備考|
|ヘルプ|ヘルプを表示|ある場合はヘッダー部分に配置|
|入力支援|入力支援ダイアログをポップアップ|テキストボックスの右に配置、見た目は[...]|
④入力支援ダイアログのフッターボタン
|ボタン名|動作|備考|
|F10:検索|検索を実行||
|F11:選択|業務画面のテキストボックスに値をセットしてダイアログを閉じる||
|F12:戻る|ダイアログを閉じる||
⑤ログイン画面
ファンクションキー割り当てなし
|ボタン名|動作|備考|
|ログイン|メニュー画面に遷移||
|パスワード変更|パスワード変更画面に遷移||
|管理者に連絡|メーラが開き、あて先がシステム管理者||
⑥パスワード変更画面
ファンクションキー割り当てなし
|ボタン名|動作|備考|
|パスワード変更|パスワード変更してログイン画面に戻る||
|戻る|ログイン画面に戻る||
⑦メニュー画面
・機能名のリンクをクリックで業務画面表示
・画面番号テキストボックスに番号を入力して、開くボタンクリック（もしくはEnterキー）
で業務画面表示
**6.エラー時の動作
エラー種類と動作：
・クライアントで発生するエラー
①ロストフォーカス時単項目チェックエラー
内容：
テキストボックスからフォーカスが外れたタイミングでチェックを行う、
単項目のチェック。サーバサイドへの問い合わせはしない。
細かくは、「型チェック」⇒「範囲チェック」の順で行い、
型チェックでエラーの場合、範囲チェックは行わない。
ただし、未入力でフォーカスをはずす場合は、チェックを行わない。
動作：
ポップアップでエラーを表示、エラーになった項目名と理由を表示する。
②クライアントサイドシステムエラー
内容：
JavaScriptで予期せぬ結果が返るなど、クライアントサイドで発生するシステムエラー。
動作：
・ポップアップでエラーを表示。
・サーバに非同期通信でエラーを通知を試行。
・および、クッキーにエラー内容を書き込む。
・サーバで発生するエラー
①～③までは、サーバ処理の最初にこの順で実行する。
①単項目入力チェックエラー
内容：
単項目の入力内容チェック結果のエラー。
細かくは、「必須チェック」⇒「型チェック」⇒「範囲チェック」優先順位でチェック。
また、画面上の全入力項目を一度のに全てチェックする。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「入力チェックでエラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目のうち、Tab順が最も早い箇所に設定。
・画面下部のメッセージ領域に、フォーカスが当たっている項目のエラー内容を表示。
（その後も、サーバー処理が発生するまで、フォーカスが当たった項目がエラーの場合だけ、
メッセージ領域にエラーを表示するようにし続ける。）
②相互項目入力チェックエラー
内容：
項目間の入力内容を相互チェックして判明するエラー。
例えば、値の大小比較。終了日のほうが開始日より早い値が設定されているなど。
このチェックは、１箇所でもエラーがあればそこで終了。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「入力チェックでエラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目のうち、Tab順が最も早い箇所に設定。
・画面下部のメッセージ領域に、相互チェックエラー内容を表示。
（その後も、サーバー処理が発生するまで、メッセージ領域にエラーを表示し続ける。）
③コード未存在エラー
内容：
マスターに存在しないコードが入力されているかどうかチェックする。
このチェックは、１箇所でもエラーがあればそこで終了。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。「コード未存在エラーが発生しました。」と表示。
・エラーのあった項目の色を赤色に変更
・フォーカスをエラーのあった項目に設定。
・画面下部のメッセージ領域に、コード未存在エラーの内容を表示。
④排他制御エラー
内容：
更新対象のデータが、すでに別のトランザクションで更新されてしまっていた場合発生。
このチェックは、１箇所でもエラーがあればそこで終了。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。
「このデータは別のユーザに更新されています。読み込みなおしてから更新してください」
と表示。
・画面下部のメッセージ領域にも、エラー内容を表示。
⑤業務処理エラー
内容：
①～④に当てはまらないエラーでプログラム内で明示的にチェックを行うもの。
例えば、会計的な締め処理が終了しているデータを更新しようとした場合にエラーとするなど。
このチェックは、１箇所でもエラーがあればそこで終了。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。エラーメッセージはエラー内容に応じたものを出す。
・画面下部のメッセージ領域にも、エラー内容を表示。
⑥サーバサイドシステムエラー
内容：
バグもしくはハード・ミドルウェアに障害がある場合に発生、タイミングは随時ありえる。
このチェックは、１箇所でもエラーがあればそこで終了。
動作：
・入力した画面から次の画面には遷移させない。
・ポップアップでエラーを表示。エラーメッセージはエラー内容に応じたものを出す。
極力内容を分類するが、NullPointerException等バグにより発生するものは、
「予期せぬ例外が発生しました。」とする。
・画面下部のメッセージ領域にも、エラー内容を表示。
**7.その他の動作
・タブキーによる制御準は、画面単位で、「ブラウザ標準」or「全項目の順序制御」を決める。
・画面初期表示時のフォーカスはタブによるキー制御の1番目のもの。
・完了画面から初期画面に遷移した場合、初期画面に検索機能があれば直近の検索条件で再検索する。
・Enterキーでも次の項目へのフォーカス移動を行うようにする。ただし、ボタンにフォーカスが当たっている場合は、ボタンクリックの動作をする。
・テーブル内の項目にフォーカスが当たっている場合に、上下のキーを入力すると、フォーカスが１の行、下の行に移動する。
・クリアボタン、戻るボタン、終了ボタンクリック時は、入力項目が変更されている場合のみ、「編集内容が失われます。よろしいですか？」と確認ダイアログを出す。
ただし、入力項目でも単に検索条件の項目の入力の場合は、変更とみなされない（つまり確認ダイアログは出ない）。
・入力項目は、フォーカスを受け付けた際は、色が変わる。
（このぐらいにしておきます。）
このwikiのメインではないのでここは非常にシンプルに書いておきます。
**1.開発プロセスの概要：
ざっくりこんな流れを想定します。
・①要件定義⇒②外部設計⇒③内部設計⇒④単体開発／単体テスト⇒⑤結合テスト⇒⑥シナリオテスト⇒⑦システムテスト⇒⑧ユーザーテスト
・SEとPGは分業制です。
-SEはお客様の対面に立って、仕様の詰めを行うがプログラム開発はしません。
スキルとしてもJavaによるプログラムが出来ることは必須としません。
-PGはお客様の対面には立ちませんが、プログラム開発を行います。
①要件定義
システムの業務フロー、機能一覧（画面一覧とバッチ一覧）、
DBの主要項目ぐらいまでは洗い出します。
担当：SE
②外部設計
お客様と決めておくべき事項は全てここで決めます。
加えて、画面の項目やDB項目の物理名は決めておきます。
担当：SE
③内部設計
外部設計で定義していないので、プログラム開発に必要な項目を設計する。
担当：PG
④単体開発／単体テスト
プログラム開発と、プログラム単体の自動テスト(JUnitなど)、
PGのローカルPC上での画面単位の動作確認テストなどを実施。
一連の操作による画面の流れが正常に出来る程度の結合テストまでは実施。
担当：PG
⑤結合テスト
全プログラムを結合して、結合テスト環境に配備してテストを実施。
関連する機能同士の整合性の確認、また、PG開発者とは別の人間により、
単体テストの再確認等も実施。
結合して動かせることと、PGが開発したプログラムの品質確保が目的。
担当：SE
※、不具合の修正はPGが実施
⑥シナリオテスト
夜間バッチ実行（日次処理、月次処理、年次処理）とオンラインでの入力を絡めた、
実業務のシナリオを想定したテストを実施。
結合テストの一部だが、上記のレベルの品質が安定しないと実施が不能なため、
タイミングはかなり開発の後半になる。
担当：SE
※、不具合の修正はPGが実施
⑦システムテスト
負荷テスト、バックアップ／リカバリーなどの運用テストなど実施。
本番環境へのプログラム配備と確認もここで行う。
タイミングは、⑥と平行ぐらい。
アーキテクチャーとして性能が出ない構成になっていないかどうかというレベルの、
負荷テストはもっとまえに実施する。
担当：
※個別機能の担当者主体ではなく、アーキテクトなど主体となる。
⑧ユーザーテスト
最後にユーザーが受け入れのために確認を行うテスト。
担当：
ユーザー。
ただし、SEが最大限に支援を行い。修正はPGが行う。
2.どのように開発を支援するか
①徹底した標準化と、フレームワーク／ツールによる支援。
・設計書から、均質な動作をするソースコードを自動生成できるように
ツールを開発します。
・ツールでは100%自動生成は目指しませんが下記の方針として自動生成します。
・自動生成後に追加で手動で記述する部分と、自動生成部分は明確に分離して、
何度でも、設計書⇒ソースコード生成を行えるようにする。
これにより、設計書に修正が必要な変更が発生した場合は、
設計書修正⇒ソースコード修正の流れを維持できるようにし、
生産性向上とともに
「設計書とソースコードの乖離を最小限に抑えること」
「自動生成部分に変更があった場合も生成できること」
も狙う。
・設計資料も含めて、何箇所にも等価なものを記述する手間を省く。
例えば、HTMLで設計資料用の画面イメージを作り、実装用にはJSPを作成する
といった無駄も省けるようにする。
②上記を前提とした、設計／実装ガイド資料を作成
③上記を前提とした設計書テンプレートを作成。
レビューガイド／チェック資料なども作成。
④共通部品の提供
共通部品として提供できるものは一式そろえる。
⑤単体開発環境を提供。
・Eclipseに、プロジェクトに必要なプラグインを設定済みにして配布。
・SVN環境の整備。
-フォルダ階層の標準化やソースコード管理方法の整備も含む。
⑥結合テスト以降のテスト環境構築と、ライブラリ管理者への受け渡し方法の整備。
ここでいうライブラリ管理者は、リリースすべきソースコードの管理と、
障害解消の対応付けなどを行う人のこと。
どこまで人手を必要とするかは、考え方と環境整備の充実度による。
本wikiでは、「結合テスト」で使用するソース管理は、
開発者やサブシステムのリーダの担当とし、
「シナリオテスト」以降のテストで使用するソースは、
結合テストで合格したものを厳格な手続きでライブラリ管理者に受け渡して
管理する方法を想定する。
⑦自動テスト環境の整備。
単体開発者がJUnit、Selenium等による自動テストを実施できる環境を用意し、
かつ、テストソースもソースと一緒にSVN管理する。
テストケースの網羅性なども一定の指針を設けて、最低限のラインは確保する。
ただし、自動テストをやったら手動テストはしないというのではなく、
普通に手動で動作させての確認は自動テストと重複する内容でも1度は実施する。
結合テスト以降の環境では、毎日全てのテストソースを夜間自動実行し、
結果をフードバックして不具合は速やかに修正する。
⑧不具合修正／要件変更手順の整備
手順を明確にし、お客様と同意しておく。
（このぐらいにしておきましょう。）
