「プロジェクトリーダー的なプロジェクトメモ」の詳細記事： Javaってまだいけますか
いっぱいいっぱいで無理なので学んだ事をいちいちメモっていくブログです。
[PR]
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
Navigation
プロジェクトリーダー的なプロジェクトメモ
プロジェクトを通じて感じたことをメモ。
（かなり走り書きです。）
製造
テスト
（かなり走り書きです。）
主に業務アプリをやってきた中で感じたことを徒然なるままに綴ってみました。
全般に言えること
全般に言えること
- 標準化、規約、テンプレートの作りこみは大事 ⇒最初に作ったものが絶対ではなく、育てていくもの。
- 担当は特化させて、最終的に明文化して情報展開
- ＰＬが１人月分作業を請け負ってはだめ。最後の切り札的に入れる余裕を。
- ロジカルシンキング重要。大きな方針から詳細への順で考える。
- ドキュメント、テスト仕様書は
- 読みやすいこと
- 編集、メンテがしやすいこと
- 漏れが発生しにくい工夫をすること
⇒理想は埋めていくと自然に良いドキュメントになるテンプレートを作る
- １つ１つ個別に検討することは極力減らし、ルールを決めて自動的に決定されることを増やすと楽
- 早めのドラフト版レビューで手戻り少なく
設計
- 全般
- ユーザの目に触れること、ユーザの合意を得る必要があるものは外部設計で
- フォルダ構成はリリース後のことも想定してちゃんと考える
- 外部設計
- 発注者ビューガイドラインは参考になる。
- 特に重要なもの
- 各種方針決定
- ドキュメント規約
- 表現（「押下する」か、「クリックする」かなど）、文言、項番、表形式、英数記号は半角か全角かなどの統一ルール
- 用語集による用語の統一
- 機能分類の応じてテンプレート化する
- 処理の流れ、処理の内容、例外処理を分けて書くと書きやすい。
- 入力制御
- 数値、英字、漢字、日付、フリーテキストの形式、桁数、入力ルールなど
- 自動トリム、自動大文字／小文字変換、日付変換など
- 画面関連方針設計
- デザイン／レイアウトガイドライン⇒ブラウザタイトル、画面タイトルのルールも合わせて
- 文言表記ルール⇒ドキュメント規約と同様
- 英数記号は半角か全角か
- ”組織”か”部署”か
- ”名”か”名称”か
- 日付はyyyy/mm/ddか、yyyy年mm月dd日か、yy/m/dか など
- バリデーション方針
- クライアント側、サーバ側の分担方針
- 通知方法
- 画面トップにメッセージ
- アラートダイアログ
- 入力項目の脇にメッセージ など
- 入力方式
- 入力支援（カレンダー表示、自動保管、英字大文字小文字自動変換など）
- 予め入力項目パターンを洗い出してルール化する
- 短いテキスト（氏名など）、中間のテキスト（メールアドレスなど）、
- 長いテキスト（会社名、住所など）、複数行テキスト（備考など）
- コード類（社員コード、組織コードなど）
- ・日付（年月、年月日、時刻）
- 完了画面、エラー画面、エラーメッセージ表示形式
- ポップアップ画面の形式
- ページングの形式
- 検索結果0件の場合の表示形式
- セッションタイムアウトの方針
- 読み取り専用項目はreadonlyかdisabledかラベル表示か
- 権限制御
- 機能公開／非公開、ユーザ権限分類方針設計
- ログイン方法、ログアウト方法
- 共通コンポーネントでの制御と各機能での制御の住み分け
- プロトタイプの有効活用
- JSPなどに利用する予定で作ると実装が楽
- 外部設計は内部設計の方針（後述)に応じて詳細度を変える。
- ドキュメント規約
- ＤＢ設計
- 全般
- 命名規約
- データ型、桁数決定ルール
- ＤＢオブジェクト名称辞書を作成するなどして周知
- ツール
- ＥＲモデリングツールの選定、利用方針
- ＤＤＬや定義書が出力できるなど、生産性アップを考慮したツール選び
- ビュー、ファンクション、プロシージャ使用方針
- ビューは共通だけ、など
- 全般
- 内部設計
- メンバースキルに応じて重み付けを変える。
- 初級／中級が中心のチーム
- 実装方法のレビュー／合意をする為、割とちゃんと書いたほうがいい
但し、プログラムをそのまま文章にしたものではなく、SQLやロジックの設計を中心に無駄なく記述したものにする。
- 実装方法のレビュー／合意をする為、割とちゃんと書いたほうがいい
- 中級／上級が中心のチーム
- 外部設計を詳しめにして、内部設計は共通系だけで十分
- 初級／中級が中心のチーム
- 特に重要なもの
- アーキテクチャ設計
- 基底クラス設計
- プレゼンテーション層設計
- ロギング、エラー通知方針
- 実装規約設計、コーディング規約
- パッケージルール
- セッションの利用ルール
- トランザクショントークン利用方針(２重サブミット、不正遷移制御方針）
- その他入力データの空白除去方針など共通ルール
- 共通処理設計
- 複数行テキスト項目の表示時整形
- アーキテクチャ設計
- 設計書にもテンプレートメソッドパターンは有効
- 基本の流れを定義した設計書と、固有機能部分の設計書を分けて、記述内容に重複がないように、といった感じで。
- メンバースキルに応じて重み付けを変える。
製造
- 利用するツール、Eclipseプラグインなどの選定
- 開発環境構築手順書
- 開発環境資料（URL、DBサーバのホスト、ポート等をまとめた資料）
- ビルドプロセスは最初に整備（Maven2、Antなどの利用）
- 共通部分の作りこみ重要
- レガシーシステムの場合はアダプタークラスの作りこみ重要。
- フレームワークごと入れ替えられない場合は、使いにくい部分を隠蔽して生産性アップ。
- 開発プロセスの効率化
- ローカルデバッグがしやすい環境を作る
- デプロイ／動作確認がさくさくできる環境を作る
- バージョン管理やバグトラッキングは言うまでも無く
テスト
- テスト仕様書
- 再利用可能なテスト仕様書
- 設計書と１対１で対応したずっと使えるテスト仕様書を作る。
- 最初から全てJUnit化できなくても、徐々にJUnit化していくのも有り。
- 漏れが少ないテスト仕様書
- 自然と漏れが無くなる、予め書くべきことを書かざるを得ないような工夫をしたテンプレートを作りこむ。
- 機能分類別基本テストケースパターンで標準化
- 正常系、異常系
- 大分類、中分類、小分類
- 設計書章番号
- テスト分類（同値分析、境界値テスト）
- 確認方法
- 共通仕様テスト
- 共通で各機能に実装されているべき処理などは個々のテスト仕様書ではなくまとめてテストする。
マトリックスにするなどして漏れなく。
- 共通で各機能に実装されているべき処理などは個々のテスト仕様書ではなくまとめてテストする。
- 再利用可能なテスト仕様書
- ユニットテスト
- テストケースのコメントのルール化
- テスト対象のクラスは最初にルール化
- ビジネスロジッククラスのpublicメソッド単位？
- ユーティリティ、共通クラスは全て対象、など。
- DBUnitを利用する場合のテストデータ管理戦略は難しい。
- 総合テスト
- テスト計画書
- テストの方針、方法、環境、担当者、報告方法、障害対応方針などをまとめる。
- 品質アップのために
- 単体レベルのテスト漏れ
- 実装担当者とテスト担当者を変えることにより視点を変えて漏れを防ぐ。
- テスト結果／エビデンスのレビューを確実に行なう。
- デグレ防止
- JUnit等を利用したテストの自動化を行なうことで防止する。
- セッション周りの不具合
- セッションの利用方針について厳密に規約を決める、または共通フレームワーク化し、不具合を起きにくくする。
- 単体レベルのテスト漏れ
- テスト計画書
リリース
- リリースは必ず自動化
- ビルドツールや、batスクリプトを作成してリハーサルしておく。
- リリース手順書重要
- アプリケーションのデプロイだけでなく、データ移行内容なども十分にレビューしておく。
リリース後
- 運用資料を整備する。
- 利用ユーザの追加手順
- 夜間バッチの運用手順、障害対応手順 など
引継ぎ時に自分が楽です。
PR
Navigation
「プロジェクトリーダー的なプロジェクトメモ」にトラックバックする
「プロジェクトリーダー的なプロジェクトメモ」へのトラックバック
「プロジェクトリーダー的なプロジェクトメモ」へのコメント
「プロジェクトリーダー的なプロジェクトメモ」にコメントする
Navigation
menu
ブログ内検索
カテゴリー
カウンター
忍者アド
リンク
最新CM
[07/17 セバ]
[12/27 NONAME]
最新記事
(10/15)
(10/01)
(08/12)
(08/12)
(08/11)
プロフィール
ＨＮ：
takacy.k
年齢：
44
性別：
男性
誕生日：
1979/08/13
趣味：
酒
自己紹介：
個人的なメモですので、投稿内容について真偽を保証するものではありません。また、当ブログの内容をご利用になったことによる（以下略）