ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

Vista普及率、23%

2009-05-08 22:43:08 | Weblog

ここのニュース
Vista普及率が23%に 1年半で17%増も主流はやはりXP
http://headlines.yahoo.co.jp/hl?a=20090508-00000011-zdn_ep-sci


ここまで売れないWindowsってのも、すごいよね(^^;)



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

デジタルMCA VS ケータイ(運行管理とデジタルサイネージ)

2009-05-08 17:53:55 | Weblog

 ケータイと無線のせめぎあいみたいな話をこの前書いたけど、どーもMCA VS ケータイの世界では、まさに勃発している?ようだ。
 この前は簡易無線のデジタル化について書いたけど、MCAもデジタル化されていて、バスの運行に利用されているようだ。

 バスの運行管理は、デジタルMCAを使っているらしい(日本電気)
No.250 都営バスの運行情報システム
http://www.f-banchan.net/tokyo/tobussys/tobussys.htm


 もちろん、この分野、KDDIのGPSMAPによる運行管理の分野と、もろバッティングする。

KDDIの通信モジュールを搭載した除排雪車両運行管理システムを開発
http://www.kddi.com/corporate/news_release/2006/0222/index.html


ただ、この技術って、いままで、車両→指令局の流れ中心で考えてたけど、逆に指令局→車両っていう流れも実現できるはずで、そーなってくると、一斉配信できる、デジタルMCA、ケータイ以上に(ま、ケータイでもできるんだけど)面白いことできるんじゃないか。




 デジタルMCAでは、車両(移動局)から、指令局(会社側)に対して、画像を送ることもできるようだ。
画像伝送装置「DARWIN(ダーウィン)システム」
http://www.mrc.or.jp/top/application/post.html#more


じゃ、逆向きに、会社からバスやタクシー、駅にデジタルMCAを使って、広告の画像などを配信し、
バスやタクシー、駅では、その画像をデジタルサイネージ(=山手線のトレインチャンネルのようなCM)として表示する

ってこともできるんじゃないか?

 まあ、MCAで送れる量の問題もあるけど、デジタルサイネージは”ぱたぱたアニメ”っぽくてもいいので、何回かに分けておくると、いっせいにデジタルサイネージの画像(=CM)を送れる。
 そうすると、MCAを使ったデジタルサイネージによるCM、それによる、バスやタクシーの広告収入の増加などが考えられそうだ。




 てなわけで、MCA VS ケータイは、さらに、デジタルサイネージとか、あらたな市場でさらに起こってくるような気がする。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

アジャイルとウォーターホールの位置づけと限界を30年前に指摘したLehmanって、すげー!

2009-05-08 02:22:06 | Weblog

M.M.Lehman(りーまん?)という人がいるそうだ。
 この人が、
Programs, life cycles, and laws of software evolutionという論文を書いているそうなのだが、そこで、S-ProgramとE-Programというのを議論しているそうだ。

S-Programは、ちゃんとした仕様書があるもの
E-Programは、仕様が現実を組みこんでしまっているため、現実が変化すると、
      仕様も変化しちゃうというものらしい。

論文を直接読んだわけではなく、ある人から聞いた話を自分で理解した範囲なので、まちがってるかもしれないけど、ま、そーだそーな。。。




おお、この考えはすごいっす!

仕様がはっきりしているかどうかで、開発方法論をわけてしまうと、

S-Programは、仕様がはっきりしているのであるから、ウォーターフォールが向いていて、
(仕様が柔軟でないなら、柔軟に開発できるアジャイルをわざわざ使うことはない)
自動化やソフトウエアファクトリー的な開発も考えられる。
(ソフトウエア「ファクトリー」の場合、工場ラインを途中で変えると面倒なように、
 ソフトウエアファクトリーも画一的な開発手法である程度のスケールでやらないと、
 メリットがでにくい)

一方
E-Programは、仕様が現実にともなって変化してしまうなら、これは
アジャイルがむいている。俊敏性によって、現実の変化に追いついて
いけるからという意味もあるけど、それ以前に、ウォーターフォール
のように逆戻りしない場合、変化されてしまっては困る。
 そして、現実が変化する場合、お互いの現状の意思を確認することは
重要で、その意味でテストファーストにして、結果の確認をしたり、
プロトタイプ、モックアップを作成し、共通認識を得ることは、意義深い。




つまり、Lehmanは仕様がどれだけ決まっているかによって、S-Programと
E-Programにわけているけど、それは、今現在の時点で考えると、この違いが
まさにウォーターフォールとアジャイルの2つの開発方法論に対応していて、
このLehmanの視点によって、かなりの開発や周辺事項が整理され、不要な
(不毛な?)議論をしなくて済むようになる。

これを約30年前にだした、Lehman、すごすぎです。。。


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする