初めてのＲｕｂｙを読む その３５ ７．２

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

７章　メソッド
７．２　メソッドの定義

から

---

■７．２．１　def式
・メソッドを定義するにはdef式を使う
・メソッド内には任意の式を並べることが出来、
　メソッドが呼ばれると実行
　　　→メソッドの本体
・メソッド内で最後に評価された式の値が戻り値になる

---

■７．２．２　return
・メソッド内から陽に戻り値を返すにはreturnを用いることが出来る
・戻り値の式は省略可能
　　→省略してreturnだけ書くと、nilが返る
・returnは必須でない
　　→returnに出会わずメソッド末尾に到達すると
　　　最後の式の値が戻り値

・多値の返却
　returnの後に、カンマ区切りで複数の式を書くことが出来る
　　→配列が返る
　呼び出し側では、多重代入の要領で多値として受け取る
　多値を返す場合は、return必要

・値を返さないメソッドは存在しない
　　→返り値に使い道がない場合はnilを返す

---

■７．２．３　デフォルト値
・引数にデフォルト値を指定できる
　→呼び出し時に指定しないとデフォルト値適用

・デフォルト値を持っている仮引数のことを省略可能な引数という
　→デフォルト値が定義されていない引数を省略するとエラー
　→Ｒｕｂｙ１．８においては、省略可能な引数より後に
　　省略不能な引数が存在してはならない

・デフォルト値の評価コンテキスト
　デフォルト値には任意の式を指定できる
　　→呼び出し時にデフォルト値が必要になると、毎回評価
　　　　　→レシーバーのコンテキストで評価される
　　　　　→式を都度評価する：メソッド定義時には確定しない

---

■７．２．４　可変長引数
・呼び出すケースことに引数の数が異なるもの
　　→pなど
　仮引数の中のいずれか１つを、可変長引数の受け皿にすることができる
　　→*をつける：配列として割り当てられる

・スコープの発生
　メソッド本体のローカル変数スコープは外部と完全に独立している
　→メソッド本体の自由変数が外部環境によって解決されることはない
　→クロージャーとは異なる。

「au版iPhone 4Sで初期不良（？）」という話が書いてあるブログ

ここのブログ

au版iPhone 4Sで初期不良（？）発生のため交換
http://blog.livedoor.jp/whats_my_scene/archives/51768357.html

の話(以下太字は上記ブログより引用）


　今日、突然、au版iPhone 4Sで3G回線からのネット接続が出来なくなり、結局は端末を交換することになった。

という書き出しで始まり、以下、経緯が書いてある。
まあ、それについては、そちらのブログを見てもらうとして、
結局


au版iPhone 4Sのみで同様のトラブルが発生しており、原因は不明で現在調査中とのこと。同じ症状が出た場合、今のところは端末交換でしか対応できない由。


とのことらしい。
早く原因を解明しないと、お客さんに逃げられてしまうんではないだろうか？au

ＰＭＢＯＫのお勉強 その３７ － ７．２

（今日は理由あって、ＰＭＢＯＫを２つやります。
　あしたＲｕｂｙを２つやります）

今、

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

のお勉強をしています。

前回は７．１章だったので、今回は７．２章です

---

■予算設定


＜＜インプット＞＞

・アクティビティ・コスト見積もり
　　７．１より

・見積もりの根拠
　　７．１より

・スコープベースライン
　　・スコープ記述書

　　・ワークブレークダウンストラクチャ
　　　　５．３より

　　・ＷＢＳ辞書
　　　　５．３より

・プロジェクトスケジュール
　　　　６．５より

・資源カレンダー

・契約

・組織のプロセス資産


＜＜ツールと技法＞＞
・コスト集約

・呼び設定分析

・専門家の判断
　　専門知識の情報源は以下のようなものがあるが、
　　これに限定されない
　　　　・母体組織内のほかの部門
　　　　・コンサルタント
　　　　・顧客を含むステークホルダー
　　　　・専門家の協会や技術関連の団体
　　　　・業界団体

・過去の関係

・限度額による資金調整


＜＜アウトプット＞＞
・コスト・パフォーマンス・ベースライン

・プロジェクト資金要求事項

・プロジェクト文書更新版
　　以下のものがあるが、これに限定されない
　　　　・リスク登録簿
　　　　・コスト見積もり
　　　　・プロジェクトスケジュール

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

今、

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

のお勉強をしています。

前回は６．６章でした。

今回から、

第７章　プロジェクト・コスト・マネジメント

に入ります。今回は、７．１章です

---

■７．１　コスト見積もり

＜＜インプット＞＞

・スコープ・ベースライン
　　スコープ記述書
　　　　５．２より
　　ワーク・ブレークダウン・ストラクチャー
　　　　５．３、４．３より
　　ＷＢＳ辞書
　　　　５．３より


・プロジェクト・スケジュール
　　　　６．３，６．４より


・人的資源計画書
　　　　９．１より


・リスク登録簿
　　　　１１．２より

・組織体の環境要因

・組織のプロセス資産


＜＜ツールと技法＞＞

・専門家の判断


・類推見積もり


・係数見積もり


・ボトムアップ見積もり


・三点見積もり
　　次の３点の見積もりを行う
　　　　最頻値
　　　　楽観値
　　　　悲観値

・予備設定分析


・品質コスト
　　８．１より

・ベンダー入札の分析


＜＜アウトプット＞＞

・アクティビティ・コスト見積もり


・見積もりの根拠
　　詳細資料としては、以下のものがある
　　　　・見積もりの根拠を記した文書
　　　　・すべての前提条件を記した文書
　　　　・すべての既知の制約条件を記した文書
　　　　・見積もり範囲の表示
　　　　・最終見積もりの信頼性レベルの提示


・プロジェクト文書更新版

「標準ソフトウエア工学教科書」を作ってみたいと思います その１５ ３．３

土日ではなくなってしまいましたが（＾＾；）

土日シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

今回は、外部設計です。

---

■３．３　外部設計

　前回、要求分析で要求をだしたので、次に、この要求を満たすシステムを設計していきます。
　設計については、ここで、２つに分けて考えます。

　　１．ユーザーや外部システム等（ユースケースのアクター）で見える部分。
　　　　→インターフェース、特にユーザーインターフェース（ＵＩ）

　　２．ユーザーや外部システム等（ユースケースのアクター）で見えない部分

　１は外部に見えるところなので、外部設計、２は、内部部分なので、内部設計となります。
　今回は、このうち、外部設計について行います。

------

　外部設計に関して、一番大きな部分は、
　　　１．ユーザーとのインターフェースを決める、ユーザーインターフェース
　　　２．他システムがアクセスするＤＢ、ファイル部分
　　　３．Ｗｅｂサービス等の場合、通信部分のインターフェース（引数と返り）
　　　４．２．３の基本となるコード化

　画面メッセージを分ける場合もありますけど、それは、１に含まれると、ここでは考えましょう。
　２に関して、先ほどの説明だと、他に見えるところだけでもいいのでは？と思うかもしれませんが、このテーブルは見えて、あのテーブルは外部に出さないので、設計しないとなると、検証できなくなってくるので、この場合、外に見えるか否かにかかわらず、全体を設計します。

　なお、ユーザーインターフェースとの矛盾をチェックするために、仮に他システムがＤＢ、ファイルにアクセスしないとしても、外部設計でＤＢ、ファイル設計するのが普通だと思います。

　なお、４のコード化設計は行うのですが、１、２をしているときに自動的に出来てしまうので、意識して行うのは、１のＵＩ、２のＤＢ，ファイル定義で、最近のＷｅｂサービスにおいて、３を考えるという形です。
　なお、以降面倒なので、ＤＢ，ファイル設計と書かずに、ＤＢ設計としてしまいます。

--------------

　では、ＵＩ，ＤＢをどのように設計していくかですが、まず、前提について、確認してみます。
　前提として、要求仕様では、こんなことをしているのでした。

（１）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５）機能要求、非機能要求を要求仕様書という形でまとめる


つまり、（３）の段階で、入力と出力は、決まっているはずです。
なので、この入出力を検討します。

（あ）（３）の入出力を、画面、帳票、ＤＢなど、メディアごとに分ける。

（い）画面について
　　　　（い－１）画面全体のルックアンドフィールを決める
　　　　　　　→全体的な画面イメージ
　　　　　　　　（背景、大きなレイアウト、ナビゲーション等）

　　　　（いー２）（あ）で抽出した画面を、１画面にするか、複数のものを
　　　　　　　　　まとめるかなど考慮して、画面割りをきめる。

　　　　（い－３）画面をどのように遷移させていくか、画面遷移をきめる
　　　　　　　　　　　→追加する画面が出てくるかも

　　　　（い－４）各画面の画面レイアウトを決める

　　　　（い－５）い－３、い－４をまとめて、画面定義書とする
　　　　　　　　つまり、画面定義書は、画面遷移図と画面レイアウトからなる

　　　　（い－６）お客さんにチェックしてもらって、承認を得る


（う）ＤＢについて
　　　　（う－１）どのようなテーブルがいるか決める
　　　　　　　→正規化したりして

　　　　（う－２）テーブルの項目などを決める

　　　　（うー３）テーブルの妥当性を確認する
　　　　　　　　・入力したデータで、必要なものは保存されているか
　　　　　　　　・容量などの見積もりで、無茶はないか？

　帳票に関しては（い）の画面を帳票にかえて読み替えてください。ただし帳票遷移はありえないので、そこは無視します（い－３はない）
　Ｗｅｂサービスに関しては、（う）のテーブルをサービスに読み替えてください。
　　　　　

（え：成果物）結果として、画面定義書、ＤＢ定義書、帳票定義書、サービス定義書ができます。

------------

　Webアプリケーションの場合、画面をＨＴＭＬで記述しておくと、レイアウトは画面イメージを貼るだけだし、お客さんと確認するとき、ブラウザを使ってプレゼンできます（＝プロトタイプになる）。
　このＨＴＭＬで画面をつくるということが、後工程でとても楽になることなのですが、
　それは、後工程の話としておいておきます。

　上記のやり方だと、画面・帳票のレイアウト、遷移に関しては、この外部設計の段階で確定し、ＤＢはおおよそ決まります（内部設計や実装で変更もありえる）。

　ただし、画面設計はそこまでやらないという考えもあります。
　項目をこの段階では確定させない（確定できない）という考え方で、その場合、画面定義書は、内部設計でつくられます。
　が、この方法の場合、お客さんに見せるのがもっと後になり、画面が内部設計中に動くので、内部設計にダイナミックな修正が入ります。これを嫌う場合、ここ（＝外部設計）で大まかに確定してしまいます。

---

「標準ソフトウエア工学教科書」を作ってみたいと思います その１５ ３．２

シリーズ「標準ソフトウエア工学教科書」を作ってみたいと思います

昨日、アップしそびれた分、「３．２　要求分析」です。

---

３．２　要求分析

　前回の超上流で、プロジェクトの目的と、プロジェクトマネージャーぐらいは決まった。
　そこで、次の段階としては、一般的に考えると、

（１）プロジェクトマネージャー（部長くらいとしよう）は、
　現場責任者（課長）をあつめて、プロジェクトの目的などを
　話します。

（２）現場責任者（課長）は、大まかに仕事と担当者の関係はわかるので、
　それをもとに、担当者を指名して

（３）担当者が業務内容を話します。
　ここで、業務の入出力が決まります。

（４）さらに、システム化するに際して、ユーザーインターフェース
　や、応答時間など、業務以外の部分を決めます。

（５）それらをまとめます。


　前回の話で、（１）のプロジェクトマネージャーとか目的等は決まりました。
このあと、（２）、（３）の作業をして、現場担当者の作業（入力－処理－出力）
を明確化するのですが、それには、構造化手法と、オブジェクト指向の方法があります。


------


　構造化手法の場合は、まずシステム全体の入出力を考え、コンテキスト・
ダイアグラムを作成します（ＤＦＤでプロセスが１個のもの）。

　それから、システムを詳細化していきます。
　企業であれば、部長から課長、係長、現場担当者という具合にヒアリングをかければ、
詳細化されていくはずです。それを表現します。

　途中の管理職の人が、現場の詳しいことがわからないようであれば、入出力は
省略し、こんな機能があるというＤＭＭの形で詳細化していき、
　課長、係長と下がっていくと、どこかで入出力がはっきりするようであれば、
そこからＤＦＤを使って書き起こすのがいいと思います。

　どちらのケースでも、最終的な現場担当者の作業は、業務流れ図として表現します。
　業務流れ図では、どのデータを何から（画面から、ＤＢから等）入力し、どこに出力
するか、どのような手順で処理するのか、処理するための条件があるのかが、図で
書き表わされます。

　これができると、データベースに書くべき内容がわかり、エンティティが出てくるので
ＥＲ図がかけます。

　ＤＦＤは、上位のＤＦＤと詳細化した下位のＤＦＤで、外部からの入出力が一致して
いないといけません（一致していなければ間違い）。
　また、ＤＦＤのファイルとＥＲ図のエンティティ、業務流れ図のＤＢが対応している
はずです（１対１でなくてもよいが、ＥＲ図にあるエンティティが理由もなく、ＤＦＤや
業務流れ図にまったく出現しないのは、不自然）。


-----------

　一方、オブジェクト指向の場合、ユースケース図から始まります。

　まずは、部長が課長に仕事を割り振られ、課長が担当者に割り振るとき、課長は、
担当者に、ある仕事をしてもらうことを期待して、割り当てるのが普通と考えられ
ます。
　もちろん、「お手伝い」「遊軍」としてわりあてることもありますが、その人
たちは無視します。すべてお手伝いというのはすくなく、受注、倉庫番とか、
なんらかの仕事はあるんじゃないでしょうか？もし、全員お手伝いだとしたら、
その会社はシステム導入以前に問題があると思います。

　その仕事に、だれが関係するかを考え、仕事関係者をアクター、仕事をユースケース
としてユースケース図を描きます。
　が、ユースケースは動詞の形が望ましいです。たとえば、「倉庫番」は、「倉庫番する」
というのは不自然ですので、「入庫する」「出庫する」「在庫照合する」などに分かれます。

　まず、大きくざっくりと描くことが大事で、たとえば「入庫する」を「積みおろしする」
「検品する」「データ入力する」とか、細かく分けちゃうと、混乱します（これは、あとの
アクティビティ図に描きます）

　とはいえ、ユースケースも細かくすることはあります。

　まあ、そんな形で充分細かくなったら、担当者が行う作業を、手順とともに表現する
アクティビティ図を作成します。
　しかし、アクティビティ図は、構造化分析の業務流れ図ほどの表現力をもちません。
　入出力は表現できません。
　そこで、ユースケース記述というのを作って、そこの基本系列等に、入出力を文章で
描いていくことになります。

　なお、データ構造に関しては、ユースケース記述を見れば書けることになります。
　ＵＭＬはＥＲ図はないので、これに相当するクラス図で描くことになりますが、実際は
ＥＲ図を使ってしまうことが多いです。

-------------------

　上記の方法により、業務の入出力が決まりました。
　構造化手法の場合には、業務流れ図に、オブジェクト指向の場合には、
ユースケース記述に業務内容（入力－業務－出力）の流れは、記述されています。

　次に（４）の業務以外の要求についてまとめます。
　
　ちなみに、（３）のような業務に関する要求を、機能要求、
（４）のような、業務以外の要求を、非機能要求とか言ったりします。

　非機能要求は、上記、オブジェクト指向分析で利用する図（ＵＭＬ）でも、
構造化手法分析で利用する図でも表現されないし、明確な分析方法はありません。
（ちなみに、ＳｙｓＭＬの要求図では表現できます）。


そこで、

　非機能要求グレード
　http://sec.ipa.go.jp/reports/20100416.html

　のようなチェックリストを基に考えたり、機能要求を基に考えたり、
　 JIS X 0129-1 (ISO/IEC 9126 )のソフトウェアの品質特性を基に
考えます。


　ここまでくると、（５）のように要求仕様書としてまとめられます。
　まとめ方としてはＩＥＥＥ８３０等に基づいてまとめるのが、今のところ
よいのでしょうか？

----------------

　この要求仕様書の作成方法は、各社各様です。上記の方法は、公開されている、
一般的な方法について描いただけです。
　ただ、手法の側面をそぎ落とし、誰が何をやっているのかだけに注目すると

（１：前提）プロジェクトの目的と、プロジェクトマネージャーは決まっている状態で、

（２）えらい人からえらくない人へ、仕事を分割していく
　　　→その仕事の範囲をざっくりと図や文にまとめる

（３）最終的に、仕事を受け持つ担当者に行き着く
　　　担当者のやるべきことを、入力と出力に着目して、記述する
　　　→機能要求

（４）機能要求以外（非機能要求）を何らかの方法で、えいやときめる（＾＾；）

（５：成果物）機能要求、非機能要求を要求仕様書という形でまとめる

という形になると思います。

「iPhone 4Sの『Siri』に脆弱性あり」

「デフォルト設定では暗証番号でロックした端末すら危険」なんですって。

ここのニュース

セキュリティ専門家が指摘、「iPhone 4Sの『Siri』に脆弱性あり」――デフォルト設定では暗証番号でロックした端末すら危険
http://headlines.yahoo.co.jp/hl?a=20111021-00000002-cwj-sci

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

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

今日から
７章　メソッド

７．１　メソッド呼び出し
から

---

■７章　メソッド

・メソッド：Ｒｕｂｙにおいて手続きをモジュール化し、再利用するための仕組み
　　オブジェクト指向のメッセージ送信と
　　構造化プログラミングのサブルーチン
　両方の役割

・関数型メソッド
　　オブジェクトとは無関係に呼びさせる

---

■７．１　メソッド呼び出し
・Ｒｕｂｙプログラムにおけるすべてのデータはメソッドを持っている
　　→どんなメソッドを持っているかは、クラスによる
・Ｒｕｂｙプログラミングで中心的な役割を果たすのがオブジェクトに
　対するメソッド呼び出し

・メソッドを呼び出すには、レシーバー、メソッド名、引数を以下のように書く

　　　a.some_method(1,"str")
　　　a::some_method(1,"str")

　クラスメソッドを呼ぶ場合を除いて、第一のスタイルが主流

---

■７．１．１　括弧の省略

・引数をくくる括弧はあいまいさを生まない限り省略可能

---

■７．１．２　メソッド連鎖

・メソッドは必ず何らかの値を返す
　　→メソッドの返り値ないし戻り値という
　　→返り値に対してメソッドを呼ぶことも可能
　　　　　→メソッドチェーン

---

■７．１．３　レシーバーの省略

・メソッドを呼び出すレシーバーを省略することができる
　　→この場合は、デフォルトのレシーバーである
　　　selfに対してメソッドが呼ばれる
　　　　　→C++,Javaなどのthis

・擬似変数selfは常に「現在のレシーバー」をさしている

・privateメソッドは、常にレシーバーを省略形式で呼び出す。


・レシーバー省略とローカル変数
　引数をもたないメソッドのレシーバーを省略すると、
　ローカル変数の参照と見分けつかない
　　　→ローカル変数優先
　関数的メソッドでも形式的にはレシーバーを持っている

・組み込み関数
　どこからでも呼び出せる便利な関数メソッド
　Kernelモジュールのメソッド

---

■７．１．４　引数展開
・ * 修飾により、配列に格納された値を引数リストに
　展開できる

・Ｒｕｂｙ１．８では、 *　付き要素は引数リストの最後
　Ｒｕｂｙｉ．９では、出現位置、回数ともフリー
　配列から引数リストへの自動的展開は行わない


・関数型メソッド
　非オブジェクト指向的に用いられるメソッド
　レシーバーを持たない手続き

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

今、

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

のお勉強をしています。

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

---

■６．６　スケジュール・コントロール

＜＜インプット＞＞

・プロジェクトマネジメント計画書

・プロジェクトスケジュール

・作業パフォーマンス情報

・組織のプロセス資産


＜＜ツールと技法＞＞
・パフォーマンス・レビュー
　　　アーンドバリューマネジメント（ＥＶＭ）採用の場合
　　　　　　スケジュール差異（７．３）
　　　　　　スケジュール効率指数（７．３）
　　　クリティカルチェーン採用（６．５）の場合
　　　　　　バッファ

・差異分析
　　　スケジュールベースライン（６．５）との差異


・プロジェクトマネジメント・ソフトウェア


・資源平準化
　　　６．５

・Ｗｈａｔ－ｉｆシナリオ分析
　　　６．５


・リードとラグの調整


・スケジュール短縮
　　　６．５

・スケジューリングツール



＜＜アウトプット＞＞

・作業パフォーマンス測定結果
　　ＷＢＳ要素、特にワーク・パッケージと
　　コントロールアカウントにて算出した
　　スケジュール差異（ＳＶ）とスケジュール効率指数（ＳＰＩ）
　　を文書化して報告


・組織のプロセス資産更新版
　　以下のものがあるが、これに限定されない
　　　・差異の原因
　　　・選択した是正措置とその選択理由
　　　・プロジェクトのスケジュールコントロールから得られるその他の教訓など

・変更要求


・プロジェクトマネジメント計画書更新版
　　以下のものがあるが、これらに限定されない
　　　・スケジュールベースライン
　　　・スケジュールマネジメント計画書
　　　・コスト・ベースライン


・プロジェクト文書更新版
　　以下のものがあるが、これらに限定されない
　　　・スケジュール・データ
　　　・プロジェクト・スケジュール

UMLなどの図に描くと、あいまいでなくなるという「あいまい」の定義って、あいまいじゃない？

「UMLに描くと、あいまいでなくなる」

って、よく聞くじゃないですか・・・え、聞かない？
じゃ、検索してみて！
「UML あいまい なくなる」でけんさくすると、

　　・あいまいでないか、
　　・あいまいさが残る

っていう表現になる。前者は、ないって言い切っているし、後者も、あいまいがないからこそ、残っている部分もあるという表現になるので、どちらも、「あいまいがなくなる」という前提で書いている。

　問題はこのとき、「あいまい」の定義は何？
　これが判らなければ、「あいまいさがなくなる」って言っても意味はない。

ここで

１とおりにしか解釈できないことである
　というのなら、ＵＭＬの意味はない。
　いきなりプログラム言語で書いてしまったほうが、曖昧さはない。コンピューターは何通りにも解釈して、恣意的に結果を出すということはないのだから・・
　Ｊａｖａとかで記述し、細かいところはダミーモジュールにして、シミュレーションしたほうが早い。


情報を網羅できる
　ＵＭＬのほうが、欠落している。ＵＭＬが出る前の業務フローのほうが、画面、帳票などの出力先が明示されるので、情報量がある。

情報が整理される
　整理という観点なら。Ｅｘｃｅｌに書いたほうが整理される。


情報が見える化できる
　ＵＭＬじゃなくっても見えるか出来るし、もし、見える化命なら、ユースケース記述なんていう、記述にたよるのは、おかしいよね！

・・・あいまいの定義が、一番あいまいな気がする・・・
なんか、あいまいという言葉をあいまいに使うことにより、
「ＵＭＬはあいまいでない」ということに信憑性を持たせているんじゃないかなあ？
（あいまいの定義があいまいだと、あいまいでないかどうかはわからない）


構造化手法より、あいまいでないことは、どのように証明できるのだろうか？
少なくても「情報を網羅できる」「情報が見える化できる」という意味では、
構造化手法より、劣るよね・・・

世界コンピュータ将棋選手権で優勝した将棋ソフト「Bonanza」の遊び方

Bonanzaは、窓の杜にある

Bonanza
http://www.forest.impress.co.jp/lib/game/puzzle/tblegame/bonanza.html

の右上にあるＤｏｗｎｌｏａｄをクリック

ＺＩＰファイルを保存して、それを解凍。
Windowsの場合、解凍したフォルダをどんどん降りていくと、
winbinというフォルダがある。
その中のフォルダにCsa.exeというのがある（歩のアイコン）ので、
ダブルクリック。

起動すると、２つのウィンドウが出る。将棋版のウィンドウのほうで、
playをクリックすると、こんなかんじに

なるので、startを選択。すると

というダイアログが出る。先手でよければ、ＯＫボタンクリック

すると、将棋のこまが適当に動かせる。
動かしたいこまをドラッグ＆ドロップ。
コンピュータが手をさすと、ぴこ！とかいうかんじの音が出る。

詰まると、なんかダイアログが出る。
playメニューの横のFileメニューにexitがあって、終わらせられる。

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

今、

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

のお勉強をしています。

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

---

■６．５　スケジュール作成

＜＜インプット＞＞

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


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


・プロジェクト・スケジュール・ネットワーク図
　　　６．２より

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


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


・アクティビティ所要時間見積もり
　　　６．４より


・プロジェクト・スコープ記述書
　　　５．２より


・組織体の環境要因


・組織のプロセス資産




＜＜ツールと技法＞＞

・スケジュール・ネットワーク分析


・クリティカル・パス法


・クリティカル・チェーン法


・資源平準化


・What-ifシナリオ分析


・リードとラグの適用


・スケジュール短縮
　　スケジュール短縮技法には、以下のものがある
　　　・クラッシング
　　　・ファスト・トラッキング


・スケジューリング・ツール



＜＜アウトプット＞＞

・プロジェクト・スケジュール
　　多くの場合、以下のような形式を使って図示する
　　　　・マイルストーン・チャート
　　　　・バー・チャート
　　　　・プロジェクト・スケジュール・ネットワーク図

・スケジュール・ベースライン


・スケジュール・データ
　　以下のものが含まれるが、これらに限定されない
　　　　・期間ごとの資源に対する要求事項
　　　　・代替スケジュール案
　　　　・コンティンジェンシー予備のスケジューリング


・プロジェクト文書更新版
　　以下のものがあるが、これらに限定されない
　　　　・アクティビティに対する要求事項
　　　　・アクティビティ属性
　　　　・カレンダー
　　　　・リスク登録簿

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

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

６章　変数と式
６．５　大域脱出
から

---

■６．５　大域脱出
・深い入れ子からの脱出
catch(:exit)
{
loop do
　　loop do
　　　　throw :exit
　　end
　end
}

・上記の例の場合、throwで書いた識別名(:exit)と同じ識別名をもつ
catchの外側にまで出る

・対応するcatchが見つからないと、ArgumentError

---

たしかに、パソコン業界は、暗黒だわ、スマホによって・・・

　ジョブスさんのアップルに対して、ＩＢＭは、こんな企業が勝ったら、パソコン業界は暗黒時代になるといっていたんだそうです。

　たしかに、アップルが時価総額トップになって、勝ったら
　世の中は、スマホの時代になって、
　パソコン業界は、暗黒時代ですね！
　見事に予測が当たっている！！さすがだ・・・

ジョブズ　日本の家電メーカーを「海岸埋め尽くす死んだ魚」
http://zasshi.news.yahoo.co.jp/article?a=20111019-00000001-pseven-int

の記事の以下の部分より
（本エントリ内の太字は上記サイトからの引用）

神と呼ばれた男、スティーブ・ジョブズ（享年56）。ジョブズがプレゼンテーションするたびに、世界の常識が変わる。彼の動向は否応なしに大きな注目を集めた。そこで発揮されるのが、彼一流の話術だ。

「製品発表の場で仮想敵をつくり、厳しく非難したりバカにしながら、アピールしたい商品を光らせます」とは経営コンサルタントでかつてアップル社で働いた経験を持つ竹内一正氏。おかげで、マイクロソフトは「趣味が悪い」と貶され、IBMも「こんな企業が勝ったら、パソコン業界は暗黒時代になる」とボロクソにいわれた。

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

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

---

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

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


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


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


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

---

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

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

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

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


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


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


といったことを行うと、


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

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

---

この方法だと、

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

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

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

---

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

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

---

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

　気が向いたら・・・