1.把质量放在第一位：必须对软件质量进行量化，并扇〈胧┐俳柿康谋Ｕ?lt;/FONT>
常用的量化指标有缺陷泄露率，缺陷密度，COPQ,COGQ和COQ
软件项目质量包含了可用性，可测试性，健壮性，性能，易用性和友好性，可维护性等多项内容应该制定不同的量化指标
2.高质量的软件是可能的
评审，原型，客户参与，测试，迭代开发，雇用优秀人员已经证明可以很好提高软件质量
3.尽早的向客户交付产品：无论在需求阶段理解客户的需求有多难，确定用户真正需求的最有效的方式就是尽可能早的交给他们一个产品让他们使用。
这个是现代过程框架的一个重要原则。原型法，增量迭代，客户参与验证等已经被认为是成功的方法
4.在编写需求前确定问题：当面对一个被认为是问题的问题时候，多数工程师都急于给出一个解决方案。当试图解决一个问题的时候，要保证已经试验过了其它的选择，不要被轻而易举的解决方案所迷惑。
解决方案在逐步细化的过程中，问题的参数也会变得越来越容易掌握。现代工程框架直到充分理解问题，足以提交整个产品时候，才会将问题和解决方案一起归档。
5.评价设计可选方案：当需求达成一致后，你必须验证多种架构和算法。你肯定不想在需求说明书中使用了一个"构架"就真的使用这个构架。
现在软件过程中设计可选方案的分析过程是和需求规格说明同时进行的，而且需求和架构的产出物是明确分开的。需求有专门的需求规格说明书，而架构有相关的4+1View的架构文档。
6.使用合适的过程模型：项目必须要根据自己的项目特征来选择项目的过程模型，这些特征包括项目规模，周期，人员情况，需求可变性，文化，风险，应用领域等。
7.在不同的阶段使用不同的语言：
8.尽可能缩小理解上的差距：尽可能缩小理解上的差距，软件结构必须与现实世界的结构尽可能的接近。
这个原则一直是面向对象技术，基于构件开发以及可视化建模的动力。
9.技术比工具重要：没有受过训练的软件工程师使用工具会成为一个危险的，仍未经训练的工程师。
该原则没有提及的另外两个重要地方是 1)受过良好训练的软件工程师使用好的工具的生产效率要好于受过良好训练没有工具的软件专家。2)自动化是推广，标准化并交付好的技术的最佳方式。
10.在快之前首先保证运行正确：要使一个可用的程序运行得更快些，远比让一个运行的快的程序可用容易的多。在开始阶段的编码不要考虑优化的问题。
由于我们在前期很难发现系统隐藏的性能问题，我们要作的是尽快让程序可用，以去理解复杂的性能。
11.评审代码：评审详细设计和代码来查错，是一个比测试好得多的方法。
人们过分夸大了这种方法的价值。当正确的使用并集中在一个已知的问题上时候，评审对于解决问题是十分有效的。毫无方向的评审极少能够发现架构和全局的问题。
12.好的管理比好的技术更重要：最好的技术并不能够弥补差的管理，而一个好的经理人可以用贫乏的资源取的伟大的成就。好的管理推动人们发挥自己最好的一面，但没有一种普遍正确的管理风格。
13.人员是成功的关键：具有适当经验，才能和培训的高技能的人员是关键。即使没有足够的工具，语言和过程，人员配备正确也可以成功。而错误的配备了人员，即使有合适的工具，语言和过程，项目也可能失败。
传统软件工程也这么强调人的因素，足见人对整个软件项目的重要性。
14.谨慎的跟随潮流：面对对象，度量，复用，过程改进，CMM和原型化－这些事情都可能提高质量，降低成本并提高用户的满意度。人们普遍过分吹嘘这些技术的潜力，而无法保证这些技术是对所有项目都普遍有效。
这是一个明智的建议，先进的技术不仅仅带来风险。而且不能够很好保证特性，成本和进度的折中要求。
15.勇于承担责任：成功仅仅依靠好的方法，工具和构件是远远不够的。成功需要好的人员，好的管理和有战斗力的团队。在这种团队中，项目成员即使遇到不可避免的困难或挫折，也会专注于推动项目前进。
16.理解客户需求的优先级：如果能够按时得到20%功能，客户可能会容忍80%功能延期。
理解客户优先级很重要，同时客户永远是正确的心态往往导致更大的进度延迟和金钱的浪费。
17.用户看的越多，就想得到更多。你提供给用户功能越多，用户越想得到更多的功能。
18.计划丢弃：成功最关键的因素就是一个产品是否是全新的，这样一个全新的应用，接口，架构或算法，极少能够第一次就正常工作。
现代工程认为不应该一开始就计划丢弃，相反，你应该计划把一个不成熟的原型产品进化为一个成熟的模型。
19.为变更做设计：你使用的架构，构件和规格说明技术必须能够适应变更。
这是一个简单的叙述，但已经被证实过于复杂以致于难以实现。敏捷，迭代，原型的方法论加上后期的不断重构可以较好的实现这点。
20.没有文档的设计不是设计：我经常听到我们的软件工程师说我们的软件设计做完了，只剩下文档工作了。
源代码也是一种设计。现代工程认为，软件制品包括源代码都应该是自成文档的。只是描述的形式不同而已。
21.使用工具，只是要现实一点：软件工具会让用户更有效率。
22.避免玩弄小技巧：许多程序员热衷于玩弄小技巧，以晦涩的方式正确的完成功能。要通过避免使用这种技巧性代码的方式显示你的聪明才智。但避免玩弄小技巧决不是扼杀创新。
23.封装：信息隐藏是一种简单的技术，被证明可以使软件更易于测试和维护。
基于构件的设计，面向对象的设计以及现代设计和编程符合，使这个原则进入到了主流的实践阶段。
24.使用藕合和内聚：藕合和内聚是度量软件内在的可维护性和适应性的最佳方式。
这个重要的原则很难实施，人们很难对藕合和内聚进行有效的度量。
25.使用McCabe复杂度度量标准：虽然有很多可用的度量元可以报告软件的复杂性，但没有一个有Tom McCabe更好用。
26.不要测试自己开发的软件：软件开发者永远不要成为自己开发的软件的主要测试者。
开发者应该测试自己的软件，度量的测试群组也应该测试它。
27.分析错误的原因：靠预防错误的发生比找出错误并修复它来减少错误的影响要划算的多。这样做的方法之一是当检查出错误的时候分析它的原因。
在工程阶段不要害怕犯错误，在生产构造阶段要分析错误的原因和根源。
28.意识到软件熵的增长：任何经过持续修改的的软件系统的复杂度都会增加，并且变的越来越紊乱。
29.人员和时间是不可以互换的：只以人月来度量项目是没有什么意义的。这以原则永远有效
30.期待优秀的表现：如果对他们有较高的期望，雇员们会做的更好。
这一原则不仅仅适用于软件管理，而且适用于所有学科。
您的位置：
