二重送信…ワンタイムトークン。便利機能として javascript。
XSS…サニタイジング( HTML の属性値や文章のエスケープ、javascript のリテラル文字列のエスケープ等々 )。
SQL インジェクション…prepared SQL。LIKE に関しては「_、%、＿、％」の 4 つを手作業でエスケープ。DBMS によって字種や字数が違うかも。
未ログイン・権限不足…セッションにログイン情報を持つ。フィルタやインターセプタやチェーンで対応。サーブレットやリクエストプロセッサの頭でも良いかもだし基底アクションクラスの頭でも良いかも。権限で画面表示を分けるなら画面を分けても良いし、画面の部品単位で JSP のカスタムタグで囲って対応するのも良い。
直 URI 指定…ワンタイムトークン。Referer。
セッション同時アクセス…synchronized。ワンタイムトークンを工夫して使う。
セッションフィクセーション…ログイン時にセッション ID の再発行をする。更にワンタイムトークン等々の対策も行うと入力内容を盗むのまで防げる。
フェイザー…画像数字。同一ホストからの書き込み間隔制限等々の制限。
不正な入力…サーバーでバリデーションをしっかりやる。画面入力は一度全て String 型で受け取るのが良い。必須、文字種、定数リスト、最小バイト数、最大バイト数、最小文字数、最大文字数、数値最小値、数値最大値、最小精度、最大精度、最大小数部桁数、正規表現、項目相関( 同時入力不可、同時入力必須、何れか必須、歯抜け、順序、重複、大小、その他 )、DB 問い合わせ( 当然の事だが、単純な存在チェックだけで無く、ユーザ権限内で照会・更新が可能である事をチェックするし、その他の業務的なチェックも行う )。利便性向上の為にサーバーでバリデーションしつつクライアントでもバリデーションするのはアリ。それにはサーバーサイド javascript が非常に有効。モバイルでは特に外字や文字コードに注意。ファイルシステムパスや URI やスクリプトや SQL の元になる文字列の場合は特別に慎重にバリデーションする。サーバサイドで出したエラーメッセージと項目赤化を、クライアントサイドで出したエラーメッセージや項目赤化が上書きしたりする事を考慮する。javascript はイベントの発生が偶に漏れる。ユニークキー指定での検索等の所謂「単票」系の場合は、SQL の WHERE 条件や内部結合条件はシンプルにし、先ずは結果を受け取ってから、それから java でチェック処理を行い、不正な入力に就いての詳細なメッセージを出し分ける。そうじゃない「検索条件にヒットする一覧を取得する」タイプの検索の場合でも、個々の検索条件フィールドへの入力が不正である場合、例えば商品コードというフィールドに商品マスタに存在しない値が入力されている場合は、その単位でメッセージを出して上げた方が親切ではある。
変換ルール…バリデーションで OK だった値を内部ロジックで利用する為に変換するルールの決定。yyyy/MM/dd を yyyyMMdd に変換するとか。ゼロサプレスするとか。カンマを除去するとか。JSP に返ってしまう値を直接に変換しないように注意する事。
メールヘッダインジェクション…バリデーションとかで落とす。
OS コマンドインジェクションとか…バリデーションとかで落とす。
Referer での情報漏洩…URI にセッション ID 等の重要情報を入れない。外部サイトへのリンクを書かない。
ログイン有りシステムでの匿名書き込み…ナンセンスな機能に思えるけど要望がある場合は考慮する。TCP/IP ログや HTTP ログやログインログやアプリログや書き込みログ等々により、システム管理者は割と容易に書き込みした人を特定する事が出来る事を周知する。それでも尚やりたいという事になったのであれば、匿名である事が出来るのは一般ユーザ間の話だけであるという前提を打ち出し、それからそれを満たす実装を行う。当たり前の事なんだけど絶対に hidden とかに個人情報を入れない。入れるとしたら暗号化 ViewState みたいな形にする事。HN と実名の違いを明確にして騙りを不可能にする事。
デバッグ情報…テスト工程を終えたら画面に例外情報とかを表示しない様にする。
同一セッション複数ウィンドウ…hidden を使う。セッションでやるなら色々と工夫する。メモリの使い過ぎに注意する。必要なら DB も使う。セッション持ちが長いならウィンドウ単位でより短いスパンで消したりする。対話( Conversation )の概念を盛り込む。
同一ユーザ複数セッション…不可能にしたいならちゃんと対策を入れる事。
ブラウザ機能の戻る…ブラウザの機能で戻るなって説明書き。GET メソッドばかりで構築してセッションを殆ど使わない。
ブラウザ機能の更新…Post Redirect Get。
URI 2083 対策…Redirect しない。
セキュリティに関する基本的な考え方…攻撃者はアクセスしてる人自身か、それとも第三者か。攻撃対象はシステムか、それともアクセスしてる人か。想定外のアクセスによって困るのは誰か、システムが困るのか、アクセスしてる人が困るのか。システム構築の前提条件の下で( イントラネット等の限定された環境下等々 )そのセキュリティ対策が必要か否か。その機能は必要か、必要な機能とされているか、セキュリティ的に必要か、ユーザビリティの観点から必要か、処理効率性、保守性、移植性、開発効率性、テスト容易さの観点から必要か。第三者系の基本的な攻撃パターンを考える。画面やコンソールを見る( 画面、URL、リファラー等の HTTP ヘッダ )、HTML を見る、プログラムを仕込む( ウイルス、トロイ、キーロガー )、仕込み URL を踏ませる( XSS、XSRF、セッションフィクセーション )、電話やメールで指示する( オレオレ詐欺の様な物で、無限の可能性を秘めた攻撃方法であるとも言えて、理論上はどんな壁も打ち破れる可能性があると思われる )、パケット盗聴や改竄を行う。ユーザ自身が攻撃者の場合の基本的な攻撃パターンに就いては、アプリレベルの対策としては基本的にはバリデーションをやってれば良い筈で、それによって大体は防げる…。↑に書いた様にサーバーのデバッグ情報を出さないようにしたり、セキュリティホールを埋めたり、DoS 対策とかも必要になるけど…。
データベースの更新…必ず更新を行うリクエストでトランザクションを作りその中で必要な全てのチェックを行う。デッドロックとかアイソレーションレベルとかロックエスカレーションとかレコードロック可能かとか MVCC かとか排他手段とか全て気にする事。外部キー使ってるとロックされるレコードが色々だから注意しろ。ファイルシステムとデータベース更新を 1 つのトランザクションで行う場合は整合性の確保に注意する。ロック前にロック無しでチェック出来るならロックせずにチェックする。ロックしてからも同じチェックが必要な事にも注意する。ロック前に参照した値はロック内では使わない。ロック内ではロック順序や処理順序に注意し、ファイルシステムのロールバック可能性の最大化を考慮する。エラー時はログを出したり復帰コードをセットしたりファイルシステムのロールバックを行う。DELETE & INSERT は更新日時の書き変えを強制的に行ってしまう事と、効率の悪さが問題になる事に留意する。外部キーやカスケード削除を考えても筋悪なのは明白。トランザクションを分割して細々とコミットする場合でも処理順序に注意する( 特にエラー発生時点で処理中断する場合 )。テーブルの更新順序のルールとテーブル内のレコードの更新順序のルールをそれぞれ独立して適用するのは問題が無いが、共用すると問題が発生する可能性がある事に留意する事。
排他、インデックス…基本設計から詳細設計への移行期に相当する所で排他やインデックスの設計が行われる事が多いが、非常に落とし穴になる事が多いので注意する事。単体テストが終っても排他設計が未完という状況というのは冗談抜きで有り得る。バッチ処理も当然考慮する。一般的にはテーブルロックは頼ってはいけない機能だけど、状況が状況なら頼る事もあるって事を頭の端に入れて置く。
楽観的排他…画面表示内容が、裏で走る他ユーザやバッチによる更新処理によって、DB の中身より古くなってしまう現象…に対するチェック機構を備える事。更新カウンタやタイムスタンプ等々を用いる方法で行う。更新が頻繁に行われる場合や、画面編集に時間が掛かる場合、単にエラーとするだけでは時間を掛けて編集した内容が水の泡になり捲ってユーザビリティに非常に欠ける使えない物になってしまうので、その辺りも良く考慮する事。粒度も気にする事。明細行が複数ある画面の場合、それぞれの明細行の各々に就いて楽観的排他を行う必要がある場合と、画面全体の明細に対して楽観的排他を行う必要がある場合がある事に留意する。その切り分けは明細行の各々が他の明細行と全く相互に関連が無い、と判断出来る場合は各々の明細に対しての楽観的排他のが良い。だけど画面を見ている担当者が明細 A の数が 100 だから明細 B の数は 150 にしよう、と判断を行う事がある場合は画面全体に対する排他を行う必要がある。
NOT の考え方…DB 検索をする場合は NOT や IS NULL を使うとインデックスが使われなくなってしまうので使わない。それが原則なのだけど、ある項目( NULLABLE )の取り得る値として 'A', 'B', 'C' と定義されていて、設計書に「'A' 以外を検索する」と書かれていて、その項目にインデックスが付いていない場合に NOT や IS NULL を使うべきか迷ってしまう事がある。その検索には他の検索条件もあって、そちらにインデックスが付きそうだったり付かなそうだったりする事もある。この時に機能設計書の不備や DB 設計の不備が考えられるし、機能設計書が正しいという事も考えられる。こういう場合に速やかに機能設計者や DB 設計者に問い合わせ出来る仕組みが存在すると良い。類似の話もあるだろうし。全く違う話になるけど、画面のドロップダウンリストに ALL, 'A', 'B' という 3 項目があって、その項目が DB の商品種別( NULLABLE )に結び付いていて、商品種別の取り得る値として 'A', 'B', 'C' と定義されている場合、ALL を選択された場合に検索条件として IN( A, B ) と書くべきか、それとも検索条件を生成しないべきか、これは迷う所になる。はっきりと設計書に書くべき。
DB のカラムの型…java 型との対応関係を明確にする。DB のカラムのデータを java 型が包含するのが理想。DB の NUMBER(9) と java の int とか。DB も java も浮動小数点数は極力使わない。画面 IO で文字列変換するので null 等をどう変換するのかとか気にする。
コネクションプール…留意する。色々な方式がある事に注意する。ロードバランサとの組み合わせも考慮する。
SQL…java ソースに書いたり、プロパティに書いたり、XML に書いたり、テキストファイルに書いたり、フレームワークを使ったり、色々と書き方があるので良く考える。定数を使えると良い。
ID を歯抜けにしたくない…DB のシーケンスを使うな。
ロードバランサ…ロックとかは全て DB で。ファイルは NAS で。同一ユーザ単一ログイン制限は DB で。普通にログを実装すると、ログはサーバ別になる。キャッシュに注意。
トランザクション…宣言的トランザクションを使え。入れ子方法とか気にしろ。
盗聴・改竄…HTTPS。Verisign とか。ルートキーとか。
クラス分け…アクション( コントローラ )とサービスと Dao を分けとけ。役割をはっきりさせとけ。Bean の作り方もはっきりさせとけ。例外クラスの作り方は落とし穴になりがち。サービスとか Dao の作り方のレベルを決めとけ、例えばどこからでも呼ばれても良い作りであるとか、画面ありきで現状の特定の画面から呼ばれる事を前提で作っても良いとか、利用側は前提条件を全て知った上で呼び出すとか。
定数…java, jsp( 特に el 関数での直接参照 ), xml の全てのファイルから参照出来るようにしろ。バリデーションと緊密に連携出来る様にしとけ( ドロップダウンリストとか )。enum( ラベルと値と順序を持つ )使え。enum は画面用( ドロップダウンリストとかバリデーションの値として許される値 )と DB カラム用( DB のカラムの値として許される値 )と値定義用( 全ての値 )にパッケージを分けて更に相互に変換出来るようにしろ。DB カラム用は変換が面倒になったりするので値定義用を流用した方が良いかも。
Action のチェーン…チェーン先を直接 URI 指定で叩かれる場合を考慮しろ。
有効期限…HTTP ヘッダ( jsp, apache )や HTML ヘッダにブラウザキャッシュとプロキシキャッシュ無効にするとか書いとけ。クエリストリングにタイムスタンプを入れたりするのもアリ。
テスト…自動化しろ。Selenium 使え。dbunit, djunit 使え。エクセルのテスト仕様書から Selenium や dbunit の java テストコードを自動生成しろ。エビデンスも自動取得しろ。エビデンスの成型はエクセルマクロで自動化しろ。客にエクセルのフォーマットとか納得して貰え。人数分スキーマ用意しろ。雛型データを用意しろ。外部キー制約を外したりしろ。Findbugs とか checkstyle とかカバレッジツールとか使え。再デプロイしないとテスト日付が変わらないとかそういうの無くせ。サブシステム単位で DB でテスト日付とか管理すると良い。テスト環境のパフォーマンスに注意。テストし易いコーディングをする事。テストデータを一括更新するツールを作成する事。何故なら開発途中や改修案件が発生した際に、データベースにカラムを追加したりする事が良くあるのだけど、そういった場合にテストデータを一括で直す事が出来ないとリグレッションテスト環境のメンテを放置するケースが非常に多いから。テスト用ログイン画面の用意。出力された HTML ソースを目視確認、カバレッジ確認、見た目を目視確認、異常系を確認、ソースレビュー、動きを実際に動かして確認、ログを確認、ファイル出力や DB 更新とかを確認。
開発初期…エクセルから java ソースとか SQL を或る程度自動生成して置け。インターフェイスとか abstract とかちゃんとして置け。コーディング規約。ライブラリ( java, js )作っとけ。フィルタもインターセプタも。AOP。カスタムタグと el function。header, footer。CSS。ページングとか。ソートとか。和英辞書。アップロードやダウンロードや一時ファイル。ダウンロードは必ず子ウィンドウでやると良い( 子ウィンドウの URL で直接ダウンロードファイルを指すと、ダウンロード時に自動的に子ウィンドウが閉じる( GET メソッドを使う事に注意。実は POST メソッドも可能 ))。フレームワークやライブラリや開発ツールの選定。研修準備。ログ出力先を全て洗いだす。ログ出力先選択基準を決定する。ログ出力インターフェイスを作る。会議体の構築( 朝ミ、リーダー会、進捗会議 )。開発効率を最大化する座席配置の確保。パソコンと周辺機器の確保。電源と LAN の確保。各種アカウントの取得( Windows ネットワーク、SVN、メール、FTP、SSH、DBMS、その他 )。フリーソフトの申請と承認。必要な有償ソフトのライセンスの取得。開発環境構築手順の確立。Check Style 設定とフォーマッタ設定とコードテンプレート設定と FindBugs 設定と AnyEdit の行末ホワイトスペース削除とセーブ時の強制フォーマッタはやって置くべきかも。ログイン画面若しくはログイン情報の引き継ぎの確定。セッションに持つ情報の確定。プロジェクト構成とパッケージ構成の確定。
仕様書…SQL とかを自動生成出来る様にして置け。DDL も DML も。
onload…注意して使え。余り使うな。ここに初期化処理を書くと、重い画像を表示し終えるまで初期化されないので、後々に客に文句を言われる原因になる事が多い。画面を一括表示する処理を onload や ready で行う場合、visibility や display を使うと思うが、画面崩れが起こらない様に注意する事。
JSP やアクションを書く時の細かい注意とか…チェックボックスを書く場合は、チェック状態とチェックボックスが持つ値を分けてフォーム等々に持って置け( 要はドロップダウンリストと同じイメージ )。readonly は HTTP リクエストのパラメータとして値が飛ぶ、disabled は値が飛ばない、display none は値が飛ぶ。disabled は値が飛ばないって事に就いて顧客理解を得る事。セッションフォームを使う場合は、disabled やチェック無しチェックボックスは、結果として null にならず前の値がそのまま残る事を頭に焼き付けて置け。セッションフォームを使う場合は兎に角クリアする必要が常に出て来る事を意識せよ。更新処理の後には再検索をする必要がある場合がある事を覚えて置け( その場合は検索結果が 0 件であっても正常終了メッセージを出す )。Oracle で IN は 1,000 個までしか中身を書けない。Oracle で JDBC のバッチ処理は 65,535 件ぐらいが限界だった筈。c:out は HTML の本文や属性値としては適切だけど javascript には不適切。javascript の書く場所によっても違う。href なら urlencoding で onxxxx なら c:out で script タグなら javascript 専用のエスケープになると思う( 多分 )。
エラー処理…最初に細かく方針決めとけ。マジで細かく決めとけ。メッセージとかも。入力値を消さないとかも。一覧のヘッダも出さないとか。ヘッダだけ出すとか。検索条件を無条件にして 1 ページ目を出すとか。ボタン出す出さないとか。バリデーションエラー時にドロップダウンリストの中身を DB から持って来るとか一覧を出すとか。エラーメッセージの表示場所は全て同じ場所か項目毎か。エラー項目は赤くする。項目相関エラーなら関連項目全てを赤くして、メッセージは固定の場所で、メッセージにエラー内容の他に項目名や項目値や行番号や列番号やキー名やキー値を持たせる。ユーザビリティを向上させる為に、ある致命的なエラーが発生した場合の画面表示では、ある部分しか表示が出来ない為にある部分だけを表示させてエラーメッセージはある部分に出すが、もう少しマシなエラーが発生した場合はもっと画面を表示してエラーメッセージをある部分に出し、更に小さなエラーの場合は画面全体を表示しながらエラーメッセージを項目毎に出す、といった定型化し難いエラー処理があり得る事に留意する。エラーに親子兄弟関係があり、エラー時の画面表示にも親子兄弟関係がある、若しくはより複雑な関係にある、という事があり得る事に留意する事。例えば、全ての単項目チェックの後に相関チェックを行い、単項目チェックに 1 つでもエラーがあった場合は相関チェックを行わない…というやり方より、相関チェックに関係の無い部分での単項目チェックでエラーがあっただけの場合は相関チェックも行う…というやり方の方がユーザビリティが高い。明細行でエラーが出たら行全体やセル全体を赤くするというニーズは良くある( 列全体は余り無いだろうけど )。
戻る・進む・画面遷移…前画面の値を残すか方針決めとけ( 検索条件、現ページ、ソート条件、一覧内容全て、その他 )。戻ってから同じ画面に進んだ場合に値を残すか。画面遷移の前後を気にして、このタイミングでセッションのメモリのこの部分をクリアするとかしなくてはならないとかしてはならないとか気にする。A から B への画面遷移はダメなので弾くとか、A を経由した B から C への画面遷移はダメなので弾くとか、再帰回数オーバーなので弾くとか気にする。
画面動作標準…決めとけ。マジで細かく決めとけ。検索条件を変更して一覧のレコード選択してサブミットしたら検索条件は活きないとか。現行検索条件と変更後検索条件を両方出すとか。ページに表示する最大行数。複数ページ間に跨る編集の許容。ページの情報をセッションにキャッシュするかどうか。非表示項目や無効項目や読み取り専用項目の使い分け。ソートの昇順降順や第二第三キー。0 件や件数オーバー。TAB。長時間処理の結果のポーリング間隔( リフレッシュ、AJAX ポーリング )。フォント。縦スクロールの可否、横スクロールの可否。初期表示の一覧は無条件検索か 0 件か、一覧のヘッダは出すか出さないか。一覧のスクロールはヘッダを除く明細部のみか。初期フォーカス。フォーカス時テキスト全選択。既定ボタン。キャンセルボタン。ドロップダウンリストの既定値と最初の値と最後の値とセパレータや行数や幅と高さ。ラジオボタンの既定選択状態。その他の初期値。画面共通テスト項目の作成。数値のカンマ編集と日付のスラッシュ編集。正常終了メッセージや PUSH メッセージ。複数明細を一括編集する画面で、画面イメージの通りに DB を作り込むのでは無くて、DB に対する差分更新を行う画面があり得る事を留意( 表示時は DB から全てのデータを持って来たりするので、仕様が非常に分かり難い )。javascript を多少は使ったリッチめのクライアントにする場合は、ユーザが画面上の全ての値を変更していないならば、サブミットを非活性にしたりと色々とやる事も考慮( defaultValue を使うだけではダメで disabled とかも色々と考慮。単なる便利機能では無くて保護機能であるならば、サーバサイドでのチェックも必要になる )。空の値の画面表示方法。フォーマット( yyyy/MM/dd, #,##0 )。セル等々が横や縦に伸びても良いのか否か。
iframe を使ったモーダルダイアログと序でに Ajax エラー…エラー表示に注意する。エラー HTML が返って来た場合に画面全体にエラー HTML を表示する様に細工をする必要があるかも。例えば、ブラウザ内臓のソケットエラーの HTML や WWW サーバーが返す 503 エラーの HTML やアプリサーバーやフレームワークが返すエラー HTML が返された時に、モーダルダイアログ内にエラーを表示するのでは無くて画面全体に表示する様に特殊な対応をする。Ajax 通信でエラーが発生した場合も同様の対応が必要かも。Ajax 通信で JSON を期待していたのに HTML が返された場合、location.href する必要があるかも。それにモーダルダイアログ内の Ajax 通信でエラーが発生した場合は、モーダルダイアログ内を location.href するのではなくて、画面全体を location.href する必要があるかも。ショートカットキーの制御をしている場合は、モーダルダイアログ内での挙動に注意する事。例えば F5 とかが画面全体に適用されてしまうとかモーダルダイアログ内に適用されてしまうとか。F5 に限らずキーボードごとに注意する。元からあるキーボードショートカットに限らず、自作のキーボードショートカットにも注意する。キーボードショートカットに限らず様々なスクリプト処理に注意する。beforeUnload で色々とやろうとする場合も注意する事。モーダルダイアログ内では beforeUnload 系の処理を動かさない様にするとか。モーダルダイアログの親画面の入力を元にモーダルダイアログを表示する場合に、バリデーションエラーが発生した場合、モーダルダイアログ内にバリデーションエラーを表示するのではなくて、親画面の方にバリデーションエラーを表示してモーダルダイアログは表示しない様にする事。その為に事前に Ajax でバリデーションを行う( これはユーザビリティの為に行う事であって、モーダルダイアログ表示時にもセキュリティの為にバリデーションを行う )。対話( Conversation )を盛り込んだりする。Conversation の破棄タイミングに注意する。エラー時に破棄するとか。破棄する時はセッション全体を破棄するとかも考慮する。Conversation を親子で持つか共有するか並行にするか、そういうのも考慮する。外部サイトに遷移する場合も考慮する。onload でモーダルダイアログのサイズを iframe の window に合わせる場合は、window の中身を display: none で一括表示してたりしないかに注意する。
子ウィンドウ…親ウィンドウが保持するワンタイムトークンが無効になるので書き変えてやる必要がある。モーダルとモーダレスの考慮。外部サイトに遷移する場合も考慮する。
キー操作…ブラウザなので制約が多い事に留意する。TAB、IME、エンターには特に注意。上下左右、PageUp, PageDown, Home, End も割と注意。スペース、バックスペース、ファンクションキー、Esc、Insert、Delete も少し注意。Ctrl, Alt, Shift 系も注意。
必須入力…分かり易く。
多言語…方針決めとけ。ボタンとかに直接文言書かせないとか。
対応ブラウザ…決めとけ。javascript 必須とか決めとけ。画面サイズとか決める。メニューやステータスバーの非表示とか。
XHTML…やっといた方が良いかも。
コメント…基本的には <%-- --%> で書く。
ログイン…セッション ID は再発行する。「パスワードが間違っています」というメッセージは表示しない。
キャッシュ…アプリ起動時に確定する事はキャッシュする。intern しよう。ログイン時に確定する事はセッションにキャッシュする。DB 更新により不整合が発生する可能性に注意する事。テストをやり難くする事にも留意する( 起動が遅くなる、DB 更新しただけではダメで再起動する必要が出て来る )。ロードバランサに注意。
フィッシング詐欺…フレームは使わない。アドレスバーとステータスバーを表示する。右クリックを許可する。
スレッドローカル…使え。
レビュー…Jupiter とか使う。手順や体制構築する。
ワークフロー…コーディング、ソースコードレビュー依頼、単体テスト仕様書作成、単体テスト仕様書レビュー依頼、単体テスト実施、コミット( コミットログのテンプレートの配布 )。
変更が発生した時…整合性を考える。ユーザ視点での整合性を考える。ここを変更するとエラーメッセージの意味がおかしくなるとか。システム視点での整合性を考える。色々とバグらない様に。修正する資産を考える。基本設計、詳細設計、ソース、UT 仕様書、UT ソース、UT 結果…。スケジュールを考慮して、見積もりを立てる。管理者や顧客と交渉する。ユーザ( 利用者、管理者、経営者 )の使い易さは当然として、基本設計〜テストまでの修正の容易さも考慮する。
Ajax ライブラリ…jQuery は良いって話。俺は YUI しか使った事が無い。
設定より規約…保守性を下げない感じで有効活用したい。
運用方法…24 時間稼働とか気にしろ。日付を跨ぐの気にしろ。営業日とか休日とか締め日とか色々と気にしろ。
日時の取得…DB から取るのが理想。NTP で全て同期取れ。
ユーザ…権限によって表示出来る画面とか気にしろ。
B to B…どこまでセキュリティ対策するか明確にしろ。
パフォーマンス…応答速度とか気にしろ。ユーザ数・アクセス頻度・データ件数・最大アクセス時間帯とかハードウェアとか。夜間バッチ時間とか。メモリとかディスクとかネットワーク幅とか。日中バッチが動いてる間の負荷とか。javascript で重い処理をするのは、顧客が使ってるマシンが古かったりすると拙い事になるので、顧客が使うマシンを確認する。
文字コード…ブラウザが送って来るコードと java 内部コードと jsp のコード( ソース、アウトプット )と DB のコードを特に気にする。DB のインスタンスの設定やコネクションの設定やテーブル定義の比較方法に関する設定に就いても気にする( トリム比較とか大小無視比較とか色々 )。length はサロゲートペアを考慮しない。改行コードも気にする。
ソート…java でソートするのと DB でソートするので順番違うので注意。文字コードの違いだけの問題じゃない。DB は比較方法その物が特殊。
this…AOP と相性が悪い。
Lazylist…注意して使え。メモリ不足攻撃されるかも。
jsp…直アクセスはさせない。WEB-INF の下に置いて、アクションからフォワードしたりする。
DB Analyze…日次でやらないなら SQL にヒントとか書け。SQL を工夫して書け。インデックスもちゃんと付けろ。
移植性…OS、WEB サーバ、アプリサーバ、DB サーバ、Java バージョンを決めて置く。序でにライフサイクルも。
csv, xml…import, export やるなら処理方式とか決めとけ。エラー処理も。
納品物や作業内容…はっきりさせよう。厳しい要求にはそれなりの金と期間を求める。内部設計と詳細設計の作業境界をはっきりさせて置く。詳細設計の納品物を決める。書式を決める。UT の納品物を決める。djUnit 使用で C0 カバレッジを満たせば OK とか。Selenium を使っても良いとか。テスト仕様書が必要とか。エビデンスとして入出力ファイルやスクリーンショットや DB のスナップショット( 実行前後 )が必要であるとか。結合テストと単体テストの境界を決める。品質管理報告書が必要かとか。
外部プロセス…java の苦手分野なので注意する。子プロセスの標準出力と標準エラー出力は読み切ってやる事。プロセス ID を取得する事は出来ない。
外部設計書の確認…外部設計レベルのデータベーステーブル定義書、ファイル定義書、画面定義書( レイアウト、モックアップ、表示/非表示、活性/非活性 )、機能定義書、メッセージ定義書、外部システム IF 定義書は存在するか。業務フロー、処理フロー、データフロー、画面遷移図は存在するか。ユーザ権限と表示可能な画面群の関係を表す設計書。
内部設計書の確認…内部設計レベルのデータベーステーブル定義書( 処理に関わる項目が追加されてたり、排他を考慮した設計になってたり、インデックスが張られてたり、テーブルスペースとか考慮してあったり、更にユニークインデックスを張らないフィールドであっても運用上はユニークになるよとか記述されてたり )。機能定義書が排他を考慮した設計になっている。プロパティ定義書。メッセージ定義書に非機能要件的なメッセージが追加されている。画面項目やデータベース項目やファイル項目の一覧が存在し、表記揺れが無くなっている。和英辞書が存在している。処理負荷の高い処理が抽出されている。共通処理が抽出されている。コーディング規約が存在している。
詳細設計メンバーと基本設計メンバーのホットライン…確立する。質問を書くエクセルシートを用意する。修正を依頼するエクセルシートを用意する。
信頼出来るドキュメント…一覧を頂く。
厳しい大スケジュール…詳細スケジュールを見積もってみて、これだけリソースが足りない旨を説明する。延長か増員の可能性に言及する。
詳細スケジュール作成、進捗管理…クリティカルパスを考慮する。類似機能は同一人物に任せて作業効率を上げる。人は学習する事を考慮する。基本設計が完全に終っている物を優先する。動作確認したいのを優先する。作業効率を上げる為にコピー元や共通処理を考えながら順序を決めて行く。開発初期には問題が多発しそうなのを熟練にやらせ問題点を洗い出す。初心者には簡単なのから任せて行く。人を育てたい要望があるなら考慮して色々と任せてみる。基本設計に修正が入るのを考慮してバッファを取る。各自に詳細見積りを出して貰いそれを反映する。リファクタリングや全体に及ぶ基本設計の修正に対応する期間を取って置く。リーダーはリーダー業務があるので手を空けて置く( サポート要員にもなる )。複数作業者が同時に同じファイルにアクセスすると作業効率が落ちるので避ける。チーム外からのノウハウ伝達も考慮する。チーム内の縦のノウハウ伝達も考慮する。チーム内の横のノウハウ伝達も考慮する。各自の得意分野と性格と都合の考慮。人や資材を融通し合う事を考慮。人や資材の外部調達を考慮。人や資材が出て行く事を考慮。水平分業( 工程、作業 )と垂直分業( 機能 )を適切に行う。利用ユーザが同じ( 営業担当が使う画面群、製造担当が使う画面群、管理者が使う画面群 )という単位で分けるのは割と良い。早めに終った人と遅れてる人が居る場合、早めに終った人に遅れている人の作業を手伝わせて、詳細スケジュール全体で狂わない様にする。そういう調整をしても遅れてしまった場合、詳細スケジュールの見直しを行う。スケジュールを書いた人間は、どの機能とどの機能が類似している等々の情報をスケジュールを書いた段階で掴んでいる為、各担当が機能に取り掛かり始めた時に何を参考にすれば早く作業を進められるかアドバイス出来る。そういうアドバイスの為のドキュメントも作成すると尚良い。
http://d.hatena.ne.jp/ILoveMisuzuchin/20110610 も読んで。
http://d.hatena.ne.jp/ILoveMisuzuchin/20100614 も読んで。
以下はインフラレベルの設定の話。
DB ユーザ権限と OS ユーザ権限とファイルシステムアクセス権限の最小化。
セッション ID を類推不可に。
セッションのタイムアウトをそれなりの時間に。
Cookie の domain, path, secure をちゃんと指定する。
index.html が無くてもディレクトリを見せない。
HTTP レスポンスヘッダにサーバのバージョンを入れない。
GET, POST, HEAD メソッド以外は受け付けない。
サーバや DBMS のデフォルトアカウントやデフォルトパスワードの無効化。
