アカウント名:
パスワード:
(1)プログラム設計書に基づいてプログラミングすること。 → ありえん。んなもん書くか、今どき。
(2)プログラムコードはコーディング標準に適合していること。 → まあ、これはある。
(3)プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。 → 評価?コードレビューをしろってことか?で、それを保管するの?そんな暇がどこにある。
(4)重要プログラムは、プログラム作成者以外の者がテストすること。 → エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
結論 → 75% ぐらいは非現実的。しょせん、お役人の考える基準なんてこんなもんだ。
>(3)プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。> → 評価?コードレビューをしろってことか?で、それを保管するの?そんな暇がどこにある。最近はコードレビュー支援ツールというのがありまして....。時間的拘束も場所の制約もなく、自動で記録もされて指摘事項もDB化されるのなら、それを前提としたスタイルもありなんじゃないかなあと思う。
問題はそれを元請けが導入して、かつ積極的に活用しようとしているか。
じゃないと結局エクセル版も出来て二重苦に。
エクセルに流しこめばいいんじゃね?まあ、どうしようもないフォーマットってのはあるけど、融通は効く事が多いでしょ。いや、そうでもないか。表があるなと思ったら、全部テキストボックス貼って作ってあったとか....悪夢だ。#そこまでひどくないけど、今、それに似たドキュメント触ってるんだよな....
つまりエクセルは「コードレビューし得んツール」ってことだな。
ある程度以上の規模のプロジェクトなら、ソースコードのクロスレビューと結合テスト以降のアジェンダを残すぐらいは普通にやるだろう。というか、やっとかないと問題が起きたときにテストをしたしないとかで揉めて酷いことになるし。
ですよね。成果物の品質保証を「暇がないから無理」はちょっとどうなんだろう…
暇がないから時々おつりを間違うATMとか嫌だ。
>(4)重要プログラムは、プログラム作成者以外の者がテストすること。> → エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
その通り。
弱小ベンチャーは開発請負などをすべきではない。
よくわかってるじゃないか。
え、専任のテスターとかいるよね普通。
うちは、請負のプロジェクトごとには専任のテスターはおかず、(システムテストは)複数のプロジェクトに対してテスト専門のチームがテストする体制にしてます。テストツールとか、エビデンスの作り方とかを共通化・効率化したいので。
たくさんバグがみつかるとテストチームにご褒美、見つからないと開発チームにご褒美ですね。
いません。会ったこともありません。そういう人種を抱えられるのは、大手エスアイヤーだけです。弊社のような吹けば飛ぶようなソフト会社では、設計からプログラムからテストから保守まで、全部ひとりがやるんだよ。
もちろん経産省のなんたらは見たことないし、遵守しろと言われても無理な話なのは言うまでもない。
理想と現実は違うんだよ。
#さ、自虐モード終了
まず寝ろ。
枕は麦がらが入った奴で、枕元にハーブを置くと一層効果が出る。さすれば、深夜3時になった時に小人さんが現れ必ずやテストを完遂してくれるだろう
男は一歩外に出ると7人の敵がいるソフトウェアは一旦外に出ると千人のテスターがいる
#という気持ちでリリース
なかなか面白いコメントだったw
要求くらいまとめて確認するだろう。それで十分
テストツールを使えば?
受け入れテストをユーザーか元請にしてもらえばいいじゃん
時間や人手が無くても代わりの方法は幾らでもある。
その『代わりの方法』が、経産省のシステム管理基準に反映されていないのが問題なんじゃないの?
例えば、他のコメントにあるように今時ドキュメントの自動生成ツールが普通に使われているのに、システム管理基準に従うとあくまでも『プログラム設計書』を先に作成することが要求されるのでツールの恩恵を十分に得られないとか。
もう少し目の前の箱を活用することを考えようよ。
OK ケイサンシヨウ!
『プログラム設計書』の定義が問題でしょ?経産省のシステム管理基準には何ら言葉の定義がありません。
請負形態によるけれど。
今回の場合はコーディング請負と思われえるので、元請の要求内容が『プログラム設計書』と思われます。
元請の義務を下請に振る営業は論外
>受け入れテストをユーザーか元請にしてもらえばいいじゃん受け入れテストは違うんじゃない?ここでいってるのは出荷前にテストを作成者以外がやって品質保証すべきっていってるんじゃないの?受け入れテストは発注者が品質を確認するテストでしょ?普通の会社だったら必ずやるよ。受け入れテストなしで検収あげるなんて恐ろしくてできないです。受け入れテストじゃなくて品質保証テストのことだったらユーザ、元請とかにしてもらうっておかしくない?作成側で品質保証しないけど作りますよって、例えるならジャンクパーツと同じじゃないですか。請負開発じゃないですよ。発注側からすると、そういう意識の会社はおつきあいしないか、徹底的に安くかいたたくしかないんじゃないかと思います。だって依頼部分の重要プログラムの品質保証を発注側でやるんでしょ?単純にその部分の金額減額して発注側に積むだけでしょ。
(2)~(3)は重要だ。 世に出すなともな製品ならやるべき。出来ないなら、元請けに知らせ、元請け側が別企業にやらせるべき。
(1)については、詳細レベルによるが、必ずしも作成する必要はない。 特に抽象度の高い言語を使う場合にはそのソース自体が設計記述になるし、十分なコメントとして設計情報をソース内に記述して代用とできる。
また、ソースのファイル構成自体が構造設計を反映したものにすれば良い。 だから、ええ加減なモジュール分けはダメだ。(2)の規約に、そういう設計基準のような規約も入れたら良い。
テスト自動化もしてないから、弱小なのでは。
(3)に関しては品質管理という意味で必要どちらかというとPM側で品質評価に必要な指標ですけどね
うちも弱小企業ですが、テストは顧客にまかせちゃってます。だから安い。見積書にはテスト費用をしっかり多めに書いて、じゃあこの分値引きするからテストは御社でやってね、というスタンス。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
テスト結果 (スコア:0)
(1)プログラム設計書に基づいてプログラミングすること。
→ ありえん。んなもん書くか、今どき。
(2)プログラムコードはコーディング標準に適合していること。
→ まあ、これはある。
(3)プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
→ 評価?コードレビューをしろってことか?で、それを保管するの?そんな暇がどこにある。
(4)重要プログラムは、プログラム作成者以外の者がテストすること。
→ エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
結論
→ 75% ぐらいは非現実的。しょせん、お役人の考える基準なんてこんなもんだ。
Re:テスト結果 (スコア:2)
>(3)プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
> → 評価?コードレビューをしろってことか?で、それを保管するの?そんな暇がどこにある。
最近はコードレビュー支援ツールというのがありまして....。
時間的拘束も場所の制約もなく、自動で記録もされて指摘事項もDB化されるのなら、
それを前提としたスタイルもありなんじゃないかなあと思う。
#存在自体がホラー
Re: (スコア:0)
問題はそれを元請けが導入して、かつ積極的に活用しようとしているか。
じゃないと結局エクセル版も出来て二重苦に。
Re:テスト結果 (スコア:3, おもしろおかしい)
エクセルに流しこめばいいんじゃね?
まあ、どうしようもないフォーマットってのはあるけど、融通は効く事が多いでしょ。
いや、そうでもないか。表があるなと思ったら、全部テキストボックス貼って作ってあったとか....悪夢だ。
#そこまでひどくないけど、今、それに似たドキュメント触ってるんだよな....
#存在自体がホラー
Re: (スコア:0)
つまりエクセルは「コードレビューし得んツール」ってことだな。
Re:テスト結果 (スコア:1)
ある程度以上の規模のプロジェクトなら、ソースコードのクロスレビューと結合テスト以降のアジェンダを残すぐらいは普通にやるだろう。
というか、やっとかないと問題が起きたときにテストをしたしないとかで揉めて酷いことになるし。
Re:テスト結果 (スコア:2)
ですよね。
成果物の品質保証を「暇がないから無理」はちょっとどうなんだろう…
Re: (スコア:0)
暇がないから時々おつりを間違うATMとか嫌だ。
Re: (スコア:0)
>(4)重要プログラムは、プログラム作成者以外の者がテストすること。
> → エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
その通り。
弱小ベンチャーは開発請負などをすべきではない。
よくわかってるじゃないか。
Re: (スコア:0, おもしろおかしい)
え、専任のテスターとかいるよね普通。
Re:テスト結果 (スコア:4, 興味深い)
うちは、請負のプロジェクトごとには専任のテスターはおかず、
(システムテストは)複数のプロジェクトに対してテスト専門のチームがテストする体制にしてます。
テストツールとか、エビデンスの作り方とかを共通化・効率化したいので。
たくさんバグがみつかるとテストチームにご褒美、見つからないと開発チームにご褒美ですね。
Re:テスト結果 (スコア:1)
いません。会ったこともありません。
そういう人種を抱えられるのは、大手エスアイヤーだけです。
弊社のような吹けば飛ぶようなソフト会社では、設計からプログラムからテストから保守まで、全部ひとりがやるんだよ。
もちろん経産省のなんたらは見たことないし、遵守しろと言われても無理な話なのは言うまでもない。
理想と現実は違うんだよ。
#さ、自虐モード終了
Re: (スコア:0)
まず寝ろ。
枕は麦がらが入った奴で、枕元にハーブを置くと一層効果が出る。
さすれば、深夜3時になった時に小人さんが現れ必ずやテストを
完遂してくれるだろう
Re:テスト結果 (スコア:1)
男は一歩外に出ると7人の敵がいる
ソフトウェアは一旦外に出ると千人のテスターがいる
#という気持ちでリリース
Re: (スコア:0)
なかなか面白いコメントだったw
Re: (スコア:0)
(1)プログラム設計書に基づいてプログラミングすること。
→ ありえん。んなもん書くか、今どき。
要求くらいまとめて確認するだろう。それで十分
(3)プログラムコード及びプログラムテスト結果を評価し、記録及び保管すること。
→ 評価?コードレビューをしろってことか?で、それを保管するの?そんな暇がどこにある。
テストツールを使えば?
(4)重要プログラムは、プログラム作成者以外の者がテストすること。
→ エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
受け入れテストをユーザーか元請にしてもらえばいいじゃん
時間や人手が無くても代わりの方法は幾らでもある。
Re: (スコア:0)
その『代わりの方法』が、経産省のシステム管理基準に反映されていないのが問題なんじゃないの?
例えば、他のコメントにあるように今時ドキュメントの自動生成ツールが普通に使われているのに、システム管理基準に従うとあくまでも『プログラム設計書』を先に作成することが要求されるのでツールの恩恵を十分に得られないとか。
Re: (スコア:0)
ISO9000とかでもそうだけど規格は紙の文書作ることは一切要求してないよ。それと同等の検証可能性をシステム化することに意味があるんだから、もう少し目の前の箱を活用することを考えようよ。
Re: (スコア:0)
OK ケイサンシヨウ!
Re: (スコア:0)
『プログラム設計書』の定義が問題でしょ?
経産省のシステム管理基準には何ら言葉の定義がありません。
請負形態によるけれど。
今回の場合はコーディング請負と思われえるので、
元請の要求内容が『プログラム設計書』と思われます。
元請の義務を下請に振る営業は論外
Re: (スコア:0)
>受け入れテストをユーザーか元請にしてもらえばいいじゃん
受け入れテストは違うんじゃない?
ここでいってるのは出荷前にテストを作成者以外がやって品質保証すべきっていってるんじゃないの?
受け入れテストは発注者が品質を確認するテストでしょ?普通の会社だったら必ずやるよ。受け入れテストなしで検収あげるなんて恐ろしくてできないです。
受け入れテストじゃなくて品質保証テストのことだったらユーザ、元請とかにしてもらうっておかしくない?
作成側で品質保証しないけど作りますよって、例えるならジャンクパーツと同じじゃないですか。請負開発じゃないですよ。
発注側からすると、そういう意識の会社はおつきあいしないか、徹底的に安くかいたたくしかないんじゃないかと思います。
だって依頼部分の重要プログラムの品質保証を発注側でやるんでしょ?単純にその部分の金額減額して発注側に積むだけでしょ。
Re: (スコア:0)
(2)~(3)は重要だ。 世に出すなともな製品ならやるべき。
出来ないなら、元請けに知らせ、元請け側が別企業に
やらせるべき。
(1)については、詳細レベルによるが、必ずしも作成する
必要はない。 特に抽象度の高い言語を使う場合には
そのソース自体が設計記述になるし、十分なコメントとして
設計情報をソース内に記述して代用とできる。
また、ソースのファイル構成自体が構造設計を反映した
ものにすれば良い。 だから、ええ加減なモジュール分けはダメだ。
(2)の規約に、そういう設計基準のような規約も入れたら良い。
Re: (スコア:0)
テスト自動化もしてないから、弱小なのでは。
Re: (スコア:0)
(3)に関しては品質管理という意味で必要
どちらかというとPM側で品質評価に必要な指標ですけどね
Re: (スコア:0)
>(4)重要プログラムは、プログラム作成者以外の者がテストすること。
> → エンドユーザのことではないとすると、うちみたいな弱小ベンチャーには無理な相談だ。
うちも弱小企業ですが、テストは顧客にまかせちゃってます。だから安い。
見積書にはテスト費用をしっかり多めに書いて、
じゃあこの分値引きするからテストは御社でやってね、というスタンス。