ソフトウェア工学

ソフトウェア開発の決定的な方法論はできるのか？

「要求工学」とか「ユースケース」とか、誰か教えてたもれ。

方法論ってProcess Modelのこと言ってるの？

プログラマの作ったシステムは全く売れないんですが
どうすればいいのでしょうか？

たいていのソフト開発プロジェクトでは、
大金を溝に捨てることはいとも簡単に行われているらしい。
将来、このツケは誰にしわ寄せが来るのかな。

そりゃ、プログラマが作るからだろ（笑）＜売れない

役に立ってる？

１＞
最先端のソフトウエア工学は人文系分野だと思います。

人文系の作ったソフトは最悪。
まともなソフトは、エンジニア+ビジネスマン+デザイナーが作る。

＞８　意味不明。

まず対象となる業務を学ぶ事じゃな

ドキュメント書きばっかで疲れる。

設計デザインのドキュメントが完成する以前にプログラムを書いてはいけない。

＞１２
５年ほど前ですが
ソフトウエア工学は、離散数学と代数で終わりました。Ｃ＋＋や
オブジェクト指向プログラムやるだろうと得意げになっていたパ
ソコンの使い方ヲタクは初日に全滅して面白かったです。

基礎が分かってないとそうななるんですよね。

>15
確かにプログラミング言語は手段であって目的じゃないから
問題を分析する基礎力が無いとなんにもできません

離散数学と代数の基礎が出ない奴が書いたプログラムは
プログラムじゃなくてぼろグラム以下
でもそう言う奴に限って変に細かいところは知っていたり
することもたまにあるから困ったもんだ

>15 さん
文系の人としては気になるので少し質問です。

数学技術を使う特定分野（金融系など）に関するプログラムは
ともかくとして、例えば在庫管理等のプログラムにおいても
離散数学や代数の基礎は必要なのでしょうか？

私としては、最近のプログラムは数学的な技術を使う部分を
カプセル化して、それ以外の部分に注力する傾向があるように
思えるのですが。

（例：クィックソートを知らなくても C 言語関数の qsort の恩恵に預かることができる。）

# 数学によって培われる分析的思考という話は別として。

>（例：クィックソートを知らなくても C 言語関数の qsort の恩恵に預かることができる。）
あえて言うとこの一文にどういう意味合いがあるかご存じですか
クイックソートが有効な場合や有効でない場合、また処理時間の
算定などシステム運用を考えたときのレスポンスがどうなるかを
系統立てて考えないと動くけど実用に耐えないシステムができあがります

カプセル化したライブラリー等の活用や計算機のパワーでプログラミ
ングレベルでの数学的な負担は減ってきているとはいえ基本を押さえ
て置かないととんでもないプログラムを作る輩が多いです
特に事務系ではやたらとソートを使ったプログラムが多いというのは
そのよい例でしょう
ソートの奥義はデータをそうとしておくことです（有沢誠談）

ビッグ・オーとか知っといてそんは無いと思う。

適切な場所に適切なアルゴリズムを適用するのは、全くの
基礎なしでは難しいかもね。

複雑度知らずしてそのアルゴリズムを知っているとは言って欲しくないぞ。

オーダー知らなくても、実用上はあまり問題ない。
線形代数できても、プログラミングできるとは限らない。
・・・と言っていると、学問板じゃなくなってしまうが。

＞オーダー知らなくても、実用上はあまり問題ない。

その程度のお仕事なさってるわけね。

オーダー分かってないと適切なアルゴリズムが選択できない
つまり、まともなデータ構造が選択できない
よって必要以上に遅いものが出来上がる。

＞２０のような方が
データーの順番を逆にするのにソートキーの判定を逆にして
平気でqsortなんかかけちゃうんだよねこれが
理由を聞くとこーでんぐが楽だから

プログラムの内部処理には、
ソートとサーチ以外に何があるのですか？

システムが複雑化している現状で、
プログラマのスキルも様々になってきてるから、
そういう、全然知識がないけどプログラムを組む
人のために、ライブラリが進化するって
考え方はダメかな。
学問板としてはアレかもしれないけど、
コスト論で言えばコーディングが楽、とか
スキルの低いプログラマでも組める方が安い、
というような選択肢ってありますよね。
もちろんその後で処理に時間がかかってかえって
コストかかるなんてこともあり得るわけだけど（笑）

安易に出来合いのライブラリを使うのは良くない。
プロトタイプを作る実験のみで使うのはかまわないが、、、
実験で使ったライブラリは思い切って全部捨てよう。

何事も知らないより知っていたほうがよいことは、まったく正しい。
しかし、ちゃんとしたプログラマならO(n^2)とかO(nlogn)とか
知らなくてもほとんど適切なアルゴリズムを選択するものだ。
なぜかというと、頭の中に適切な処理のモデルがあるから。
O()が分からなくても、ループを何回回るかがイメージされている。
定量的には解析できなくても、イメージで定性的に理解されている。
プログラマとして重要な特性は、解析ができることよりも
頭の中で、そういうふうに処理を手順としてイメージして
組み立てららているかというところにあると思う。
逆に、線形代数や微分積分ができてもあほあほなプログラムを
組む奴はたくさんいる。そういう計算力より論理性が重要。

実際に処理時間が掛かっているのは、全体のうちの1割とか。
完璧主義よりも、ボトルネックから解消していく方が、経済的に正しい。
こだわりだすと、OSから(ハードから?)作らないといけなくなる。

＞２７
誰も微積の話はしていない
少なくても離散数学の基礎ぐらいはマスターしておくべきです
プロとしてやっていこうと思うならば少なくても以下のような本ぐら
いは目を通しておくべきでしょう
１．The Art of Computer Programing Vol1＠｀2 (Knuth)
２．アルゴリズム＋データ構造＝プログラミング（Wirth)
３．アルゴリズムの設計と解析１，２(Aho)
４．岩波講座　情報科学シリーズ
５．ｂｉｔ　共立出版

＞２８
そのボトルネックがスキルの低いプログラマーが作ったプログラム
だと言うことなんですけど
実際に実運用試験で引っかかるのは応答時間が悪いという不具合が多く
貴方の言う１割に該当する部分を直すだけで応答時間が一桁短くなるな
んて言う事例はごろごろしているよ

I agree with you.
But I think that those books are not on
math and linear algebla＠｀ but on compuer science.

algebla -> algebra

おお〜い＞３０＆３１＝２７＆２８か
ここは情報システムの板だろうが
それにソフトウェア工学に関するスレッドだろ
あんたが怒る筋合いはお門違いじゃないかい（笑）

話がかみあってないな。
だからよかったねっていうことじゃないの?
1度しか実行しないようなところに効率考えるのは無駄ってこと。
で、1割の部分に傾注して改良できたんだから良かったんじゃないの。
そもそも、1割の部分に馬鹿プログラマを割り当てたのがおかしいわけ。

＞３３
何時もくだらないプログラムの尻拭いさせられている身として脱線したけど
その一度と言うのがくせ者でね動いているのが有れば使ってちまえと言う不
逞の輩がいるからよく考えもせず使い回すんだよねオブジェクト指向になる
とその傾向がもっと酷くなる
まぁ確かに上に上げた参考書は線形代数学の本じゃないけどプログラミング
を線形代数を用いて解説してあるという意味じゃ一読の価値はあるよ

>29
4、5はともかく、1-3は最近あまり流行らんよ。
Ahoのは、例の「ドラゴン・ブック」はまだ現役っぽいけど、
ありゃコンパイラだし。

アルゴリズムで流行りの教科書は、やっぱし"introduction to algorithms"
で決まりでしょう。白くてぶっとい奴。

離散数学は、これだ！と薦められるのを思いつかないけど、
英語版のほうが遥かにセレクションが多いと思う。
、
CSの教科書は、簡単な英語で書いてあるのが多いので、AMAZON
あたりで流行の教科書を漁ってみるのが吉。

それは単に教科書として使われるかどうかという流行の話じゃないの？
３あたりの内容は執筆が古いからといって out of date な内容だとは思わないけど。

プログラミングやアルゴリズムの本で、
ノルムや逆行列が出てくるものってほとんどないと思うんだけど。

＞実験で使ったライブラリは思い切って全部捨てよう。
これは、心構えとしては偉いと思うんだけど、
ソフトウェアの再利用促進と部品化・規格化という
ソフトウェア工学の概念に反するところがある。

32の人ではないけど、
実験で使ったコードから得た結果をもとに、再利用すべき部品や、
パラメータを検討して、再利用可能な部品として構築しなおすと
いうことではない？

結構アメリカの教科書業界と言うのも競争が激しいみたいで、
日々新しい工夫がされた教科書が出版されてます。
で、もちろんクラシックな本もいいんだけど、有名な大学で
こぞって採用されているような新しい教科書は、それなりに
わけがあって採用されているわけで、一度手にとって見られる
ことをお勧めします。クラシックな本の内容を踏まえた上での
分かりやすい記述がなされているのも多く、特にこれから勉強
される方にはとっつきやすいと思います。

Introduction... については既に中身知ってます。
確かに分かりやすくて良い本です。
実はひとに勧めるのも最近はこの本（日本語訳は三冊になってますが、経済的には原書買った方がお特ですね）。
Aho らの本については確かに院生レベルなら良いかも知れませんが学部生にいきなりはつらいのかな。
実際 29 の本の後に学部生向けの本が出てて序文でそれっぽい事言ってましたね。
あと Kunuth 本についてはソート一つ取っても他の参考書ではなかなか出てこないトピックなんかも載ってて、内容的には今でも価値は大きいと思います。

いずれにしても取っ掛かりの教科書としては確かに新しい方が色々考慮もされてて良いでしょうね。

なるほど。そりゃ知っていた方がいいに決まってますよね・・・

ところで、いくつか教科書が紹介されていますが、
その中で比較的安価ものはどれでしょうか？
値段で本を選ぶのは心苦しいのですが、財布が理性的選択を許さないもので（笑い）

＞１．The Art of Computer Programing Vol1＠｀2 (Knuth)
＞２．アルゴリズム＋データ構造＝プログラミング（Wirth)
＞３．アルゴリズムの設計と解析１，２(Aho)

うーむ、まあ、上の本は名著ではあるが「ソフトウェア工学」
ってのとはちょっと違うんじゃねえか？

どうせなら、D.Griesの「プログラミングの科学」なんて
のはどうだい。金槌でアタマ殴られるくらいのカルチャー
ショックがあるぜ。プログラムの正当性は論理的に証明
される必要があるなんてこたあ、日本のソフト屋のアタマ
にはゼンゼンないだろうからな。

Dr.Gさん、こんにちは。

大学じゃソフトウェア工学と称してソフトウェア科学
教えてる先生が多いからなぁ。
ソフトウェア工学なら、Alan.M.Davis の
「ソフトウェア開発２０１の鉄則」 とか、
Gerry Weinberg のシリーズとか、Yordon の本とか
を勧めた方がいいだろう。
マイケル・ジャクソンの「ソフトウェア博物誌」
は、その後読むように。

また古い本が出てきましたね。
プログラムの正当性うんぬんについても今ならもう少し新しい本がありそうですね。
Jeffrey H Kingstom の Algorithms and Data Structures(Design＠｀ Correctness＠｀ Analysis)
なんかでも正当性の話はでてきてたような気がします。この本では言語としてEiffelを使ってます。
正当性の証明も大事ですが、その前にプログラミングとは構成的証明に他ならない（と言い切ると御幣がありますが）という事は広く認識されてもいいですよね。
でもここはソフトウェア工学のスレッドでしたか。

＞４５
科学なくして工学もなしというところなのでしょうか？
科学的知見（心理的側面も含む）なくしては適切な工学も成り立ち得ないからなのではと思います。

Brooksの「人月」は外せないでしょう。

＞４６
パソコンも洗濯機や電子レンジのように家電製品となり
大衆文化になったわけだからソフトも工学じゃなくて
文化に変わってきているのだと思います。

意味不明。
工学が科学と置き換わるものではないのと同様文化も工学と置き換わるものではない。

　確かに使い方は、文化になってきているけど、
　ソフトやハードは工学だとおもう。

たしか MITかどっかの学部向けで Scheme 使った教科書ってのが
あって、最近邦訳がでたんじゃねーかい？

しかしなー、教科書レベルの話と現場レベルでの話しっていうのは
俺にはなかなかむすびつかんわい。

何か有名所のソフトでそういうのあんのかい？

だーれーがーパソコン便利にしてきたのかーをー
考えましょうねー。

あとから乗っかってきて文化だとかしたり顔でいう奴らは
どこにでもいるけど、あんまり話しを一般化しすぎないように
注意しましょう。

Structure and Implementation of Computer Programs ですね。
良い本です、だけだと他の本と同じ位になってしまうので、大変良い本です、と表現しておきます。
第二版なのですが訳者もあの和田先生という事もあり期待できます。
サイズもＡ４版と扱い易くなっている上、無駄に字が多く空白の多い紙面構成はとっていないのも訳者の良心が感じられます。

なお、教科書レベルと現場レベルを結びつけられるかどうかは技術者のレベルに依存します。

○無駄に字が多く
×無駄に字が大きく

＞５２
意味不明。

４８です。
皆が認める良い技術、良い商品だからこそ家電製品になるわけです。
人が良いと認める（マーケットが広がる）ことこそ技術で最も光栄な
評価のされ方だと思いますけど。技術とは一体何で評価するか考えて
みましょうね。

技術的にベストだからって、必ずしも
マーケットでシェアを取れるわけでは
ないよ？電化製品でもパソコンでも
その点は同じ。

電化じゃなくって、家電の間違いね。

良いものだから、売れるとは限らないね。
悪いものだから、売れないとも限らない。
良いものだと思わせるものが、売れるのね。きっと。

＞４６

＞また古い本が出てきましたね。

俺はこの本でゼミやったんだよ。
ちなみに師匠はこの本の訳者だ。（＾＾;）

＞プログラムの正当性うんぬんについても
＞今ならもう少し新しい本がありそうですね。

今なら林晋氏の「プログラム検証論」を薦めるね。

＞正当性の証明も大事ですが、その前にプログラミングとは
＞構成的証明に他ならない（と言い切ると御幣がありますが）
＞という事は広く認識されてもいいですよね。

カリー＝ハワードの原理だろ。
日本じゃ佐藤雅彦氏（電通のCMプランナーにあらず＾＾；）
が「構成的プログラミング」を提唱し、前述の林晋氏がこの
考えに基づいてプログラム抽出系PXを作ったのは有名だ。

↑
おっさん、みっともないぞ。

＞４３
定番の本ですね。学部でやりました。
art of computerは、プログラムは設計手法が完璧でない時代で
あってまさに才能の必要性は芸術並みと著者が言いたかったので
しょう。しかし、離散数学という公平なツールがあればセンスの
ない私でも理解できます。私のような才能のない者にも道を開い
てくれる本としてありがたいものでした。

どゆこと？＞６０

The Art of Computer Programing の"art"って芸術なくて、「〜術」とか「技」ぐらいの意味だと思っていましたが、
本当のところはどうなのでしょうか？＞英語の達者な方
＃「職人技」 = 「芸術」 とするなら、いいのかもしれませんが。

６１です
＞６２
あの本は学部の頃読みましたが、職人技≠芸術だと思います。
プログラムを作ることは言語なので慣れれば誰にだってできますが、
それは所詮コード書きです。作者の言いたいのは慣れればできるも
のではなく離散系の芸術の解説書みたいなものという印象を受けま
した。

なぜ、ソートのオーダーでオイラー定数がでてくるか？みたいなこ
とを前に出したかったのでは？職人と理解すると、単なる例文集に
なってサイエンスが消え去り計算機語学になってしまうと思います。

64>
そっち方面に関心があるなら、"Concrete Mathematics"の方が
オモシロイでしょ。でもそりゃ離散数学だよなあ。

ソフトウェアの理論ってのは、どっちかっていうと数学基礎論
よりじゃないか？もちろん、オレがそっち方面の出身だってのは
あるけどな。

"The art of 〜 "って、もともと、高級万年筆メーカーのモンブランのコピーで使われている"The art of writing"を面白くもじっただけなんじゃないの？

>66
孫子をご存じない？
The Art of War

知りませんでした、そこまで大昔とは。勉強になります。>67

同じく。勉強になりますなあ。

ソフトウェア工学と、数学基礎論よりの
ソフトウェア理論は分けて考えた方がいいぞ。>Dr.G
理論は理論で重要。それは認める。
でもそっちにばかり気を取られて、肝心の「ソフトウェア工学」
が全く発達していないのが悲しいかな日本の大学の状況。
IEEE Software 並の雑誌が日本で出るようになんなきゃね。

＃でも俺も Concrete Mathematics はオモシロイと思う。

７０＞
ワシにいわせれば「ソフトウェア工学」なんてものはない。
「ＯＳ工学」とか「言語工学」とか「ワープロ工学」とか
「データベース工学」とかいうならともかくな。

かくいう私はリアルタイムシステムの一つである「＊＊システム」
の研究をしている。この件に関しては日本で第一人者といっても
いいな。何しろ他に研究してる奴がおらんのだから。ま、ＩＥＥＥ
の雑誌程度で世の中わかったつもりになってるようじゃ日本人は
まだまだ世間知らずの黄色いサルだな。ギョウカイ別の細かいネタ
をだれがそんなデカイところに書くか。いっとくが本当の工学は、
もっと小粒だがピリリと辛いってもんだ。(＾＾;)

アメリカってのは「知」がちゃんと「お金」になるところだ。
なにしろテッテイテキに実力主義なのだからな。大学でアホな
学生にチーチーパッパなんかやってるのは、はっきりいって
ジマンにもなんにもなりゃしない。もしいい研究ができたら、
さっさと大学なんぞ辞めて、ベンチャー企業を作るってのが
アメリカだし、大学のほうも、ただ辞められても損だから、
自分とこでベンチャーやって、金稼ごうとなかなか商魂逞しい。
おい、７０、わかってるか？

>ワシにいわせれば「ソフトウェア工学」なんてものはない。
あぁ、ここにもいた。
個別の技術の発展だけが工学だと思ってるアホが。
っていうかＤＢ工学とソフトウェア工学の違いも理解してないな。ふぅ。

しかもアメリカ盲信主義ときたもんだ。
日本的システムも理解しないで「アメリカはうらやましい」だ。
そんなにうらやましければ、さっさとアメリカに行って
ストックオプションで大儲けしててください。
まぁ日本で一人しかやってない研究で「日本一」だとか
2Ch で威張ってる奴にできればね♪
間違っても工学者とは名乗らないでくれ。頼むから。

下らん突っ込みはおいておいて、
ソフトウェア工学の話しをしましょうや。

私はあまり知らないけれど、職人的作業が
まだまだ重要であるソフトウェア生産現場
において、その職人達は一体何を学べば良
いのかが知りたい。

分析、設計、実装の技術は色んなところで話題になるけど、
テスト法やデバッグ技術は話題にならないね。重要なのにね。
管理者なら構成管理（バージョン管理）や測定（メトリクス）、
見積もりや計画、外注管理あたりも重要じゃないっすか？

設計とか、実装もだけど、結局一番難しいのはテストだねえ。
大学の研究では、正面向いて、テストの研究しているところって少ないような。
学会論文も少ないけど。あんまり、評価されない分野？

＞あぁ、ここにもいた。
＞個別の技術の発展だけが工学だと思ってるアホが。

あぁ、ここにもいた
個別の技術を避けて、一般論で満足してるアホが。

ま、マイケル・ジャクソンの「ソフトウェア博物誌」でも読むんだな。

＞っていうかＤＢ工学とソフトウェア工学の違いも理解してないな。

どうせオヌシのいう違いは、DBはソフトウェアじゃないとかいう
些末なモノだろ。トーシロの典型だな。

＞しかもアメリカ盲信主義ときたもんだ。

おっと、IEEEがどうたらこうたらいってた奴こそ
アメリカ盲信の極致じゃねえか。

オレがいうのはアメリカの社会ってもんが、
アメリカの技術を支えてるってこった。

＞まぁ日本で一人しかやってない研究で
＞「日本一」だとか 2Ch で威張ってる奴にできればね♪

そのコトバ忘れるなよ。（ニヤリ）
研究もしてない奴はビリにはなれても一番にはなれんだろ。
要するに単にゴクツブシってところだ。ま、うだうだ文句を
いう暇があったら首でも括って彼岸にでもいっちまいな。
オヌシのエサを犬に食わせたほうがマダ世の中のためだぜ。

７５＞
＞分析、設計、実装の技術は色んなところで話題になるけど、
＞テスト法やデバッグ技術は話題にならないね。重要なのにね。

７６＞
＞設計とか、実装もだけど、結局一番難しいのはテストだねえ。
＞大学の研究では、正面向いて、テストの研究しているところって
＞少ないような。

をひをひ、モデルチェッキングや証明の話がテストやデバッグとは
全然別のことだと思ってるなら相当理論音痴だぜ。

モデルチェッキングってのはいわば効果的なテストの技術だろうし、
正当性証明ってのは、デバッグを「論理」を使ってやろうってもの
だ。

世間じゃ、理論もなんも知らんトーシロが、「理論と実際は違う」
と抜かしやがるが、理論はちゃんと実践を意図してるんだよ。
さらにいえば理論がすすまねえってことは、それだけ現実の問題
がムズカシイってことで、横丁いったら実は近道なんて上手い話が
ゴロゴロ転がってると思ってるなら、相当オメデタイね。

>77
ちょっと待て。

どんな研究してるのかは知らんが、
「ソフトウェア工学」っていうものは「ある」。

79>
＞どんな研究してるのかは知らんが、
＞「ソフトウェア工学」っていうものは「ある」。

そりゃ「ある」だろうよ。問題はそいつがホントに
「ソフトウェアの工学」なのかどうかってことさ。

オヌシ、自分のやってる学問について一回も批判の目を
向けたことがないのかい？そいつは愚劣ってもんだぜ。
人がいうこと赤ベコみたいにうなづいてバカみたいに
やってりゃ評価されるって思ってるなら学者なんか
やめてイナカで米でもつくってたほうがいいな。（￣ー￣）

>80
誰が学者だって言った？

世の中で学者が一番えらいと思ってるようなくちぶりだな。

Dr.G さんのつまらない煽りは気にしないで、
Dr.G さんの思ってらっしゃるのとは違うソフトウェア工学
の話をしましょうよ。>ALL
学者だろうがなかろうが関係ないでしょ。
理論や学者が偉いのはよく分かりましたよ。

実際にテストとか見積もりを、勘や経験じゃなくて
「現場でも分かりやすい」きちんとした方法で
やってるところってあります？

Gさんが言ってることって、ミクロ経済学でマクロ経済が
説明できるってなことでしょうね。たとえ悪いかな。
量子論で薬品生成の有機化学を、説明しようってことかな。
Gさんの大好きな論理数学と、実際のソフトウェア開発は、
規模が違いすぎると思います。理論がだめとかそういうのではなく。
だから、「ソフトウェア工学」という、ある程度大きな
プロジェクトを成功させるための方法の研究が必要でしょう。
科学よりも実践に近い「工学」として。

論理を使ったデバッグってＩ／Ｏ込みでできるんだっけ？

８３＞
＞論理数学と、実際のソフトウェア開発は、
＞規模が違いすぎると思います。

バグは規模と関係なく現れるぜ。

いっとくが、どんなソフトも小さなモジュールから出来る。
機械が馬鹿でかいからといって、ネジの精度を落とすバカはいるまい。

もし、本当に「実践」が大事だというなら、おぬしのように
「ネジなんかどうでもいい」という態度では死ぬぜ。

８４＞
＞論理を使ったデバッグってＩ／Ｏ込みでできるんだっけ？

Ｉ／Ｏ込みなら論理は要らないっていうのかい？

まあ、そういうことをいうのは勝手だが、それなら
飛行機が制御システムのバグで落っこちても文句
いわないでくれよ。（￣ー￣）

＃実際にはＮＡＳＡ等は航空機のシステムの安全性検証の為に
＃フォーマリズムの利用を積極的に研究している。

分かった分かった偉いよフォーマルメソッドはさ。
何でもできるよ。さすが早大出身だ。偉い偉い。

じゃああんたのフォーマリズムとやらでWindows2000
のバグでも見つけて直してくれよ。
俺達が困ってるのは現場なの。研究じゃないの。
最初から頭の良い人が作れるわけじゃないの、現場は。
だから論理の話はやめてくれ。俺達はバカだから分からん。
ここで発言するんなら、「使いやすい」フォーマルな方法でも
紹介してくれよ、あんたならできるだろ。>Dr.G

８７＞
＞俺達が困ってるのは現場なの。
＞最初から頭の良い人が作れるわけじゃないの、現場は。

アホがモノ作るほどキケンなことはないな。
今すぐ辞表かいて辞めてくれ。他の職場ならいくらでも
世話してやる。但しソフト業界は駄目だ。君の作った
ソフトのバグで世界が破滅したら、責任とれまい。
イナカで米でもつくってくれ。まあ、多少マズくても
食べられないことはあるまい。（￣ー￣）

今、バカであることは仕方がない。
しかしながら、バカであることに開き直って
向上する努力を徹底的に回避することは
許し難い。「尻拭い」は誰がすると思って
いるのか？君、人の尻拭いが好きか？キライだろ。
じゃ、人に尻拭いさせるんじゃない。

オレもバカだが、バカであることを「善し」と考えたことは一度もないぞ。
甘えたこといいやがるんじゃねえ。このクソッタレ野郎！

はいはい。バカでもアホでもクソッタレでもいいですよ。>Dr.G

そんなことより現場のソフトのバグをどうするか、ですね。
開発のしわ寄せが後工程に全部来てしまうのが悩みです。

なんかカッコ悪い。
付け加えていって、言い訳みたい・・・

＞いっとくが、どんなソフトも小さなモジュールから出来る。
＞機械が馬鹿でかいからといって、ネジの精度を落とすバカはいるまい。
だからって、ソフトウェア工学というものがない理由にはならない。
お前は、この文章の中でみずから、基礎論（ネジ）だけでは
大規模ソフトウェアが構築できないことを、認めている。
基礎論の話は、別のスレッドでやってくれ。
ここでは、ネジの加工から上のレベルの話をしている。

要するに、
”技術馬鹿は実践が伴わないことが、ままある”
という見本がここに在るということだな。

現場に苦労をかける典型的なタイプだ。

Dr.G に百歩譲るとして．．．
NASA とか DoD みたいな超高信頼性システムならともかく、
"Good Enough Quality（そこそこ品質）"でよいシステムで、
フォーマルメソッドやクリーンルームって、どこまで
使われてるんでしょうかね？ＩＢＭの人読んでないかな？
使えるんなら数学でもなんでも勉強するけど、理想論じゃイヤよ。

どうもあなたの使う語彙・言葉ってのは意味が分かりにくいですねぇ。
フォーマリズムってのは形式的手法って事？
で、それは形式論理の事？
プログラムの正当性の証明という文脈ででてくる「論理」の枠組には
Ｉ／Ｏは出てこれないし扱えないんじゃなかったの？
せめてそういうものを扱うための形式論理の研究もある位言ってくれないと。

omae iranai deteike!! deiri kinshi! > Dr.G