项目管理复习.docxVIP

Capture14 质量，软件质量概念（事物的特征或属性 ） 在软件开发中，可能会遇到两种质量：a) 设计质量包括需求、规格说明书和系统的设计。 b)符合质量主要关注于实现的问题。 C)用户满意度= 合格的产品+ 好的质量+ 按预算和进度安排交付 质量-实用观点 玄妙观点 (如 Persig)认为质量是马上就能识别的东西，却不能清楚地定义。 用户观点是从最终用户的具体目标来说的。如果产品达到这些目标，就显示出质量。 制造商观点是从产品的原始规格说明的角度来定义质量，如果产品符合规格说明，就显示质量。 产品观点认为质量是产品的固有属性（比如，功能和特性）。 最后，基于价值的观点根据客户愿意为产品支付多少钱来评测质量。实际上，质量涵盖所有这些观点，或者更多。 软件质量可以这样定义 ： 在一定程度上应用有效的软件过程，创造有用的产品，为生产者和使用者提供明显的价值。 质量的维度 耐久性。是否能够对软件进行维护（变更）或改正（改错），而不会粗心大意地产生料想不到的副作用？随着时间的推移，变更会使错误率或可靠性变得更糟吗？ 适用性。软件能在可接受的短时期内完成维护（变更）和改正（改错），技术人员支持人员能得到所需的所有信息以进行变更和修正缺陷吗？ 审美。我们中的大多数都同意美的东西具有某种优雅、特有的流畅和醒目的“外在”，这些都是很难量化的，但显然是不可缺少的。 感知。在某些情况下，一些偏见将影响人们对质量的感知。 性能质量。软件是否交付了所有的内容、功能和特性，这些内容、功能和特性在某种程度上是需求模型所规定的一部分，可以为最终用户提供价值。 特性质量。软件是否首次提供了使最终用户惊喜的特性？ 可靠性。软件是否无误地提供了所有的特性和能力？当需要时，它是否是可用的？是否无错地提供了功能？ 符合性。软件是否遵从本地的和外部的与应用领域相关的软件标准？是否遵行了事实存在的设计惯例和编码惯例？例如，对于菜单选择和数据输入等用户界面的设计是否符合已接受的设计规则？ 认识软件质量：足够好软件提供用户期望的高质量功能和特性，但同时也提供了其他更好的包含已知错误的难解的或特殊的功能和特性 。 实现软件质量关键：软件工程方法 项目管理技术 质量控制 质量保证 Capture15 评审技术、什么是评审、为什么进行评审 评审会议由技术人员对技术人员进行 ；在软件工程过程中产生的对工作产品的技术评估 ；软件质量保证机制 ；训练场地 常用的评审技术：正式评审和非正式评审？ 度量 评审工作量、发现错误数、错误密度 总评审工作量和发现的错误总数定义为： Ereview = Ep + Ea + Er Errtot = Errminor + Errmajor 错误密度表示评审的每单位工作产品发现的错误数。 错误密度= Errtot / WPS 其中： 准备工作量Ep——在实际评审会仪之前评审一个工作产品的工作量（单位：人时） 评估工作量Ea —— 实际评审工作中所花费的工作量（单位：人时） 返工工作量Er —— 修改评审期间发现的错误所用的工作量。 （单位：人时） 工作产品规模WPS ——被评审的工作产品规模的衡量（例如，UML模型的数量、文档的页数或代码行数）。 发现的次要错误Errminor ——发现的可以归为次要错误的数量（要求少于预定的改错工作量）。 发现的主要错误Errmajor ——发现的可以归为主要错误的数量（要求多余预定的改错工作量）。 非正式评审和正式评审 非正式评审包括： a. 与同事就软件工程产品进行的简单桌面检查 b.以评审一个工作产品为目的的临时会议（涉及两个以上） c.结对编程评审 结对编程鼓励在创建工作产品（设计或代码）时进行持续的审查，其好处是即时发现错误，结果是得到更好的工作产品质量。 正式评审：FTR的目标是： 发现软件的任何一种表示形式中的功能、逻辑或实现上的错误 ； 验证评审中的软件是否满足其需求 ；保证软件的表现符合预先指定的标准 ；获得以统一的方式开发的软件 ；使项目更易于管理 FTR实际上是一类评审方式，包括走查和审查。 评审会议（限制争论和辩驳） 评审会（通常）由3~5人参加。 应该提前进行准备，但是占用每人的工作时间应该不超过2小时。 评审会的时间应该少于2小时。 FTR关注的是某个工作产品（例如，一部分需求模型、一份详细的构件设计、一个构件的源代码）。 与会人： 开发人员——开发这个工作产品的个人 通知项目负责人该工作产品已经完成，需要进行评审 评审主席——评估该工作产品是否准备就绪，制作产品材料副本，并将这些副本分发给2到3位评审员以便事先做准备 评审员——应该用1到2小时来评审该工作产品，通过做笔记或者其他方法熟悉该工作产品。 记录员——负