XML早已经不是新鲜的技术了。记得03年刚毕业的时候，技术前沿还是asp,jsp，html的时候，xml已经在很多地方用了。对微软的VS2003的接触，MHTML的应用，才逐渐了解XML是个什么东西。
到后来，虽然每个项目中都涉及到xml，还有根java相关的大堆大堆的xml配置文件，但都没有深刻的领悟到xml的方便。
后来，慢慢的Webserivice出来了，使用xml序列化。强类型DataSet出来了，使用xml注解。
慢慢的有点体会。直到最近的一个项目，用了大量的xml，才知道原来xml使得代码的灵活的变得如此疯狂。
很多东西，抽象出来后，使用xml使得很多开关变得更方便灵活，事半功倍的体会非常深刻。
回头感叹一句、怪不得大公司像IBM,微软等，能够提供迅速提供智能解决方案，其实有了基础，东西都是现成的，改改就可以用了。真是方便。
2009年4月26日星期日
デザインパターン再復習の３ー振る舞いに関するパターン
Iterator （１つ１つ数え上げる）
Template Method （具体的な処理をサブクラスにまかせる） 要注意：テンプレートですから、基本記述は全部I/Fです。
Strategy （アルゴリズムをごっそり切り替える）
Visitor （構造を渡り歩きながら仕事をする）
Chain of Responsibility （責任のたらい回し）
Mediator （相手は相談役１人だけ）
Observer （状態の変化を通知する）
Memento （状態を保存する）
State （状態をクラスとして表現する） 要注意：状態に対する各種処理はこのクラスにまとめる。
Command （命令をクラスにする）
Interpreter （文法規則をクラスで表現する）
Template Method （具体的な処理をサブクラスにまかせる） 要注意：テンプレートですから、基本記述は全部I/Fです。
Strategy （アルゴリズムをごっそり切り替える）
Visitor （構造を渡り歩きながら仕事をする）
Chain of Responsibility （責任のたらい回し）
Mediator （相手は相談役１人だけ）
Observer （状態の変化を通知する）
Memento （状態を保存する）
State （状態をクラスとして表現する） 要注意：状態に対する各種処理はこのクラスにまとめる。
Command （命令をクラスにする）
Interpreter （文法規則をクラスで表現する）
デザインパターン再復習の２ー構造に関するパターン
Adapter （皮かぶせて再利用）
Bridge （機能の階層と実装の階層を分ける）
Composite （容器と中身の同一視）
Decorator （飾り枠と中身の同一視）
Facade （シンプルな窓口）
Flyweight （同じものを共有して無駄をなくす） 要注意：Factoryにより同じものをSingletonで作る。
Proxy （必要になってから作る）
Bridge （機能の階層と実装の階層を分ける）
Composite （容器と中身の同一視）
Decorator （飾り枠と中身の同一視）
Facade （シンプルな窓口）
Flyweight （同じものを共有して無駄をなくす） 要注意：Factoryにより同じものをSingletonで作る。
Proxy （必要になってから作る）
デザインパターン再復習の１ー生成に関するパターン
Abstract Factory （関連する部品を組み合わせて製品を作る）
Builder （複雑なインスタンスを組み立てる） 要注意：条件により必要なinstanceを作ること。
Factory Method （インスタンス作成をサブクラスにまかせる）
Prototype （コピーしてインスタンスを作る） 要注意：reflectionのような考えでもOKだと思いまっす。create instance by classname.
Singleton （たった１つのインスタンス）
Builder （複雑なインスタンスを組み立てる） 要注意：条件により必要なinstanceを作ること。
Factory Method （インスタンス作成をサブクラスにまかせる）
Prototype （コピーしてインスタンスを作る） 要注意：reflectionのような考えでもOKだと思いまっす。create instance by classname.
Singleton （たった１つのインスタンス）
2009年4月24日星期五
◆プロジェクトマネジメントの要点―IBMの教育資料
プロジェクトマネジメントではこんな言葉で表現されています
①スコープ定義
②変更マネジメント
③リスク識別・リスク対応計画
④ステークホルダー・マネジメント（明示的／潜在的）
⑤資源見積り（前提事項、スコープの把握、お客様の期待値等の制約の考慮）
⑥契約管理（契約書・提案事項のPMとしての十分な理解）
⑦チーム育成
個人的な考えとしては、スコープ定義後、資源の見積もりを行うはず。
まずはスコープをきちんと把握しないといけないです。
それから顧客との関係はどうやってうまく管理できるのか、重要です。
①スコープ定義
②変更マネジメント
③リスク識別・リスク対応計画
④ステークホルダー・マネジメント（明示的／潜在的）
⑤資源見積り（前提事項、スコープの把握、お客様の期待値等の制約の考慮）
⑥契約管理（契約書・提案事項のPMとしての十分な理解）
⑦チーム育成
個人的な考えとしては、スコープ定義後、資源の見積もりを行うはず。
まずはスコープをきちんと把握しないといけないです。
それから顧客との関係はどうやってうまく管理できるのか、重要です。
2009年4月14日星期二
プロジェクト管理―スコープ定義
スコープ定義の成果物はWBS（Work Breakdown Structure）の作成.
WBSは次の3つの観点から分解する。
① コスト/時間/リソースを見積もれること。
② 進捗度のベースライン（初期計画に承認済の変更を加えた基準値を時系列表示）を定義できること。
③ 作業の責任/権限を明確化できること。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
スコープ定義が不十分だと、調子をくずし、遅延/生産性低下/士気低下/を起こし、最終プロジェクトコストの増大を招くことになる。
個人的な経験には、大規模案件ならば、いくつのサブシステムがあるはず、各サブシステムを各PLに任せて、インタフェースを把握すればOKだと思います。各チーム内ではまたそれぞれ細かくWBSを作成すること。
細かく程度については、各タスクの責任者がどう動くか良く分かる程度であればOKだと思います。
WBSは次の3つの観点から分解する。
① コスト/時間/リソースを見積もれること。
② 進捗度のベースライン（初期計画に承認済の変更を加えた基準値を時系列表示）を定義できること。
③ 作業の責任/権限を明確化できること。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
スコープ定義が不十分だと、調子をくずし、遅延/生産性低下/士気低下/を起こし、最終プロジェクトコストの増大を招くことになる。
個人的な経験には、大規模案件ならば、いくつのサブシステムがあるはず、各サブシステムを各PLに任せて、インタフェースを把握すればOKだと思います。各チーム内ではまたそれぞれ細かくWBSを作成すること。
細かく程度については、各タスクの責任者がどう動くか良く分かる程度であればOKだと思います。
◆プロジェクト失敗の10の理由
① コミュニケーション不足（特にメンバー間）
② 変更管理が行われない
③ メンバーの能力不足
④ プロジェクトマネージャーの人材不足、意識と能力不足
⑤ メンバーの意識が低い（チーム感覚がない）
⑥ 受注時の見積もり精度が低い
⑦ 管理する余裕がない
⑧ 管理基準とその評価基準がない
⑨ 無理な納期（モラル低下）
⑩ 問題発生の対応がうまく取れない
② 変更管理が行われない
③ メンバーの能力不足
④ プロジェクトマネージャーの人材不足、意識と能力不足
⑤ メンバーの意識が低い（チーム感覚がない）
⑥ 受注時の見積もり精度が低い
⑦ 管理する余裕がない
⑧ 管理基準とその評価基準がない
⑨ 無理な納期（モラル低下）
⑩ 問題発生の対応がうまく取れない
订阅：
博文 (Atom)