アカウント名:
パスワード:
ビルド寸前までコードを書く行為はすべて設計です。設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
逆でしょう？同じ試験仕様書を通ればどのソフトも同じ品質です。は正しいです。試験仕様書から漏れた項目があってAでは対応しているがBでは対応していなかった場合それは「試験仕様書の品質」が悪かっただけでソフトウェアの品質としては同じですよ。
ソフトウェアの品質とはテストの結果で得られるものであって書いてあるから得られるものじゃないです。
そうでしょうか?
定量的に測れるところだけで勝負ということは、結局コスト競争だけに終始して構わない、という宣言でもある。そういうのって作り捨て(あとで増強・改良しようとも思わない)のアプリではいいかもしれませんが、のちのち拡張して使うことを考えていれば、テストでは測りきれない「品質」というものもある。
そういうものをアウトソースするな、という意見ならわからなくもないですが。
テスト屋さんとか品質管理系の人の言う「品質」とは、性能が高いことではありません。お門違いです。
現在の日本だとアウトソーシングされるプログラムなんて数こなしてなんぼの仕事ばかりなのだから必要とされるのは「要求を満たすプログラム」であって「仕様を満たすプログラム」でもなければ「品質の高いソースコード」でもないと思います。
可読性が高いのは「ソースコードの品質」が高いだけで同じ機能であった場合ソレを利用する元の発注者から見れば「同じ品質のプログラム」であってその品質を担保するのは元受の受け入れテストの結果だけです。
ようするにこの同じ品質っていうのはどこから見たときなのかがわかりません。
機能実現性やバグ数という意味ならそうでしょうねー
しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
>機能実現性やバグ数
それ以外のものをどう評価する？評価する意味ある？確かに頭悪いなーというときはあるけど、どっかで割り切らないとしょうがないんだよね。
試験仕様に表しにくい抽象的にしか評価できない品質項目はありますよね
それをワリキリでやるか、ガチガチルールで抑えるか、どんぶり指標で抑えるかの方法論はともかく何かしら実践しないと
アウトソースに出して納められた物を将来に渡ってメンテするのは誰？になっちゃいます
まぁ、パフォーマンステストとかにも現れないならソレは受け入れるしかないわな
いまどき行数で価格なんか量らないしね
>しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
最終的に生成されるオブジェクトの許容サイズなども仕様書に含めておけばよかったのでは?
非機能項目で差が出ることはよくありますよ。ソースの可読性は代表的な非機能項目。しかし品質としては重要。
ならばそれも試験仕様に加えればよろし。
受け入れテスト工数が膨らんでアウトソースにする意味がなくなる。
つまり、全てを網羅した試験でない限り、通ったからと言って同じ品質とは言えない。でも、「同じ試験仕様書を通れば」という記述はその試験仕様書が全てを網羅していると表現していない。ソースの全てのルートを通るとかいう単純な話ではなく、全てを想定した試験仕様があれば、通れば同じ品質と言えるが、それは即ち、そうやって試験を通ったプログラムは無謬であることに他ならない。
さて、そんな試験仕様を書ける奴が、世の中に一体どんだけいるかな？
お前以外は全員できるよ。
例えば、非負整数nについて必ずn+1を返す関数であることはどうやって確かめるの？ほかにも、複数のスレッドによる加算が必ずアトミックに行われることなど
ブラックボックステストしかやったことない人？
>ブラックボックステストしかやったことない人？
もしかして、>>コードカバレッジという言葉はご存知ですか？という寝言を書いた人と同じ人？
あまりに低レベルなので、もう出てこないでほしいのですが。あなたのレベルだと、とりあえず「バグのないことを証明」あたりでぐぐると良いかも。
自分の理解力を越えているものは低レベルですか。簡単そうな生き方ですね。
１．想定される入力の最小値と最大値で戻り値が正常である事を確認する。最大値は無限とか言うなよ。 馬鹿なら最小値-最大値でループを回せ。 （想定されない入力についての動作はまた別のテストで確認）２．問題が想定される条件を網羅してその条件でスレッドを実行する
上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。で、「お前以外は全員できるよ」という事なんだよ。
１．最小値-最大値でループを回さなかったとしたら、想定される入力の最小値と最大値の間の値で、戻り値が正常である事を確認したわけじゃなくて、単なる期待に過ぎないのでは？２．たまたま正常に動作したとしても、正しい同期制御ができているとは限らないのでは？
>上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。>で、「お前以外は全員できるよ」という事なんだよ。上の文と下の文の論理に飛躍があるようですよ。私にできないことがあなたにできても何の不思議もないですが、それは私とあなたとを入れ替えても同じことが言えるのですよ。
小学生の言い訳というのはこういう事か。
横だけど、計算機科学とSI現場主義との間の深い溝をこのスレッドに見た気がする。一応僕は計算機科学側なので、「お前以外は全員できるよ」に対しては「できると思ってるだけで、できてる保証はどこにもないよ。現実的にシステムを動かすのにどこまでリスクを飲み込んで妥協するか、という判断をしてるだけでしょ。」と返したいところ。
その割には、試験をした筈なのにバグのあるソフトが多いようで。余程みんな手を抜いてるんだね。
いや、いきなり、自分と自分の周りのレベルの低さをゲロされても...
反論できなくなるとレッテル貼りですか。
まあ、いいから涙拭けよ。
いや、単に無能なSEと有能なSEの間の溝でしょ。
有能なSEが普通にやってることを、無能なSEが「俺様にできないことがお前ごときにできるわけがない」って騒いでるだけ。
そこまでいくと試験という行為範囲に収まらずに、設計するという行為と不可分なんじゃないかなあ。
外注先をそのへんで信用できないなら、作成中コードのレビュー工数はマネージメント工数として積むべきものよね。
>ソースの可読性そういう項目は評価に客観性が欠けるんだよね。客観性を持たせるならば、最初に規約でガチガチにして、規約に反しているかどうかしかでしか判断できない。そうすると、100行ですむところが5000行になったりするんですよ。
で、「ぬるぬる動く」とかいう数値化できない指標は一顧だにされないからAppleはおろかサムスンにすら完敗すると。
Appleはともかく、サムスンを引き合いに出すのは疑問。googleじゃね？そうすると、ほら、あんまりくやしくない。
googleだと「ぬるぬる動く」という項目も自動で評価可能にしているかも。
まあ正直言って一連の流れは「開発作業は複数で分担しなければならない」という観念から生じているので正直、クソだとは思っています。
それはソースコードの品質であって動作に影響がでないのならばソフトウェアの品質に影響はないよ
酷い場合には（というか、普通の日本企業では？）それをコーディング規約として強制したりする会社もあるようです。
たとえばこんな感じの。「例えば、承認の機能No.1のパッケージは、 jp.co.kmotor.shouninkun.A01F001 となり、その下に、A01F001L001.java のようなクラスを作成していくことになる。jspの階層も/shouninkun/A01F001/A01F001P001.jsp のように、対応するパッケージ名と一致させていく。」「この命名規則は変更できないんでしょうか？」「できませんね」橋本さんはきっぱり答えた。「これは弊社のプログラム
ソフトウェアの品質にソースの品質が含まれない世界なんてあるんですかね？ゲームのパッケージを買うんならともかく、アウトソースで。
アウトソースだからこそ、ソースの品質程度の事は割り切るべきだと思うけどね。割り切れないか、品質を管理できないなら、それはアウトソースすべきものじゃなかったという事だ。それこそ、ゲームのパッケージを買うのと同じ事なんだからさ。
アウトソースだからこそ、そういう部分の品質の体験談を共有しておくことが重要なのでは？ と逆方向に思いますが。
このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
(a) テスト仕様もまともに書かず、常識的な品質として○○すべきだ(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ
aについては同質幻想であって論外。bについては十分条件しか述べておらず、これで品質を議論するのもエンジニアとして不見識と言いたいですね。
> このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
今まで見たことがある中国 (上海周辺) 、北米 (西海岸) のIT産業の大半の企業は同じような問題を抱えていますし、これらの問題を抱えていない企業は数えるほどしか知りませんが、日本のIT産業だけに限定しているのはなぜでしょう。この手の問題がまれな国や地域をご存知でしたらぜひ教えて下さい。
いや、多分ダメなのはあなたの頭だと思う。
>(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ誰もそんな事は主張していない。
(b')要求する品質を担保するためにテスト仕様はつくられるべきであるというのが正しい。
禿同
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
プログラミングは設計 (スコア:3)
ビルド寸前までコードを書く行為はすべて設計です。
設計を外部に任せるためには、相応の信頼と権限の委譲が必要です。
納得行くものが出来上がらずに細かな指示をしていくというのは、自分で設計する部分を増やしているだけです。
Re: (スコア:0)
同じ試験仕様を通りさえすれば、どのようなソフトも同じ品質です
と宣言してたバカがいたな
Re:プログラミングは設計 (スコア:0)
逆でしょう？
同じ試験仕様書を通ればどのソフトも同じ品質です。は正しいです。
試験仕様書から漏れた項目があってAでは対応しているがBでは対応していなかった場合
それは「試験仕様書の品質」が悪かっただけでソフトウェアの品質としては同じですよ。
ソフトウェアの品質とはテストの結果で得られるものであって書いてあるから得られるものじゃないです。
Re:プログラミングは設計 (スコア:1)
そうでしょうか?
定量的に測れるところだけで勝負ということは、結局コスト競争だけに終始して構わない、という宣言でもある。
そういうのって作り捨て(あとで増強・改良しようとも思わない)のアプリではいいかもしれませんが、のちのち拡張して使うことを考えていれば、テストでは測りきれない「品質」というものもある。
そういうものをアウトソースするな、という意見ならわからなくもないですが。
Re: (スコア:0)
テスト屋さんとか品質管理系の人の言う「品質」とは、性能が高いことではありません。お門違いです。
Re: (スコア:0)
現在の日本だとアウトソーシングされるプログラムなんて数こなしてなんぼの仕事ばかりなのだから
必要とされるのは「要求を満たすプログラム」であって「仕様を満たすプログラム」でもなければ
「品質の高いソースコード」でもないと思います。
可読性が高いのは「ソースコードの品質」が高いだけで
同じ機能であった場合ソレを利用する元の発注者から見れば「同じ品質のプログラム」であって
その品質を担保するのは元受の受け入れテストの結果だけです。
ようするにこの同じ品質っていうのはどこから見たときなのかがわかりません。
Re: (スコア:0)
機能実現性やバグ数という意味ならそうでしょうねー
しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
Re: (スコア:0)
>機能実現性やバグ数
それ以外のものをどう評価する？評価する意味ある？
確かに頭悪いなーというときはあるけど、どっかで割り切らないとしょうがないんだよね。
Re: (スコア:0)
試験仕様に表しにくい抽象的にしか評価できない品質項目はありますよね
それをワリキリでやるか、ガチガチルールで抑えるか、どんぶり指標で抑えるかの方法論はともかく
何かしら実践しないと
アウトソースに出して納められた物を将来に渡ってメンテするのは誰？になっちゃいます
Re:プログラミングは設計 (スコア:2)
Re: (スコア:0)
まぁ、パフォーマンステストとかにも現れないならソレは受け入れるしかないわな
Re: (スコア:0)
いまどき行数で価格なんか量らないしね
Re: (スコア:0)
>しっかし100行で表現できるコードを5000行に膨らまされた時にはどーしようかと思った orz
最終的に生成されるオブジェクトの許容サイズなども仕様書に含めておけばよかったのでは?
Re: (スコア:0)
非機能項目で差が出ることはよくありますよ。
ソースの可読性は代表的な非機能項目。しかし品質としては重要。
Re: (スコア:0)
ならばそれも試験仕様に加えればよろし。
Re: (スコア:0)
受け入れテスト工数が膨らんでアウトソースにする意味がなくなる。
Re: (スコア:0)
つまり、全てを網羅した試験でない限り、通ったからと言って同じ品質とは言えない。
でも、「同じ試験仕様書を通れば」という記述はその試験仕様書が全てを網羅していると表現していない。
ソースの全てのルートを通るとかいう単純な話ではなく、全てを想定した試験仕様があれば、通れば同じ品質と言えるが、それは即ち、そうやって試験を通ったプログラムは無謬であることに他ならない。
さて、そんな試験仕様を書ける奴が、世の中に一体どんだけいるかな？
Re: (スコア:0)
お前以外は全員できるよ。
Re: (スコア:0)
例えば、非負整数nについて必ずn+1を返す関数であることはどうやって確かめるの？
ほかにも、複数のスレッドによる加算が必ずアトミックに行われることなど
Re: (スコア:0)
ブラックボックステストしかやったことない人？
Re: (スコア:0)
>ブラックボックステストしかやったことない人？
もしかして、
>>コードカバレッジという言葉はご存知ですか？
という寝言を書いた人と同じ人？
あまりに低レベルなので、もう出てこないでほしいのですが。
あなたのレベルだと、とりあえず「バグのないことを証明」あたりでぐぐると良いかも。
Re: (スコア:0)
自分の理解力を越えているものは低レベルですか。
簡単そうな生き方ですね。
Re: (スコア:0)
１．想定される入力の最小値と最大値で戻り値が正常である事を確認する。最大値は無限とか言うなよ。
馬鹿なら最小値-最大値でループを回せ。
（想定されない入力についての動作はまた別のテストで確認）
２．問題が想定される条件を網羅してその条件でスレッドを実行する
上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。
で、「お前以外は全員できるよ」という事なんだよ。
Re: (スコア:0)
１．最小値-最大値でループを回さなかったとしたら、想定される入力の最小値と最大値の間の値で、戻り値が正常である事を確認したわけじゃなくて、単なる期待に過ぎないのでは？
２．たまたま正常に動作したとしても、正しい同期制御ができているとは限らないのでは？
>上にもでてるけど、基本的にさ、「俺様にできないことがお前ごときにできるわけがない」って言い張ってるだけでしょ。
>で、「お前以外は全員できるよ」という事なんだよ。
上の文と下の文の論理に飛躍があるようですよ。
私にできないことがあなたにできても何の不思議もないですが、それは私とあなたとを入れ替えても同じことが言えるのですよ。
Re: (スコア:0)
小学生の言い訳というのはこういう事か。
Re: (スコア:0)
横だけど、計算機科学とSI現場主義との間の深い溝をこのスレッドに見た気がする。
一応僕は計算機科学側なので、「お前以外は全員できるよ」に対しては「できると思ってるだけで、できてる保証はどこにもないよ。現実的にシステムを動かすのにどこまでリスクを飲み込んで妥協するか、という判断をしてるだけでしょ。」と返したいところ。
Re: (スコア:0)
その割には、試験をした筈なのにバグのあるソフトが多いようで。余程みんな手を抜いてるんだね。
Re: (スコア:0)
いや、いきなり、自分と自分の周りのレベルの低さをゲロされても...
Re: (スコア:0)
反論できなくなるとレッテル貼りですか。
Re: (スコア:0)
まあ、いいから涙拭けよ。
Re: (スコア:0)
いや、単に無能なSEと有能なSEの間の溝でしょ。
有能なSEが普通にやってることを、無能なSEが「俺様にできないことがお前ごときにできるわけがない」って騒いでるだけ。
Re: (スコア:0)
そこまでいくと試験という行為範囲に収まらずに、設計するという行為と不可分なんじゃないかなあ。
Re: (スコア:0)
外注先をそのへんで信用できないなら、作成中コードのレビュー工数はマネージメント工数として積むべきものよね。
Re: (スコア:0)
>ソースの可読性
そういう項目は評価に客観性が欠けるんだよね。客観性を持たせるならば、最初に規約でガチガチにして、規約に反しているかどうかしかでしか判断できない。
そうすると、100行ですむところが5000行になったりするんですよ。
Re: (スコア:0)
で、「ぬるぬる動く」とかいう数値化できない指標は一顧だにされないからAppleはおろかサムスンにすら完敗すると。
Re: (スコア:0)
Appleはともかく、サムスンを引き合いに出すのは疑問。googleじゃね？
そうすると、ほら、あんまりくやしくない。
googleだと「ぬるぬる動く」という項目も自動で評価可能にしているかも。
まあ正直言って一連の流れは「開発作業は複数で分担しなければならない」という観念から生じているので
正直、クソだとは思っています。
Re: (スコア:0)
それはソースコードの品質であって動作に影響がでないのならばソフトウェアの品質に影響はないよ
Re:プログラミングは設計 (スコア:2)
拝承 (スコア:0)
酷い場合には（というか、普通の日本企業では？）それをコーディング規約として強制したりする会社もあるようです。
たとえばこんな感じの。
「例えば、承認の機能No.1のパッケージは、
jp.co.kmotor.shouninkun.A01F001
となり、その下に、A01F001L001.java のようなクラスを作成していくことになる。
jspの階層も/shouninkun/A01F001/A01F001P001.jsp のように、対応するパッケージ名と一致させていく。」
「この命名規則は変更できないんでしょうか？」
「できませんね」橋本さんはきっぱり答えた。「これは弊社のプログラム
Re: (スコア:0)
ソフトウェアの品質にソースの品質が含まれない世界なんてあるんですかね？
ゲームのパッケージを買うんならともかく、アウトソースで。
Re:プログラミングは設計 (スコア:1)
アウトソースだからこそ、ソースの品質程度の事は割り切るべきだと思うけどね。
割り切れないか、品質を管理できないなら、それはアウトソースすべきものじゃなかったという事だ。
それこそ、ゲームのパッケージを買うのと同じ事なんだからさ。
#存在自体がホラー
Re: (スコア:0)
アウトソースだからこそ、そういう部分の品質の体験談を共有しておくことが重要なのでは？ と逆方向に思いますが。
このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
(a) テスト仕様もまともに書かず、常識的な品質として○○すべきだ
(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ
aについては同質幻想であって論外。bについては十分条件しか述べておらず、これで品質を議論するのもエンジニアとして不見識と言いたいですね。
Re: (スコア:0)
> このスレッドを見てると、日本の「IT産業」がダメな理由が凝縮されている気がする
今まで見たことがある中国 (上海周辺) 、北米 (西海岸) のIT産業の大半の企業は同じような問題を抱えていますし、
これらの問題を抱えていない企業は数えるほどしか知りませんが、日本のIT産業だけに限定しているのはなぜでしょう。
この手の問題がまれな国や地域をご存知でしたらぜひ教えて下さい。
Re: (スコア:0)
いや、多分ダメなのはあなたの頭だと思う。
>(b) テスト仕様を満たしていれば、どんなソフトウェアも同じ品質だ
誰もそんな事は主張していない。
(b')要求する品質を担保するためにテスト仕様はつくられるべきである
というのが正しい。
Re: (スコア:0)
禿同