共通チーム(システムアーキテクト)の仕事

ここでは、システム構築プロジェクトで、「共通チーム」として考慮すべき点を列挙します。
システムのアーキテクチャは、EJBを使ったWebシステムを前提とします。

プレゼンテーション層

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

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

ビジネスロジック層

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

トランザクション管理

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

データアクセス層

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

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

基本処理方式の検討

  • ログ出力→運用管理と連携
  • 例外の扱い、エラーハンドリング

その他業務処理方式の検討

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

開発プロセスの標準化

ドキュメント

スムーズにプロジェクトを進行させる為に、ドキュメントを欠かすことはできません。
プロジェクトに新規参入したメンバーを含め、お客様にも納得頂くことが重要です。

  • アプリケーション・デザインガイド(画面・処理・帳票・特殊機能)
  • 仕様書作成ガイド(フェーズごとの仕様書の定義と記載基準)
  • コーディング・ネーミング規約
  • 本番/開発環境構築ガイド

テスティング(単体・結合・システム・運用テストを除く)

  • パフォーマンステスト
  • セキュリティテスト
  • モンキーテスト
  • 回帰テスト
  • 受入検証(オフショア)

レビュー

人間は必ず間違いを起こすものです。チェックをしないことが信用だと考えている人が多いと感じます。「任せる」ことは、「丸投げ」とは全く異なる点に注意が必要です。

  • 仕様書成果物レビュー
  • ソースレビュー

管理関係

  • 障害管理
  • 変更管理
  • 成果物管理
  • メトリクス分析
  • その他の要因

クライアントの選定

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

データベース

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