Post by "morris", 02-14-2007, 14:23
-----------------------------------------------------
试着翻译了一部份，是否真的是这么回事儿，需要你自己来判断，呵呵
软件开发 55条真理和10条谬论
第Ⅰ部 55の真実
第一部分 55条真理
第１章 プロジェクト管理
第一章 项目管理
人員
人员
真実１：ソフトウエアの開発で最も重要なことは、プログラマが使う
ツールや技法ではなく、プログラマ自身の質である。
真理1：软件开发最最重要的，不是开发人员使用的工具和技术，而是开发人员本身的素质。
真実2：プログラマ個人を分析した研究によると、最も優秀なプログ
ラマは最悪に比べ、28倍優れている。給与が能力を反映して
いないとすると、優秀なプログラマは、最高の掘り出し物と
言える。
真理2：根据对开发人员情况的分析和研究，最优秀的开发人员和最差的，素质相差28倍。薪水并不能反映出实际的能力、优秀的开发人员是无价之宝。
真実3：遅れているプロジェクトに人を追加すると、もっと遅れる。
真理3：向已经延期的项目中追加人员，会延期的更多。
真実４：作業する環境は、プログラムの生産性や品質にきわめて大き
く影響する。
真理4：开发环境，对程序的生产效率和质量，有非常大的影响。
ツールと技法
工具和技术
真実5：開発ツールの大袈裟な宣伝文句は、ソフトウエアの開発プロ
ジェクトにとって、たちの悪い伝染病のようなものだ。ツー
ルや技法の大部分は、生産性や品質を5～35％程度、改善す
るにすぎないが、「革命的な効果」があると吹聴する場合が
ほとんどである。
真理5：开发工具的夸大的宣传，对软件项目开发来讲，就像恶性传染病一样。大部分的工具和技术，只能在生产率和品质方面改善5%到35%。所谓革命性的效果，基本上都是在吹牛。
真実6：新しいツールや技法を学習すると、最初は生産性や品質が下
がる。実際に効果が出るのは、ツールや技法が完全に身につ
いてからだ。従って、ツールや技法の導入が効果的なのは、
(a) 効果が現実的である、(b) 気長に効果が出るのを待てる
場合に限る。
真理6：新工具和技术的学习，刚开始会导致生产率和质量下降。完全掌握工具和技术后才能实际产生效果。因此，引入工具和技术的效果两种情况：a)现实的效果，b)需要耐心等待的长期的效果。
真実７：ソフトウエア技術者は、ツールの話が大好きである。いくつ
もツールを買い、評価もするが、開発で実際に使う人は、ほ
とんどいない。
真理7：软件技术人员，非常喜欢谈论工具。买了不少工具，也研究了不少，可真正在开发中实际使用这些工具的人，基本上没有几个。
見積もり
估价
真実8：プロジェクトが大失敗する原因には二つある。一つは見積も
りミスだ（もう一つはP.110の真実23を参照）
真理8：项目严重失败的原因有两个，其中之一就是估价（工时估算？）错误。
真実9：ソフトウエア開発の見積もりは、プロジェクトの開発時に
実施する場合が非常に多い。これだと、要求定義が固まる
前に見積もることになり、どんな問題がどこにあるかを
理解する以前に予測するので、意味がない。従って、
見積もり時期として適切ではない。
真理9：软件开发的工时估算，在项目开发中才进行估算的场合非常多。因此，需求确定前进行工时估算，或者理解需求及分析存在什么样的问题之前进行预测，是没有意义的。因此，上述估算的时机并不恰当。
真実10：見積もりは、上層部かマーケティングが実施する場合がほと
んどだ。実際にプログラムを開発したり、開発プロジェクト
の直接のマネジャが見積もることはない。結局、適切な人が
見積もっていないのだ。
真理10：工时估算的工作，很多时候是由上层的市场部门进行的。而不是由实际开发程序的，项目直接的管理人员（项目经理？）来估算的。结果就是，该做估算的人，没有去估算。
真実11：プロジェクトが進むに従って、見積もりを調整することは、
まずない。従って、不適切な時期に不適切な人間が実施した
見積もりを修正することは、ほとんどない。
真理11：没有根据项目的发展，来调整工时估算的结果。即，不适当的时机由不适当的人做出的工时估算，也基本上没有得到修正。
真実12：見積もり精度がいい加減だと、実際のプロジェクトが見積も
り通りに進まなくても、まったく気にならないはずだが、現
実には、みんな気にする。
真理12：如果估算的合适，就算实际的项目没有完全按照估算那样发展，也不应该太在意。但是现实上大家都很在意。
真実13：管理者とプログラマの間には、大きな断絶がある。ある研究
によると、重大な見積もりミスを起こし、管理者は大失敗プ
ロジェクトと考えているのに、開発担当のエンジニアは、こ
れまで従事した中で、最も成功したプロジェクトと考えてい
るものがあったらしい。
真理13：管理者和开发人员，有非常大的鸿沟和差别。根据某项研究、工时估算上发生了大的问题后，管理者可能认为是个非常失败的项目，但是从事开发的工程师却可能认为这是自己做过的所有项目中最成功的一个。
真実14：実現可能性の分析（feasibility study）の結果は、いつも
YESである。
真理14：能否实现某功能的可能性分析的结果，往往是YES。
再利用
复用
真実15：小規模な再利用（例えば、ライブラリやサブルーチン）は、
50年前に始まり、既に解決済みの問題である。
真理15：小规模的复用（如：函数库和子模块），从50年前就开始了，是已经解决的问题。
真実16：大規模な再利用（コンポーネント単位）は、誰もがその重要
性を認識し、なくてはならないと感じているが、今なお未解
決である。
真理16：大规模的复用（以组件为单位），谁都认识到了重要性，不能不做。但是这个问题现在还是没有解决。
真実17：大規模な再利用は、類似システム間ではうまくいく可能性が
高い。応用分野の類似性に依存するため、大規模流用の適用
範囲は狭くなる。
真理17：大规模的复用，在类似的系统间顺利进行的可能性很高。因为复用依赖于各类应用的相似程度，所以大规模的复用的适用范围会变小。
真実18：再利用には、二つの「3の法則」がある。（a）再利用可能な
コンポーネントを作るのは、単一のプログラムで使うモジ
ュールを開発する場合に比べ、3倍難しい。（b）再利用可能
なコンポーネントは、ライブラリに取り込む前に、3つの異
なるプログラムでテストする必要がある。
真理18：复用中，有两个“3原则”。A)开发可复用的组件，比开发专用的模块复杂3倍。B）复用的组件在抽到程序库中以前，需要在3个不同的程序中进行测试。
真実19：プログラムを再利用する場合、流用母体の変更は、バグの原
因になる。20～25％も変更する必要があるなら、最初から作
ったほうが、効率が上がるし、品質もよい。
真理19：程序复用的情况，
真実20：デザインパターン方式の再利用は、ソースコードの再利用に
おける問題を解決する一手段である。
複雑性
真実21：対象となる問題の複雑度が25％増加するたびに、ソフトウエ
アによる解法の複雑度は、100％上昇する。これは、改善し
なければならない数字ではなく（複雑性を下げるのは非常に
望ましいが）、こうなるのが普通だ。
真実22：ソフトウエアの開発は、80％が知的な作業である。また、
かなりの部分が、創造的な仕事であり、事務作業はほとんどない。
第2章 ソフトウエア?ライフサイクル
要求仕様
真実23：プロジェクトが途中打ち切りになる二つの原因のうち、一つ
は、仕様を確定できないことだ（もう一つは、真実8を参
照）。
真実24：仕様不良の修正コストは、製品出荷後はもっとも高いが、開
発の初期であればもっとも安い。
真実25：仕様の抜けは、仕様関係の不良の中で修正がもっとも難しい。
設計
真実26：仕様定義フェーズから設計フェーズに移る時、膨大な数の
「派生仕様（derived requirements：仕様を具体的な設計方
式にブレイクダウンする場合、設計方式に対する要求仕
様）」が生じる。これは、問題解決プロセスが複雑なため
に発生する もので、この設計仕様の量は、元の仕様の50
倍になることもある。
真実27：ソフトウエアの開発において、ベストの解法が一つしかない
ことは、まずありえない。
真実28：ソフトウエアの設計は、複雑で反復が必要なプロセスである。
従って、最初に考えついた設計方式が間違っている可能性は
高く、最適解ではない。
コーディング
真実29：問題を「基本モジュール」レベルまで詳細化できた時点で、
設計フェーズからコーディング?フェーズへ移る。コーディ
ングをする人と設計者が同一人物でない場合、「基本モジ
ュール」の認識にズレが生じ、トラブルの元となる。
真実30：COBOLは非常に悪い言語だ。しかし他の（ビジネス?データ
処理用）言語は、もっとひどい。
不良除去
真実31：ソフトウエア開発のライフサイクルで、不良除去に最も時間
がかかる。
テスト
真実32：十分テストをしたとプログラマが自信を持つソフトウエアで
も、全パスの55～60％程度しか網羅していない。パス?カバ
レッジ?アナライザのような自動化ツールを使うと、網羅率
が85～90％に上がる。しかし、100％のパスを網羅するのは
不可能だ。
真実33：100％のテスト網羅が可能でも、完全テストとはいえない。
バグの約35％は、パスの抜けが原因であり、40％はパスの特
定の組み合わせを実行したときに起きる。このバグは、パス
を100％カバーしても検出できない。
真実34：ツールを使わないと、不良除去はうまくいかない。デバッガ
はみんな使うが、カバレージ?アナライザはほとんど使わ
ない。
真実35：テストの自動化は、非常に難しい。テスト?プロセスの中に
は、自動でできるし、自動化しなければならないものもある
が、大部分は自動化が不可能な作業である。
真実36:プログラマがソースコードの中に組み込むデバッグ用の命令
語(コンパイラのパラメータにより、オブジェクト?コード
に吐き出すかどうかを制御できることが望ましい)は、テス
ト?ツールを補って余りある。
レビューとインスペクション
真実37：インスペクションを厳しく実施すると、プログラムをマシン
で実行する前に、90％ものバグを叩き出せる。
真実38：厳密なインスペクションは、大きな効果を上げるが、テスト
の代わりにはならない。
真実39：出荷後レビュー（遡及的レビュー[retrospectives]と呼ぶ場
合もある）は、顧客満足度の測定、および、プロセス改善の
両方の観点から重要だが、実施している企業はほとんどない。
真実40：ピア?レビューには、技術的問題と社会学的問題がある。レ
ビュー相手のことを十分考慮しないと悲惨な結果になる。
保守
真実41：保守には、ソフトウエアのコストの40～80％(平均60％)がか
かる。従って、ソフトウエア?ライフサイクルの最重要フ
ェーズである。
真実42：保守の60％は機能拡張であり、バグ修正は17％にすぎない。
このため、ソフトウエアの保守は、不良修正ではなく、古い
ソフトウエアに新しい機能を追加する作業である。
真実43：保守は解法であり、問題ではない。
真実44：ソフトウエアの開発作業と保守作業を分析すると、大部分は
共通している。例外は、保守の場合、?既存プログラムの理
解?が新たに加わることである。この作業には、保守の全作
業時間の約30％が必要で、保守の中心となる作業だ。従って、
開発に比べると、保守は難しい。
真実45：優れたソフトウエア?エンジニアリングに沿ってプログラム
を開発すると、保守は減らず、かえって増える。
第3章 品質
品質
真実46：品質とは、属性を集めたものである。
真実47：ソフトウエアの品質とは、ユーザを満足させることではない。
仕様を満足させることでもなければ、コストとスケジュール
を満足させることでも、信頼性でもない。
信頼性
真実48：誰もが共通に作り込む種類のバグが存在する。
真実49：バグは固まって存在する。
真実50：不良除去に、唯一無二のベストな方法はない。
真実51：プログラムの中の残存バグは、簡単には摘出できない。従っ
て不良除去では、重大なバグを最少に抑えたり、なくすこと
を目標とすべきである。
効率
真実52：プログラムの処理効率には、よいコーディングよりも、
よい設計が大きく影響する。
法則53：高級言語(HOL：High Order Language)は、適切な最適化コン
パイラがあれば、アセンブラ言語で記述した場合の90％の効
率で処理できる。最新の複雑なハードウェアを使えば、アセ
ンブラのプログラムより速くなる。
法則54：プログラムの大きさと処理時間には、トレードオフがある。
片方をよくすると、他方が悪くなる。
第4章 研究
真実55：大部分の研究者は、技法を「分析」するのではなく、「擁
護」する。その結果、(a) 研究対象の技法は、実際には、
自分が信じるほどの効果はなく、(b) 技法の本当の価値を
検証する評価研究が不足している。
第Ⅱ部 5＋5のウソ
第5章 管理について
ウソ1：計測できないものは管理できない。
ウソ２：ソフトウエア製品の品質は管理できる。
人員
ウソ3：プログラミングからエゴを取ることは可能だし、そうでなけ
ればならない。
ツールと技法
ウソ4：ツールや技法は、どんな状況でも適用できる。
ウソ5：ソフトウエアには、もっと開発方法論が必要である。
見積もり
ウソ6：コストやスケジュールを予測する場合、まずソース
コードの行数を見積もる。
第6章 ライフサイクル
テスト
ウソ7：ランダム?テストにより、テストを最適化できる。
レビュー
ウソ8：「多くの目にさらされれば、バグは枯れる」
保守
ウソ9：将来の保守に要するコストや、いつ現在のソフトウエアを入
れ替えるかの決定は、過去のコストのデータを見ればわかる。
第7章 教育
ウソ10：プログラムをどう書くかを見せれば、プログラムの方法を
教えられる。
まとめ |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图