アカウント名:
パスワード:
俺がいってるのは品質に関する内容ぐらい図面見りゃわかるだろうといっているのであって、図面を書けと入っていない。例えていうなら機械でいうこんな「▽▽▽」記号のことだ。
それで製品の品質がイメージできるか？ そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
無意味と思うのは作り手側のろくでもない意識の問題だけであって品質は、それを使う側の人間にとっては非常に大切なことだ。
それには同意する。
それに、「不可能」というのは、尺度や測定の方法が確立されていないだけの話であって真実ではない。
では、既に他の人にも言われてるが、あなたは示せるの？ 工業製品との違いを理解しないで、不可能ではない、方法が確立されていないだけでできるはず！などと言っても、本職からすれば妄想にしか見えませ
通常、他の工業製品では統計的手法というのは検査の作業を省略するための手法であって本当に重要なものに関しては、全品検査を行うのが普通である。
さんざん反論されてるのと同じ人？ 何度も言うけど、プログラムと工業製品の違いを理解しなさい。 全品検査とか、あほな単語が出てくるのが理解できてない証拠、プログラムって言うのは「一品」しか作らないものなの。 パッケージソフトみたいにお店に出荷してるのも、単にそれをコピー
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
発注側の責任でもある (スコア:3, すばらしい洞察)
と題してこういう問題を取り上げてた。
発注側もシステムをよく理解してないから、ほとんどメーカーの
言うなりになってきたけど、自治体が自分たちで業務を分析して
仕様書を書いて、機能をバラして発注してみたら、あーらびっくり
全然安くできちゃいました、みたいな話。
開発側のはしくれとして思うんだけど、こんなの当たり前だよね。
こういうお客さん、めずらしくない。
自分たちのシステムなのに、全然内容わかってなかったり他人任せ
にしてたりすることはよくある。そのくせひどいときには後から
文句だけは言ったりする。
いや工学として洗練されていないのが原因 (スコア:1, すばらしい洞察)
実際の話し、IT関連へ対する社会的なイメージは「最先端」、「高度」なんてイメージ持っている人多いようだけど、幻想に惑わされてはいけません。
機械でも、電気機器でも図面さえあれば高校でたての新人でもほぼ同じ品質の品物をイメージできるのに、そうじゃないのは情報関連ぐらいだよ。第一誰が見ても同じ物をイメージできる
Re:いや工学として洗練されていないのが原因 (スコア:0)
プログラムは文学で、システム構築は伝統工芸なんです。
そもそも １人月なんて換算式を適用するのが間違いなんだから...
(本来は結果で判断されるべき業界だと思います)
大体 工学分野という切り分けで考えれば最近20年間程度で
弱電気、電子、経営(工)、情報、知識 etc...
と大きな進歩と大きな広がりをしてれば工学として確立される訳がない。
(工学として確立された頃には利用されないあるいはそれ以上を求められます）
あとどういう意図かは判りませんが
機械でも、電気機器でも図面さえあれば高校でたての
Re:いや工学として洗練されていないのが原因 (スコア:-1, フレームのもと)
他の電気でも土木でもは図面中に品質に関する指示がきちんとされているぞ。情報分野で、「このモジュールはこの程度の品質でつくれ」なんて表現する記号なんかが一般化されてるか？
よく読め。全くこんなやつが発注者の意図しないもの作
プログラムの品質とは？ (スコア:0)
それで製品の品質がイメージできるか？
そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
Re:プログラムの品質とは？ (スコア:0)
＞そんなのでイメージできるのは部品の精度であって、最終的な製品としての品質ではないと思うぞ？
＞そもそもプログラムはそんな何ミリまで誤差があります、みたいな考えとは根本的に異なるものだし
▽▽▽を要求されている品物で～を想像するばか者は少なくとも専門教育受けていればいないだろう。少なくともおまえもそこまでバカじゃないだろう。要は、機械や電気では基本中の基本の精度や品質を情報関係ではあらわすことさえできていないところに未熟なところが残っているというこ
Re:プログラムの品質とは？ (スコア:0)
>あらわすことさえできていないところに
「できていない」じゃなくて「不可能」或いは無意味．
>未熟なところが残っているということを行っているのだ。
未熟なんじゃなくて，そもそも本質が異なる．
「ソフトウエアの品質」という言葉の意味さえ分かってない．
「精度がどれだけ」「何万Km走行しても故障するのはXX台辺り一台」
とかじゃなくて
「歴史に残る名車／名器」
の類に近い．
一個3億円のバイオリンと一個数十万円のレプリカは図面レベルじゃ
ほと
Re:プログラムの品質とは？ (スコア:0)
それが製品である以上品質は無意味なことはない。無意味と思うのは作り手側のろくでもない意識の問題だけであって品質は、それを使う側の人間にとっては非常に大切なことだ。
Re:プログラムの品質とは？ (スコア:0)
それには同意する。
では、既に他の人にも言われてるが、あなたは示せるの？
工業製品との違いを理解しないで、不可能ではない、方法が確立されていないだけでできるはず！などと言っても、本職からすれば妄想にしか見えませ
Re:プログラムの品質とは？ (スコア:1, 興味深い)
江戸時代の職人ならこんなこと言ってそうだな。昔の建築で使われていた釘を見てると同じ物なんて一つとしてない。それに比べ今のくぎなんて同じ規格のものなら違うもの探すほうが困難だろう。この原因はどこにあるのかというと、
1. 品物の図面があるのか
2. 作った品物がそのとおりにできているのか検査する手法が確立されているか
この二点に集約される。
逆に現状情報関連をみると、
1. 一応の図面に
Re:プログラムの品質とは？ (スコア:0)
さんざん反論されてるのと同じ人？
何度も言うけど、プログラムと工業製品の違いを理解しなさい。
全品検査とか、あほな単語が出てくるのが理解できてない証拠、プログラムって言うのは「一品」しか作らないものなの。
パッケージソフトみたいにお店に出荷してるのも、単にそれをコピー
Re:プログラムの品質とは？ (スコア:0)
やっと理解できたよ。プログラムは特別だといっている（思い込んでいる）だけなんだな君は。君みたいなやつらの横行がプログラムに関してはPL法の適用さえされない味噌くそ分野に追い込むことに貢献しているんだな。
他の分野で一品物の典型は、土木や建築の世界で往々にして見ることができるけど、恐ろしく品質要求基準高いよ。たとえば、鉄筋コンクリート製の橋なんかをあるところにかけたとする。何億もかけ、その橋を作ったあと検査の際に材齢強度が設計基準を満たしていないと、基本的に取り壊して作り直
Re:プログラムの品質とは？ (スコア:0)
>車両や人を通さないのが土木建築の分野の品質管理水準。
実際に橋が落ちたこともあるし、新幹線のトンネルからコンクリートの
塊が落下してあわや大惨事ということもあった。コールドジョイントが
原因でその後一斉検査をしてたよな。
タコマナローズ橋は静的な強度計算しかしておらず、カルマン渦列による
力に耐えきれずに崩壊したのだろう？建築史上に残る有名な事件だと
聞いている。
土建屋の「品質管理」なんてそんなもんだ。
ソフトウエアのバグ０はそれに比べて
Re:プログラムの品質とは？ (スコア:0)
あの話は、風による共振現象で確かに橋が落ちたのだが、その後のアメリカの建築学会の総力を挙げた原因の究明と計基準の見直しなど多岐にわたる対策により、その後のつり橋の設計基準が変わり同様の原因によりつり橋が落ちる事は世界的になくなった。つまり、業界の問題に対する取り組みを象徴する出来事なのだ。
実際に、新幹線のトンネル壁剥落事故にしても、神戸の震災の高架が落ちた事故も、最近では、新潟の地震にしろ、土木や建築の学会は大挙して学者を派遣し、さらに、お金にならないのはわ
Re:プログラムの品質とは？ (スコア:0)
知らなかったくせに無理しなくていいよ。
それにやっぱりソフトウエアの本質を分かってないド素人ゆえの発言だ。
>その後のつり橋の設計基準が変わり
>同様の原因によりつり橋が落ちる事は世界的になくなった。
「その後」の「同様の原因」に限れば「ほとんど」なくなっただけ。
「同じ失敗は（ほとんど）二度と繰り返さない」ということ。
新しい失敗原因についてはやはり失敗は避けられない。
ソフトウエアは一品ものであり、毎回要求事項も作るものも変化する。
だからたとえ「同じ失敗を二度と繰り返さない」とし
Re:プログラムの品質とは？ (スコア:0)
おまえ何も書かないほうがいいよ。話の本質を読む能力に決定的に欠けている。見てて痛々しくなる。タコマの大橋の話の本質さえ読むことができないとは情けない。
＞ソフトウエアは一品ものであり、毎回要求事項も作るものも変化する。
これこそこの業界の問題を反映している事例じゃないか。おまえ何度言っても理解できてない。土木がいやなら設備のほうの話をしてやろう。工場なんて日本中に何百万とあるけど一つとして同じ工場はない。たとえ同じ品物を作る工場を同じ時期に立ててもすべて違ってい
Re:プログラムの品質とは？ (スコア:0)
＞しかし、１０年後に今と同じシステム構築なんて誰もやっていないでしょう。
＞という事で、やはり１０年後にも同じ事を言っているように思います。
を書いたACですけど、ちょっと書いた意図を勘違いされているようですからコメント
技術の連続性が希薄な新技術を採用したときの効率がそうでない場合の数十倍であったらどうします？それでも技術の連続性を重視し効率の悪い方を選びますか？
実際にあった話ですが、４年前のシステムのリースアップに絡み新規システムを
Re:プログラムの品質とは？ (スコア:0)
実際にそれの検証が取れるのに分野にもよるが速いものだと数ヶ月遅いものだと数十年の歳月を費やすことさえあります。
実際の技術の伝播の過程を建築関連の典型的な事例を示すと大まかには以下のような形となっているようです。（私が携わったことがある少ない経験からの話なのでもっと別の過程をたどることもあるかもしれません。）
1.ある研究機関（企業や官等）が新しい技術を開発。
2.その研究機関が技術的な検証を行う。
3.学会への発表と第三者の検証。
4.検証が終了する。
5.検証の結果問題がなければ、建築基準法の改定または、省令が施行される。
6.一般的に使用しても問題がない技術として業界内で認知され、広く業界内で使用されるようになる。
基本的には、４までの間は適用した建築物に対する瑕疵には、適用した側が全面的に責任を持つことになるが、５の過程を経ると建築物に問題があった場合は施工に問題があるような特殊な事例を除き裁判でも不可抗力が認められある程度免責される仕組みになっています。
しかし、情報関連業界においては、完全な検証が終わる前に新しい技術が適用され、しかもそのことに対し、PL法の適用除外の項目にさえ上がっています（つまり使用者のほうに瑕疵の立証責任がある）。これは、製品を使う側にとっては、製品を使った時点で自己責任で片付けられ泣き寝入りの原因となるし、新技術開発者の信頼性技術の発展には全く貢献しない。そして、新技術のを使ったことに対する責任は免責されることはない。また、このような状態だから、新しい技術（だけではありませんが）を使った側にも使われた側にも個別契約以外の法的な保護もありません。
新しい技術が開発されること事態はどんな分野でもありますが、情報処理業界では、その生まれた技術に対する取扱が全くの無法地帯（他の業界から見ると未熟）となっていることに問題を感じているのです。
実際に、みんなソフトウエアのバグに悩まされたことが多いかと思いますが、このような無法地帯に手がつけられずにいるようであれば何時までたってもこの業界は変わらないでしょうね。
まあ業界トップの企業でさえ、金儲けするための技術開発はするが開発しっぱなしでそれに対する責任を果たさないようですからこの問題は根が深いことは認識しています。