新过程改进方法与实践案例 978 7 302 23431 9 第二部分 SW CMM与CMMI模型 Ch05 可重复性管理.ppt

可重复性？ 虽然没有两场完全一样的战争，但是军事家们同样可以总结出历次战争过程的共性。通过对战例的总结，获得了面对新战争环境下如何能够利用已有战例经验和教训，设计出“可重复”的战争过程。“纪律性”是任何军事组织所强调的第一个共性。铁的纪律是实现“可重复”的基础。 工业化生产的最高境界就是产品生产的可重复性。具有组织纪律、能够进行大规模生产的产业工人是传统工业生产的基础。当今对于制造业，可重复生产的最佳途径是无人值守工厂。 CMM Level 2 Key Process Areas 需 求 管 理 软件需求总是不清楚的。 有人把需求的获取看作一个知识获取或学习的过程。 需求的典型输入是一个想法(idea)，理想的输出是软件规范说明(Specification)。 一旦一个软件需求能够用形式化语言描述清楚，软件的需求就变得100%清楚了。 需求的获取过程 客户的抱怨： “我们不知道我们需要的软件是什么，我们只知道你所交付的软件不是我们所需要的，此软件不好用。” Requirements Management--- Purpose 1. 需求管理的目的 建立客户和项目开发者之间的共同理解(common understanding) 2. 就客户需求，建立和维护与客户之间的协议(合同） 此协议(合同)表示为： system requirements allocated to the software. “customer”既可以解释为系统工程组、市场组、企业内部的一个部门，也可以解释为外部客户。 协议要包括技术和非技术性需求 协议作为建立、策划、执行、追踪软件项目整个生命周期活动的基础 分配的需求 3. 系统需求的分配 通常，软件只是系统的一部分。即使是在软件密集的系统中，仍然是这样的。必须把系统的要求分配给软件需求、硬件需求、以及人(或其他)的操作需求： 这样的分配过程，在大系统研制过程中，往往不是有软件工程组决定的（例如，是由系统工程小组分配的）。因此，许多情况下，软件工程组不能决定和控制这种分配。 在项目的约束条件下，软件工程组要采用适当的步骤，保证系统分配给软件的需求被表达、编写成正式文档、并控制其变更。 需求管理的目标 1) 控制分配需求以建立软件工程和管理所使用的基线。 通常系统工程组会将模糊的需求，或者，只要硬件没法实现的，都交给软件实现。高估软件的能力，并带来风险。 需求不清晰、以及今后的不断变更造成项目的失败。 建立基线，掌握“类似”的需求，从而达到“可重复”。 2) 软件计划、工作产品和活动与分配需求相一致。 开发计划往往会偏离实际的软件需求，直接依据项目经理或客户要求，定义进度和工作产品。 需求与项目的可重复性 需求是项目的最基本输入，也是决定项目之间是否具有类似的基本依据。 当需求清晰后，我们就能对项目的规模、问题领域、大致的软件体系结构、人员所需、时间进度、软件质量要求(包括功能和非功能性)有一个大概的了解。 找出“类似”项目，达到可重复！ 一旦需求是非常不稳定的(在开发过程中，不断变更)，以前的项目经验就失去意义。项目的“可重复性”就成为空话！ 对功能性需求的理解，可以澄清许多问题，例如： 1) 软件需求文档中的用例图(use cases)和部署图能让我们了解未来的系统如何使用和部署。 2) 哪些需求的实现难度大、风险大？ 通过对非功能性需求的理解, 可以澄清许多问题，例如， 1) 对开发环境、运行环境的理解，能让项目组估计出软件的难度。 2) 对行业标准等的理解，可以掌握足够的项目知识，建立与客户的共同理解。 3) 对编程语言、数据库等要求的理解，可以清楚对人力资源的要求。 项目的类似性 通过对功能和非功能性需求的理解，我们能够知道所谓的“类似项目”类似在哪些方面，例如，编程语言、用户的行业背景、数据库、软件规模、人力资源、进度、软件缺陷率的要求等。 特别是非功能性的要求，对于确定项目之间是否具有可比性，起着决定性的作用。 例如，实验室使用的求解微分方程的软件与运载火箭上求解微分方程软件，在功能上是一样的。 但是软件质量和运行环境的差别，造就了后者比前者要付出几十倍的费用代价。 例：针对非功能性需求的改进 Engineering Ingegneria Informattica SPA 意大利的一家大型软件工厂，420员工，1994年营业额3500万ECU。 目的 解决预算的准确性 方法 扩展开发理念，增强正式说明书中非功能需求（例如易用性、可靠性、可移植性）说明，使得这些因素对软件造成的影响可以在整个开发过程中被跟踪 建立自我加强型的生命周期，了解这些因素的影响，从而更好地制定评估和项目计划。 例：针对非功能性需求的改进 商业收益 实验的6个项目