[
现在，有些机构或者企业也希望开发一些可以多次使用或者可以作为标准的统一过程（例如RUP）。作为一个软件企业，开始的时候没有足够的过程管理积累，可以采取摸索、实践、提炼、改进的步骤进行。第一阶段，可以针对具体项目制定具体的过程，而且一定要简单实用，然后逐步调整过程。也就是说第一步应该是针对具体项目制定过程，等积累了一定的项目管理经验后，第二阶段就可以针对企业制定相应的过程策略。最后，我们可以期望软件行业的过程标准。所以，软件项目过程的制定应该是循序渐进的。不一定仿照某些标准，简单实用是最重要的。
一个可以被更多人认可并行之有效的软件过程是实践出来的，而且软件过程也不是枯燥的、抽象的条款，而是具体的、生动的、有实际意义的、可操作的工具。在具体进行过程定义的时候，应该是从项目级过程逐步积累到企业级过程，再由企业级过程裁剪为项目过程。如果所有的软件企业内部都能够做到企业级的过程管理，那么实现软件界的过程统一就不远了。如果软件行业有了可以通用的统一过程标准，证明软件发展到了一个成熟的阶段了。
这里还要强调一点，谈到软件过程的重要性时，常常说软件过程可以消除依赖个人英雄主义的状况。我们也应该看到，软件过程不推崇个人英雄，但是并不是说软件项目不需要具有优秀技术的个人，好的软件过程可以加速优秀个人的成长；同理，好的软件过程也可以加速软件企业的成长。
美国NASA的经验
在探索软件过程管理的过程中，首先是不能盲从。比如，对等评审（Peer Review）是CMM中非常重要的一个关键过程域，CMM、PMBOK等项目管理体系都对走查（Walkthroughs）、审核(Inspection)等对等评审有相应的说明，但它们都没有对如何实施这个过程明确定义操作流程。如果软件企业没有很好的实践而照搬其他企业的审核或者走查等对等评审过程，那么在实施过程中可能会遇到层层的障碍，导致得不偿失。只有经过实践之后总结出来的过程，才会带来很好的结果。
又如，我们曾经在开发一个软件项目过程中发现，有些人开发的软件质量很高，而且效率也很高，测试中发现的缺陷很少。原来这些人在编译前后都进行代码走查，后来我们就要求项目组的所有开发人员都要进行自我代码走查，编译前进行一次，编译之后进行一次，保证测试之前执行两次代码走查。结果取得了非常好的效果，软件的质量得到了很大的提高。为此，将这个方法推荐给其他项目，其他项目在试用过程中发现如果进行交叉代码走查，即开发人员互相进行代码走查，效果会更好。这样逐渐总结开发代码的过程，经过多个项目的过程提炼可以编制企业的开发过程。在企业的代码开发过程中，明确说明什么时间进行代码走查，如何进行代码走查。这样通过有效的过程来提高软件产品的质量。
美国NASA Space ShuttleOnboard软件项目，在实施软件过程管理中得到了实实在在的好处。为了满足NASA约翰空间中心关于项目高安全和高性能标准的要求，Shuttle Onboard项目必须开发出高质量的软件。为此，项目团队精心制作并实践了可以提高产品质量的软件过程，经过十几年的努力和实验，摸索和开发了可以精确控制的过程，最终使软件达到零缺陷。在此期间它们参照、实验了很多的软件过程，包括需求管理、配置管理、对等评审、审查、测试、项目管理等。为了消除缺陷的根源，项目组成立“问题疏漏分析”组，分析诸如审核、测试、验证等检错方法中疏漏缺陷的原因，也就是研究这些质量过程中存在的问题，这个提高质量过程的过程包括如下四个步骤:
1.从技术上分析缺陷的原因，并且提出纠正的措施。
2.标识纠错过程中的问题，并更正过程，以消除将来采用此过程可能疏漏错误的可能性。
3.改进纠错过程中的具体方法程序，这些方法程序曾经让缺陷逃过了，没有及时捕获缺陷。
4.检查Shuttle Onboard项目中采用此过程方法的其他部分，这些部分可能同样遗漏了一些类似的缺陷，需要重新检查，以便确认没有缺陷。
通过详细的情景式分析确定缺陷的根本原因，然后将这些情景式的经验反馈给开发过程，它们对改进纠错过程起到了非常好的作用。项目组将它应用到了其他过程的分析中，诸如需求分析等，也取得了很好的效果。
同样的，Shuttle Onboard项目通过不断地度量过程、完善过程，最后达到提高项目质量的目的。过程的质量来源于实际的度量结果。同样项目的质量也可以通过高质量的过程来得到保证。
[本文共有 2 页，当前是第 2 页] <<上一页 下一页>>
]
您的位置：
