画面は業務系とマスタ系に別れ、マスタ系は１エンティティ１テーブル２画面が基本 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ＥＲ図、アクティビティ図、画面との関係、たとえば、発注者ビューガイドラインの「データモデル編」、「システム振る舞い編」、「画面編」の関係について考える ■業務系とマスタ系 画面（を含めた入出力）は、大きく２つに分かれる。 業務（トランザクション）系 と マスタ系 業務系は、発注者ビューガイドラインの「システム振る舞い編」で記載されるような、「業務流れ図」で、処理内容とその入出力（＝画面を含む）が記載される。 そこで、業務系の画面は、「業務流れ図」を見るとわかる。 一方、業務で、すべてのデータが作成・編集・削除できるわけではない。 業務以前にデータが存在していることもある。 このデータの作成・編集・削除もしなければならない。 これが、マスタ系となる。 したがって、マスタ系は、データ
発注者ビューガイドラインに沿って開発すれば、システムは開発できるって、誰か証明した？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日、発注者ビューガイドラインとＳｔｒｕｔｓのプログラムについて書いたので、一言 業界で、外部仕様について共通化する？ということで、発注者ビューガイドラインというのができた。 ところが、この発注者ビューガイドライン、はじめは、外部仕様についてまとめていたはずなのに、発注者ビューガイドラインの活用と拡張 ～機能要件の合意形成を目指して～において、１６ページで、「(2)要件定義工程における活用」っていう話で、 いやいや、要求仕様の機能要件に使えるねということになってきて、 じゃあ、あとは、非機能要件をきめれば・・・ということで 非機能要求グレード検討会が非機能要件を標準化？しようとしているが、 ちょっとまて、これ、もし、 発注者ビューガイドラインと、要件仕様の機能要件との間に不整合や
ジャストシステムの社長交代に思う、日本のソフト流通 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ほんとーだあー、ジャストの社長、代表権のない会長に退いてますね http://www.justsystems.com/jp/just/finance/j0906181.pdf（PDF) この件に関して、ここ（2009年6月20日）に（たぶん）パッケージ会社関連で「ない」先生からのコメントがあるけど、パッケージ会社の人は、きっと違った見方をするだろうから、ま、その呼び水ということで、パッケージ会社にいた、ウィリアムのいたずら様が、独断と偏見で、ちょっとコメントさせていただきますかね・・・ まず、日本では、一般の価格帯（３万円以下）で、パッケージだけでは、ソフトウエア業は成立しません。 そのからくりについて。 小売価格の６割を、開発会社が受け取るとして、３万円なら、１万８千円。 １万
ＤＩやstrutsのメリットの１つは、定義ファイルを見れば、システム全体がわかるということ？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ＤＩやStrutsなどのメリットは、定義ファイル（Strutsだとstruts-config.xml)を見れば、だいたい、どんな風な感じかというのが、つかめるところのような気がしてきた。 たとえばＪＳＰだけで書いてしまうと、どういう画面遷移になるかは、ファイルの中を見ないとわからない。 一方Ｓｔｒｕｔｓは、ソースファイルの中を見なくても、struts-config.xmlのActionと、その中のForward,FormBeanから、画面の動きが大体想像つく（きれいになってれば）。 そーいった、ソースをいろいろみなくても、大体把握できるところが、いいところなんじゃないかと・・・
「テレビ界、下請けいじめ是正へ 番組買いたたき禁止など」だって。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ここの記事 テレビ界、下請けいじめ是正へ 番組買いたたき禁止など http://www.asahi.com/national/update/0221/TKY200902210212.html （以下斜体は上記サイトより引用） テレビ業界が、番組作りを発注する制作会社への「下請けいじめ」をなくそうと、総務省と自主ルールをまとめた。契約書もかわさずに発注し、金額を一方的に下げることが珍しくない現状を改める狙いだ。制作会社の著作権も尊重する。ＮＨＫと地上波テレビ放送を手がける１２０社余りの全民放を対象に、３月中に実施する。 テレビ局には、影響あるのかな？ テレビ番組のクオリティはあがるのかな？ （これでクオリティ下がって→視聴率下がって→収入下がったら、 テレビ局は、どーするんだろう？
トヨタ、日産よりＮＨＫ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ＮＨＫの 沸騰都市 第６回 サンパウロ 富豪は空を飛ぶ http://www.nhk.or.jp/special/onair/090201.html は、秀逸であった。 どこが、秀逸かというと、 １．一時、トヨタがちやほやされて、カイゼンとかいいつつ、今はこのていたらく、 ってことで、だれも見向きもしなくなった自動車産業に対して、 復活のシナリオを明確に示した。 ２．この不況は、単なる不況でない。革命なのだが、その革命という言葉を出演者 にいわせ、どういう革命が起こっているのか、を明確に示した ３．農業をきっかけに、アフリカなど、発展途上国、後進国が一躍世界の中心に踊り出る ことは、ウィリアムのいたずらでも予測できたが、具体的に、それが、どういう展開 で、アフリカのような後進国が
クラウドに行く前に、まず社内サーバーにデータ・プログラムを集中化かな。とするとＩＰＡが。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前に、所有と共有、クラウドとユビキタスの関係などを書いたけど、サーバーとクライアントの分離の究極の形がクラウドとユビキタスだとすると、その前に、まずは、社内や事業所、部署において、とりあえず、データにしろ、プログラムにしろ、社内サーバーに集中し、個人的なプログラム・ファイルは、持たないようにしましょうよ！っていうことからでしょうね。 そして次のステップとして、この前書いたローカルＳａａＳのような、社内、事業所にデータをおいたＳａａＳのようなサービス（ＣＲＭとか＝ＳｕｇａｒＣＲＭを社内サーバーにインストールした感じ）になっていき、 さらに、「じゃ、べつに社内になくってもいいんじゃない？」という感じで、社外のＳａａＳ，ＡＳＰを利用したり、ファイルをデジタルトランクにおいたり、メールは
ウォーターフォール型開発は、コンピューター技術が発展すると破綻する・・はず（＾＾；） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） システム開発は、要求分析→外部設計→詳細設計→プログラミング→単体テスト→結合テスト→総合テストという工程で進んでいく。 このとき、ウォーターフォール開発では、その工程が終わり、次の工程に行ったら、その工程あるいはその前の工程には絶対に戻らない。また、工程によって担当者が違うこともありえる（要求分析は上級ＳＥ，プログラミングはプログラマなど） ここで、ビジネスモデルは、要求分析の機能要求を出してくるところで決定する。一方、実装は、外部設計からはじまり、プログラミングで実装する。 昨今、コンピューター技術が進むにつれて、さまざまなデバイスが現れてきた（ケータイなど）。しかし、これらのデバイスはすべての機能が使えるわけでなく、制約がある。その制約はプログラマしか知らないことも多い（Ｂ
非機能要件の開発体系 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで、 非機能要件が体系的になっていない、行き当たりばったりでは、本当にその期間や予算で実装できるかどうかわかりません。 現在の機能要件重視の考え方は、プロジェクト失敗の要因を内在しているといえそうです。 と書いた以上は、非機能要件の体系化をしないといけません。 というわけで、考えてみました。 ■非機能要件における開発手順 （１）まず、非機能要件を、形容詞、副詞、数詞などを使って出す。 この段階では、「早く」とか、「美しく」とかであって、「Linuxで」とか「ブラウザで」とかは、とりあえず置いておく。その次の段階で出てくる （１）’ユーザーのシナリオとかでもいい ペルソナとか。っていうか、そういうののほうがいいのかな・・・ （２）その要件を実現する技術を検討する 「使いや
現在の機能要件重視の考え方は、プロジェクト失敗の要因を内在している - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 前のブログで、「機能要件中心の現在の開発手法は、もう一度レビューしたほうがいいことになる。今度、そのレビューについて書いてみたいと思います」と書いたので、従来の機能仕様中心の開発方法を書いてみたいと思います。 ざっとこんなかんじ？ つまり、要求段階では、業務内容を機能要件としてまとめ、非機能要件は、その際の条件としてまとめると思います。 このとき、「どのくらいの量」とか「どのくらいの正確さ」といった、形容詞、副詞的な要素のほか、「Linuxで」とか「Javaで」といった、環境などに関することも一緒にまとめてしまうと思います。 そして外部設計の段階で、画面設計など、ユーザーインターフェース関連をきめ、さらに、要求仕様が終わった段階で詳細化とかフレームワークの決定などをすると思います
バザール型ＥＡ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 従来のＥＡっていうのは、会社全体のシステムを調査し(to-be)、そしてあるべき姿を分析する(as-if)という形式だった。つまり、全体像を描き挙げ、それを、ブレークダウンし、実装していくという、 伽藍とバザール http://cruel.org/freeware/cathedral.html で言えば、伽藍型の開発方法といえる。 では、バザール型の開発方法はないのか？ つまり、会社の機能を部分部分につくっていき、それをつなぎ合わせる手法 ・・・って、まさにＳＯＡである（＾＾；） でも、その場合、各部分で利用するデータの関連をとるには、どーしたらいいだろう？ 従来（伽藍型）は、会社全体を考え、そこからデータの全体構造、関連を正規化手法にしてＥＲ図などで表現し、１事実１箇所、データ
サーバー側はＲＥＳＴでＤＢ操作だけとなると、ツール化できてしまうんだよね！ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） で、昨日の問題。 ソフト開発は、必要工数＝0.1×ファイル数＋1.3×画面数＋0.3×バッチ数なので、 ・画面開発者の単価を減らし ・画面と操作部分を完璧に分離し、操作部分をバッチに落とし込めば 価格は安くなることになる。 このとき サーバー クライアント ・ＧＥＴまたはＰＯＳＴで引数を受け取り セッションの引数とあわせて（共通関数で） ・画面操作、処理をflashで行い ・ＤＢ操作処理 ←→ ・サーバーをflashから呼び出し、 ・結果をセッションに入れたり ・受け取ったＸＭＬをもとに ＸＭＬで返す（共通関数にセット） 画面表示させる とすると、クライアント側はＦｌａｓｈ処理のみとな
修正可能なシステム 番外編１ 出来る開発と出来ない開発の違い - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ここで 「その体系から見ると、できる開発と出来ない開発がみえてくる」というのは、修正可能なシステムでかきます と書いたので、「修正可能なシステム」の番外編として、その「出来る開発と出来ない開発の違い」を書きたいと思います（なお、番外編１の１は、べつに、２、３と予定しているわけでなく、もし今後出てきたら、１、２と続けようと思っているだけです） ■情報処理の体系 まず、「その体系から見ると」の「その体系」から説明します。 それについては、情報処理試験ぐらいのお勉強のポイントの体系化の「理論の階層と細分化」に書いた、 これは、情報処理という概念の２つの側面をあらわす。 情報処理とは、情報（データ）を、処理（プロセスを動かす、プロセッシング）することといえる。 ってことに関連する。 つま
修正可能なシステム その２ 背景－修正のジレンマ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズ化してしまった？修正可能なシステム。 前回は、概要として、何をやるかについて書きました。 本来なら、その説明をするべきですが、その前に、どこが問題で、このような手順になっているのか？という背景の話をします。 ■データに関する修正をかける場合 問題は、データ構造に対して、削除、あるいは意味が変わったり、型が変わったりする修正で起こります。 （価格を、整数から実数へ、文字２バイトを１バイト、有効期間項目をなくすなど・・） この場合、修正後のプログラムを作るには、まず、データの構造を修正しないといけません。 とくに、データ構造に追加がある場合、追加しないと、プログラムが作れないので、追加します。そうすると、同時に項目を変えないといけない場合（つじつまが合わなくなるので）、削除や
アジャイルで不幸にした業界、法令工学を応用することで、幸せになれれば。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） いいけどね！ せっかくコメント無視、匿名で書いているんだから、 もっと、世間から、反発されるけど、大事なことを、たまには、書いてみたいと思う。 最近、IT業界って、暗いとおもいませんか？ 村上企画官のおことばを待つこともなく、７Kとか１０Kとか、まったくもって、暗い、イメージの悪い業界になってしまったと思います。 こうなった原因の多くは、アジャイルという名のもとに行われる、仕様の五月雨式変更にあるとおもいます。 ウォーターフォールだった、８０年代後半、９０年代前半は、後工程で仕様変更が原則できないため、どの仕様変更を（例外的に）あえてするか、それをした場合にどれほどのインパクトがあるかを計算してから、行われました。つまり、要求仕様が管理されていました。 さらに、テストに関しても、
理系でIT業界は暗い・・・というのを、就職活動資料サイトから、論破してみる。。。 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） It Job Gate http://itjobgate.jisa.or.jp/index.html という、サイトがあるんだそうです。 このサイト（以下斜体は上記サイトより引用） 「It Job Gate」は、社団法人情報サービス産業協会（Japan Information Technology Services Industry Association：JISA）の会員企業の新卒採用情報を集めた就職サイトです。 なんだそうですけど・・ このサイトを見ると・・・ 理系でIT業界は暗い・・・ と思ってしまいます。 ここ 過去最大。売上を伸ばしている情報サービス産業。 http://itjobgate.jisa.or.jp/trend/index.html の図表１。 たしかに、売
クロスサイト”プリンティング”の応用－Webからローカルにファイルを書き出す - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日のクロスサイト”プリンティング”のテクニック、本当ならWebアプリの世界が広がる気が。。で、調べてみるね！と書いたこと報告。 たしかに、IEで、Formタグに書いた内容とファイル名で、ローカルにファイルを書き出せました （もちろん、セキュリティレベルを一切変えずに！です）。 その方法と、コードを説明しますね。 ■方法の概要 ・ローカルに、Socketサーバーで、ポート５０５０番で、以下の機能を持った サービスを立ち上げる ・POST形式で受け取った内容をもとに、引数 fnameで指定されたファイル名で、 fdataの内容を書き出す ・フォームタグでmethod=POST action="http://127.0.0.1:5050" を指定、 このフォームタグ内に、fname、
２００８年のテンサプライズ（IT版）予想解説（６）ソフト業界でトヨタ方式は無理 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズウィリアムのいたずら選定 ２００８年のテンサプライズ（IT版）、今回は５つめの解説です。 それは ６．トヨタの闇が多くの人に読まれる →トヨタを持ち上げていたプロジェクトマネージャーの知的センスが、部下に 疑問視され、マネージャーとしての権威が失墜する →あらたなマネージメント論を模索することになるが、自分で理論を生み出せない マネージャーは、見放される です。 トヨタの闇という本があるそうです。 この本の内容はともかく、そろそろ、「トヨタ方式まんせー」と言っていた、プロジェクトマネージャーたちが、血祭りに上がってもいいころだろう。 たしか、トヨタ方式では、なぜ、なぜ？と５回問うのではなかったっけ？ では、問おう。 トヨタではなぜできることが、自分たちの会社では、できない
失われた２０年－ソフト業界は変わったのか？ その１８：２０００年ごろ（３）開発方法論 - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第１８回目。今回は、開発方法論。 ■従来の開発方法論 情報処理試験のテキスト「第一種共通テキスト １５応用システム開発技術」（ISBN 4-89078-452-7）にあるような、要求仕様、外部設計、内部詳細設計、プログラミング、テストのウォーターフォール型の開発の流れは、２０００年ごろには確立していました。で、共通フレームSLCP-JCF98が、１９９８年に規定され、この手の開発の流れで、Cでやる開発は、まあ、安定してきました。 現在も、制御系などでは、この流れのようです（最近UMLもありだけど
失われた２０年－ソフト業界は変わったのか？ その１２：１９９５年ごろ（５） - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ２０年位前、１９８０年代終わりごろから、最近まで、ソフト業界とかその周辺の変遷について、特にソフト開発の立場を中心に見て行く、土日シリーズ「失われた２０年－ソフト業界は変わったのか？」その第１２回目。 今、１９９５～９９年までについてです。今回は、そのころの開発方法論、その２ 構造化分析やDFDについてです。 ■情報関連図からDFDに １９８０年代から、９０年代のはじめころまで、COBOLベースの開発のころは、要求仕様レベルで、機能を書くとき、情報関連図（FIO図っていうのと同じかな？）で書いてました。機能があって、入力、出力を書くものです。 で、これをもっと、機能とデータをはっきり分け、他人でも検証可能な形にしたDFD（データフローダイアグラム）が盛んにつかわれるようになります
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
