「平成２１年度春期情報処理技術者試験 案内書・願書」
２１ページ、「６－３.合格発表」の
（２）の
①ＩＰの合格証書には、得点が記載されます
（ＩＰ＝ＩＴパスポート）
これって、
受かればいいわけじゃなくって、
点数も影響するよね、就職とか、転職で・・・
ＴＯＥＩＣみたいに・・・
「平成２１年度春期情報処理技術者試験 案内書・願書」
２１ページ、「６－３.合格発表」の
（２）の
①ＩＰの合格証書には、得点が記載されます
（ＩＰ＝ＩＴパスポート）
これって、
受かればいいわけじゃなくって、
点数も影響するよね、就職とか、転職で・・・
ＴＯＥＩＣみたいに・・・
ファイル共有ソフトWinnyの作者、改めて無罪を主張
http://slashdot.jp/yro/09/01/20/1359247.shtml
で、（以下斜体は上記サイトより引用）
Winnyによる情報漏洩問題などに対応したい語っている
とあるが、そもそも、Winnyに限らず、「ファイルを共有」して、情報漏洩を防げるのであろうか？
情報を共有しようとする場合、データベースが使われる。
データベースなら、データを１事実１か所にまとめられるので、このデータベースにセキュリティをかけ、ネットワークにもセキュリティをかけて、クライアント側にデータを残さなければ、サーバーの（データベースの）データを共有でき、かつセキュリティが保てる。
これが、ファイルになってしまい、ダウンロードして、みんなが私有してしまうと、同じセキュリティをかけることは難しい。
仮にファイルを私有したとしても、（共有でなく）自分だけが占有しているのであれば、暗号化によって、対応できる。
たとえば、
・アプリケーションがファイルを保存するときは、公開鍵で暗号化
・読み込むときは、秘密鍵で復号化する
としよう。この場合、ほかの人に転送するには、
・その人の公開鍵を取得し
・相手に送ろうとするファイルを公開鍵で暗号化、保存
・相手は秘密鍵で復号化する
とすれば、意図しない第三者がファイルを入手しても、秘密鍵がない限り復号できないので（そして秘密鍵を第三者に渡すことはないから）、見られることはない。めでたしめでたし。
でも、ファイルを共有するとしたら、暗号化はできない。みんなが見えないと・・
とすると、ふつーのファイルをふつーにコピーするっていうことになる。
このばあい、もちろん、悪い人がいたら、結局機密情報は広まってしまうし、もし、悪い人じゃなくっても、自分の知らないうちに、だれかに（＝暴露ウイルス含む）情報が暴露されてしまったら、やっぱり機密情報が広まってしまう。
つまり、ＩＰＡなどが「Ｗｉｎｎｙは危ないですよ」とかいっても、会社のデータを自分のパソコンに何の暗号化も施さなければ、結局、データは暴露されてしまう。
なんたって、ＩＰＡ自体がＷｉｎｎｙの被害を受けているのだから。
本当に機密データを保護したいと考えるのであれば、ＩＰＡは、この前書いたローカルSaaSのような、アプリとデータをサーバーに集中させ、ブラウザベースで処理するか、暗号化して保存するようなアプリを推進したほうが、筋がいいと思う。
ここのスラッシュドットの記事
KDDIの法人向け携帯電話端末にバーコードスキャナ搭載モデル登場
http://slashdot.jp/mobile/09/01/21/1438240.shtml
によると（以下斜体は上記サイトより引用）
KDDIから、「防水」「衝撃から本体を守るプロテクタ」「ストレート型ボディ」「SDIOスロット搭載」「バーコードスキャナ搭載」という心惹かれるスペックの法人向け携帯電話端末「E05SH」「E06SH」が発表されました
ほお、バーコードスキャナ搭載となると、いろいろ便利そうだね・・・
と思ったけど、そんなことより、注目なのは、そのあと
同携帯はPCの .NET Frameworkのサブセット(.net by au)が含まれており、.NET Framework使用のアプリケーションに限り、BREWアプリケーションに必要なKDDIの検証が不要になるとのこと。
ま、まじっすかああ・・・（＾＾）
とおもって、
.net by au
http://www.kddi.com/business/neton/index.html
のページ見たけど・・・
うん、ＢＲＥＷとは、ちがうの？.NET Frameworkっていうことは・・・
（フォームは.NET Frameworkの作り方と同じになるの？）
KDDIが.NET対応の携帯電話、アプリ開発期間を数分の1に
http://itpro.nikkeibp.co.jp/article/NEWS/20090121/323169/?bzb_pt=0
をみると、Ｃ＃で開発できるって言うことは、ＢＲＥＷとは、大違いだね！
ただ、GPSは使えるのかとか、カメラはどうなるのか？とか
疑問点もいっぱい。
このへん、EZ Factoryで今後説明あるのかなあ・・・
きょうみしんしん
システム開発は、要求分析→外部設計→詳細設計→プログラミング→単体テスト→結合テスト→総合テストという工程で進んでいく。
このとき、ウォーターフォール開発では、その工程が終わり、次の工程に行ったら、その工程あるいはその前の工程には絶対に戻らない。また、工程によって担当者が違うこともありえる（要求分析は上級ＳＥ，プログラミングはプログラマなど）
ここで、ビジネスモデルは、要求分析の機能要求を出してくるところで決定する。一方、実装は、外部設計からはじまり、プログラミングで実装する。
昨今、コンピューター技術が進むにつれて、さまざまなデバイスが現れてきた（ケータイなど）。しかし、これらのデバイスはすべての機能が使えるわけでなく、制約がある。その制約はプログラマしか知らないことも多い（ＢＲＥＷにおけるＨＴＭＬ表示など）。
ということは、外部設計からプログラミングまでの段階で、実装上無理！ということが分かったり、 結合テストでパフォーマンスが出ない！ということも考えられる。
こうなると、方法を変えるしかない・・・が、それはビジネスモデルを変えることであり、ウォーターフォールでは、行ってはいけないことになる。
では、要求仕様のときに、そういう問題をつぶせばいいということになるが、ウォーターフォールでは上述のように、担当者が変わることも許される。このとき、要求分析は上級ＳＥが担当することになるが、それら上級ＳＥがＢＲＥＷの制約といった、ＣやＣ＋＋の実装を知っているとは限らない（というより、知らないのがふつう）。
つまり、実装上の問題が起きた時、それに伴うビジネスモデルの変更が出来ないウォーターフローは、破綻してしまう。
具体例を１つ。
ある会社では
営業所１０箇所＝受注を行う
物流センター１箇所＝出荷を行う
であったとする。現在は
１．営業所が受注したら、
注文請書、出庫指図書、納品書、受領書
の４枚カーボンコピーした伝票を記入
２．営業所では受注の確認、承認をした後、
注文請書をはずし、発注者へ送った後、
のこりの伝票を物流センターに送る
３．物流センターでは、センター長が、出庫指図書の内容を元に、
出庫担当者に指示を出す
４．出庫担当者はピッキング、出庫指図書をはずして残りの伝票を
出庫する箱に貼り付け、出庫する
という流れだとする。
一般に、このシステムをコンピュータ化し、リードタイムを減らそうとする場合、
１．営業所が受注したら、受注入力し、
注文請書を出力
２．営業所では受注の確認、承認をした後、
注文請書を、発注者へ送る
３．物流センターとネットワークでつながっているため、
センター長が、即座に受注内容から、出庫指示を出し
出庫担当者に指示を出す
４．出庫担当者は出庫指示画面をみてピッキング、
納品書、受領書を出庫する箱に貼り付け、出庫する
こうすると、
・受注から即座に出庫までいける
・在庫状況が把握できる
・出庫指図書がデジタル化され、紙をださなくてすむ
ので、この方法がいいように思えて、設計、実装に行く。
しかし、この方法は、危険である。
営業所１０箇所の注文を、１つの物流センターで帳票印刷することになる。
仮に、営業所が２時間かけて印刷するとしたら、２時間Ｘ１０＝２０時間
印刷していなければならず、印刷処理のために、出庫がとまる。
もちろん、プリンターを多数用意すればいいが、そうすると、費用がかさむ。
無難なのは、いままで、営業所から伝票が来ていたのだから、その流れは崩さず、
営業所で受注入力してプリントアウトすることだが、それは、ビジネスフローが
変わるので、ウォーターフォールでは許されない上、そもそも、
・受注から即座に出庫までいける
・出庫指図書がデジタル化され、紙をださなくてすむ
の目標は何一つ達成しない。ここでの効果を期待して予算をとってしまった場合、費用分の効果は出ず、まったくの失敗ということになる。
では、アジャイルならどうなるか。
１、まず、受注部分を開発し、プリンタから出るようにする
→ここで、印刷に何時間くらいかかるか検証する
２．物流センター側にデータを転送し、出庫入力システムを
作成する
→ここで、在庫確認できるかどうか検証する
３．最後に、出庫指図書のペーパーレス化を考える。
このように部分的に投資していけば、問題があるところで変更・開発中止
できるので、ウォーターフォールのように、大失敗することは少ない。
１０年以上前、とくにＣＯＢＯＬ全盛のときには、
１．上級ＳＥも、どのような感じで実装できるか、概略をつかんでいたし
２．そもそも、入出力が限られていたので、まずそこで問題は起こらなかった
なので、ウォーターフォールでも、実装した時に急に問題になることはなかった。
しかし、現在のように、コンピューター技術が発展し、実装してみないと、どうなるかわからない。知っている人はプログラマーだけ・・・という状況で、ビジネスフローを決めてしまうのは危険だし、さらに、コンピューター技術のメリットも出し切れない（こういうデバイスがあるから、こういうフローにしようというのは、ありえる）
ということで、
ウォーターフォール型開発は、コンピューター技術が発展すると破綻する・・はず（＾＾；）
前々から書いているi*法についてですが、「ゴール指向による!!システム要求管理技法」の１３３ページ、「４．２ i*フレームワーク」の章に、書き方やサンプルがあります。
また、情報処理学会から毎月くる、雑誌「情報処理」の２００８年４月号、「特集 要求工学」の３７４ページから、i*フレームワークとして記載があり、３７５ページの「図３ i*SDモデルの例」が書き方の例です。
アクセス
トータル
ランキング
