アジャイルで開発すると品質は高くなるのか？

　コメントやトラックバックは一切受け付けない仕組みになっているので、せっかくだから、他の人は書かない危ない話題について書いてみたいと思う（もし、受け付けたら炎上だよね　＾＾；）

　最近のソフトウエア工学や開発方法論では、アジャイル開発の話題が花盛りになっている。

　この前提として、

　　・要求仕様は完全なものは出ない
　　・なので、どんどん作っていって、スパイラルで開発していき
　　・仕様をつめていく

　というのが、前提にあると思います。
　で、問題なのですが。。。

　要求仕様が完璧でない場合、何度も修正かけると、どうして品質がよくなると
　いいきれるのか？

---

　
　要求仕様が完璧だったとしたら、アジャイルで開発する必要はないです。
　仕様変更がほとんど入らないことになるので、この場合、ウォーターフォールでもOKで、仕様変更を障害の一環として処理すれば、問題ないです（２０年位前の汎用の開発はこれに近かったと思う）。

　なので、アジャイルで開発するというのは、そうじゃゃないとき＝要求仕様が完璧じゃないから、アジャイルで開発して、どんどん目に見える形で確認し、修正していこうということだと思います。

　でも、ってことは、どんどん修正していけば、プログラムはよくなるって言うことが前提にあります。でも、この前提成り立ちますか？

　要求が完全でないって言うことは、部分的です。
　したがって、修正も部分最適になります。これは全体最適とは限らないので、部分最適のつぎはぎだらけのプログラムになって、ぐちゃぐちゃになり。。。
　そのうち保守できなくなり、崩壊するっていうことはありませんか？

　つまり、昨日書いた
仕様漏れ、勘違い→仕様変更→プログラムが崩れる→結合テストで破綻→デスマーチ
って話で、プログラミングレベルで修正を繰り返すと、プログラムが破綻しなければいいけど、破綻してしまったら、もう、手が付けられなくなります。

　破綻しないといえますか？？っていうか、

　破綻することのほうが多い＝作り直したほうがいい、ってことが多いと思うけど。。

---

　で、作り直すって言うのであれば、何回も作り直すよりかは、ある程度精度を高めて、そしてから、プログラム工程に流したほうがいいってことになります。

　つまり、要求仕様の精度を上げるため、プログラムを作らないでもいいシュミレーション方法（決まりきった処理と入出力から、それができるかどうか検証するみたいなかんじの話）を研究したほうがいいのに、後工程に話をすすませて、それでどうにかしようという形に、今の学会、企業、開発者は進んでいませんか？

　でもね、むかーしむかし、上流工程のミスを下流で発見する場合、下流工程に行けば行くほど、修正はたいへんになるっていう話しがあったと思うのね。だとすれば、プログラム工程で矛盾を発生させるアジャイルより、上流工程でシュミレーションをきっちりやる、さらには、ヒアリングがきっちりできる手法を考えたほうが。。品質上がりませんか？

---

　なーんてかいたら、アジャイルまんせーの人から、
　非難のコメント、トラックバックごうごうだよね。
　
　おまえは分かってないっていって。。

　よかった、コメントトラックバック禁止にしておいて（＾＾）ｖ

開発の初めから順番に書いていってみる その１６：要求分析（２）要求分析手順（１５時追加）

（１５：００に一部追加しました）

　シリーズ「開発の初めから順番に書いていってみる」の続きです。
　前回から、要求分析フェーズに入っていて、前回は、その成果物である、要求仕様書について書きました。
　今回は、要求分析の手順についてです。

---

■要求分析の手順

　要求分析の手順としては、大まかに書くと

・ヒアリング前の準備をする

・ヒアリングする
機能仕様部分
非機能仕様部分

・ヒアリング内容をまとめる
DOA、オブジェクト指向などで、方法論は違う

・要求仕様書にまとめる

ということになります。

---

■公開されている開発標準における要求仕様手順
（ここ、１５：００追加）

　要求仕様書のとき、公開されている富士通の開発標準
1.ComponentAA開発標準
http://segroup.fujitsu.com/sdas/technology/develop-guide/1-caa.html
について、触れたので、今回も、そこから、要求仕様の手順について。

上記サイトからダウンロードできる
ComponentAA開発標準 Method編シリーズ ドキュメント標準編(一般公開用）
の、「1.6作業フロー図」に書かれている要求仕様の手順は、こんなかんじ。

SA:(1) 業務要件定義
	→要件の要望をまとめる

SA:(2) 業務機能分析、データ分析
	→業務を分析する（DFD,ER図の世界）

SA:(3) 分析検証
	→データとユースケースのマッチング

SA:(4) 用語・データタイプ・コードの定義
	→用語集など

これらは、主に、「ヒアリング内容をまとめる」の具体的な手順になります。

　（１５：００追加：いったんここまで－もう一つ追加箇所あり）

---

■一番の勝負は、ヒアリングになる。

　ここで問題は、世間一般的には、

　　　DOAの場合DFD、ER図への落とし方、
　　　オブジェクト指向の場合は、アクティビティ図から、ユースケース図、
　　　　　ER図に相当する部分のクラス図の作り方までの落とし込み

　についてが話題になっています。
　（１５：００追加）
　上述の富士通の開発標準でも、まさに、このヒアリングの落とし込み、まとめ方の手順が書かれています。
　（１５：００追加：ここまで）

　しかし、これらは、本も出ていますし、手法としても、ある程度見えています。。

　問題は、ヒアリングです。ここで、聞き出せなかったり、
　間違ったことをきいてしまうと、
　以降の過程は、ぼろぼろになります（要求仕様以降も、ぼろぼろになります）

　なので、ヒアリングが大事です。

---

■でも、ヒアリングしてもユーザーがしゃべってくれるとは限らない

　でも、「さー、はなしてください」っていってら、すべて話してくれるとは限りませんよね。何から話していいか。。

　っていうことで、聞きもれが出てきます。

　そうすると、たいへんです。あとで、聞きもれ！って分かったら、仕様変更です。
　そうなると、品質が下がって。。。(途中省略）。。。デスマーチになるって言う話は
　昨日書きました。

　だから、ヒアリングの精度を上げないといけません。

---

■なので、ヒアリング前の調査が大事

　なので、ヒアリング前の事前調査が大事になります。
　ここで、うまくヒアリングができるように、事前調査が行けば、
　ヒアリングでの仕様漏れがすくなくなり、

　仕様変更が減り

　そうすると、品質はあがります。

---

■ところが、現在のソフトウエア工学は、ここに力を入れてない

　したがって、効率的な開発や、品質向上のための鍵は、要求仕様のとき、いかにシステムを正しく反映したヒアリングができるかどうかです。

　ここの研究を多くしない限り、品質は上がらないで、デスマーチが続き、情報化投資の成果は上がらず、結果として「ITの投資は一通り終わりました」となり、学生も寄り付かなくなり、衰退します。

　ところが、最近は、プログラミングに関しての研究は盛んなのですが、大量な業務情報をいかに正しく引き出すか(間違いを分かる＆足りない部分を見つける）という研究は、あまりされていません（情報処理学会論文誌などで、見ることはない。情報処理(学会の雑誌。表紙派手なほう）でもみません。

　なお、大量でなければ、論理的に考えればできるのですが、実際には、論理的に追っていけない場合に、問題が出ます(ユーザーの言葉を信じて破綻する）。

　現在の情報処理学会の研究は、（わざと？）大量の業務情報を扱わず、ある程度の情報量を用いてUMLのモデリングとか、形式仕様の話をしたりして、それ以降の作業に関して、とくにプログラミング部分に関して、話を発展させています。

　つまり、ゾウを冷蔵庫に入れる方法が知りたいのに、アイスクリームを華麗に冷蔵庫に入れる方法を議論しています。いや、アイスクリームなら、どうやっても、冷蔵庫に入るって（＾＾；）

---

　ってことで、次回は、要求分析について、ヒアリング前の事前調査を、現状はどうやっているか（いや、問題はあるんだけどね）っていう話を書こうと思います。

　

ファイルのアップロード(CGI,PHP,サーブレット,Struts）。

自分へのメモ

ファイルのアップロードをする方法について書いたもの

CGIは、前に取り上げた
HTMLでファイルをアップロードする書き方と、そのとき、サーバーにどう送られているか？ http://blog.goo.ne.jp/xmldtp/e/ebcabd358239818b03200f2abe0d1618


PHPの場合
第 38章ファイルアップロードの処理
http://php.s3.to/man/features.file-upload.html

サーブレット
ファイルアップロード処理を簡単にする（Commons活用）
http://www.atmarkit.co.jp/fjava/javatips/106jakarta018.html


Struts
●Struts－１８．ファイルアップロード
http://www.javaroad.jp/opensource/js_struts20.htm
もひとつついで
Strutsを使用したファイルアップロードのサンプル
http://struts.wasureppoi.com/util/01_upload.html


（あくまでも、自分へのメモで、CGI以外は、ためしてません）