cmmi体系简介及软件工作流程课件.ppt

工程项目标准过程 项目立项 项目计划 项目监控 风险管理过程 需求管理 项目总结 需求获取 实施设计 产品部署 确认测试 初验 系统上线 维护交接 软件配置管理 软件质量保证过程 度量分析过程 软件评审过程 维护项目标准过程 项目立项 项目计划 项目监控 风险管理过程 项目总结 主动服务监控 软件服务支撑 进行产品部署 软件配置管理 软件质量保证过程 度量分析过程 软件评审过程 公司体系文件导读 各职位体系学习质量管理体系指引 QA * * PA组件包括过程域、特定目标、特定实践、通过目标、通过实践、典型的工作产品、子实践、批注、一般实践详细说明以及参考资料。 Generic Practice Elaborations：一般实践的详细说明。 * * * * * * * * * * 有很多软件企业，在项目过程中，须提交一些进度报告、总结报告，报告中可能会有进度情况、成本情况的一些数据。收集这些数据的目标也十分明确，就是想了解项目的进度、成本情况，并与计划的情况进行比较，采取必要的措施。 “感知级”的企业，有这样的一些特点： 有明确的度量目的。 有度量值的比较基准，如例子中的计划完成时间与实际完成时间的对比。 被度量对象的属性定义得比较清楚，如上例中缺陷的属性。 对度量的结果进行分析，并且要考虑改进措施。 “感知级”的企业，应该满足CMMI2级中MA(度量)这个PA的要求的，感兴趣的读者可以去看看MA这个PA。 下面这种情况，算不算“感知级”呢？ 在项目总结报告中，统计项目进度、成本等情况，分析与计划比较的差异，提出对以后有用的改进意见。 如果只在项目总结报告的时候，才进行度量的话，是不能算“感知级”的，度量的结果要能用于项目管理，而不是项目结束后了统计出到一些数字，尽管这些数字可以用来改善以后的工作，但对该项目本身工作的改善已经没有任何作用了。 达到初级量化管理的企业，能明确量化管理的目标，通过合适的度量办法，“感知”项目的各类参数，并根据各度量指标的实际数值，采取改善项目行为的措施。 * * * * * 进行量化管理过程中，我们能得到各类参数值，但该参数值应该怎样才算合理呢？例如进度偏差多少才算合理？遗留缺陷数量多少个才算合理？ 前面提到用“功能点”法来估算项目的规模，然后我们可以由规模导出工作量，但规模与工作量是怎样的一个关系呢？怎样根据规模导出工作量呢？相同规模的软件，不同的软件企业来做，导出的工作量是不一样的。 进行初级量化管理的时候，企业通过实际的参数值，来“感觉”项目的状况，当积累足够多数据的时候，管理者可能会找出项目间的一些共同的数据特点，如可以统计出“平均值”、“最大值”、“最小值”，这些数据，可以描述组织整体的性能。 当数据积累比较多的时候，组织级的经验数据，可以用来指导管理以后的项目，例如可以用组织的平均值做为量化管理的要求。这个时候，就达到了中级量化管理水平了。 中级量化管理有以下特点： 对历史数据进行一定的分析，得出一些数值，从这些数据能大概掌握企业的能力状况。 根据大概的企业能力状况，定出项目量化的管理目标，并用于管理项目。 利用历史的经验数据，由项目规模导出工作量。 　 * * * * 麦当劳的薯条不少人都吃过，味道很好，而且每家麦当劳的薯条味道很一致。麦当劳是如何做到的呢？我们分析一下生产过程，我们发现薯条从原材料开始，到后续加工，油炸的时间，薯条炸出来后多少分钟没有售出，就销毁，整个过程都有严格的控制，而且很多地方是量化控制，时间甚至精确到秒。严格的过程控制，保证了薯条能高质量地稳定地产出。全球的麦当劳，都用同一的严格过程来管理，所以保证了全球的麦当劳的食品都是高质量的而且是高度一致的。从另外一个角度说，只要麦当劳按照既定的过程来生产食物，我们就可以“预测”出最终食物的情况，我们将对最终产品的质量非常有信心。 那么我们软件开发，是不是也希望能达到这样的效果呢？大家可以回答一下这个问题：如果项目的规模、采用的技术、人员的水平等因素都确定了，那么您是否可以很有信心去预测这个项目的最终结果呢？ 如果按照中级量化管理的办法，还是比较难达到这个效果的，“可预测级”的量化管理应该是怎样的呢？ 在回答这个问题之前， 我们需要先搞清楚什么是“稳定”的过程，什么是“不稳定”的过程。我们以“煮饭”为例，说明什么是稳定的过程什么是不稳定的过程。 大家小的时候可能都野炊过，野炊煮出来的饭可能普遍都是不太好吃的，不是太硬就是太软。为什么煮出来的效果会差异这么大呢？仔细分析一下，我们发现很多因素会影响煮饭的最终质量，如：饭锅、火候、煮的时间、水量等。当我们用野炊的方式煮饭时，这些因素都不太好控制，所以出来饭的质量变化就会比较大了。 我们换一种方式来煮饭，用电饭煲煮饭，失手的几率是不是极大地降低了？为什么