「開発プロセスサンプル」の編集履歴（バックアップ）一覧はこちら
「開発プロセスサンプル」(2009/08/18 (火) 22:50:41) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
このwikiのメインではないのでここは非常にシンプルに書いておきます。
&bold(){（ただいま作成中です。）}&italic(){}
**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度は実施する。
結合テスト以降の環境では、毎日全てのテストソースを夜間自動実行し、
結果をフードバックして不具合は速やかに修正する。
⑧不具合修正／要件変更手順の整備
手順を明確にし、お客様と同意しておく。
（このぐらいにしておきましょう。）
この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度は実施する。
結合テスト以降の環境では、毎日全てのテストソースを夜間自動実行し、
結果をフードバックして不具合は速やかに修正する。
⑧不具合修正／要件変更手順の整備
手順を明確にし、お客様と同意しておく。
（このぐらいにしておきましょう。）
