アカウント名:
パスワード:
>> バグが何件出るかなんて予測できるの？部門より>予測せずに，どうやって必要な工数(労力)を見積るんですか?
なんか、いまだにバグはあってはならない！あってはならないものの件数を考えるな、そんな閑があるならとっとと潰せ！みたいなお方もちらほら
> 測定 → 計画または目標の修正
測定している間になぜか、そのソフトウェアの規模が膨らんだりして、再度の目標設定以前に、自分らが何を作っているかすらが曖昧になっていたりしませんかね？
>> バグが何件出るかなんて予測できるの？部門より> 予測せずに，どうやって必要な工数(労力)を見積るんですか?
まあそうなんですが。工学と名乗るには、反復的な情報の収集と、それを元にした予測の妥当性が反復的が必要な訳で。それがPDCAサイクルなんですけれど、「ソフトウェア工学」なるものがPDまででCへ行かない、そんな感じはしています。
> テストを行う人の技術レベルや人数を考えずに，期間を半分(以上)と設定することに何の意味があるのですか?工学的には意味はありません。芸能としては意味があるかもしれません。工学を志向/指向するなら「技術レベル」を考えるだけでは済まず、作業に携わる個々の要員の技術レベルや効率、作業傾向等々々々々を厳密に数値化する事が必要。そうしなければ、工学的にプロジェクト計画なぞ立てる事は不可能な訳で。でもそんな事を無しで計画とか立ててるでしょ？どこの時点でか、「えいっ、やっ！」をやっているんですよ、現実問題としては。工学から芸能への逸脱が発生しているのです。
# いつかアートを抜け出してエンジニアリングになるさ、いつかは
#1856385 の元AC (しがないソフトウェア工学屋) です．
> 「ソフトウェア工学」なるものがPDまででCへ行かない
ソフトウェアメトリクス値の継続的な計測では， PDCA の C には不十分でしょうか．様々なツールで，自動的なメトリクス計測を行なえますよ．
今回のストーリーのように，テストの場合なら古典的な信頼度成長曲線でも十分ですよね．
> 作業に携わる個々の要員の技術レベルや効率、作業傾向等々々々々を厳密に数値化する事が必要。
厳密に計測することだけがソフトウェア工学ではありません．
主成分分析などで寄与率の高いパラメータを見つけ出し，予測を簡単にする研究は，非常に多くの組織で行なわれています．(研究が多過ぎてなかなか統合できないのが悩みですが)
予測モデルに必要な入力パラメータが欠けている場合にも，可能な範囲で補う手法もいろいろあります．
うーん。
> ソフトウェアメトリクス値の継続的な計測では， PDCA の C には不十分でしょうか．> 様々なツールで，自動的なメトリクス計測を行なえますよ．
「ソフトウェア工学」なるものがアプリオリなものとして成立しているならば、PDCAサイクルのCは測定したメトリクスの評価、ですよね。信頼性とか効率性は簡単ですね。じゃあ、保守性は？定量的な測定とか言ってコーディングスタイルに準拠しているかとかだけで、解析性や変更性を直接的に定量的に測定するのはほぼ無理が現実でしょう。定性的かつ主観的な評価とならざるを得ないものに対して、メトリクスを設定する事自
PDCAのCへ回ってないとはこういう話です。「ソフトウェア工学」自体の妥当性はどの様に検証しているんですか、と言う話です。
「『ソフトウェア工学』なるものがPDまででCへ行かない」という表現が，ソフトウェア工学に対するメタな意味だとは読み取れませんでした．しかし，コメント全体を読ませていただいたところでは，メタな話をなさっているわけではないようなので，混乱してしまいます．
どれが正しいのか、あるいは有効なのかに統一的な意見が無い、その様な状態でどうやって工学の目的の１つである反復的な成果が出せるのでしょうか。
「統一的な意見が無い」ことと
Play → Hey! Doctor!! → Cleric → Amen
まあそうなんですけど、
計画または目標の修正
これはなされません。
「それが基準だから」としか言いませんし、そもそもなぜそのような基準が定められているかすらも知らんのですな。
かくして無理矢理合わせることになります。
そんなことだから品質が向上しないんですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ソフトウェア工学なんて勉強したことないよ!! (スコア:0)
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:0)
ソフトウェアテストにおいても「目標設定 → 計画 → (実行) → 測定 → 計画または目標の修正」という手順が必要だという，極めて一般的な話なんですけどね．
> バグが何件出るかなんて予測できるの？部門より
予測せずに，どうやって必要な工数(労力)を見積るんですか?
> バグ出し（と、そのためのプログラム作り）には開発期間の半分はとるべき
なぜ半分は必要だと言えるのですか?
述べられていませんが，どれだけの期間を割けば十分なのですか?
テストを行う人の技術レベルや人数を考えずに，期間を半分(以上)と設定することに何の意味があるのですか?
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:2, 興味深い)
>> バグが何件出るかなんて予測できるの？部門より
>予測せずに，どうやって必要な工数(労力)を見積るんですか?
なんか、いまだにバグはあってはならない！
あってはならないものの件数を考えるな、
そんな閑があるならとっとと潰せ！
みたいなお方もちらほら
> 測定 → 計画または目標の修正
測定している間になぜか、そのソフトウェアの規模が膨らんだりして、
再度の目標設定以前に、自分らが何を作っているかすらが曖昧になって
いたりしませんかね？
Re: ソフトウェア工学なんて勉強したことないよ!! (スコア:1, 興味深い)
>> バグが何件出るかなんて予測できるの？部門より
> 予測せずに，どうやって必要な工数(労力)を見積るんですか?
まあそうなんですが。工学と名乗るには、反復的な情報の収集と、それを元にした予測の妥当性が反復的が必要な訳で。それがPDCAサイクルなんですけれど、「ソフトウェア工学」なるものがPDまででCへ行かない、そんな感じはしています。
> テストを行う人の技術レベルや人数を考えずに，期間を半分(以上)と設定することに何の意味があるのですか?
工学的には意味はありません。芸能としては意味があるかもしれません。工学を志向/指向するなら「技術レベル」を考えるだけでは済まず、作業に携わる個々の要員の技術レベルや効率、作業傾向等々々々々を厳密に数値化する事が必要。そうしなければ、工学的にプロジェクト計画なぞ立てる事は不可能な訳で。でもそんな事を無しで計画とか立ててるでしょ？どこの時点でか、「えいっ、やっ！」をやっているんですよ、現実問題としては。工学から芸能への逸脱が発生しているのです。
# いつかアートを抜け出してエンジニアリングになるさ、いつかは
Re: (スコア:0)
#1856385 の元AC (しがないソフトウェア工学屋) です．
> 「ソフトウェア工学」なるものがPDまででCへ行かない
ソフトウェアメトリクス値の継続的な計測では， PDCA の C には不十分でしょうか．
様々なツールで，自動的なメトリクス計測を行なえますよ．
今回のストーリーのように，テストの場合なら古典的な信頼度成長曲線でも十分ですよね．
> 作業に携わる個々の要員の技術レベルや効率、作業傾向等々々々々を厳密に数値化する事が必要。
厳密に計測することだけがソフトウェア工学ではありません．
主成分分析などで寄与率の高いパラメータを見つけ出し，予測を簡単にする研究は，非常に多くの組織で行なわれています．(研究が多過ぎてなかなか統合できないのが悩みですが)
予測モデルに必要な入力パラメータが欠けている場合にも，可能な範囲で補う手法もいろいろあります．
Re: (スコア:0)
うーん。
> ソフトウェアメトリクス値の継続的な計測では， PDCA の C には不十分でしょうか．
> 様々なツールで，自動的なメトリクス計測を行なえますよ．
「ソフトウェア工学」なるものがアプリオリなものとして成立しているならば、PDCAサイクルのCは測定したメトリクスの評価、ですよね。信頼性とか効率性は簡単ですね。じゃあ、保守性は？定量的な測定とか言ってコーディングスタイルに準拠しているかとかだけで、解析性や変更性を直接的に定量的に測定するのはほぼ無理が現実でしょう。定性的かつ主観的な評価とならざるを得ないものに対して、メトリクスを設定する事自
Re: (スコア:0)
「『ソフトウェア工学』なるものがPDまででCへ行かない」という表現が，ソフトウェア工学に対するメタな意味だとは読み取れませんでした．しかし，コメント全体を読ませていただいたところでは，メタな話をなさっているわけではないようなので，混乱してしまいます．
「統一的な意見が無い」ことと
PDCAサイクルなら実践してるぜ！ (スコア:0)
Play → Hey! Doctor!! → Cleric → Amen
Re: (スコア:0)
まあそうなんですけど、
これはなされません。
「それが基準だから」としか言いませんし、
そもそもなぜそのような基準が定められているかすらも知らんのですな。
かくして無理矢理合わせることになります。
Re: (スコア:0)
そんなことだから品質が向上しないんですよ。
Re: (スコア:0)
その低いレベルに同調する人が多いのも、日本のソフトウェア開発力の
低下が著しいことを表しているのかもしれないと実感しました。
なーんて書くと、自分の能力を否定されたと思った輩がわらわらと
反論してきたりするんですよ。
自分が至らない事を何とか正当化するのではなく、至らない事を改善
することが大切。