ＰＭＢＯＫのお勉強 その１０ － ２．２

今、

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

のお勉強をしています。

前回２．１をやったので、今回２．２をやります。

---

■２．２　プロジェクトと定常業務

・実行される業務は、プロジェクトか定常業務かのいずれかに分類できる

・この２種類の業務には、以下のような共通の特性がある
　　　・人が実施する
　　　・資源が限られるなどの制約を受ける
　　　・計画、実行、監視、コントロールの対象となる
　　　・組織の目標や戦略計画を達成するために実施される

・定常業務は継続的、プロジェクトは有期性

・定常業務はプロジェクトを実行しているビジネスの側面を支えている
　　→両者の間には、かなり多くの相互作用
　　→プロジェクトマネージャーは複数の事業執行マネージャーと
　　　協力して作業を行う
　　→定常業務部門から提供される資源の量はプロジェクトにより異なる

・プロジェクトの性質によっては、要素成果物を生成することにより、
　既存の定常業務が変更されたり、定常業務の役に立ったりする場合がある

---

初めてのＲｕｂｙを読む その１０ ３．１

　「初めてのRuby」を読むの続き
今回から３章。まずは

３章　数値
３．１　数値リテラル

---

■３章　数値
・Ｒｕｂｙは組み込みで多倍長整数をサポート
・Ｒｕｂｙで数値を計算する上での最大の難点は、計算が遅いこと
・独自のクラスを作成することができる
　　　→演算子オーバーロードに対応

---

■３．１　数値リテラル
・Ｒｕｂｙに組み込みの数値は、
　　　整数Ｉｎｔｅｇｅｒオブジェクトと
　　　浮動小数点Ｆｌｏａｔオブジェクトに分かれる

・いずれもリテラル表記を用いて構築するのが普通

---

■３．１．１　整数リテラル

・普通に表記すると１０進数

・リテラルの先頭に記号を付け加えることで２進、８進、１６進
　　0xまたは0X　　　　　　　　１６進数
　　0dまたは0Dまたは記号なし　１０進数
　　0oまたは0Oまたは0　　　　　８進数
　　0bまたは0B　　　　　　　　　２進数

・Integerは内部的には、FixnumやBignumというIntegerのサブクラスで表現
　　　Fixnum：内部的に固定長で実装
　　　Bignum：内部的に多倍長整数（任意に大きな整数を表せる）

---

■３．１．２　浮動小数点リテラル

・Rubyで実数値を扱うには浮動小数点を用いて近似的にあらわす
・結果として誤差を生じる場合がある

・ＩＥＥＥ７３４の実装
　　　→少なくとも仮数部５２ビット、指数部１１ビットの精度

・特殊な浮動小数点の値
　　　　正の無限大(Infinity)
　　　　負の無限大(-Infinity)
　　　　非数(NaN)

---

次は３．２

「KAOSによる要求工学からUML設計への統合」とかを聞いてきた

ソフトウェアエンジニアリングシンポジウム2011のワークショップ４　要求工学の午前中の発表で聞いてきた話を報告してみる。

---

■１．KAOSによる要求工学からUML設計への統合
　本田さん（電通大大学院）

KAOSモデル
・要求抽出・定義
　系統的、網羅的＆論理的分析

UML
・要求レビュー→設計
・静的・動的構造の多彩な設計

KAOSモデリング→UMLへ
・ゴールモデル
　　洗練パターン
　　　　↓
・操作モデル
　　洗練パターンから変換パターン
　　　　↓
・ユースケース図
　　　　↓
・イベントフロー図

---

■２．アーキテクチャ指向による要求獲得－診療ドメイン事例－
　　友枝さん

・九州病院のIBMのシステムの話？
　（と発表者は言ってないけど、たぶんその話のように聞こえた）

・アーキテクチャ指向をベースにドメイン分析～要求～外部設計

・ポイント
　　・顧客や利用者の要望は聞くが、要求は聞かない
　　　　　要望：具体的でなく、ざっくりしたこと
　　　　　要求：システムに求めていること
　　　　→でも、その出所は押さえる
　　・ドメインの知見を元に、要求を明らかにする
　　・やることだけでなく、やらないことも明確に
　　・作るのはリスクなので、できるだけ作らない
　　・ドメインEngとアプリケーションEng

・手順
　診療ドメイン全体
　　→診療ドメインシナリオ
　　　　→部分共通化
　　　　　　→依頼・実施ドメイン
　　　　　　　データセキュリティドメイン
　　　　　　　お仕事実施ドメイン
　システムイメージ


・まとめ
　・ドメインモデル：相互理解に有効
　・シナリオ：確認、納得を得るのに有効
　　　システムの統合的な動き
　　　ここの部署システム
　・WFでなく、タスクとその状態で業務を連結
　　柔軟性向上に寄与
　・概略確認に有効だが、本件だけでは
　　システムの要求定義は完了しない

---

「KAOSによる要求工学からUML設計への統合」については、
ちょっと自分の考えを別エントリで書きたいと思います。

9月12日(月)のつぶやき

08:47 from goo
ソフトウエア開発や、UML、その他ダイアログは、ロジカルシンキングに還元できる #goo_xmldtp http://t.co/XtRp1Fa
by xmldtp on Twitter

コンテンツ制作会社の場合、オフショアよりフレームワークの高度化のほうが・・・

DeNAがベトナムの会社を買収したけど、
コンテンツ制作を継続的に行うゲーム会社のような場合、

オフショアして、仕様を海外のソフト委託会社に伝えるよりも、
フレームワークを高度化して、仕様を入れればすぐにゲームができるように
したほうが、柔軟性は高いと思う。

Androidは、アプリにおいてはPhoneGapのようにHTML5で書いたほうが
生産性は何倍も高い（たぶん、ウィジェットとかはできないんじゃないかな？）
必ずしも、オフショアが成功を意味しない気が、最近する・・・


DeNA、ベトナムのゲーム開発会社を買収
http://headlines.yahoo.co.jp/hl?a=20110912-00000028-rbb-sci