なんか、
「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？
http://blog.goo.ne.jp/xmldtp/e/2896922420cd01406a25f75606265c2a
の反響が大きいらしい・・・？
なので、ちょっと、これに関して、何点か、付け足しておく。
まず、第一点。
現在の日本のソフトウェア工学を論じるうえで、
「実は、astahを使って、要求から画面のソース作成までを一気通貫
（＆自動生成）する方法は、論文が出ていて、無料で見られる」
っていう事実は知っておいたほうがいい。
そして、その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せる。
まず、その論文は、これ
UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法
コンピュータ ソフトウェアVol. 27 No. 2,日本ソフトウェア科学会(2010)
https://www.jstage.jst.go.jp/article/jssst/27/2/27_2_2_14/_pdf
ここで、示されている手法は以下のとおり
（上記の図は、上記論文より引用）
上流部分の一部は、この論文の対象外となっているようなので、そこを
付け加えて、全部書くと、こんな手順になる。
（ここは付け足した）
・なにをやりたいかをきめ、そのやりたいことに関する人を挙げる
人とやりたいことを結ぶと、ユースケース図になる。
ここで、やりたいことを、以下、「サービス」という
また、人は何でもしてよいわけではない。
何ができるかを決めたものを以下「権限」とよぶ
↓
（ここから、論文の内容）
・サービスの実行手順と、そのサービスの入出力をまとめ、
アクティビティ図に描く
→この論文で言っているアクティビティ図は、普通のアクティビティ図
と同じではないが、astahのアクティビティ図で書ける
↓
・その入出力項目の項目名と関連をしらべて、クラス図にまとめる
↓
・具体的にどんな値を入れるかを例を出して考え、オブジェクト図にまとめる
→ここで、検証する
→シナリオ単位の入出力にまとめる→テスト内容が確定する
↓
・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）
アクティビティ図にまとめる
（論文には書いてないけど）
普通は画面遷移図だろうけど、
astahに画面遷移図はないからなあ～
↓
その画面をもとに、自動生成
この手法は、画面からデータ構造を決めている。
したがって、最近の画面→クエリ→ＤＢ作成の手法には向いているんだけど、
「ＤＢは、正規化したもの」にする、従来の手法を用いる場合には、
クラス図にした入出力項目を元に、ＤＢのテーブル（ないしＥＲ図）
を作ることになる。
この手法は、佐藤正美氏の本などに出ている。
ただ、この手の論文はでていないかな・・・
しかし、最近は正規化をしないので（ＣａｋｅＰＨＰでbakeでつくるときなど）
これでもいいわけだ。
松浦先生のところで、小形先生（論文発表当時は、芝浦工大のたしかＤ？現在、信州大）がこの論文を出したので、ここから先、単にCakePHPとかで、全自動生成したとしても、卒論レベルならＯＫだけど、フルペーパーでは、ちょっとね・・・っていうレベルになった・・気がする。
ちょっと、脳内で妄想してみてね。
ある修士の院生が来て・・・
（院生）ＣａｋｅＰＨＰで、要求から全自動でプログラミングを作るという「リサーチ・クエスチョン」で修士論文を書きたいと思います。
（先生）ほお、どう、アプローチするんだい。
（院生）まず、関連研究で、 「UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法」を挙げます
（先生）うん
（院生）そこで出てくるクラス図をastahでつくり、プラグインを作って、項目名を抽出、ＳＱＬを作成して、ＤＢを自動生成します。
（先生）なるほど、ＤＢは自動生成できるね。そこから・・・
（院生）はい、bakeをたたいて、ＤＢからモデルを作ります。
（先生）・・・
（院生）そして、bakeをたたいて、モデルからコントローラーを作り、
最後に、bakeをたたいて、コントローラーからビューを作ります。
従来、手作業でやっていたことを、プログラムで自動化して行うので、
とてもはやく仕上がります！
（先生）それ、２年間で・・・
（院生）はい！（＾＾）ｖ（満面の笑み）
（先生）・・・それって、３ヶ月ぐらいでできないか（＾＾；）・・・
bakeもいいけど、zfとか、symfonyとかもたたいてみて、
比較する気は、ないかね（＾＾；；；；・・・・・
卒論や研究会発表なら、ある方法論、まあcakePHPでもいいや、ＣＯＲＢＡでもいいや、ＳＯＡＰ使っても、ＲＥＳＴでも
ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460
に出てくる技術を一つ挙げて自動化っていうのも、アリだと思う。
ただ、修士論文以上、博士論文、フルペーパーになると、
それでは、スコープ小さすぎで、
・クラス図から項目名に基づき自動的に正規化し、ＤＢの論理構造と
画面の物理構造を連結するコントローラー等を自動生成する手法
・cake,Zend,symfonyなど、いろいろな手法を切り替えて、自動生成できる
フレームワーク
ぐらいにならないと・・・
ただし、経験論文ならありだと思う。上記の手順で、実際に仕事を請けてやった場合の論文を、経験論文を受け付けている研究会で発表するのは、大アリだと思う。
だけど、そのとき、机上の空論をしてるんじゃ、もうだめぽで、そのとき、どういう問題があって、どう解決したかまでが、求められる。ただ、ここまでいくと、大学の先生や研究所ではできない
（そんなソフト開発のお仕事は請けないからね。大学は・・
・・・ただし産学連携ＩＴ授業として論文にするのはありかな）
次の話題。その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せるということだけど、
上記で自動生成は、要求→設計→コーディング（のはじめ：自動生成）まで行っている。
このまま、コーディングののこり（カスタマイズ部分）と、テストをやるとして、
のように、まず、設計対象となる、全ての部分について、
・サービスの実行手順と、そのサービスの入出力をまとめ、
それが、全システム終わったら、設計段階ということで
・その入出力項目の項目名と関連をしらべて、クラス図にまとめる
さらにそれが全システム終わったらＵＩ設計ということで、
・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）
というように、全体が終わってから、次の工程にいくと、ウォーターフォールになる。
一方
のように、全サービスをいくつかのサービスに分割し、その中で、
上記の要求、設計、ＵＩ、実装って入っていくと、
これは、インクリメンタルモデル。
スパイラルは、ベームが提唱した理論の場合、各フェーズでプロトタイプを
つくる。ってことは、一番初めに挙げている図１のカタチで、ＷＦをやるに
過ぎない。
アジャイルは、基本的に、どの順番でやるかは、まかされている。
まあ、１つのサービスを一気に作っちゃったほうが、はやいかな？
Ｗ字開発は、オブジェクト図を作って、具体的データを考える（ＣＳＶとかつくる）
際に、テスト項目も考えると、設計時にテスト仕様書をつくることができる。
ってことで、この論文をベースに、いろんな開発プロセスにもっていけるわけよ。
で、この論文の先を、今、みんな考えているわけなんだけど、
まあ、それについては、このエントリ、いくらなんでも長くなりすぎたので、
このへんで切って、別の機会に。
「アジャイルがダメだと思う7つの理由」と「ソフトウェア工学は失敗している」は同じ次元の釣り？
http://blog.goo.ne.jp/xmldtp/e/2896922420cd01406a25f75606265c2a
の反響が大きいらしい・・・？
なので、ちょっと、これに関して、何点か、付け足しておく。
まず、第一点。
現在の日本のソフトウェア工学を論じるうえで、
「実は、astahを使って、要求から画面のソース作成までを一気通貫
（＆自動生成）する方法は、論文が出ていて、無料で見られる」
っていう事実は知っておいたほうがいい。
そして、その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せる。
まず、その論文は、これ
UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法
コンピュータ ソフトウェアVol. 27 No. 2,日本ソフトウェア科学会(2010)
https://www.jstage.jst.go.jp/article/jssst/27/2/27_2_2_14/_pdf
ここで、示されている手法は以下のとおり
（上記の図は、上記論文より引用）
上流部分の一部は、この論文の対象外となっているようなので、そこを
付け加えて、全部書くと、こんな手順になる。
（ここは付け足した）
・なにをやりたいかをきめ、そのやりたいことに関する人を挙げる
人とやりたいことを結ぶと、ユースケース図になる。
ここで、やりたいことを、以下、「サービス」という
また、人は何でもしてよいわけではない。
何ができるかを決めたものを以下「権限」とよぶ
↓
（ここから、論文の内容）
・サービスの実行手順と、そのサービスの入出力をまとめ、
アクティビティ図に描く
→この論文で言っているアクティビティ図は、普通のアクティビティ図
と同じではないが、astahのアクティビティ図で書ける
↓
・その入出力項目の項目名と関連をしらべて、クラス図にまとめる
↓
・具体的にどんな値を入れるかを例を出して考え、オブジェクト図にまとめる
→ここで、検証する
→シナリオ単位の入出力にまとめる→テスト内容が確定する
↓
・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）
アクティビティ図にまとめる
（論文には書いてないけど）
普通は画面遷移図だろうけど、
astahに画面遷移図はないからなあ～
↓
その画面をもとに、自動生成
この手法は、画面からデータ構造を決めている。
したがって、最近の画面→クエリ→ＤＢ作成の手法には向いているんだけど、
「ＤＢは、正規化したもの」にする、従来の手法を用いる場合には、
クラス図にした入出力項目を元に、ＤＢのテーブル（ないしＥＲ図）
を作ることになる。
この手法は、佐藤正美氏の本などに出ている。
ただ、この手の論文はでていないかな・・・
しかし、最近は正規化をしないので（ＣａｋｅＰＨＰでbakeでつくるときなど）
これでもいいわけだ。
松浦先生のところで、小形先生（論文発表当時は、芝浦工大のたしかＤ？現在、信州大）がこの論文を出したので、ここから先、単にCakePHPとかで、全自動生成したとしても、卒論レベルならＯＫだけど、フルペーパーでは、ちょっとね・・・っていうレベルになった・・気がする。
ちょっと、脳内で妄想してみてね。
ある修士の院生が来て・・・
（院生）ＣａｋｅＰＨＰで、要求から全自動でプログラミングを作るという「リサーチ・クエスチョン」で修士論文を書きたいと思います。
（先生）ほお、どう、アプローチするんだい。
（院生）まず、関連研究で、 「UML要求分析モデルからの段階的なWeb UIプロトタイプ自動生成手法」を挙げます
（先生）うん
（院生）そこで出てくるクラス図をastahでつくり、プラグインを作って、項目名を抽出、ＳＱＬを作成して、ＤＢを自動生成します。
（先生）なるほど、ＤＢは自動生成できるね。そこから・・・
（院生）はい、bakeをたたいて、ＤＢからモデルを作ります。
（先生）・・・
（院生）そして、bakeをたたいて、モデルからコントローラーを作り、
最後に、bakeをたたいて、コントローラーからビューを作ります。
従来、手作業でやっていたことを、プログラムで自動化して行うので、
とてもはやく仕上がります！
（先生）それ、２年間で・・・
（院生）はい！（＾＾）ｖ（満面の笑み）
（先生）・・・それって、３ヶ月ぐらいでできないか（＾＾；）・・・
bakeもいいけど、zfとか、symfonyとかもたたいてみて、
比較する気は、ないかね（＾＾；；；；・・・・・
卒論や研究会発表なら、ある方法論、まあcakePHPでもいいや、ＣＯＲＢＡでもいいや、ＳＯＡＰ使っても、ＲＥＳＴでも
ソフトウェア工学は失敗している
http://d.hatena.ne.jp/nowokay/20130322#1363969460
に出てくる技術を一つ挙げて自動化っていうのも、アリだと思う。
ただ、修士論文以上、博士論文、フルペーパーになると、
それでは、スコープ小さすぎで、
・クラス図から項目名に基づき自動的に正規化し、ＤＢの論理構造と
画面の物理構造を連結するコントローラー等を自動生成する手法
・cake,Zend,symfonyなど、いろいろな手法を切り替えて、自動生成できる
フレームワーク
ぐらいにならないと・・・
ただし、経験論文ならありだと思う。上記の手順で、実際に仕事を請けてやった場合の論文を、経験論文を受け付けている研究会で発表するのは、大アリだと思う。
だけど、そのとき、机上の空論をしてるんじゃ、もうだめぽで、そのとき、どういう問題があって、どう解決したかまでが、求められる。ただ、ここまでいくと、大学の先生や研究所ではできない
（そんなソフト開発のお仕事は請けないからね。大学は・・
・・・ただし産学連携ＩＴ授業として論文にするのはありかな）
次の話題。その手法の使い方を変えるだけで、ウォーターフォールから、
インクリメンタル、スパイラル、アジャイルが全部、導き出せるということだけど、
上記で自動生成は、要求→設計→コーディング（のはじめ：自動生成）まで行っている。
このまま、コーディングののこり（カスタマイズ部分）と、テストをやるとして、
のように、まず、設計対象となる、全ての部分について、
・サービスの実行手順と、そのサービスの入出力をまとめ、
それが、全システム終わったら、設計段階ということで
・その入出力項目の項目名と関連をしらべて、クラス図にまとめる
さらにそれが全システム終わったらＵＩ設計ということで、
・サービスの実行手順をきめて（画面遷移→ナビゲーションが決まる）
というように、全体が終わってから、次の工程にいくと、ウォーターフォールになる。
一方
のように、全サービスをいくつかのサービスに分割し、その中で、
上記の要求、設計、ＵＩ、実装って入っていくと、
これは、インクリメンタルモデル。
スパイラルは、ベームが提唱した理論の場合、各フェーズでプロトタイプを
つくる。ってことは、一番初めに挙げている図１のカタチで、ＷＦをやるに
過ぎない。
アジャイルは、基本的に、どの順番でやるかは、まかされている。
まあ、１つのサービスを一気に作っちゃったほうが、はやいかな？
Ｗ字開発は、オブジェクト図を作って、具体的データを考える（ＣＳＶとかつくる）
際に、テスト項目も考えると、設計時にテスト仕様書をつくることができる。
ってことで、この論文をベースに、いろんな開発プロセスにもっていけるわけよ。
で、この論文の先を、今、みんな考えているわけなんだけど、
まあ、それについては、このエントリ、いくらなんでも長くなりすぎたので、
このへんで切って、別の機会に。
アクセス
トータル
ランキング
