スポンサーサイト

 --------
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

スポンサーサイト の続きを読む


カテゴリ :スポンサー広告 トラックバック(-) コメント(-)

詳細設計の粒度

 2007-03-05
先日、職場の人とこんな会話がありました。

職場の人:「これ(詳細設計)って、どこに機能内容が
      書いてるんでしょうね?」

ぼく:「そのファイルの前のほうに書かれてるんじゃないですか?」

職場の人:「ほんとだ、でも真ん中の方にも書かれてるよ」

これは既存の詳細設計書を見ての会話でした、
ファイルはエクセルで書かれていて、
1画面に1ファイルで、シート毎に
画面定義書やチェック内容、処理定義などが書かれていました。

設計書粒度って難しい、、
これまで色々な設計書を見てきたけど、
どれも一長一短な気がします。

というか、解かりやすく書かれていても、
やっぱりどこかはローカルルールなので、
メンテが発生する度にどうしても
最初の指針がずれていってしまい、
結局ソースを追いかけるハメに、、

それならいっそXPとして仕様書なしの方が
いいのか?
コメント+javadocと画面毎の機能概要と
基本設計で充分?

どっちにしろ明確な良いルールがあって
誰が見ても理解が容易で、
どこのプロジェクトでも通用する設計書が理想だな。

こうゆう所をもっと追求したいんだけど、
今の仕事は維持改善だからなー、
焦らずチャンスを待とう。

よろしければポチっとお願いします。(変な所には飛びません(^^))


詳細設計の粒度 の続きを読む


移行計画書

 2007-02-17
移行計画書とは、本番リリースするモジュールを
どういう手順で環境に乗せるかを記述するドキュメント。

付随する資料としては、
移行手順書‥実際の手順を詳細な作業レベルまで落とし込んだ内容を記載する
タイムテーブル‥時系列に移行作業を並べたもの
とかがあります。

WEBの場合だと、おおまかに
・サーバー環境構築
・モジュールデプロイ
・デプロイ後の動作確認
・本番データ移行
見たいな感じの事を記載します。

ここまでは実際の開発環境を作った時の焼き直しでいいんだけど、
難しいのは、ミスった時の代替案や復元作業を考える事です。

大体、移行当日はサーバーを止めて作業をするので休日に実施する事が
ほとんどで時間的制約もあります。
その為に、事前に細かな資料を入念に準備する必要があるんですけど、
何が起こるかわかりません、もしかすると突然ハード故障やネットワーク障害が起きたりする
かもしれません。

その為の代替案なんですけど、
ハード故障の場合だと予備のマシンや既存のマシンにデプロイ先を変更するだったり、
細かな作業ミスが発生した場合でも、この時点までDBの内容を戻しますとかだったり
考えないといけません。

でも、僕の場合。
ええいメンドクセー
「ハード故障の場合、ベンダーへ連絡」
だって筐体1台しかないんだもん。。

これじゃレビュー通んないだろうなー
どうしよー


よろしければポチっとお願いします。(変な所には飛びません(^^))


移行計画書 の続きを読む


≪ トップページへこのページの先頭へ  ≫
halken800 Twitter
最近の記事
カテゴリー
タグリスト
最近のコメント
最近のトラックバック
広告



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。