ＰＤＣＡサイクルとＰＤＳサイクルの違い

ちょっと気になったというか、後の話で使うかもしれないので。。
自分のメモ的には、リンクだけでいいんだけど、少し説明。

ＰＤＳとＰＤＣＡの違いは、
ここ　http://www.technofer.co.jp/FAQ/FAQ9001_070.html
の受講生がもろきいているけど、もともと、ＰＤＳサイクルというのがあって、
それを品質管理のほうで、ＳをＣ（チェック）とＡ（Ａｃｔ）にわけた。

　なお、そこには、はっきりかいてないけど、ＰＤＣＡというのが出てくるのは、
ここhttp://www.atmarkit.co.jp/aig/04biz/pdca.html
によると、W・A・シュハートといっている。（デミングはＰＤＳＡとしている）

　ＳをＣとＡにわけたということは、ＡにおけるActが、以下のような性格を
もつことになる。

　Ａは、初めに立てたＰの範囲内において、それを継続するか、破棄するか、カイゼンするかを決定し、行動するものである。つまり、Ｐの範囲でのカイゼンの行動をとる。

　一方ＰＤＳサイクルにおいて、Ｓで評価した結果、新しいＰをたてるときは、ＰＤＣＡのあらたなＰ同様、以前のＰＤＣＡの結果に影響は受けるものの、新しいＰであるから、自由に建てられる（ＰＤＣＡのＡのように、はじめのＰの範囲に対しての反応ではなく、それをにらみながらも、あらたなＰを自由にたてることができる）。

　ＰＤＣＡサイクルのＡの意味に関しては、
　ここ　http://jikan.livedoor.biz/archives/50904625.html
　そこによると、
Act ： take actions to continually improve process performance.
だそうな。。

LAOXのThe Computer館の中が昔と違ってた

　今日、ひさびさに、LAOXのThe Computer館（秋葉原）にいったら、
　なんか、昔と違ってて、３階のソフトのコーナーが５階にいってて、
３階がよくわかんない（＾＾；）コーナーになっていた。

　で、The Computer館の周りも変わってて、工事してたし。。。

　秋葉原に、ちょっといかないと、大きく変わってしまうようだ。。
　最近は。。

楽天のオークションが、たたかれてるね

ここ
被害者が告発「楽天オークションはトラブル続きの最悪サイトです」
http://www.mynewsjapan.com/kobetsu.jsp?sn=562

ほー、ウィリアムのいたずらは、
オークションはやってないので、
あんまり関係ないけど。。。
うーん、なんかいろいろありそうな気配？？

でも、このネタ、本家（楽天日記にあります）では、
絶対かけないネタだ（＾＾；）

業務のまとめからＤＦＤへの変換方法

　最近、業務をまとめたシートと、入出力についてまとめたシートをつかって、DOA,オブジェクト指向の各種の図やシナリオ、テストデータやプログラムに展開する話を書いています。

　今回はＤＦＤ（データフローダイアグラム）について書きます。

---

■まず、ＤＦＤとは、なにか？

　ＤＦＤ（データフローダイアグラム）は、デマルコによって提唱されたもので、
構造化分析とシステム仕様という本に詳しく書かれています（この本自体は、古典として有名）。

　で、この図は、国のＥＡでも「機能情報関連図」として、描くものになっています。
　実際、そのサンプルが、ＥＡのページの
機能情報関連図（DFD）：現状モデルの策定
http://www.meti.go.jp/policy/it_policy/ea/gainen/product/dfd/1.html
にあります。

　そこの下のほうにある図がＤＦＤ（のサンプル）です。

　ちなみに、システム全体と、外部とのやり取りを書いた、最上位のＤＦＤを、コンテキストダイアグラムといいます。そして、ＤＦＤの終わりは、１枚の紙で機能を文章化できるくらいのレベルまで落とし込むとされます。この「１枚の紙で機能を文章化」されたものが、ミニスペックといいます。

で、結局、ＤＦＤは、なにを書くのか？っていうことになると、
ここ　http://www.meti.go.jp/policy/it_policy/ea/gainen/product/dfd/5.html

にあるように、こんな種類のものを書きます（上記のデマルコの本の６９ページ）。

データ源泉／データ吸収
　四角の図形で描かれているものです。外部からのデータ入力がデータ源泉、外部へのデータ出力が、データ吸収になります。

プロセス
　楕円で書いているものです

ファイル
　二重線の中に文字を書いているものです。実際にはファイルだけでなく、ＤＢも入ります。
　永続性のあるデータってことです。

データフロー
　矢印の線です。

---

■業務をまとめたシートからＤＦＤを書くには？

　では、以前書いた、業務をまとめたシートからＤＦＤをかく方法についてです。
　ここでは、とくに、受注を例にかんがえます。

（１）これから描こうとする業務のシートをあけて、内容の子アクティビティをチェック
　　　受注シートをあけて、子アクティビティをチェック、この子アクティビティが、
　　　プロセスとしてかかれます。

（２）子アクティビティは、プロセスですので、てきとーに楕円を書いて、
　　　そこに、子アクティビティ名をいれて、プロセスの表記をしてください。
　　　たとえば、受注の子アクティビティに、受注受付、受注票作成、とあったら、
　　　受注受付のプロセスと、受注票作成のプロセスを書きます。

（３）（２）の子アクティビティのシートをひらいて、それぞれについて
　　　入出力のところをみてください。

　　　このの入力のうち、ファイルは、ファイル名.項目名となっているはずです。
　　　ＤＢは、テーブル名.項目名となっているはずです。

　　　このうち、ファイル名の部分、テーブル名の部分を取り出し、
　　　　　もし、まだ図にかかれていなかったら、
　　　　　　　ファイルの二重線を描いて、
　　　　　　　そこにファイル名（テーブル名）をかいて、
　　　　　　　矢印の線（データフロー）を書きます（プロセス側に矢印がくる）
　　　　　図に描かれていたら、
　　　　　　　書かれているファイルのところから
　　　　　　　矢印の線（データフロー）を書きます（プロセス側に矢印がくる）

　　　出力も同様に、出力のところをみて、ファイル名を書いたり、データフローの
　　　矢印を書きます（ファイル側に矢印がきます。つまり、矢印の方向が逆です）

　　　もし、データフローにデータ項目を書く場合は、上記入出力のところの
　　　テーブル名.項目名の、項目名のほうを書いてください。

　　　上記の例だと、まず、「受注受付」の入出力をみて、入力に書かれているものの、
　　　ファイル名、テーブル名を取り出して、ファイルとして書き、データフローを
　　　いれます。項目名も必要なら、データフローに書いてください。
　　　　出力も同じことをします。
　　　そのあと、「受注票作成」もみて、同じことをします。
　
（４）上記の入出力の入力のうち、ファイル入力以外の入力、つまり、画面入力は、
　　　データ源泉にあたります。

　　　　その画面を入力する「人」など（画面自体ではありません。ちゃんと、
　　　画面表示のアクティビティを書いていれば、その担当者にあたります）について、
　　　四角形を書いて、データ源泉として、矢印を書きます
　　　（プロセス側に矢印がきます）

　　　入出力の出力のうち、ファイル以外、つまり、画面出力と帳票出力は、
　　　データ吸収にあたります。
　　　　その画面や帳票を見る「人」など（画面・帳票自体ではありません。ちゃんと、
　　　画面出力のアクティビティを書いていれば、その担当者にあたります）について、
　　　四角形を書いて、データ吸収として、矢印を書きます
　　　（四角形の吸収側に矢印がきます）

　　　なお、項目名を書く場合、画面名、帳票名でＯＫの場合、項目まで書く場合、
　　　いろいろあります。

　　　先ほどの例だと、「受注受付」では、受注受付画面がこれにあたります。
　　　この受注受付画面を入力する人（受注係の場合、お客様の場合と、考えられるが
　　　実際に入力する人）を四角をかいて、データ源泉とする。

　　　「受注票作成」では受注票を見る人（１人、１部署だけとは限らない）を、
　　　データ吸収として、四角をかいて、そのあと、データフローを書く。

（５）「後のアクティビティ」のところをみて、あとのアクティビティに、データフロー
　　　を書く（１つとは限らない）後のアクティビティ（プロセス）のほうに矢印が来る

　　　先ほどの例だと、「受注受付」の「後のアクティビティ」に、「受注票作成」
　　　と書いてあると思うので、「受注受付」から「受注票作成」にむけて矢印を
　　　書く。

---

大体こんな感じでできると思います。

では、次は、また違う図で。。

いまの、若いひとは、「ワープロ専用機って見たことない」そうだ。。

Impress Watchの萌えニュースで、１０年前のニュースというのを
やってます。
出演は、 村井真里さんと、中畠綾香さん、
やっぱ、この２人っすよねー（＾＾）

っていうのは、さておき、この中で、
「ワープロって、パソコンでやるんじゃないの？」
「ワープロ専用機って見たことない」
っていうようなこといってるくだりがでてくる。。。

がーん。。。そー言う世代なのか（＠＿＠！）

ひえー。。。。

そんな世代では、きっと、「松」や「桐」っていっても、木の名前だろう。。
「一太郎」はまだしも、三四郎。。は、柔道の人？
「五郎」は、野口五郎？？いやいや、野口五郎も、あやしいよねえ。。。

　意外と、のむらのよっちゃんとかも、「あ、あゆのバックバンドの人？」っていわれそうだし、近藤真彦は、「車関係の人？」っていわれそうだし、田原俊彦は、「あ、最近株で３５００万もうけた人？」とかいわれ。。。って、それはないって（＾＾；）

Ｐ．Ｓ　そーやって、みんな変わっていく中で、この前、テレビショッピングのカラオケの紹介で、「あずさ２号」を歌っていた「狩人」は、ある意味偉大だ。。

ウォーターフォールとスパイラルモデルの問題点とインクリメンタルモデル

ちょっと自分に対するメモみたいなもん。
開発方法論のウォーターフォールとスパイラルモデルの問題と、
おとしどころとしてのインクリメンタルモデル

---

■ウォーターフォールモデル＝途中の仕様変更の問題、間違えると大変
　ウォーターフォールモデルは、開発をいくつかのフェーズ（要求分析、外部設計、内部（詳細）設計、プログラム、単体テスト、結合テスト、総合テスト（システムテスト、運用テスト）に分け、それぞれのフェーズを完了してから、次のフェースにうつる。

　いわゆるＶ字型開発というものになる

　この開発は、１フェーズが長く、先が見えにくい上、数年もかかるプロジェクト
の場合、途中で仕様変更ができないので、時代遅れのシステムになるという問題もあるが、それ以上に、大きくなった場合、上流工程で間違いがあると、下流工程で総崩れになる危険がある。

　たとえば、ユーザーインターフェースで、カーソル移動をいろいろできるように
設計していたが、実は、その画面ツールでは、クライアント側の入力に応じてカーソルを移動するという仕組みはなかった。
　などというとき。。。

　プログラミングするときに気づいたなどとなると、外部設計まで戻らないといけない。

　ここまでのミスは、まずないが、仕様の取り違えや矛盾が、かなり下流になって
からくるということはある。

　仕様変更が多く、オープンシステムになって、作ってみないと、どういう制約があるかわからないという昨今は、そのため、スパイラルモデルを検討されるようになった

---

■スパイラルモデル＝ループ、逆スパイラルに陥る危険性
（ここで言っているスパイラルモデルは通俗的な意味であり、
　ベームのいう学術的なスパイラルモデルではない。
　学術的なスパイラルモデルはまったくの別物で、以下の内容はあてはまらない）

　
　スパイラルモデルの場合は、開発工程を、何度も繰り返していく
　（くどいが、この定義は、ここなどに書かれている通俗的なもので、ベームのものとは異なる）。
　そのため、逐次仕様変更も可能になってくる。

　しかし、このことは、開発中に仕様変更が入るため、仕様追加したことによる、
インターフェースの矛盾や、変更し忘れなどを招く危険がある。
　この場合、品質は悪くなり、それを取り繕うためになにかすると、またそこに
バグが入ったりしてという、やればやるほど悪くなる逆スパイラルを招く危険が
ある。

　また、スパイラル、とくにテストファーストでやっている場合、仕事をしている
ような気になるので、モデルの本当に難しいところを置いておいて、わかりやすい
ところから手をつけ、そこを何度もカイゼンしていくという危険がある。

　この場合、本当に考えなければいけないところは、何時間も考えないといけないので、なかなか先に進まない。そーいうことはあとまわし、ブラックボックスということにしてしまい、わかりやすいところばっかり、あーでもない、こーでもないと議論する、

　つまり、仕事はしているが、おなじところを堂々巡りするループにおちいる。

　ここで、スパイラルは、何周までという規定をもうけてしまうと、今度は、
その周回をまわれば、本当にシステムができるのかどうか？がわからない。

---

■インクリメンタルモデル

　そこで、インクリメンタルモデルがでてきた。
　大きなシステムをサブシステム、サブサブシステム。。。とわけ、その中では、ウォーターフォールが採用され、システム全体としては、順次、サブシステムをつくっていくという流れ。
　この場合、本来のインクリメンタルモデルではないかもしれないが、サブシステム（ないしサブサブシステム、もっと小さく分けたなら、その単位）を１つのプロジェクトとして、各プロジェクトはウォーターフォールで作成し、プロジェクトが完了した後で、そのシステムの足りない点や、仕様変更したい点をまとめ、その修正も１プロジェクトとしてしまうと、プロジェクトをいろいろやっていくことによって、スパイラルのように、仕様変更に対応できるようになる。

　この場合、どの時点で、そのサブサブシステムにわけ、その際、何を決め、その各プロジェクトをどのように運営していくことで、一番効果的にできるか。。。
　という疑問が生じる

---

　今回はここまで。上記の疑問は、別の機会に。

Linuxのファイルシステムの１つを開発した人の会社、格安で売却の方針。というのも開発者が殺人の

容疑で勾留されていて、弁護費用がなくなっちゃうから。。。会社を売るそうな。

ちなみに、そのファイルシステムはReiserFS。
（表題の字数制限の関係で、みょうなところで、切れてしまった　＾＾；）

で、その記事が載ってるのが、ここのスラッシュドットニュース
Linux: 妻の殺害容疑で勾留中のHans Reiser、Namesysを売却方針
http://slashdot.jp/linux/06/12/22/0642220.shtml
で、そこによると（以下斜体は上記記事からの引用）


ReiserFSの開発者であり、妻の殺害容疑で現在も勾留中のHans Reiser氏であるが、本家Slashdotのストーリーによれば、彼の会社である Namesys社を売却する方針のようだ。これは、彼自身の弁護のための費用が尽きかけているため


（中略）


確かにReiserFSを所有できることを魅力に感じるところもありそうだ。


（中略）


気になる捜査の状況だが、本家ストーリーで参照しているWired Newsの記事から、Nina Reiserさんの行方はまだ分かっていないようだ。Hans Reiser氏が逮捕されたのは、彼の家と車からNinaさんの血痕が見つかったからのようだが、Hans氏は現在も無実を主張している。


Linuxのファイルシステムの開発者が、奥さんの殺人容疑で勾留てのもすごいが、
その裁判費用が底をつきそうなんで、会社売っちゃうって言うのもすごい（＾＾；）

で、買うとしたら、どこの会社？？

やっぱ、ここは、ターボリナックスにかっていただきたーい！
この前、Laser5買収したでしょ。
だから今度はReiserFSって、どお（＾＾）

日本人はLとRの発音の違いができないから、困るよ（－＿－）
といわれそうなんで、このへんで。。。