ビッグデータは、Ｈａｄｏｏｐ＋Ｒなの？でもＣＭではＥｘｃｅｌって言ってるよ（＾＾；）

日経コンピューターネタでもうひとつ。

日経コンピューター　２０１３年４月４日号　２６ページ～

ビッグデータの「初動」３原則

というのがある。初動３原則は、
１．全社連携の軸を担えるシステム部門が主導権を取る
２．分析の有効性を説いて回り利用部門・経営陣を巻き込む
３．今後２年のシステム、人材・組織、データ充実を今のうちに計画
だそうな。

で、問題なのは、以下の論調が、
ビッグデータは、Ｈａｄｏｏｐ＋Ｒ・ＳＰＳＳというカタチ
なのに、３６ページにＥｘｃｅｌの話が出てくる。

ＪＲのトレインチャンネルには、
ビッグデータ時代に（中略）エクセルの力
みたいなのがでてくる・・・

ビッグデータは、Ｈａｄｏｏｐ＋Ｒなの？Ｅｘｃｅｌなの？
この記事を読んだだけでは良くわからない。
そこで、つけたし。

---

■Ｈａｄｏｏｐ、Ｒ・ＳＰＳＳ、Ｅｘｃｅｌ（やＯＬＡＰ）



ローソンのビッグデータは、なぜ山本一郎氏に叩かれるほどの成果しか出なかったのか？
http://blog.goo.ne.jp/xmldtp/e/f6aa4b0ee88352c8bf5b91e2816ce296

にも書いたけど、Ｈａｄｏｏｐだけではだめ・・・

その理由は、Ｈａｄｏｏｐ、Ｒ，Ｅｘｃｅｌそれぞれに、得意不得意があるから。

Ｈａｄｏｏｐ
　基本的にデータをためるものと思ったほうがいい
　バッチ処理は早い。大得意
　リアルタイム処理、小量トランザクションは苦手。

Ｒ・ＳＰＳＳ
　計算は得意。いろんな統計処理ができる
　そもそも、データベースではないので、データはどこからか持ってくる
　特にＲは、キレイに表示するのは大変。まあ、plotで表示はするんだけど・・

Ｅｘｃｅｌ（やＯＬＡＰ）
　でかいデータはだめ
　グラフ表示はお手の物。
　ちょっとした処理は、気軽にできる

なので、目的に応じて、３つを使い分ける。
その際に、つなぐツールとして、（日経コンピューターの記事では紹介されていなかったけど）
ＥＴＬがある。

---

■どう使い分けるか

・とりあえずデータはＨａｄｏｏｐみたいな大容量処理できるものに入れる
　　→ＭｙＳＱＬとかから、Ｈａｄｏｏｐに入れる仕組みを作る

・ＥＴＬツールによって、適当に切り分け、ＥＸＣＥＬやＯＬＡＰで
　データサイエンティストが、いろいろ面白い現象を考える
　→「ローソンのビッグデータは、なぜ山本一郎氏に叩かれるほどの成果しか出なかったのか？」では、
　ここをＢｉｇＱｕｅｒｙを使って話した。それでもいいが、そうするとデータをＨａｄｏｏｐと
　ＢｉｇＱｕｅｒｙに入れることになる。
　それもいいけど、ＥＴＬツールを使ってちょっとデータを切ってきて、見るっていうほうが
　簡単かな

・そのなかで、あ、これいけそう！と思ったものを、ＲやＳＰＳＳで処理する。
　このとき、Ｈａｄｏｏｐに接続することになる。
　ＲとＨａｄｏｏｐは、標準入出力を介して、Hadoop Streamingを使う手もあるし、
　ＥＴＬツールを使って切り出したり、Ｈｉｖｅ使ったりという手もある

・処理結果は、Ｅｘｃｅｌなんかでグラフ化したほうがきれいかもしれない
　いや、がんばりたかったら、Ｒでがんばって、グラフ書いてもいいけどさ・・
　それを、一般の人にご披露する

・一般的な営業、企画、事務系の人には、必要そうなデータをバッチで適当な量切り出し、
　Ｅｘｃｅｌで見てもらったり、
　必要そうな資料をバッチ出力したりということで、いいと思う。

---

１つの技術で全部やろうとするより、
担当者のスキルとレベルに応じて、扱うデータやツールを
組み合わせたほうがいい。

なお、ＥＴＬツールとしては、TalendはＨａｄｏｏｐ使えたと思う
また、ＥＴＬにこだわらなくても、ＨＩＶＥ使って検索、その結果を利用しても良い。

アジャイルを終了させ、日本を中国化するかも？－裁判所と日経コンピューターが・・

う～ん、ソフトウェア工学話を終わらそうとしたら、
日経コンピューター 2013年４月４日号　にこんな記事が

誤発注裁判が改めて問う
「バグは重過失か」
日経コンピューター 2013年４月４日号　６８ページ～

これ、ツッコミどころ満載なんで、その中のいくつか

---

■この裁判を整理してみる

　この裁判は、
・みずほ証券が誤発注をした。
・誤発注したときに、取り消しをしたが、取り消せなかった
　　→もし取り消せなかったら、
　　　ふつうは、買いで失敗したら売り、売りで失敗したら買いと
　　　反対取引を自らして、相殺すると思うけどが、反対取引は、
　　　たしかかなり遅れてしたはず。
・取り消せないのは、富士通がばぐったから
・だから、「東証に責任がある」？
　　→謝罪と賠償をせよ

つまり、まとめると

　　みずほ証券←裁判→東証←受け入れ：開発→富士通

---

■そもそもソフトウェア工学的に見ると、顧客にソースコード
　を開示させること自体、おかしい。


　まず、ソフトウェア工学的に考えると、東証は、発注もとの顧客
の立場であり、ソフトウェア工学の教科書、たしかPfleegerさんの本
の日本語訳版にもあったと思うけど、顧客は、受け入れテストを
すればいいことになっている。
　その際、ソースコードや詳細設計はわからなくてよい。

　たとえば、アメリカの掃除機を、日本の量販店が買い、その日本の
量販店がある人Ａさんに売って、Ａさんが怪我したとする。
　Ａさんは、量販店を訴えたとする。ここまではＯＫ！
　でも、Ａさんは、掃除機のプログラムミスで怪我したからといって、
機密事項も含んでいるアメリカの掃除機のプログラムの開示請求をしたり、
量販店が、プログラムのチェックをしていないということを訴えるのは、
おかしいでしょ（＾＾；）
　量販店が調べることは、ちゃんと動作するか、安全かということを、
「掃除機を元に」しらべる。つまりソフトウェア工学的に言えば、
量販店はブラックボックステストを行うのであって、
ソースコードを見るホワイトボックステストを刷る必要はない。
なので、ソースを開示する必要はない。

　もし、ソースを開示する必要があるとすると、
　日本に輸出する場合は、すべて、ソースコードを開示し、ドキュメントも
開示しなければならないという制約が付くことになる。
　ソースコードには企業機密もあるので、これは、一般に大きな制約になる
というか、これは、まさに中国が求めた

中国、デジタル家電ソースコード強制開示強行へ
http://www.excite.co.jp/News/net_clm/20090424/Slashdot_09_04_24_0115201.html

となんら変わらない。これが問題になったことは、みんなも
覚えているだろう。

　顧客が、ソースコードを開示しなければならないとしたら、
このように、日本が中国化することになり、日本の産業は終わるだろう。
　はっきりいう、世界のソフトウェア工学は、そんなことを求めていない。
　顧客の受け入れ検査はブラックボックステストが前提だ。

---

■みずほ証券の主張は、無理筋ではないのか？

６８ページにみずほ証券の主張があるが、本当にこの主張なら、ちょっと
無理筋な気がする・・

みずほ証券の主張
１．たとえば自動車事故が一定の確率で起こるとして、
　　そのことを理由に「事故を起こした運転手に過失がない
　　と判断されることはないはずだ」

　今回の東証の事故は、事故を起こした原因が東証にあるのではなく、
富士通のバグであるという論拠になっている。
　したがって、上記のたとえで言うと、

　たとえば、某社の自動車は、リコールが多く、事故も一定の確率で起こしている。
　そのとき、事故を起こした運転手は普通のオペレーションをしていて、
　たまたま「歩行者の不注意」（＝みずほ証券の誤発注）で、
　自動車のリコールすべき案件（＝富士通のバグ）あったために、
　運転手（東証）が事故を冒したとき、

　確かに運転手は事故を起こしたので、過失はあるかもしれない。
　しかし、運転手は、リコール案件を知らなくて、普通は当然じゃないか？
　リコール案件をしらなかったから、重過失になるのか？

　え～、そしたら、リコール案件で自動車事故を起こした人は、
　何も知らない間に、重過失かい！

　おかしいだろ。。。この論拠

２．バグは容易に発見できた
　　→これは、あとで論じる。無理筋だ。

３．ソースコードの変更を設計書に反映するのは当然だ

　今、議論しているのは、バグの問題。
　「ソースコードの変更を設計書に反映」しない場合、
　かならず（ないしはかなりの確率で）、このバグを生じるというのを論証しない限り、

　「ソースコードの変更を設計書に反映」しないことを理由に
　バグを生じる責任は問えない。

　ところが、発生順序を考えると、

　「修正依頼」→「設計書に反映」→「修正」

　という工程なら、たしかに設計書に反映しないと、修正ミスが起こるだろうが、

　「修正依頼」→「修正」→「設計書に反映」

　という工程をとっている場合、「設計書に反映」しなかったから、「修正」ミスしたとは言えない。
　なので、この状況から、かならずバグを生じるという論証は難しいはず。

　ということで、みずほ証券側のロジックは、論理飛躍があり、無理筋。
　東証のブロックが甘いから、議論が成立しているだけではないのか？

---

■バグは、後講釈でいうなら、みんな簡単。


アメリカでもFORTRANのプログラムで、ピリオドとカンマを打ち間違えて失敗したプロジェクトがありました。

という話を、

FORTRANのDO文と落ちたロケットのfolklore


で議論している。ここであるように、カンマとピリオド、ハイフンですら、間違える。

テストしてたら、見つかっただろうにね・・・
机上デバッグで気づくだろう・・・

後講釈なら、何でもいえるよね。
でも、見つからない・・・ってことは、現場の人なら知っているはず。
いや、ＮＡＳＡですら、みつからないんだぜ！

それと比べると、実は、今回のテストは、ちょっと（いやかなり）難しい。

ばぐった理由は７２ページに図入りである。
ＩＦ文で分岐しているのだが、その前に「条件が成立しない」というもの。
では、このテストを考えるよ

・単体テスト
　網羅率を１００％にするには、すべてのＩＦ文を通す必要がある。
　そこで、デバッガで、ＩＦ文の前に、会員ＮＯなどに対して値を設定してしまった場合、
　２、３の条件とも（値をいれて）チェックする→ＯＫとなるので、ここでは見つからない

・結合テスト
　　１の部分でかならずセロクリアされるのが「問題と気づくためには」
　　どのくらいのテストケースが必要なのか、が書かれていない
　　なので、どのくらいのテストケースを挙げないと、この状況に気づかないのか、わからない

　３は、約定した状態。２は部分約定の状態。
　部分約定のすべてが間違えていた・・ってなったら、部分約定しないはずだけど、
　たぶん、部分約定って、するよねえ・・たまに。。。

　っていうことは、単純な部分約定ではなく、かなり込み入ったケースにおける
　部分約定と考えられる。そのテストケースを導出するのに、どれくらいかかるか・・

　そして、組み合わせチェックだから、直交表などを使った場合、この条件が
確実にチェックできるのか・・・

　ね、簡単な議論ではないのよ・・・

・システムテスト・統合テスト
　普段、東証で問題は起きていない。
　っていうことは、これはまれなケースと考えられる。
　ってことは、「簡単に見つかる」重過失のケースとはいえない。
　約定できないとかいうのなら、重過失だろうけど、部分約定は簡単なケースじゃないし、
　それも、今回の場合は、普通にあるケースじゃない（普通は値幅制限があるから）

　もちろん、そのケースもやっておくべきだけど、それを忘れたから、重過失・・かあ？

・受け入れテスト
　システムテスト、統合テストと同レベルのテストをするばずなので、
　上記と同じ議論になる。

　ってことで、「ゼロクリア済み」というのを見つけなきゃいけないので、
　単純なテストではないのだ・・・

---

■ソースコード修正からドキュメント等を自動生成するのが、
　ソフトウェア工学の流れのはずでは？

　そして、極めつけの議論は、
　７２ページ２段目から、３段目の議論

「システムを保守する者は、ドキュメントを見ないというのだろうか。
　ソースコードだけが頼りというのでは、ソフトウェア工学が長年にわたってきた知見を
　すべて無視することになる」


　まず、ソフトウェア工学は、流行があり、長年にわたった知見でも、
流行ってないと無視される（＾＾；）
　例えば、いま、ＣＯＢＯＬの研究してる人少ないと思うよ・・

　ま、そこはさておき、今の流れは、ソースコードからの自動化。
　つまり、ソースコードからドキュメントやその他の可視化できるものを自動的に作り出すのが主流
　なので、ドキュメントを見るだろうけど、それをソースコードを頼りに作るのが、
今の流行かな。

　典型例がＪａｖａＤｏｃだよね。納品物になっているけど、あれ、ソースコードから作ってる。
　ＥＲ図も、ＤＢから自動生成させてたりするし・・

　もし、

　「ドキュメントは作らなければならない・判りきった詳細設計書でも、
　　自動化せずに・・・」

　とか言ったら、アジリティはなくなってしまう。
　アジャイル終了のお知らせになる。。。
　裁判所と日経コンピューターがアジャイルを終了させる？


　そもそも、アジャイルでやる場合、チケット駆動開発を導入すれば、

（１）修正要望のチケットを発行する
（２）修正者がソース修正してコミットする
　　　　→ここで差分は取れる
（３）チケットに修正箇所を書く
　　　　→もちろん、これは（２）から自動化してもいい。

とすれば、修正ドキュメントをわざわざ作らなくても、修正箇所と修正内容がわかり、
保守できる。一般の人から見ると、これこそまさに、ソフトウェア工学！

---

■でもね・・・

　なんだけど、アカデミックな世界では、ソフトウェア工学上で、チケット駆動開発は浸透していない

情報学広場で、
　　チケット駆動開発を引くと、８件
　　TiDDとひくと、３件
　　Redmineで引くと２９件

IEEE Xploreで
　　Ticket Driven Developmentをひくと７件
　　（ＴｉＤＤはどうも、違う意味になるらしい）
　　Redmineで２件

ということで、当然ながらTiDDは、日本で進んでいるけど、今一歩なのだ・・
なので、上記開発スタイルが、TiDDな人では一般的ではあるけれど、
学会ではまだ認識されず、ドキュメントを（手作業で？）修正なんていう
議論が成立してしまうわけだ。

---

　現場の人から見ると、かなり変な論拠で、みずほ証券も東証も闘っているんだけど、

　意見書を出しているソフトウェア工学の専門家は、たぶん大学の先生なので、
　大学の先生で今の現場の感覚と近いのは、鷲崎先生のところとか、西先生のところとか
　極わずか・・

　となると、こういう判らん議論になってしまうわけだ・・

アジャイルをやりたいなら、世界を相手にすべき！

いくらなんでも、ソフトウェア工学話で引っ張るのは、無理が出てきたし、


アジャイルをダメにしないためにすべきこと
http://arclamp.hatenablog.com/entry/2013/03/28/000000


で、大体話がまとまってきたので、もうそろそろ、ソフトウェア工学ネタ
はうちも、終わりにしていいかな・・・

と思って、話をまとめる方向に行ってみたいと思う。

---

上記の「アジャイルをダメにしないためにすべきこと」は
結局、「アジャイルだけではない」という話だと思います。
現実は、その通りだと思います。

アジャイルで向いているプロジェクトもあるし、
アジャイルに向いていないプロジェクトもある。
だから、アジャイルで有名な永和システムさんも、
１００％アジャイル案件なわけではないし
（と、この前聞いた。聞き間違い出なければ）

日本のプロジェクトのかなり多くがウォーターフォールであるのは、
「ソフトウェア開発データ白書 2012-2013」
（http://sec.ipa.go.jp/publish/tn12-002.html
にいき、アンケートに答えるとＰＤＦ版が無料で手に入る）
の４２ページ「図表４－５－１　開発ライフサイクルモデル」
でウォーターフォールが９６．５％なことからもわかる。

アジャイルは現状、Ｗｅｂの開発では多く利用されているみたいだけど、
「図表４－４－１１　開発言語」にあるように、Ｊａｖａの
次に多いのはＣＯＢＯＬっていうぐらい、Ｗｅｂ以外の開発も
現存していて、そんなＣＯＢＯＬを利用する開発では
アジャイルって、なじみにくいかもしれない。
（ＣＯＢＯＬは、入出力が「カチッ」としていたほうが書きやすい
　あんまり、変わるとやりにくい）

脱線：
　でも、この調査すごいよな。ＡＢＡＰがあって、Ｒｕｂｙがない（＾＾；）
　Rubyより、InputManのほうが、有名なのか（＾＾；）

　ってなことで、実際は、ネットで議論されているよりも、
ウォーターフォールは存在するし、たぶんだからこそ、
ウォーターフォールでうまく行かない部分を、
アジャイルに期待している部分があって
自分の今やっている仕事の否定として、アジャイルが存在している可能性がある。

---

ウォーターフォールは、属人性の排除を目指し、
ソフトウェアファクトリー化
できるんじゃないかとの期待をもった。
これが、ソフトウェア工学となじみやすく、
自動化の話や品質管理の分野が進んだ。

今も進んでいて、ウォーターフォールでできる、
カチッとた大規模開発は、自動化を目指していくだろう。
そして、ソフトウェア工学も、この分野では進んでいく。
要求工学の一部とＭＤＡ、品質管理の一部は、この分野かな

---

一方、Ｗｅｂの世界は、アジャイル開発に向いている。
そんな世界は、ユーザーのＵＸ要望は高いし、他社の出方によって、ビジネスモデル
が大きく変わる。

でも、アジャイルは、人が変わると同じことをやっても、
うまく行くとは限らない。人の部分が結構ある。
この手の話は、日本のソフトウェア工学では、
現状、パターンランゲージとか、事例研究以外の分野では
論文になりにくく、学会では、フルペーパーを通している人は少ないと思う。

情報学広場（情報処理学会の論文が検索できる）で
　　アジャイルで検索すると、１３２件
　　ＵＭＬで検索すると８４１件だから、
　ＵＭＬほどには、アジャイルはぜんぜん広まっていない。

日本のソフトウェア工学の教科書もこんな感じなので、
アジャイルとかは、あまり出ていない。
この現状は、
ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460

で指摘されている。

---

ただ、だからソフトウェア工学は「だめ」なんだという話には、実は、ならない。
博士号をとるために論文を書くのであれば、たしかに、
情報処理学会、信学会、ソフトウェア科学会の中から考えるが、
そうじゃなく、著名な先生であれば、ＩＥＥＥに自分の論文を
出すことを考えるだろうし、まあ、普通の大学院生なら、関連研究に
国内だけでなく、ＩＥＥＥやＡＣＭを調べるのは必須だ。

IEEE Xploreで
　　agileを引くと４４８５
　　UMLを引くと4224
アジャイルのほうが、出ている論文が多いのだ

---

そして、さっき

PressmanのSoftware Engineeringを超訳ななめ読み　その３－各種アジャイル
http://blog.goo.ne.jp/xmldtp/e/6c4fb02e21f0c2c267d77431ed845e12

に書いたように、アメリカなどでの教科書的に読まれる
Pressmanの本では、日本で紹介されていないようなアジャイル手法が、
ガンガン出ている。

日本では、リーンやScrumが話題だが、それは日本ではそうなだけで、
（たぶん、日本の風土に合っているんでしょうね）海外では違う。

そして、海外では、（のちのち紹介していくけど）ウォーターフォールも
スパイラルもアジャイルも形式手法もアスペクト指向も
ちゃーんとソフトウェア工学の範囲になっている。
つまりで書かれているのは、日本の現状の「情報処理学会、信学会、ソフトウェア科学会」で出ているソフトウェア工学の話であり、IEEEとかで扱うソフトウェア工学は、「ソフトウェア工学は失敗している」で挙げている分野、さらにそれより広い広い領域を扱っている。

つまり、日本のソフトウェア工学は、問題あるかもしれないけど、
世界的に見ると、「ソフトウェア工学」は実務の分野も含んでいる。

---

そして困ったことに、日本でソフトウェア工学を専攻する普通の？大学院生であれば、
IEEEとかACMを中心に調べ、テキストとしては、今取り上げているPostmanの本か、
Pfleegerさんの最新版の原著

Software Engineering: Theory and Practice
http://www.amazon.co.jp/dp/0136061699

とかで勉強しちゃう
（これは、「ソフトウェア工学は失敗している」で挙げている
「ソフトウェア工学―理論と実践」の原著の最新版）
Pfleegerさんの本も、アジャイルを最近足しているらしい。

そして、さらに困ったことに、まあ、そこそこの大学院生や大学の先生は英語読めちゃうので
ＩＥＥＥの論文とか、さっき挙げたテキストを読んで、あんまり日本の本や論文を気にしない。
訳してもらいたいとも思わないし、訳す暇もない。なんだったら、英文で論文を書く気も満々！
つまり、研究者の目は海外、特に国際的なＩＥＥＥとかに向いている
（ＩＥＥＥは、アメリカの団体だけど、学界的には世界に開かれている、国際的な場となっている）

結果、日本のソフトウェア工学が遅れているように見えて、
それを一般の開発者がみると、
「なにやってんだ！日本のソフトウェア工学は！！」
という論調になってしまう。

---

なんで、本当にアジャイル、さらにソフトウェア工学全般を
勉強したいのなら、世界を相手にして、
英語の本や論文を読まないと、はじまらない・・・

・・・っていうのが、現状なのよ・・・

でもね、えいご、にがてなんです・・・
だれかやくしてほしい・・・

Ｐ．Ｓ　Ｇｏｏｇｌｅ翻訳をかけると、
なおさら判らない訳になる・・・

PressmanのSoftware Engineeringを超訳ななめ読み その３－各種アジャイル

みんなから、無慈悲な稲妻を受けないために、
大事そうなところを、超訳＆ななめ読みしている

PressmanのSoftware Engineeringを超訳ななめ読みする

前回で、第一章が終わったので
今回から、本格的に超訳＆ななめ読みです。
まずは、アジャイル関連の３章

---

■アジャイル概論

３章　アジャイル開発

　２００１年、ケント・ベック他１６人の著名なソフト開発者、ライター、コンサルタント（アジャイル　アライアンスと言われる）は、アジャイルマニュフェストに署名した。それは、以下のように始まる

　で、はじまる第三章はまず、

３．１　アジャイルとは何か
　ではじまります。ここではヤコブソンの「アジリティ」の説明が載っています。

３．２　アジリティと変化のコスト
　に関しては、アジャイルとアジャイルを使わなかった場合で
　スケジュールが進んでいったときのコストのかかり具合について
　話を進めています。

３．３　アジャイルプロセスとは何か
　では、
　　３．３．１　アジリティ　プリンシパル
　　　でアジャイルソフトウェアの12の原則

　　　について書いてあります
　　３．３．２　アジャイル開発の政治学（ポリティクス）
　　　で、なんか書いてあって、
　　３．３．３　ヒューマンファクター
　　　で、アジャイルチームの鍵となることとして
　　　　コンピテンス
　　　　共通のフォーカス
　　　　コラボレーション
　　　　意思決定能力
　　　　ファジーな問題の解決能力
　　　　相互信頼と尊重
　　　　自己組織化
をあげています。ここまでが概論

---

■アジャイルの種類

３．４　エクストリームプログラミング（ＸＰ）
　「３．４．１　ＸＰの価値」、「３．４．２　ＸＰプロセス」で一般的なＸＰの話
　「３．４．３　Industrial XP」でＩＸＰを上げています。
　　　このなかで、ＳＤＤ（Story-driven development)とＤＤＤ（domai-driven development)
　　　について述べ、「３．４．４　ＸＰについてのディベート」で議論をしています。

３．５　他のアジャイルプロセスモデル
　３．５．１　Adaptive Software Development（ＡＳＤ）
　３．５．２　Ｓｃｒｕｍ
　３．５．３　Dynamic System Development Method(DSDM)
　３．５．４　Crystal
　３．５．５　ユーザー機能駆動開発（ＦＤＤ）
　３．５．６　リーン ソフトウェア開発（ＬＳＤ）
　３．５．７　アジャイル　モデリング（ＡＭ）
　３．５．８　アジャイル統一プロセス（ＡＵＰ）

---

■そして
　３．６　アジャイルプロセスのための一連のツール
　３．７　サマリー

と続いている

---

３．４～３．５にかけて、あまり日本で話題になっていないＡＳＤ，ＤＳＤＭ，アジャイルモデリング、ＡＵＰなど、数多くの開発方法を挙げて説明している。