ＵＭＬ以前の、システムの関連性（トレーサビリティ）

さっき、大学院のレポートに出席の感想として書いたことの一部抜粋。
さっきの「システム開発地図」の話にも関係しそうなので・・・

---

　私が、アプリケーション系に入った（ＥＡが騒がれていた、２００３年ごろから）ころは、
　以下のような方法論が固まっていました。

・まずは、システムを「部長レベルの視線で」ざっくり分けて
　　→コンテキストダイアグラムやＤＦＤ
　　　場合によっては、機能構成図（ＤＭＭ）にまとめる


・それを、ＤＦＤによって詳細化し、課長レベルの目線に下げて、


・さらに、課長さんから、担当者に聞き、担当者のやっていることを、
　入出力をもとに、業務流れ図（WFA）にまとめる


という流れが、国家的に（上記のサイトは、もともとは経済産業省のＥＡサイト）
決まっていました。

---

　ここから、設計レベルでの検証として、

・ＤＭＭの各機能が、ＤＦＤに対応しているかどうか、
　さらに、ＤＦＤの上位の機能と、下位の機能で矛盾がないかどうか
　(入出力が一致しているか等）

　のチェックを行い、その上で

・ＤＦＤのファイルが、業務流れ図の中で、ＤＢ等の
　データ保管メディアとして記述されているか確認し、
　そのファイルの内容をＥＲ図でまとめ、漏れがないかどうか確認し


・ＤＦＤで、外部から、プロセスに入ってくるとき、
　画面が必要かどうか確認し、必要な場合、それが、
　業務流れ図の画面として存在しているかを確認し、


・ＥＲ図の各エンティティに対して、ＣＲＵＤを作成し、
　生成されてないのに参照するなどの矛盾がないか確認
　し、あれば、ＤＦＤから直す


といったことを行うと、


・業務流れ図上に、画面、帳票、プロセス、ＤＢ書き出し
　がすべて整理されるので、その各パーツを設計手順に
　したがって設計し、実装すればよい

というようになるような形が出来上がっていました
（プロジェクトによっては、当然、一部省略したりするのですが）

---

この方法だと、

・業務流れ図はＩＤＥＦ０と違い、実体がそのまま書かれているので
　お客さんとの間でも、確認が出来る。

・業務流れ図に画面、帳票が全部出ているので、それに対してレイアウト
　をつくり、画面遷移を行えばよい→作業の終わりがわかる

というメリットがあり、この時期の仕事は、
悩まず仕事ができて、仕事しやすかった記憶があります

---

その後、ＵＭＬには、ここまでの記述力がないので、混乱した時期が
ありましたが、現在では、ＵＭＬでも、ユースケース記述を使うと、
同程度の記述力があり、ユースケース記述から、実装まで、一貫性を
もって、プログラムが書けるようになってきたので（ＩＣＯＮＩＸと
ＪＳＰやフレームワークによって）あのころと同じく、開発しやすい
体制になったと思います。

　もし、この体制がなければ、いまのRuby on Railsでの開発などは、
混乱のきわみになったと思います。

---

　こんど、結果として、
ＵＭＬでは、どういう流れになったのか
を書いたほうが良いね！

　気が向いたら・・・

ＰＭＢＯＫのお勉強 その３３ － ６．４

今、

プロジェクトマネジメント　知識体系ガイド（PMBOKガイド）第４版
http://www.amazon.co.jp/dp/1933890681

のお勉強をしています。

前回は６．３章だったので、今回は６．４章です

---

■６．４　アクティビティ所要時間見積り



＜＜インプット＞＞

・アクティビティリスト
　　６．１より


・アクティビティ属性
　　６．１より


・アクティビティ資源に対する要求事項
　　６．３より


・資源カレンダー
　　６．３／９．２より


・プロジェクト・スコープ記述書
　　５．２より
　前提条件には以下のものがあるが、これに限定されない
　　　・既存の事情
　　　・情報の可用性
　　　・報告する期日の間隔
　制約条件には以下のものがあるが、これに限定されない
　　　・使用可能なスキルのある人員
　　　・契約条件と要求事項


・組織体の環境要因


・組織のプロセス資産



＜＜ツールと技法＞＞

・専門家の判断

・類推見積り

・係数見積り

・三点見積もり
　　　最頻値
　　　楽観値
　　　悲観値

・予備設定分析



＜＜アウトプット＞＞

・アクティビティ所要期間見積り

・プロジェクト文書更新版
　以下のものがあるが、これに限定されない
　　　・アクティビティ属性
　　　・期間見積もりを作成する前提条件（スキルレベル、可用性など）

初めてのＲｕｂｙを読む その３２ ６．４

「初めてのRuby」を読むの続き

６章　変数と式
６．４　例外処理
から

---

■６．４　例外処理
・Ｒｕｂｙも例外処理を持っている
　　→Ｒｕｂｙライブラリのほとんどは例外によって
　　　利用者プログラムにエラーを通知

・例外を用いるには
　　　・begin endでくくる
　　　・例外が発生した場合、対応したrescue節にジャンプ
　　　・例外オブジェクトを捕捉変数に入れて、処理を制御句へ
　　　　　　クラス指定を省略するとStanderdError指定
　　　　　　例外オブジェクトを使わなければ捕捉変数省略可能
　　　・else句があると、例外が発生しなかった場合実行
　　　・ensure句は例外の有無にかかわらず実行
　　　　　　→必要ないとき、else,ensureは省略可能

■６．４．１　rescue修飾子
・簡潔な例外処理記法としてrescue修飾子がある

　　do_something rescue　error_handring

・左辺の実行中にエラーが発生すると、右辺を実行
・例外クラスを指定したり、例外オブジェクトを捕捉することはできない

■６．４．２　raise
・ユーザーが明示的に例外を発生させるには、組み込み関数raiseを使う
・エラーメッセージ、例外クラスは省略可能
　　→省略すると、RuntimeError

システム開発の関連、ＵＭＬの図の関連を書いた「システム開発地図」

　この前報告した、「SEC特別セミナー」の「ディペンダブルシステムのためのモデルベース開発技術の最新動向」で、羽生田 氏が講演中に話していたんですけど、

　豆蔵では、システム開発の関連、ＵＭＬの図の関連を書いた「システム開発地図」
　っていうのをつくったみたいです。
　なので、メモメモ

詳しい話は、

システム開発地図 第1回：エコな開発を
http://labo.mamezou.com/special/sp_015/sp_015_001.html


で、図自体は、

http://labo.mamezou.com/special/sp_015/sysdevmap/sysdevmap.html

にあるのかしら・・・（Silverlight 3がいる？）

Ｒｕｎで、流れを自動的に流してくれるんだけど・・・
やばい、ぐるぐる動いて、きもちわるくなってきたあ・・・（＠＿＠；）