品質の最近のブログ記事

読者があるホテルにいるとしよう。誰かが火事だと叫ぶのを聞く。消火器のところへ走り、警報気を引いて消防署を呼ぶ。全員外に出る。消火活動はホテルを改善しない。それは品質の改善ではない。それは消化なのだ。

「ワインバーグのシステム変革法」

ほとんどの遅延プロジェクトは、コーディングがかなり進捗するかもしくはテスト作業が始まるまで、日程通りにいっているように見える。そのとき、早期に行ったあらゆる便法的作業がテスト作業を遅らせて行き詰まり、プロジェクトが頓挫する。欠陥予防あるいはインスペクションを通じて早期に品質管理をしたプロジェクトは、テスト作業を一気に通過する。---ケイパース・ジョーンズ

「ワインバーグのシステム変革法」

ソフトウエアの品質は、プロジェクトの１つの要因であり、日程やコスト、人員、開発資源のトレードオフを進める上で十分考慮しなければならないと言うことだ。

「デスマーチ」

ソフトウエアを不安定にさせることは、大部分のバグより更に多くの問題を生じさせる。そのため、どのバグを訂正するかについては非常に慎重でなければならない。

「ソフトウェア開発のダイナミズム」

テスト済みのコードの品質を改善する唯一の効果的な方法は、テスト前のコードに入り込む欠陥の数を減らすことである。

「ソフトウェア開発プロジェクト技法」

品質に関する主要な決定要因は、そのほとんどがテストを開始する以前からソフトウエアに内在している。

「ソフトウェア開発プロジェクト技法」

短時間だけなら、品質を犠牲にしてスピードを採るのは効くケ−スがある。数度の戦闘には勝てるかもしれないが、しかし決して戦争には勝てっこないのだ。長期にわたっては、妥協が必須となり、ちょうど1980年代の米国の自動車産業のような破目に陥る：つまり、市場で覇権を失い、新しいグローバルプレーヤーとの競争力を失ってしまう。

「デマルコ　大いに語る」

品質とスケジュール目標のトレードオフが出来ないと感じると、管理者は人々の交流の質を犠牲にしたいという気になりがちだが、そうすればすぐに品質とスケジュールの両方に代償を支払わなければならない羽目になる。

「ワインバーグのシステム行動法」

品質さえ気にしなければ、品質以外のどんな要求でも満たすことができる。

「ワインバーグのシステム洞察法」

品質を手っ取り早く片づけようとすればするほど、問題はますます悪くなる。

「ワインバーグのシステム思考法」

当初から品質のいかんにかかわらず、最短スケジュールで完了することを目的としたプロジェクトでは、スケジュールと費用の両面で超過する傾向がかなり目立つ。当初から品質と信頼性を第一に完了することを目指したソフトウエアプロジェクトでは、スケジュールが最もよく守られ、高い生産性および市場での成功率の高さが達成された。

「コードコンプリート」

全てのソフトウエアエラーの約40%は、ストレスが原因であると判明している。

「ラピッド デベロップメント」

過度のスケジュールプレッシャーの下で開発され、リリースされた製品では、通常の4倍の欠陥が報告されている。

「ラピッド デベロップメント」

品質保証作業がプロジェクトの終盤まで後回しにされた場合、３，４個の低品質なコンポーネント及び相互関係のデバッグだけではすまない。開発者は、何百、何千の低品質なコンポーネントとその相互関係のデバッグ作業に直面することになる。

「ソフトウェア　プロジェクト　サバイバル　ガイド」

速さと品質のどちらを優先するか決めるときに判断材料となるのは、よく言われるように、品質が悪いという評判は、開発が早かったという評判が忘れられてからもずっと後まで残るという点である。

「ソフトウェア　プロジェクト　サバイバル　ガイド」