ソフトウェア開発の定量化手法 第3版。タメになる言葉15。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その15。

テストケースには、そのテストケースでテストすべき製品よりも欠陥が多い場合があるということがわかった。
もう１つ、そのテストケースの約3分の1は重複しているという思いがけない発見もあった。
そのようなテストケースはテスト成果には何ら寄与せず、単にテストのコストを増やすだけである。

一般に、品質保証グループがテストケースの誤りを調べることはないし、テストグループですらめったにテストケースの検討はしない。
また、テストケースの妥当性と重複を調べるために専任グループを置いている企業はない。

2008年時点では、テストケースは誤りやバグが多くあり、欠陥予防や欠陥除去活動の大きな妨げになっているということである。

テストコードの保守についてさほど検討されずに、テストカバレッジの誘惑にとりつかれ、とにかくテストコードを書きまくるという現場もありますね。

妄信と言っても良いほど。

品質保証に対する総合的な取り組みが大事ですよねぇ…

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉14。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その14。

生産性の高いほうから25%のプログラマは、生産性の低いほうから25%のプログラマのほぼ2倍（役4㎡に対して約7㎡以上）のオフィススペースを使用している

スペースを作るには直接的にお金もかかるし難しい問題ですね。 

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉13。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その13。

ソフトウェア開発は難しい知的な業務であり、複雑度が高く、多くのバグや欠陥が生じやすい。

一般論として、民間のソフトウェアのコストとスケジュールは、最もコストがかかる欠陥除去作業に左右される（軍需ソフトウェアでは文書化作業に最もコストがかかる）。

バグが見つかる事そのものを問題と捉える会社やチームはけっこう多いと思う。

多少がバグが出ても気にしないチームもあるけど、それはそれで問題だと思う。

ソフトウェアというのはバグがあるのが当然であり、対応するコストがかかるのも普通であり、減らす努力はしなければならない。

それは簡単な事ではないと認識しておくのが大事。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉12。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その12。

保守費用は、実のところは追加、修正のコード量に左右されるのではなく、修正アプリケーションの規模、経過年数、複雑度、潜在欠陥量に大きく左右される。

修正しようとする内容の影響が少ないというのは直感に反する事実なので、面白い知見です。

運用エンジニアの目標として、既存コードの複雑度を減らすというのは良いかもしれないですね。複雑度を減らした結果上がるという「保守担当量」も計測して目標に据えるのは良いかもしれない。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉11。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その11。

ソフトウェア要因が1,000人程度の中規模ソフトウェア組織は、コスト超過、スケジュール遅延など最も問題をはらんだ組織である。

この規模の組織にあっては、速やかに専門化する必要があるが、多くはジェネラリスト重視の姿勢を引きずっている。

そのため中規模組織は最低の生産性と最悪の品質レベルを示す事が多い。

この規模の企業でも洗練された企業は以下に示すように幅広いスペシャリストを擁している。 

ジェネラリストよりも専門家を置いた方が生産性は高いというお話。

小規模の会社では一人が多くの事やらざるを得ないが、1000人以上の会社では専門家が多い体制だと良い。

直感的にも、専門家のほうが良い仕事ができると思う。

ジェネラリストというと聞こえは良いが、ただの素人集団という場合が多い。というのは個人的意見。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉10。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その10。

西暦2000年問題は世界中で運用されているアプリケーションの最大75%に影響した。

根本原因は単純であったがユーロ通貨問題とは異なり、この問題は経営情報システムのみならず医療機器、電話交換システム、プラントなどに組み込まれたコンピュータにも影響した。

（ユーロ通貨への対応とあわせて）ちなみにこの2つの問題のために1999年と2000年には世界のソフトウェア技術者の65%以上が、さまざまな保守と機能拡張に従事したとされる。

2000年問題って騒がれたけど結局何もなかったよね～。

という声をたまに聞くので引用してみた。 

プログラムの保守の仕事は増え続けている。今後も増え続けるのでしょう。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?

ソフトウェア開発の定量化手法 第3版。タメになる言葉9。

「ソフトウェア開発の定量化手法」より、個人的にタメになると思ったところの引用。その9。

開発手法ごとの生産性と欠陥除去率の一覧データが掲載されいてる。

表を全部引用するのはちょっとアレなので、得られた知見のみメモ。

生産性と欠陥所率がともに高いのは「TSP/PSP＋スクラム」または「CMMレベル5＋シックスシグマ」という手法の組み合わせでした。

これは次に何を勉強すべきかの道しるべになりますね。

開発手法は、プログラミング言語とほとんど同じくらい急速に開発されている。

1985年からデータを収集しているが、新開発手法はほぼ2か月に1つの割合で発表され続けている。 

とのこと。

開発コンサル等はよく「新しい手法」「話題の手法」を現場に適用し、混乱を招き、現場の人が必死に混乱を修正して出した結果を「コンサルの成果」としてかっさらい、経営は舌先三寸に丸め込まれて「新しい手法」を信じ、絶望に打ちひしがれたプログラマーが転職していく。

という地獄のループをいくつか経験した。

「開発手法」もコロコロを新しい物に手を出さない方が良いきがする。

ソフトウェア開発の定量化手法 第3版 ?生産性と品質の向上をめざして?