ここでは、システム構築プロジェクトで、「共通チーム」として考慮すべき 点を列挙します。

システムのアーキテクチャは、 EJBを使ったWebシステムを前提とします。

• プレゼンテーション層

  プレゼンテーション層の役割は、画面からのリクエストを受付け、ビジネスロジックを呼び出し、処理結果に従って画面の再描画を行うことです。
  堅牢なシステム構築のためには、プレゼンテーション層では他にも多数の考慮点が必要です。
  

  • 認証(ログイン・ログアウト)
  • 認可(権限・ログイン制御)
  • 業務規制
  • ページガード
  • サニタイジング(SQLインジェクション対策・クロスサイト・スクリプティング対策)
  • HTTPセッション管理
  • ページ送り
  • エンコード・デコード(文字化け)
  • 国際化
  • 多言語化
    
    

• ビジネスロジック層

  ビジネスロジック層は、業務設計に依存する割合が大きく、処理方式を統一 することが難しい箇所です。
  しかし、最低限のルールを決めておかないと、プログラムの保守性に大きく関わってきます。

• トランザクション管理
• ユーザコンテキストの設計、管理
• 例外の扱い
• セッションファサード、DTOなどの定番パターン
  
  

• データアクセス層
  データアクセス層は、データベースアクセスをカプセル化します。 一般的には、データベースベンダー独自の機能を使わず、可搬性を保つことを目指す傾向があります。
  しかし、ほとんどの場合、複数種類のデータベースに対応させる要件はありません。

• O-Rマッピング
• JDBCテンプレートフレームワーク
• バックアップ計画

• 基本処理方式の検討
  
  • ログ出力→運用管理と連携
  • 例外の扱い、エラーハンドリング

• その他業務処理方式の検討
  
  • 帳票処理方式
  • メール配信処理方式
  • 他システム連携
  • Javaバッチ処理方式(オンラインとは異なるフレームワークで行なうべき)

開発プロセスの標準化

• ドキュメント
  スムーズにプロジェクトを進行させる為に、ドキュメントを欠かすことはできません。
  プロジェクトに新規参入したメンバーを含め、お客様にも納得頂くことが重要です。
  
  • アプリケーション・デザインガイド(画面・処理・帳票・特殊機能)
  • 仕様書作成ガイド(フェーズごとの仕様書の定義と記載基準)
  • コーディング・ネーミング規約
  • 本番/開発環境構築ガイド
    
    

• テスティング(単体・結合・システム・運用テストを除く)
  
  
  • パフォーマンステスト
  • セキュリティテスト
  • モンキーテスト
  • 回帰テスト
  • 受入検証(オフショア)
    
    

• レビュー
  人間は必ず間違いを起こすものです。チェックをしないことが信用だと考えている
  人が多いと感じます。「任せる」ことは、「丸投げ」とは全く異なる点に注意が必要です。
  
  • 仕様書成果物レビュー
  • ソースレビュー
    
    

• 管理関係
  
  
  • 障害管理
  • 変更管理
  • 成果物管理
  • メトリクス分析
    
    その他の要因
• クライアントの選定

  オンライン処理を行う、クライアントは、ウェブブラウザが主流です。
  しかし、より表現力豊かなユーザインタフェースを提供するために、リッチクライアント技術が台頭し始めています。

• データベース

  RDBMSが主に用いられる。Oracle、DB2、SQLServerがシェアを分け合っており、
  オープンソースの製品として、PostgleSQLやMySQLがこれに割って入る構図となっている。