我的msn：luoyear@netease.com

谢谢各位支持本坛子的兄弟姐妹

可用性测试为您带来的好处
简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。
本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。
在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。

使用反复、周期性的设计过程
反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
·        及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
·        综合设计：设计的所有方面应当齐头并进发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
·        及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。
·        反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。
相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。
螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。

构思阶段
产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。
在构思阶段，通常进行下列可用性活动：
环境研究
基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。
环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。
环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。
竞争性测试
通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。
竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争 — 产品必须比现有的进程更有效、更好。
进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。
用户/受众分析
了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：
·        计算机使用经验
·        年龄
·        接受培训的程度
·        用户群之间的社会关系
·        特殊要求（可访问性）
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。

规划阶段
规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic® 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。
根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。
用户情况
创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。
任务分析
任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。
一些要考虑的问题和活动：
·        此环境中的任务是什么？环境研究应能帮助您找出并描述用户所执行的任务。
·        创建顺序图，描述用户执行的任务之间、用户和产品之间的相互作用。
·        在构思阶段确定功能的作用领域。提出问题：“我们要支持的具体任务是什么？”
·        与产品设计者一起创建情节串联图板或顺序简图。
启发式评估
启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。
如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
1.        每个评估人员都浏览数遍界面，检查各种对话框元素，然后将其与一些已知的可用性原则相比较。
2.        评估人员相互合作，将结果合并到列表中，列出用户界面中的可用性问题，并注明设计方案中违反的相关可用性原则。
3.        一旦每个评估人员都分别执行了启发式评估后，他们就集中起来将其评估结果合并在一起。
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。
认知性遍历
认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！
根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：
1.        对系统原型的详尽描述，例如初级规范可提供什么样的系统。这种描述不一定是完整的，但要相当详尽。诸如菜单的位置或措辞这样的细节也可能导致相当大的差异。
2.        对用户在系统中要完成的任务的描述。该任务应当是大多数用户将要执行的有代表性的任务。
3.        一个完整的、书面的操作清单，列出使用给定原型完成任务所需执行的操作。
4.        指出用户的身份，以及评估人员能够假定这些用户已具有哪一类别的知识和经验。
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。
GOMS
GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。
Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
·        不言自明，目标就是指用户的目标。用户使用软件要达到什么目的？在下一天、下几分钟、下几秒钟？
·        操作符是指软件允许用户采取的操作。
·        方法是子目标和操作符经仔细设计后得出的序列，可用来实现诸如剪切和粘贴等目标。
·        选择规则是用户要遵守的判定规则，以确定在特定环境下要使用的方法。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。
卡片排序
卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。
卡片排序用于：
·        展示用户对于任务范围的总体模型。
·        展示用户如何对项目进行分组或分类的。
·        展示用户对项目之间的关系和相似性的看法。
·        将用户的概念模型转换为设计。
反复可用性测试
对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。
您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。
在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。
如 Jakob Nielsen 所述，反复的可用性测试包括：
1.        用户和任务观察 — 观察用户，保持安静，让用户做一切通常情况下会做的操作。
2.        情况 — 使用一种可以减少功能数量、降低功能级别的建模方法。
3.        简化的对谈式测试 — 一次安排一个用户完成一组任务，并要求用户“发现问题就直接告知测试人员”。
4.        启发式评估 — 基于基本可用性原则来评价界面。

开发阶段
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。
在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。
真实代码测试
让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。
可用性实验室测试
在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。
注意：   作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。

稳定化阶段
当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。
基准测试
对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。
要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。

为下一版本做准备
将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：
·        竞争性测试 — 在稳定化阶段，这种测试是对自己的产品进行测试，以将其与先前收集的有关竞争产品的数据作比较。
·        现场研究 — 类似于环境研究（该研究是要了解“我们要做什么软件？”），使用您已构建的软件来找出存在哪些问题，可在下一版本加以解决。
·        关于事件的工具化版本研究 — 软件的工具化版本基本上用来观测软件自身并在发生事件时记录数据。您在大量会话和用户的基础上对产品进行测量以找到使用趋势。

参考文献和资源
文献和书籍
·        Boehm、Barry W.Software Engineering Economics. NY: Prentice Hall, 1981.(ISBN: 0138221227)
·        Dumas、Joseph S. and Janice C. Redish.A Practical Guide to Usability Testing. London: Intellect Books, 1999. (ISBN: 1841500208)
·        Helander、Martin、Thomas K. Landauer and Prasad V. Prabhu, eds.Handbook of Human-Computer Interaction. North-Holland, 1997. (ISBN: 0444818766)
·        John, B. E. "Why GOMS?" ACM Interactions, vol. 2, no. 4 (1995): 80-89.
·        Microsoft Site Server Development Guide
·        Nielsen, Jakob. Usability Engineering. Boston: AP Professional, 1994。(ISBN: 0125184069)

简介
在工作中体现可用性
在创建软件的环境中，术语“可用性”表示一种方法，它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计，它从设计过程的一开始就将用户关心的问题和意见考虑在内，并提出在任何设计决策中用户的需要都应摆在首位。
这种方法最显著的特点就是可用性测试。在测试中，用户使用产品的界面进行工作，通过界面进行交互，就他们的观点和关心的问题与设计人员和开发人员进行交流。
本文讨论了可用性的概念，并讨论了为什么可用性在所有软件设计项目中都是一个重要部分。本文的第一部分定义了在软件开发环境中可用性意味着什么，以及它与衡量产品价值的其它方面间的关联。第二部分回答了一些常见的问题，包括：为什么可用性很重要，以及如何在开发过程中体现以用户为中心的设计理念等。本文在结尾处列出了一些书籍、论文和组织机构名称，帮助您加深对可用性的了解，并在项目中应用可用性。
本文中讨论的大部分概念在零售和内部软件开发中均有所应用。在阅读本文时，请注意“用户”和“产品”等词语，并思考如何将其应用到您的项目和最终用户中。

可用性定义
易于使用
可用性是衡量使用一种产品来执行指定任务的难易程度的尺度，它与实用性和受欢迎度等相关概念是有差异的。
可用性与实用性
决定产品可接受性的核心属性是其有用性，它用于评价实际使用产品时，是否能达到设计人员期望产品实现的目标。有用性的概念可以进一步划分为实用性和可用性。虽然这些术语间有联系，但它们却不能相互替代。
实用性指产品执行任务的能力。根据设计，产品执行的任务越多，其实用性就越高。
让我们以二十世纪八十年代末问世的典型 Microsoft® MS-DOS® 字处理程序为例。此类程序提供了多种强大的文本编辑和处理功能，但需要用户学习和记忆几十个令人费解的按键后才能执行这些功能。可以说此类应用程序具有很高的实用性（它们为用户提供了必要的功能），但其可用性却较差（用户必须花费大量的时间和精力来学习和使用它们）。与之形成对比的是，一个设计合理的简单的应用程序（如计算器）使用起来很容易，但其实用性却有欠缺。
这两种性质都是一种产品被市场接受所必需的，而且它们都是总的有用性概念的一部分。显然，若程序很好用但没有什么有价值的功能，那么没有人会使用它；如果程序的功能强大但却很难使用，那么用户也很可能会拒绝这个程序而转向其它的替代品。
可用性测试帮助您判断用户使用产品执行特殊任务的难易程度。但是，它并不能直接帮助您判断产品自身是否有价值、是否实用（在可用性测试中，用户可能会主动提出一些关于实用性的意见，但任何意见都应通过其它更可靠的研究方法予以验证）。
喜欢它与使用它
受欢迎度往往表示产品中可取的特性。如果人们喜欢某产品，就更有可能使用它，并将它推荐给其他人。但是，与实用性一样，您一定要小心不要将受欢迎度和可用性混淆。
人们喜欢某产品的原因往往与实用性和可用性无关。他们可能被产品的样式和引人注目的外观吸引，或被心目中所赐予的该产品的地位吸引。人们倾向于喜欢很好用的产品，但这并不是说人们普遍喜爱的产品就是可用的。
可用性是指人们是否可以使用该产品来执行他们需要执行的任务。可用性测试主要用于评价性能而不是评价喜爱程度，但标准化的调查问卷也可以用来衡量人们对产品的喜爱程度。
发现、学习与有效性
可用性包含很多方面，但通常这一术语特指发现、学习和有效性这三种属性。
发现表示针对某种特定的需要去寻找并找到产品的某一功能。可用性测试可用于确定用户找到某一功能所用的时间，以及在整个过程中用户犯了多少错误（关于定位的错误选择）。
学习表示用户弄清楚如何运用所发现的功能来完成现有任务的过程。可用性测试可以确定这个过程的长短，以及在学习该功能期间用户犯了多少错误。
有效性表示用户“掌握”了某项功能，不再需要进一步学习即可使用。可用性测试可以确定有经验的用户使用该功能时执行必要步骤所需的时间。
可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂，导致用户基本上每次使用时都要重新学习；对于这些功能，Microsoft 通常开发了使用向导，在整个使用过程中对用户予以指导。
光喊口号是不够的
软件设计人员有时以为简单的口号，如“使产品更可用”，就可以解决可用性问题。虽然对可用性的积极态度是重要的，但是只有在具体的产品创建环境中，通过对普通用户进行恰当的可用性测试，才能为设计人员提供所需的信息，使产品可以满足用户的需要。“使产品更可用”应当成为每个软件设计人员的座右铭，但是这句话只对那些了解“可用性”含义的设计人员才有意义。而对普通用户进行测试就是可以找到的最可靠的途径。

常见问题
为什么要强调可用性问题呢？
如果您还没有在产品设计过程中将可用性因素考虑在内，您可能会问：可用性为什么是必要的，或可用性为什么是可取的？毕竟，不进行任何可用性工作，也可能发售一个可以工作的、没有错误的产品。但是，通过引入以用户为中心的设计理念可以使产品在很多方面得以很大改进。
减少用户拨打技术支持电话的次数是执行可用性测试的最佳理由。较差的可用性是用户拨打软件技术支持热线的主因，而每个软件公司主管以及信息服务经理都知道产品支持的成本是多么昂贵。此外，用户不得不寻求技术支持增加了用户对产品的潜在不满情绪。如果用户发现贵公司的产品使用起来十分容易，那么他们就不必频繁地打电话寻求技术支持了。
对于内部使用的软件，之所以将可用性作为开发过程中的一个重要部分，其原因还在于它减少了培训费用。对用户而言，可用性强的软件学习起来比可用性不受重视的产品学习起来要容易得多。用户能够更快地了解产品的各项功能，并能长久地掌握它，这直接减少了培训费用和时间。
可用性测试有助于促进用户对产品的接受程度。有很多因素决定了用户对产品的接受程度，这些因素包括可用性、实用性和受欢迎度。对于零售产品，用户的接受程度往往直接影响对产品的重复购买或对产品的忠诚度，这说明用户可能将产品推荐给其他人。对于内部应用程序，用户的接受程度决定用户是否愿意使用该软件执行任务，而这些软件就是针对这些任务设计的，这有助于提高生产效率。提高可用性是提高用户对产品的接受程度的一个因素。
可用性可将您的产品与您的竞争对手的产品区分开来。如果两个产品在实用性方面从本质上讲是一样的，那么人们很可能认为可用性更好的产品高出一筹。此外，由于 Microsoft® Windows® 的外观和感受以及随附的编程准则划定了基本用户界面的使用区域的标准，因此很多执行相似功能的程序其外观与操作在相当大的程度上是相似的。这些相似性表明，即使可用性上的细微差异也会对用户的喜好产生重大的影响。
最后请记住，每个产品最终都要进行可用性测试。用户每次使用您的产品时，都是在对它进行可用性测试，而他们对可用性优劣的意见将会影响他们是否继续使用该产品。将产品推向市场之前，对产品进行测试，可以有助于确保用户对产品的满意程度。
它的花费是多少？
软件设计人员和项目经理往往担心，如果采用以用户为中心的设计过程并执行适当的可用性测试，恐怕要占用大量的时间并花费大量的金钱。事实上，花费在关注用户方面的时间和金钱通常是相当少的，而且与不这样做而导致的花费相比，这点花费也是微不足道的。
例如，设想一下在开发周期的后期而不是在前期（产品仍处在开发阶段时）对设计进行修正您要花费多少时间和金钱吧！如果您一直等到 Beta 测试时期才使用户接触到产品以便进行可用性测试，就会发现自己不得不将花费了大量时间开发的程序的各部分分拆重做。而若等到产品真正发布时，如果要根据负面反馈进行修改或支持较差的设计，因为产品支持的庞大开销或用户对产品的接受程度较差等原因，很可能要支付高昂的费用。
合理的可用性研究通常只需要两周或更短的时间，并可以显著减少开发周期后期进行修改所需的时间和金钱。进行测试所需的花费将根据您的产品的性质以及所测试的界面部分的不同而有所不同。
可以认为可用性测试与代码测试是类似的。成功的项目经理在计划开发项目时总是会考虑到代码测试。他们并不认为代码测试是项目时间表或预算外的额外部分，而是将代码测试作为开发过程的一部分而计入成本。因为若不进行代码测试，那么花费反而会高得多。对于可用性测试，情况也是如此。
怎样获得可用性？
在理解可用性的重要性基础上，软件设计人员有时试图“获得”一些可用性，就好象可用性是一种成分，他们可以简单地把它添加到产品中，这样产品就更可用了。然而，可用性应当是设计过程本身的一部分，不是您可以在设计过程的随便某一地方添加的“东西”。可用性专家提到“用户关注的”与“以用户为中心的设计”的原因是：可用性取决于将用户的需要一直作为设计过程的中心。以用户为中心的设计根据需要的不同，包含的内容不单单是在界面中按照一组规则，对按钮和菜单布置进行管理。可用性测试是对设计工作进行检查的良机，而不是在产品中“添加”可用性的一种方法。
Gould、Boies 和 Lewis (1991) 为以用户为中心的设计定义了 4 个重要的原则：
·        及早以用户为中心：设计人员应当在设计过程的早期就致力于了解用户的需要。
·        综合设计：设计的所有方面应当齐头并进的发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
·        及早并持续性地进行测试：当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。
·        反复式设计：大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
为什么应当将用户融入进来？
设计人员应当认识到他们自己不是普通的用户。与一般的用户相比，他们对正在开发的系统有着更深入的了解。因此，对大多数用户而言不明确或造成混淆的界面，可能对那些从事项目设计工作的人员来说是非常清晰的。某些软件设计人员可以在一定程度上代表普通用户，但他们绝对不能代替实际使用产品的真正用户。
因此，通过在早期关注普通用户的需要，并根据用户测试结果经常改进设计，以用户为中心的软件设计人员会提出更好的设计，并生产出更好的产品。
更好的设计将得到用户更好的认可。零售软件增加买进点的利益是很明显的：这增加了销售额。对于为内部使用而开发的软件，认可也是十分重要的：买进点增加将导致生产效率增加，并减少了对技术支持的需求。显然，从开发的一开始就将用户融入进来，并向用户表明您看重他们所关心的问题和需求，这将使用户更愿意协助您开发出更好的软件。
遵循这些准则就足够了吗？
Microsoft 为 Windows 计算平台开发了一系列界面准则，以此确保 Windows 程序具有一致的外观和感受。其它公司为非 Windows 计算平台开发了类似的准则，并且象 Jakob Nielsen 这样的专家撰写了大量关于设计可用 Web 页的文章。通过关于这些主题的大量信息，设计人员有时认为生产可用产品所需的全部工作就是严格遵守准则和规范。
这种想法的错误之处在于：准则在本质上是通用的。准则必须应用到各种各样不同的情况之中，因此它不能总是针对您正在设计的特定的应用程序制订最佳的行动方案。遵守一组合理编写的准则有助于您设计出风格一致的界面，但是您不能保证它是可用的，除非通过真正的用户对它进行了测试。当您的确要使用准则时，不要象使用详尽的说明书一样，希望根据准则执行的方法所生成的所有结果都是最好的。两个设计人员可以用两种不同的方法实施同一个准则，而两种实施方案对特定情况却不一定同等适用。而且，有时候严格遵守准则可能导致很差的结果，或在准则之间发生冲突。只有采用以用户为中心的设计，才可以在问题产生前排除它们。
对这个问题的另一种理解方式是：应当使以用户为中心的设计理念成为设计决策的决定因素，而不是以用户界面准则为决定因素。
是否需要创建可用性实验室？
不要以为可用性测试就意味着创建昂贵的实验室，在天花板上安装摄像机，安装单向镜，以及采用其它以小组为中心的设陷技术。的确，进行大量测试的公司通常认为建立专用的实验室十分方便，并且可用性顾问往往可以为客户提供各种各样的设施和设备，但您也可以在各种各样的设置和环境中执行有用、有效的可用性测试。
一种方法只需要一个测试人员（该测试人员对有人参与的研究工作与数据收集十分精通），在用户工作时坐在用户后面观察用户如何执行任务，这在会议室或办公室里就可以轻而易举地办到。Dumas 和 Redish (1999) 提供了大量关于使用观察法进行测试的信息。
随着可用性测试的进一步进行，您可以添加诸如摄像机、单向镜等设备，或其它帮助实时观察和记录用户显示器的工具。不必一下子添加所有的设备，即使一件一件地添加，也可以使您从可用性测试中获得更多有价值的东西。
另一种方法是，您可以将测试外包给可用性顾问。关于为您寻找合适顾问的几点提示信息，请参见下文的“我如何开始？”。
我如何开始？
一旦您决定将以用户为中心的设计原理运用到您的开发过程中，就需要决定是自己雇佣可用性专业人员还是将可用性测试外包给供应商。
可用性专业人员协会 (UPA) 有一份供应商指南，有助于找到为您执行测试的可用性顾问。
有些咨询部门还可以帮助您创建您自己的可用性实验室或开发内部的可用性程序，在您的设计过程中引入可用性理念。
如果您宁愿自己雇佣可用性专业人员，那么 Human Factors and Ergonomics Society 有职业介绍服务，使您可以找到潜在的雇员。很多可用性专业人员还属于 ACM Special Interest Group on Computer-Human Interaction (SIGCHI) 和 UPA，您也可以在他们的出版物和会刊上刊登招聘广告。
无论您选择哪种途径，请记住：您将要雇佣的是测试服务人员，而不是那些自己访问您的界面，并告诉您界面上有哪些错误的人员。设计人员不是普通用户的原则同样也适用于可用性专业人员。
关于这些公司和组织的信息，请参见下文的“资源”，您从中可以找到更多的关于可用性测试和以用户为中心的设计的内容。

资源
文献和书籍
Beyer、Hugh 和 Karen Holtzblatt。Contextual Design: Defining Customer-Centered Systems。San Francisco: Morgan Kaufmann, 1997。(ISBN: 1558604111)
Dumas、Joseph S. 和 Janice C. Redish。A Practical Guide to Usability Testing。 London: Intellect Books, 1999。(ISBN: 1841500208)
Gould、John D.、Stephen J. Boies 和 Clayton Lewis。"Making Usable, Useful, Productivity: Enhancing Computer Applications。" Communications of the ACM (January 1991): 72-86。
Hackos、JoAnn T. 和 Janice C. Redish。User and Task Analysis for Interface Design。New York: John Wiley and Sons, 1998。(ISBN: 0471178314)
Nielsen, Jakob。Usability Engineering。Boston: AP Professional, 1994。(ISBN: 0125184069)
Shneiderman 和 Ben。Designing the User Interface: Strategies for Effective Human-Computer Interaction。Reading, MA: Addison Wesley, 1998。(ISBN: 0201694972)

极端编程（eXtreme Programming，XP）的特点及讨论

转摘自XPchina.com

XP在很多方面都和我们传统意义上得软件工程不同，同时，它也和传统得管理和项目计划得方法不同。这些方法在软件工程和其他管理活动中都有借鉴意义。

特点如下：

不采用瀑布式得软件工程方法，而采用原型法。将一个软件开发项目分为多个迭代周期，每个周期实现部分软件功能。在每个周期都进行提出需求、设计软件架构、编码、测试、发布得软件开发的全过程。每个周期都进行充分的测试和集成。这样的好处是可以不断的从客户方面得到反馈，更逼近实际的软件需求。通过频繁的重新编码的过程，可以非常适应功能更改的需求，同时增加软件的易维护性。在不断的迭代中，避免架构设计的重大失误造成的软件不能如期交工，避免了软件设计的风险。

在软件设计中，强调简单性，就是坚决不作用不到的通用功能。同时，也不刻意避免重新编码，只有不断得重新编码才能保证软件得合理性。不害怕对整个软件推倒重做。认为重新编码是很正常得现象。每次得重新编码都会大大减少软件中得熵值。

在专业分工中，提出在开发团队中要有全职的客户人员的参与，同时在软件团队中也要有自己的领域专家。这样，可以和客户充分交流，彻底了解应用需求。这种软件需求的提出不是一次性的，而是不断的交流。

也有专门的软件架构的设计师，首先进行软件整体架构的设计。这种设计一般使用UML语言。

在软件开发的顺序上，和传统方法完全相反。传统方法是按照整体设计、编写代码、进行测试、交付客户的方法。而XP是按照交付客户、测试、编码、设计的顺序来开发。首先将要交付客户的软件的界面作出来，先让客户对软件有实际体验，这样，可以获得客户的更多的反馈，使需求可以在开发前确定。在编码前就先把测试程序做好，这样，编码完成后就可以马上进行测试。通过不断的测试来保证软件的质量。在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。

在项目计划的实现上，每次的计划都是技术人员对客户提出时间表，由最后的开发人员对项目经理提出编码的时间表。这种计划都是从下而上的，不是从上到下的，更容易保证计划的按时完成。同时，多个迭代周期也使工期的估计越来越精确。

在分工上，强调角色轮换，项目的集体负责，分工的自愿性。分工的自愿性就是每个人的工作内容不是由项目经理分派，而是由每个人自愿领取，这样保证了每个人可以发挥自己的特长，适应自己的情况。当然，在每个问题上都要有唯一的决策人，同时，也要经过充分的交流和沟通。角色轮换就是在项目中，一个人在不同的周期中担任不同的角色，可以保证每个人对项目的整体把握，方便项目中的沟通和理解。项目的集体负责，就是每个人不是完成自己的工作就可以了，要对整个项目的完成负责，任何人都可以对工作的任何部分提出自己的建议。任何人都可以从事任何工作。任何人都要对整个项目熟悉。这样做的优点是可以充分的锻炼人、可以发挥每个人的积极性、可以使项目不依赖于某个特定的人，方便今后的软件的维护，通过工作内容的变换可以提高人工作的兴趣。通过角色轮换还可以使每个人都劳逸结合，方便相互理解，避免由于不理解而造成的各种配合问题。

保证8小时工作制，避免加班。

（我加几条：要有充分的培训、要有每个人的提升空间、制定报酬要根据对企业的贡献大小，而不是职位的高低，允许下属比上级薪酬更高，薪酬的高低取决于绩效评定，同时绩效评定要尽可能量化。并且推行淘汰制。同时有有效的招聘制度。有强有力的后勤保障制度和轻松的企业文化。）

提出了成对编程的思路，就是每个模块的编码都是两个人一起干，共用一台电脑。这样，一个人编码时，令一个人就可以检查代码，或对编码的思路进行思考，写文档等。不再有另外的测试人员，两个人同时完成代码的测试，并且使先写测试程序然后再编程。这样避免了编程人员和测试人员的矛盾。也解决了一个人自己检查的局限性。两个人共同检查可以避免大多数的错误。在共同编程中还可以进行经验的交流和传授。也避免了将一个工作一直干下去的无聊，交流增加了情趣。并且两个人共同工作也增加了工作量的弹性，使项目计划的瓶颈工作能尽快解决。根据成对编程的思路，开发小组也可以分为两个小组，一个小组进行开发，另一个小组作改进和bug修正等工作。也有同样的效果。

在人员的分工上要灵活，要保证软件开发中的角色的齐全，但每个角色可以由几个人共同担任，也可以一个人担任几个角色，并且在项目的不同时期，不同角色的人员数量会不断变化。

每天或隔天，开一个站立会议（保证开会时间尽量短），来解决工作时间不一致和相互打扰工作的情况。在每个迭代周期也有一个计划和分工等的全体大会

XP的实施方法就要求能适应工作中出现的问题，不断对xP进行改进，而不能照搬套用。

XP的目标就是发挥人的最大积极性，保证充分的交流。

XP得优势是能很好得适应需求得更改、设计框架得更改。

XP采用和建立一个通常框架相反得方法来适应需求，而是尽量简单。

问题：
有没有感觉实施xp的前提条件很多，如果这些条件不能满足就不能充分事实xp.例如8小时工作，工作环境等。

8小时工作可以说即是前提又是结果，如果不能8小时工作，让开发队伍有充分休息，大家怎么能结成pair，高效的开发？而如果开发效率低下，大家有怎么可能只8小时工作。--notyy

XP可以说是各种思想的大集合，实际上XP的核心特点就是原型法的软件开发方法。其它的各种特点可能不一定是XP独有的，只是针对目前软件工程中存在的问题，分别提出了很多思路独特的方法。这些方法并不是一个紧密的整体，相互直接有可能分离、独立。因此，了解了XP的方法，可以只应用它的几个特点，不一定全部照搬。比如成对编程、8小时工作制、轮岗等，都可以单独实施。－－tomz

这个观点不认同，XP核心特点并不是原型法的开发方法。原型法的关键是在通过原型获取需求后，要毫不犹豫的抛弃原型，重新开发，因此原型可以是很粗糙的，代码质量可以是很拙劣的。而且因为原型是用来获取整体需求，所以要求原型要完整，覆盖到整个项目的各功能点。 而xp是迭代开发，并没有一个包含所有功能的“原型”版本，而且对每一个“小版本”都有很高的质量要求，比如总共有10个功能点，原型法要求做一个覆盖所有10个功能点的粗糙版本，而XP要求先做一个有2个功能点的版本，然后再每个开发周期往上面加两个功能点，并且这包含两个功能点的版本是要“确实完成”的，是要经过充分的测试，重构、提炼的，让人放心的小版本。这一点与原型法有很大差别。 ----notyy

啊，我是门外汉，确实没有搞清“迭代”和“原型”的区别。用词有误。那就是说：“XP的核心特点是迭代”。－－tomz

我感觉部分岗位的集体主义的软件开发也是XP的很有用的方法。但不知道在中国是否符合国情。－－tomz

本文是根据IBM一个开发团队的XP故事总结的，在www.linuxaid.com.cn网站上看到的。但现在在IBM和linuxaid网站上都找不到这个文章了。－－tomz

精彩文章，可否转载？--notyy

转载没问题，这只是我的一个读书心得，没有发表过。不过你要转载到哪里？这里不是你的网站吗？已经贴上来了啊？－－tomz
question:
“在进行软件架构设计之前就进行编码，可以使问题更早暴露，可以使最后的软件设计更体现编码的特点，更符合实际，更容易实现，也保证了设计的合理，保证了软件设计的大量决定的正确性。 ”
notyy兄，能详细讲一下吗？ 先编码后设计，有点不理解他的优点。。你先讲一下好吗？ 踏冰
世界上并没有先编码后设计的开发方法。xp的开发方法是边设计边编码。
所谓先编码后设计里的设计是指软件架构的设计，指先设计（和编码）局部的功能，在进行了几个周期的开发，有了足够多的需求和经验后再提炼出体系架构，是一种自下而上的设计方式。
好处是避免了先设计软件架构后编码的方式中容易出现的设计脱离实际，无法编码实现等问题。
缺点是早期设计变化剧烈，不断的refactoring，可能几个开发周期后，经过大量修改后设计会和第一个开发周期时所做的设计相差巨大。 但另一方面，这也正好说明，在编码前先设计软件架构，是非常困难的，很容易在后期发现难以克服的问题。--notyy
2002-8-30 23:51:13 tomz
极端编程属于轻量级的方法，认为文档、架构不如直接编程来的直接，前两者容易和最终编程产品脱节，容易做很多无用工，而对编程者来说，代码是最好的表达工具，所有的结构设计思想都马上可以用代码来表达，因此，不需要先对别人描述架构，只要编出来，别人自然懂了。
使用架构来表达毕竟了用编程直接表达在结构上会有脱节的地方。
另外，极端编程不明确区分设计者和编程者，编程者就是设计者，自然，程序代码就成了比较方便的架构表达工具。将两步并作一步，自然节省设计时间。
当然，并不是事先没有沟通，而是极端编程认为口头交流是最有效的，因此，就用不到架构描述工具。

计算机和通信技术的迅速发展，特别是Internet技术的发展与普及，为企业内部、企业与外部提供了快速、准确、可靠的信息交流渠道。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备支持系统。正是由于这样的市场需求与技术发展现状，为我国的IT行业带来了空前发展的机遇，特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力，其中软件质量保障在其发展过程中占有重要的位置。 众所周知，印度已成为世界上软件业增长最快的国家，目前每年软件业产值达数十亿美元，并且还在以每年30%～50%的速度增长。比较我国和印度的软件产业，就不难发现:中国拥有巨大的软件市场和世界公认的软件开发资源，在基础研究和对技术前瞻性的把握上，也有自己的优势，就整体社会经济环境而言也优于印度。此外，中国的软件开发人员费用比较低廉，仅是世界市场的1/3左右。虽然中国人并不缺乏软件开发的天赋，但是在越来越强调规模化经营的今天，先天不足的管理痼疾使我们举步维艰，难以摆脱小作坊式的软件开发模式。而印度软件业从一开始就立足于为美国软件企业服务，并遵循其软件开发的管理模式，与国际标准接轨。
管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
1.软件企业的组织结构
(1)A公司结构
图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。

图1
* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。
(2)项目组结构
1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
2) 汇报关系为:
Team Member->Team Leader->PC->EM->研发总负责人。
3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
1级:Software Engineer，刚毕业的本科生和研究生。
2级:Senior Software Engineer。
3级:Project Leader。
4级:Project Manager。
5级:Senior Project Manager。
3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。
A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。
A公司通常的项目组为4到5人，最多不超过10人。
以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。可以看出，A公司的组织结构非常清晰，各个部门分类非常细，任务明确，软件生产的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总经理，层层管理，沟通渠道畅通。而在我国，管理的不规范往往首先体现在公司的组织结构上，集中表现为部门的缺失和管理的交叉上。我国的软件公司，大部分规模较小，开发人员超过100人的公司很少。在印度，软件公司无论大小，都是“麻雀虽小，五脏俱全”，绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为，国内的软件企业要想有效地保障产品质量，首先就要在构架合理的组织结构上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构不合理，其他方面再下功夫也是徒劳。有人说，因为国内软件企业规模小，所以造成结构设置的欠缺，但笔者认为恰恰是因为没有建立一个规范化的组织结构，才会使软件产品质量不保，进而严重影响了企业的发展扩大。
2.项目计划
凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。
项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。
大概很多人都听过这样一句话：“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响，但对于软件企业而言，却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象？究其原因，笔者认为主要是因为对计划的重视程度不够，计划过于笼统、粗糙导致可执行性太差，再加上一些人为因素的影响，必然会产生这样的后果。
如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。
因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。
3.项目管理
当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：
(1)开发阶段和项目周期
开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
(2)流程
* A公司对流程比对项目更重视。
* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。
(3)计划
1) 计划详细、周到。
2) 流程中明确定义开发阶段。
3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
* 进入条件，输入;
* 验证方法;
* 结束条件，输出。
4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。
5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。
(4)Review
按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。
在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。
(5)QA
QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。
(6)度量数据
CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。
(7)团队精神
印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。
(8)培训
印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。
(9)配置管理
在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
(10)记录
记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
1)与客户和其他项目组的所有往来必须邮件记录。
2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。
3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。
4)记录比较准确、比较客观。
5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。
以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:
1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。
3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。
4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：
1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
2）合理的时间表――为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。
4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
5)沟通――在适当时机进行预排和检查;充分利用团组通信工具―电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。
4.PC（项目经理）
项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。
（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：
* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。
* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。
*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。
（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。
（3)总的说来，PC安排工作有这么几个特点:
a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。
b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:
* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。
* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。
* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。
* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。
d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。
e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。
f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者， 笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。
总结　　
以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在这个问题上不妨采取“拿来主义”的办法，对于好的，事实证明是成功的经验，首先是“占有”，然后才是“挑选”和“创新”。如果能把印度的管理经验真正领会并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用。

——采访印度NIIT CEO有感,一篇有趣的文章，论述中印程序员之间不同的另外一个方面
今天下午采访印度NIIT的CEO Vijay Thadani。NIIT是印度最大的IT培训机构，业务遍及38个国家和地区。同时，NIIT Tech. 也是一家CMM5的软件企业。
采访的详细内容大家会在CSDN的新闻里看到。我倒不是觉得这次采访有多么精彩，不过为了准备这次采访，我做了一些功课，查了一些资料，倒是真有些感触。
最大的感觉，我们还在喋喋不休的争论该不该走印度道路，印度已经一骑绝尘而去。我的同事邹震在一篇采访稿里总结说，印度大型现在软件企业的开发人员规模不是几百上千，而是几千上万，最大的InfoSys，其开发人员规模马上就要达到三万二千人，在软件工程化方面，印度已经走到了世界的最前列。现在再谈该不该走印度道路，谈要不要与印度竞争，已经是很可笑的事情了。而且，印度软件业并不象我们自我安慰的那样，安于外包的现状睡大觉，而是已经挺进自主技术领域，并在美国本土与IBM开展竞争。套句俗话，人家在产业升级！这样下去，5年之后，我们该讨论是不是要走越南道路了。
牢骚发过了，说点正题。
我问了这位CEO一个问题。我说中国程序员跟印度兄弟不一样，都很躁，几年拿不到高薪，得不到提升，就受不了了。印度兄弟好像不同，能忍。是不是这样？
他说不对，印度程序员也一样急躁，也想快快地拿高薪，早日升迁，这一点，全世界的程序员都差不多。
下面是最重要的话。
“差别在于，中国程序员把编程当艺术。这很正确，编程就是一门艺术。但是我们印度的程序员不但知道编程是艺术，而且认识到艺术背后还需要有纪律。你有你的艺术，我有我的艺术，她有她的艺术，只有通过纪律把我们的艺术整合起来，才能完成有价值的工作。我听说中国的程序员更擅长自由思考(free thinking)，所以在游戏软件方面很成功。印度软件的强项在于业务解决方案，在这个领域里，纪律格外重要。通过培训掌握技术之后，只要大家能够严格遵守纪律，认真把工作作到位，就能成功。”
艺术背后还有纪律，也许这就是印度软件成功的理念基础。对我们很多人来说，编程的最大魅力来自于创造的乐趣，来自于“不走寻常路”的乐趣，来自于超越的乐趣。如果编程是一件规规矩矩的机械工作，我想很多人都不会走上这条路。可是这当初驱使我们走上编程之路的乐趣，也许正是导致中国软件业始终无法壮大的本质原因。至少这位印度人是这么认识的。
我一向不赞成走印度道路，因为印度模式是最适合印度的软件发展模式，中国不是印度，当然不能走印度道路。但是印度成功的经验是可以借鉴的。印度人遵守纪律，于是就主攻业务类软件，接单定制，合同开发，建立超大型的软件企业。那么我们中国人的特点是什么？应该选择怎样的路线？建立怎样的软件产业结构？我不知道是否有人认真讨论过，不过似乎大家更多地在讨论“是走印度模式还是美国模式”这样的伪问题。我有的时候真的很奇怪，怎么我们就非得走个洋路线才能活下去？
这位CEO说中国的游戏软件很成功，不用多想也知道他没搞清楚，大概是听说中国网络游戏何其火爆，殊不知中国网络上的游戏，大多是韩国造。Free thinking? 我好像记得10多年前，人们说中国足球的优势是“灵巧”。

内容:

       功能驱动开发模式FDD
http://www.huihoo.com/development/fdd.html
FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同开发的一套针对中小型软件开发项目的开发模式。
FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。简单地说，FDD“是一个以Architecture为中心的，采用短迭代期，目期驱动的开发过程。它首先对整个项目建立起一个整体的模型，然后通过两周一次‘设计功能-实现功能’的迭代完成项目开发”。此处的“功能”是指“用户眼中最小的有用的功能”，它是可理解的、可度量的，并且可以在有限的时间内（两周）实现。在开发过程中，开发计划的制定、报告的生成、开发进度的跟踪均是以上述“功能”为单位进行的。在FDD中，它认为：只有良好定义的并且简单的过程才能被很好地执行。另外，由于在FDD中采用了短周期的迭代，最小化的功能划分法，所以可以对项目的开发进程进行精确及时地监控。
FDD的使用需要有相应工具的支持，Peter Coad等人开发出了一套扩展的UML（FDD UML Extensions），并在Together中实现有关的功能，详细内容可参见后文。
在FDD中，存在“主要功能集”、“功能集”、“功能”等概念，它们之间的关系及示例如下所示：
主要功能集 = 功能集1 + 功能集2 + …
功能集 = 功能1 + 功能2 + …
其中，主要功能集是在初始阶段根据用户的需求所制定出来的比较粗的，有待于细化的对开发项目所需要功能的描述；功能是在开发过程细化的结果，在每个迭代期中需要实现若一干个功能，这些功能的集合被称之为功能集。
在FDD中，它将开发过程划分为如下五个阶段：
l         制定整体的模型
l         根据优先级列出功能的详细列表
l         依据功能制定计划
l         依据功能进行设计
l         实现功能
每个阶段的定义又是通过被称之为：ETVX的方法从下面四个方面加以描述的：
l         Entry：Specify clear and well defined entry criteria for the process；
l         Task：列出所有要实现的任务列表，名称，是否需要实现，任务描述；
l         Verification：；制定对过程结果的评批标准；
l         eXit：过程结束时所需的结果；

FDD过程示意图
在FDD中主要存在三类人员：主要开发人员、类的所有者、功能团队，它们各自的含义如下：
l         主要开发人员：用于领导其它开发人员进行DBF/BBF的开发，对开发工作进行监督（例如对设计及代码进行审查）。主要开发人员的数量由项目整体的大小所决定，如果需要加快开发进度则可以再培养新的主要开发人员。与其它开发人员相比，主要开发人员具有更高的开发效率。Fred Brooks在几十年前就提出了：增加开发人员数量只会降低开发效率。但对于小型的，以用户功能驱动的轻量及的开发过程此原则并不适用。在此过程中采用增加人员的方法可以提高开发的并行效率。
l         类的所有者：一个类有且只有一个所有者，即一个类只能由一名开发人员进行设计及编码。采用这种方式是十分有效的，因为开发人员会感觉他拥有了部分属于自已的代码，他会以此为荣；此外，它还可以保证相关代码的一致性。如果此类中包含有复杂的算法，那么可以再增加一名专门负责算法的开发人员。虽然FDD是面向用户功能的，而不是面向类的，但用户最终关心的是那些他们需的功能，而并不关心在开发时采用何种框架模式，所以在此以类为单位进行人员分配与开发的宗旨并不矛盾。
l         功能团队：开发时功能会被分配给主要开发人员，再由主要开发人员根据实现此功能所需类的所有关系找到有关的开发人员从而构成一个临时的（最多两周）的团队。一名开发人员可以同时负责多个类的开发工作，即他可以在同一时刻处于多个功能团队中。因此在每个DBF/BBF中功能团队的人员均可能发生变化。在此团队中主要开发人员处于核心地位，团队内部的交流也是经及为中心的。采用这种方法可以加速开发进度，并且主要开发人员还可以对过程进行必要的监控，保证设计与实现的一致性。从更高的角度来看，主要的系统设计师又负责监控各功能团队中的主要开发人员。
采用FDD方式进行开发时，各阶段时间的分配关系大致如下所示：
l         Develop an overall model                     10% initial, 4% on-going
l         Build a features list                             4% initial, 1% on-going
l         Plan by feature                                          2% initial, 2% on-going
l         Design by feature, build by feature              77%（两周一个迭代期）

DBF/BBF中各阶段时间分配关系：
l         DBF
²        Walk through the domain              1%
²        Design                                40%
²        Inspect the design                3%
l         BBF
²        Code/test                             45%
²        Inspect the code                   10%
²        Promote to build                   1%

需要注意的是：上述Coding的过程中还包含有单元测试的内容。此外单从DBF/BBF的过程来看，设计所有的时间要比编码的时间长（40% : 45%），但考虑到FDD的整个实施过程（包括前期的建模过程），设计的时间还是比编码的时间要长的（45% : 35%）。
在FDD中另一个重要的，并且也是十分有特色的部分就是它的报告功能。每周Release经理要召开一次会议，会议一般限定于30分钟以内，在会上每个主要的开发人员全面地介绍其所做的工作，并标识出相应的项目状态图。通过这种口头上的交流，可以确保各主要开发人员能对项目的其它部分有一个充分的了解。会后，Release经理还要根据有关内容更新数据库中的信息并生成相应的报告，这个报告将发送给项目团队、用户以及主要的管理人员。



为跟踪项目开发状态需要使用数据库对有关内容加以保存，在数据库中应保存如下信息：
l         类型（问题域、人的交互活动、系统交互活动）
l         标识（功能集前缀+序列号）
l         状态（正在处理、不再需要、正常）
l         主要功能集
l         功能集
l         文档引用信息
l         活动事件
l         主要开发人员
l         问题域分析时的计划日期，实际日期
l         设计时的计划日期，实际日期
l         设计复查时的计划日期，实际日期
l         编码时的计划日期，实际日期
l         编码复查时的计划日期，实际日期
l         提交构造时的计划日期，实际日期
l         备注

项目计划表

功能详细列表
另外，有关类及类的所有者的信息保存在其它的表中。根据数据库可自动生成有关报告。

项目已完成功能统计表

FDD中扩展的UML
FDD 过程 #1: 开发总体模型
Entry Criteria:
客户已准备好建立一个系统。他已经有采用某种形式保存的需求列表。此时用户可能还不能完全分清楚什么是他“必面要的”，什么是他“想要的，最好有的”，但这没有关系。
Tasks:
组建建模团队        项目管理        必须        建模团队是由来自于领域以及开发方面的永久性人员组成。在建模的过程中也可以从其它项目中人员以便有更多的人可以参与并对模型进行评估。
领域分析        建模团队        必须        领域专家对问题域进行介绍，此过程可能是20分钟也可能是几个小时，需根据具体的问题域情况决定。在介绍时所涉及的内容应比问题域稍大一些。
学习资料        建模团队        可选        学习各种资料，包括：组件模型、传统的或者是采用use-case方式描述的功能需求书、数据模型以及用记手册。
生成非正式的功能列表        系统设计师 主要程序员        必须        建模团队生成非正式的功能列表，至于具体的细化和完善留到下一阶段进行。如果需要的话，应将有关的参考资料一并注明。
开发子模型        划分为小组形式的建模团队        必须        系统设计师提出最初的组件或者是入手点。根据对问题域的理解，小组使用原型及组件创建出类图。创建过程如下：首要关心的是类以及它们之间的关系，然后是类所包含的函数，最后才是类所具有的属性。在寻找类的函数的过程中可以参考对问题域的理解，最初的功能列表，以及原型中所建议的函数等方法。同时还需要生成一个或多个非正式的序列图。
开发模型        系统设计师 建模团队        必须         
记录候选模型        系统设计师 主要程序员        必须        记录员（可以由团队人员分别担任）记录下来工作中所评估过的比较重要的但未被采用的模型，以便于将来在项目中参考。

Verification:
内部及外部的评审        建模团队        必须        参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。

Exit:
结束过程时，团队必须提交如下内容，并且这些内容已经过开发经理以及系统设计师的审阅及批准：
-          类图，包括：类、类间关系、类的函数以及属性。类及类间关系建立起了模型的大致轮廓。根据最初的功能有列表以及非正式的序列图而来的函数展现出系统的功能，并且是后续开发过程中建立详细功能列表的前提。此外还应有非正式的序列图。
-          非正式的功能列表。
-          其它可供选择的模型信息。

FDD 过程 #2: 创建功能列表
在此阶段，团队标识出所有的功能，对其加以分组，为其设定优先级，并设置相应的权重。
在下面的活动中，小组工作的重点在于功能，因此领域专家可以不再需要。
Entry Criteria:
建模团队已成功地完成了FDD第一阶段的工作，开发出了系统的整体模型。
Tasks:
组建功能列表团队        项目经理 开发经理        必须        功能列表团队是由来自于领域专家以及开发方面的固定人员构成的。
标识功能 创建功能集        功能列表团队        必须        团队首先从上一阶段得到的非正式的功能列表入手，接着：
                -          将模型中的函数转换为功能
                -          将模型中的moment-intervals转换为功能集（并将功能集再组织成主功能集），头脑风暴，选择，添加功能以便实现用户所要的以及所想的。
                在此采用下述格式进行描述：
                -          针对功能： <action>the<result><by | for | of | to>a(n)<object>
                -          针对功能集：<action><-ing>a(n)<object>
                -          针对主功能集：<object>management
                此处的object可以指一个人、一个地点或者一件事（包括：角色、某一时刻、某一时间段或者是描述）
为功能集以及功能设置优先级        功能列表团队        必须        通过“Feature Board”为功能集以及功能设置优先级。优先级的划分：A（必须实现），B（最好能实现），C（如果可能则实现），D（以后再实现）。设置时是依据用户的满意程序所定的。
分解复杂功能        功能列表团队        必须        在系统设计师的带领下开发人员对功能进行查开，以便找到那些无法在两周之内完成的功能，对此类功能应将其细分为更小的功能或步骤。

Verification:
内部及外部的评审        功能列表团队        必须        参与此项目的领域专家进行内部自评，外部评审是必须的，以便判断对问题域的理解是否正确，功能是否是必须的，范围是否合理。

Exit Criteria:
    本阶段结束时，详细的功能列表必需已经产生了，并且将功能进行分组形成主功能集以及功能集，此外这些内容已经过开发经理以及系统设计师的审阅及批准。

FDD 过程 #3: 根据功能制定计划
根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。
Entry Criteria:
功能列表团队已成功地完成了FDD第二阶段的工作，并已形成详细的功能列表。
Tasks:
计划制定团队        项目经理        必须        计划制定团队由项目经理、开发经理以及主要开发人员给成。
制定功能以及功能集的开发顺序        计划制定团队        必须        计划制定团队设置开发的先后顺序，并制定出最初的针对功能集或者主要功能集的完成日期。
为类指定实现人        计划制定团队        必须        根据开发顺序以及功能的重要性为每个类指定特定的实现人。
为主要功能集以及功能集指定相应负责的主要设计人员        计划制定团队        必须        根据开发顺序以及功能的重要性为每个主要功能集或者是功能集指定相应负责的主要开发人员。

Verification:
内部及外部的评审        计划制定团队        必须        参与此项目的计划制定人员进行内部自评，外部评审是必须的，并且是由更高一级的管理人员进行。采用“由顶向下”的方式让所有的开发人员均对此计划进行评估。通常一些开发人员由于过分保守会希望延长开发时间。但另一方面，项目经理或者是开发组长又会觉得“每个人都具有与我相同的能力”从而认为可以提前完成开发。在此应进行相应的平衡。

Exit Criteria:
本阶段结束时，开发计划已经产生了，并且这些内容已经过开发经理以及主要设计师的审阅及批准。计划中应包括以下内容：
-          一个整体的开发日期
-          针对每个主要功能集、功能集、功能指定有关负责人（CP）以及完成时间
-          针对每个类，指定负责其完成的开发人
注意：
    为便于为功能设置优先级，可以创建一个称之为FFB（待实现功能板）。

FDD 过程 #4: 根据功能进行设计（DBF）
根据已制定的层次化的、具有优先级以及权重的功能列表，项目经理、开发经理以及主要开发人员一起制定出DBF/BBF阶段的里程碑。
Entry Criteria:
计划制定团队已成功地完成了FDD第三阶段的工作。
Tasks:
组建DBF团队        主要程序员        必须        主要开发人员从已有的类中找与可能与特点功能有关的类，然后找到负责实现这些类的开发人员并将他们组建成功能实现团队。开始进行功能的设计，如果需要的话，还可以请领域专家加入。
问题域学习        功能实现团队 领域专家        可选        （本步骤是可选的，主要依赖于功能的复杂性而定）领域专家将对问题域进行一个一般性的介绍，他只介绍与功能有关的内容，但这并不是为理解与功能有关的上下文所必须的工作。
学习有关参考资料        功能实现团队        可选        （本步骤是可选的，主要依赖于功能的复杂性而定）根据功能列表中所列的参考书目以及其它的可拿到的资料，功能实现团队的成员进行学习，以便获得与功能相关的详细的信息。
创建序列图        功能实现团队        必须        根据对功能的理解以及原有的非正式的序列图和组件，功能实现团队创建一正式的，详细的序列图。同时应记录下可选择的其它方案、决定以及注释。主要的开发人员将序列图添加至项目模型中（同时也要更新相应的类图）。
实现类及其方法的原型        功能实现团队        必须        每位类的实现人员根据序列图更新有关类及类中的方法，这包括：方法的参数、返回值、错误处理以及消息的发送。
设计复查        功能实现团队        必须        功能实现团队完成对设计的复查。如果主要开发人员认为有关功能的设计比较复杂并对其有所担心的话，他可以从别的地方请若干人员一起进行复查。
记录设计复查活动        文档人员        必须        团队中的文档人员针对类的实现人按顺序将有关设计复查的活动记录下来。

Verification:
设计复查        功能实现团队        必须        功能设计团队通过对序列图的“走查“实现内部的复查。外部评审是必须的，以确保存有关功能均以实现。

Exit Criteria:
本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：
-          功能及其相关参考资料（如果有的话）
-          详细的序列图
-          更新后的类图
-          更新后的类及其方法原型
-          开发团队认为有价值的其它实现方案

FDD 过程 #5: 根据功能进行设计（BBF）
在DBF工作的基础上，每个类的实现者完成类的各个方法。此外他还需完善基于类的测试方案并实现类一级的单元测试。根据主要开发人员的意见，功能实现团队可能还需在进行单元测试之前先进行源代码检查。当代码编写并检查后开发人员就将其放入配置管理系统中。在所有的类均已完成并Check-In之后，主要开发人员将代码提升以便进行构造。
Entry Criteria:
功能实现团队已成功地完成了FDD第四阶段的工作。
Tasks:
实现类及其方法        功能实现团队        必须        根据DBF中的详细的序列图类的实现人员完成类的方法的实现。此外他也要为测试实现有关的测试方法。主要开发人员则需添加针对功能的测试方法。
代码检查        功能实现团队        必须        主要开发人员负责安排一次针对BBF的代码检查，检查可以在单元测试之前也可以在其后。一般检查是由功能实现团队成员加以完成的，如果主要开发人员认为需要的话，也可以请团队以外的人进行检查。
代码检查记录        文档人员        必须        团队中的文档人员针对每个类的实现人将有关的代码检查活动记录下来。
单元测试        功能实现团队        必须        每个类的实现人员均需测试相应的类的代码以及此类所支持的功能。作为所有功能的集成者，主要开发人员对整个功能进行测试。
Check-In代码并对其进行构造        功能实现团队        必须        代码一旦编写完成并经过检查和测试，类的实现人就可以将其放入配置管理系统中。当所有的类均已完成Check-In并且可以正常工作时，主要开发人员将提升代码以便进行构造，同时更新在功能列表中的有关功能的状态信息。

Verification:
代码检查及单元测试        功能实现团队        必须        功能实现团队必须进行代码检查。文档人员应记录有关活动。

Exit Criteria:
本阶段结束时，应已完成如下工作，并且这些工作已经过主要设计师的审阅及批准。计划中应包括以下内容：
-          实现了类的方法并对代码进行了检查和单元测试
-          按顺序针对每个类的方法的单元测试记录
-          类已被开发人员Check-In，主要开发人员已提升代码进行构造并同步更新功能状态。

再论"业余"和"专业"
----致力职业化 提高成功力
文档版本
版本
创建时间
创建人
备注

1.0.0926.1
2003-9-26
郑昀
第一稿

1.0.0927.1
2003-9-27
郑昀
第二稿

SQWebMail之烂
外面比较盛行的一种qmail的Web界面，是SQWebMail，还算是比较受人追捧的，而且框架搭也算是好的。
但你看看他的源代码。不说别的，只要看主程序sqwebmail.c的源代码就知道了，严格说，这整个工程一点也不符合软件工程编码规范。
sqwebmail-3.3.1文件夹下有818个文件，27个子文件夹，但是注释呢，命名规范呢？其中代码耦合性也太强，动一发而牵全身，很不好维护。这竟然是一帮大学里的教授后来改进的版本，一砣：

/*

** Copyright 1998 - 2001 Double Precision, Inc.  See COPYING for

** distribution information.

*/

static void do_output_form_loop(FILE *f)
{
     if (strcmp(kw, "a") == 0)
         {
              …
         }

         else if (strcmp(kw, "d") == 0)

         {

              …

         }

         else if (strcmp(kw, "D") == 0)

         {

              …

         }

         else if (strcmp(kw, "G") == 0)

         {

              …

         }

         else if (strcmp(kw, "r") == 0)

         {

              …

         }

         else if (strcmp(kw, "s") == 0)

         {

              ….

微软的源代码
让我们再来看看微软的源代码，这个源代码大家机器上都有，不是什么秘密，就在C:\Program Files\Microsoft Visual Studio\VC98\CRT\SRC下面，看看人家怎么做的，再看看sqWebMail。

    咱们不讨论算法意义上的有无漏洞，兹为了说明代码的可读性，举一个最简单的例子，微软的工程师是这么写一个strlen的经典实现：

/***
*strlen.c - contains strlen() routine
*
*       Copyright (c) 1985-1997, Microsoft Corporation. All rights reserved.
*
*Purpose:
*       strlen returns the length of a null-terminated string,
*       not including the null byte itself.
*
*******************************************************************************/

#include <cruntime.h>
#include <string.h>

#ifdef _MSC_VER
#pragma function(strlen)
#endif  /* _MSC_VER */

/***
*strlen - return the length of a null-terminated string
*
*Purpose:
*       Finds the length in bytes of the given string, not including
*       the final null character.
*
*Entry:
*       const char * str - string whose length is to be computed
*
*Exit:
*       length of the string "str", exclusive of the final null byte
*
*Exceptions:
*
*******************************************************************************/

size_t __cdecl strlen (
        const char * str
        )
{
        const char *eos = str;

        while( *eos++ ) ;

        return( (int)(eos - str - 1) );
}

    当然，微软的STL实现版本是公认的可读性差，我也看不过眼，换了STLPort了事。
想跟Microsoft,Oracle,CA,IBM竞争吗？
在我看来，我不管你是什么软件公司，管你是什么主义战士，就一个原则，要是不会写文档，不会写注释，写个函数连个输入输出异常注释都没有，那你就别在这行混了，不够丢人现眼的。有时间也翻翻软件工程，软件管理的书，看看那个书上赞成软件没有注释，没有文档？
    花钱买享受，这是人生的一个基本原则，干吗在那里吭哧吭哧一代人又一代人反复看着同一批糟糕的源代码，还给自己脸上贴金“源代码剖析”，那是因为你不剖析都不行。简直就是浪费生命。公司要赚钱，要快。没本事写注释的人就开掉，没本事遵循软件工程的人就开掉，这就是我的原则。想加入CMM的行列吗？最起码你的公司要过ISO9001吧？
你们公司有吗？就靠没注释没文档？能过吗？能够跟Microsoft,Oracle,CA,IBM竞争吗？

自由软件的“自由”含义：
自由软件，一般指遵循GPL或LGPL规则的程序。GPL或LGPL规则要求源代码公开，并且允许你在遵循GPL或LGPL的情况下享有共享和修改自由软件的自由。
    当我们谈到自由软件（free software）时，我们指的是自由而不是价格。我们的GNU通用公共许可证决意保证你有发布自由软件的自由（如果你愿意，你可以对此项服务收取一定的费用）；保证你能收到源程序或者在你需要时能得到它；保证你能修改软件或将它的一部分用于新的自由软件；而且还保证你知道你能做这些事情。
    首先，GPL规则中并没有要求软件的维护者一定要提供详细的文档和注释（而且我找了几个著名的自由软件源代码看了一下，注释还是有的，只不过没有详细到每行代码都有的地步。）。我认为详细的文档和注释作者是作为服务提供的，而服务是要收费的。国内的第一个开源软件项目Minigui（一个极好的中文图形界面，可以只有2兆大小），他提供源代码和用户使用说明的详细文档，至于开发文档和函数库说明，他会收取600元的费用。我认为这个价格只是个成本价，假如你连这点费用都不肯付的话，那就没什么好说的了。
至于微软，由于你根本就见不到源代码，所以根本不存在为他的文档和注释发愁的情况。不要说你们公司能见到部分源码，你们是微软的合作伙伴，那别的人呢？而自由软件的源码是对所有人开放的。更何况你们也只能见到一小部分源码而已。而且微软决不会允许你把他的产品移植到别的操作系统上或一些新的机器上的，这些工作只有他自己才能做，因为你见不到所有的相关源代码。而自由软件就可以，你可以把他移植到任何一个操作系统上，包括windows。一个新的cpu芯片出来，没多久就会有一个黑客把linux移植上去，而这个黑客并不是linux的维护者，为什么他可以作到这样的事呢，因为自由软件是源码公开的。
    我认为微软之所以提供详细的文档和接口说明，部分原因是他不提供源代码，不得不这么做，否则别人就没有任何办法去使用他的产品了。当然了，微软产品的简单易用是出了名的。可是由于你没有源码，很多时候为了达到某个目的，除了微软替你去做，你是根本无法完成的。例如高性能和新的功能。你难道可以命令微软去做这一切么？
    所以，不要对自由软件有这么大的意见。假如你想要详细的文档，你可以购买他们的服务。如果维护者不是某个公司，而是个人行为的话，你可以和他本人联系（一般他都会留下e_mail），也许他不收费就会提供给你的，即使收费，我想也不会比微软更贵的！

做Coding，还是多一点职业道德
专业做Coding，还是多一点职业道德，多看看软件工程的书。想想如果是你开公司，你难道会鼓励你手下的人不写注释，不写文档吗？
有机会的话，读读《Code Complete》(http://www.csdn.net/develop/Read_Article.asp?Id=10997)，这本几十年前的书，就已经说得很明白了：

交流和合作
    真正优秀的程序员应学会怎样和别人工作和娱乐，编写可读代码是对程序员作为组中一员的要求之一。
    计算机也就同其它人一样能读懂你的代码，但是它要比其它人更能阅读质量差的代码。作为可读性原则，你应将修改你的代码的人时刻记在心上。开发程序首先应同程序员交流，其次则是和计算机交流。
    绝大多数高水平程序员喜欢使自己程序的可读性强，并抽出充足的时间这样作。虽然只有一些人能坚持到底，而且其中一些人还是高水平的代码编写者，对开发中程序员级别的了解，有助于解释什么地方适合于此原则：
    级别1：初学者
    初学者是能使用一种语言基本能力的程序员，这样的人能够使用子程序、循环、条件语句和其它许多语言特征。
    级别2：中间者
    中间级程序员有使用多种语言的能力，并且至少非常熟悉某一种语言。
    级别3：专家
    编程专家对其语言或环境或对这二者有着很深的造诣，这种级别的程序员对公司有价值的，而且有些程序员往往就停留在这个水平上。
    级别4：大师
    大师有着专家那样的专业知识，并能意识到编程只是15％和计算机交流，其余85％是和人打交道。一般程序员只有30％的时间甚至更少。大师所编写的代码与其说是给计算机看倒不如说是给人看的。真正的大师级程序员所编写的代码是十分清晰易懂的，而且他们注意建立有关文档。他们也不想浪费其精力去重建本来用一句注释就能说清楚的代码段的逻辑结构。
    一位不强调可读性的高水平代码者可能停留在级别3的水平上，但是问题还不止如此。依作者本人的经验，人们编写不可读代码的主要原因在于他们所编代码质量较差。他们并不是自言自语地说：“我所编代码不好，所以我要使其难以读懂”，而是他们并不能完整地理解自己的代码以致于不能使其是可读的，这就使他们只能停留在1或2级的水平上。我所见的最差的代码是由一个任何人看了她的程序后都会望而生畏的人所编写的。最终，她的上司威胁说如她再不改正就要解雇她。她的代码是不作注释的，并且其程序中充满了如x，xx，xxx，xx1和xx2这样的全局变量。她的代码给了她大量的机会显示她的改错能力。
记住我们是专业程序员，我们的视角一定要和业余的区分开来。
我们不是自由软件工作者。
我们是靠这个赚钱的。所以，你用不着替他们辩护。因为你天生应该喜欢让你赚到更多钱的事物。
我赞同微软的商业运作方式。我赞同付费服务。因为我也是靠这个吃饭的。
不管是微软，还是IBM，都有许多这方面的专家现身说法，多读读这些人的书。别相信那些小公司的或者在校的学生，有时候他们的话是毒药，会毒害你的心灵，蒙蔽你的双眼，让你看不清楚商业社会里面的游戏规则。
"业余"和"专业"
下面摘录透明采访软件思想家Gerald Weinberg的访谈摘录，在http://www.umlchina.net/touming.html：

　　 "业余"和"专业"
　　 "程序开发"这个词所蕴含的行为方式是无穷无尽的。　　
　　一位业余程序员可能刚刚用六条语句写就了一个BASIC程序，可以用来求解二次方程的根，便开始就程序开发的理论与实践侃侃而谈--最令专业程序员们反感的，莫过于此。
　　 --《程序开发心理学》，第7章
　　 《程》：我注意到您多次强调"业余程序员"和"专业程序员"之间的差异……
　　 GW：因为我认为这是一个非常重要的观念。并不是"以编程为生的人"就有资格自称"专业程序员"的，但真正对软件学科起到推动作用的全然是专业程序员。这并非贬低业余程序员，任何一门学科都有业余爱好者，这无可厚非。但有必要划清业余选手和专业选手之间的界限，这样业余选手也能找到自己努力的方向。
　　 《程》：可是，如今软件的范围如此宽泛。从政府机关到航天飞机，从移动电话到超级市场，到处都有软件。各种软件之间的差异如此巨大，我们又该如何区分专业程序员和业余程序员呢？

　　 GW：在我看来，首先应该考虑的是他们编程的目的。如果只是为一己私利而编程，如果编程的结果对别人毫无影响，这就是业余程序员的编程方式。
　　举个例子吧，计算机系的研究生在知识的深度和广度上都已经相当不错了，但他们通常只是为自己编程--为了学习、或者为了拿到学位，所以他们仍旧只是业余程序员。如果他们在学习之余还有一份工作，为别人开发实际使用的软件，这时他们就是专业程序员。
　　请记住，专业程序员未必都很出色，业余程序员也可能出类拔萃，但他们编程的目的是不同的，这决定了他们之间本质性的差异。
　　 《程》：自从知道您对"专业"和"业余"的划分之后，我就一直想了解您对共享软件（share-ware）的看法。很多年轻程序员怀着淘金梦去做共享软件，您认为共享软件对于软件行业有什么贡献？
　　 GW：几乎所有的共享软件都是垃圾。虽然商业软件和开源软件也有不少垃圾，但共享软件几乎全是垃圾。我曾经试用过一些共享软件，但仅仅是尝试而已。如果我要掏钱买一个软件来用，我一定要求有一家值得信赖的公司为它提供支持。至少在美国，值得信赖的软件公司并不多。很多公司开张不到五年就倒闭，然后他们的顾客再也得不到任何支持。而共享软件，它们的用户能得到的保障就更少了。不，至少我不会去买这样不可靠的软件。
　　如果从软件行业的角度来说，共享软件给年轻人们灌输了很糟糕的习惯，让他们以一种业余选手的方式工作。共享软件的作者们习惯于单打独斗，总是凭着自己的爱好工作，这种牛仔式的工作方式至少是缺乏专业精神的。
小结
      我的想法就是，共享软件或者帮别人打零工的制作流程，给了年轻气盛的程序员们一种缺少项目管理的开发环境，这是不太好的修炼方式，容易走火入魔。
“即使是一个不够完美的东西，在某个特定时期也有他存在的价值”，这个辩证法我当然同意。但是我认为一个项目的源代码最基本的构成因素就是代码和注释和文档，这是三要素，如果没有这些东西，就像生下个儿子却没有JJ一样，根本就没有面世的必要。所以这不是完美不完美的问题。

开源项目和商业软件，如果不遵守基本项目生存规则，无论其中有多么高的高手参与，一样会失败。
我赞同商业开发模式，但不反对开源，如果做得好，我们也会拿来主义。如果做得只是一个徒有代码和功能的开源项目，那我觉得他会走向衰亡。看看SourceFouge上的那么多东西，真正有几个能够为商业社会所采用？几率有多大？其实像有着优秀项目的人，如果归拢到公司里，可能会有更大的发展。因为商业公司有足够的财力推广，有足够的人力包装。
欢迎指正和讨论。
本文档所包含的信息代表了在发布之日，zhengyun_ustc对所讨论问题的当前看法。
本文档仅供参考。
用户必须遵守所有适用的版权法。在不对版权法所规定的权利加以限制的情况下，如未得到 zhengyun_ustc和CSDN.Net明确的书面许可，不得出于任何目的、以任何形式或手段（电子的、机械的、影印、录制等等）复制、传播本文的任何部分，也不得将其存储或引入到检索系统中。

Thank CJW
Written by zhengyun_ustc ( at ) hotmail.com

来自：清华大学出版社《深度精耕——日本软件企业精义解读》 作者：唐德权 [2004/11/08]
索林根的软件度量指南：十大方针
软件度量专家索林根(Van Solingen)在《聚焦产品的软件过程改善》(Product Focused Software Process Improvement)中详细阐述了软件度量项目工程(Measurement program engineering)，提出软件度量的十大方针，如下所示。
1. 准备让软件开发者参与软件度量项目；
2. 开始软件度量工程前了解软件产品的质量目标、过程模型和学习目的；
3. 软件度量项目工程为目标导向，确保具备有限但相关的度量设定；
4. 指定期望值(假设)；
5. 由具有实际度量经验的人员按照规则对度量数据作出分析和解释；
6．将度量数据的分析和解释聚焦于：详细而精确的过程行为、全局过程、或者产品质量目标，但是决非聚焦于个人绩效；
7. 执行专门资源(人员)来支持度量项目工程的开发团队；
8. 评价实际产品质量和目标产品质量的差距；
9. 评价过程行为的影响(产品质量方面)；
10. 将特定情景中过程行为的知识存储到经验数据库中。
高尔发的关键成功因素：九大要素
品质与生产力管理集团(Q/P Management Group)总裁斯科特·高尔发(Scott Goldfarb)在《建立有效的度量体系》(Establishing a Measurement Program)中认为，建立并实施有效软件度量体系的关键成功因素包括如下：
1. 确定度量目标和计划；
2. 获得高层管理者的支持；
3. 拥有专属资源；
4. 面向员工的培训、教育和营销推广；
5. 日常工作中的度量一体化；
6. 聚焦于项目团队的结果；
7. 度量不要针对个人；
8. 有效定义数据以及实情报告制度；
9. 推动度量自动化。
软件工程研究所的软件度量规则：二十八条规则
美国卡内基·梅隆大学软件工程研究所在《软件度量指南》中列出了如下软件度量的规则：
1. 理解软件度量方法只是达到目的的手段，而其本身并不是目的；
2. 以应用度量结果而不是收集数据为中心；
3. 理解度量的目标；
4. 理解如何应用度量方法；
5. 设定期望值；
6. 制定计划以实现早期成功；
7. 以局部为重点；
8. 从小处着手；
9. 将开发人员与分析人员分开；
10. 确信度量方法适合要实现的目标；
11. 将度量次数保持在最低水平；
12. 避免浮夸度量数据；
13. 编制度量工作成本；
14. 制定计划使数据收集速度至少是数据分析和应用的3倍；
15. 至少每月收集一次关于工作投入水平的数据；
16. 明晰关于工作投入水平数据收集的范围；
17. 仅收集受控软件的错误数据；
18. 不要指望准确地度量纠错工作；
19. 不要指望找到界定完善的放之四海而皆准的过程度量方法；
20. 不要指望找到过程度量的数据库；
21. 理解高级过程的特征；
22. 应用关于生命周期阶段的简单定义；
23. 用代码行表示规模；
24. 明确将哪些软件纳入度量范围；
25. 不要指望使数据收集工作自动化；
26. 使提供数据的工作更容易；
27. 使用商业上可用的工具；
28. 认为度量数据存在瑕疵、不精确也不稳定。
帕克的目标驱动软件度量原则：四大原则体系
帕克(Robert E. Park)、哥特(Wolfhart B. Goethert)和弗罗哈克(William A. Florac)在1996年的《目标驱动软件度量指导手册》(Goal-Driven Software Measurement—— A Guidebook)中提出软件度量的原则如表5-10所示：
表5-10 帕克的目标驱动软件度量原则
1. 部门管理者的度量原则

—— 设立清晰的目标；
—— 让员工协助定义度量手段；
—— 提供积极的管理监督：寻求和使用数据；
—— 理解员工报告的数据；
—— 不要使用度量数据来奖赏或者惩罚实施度量的员工，并确信他们知道你和其他任何人都遵守这一规则；
—— 建立保护匿名的惯例，对匿名提供保护将建立起信任并培育起可靠数据的收集机制；
—— 如果员工的报告基于对组织有用的数据，支持他们；
—— 不要强调那些排斥其他度量方式的某种度量方式或者指标。

2. 项目管理者的度量原则

—— 知晓组织的战略性焦点并强调支持该战略的度量手段；
—— 在追踪的度量手段上与项目组获得一致，并在项目计划中定义这些度量手段；
—— 向项目组提供规则有序的关于其所收集数据的反馈；
—— 不要私人单独地进行度量。
3. 项目组的度量原则

—— 尽最大努力报告准确而及时的数据；
—— 协助在管理中将项目数据聚焦于改善软件过程；
—— 不要使用软件度量夸耀自身的优秀，否则这将鼓励其他人使用其他数据展示其反面。

4. 通用原则

—— 软件度量本身不要成为一个战略；
—— 在软件过程改善的全局战略中整合软件度量，为此应该拥有或者开发一种这样的战略来联合软件度量计划；
—— 带着共同目标与课题从点滴做起；
—— 设计一种持续的软件度量过程，以使其：
? 与组织目标与宗旨相联系
? 包括严格的定义
? 持续实施；
—— 在广泛实施所设计的度量手段和过程之前进行测试；
—— 对软件度量手段和度量活动的效果进行度量和监控。
弗罗哈克的实用软件度量原则：十大原则
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中提出成功的过程度量原则如下。
1. 过程度量受商业目标驱动；
2. 过程度量手段源自软件过程；
3. 有效度量需要明确阐述的可操作性的定义；
4. 不同的人拥有不同的度量观点和需求；
5. 度量结果必须在产生结果的过程和环境中检验；
6. 过程度量应当跨越整个生命周期；
7. 保持的数据应当提供分析未来的实际基线；
8. 度量是进行客观沟通交流的基础；
9. 在项目内部和项目之间对数据进行总计和比较需要细心和规划；
10. 结构性的度量过程将强化数据的可靠性。

软件度量的要点：来自实战的教训
软件度量这一作业本身比较难以在实际的软件开发中顺利操作，也难以在软件开发改善中产生立竿见影的效果，甚至会让人觉得这是枯燥无味的无用功。这往往会形成妨碍实施软件度量的阻力，挫伤软件度量人员的积极性和热情。那么，如何有效地推动软件度量，就成为软件度量作业的重点课题。下面是软件度量作业的要点，可以作为推动软件度量作业的参考。
1. 从点滴开始。与其采用声势浩大的软件度量运动，还不如从点滴开始：让员工逐渐进入度量状态，避免因为大规模运动带来的不适和阻力。从点滴开始，从小规模的简单的度量项目开始，从能够吸引员工并能让其接纳的度量项目开始，保证软件度量能在避免受挫的情况下得以逐渐推进，同时尽可能提高软件度量的自动化程度。
2. 解释为什么。这是消除抵制情绪和消解阻力的重要环节，因为人们不会切实地践行那些他们没有真正理解和接纳的理念和措施。需让员工明白，使用度量将比没有任何度量要好；度量将在一定程度上增进对软件开发的理解、预测、评估、控制和改善；软件度量仅仅针对软件产品、项目和过程，而不针对个人；等等。
3. 根据项目实情加以具体实施。不同的项目拥有不同的产品、流程、环境、目标和顾客，顾客、软件开发人员、项目组甚至经营者对项目的需求也不同，必须聚焦于解决该项目在产品、流程等方面的问题，而不是直接套用以前曾经实施或者已经模式化的度量标准。
4. 共享数据。度量数据的共享这一行为本身具有四大好处：一则可以让员工感受到度量的切实性，即行动正在按照计划进展；二则可以为员工提供度量的反馈信息，以改进现状；三则可以通过比较，寻找最佳实践，实施标杆学习；四则可以通过数据共享增进信任，消除软件度量可能带来的误解。
5. 保持简单易懂。简单易懂这一点对于降低度量过程中的理解成本、沟通成本和实施成本都不可或缺。因为软件开发人员没有必要成为软件度量理论、统计方法以及度量技术的专家，他们仅仅需要知道软件度量与解决问题之间的关系，知道如何简单高效地实施度量。
6. 塑造度量文化。在软件开发中有意识地塑造一种重视记录、亲近数据、偏好图表、基于度量进行作业的习惯或者说文化，将判断、分析和决策立基于可预测性、可控制性、可改善性之上。
软件度量的陷阱：直面铜板的反面
就像铜板的正反两面，软件度量也具有正反两个方面的影响：正面效用在于通过度量获得定量化的可控过程，负面影响在于其过度滥用带来的危害，比如：
1. 软件开发的量化指标替代了开发目标。软件开发管理中定量化极为重要，这当然是指有目的的、毫无浪费的、明确的定量化。如果视软件度量为目的，那么软件度量就会陷入可悲的误区：纯粹的量化指标替代了目标，数据淹没了宗旨，任务迷糊了方向，软件度量成为软件开发过程的目标而不是手段，成为应付考核和评价的功利性工具。指标仅仅是个反光镜，而不是行进的指向标。如果不能理解软件度量在商务上的目标，那么就会出现这样的情况：收集了错误的数据，以及数据没有被正确使用。要想接近目标，双眼必须注视前方。
2. 软件开发的度量方法取代了度量理念。软件度量不仅仅包含着丰富多样的度量方法，更包含着博大精深的度量理念；不仅仅需要理解软件度量的方式方法，更要践行软件度量的理念。如果仅仅拘泥于软件度量的方式方法而忽略更为本质、更为精髓、更为深刻的理念，那么软件度量对于软件开发的意义就不再重要，因为这种情况下的软件度量虽然获得了看似完美的躯壳，却丢失了灵魂。
3. 软件开发的度量结果成为奖惩的根本依据。软件度量的结果如果成为考核和奖惩的根本依据，那么就偏离了软件度量的用途：软件度量只针对项目、产品和过程，用于对软件项目、产品和过程进行理解、分析、预测、评估和改善；软件度量从不针对个人，既不用于评估个人的能力，也不用于评估个人的绩效，更不用于作为个人奖惩的根据，这样才能保持数据的可靠性、客观性和准确性。如果软件度量针对个人，这将从根本上影响个人的态度和行为，并危害团队的绩效。永远不要让软件度量成为软件开发人员心理上的负担。
过程影响公司的首席咨询顾问卡尔·威格在其《软件度量的十大陷阱》一文中总结了软件度量应该避免的十大陷阱：
1. 缺乏管理承诺；
2. 度量得太多太早；
3. 度量得太少太晚；
4. 度量了错误的事项；
5. 度量定义不严密；
6. 度量用于评估个人；
7. 度量用于激励而非理解；
8. 仅仅收集但不使用数据；
9. 缺乏沟通和培训；
10. 曲解度量数据。
软件度量并非神话，从其诞生之日起就没有预言过任何神话。软件度量仅仅是增进软件理解、预测、评价、控制和改善的富有助益的路径。如果仅仅寄希望于以统计为基础的软件度量来获取软件开发的所谓“银弹”，就需要重温那句富有讽刺意味的名言：谎言有三种，即谎言、该死的谎言、统计数据。

1. 为什么一个软件公司需要基于CMM的软件工作过程？
建立及遵循基于CMM的软件工作过程可以为软件公司带来两个I: 保证（Insurance）和投资（Investment）。  
保证是指公司能够保质，保量并按期交付给客户令其满意的产品， 即为当前工作带来保证。投资是指在做当前的软件工作的同时，一个项目或整个公司所建立起来的各项工作过程（各类文档/资料），可以为将来的相关工作提供参考，甚至可以被直接采用。




2. 我认为有关CMM的工作是公司管理层需要做的，与软件工程师没有太大关系。
如今的软件项目趋向于大规模和高复杂度。一个项目一般需要涉及多个阶段来完成：项目提议，需求分析，项目计划，系统设计，编制程序，各类测试，产品交付以及维护支持。在某些阶段可能需要一个队伍的共同参与。一个软件工程师应该参与多个阶段并与其他项目相关人员密切合作，这些工作的具体方针和实践都可以得益于CMM。



3. 我们已经处于编程阶段，可是我们的客户还是不断更改/增加软件需求，我们应该怎么办？
这是软件开发项目中经常发生的情况。一个软件公司不可能要求它的客户具备CMM的知识或实践。但在这种情况发生时，项目负责人（Project Leader）或技术经理（Technical Manager）应该遵循CMM建议相关的工作过程，组织项目人员讨论及评审这些变化，如果影响到产品设计，编程，测试以及交付日期时，项目负责人或技术经理应该及时与客户沟通，向他们出示相关文档，协商解决方案。



4. 我们为项目所建立起的各类工作过程，是否适用于公司里的其它项目？我们是否需要借鉴或实施其它项目所建立起的各类工作过程？
一个项目建立起的各类工作过程（各类文档/资料）可以适用于其它项目。这要看公司的目标是CMM的哪个级别。CMM第2级要求各个项目建立并遵循适当的工作过程；CMM第3级要求整个公司建立适当的工作过程，各个项目可以根据实际情况在得到批准后剪裁或调整某些工作过程。



5. XSSC的公司标准软件过程（OSSP）与CMM之间的关系是什么？
这个问题其实是在问 ”XSSC的OSSP是如何具体体现CMM的？”。
CMM规范了在各个关键工作过程领域中应该进行的各种工作，但是并没有将这些工作系统地联系起来。在某些方面，CMM只列举出软件公司或项目应该具有的工作过程，文档或度量数据，但是并没有建议如何实际运作，如何建立文档，如何获取数据。 XSSC的OSSP根据公司的不同种类的软件项目（开发类项目，产品本地化类项目，和维护类项目），将CMM规范的各种工作按照实际发生的先后顺序贯穿于各类项目的整个生命周期中。同时，XSSC的OSSP也包括了XSSC在十多年的软件工作中累积和提炼出来的工作过程，文档样板，过程控制与数据收集的工具等内容，是XSSC达到CMM第３级的重要依据。




6. CMM第４级和第５级为什么比第２级和第３级涉及到的关键工作过程领域（KPA）来的少？
当一个公司向CMM高级别迈进时，所有低级别包括的KPA都要被考虑。另一方面，在进行CMM高级别的评审时，所有低级别的KPA都要被评审。因此，　CMM第2级有6个KPA，　CMM第3级有（6＋7＝13）个KPA，　CMM第4级有（13＋2＝15）个KPA，　CMM第5级有（15＋3＝18）个KPA。



7. 一个达到一定CMM水准或者已获得CMM级别的公司如何与CMM程度较低的公司进行项目交往或合作？
CMM水准较高的公司不能放弃自己的任何软件工作过程，也不能降低程度地实施公司的各项方针政策，而应该清楚地识别和定义与CMM水准较低的公司之间的工作接口，并建立相关协议。



8. 通过软件测试（Testing）可以保证软件产品质量，为什么还需要同行评审（Peer Review）？
一般来说， 软件测试有以下缺点：
只有等到软件编码完成后才能进行。
所耗费的成本是整个项目生命周期中最高的阶段。在此期间，软件工程人员等待测试结果，即使被分配其它工作，也不能全力投入；软件测试人员需要做大量重复性的工作。
所以软件测试阶段应该被尽量缩短，否则项目的整体表现将受消极影响。那么，怎样才能减少软件测试工作量呢？ 同行评审对此可以提供很大的帮助，可以及早地有效地从软件工作产品中消除错误，弥补缺陷，纠正误解和设防隐患，从而减少软件测试的工作量。



9. 遇到很主观一类的问题如何解决？ 如SQA人员应该怎样选择参加项目的那些评审？
遇到类似问题，相关人员应该将问题提交给公司的SEPG小组，由SEPG小组制订出相应的解决方案，经过检讨或评审后，将方案提升为公司的文档化规程，即使主观问题根据客观依据得到解决。



10. 小项目如何实施ＣＭＭ？
何谓小项目在学术界或工业界并没有明确的定义。一般来说，规模在3-5名人员、为期6个月以下的项目，是小项目。小项目不可避免地会剪裁一些CMM的过程。下面是一些小项目为达到CMM 3级必要的过程：
将客户需求文档化。
定义任务分解构架(WBS)，做出工作计划。
跟踪重要工作的完成情况或保证至少在3周内做一次进度跟踪检查。
采用灵活的SQA和同行评审过程，例如，配备兼职的SQA人员，只在项目开始和项目结束时进行评审，或者在一次评审中评审多个文档或代码。
建立系统配置管理系统。
建立负责改进项目软件过程的职责。

一、各关键过程域名称：
Level 1：Initial（第1级：初始级）
Level 2：Repeatable（第2级：可重复级）
RM        Requirements Management（需求管理）
SPP        Software Project Planning（软件项目计划）
SPTO        Software Project Tracking and Oversight（软件项目跟踪与监督）
SSM        Software Subcontract Management（软件子合同管理）
SQA        Software Quality Assurance（软件质量保证）
SCM        Software Configuration Management（软件配置管理）
Level 3：Defined（第3级：已定义级）
OPF        Organization Process Focus（组织过程焦点）
OPD         Organization Process Definition（组织过程定义）
TP        Training Program（培训大纲）
ISM        Integrated Software Management（集成软件管理）
SPE        Software Product Engineering（软件产品工程）
IC        Intergroup Coordination（组间协调）
PR        Peer Reviews（同行评审）
Level 4：Managed（第4级：已管理级）
QPM        Quantitative Process Management（定量过程管理）
SQM        Software Quality Management（软件质量管理）
Level 5：Optimizing（第5级：优化级）
DP        Defect Prevention（缺陷预防）
TCM        Technology Change Management（技术变更管理）
PCM        Process Change Management（过程变更管理）

二、其它常用缩略语：
CBA IPI        CMM-Based Appraisals for Internal Process Improvement（用于内部过程改进的基于CMM的评价）
CCB        Configuration Control Board（配置控制委员会）
CM        Configuration Management（配置管理）
CMM        Capability Maturity Model（能力成熟度模型）
CMU        Carnegie-Mellon University（卡耐基•梅隆大学）
COCOMO        COnstructive COst MOdel（构造性成本模型）
CR        Change Request（变更请求）
DoD        Department of Defense（[美国]国防部）
FP        Function Point（功能点）
IDEAL        Initiating，Diagnosing，Establishing，Acting，Leveraging（启动、诊断、建立、行动、推行）
ISO        International Standardization Organization（国际标准化组织）
KP        Key Practice（关键实践）
KPA        Key Process Area（关键过程域）
KSLOC Kilo Source Lines Of Code（千行源代码）
MSG        Management Steering Group（管理指导组）
PCB        Process Capability Baseline（软件能力基线）
PDB        Process Database（过程数据库）
PERT        Program Evaluation and Review Technique（计划评价与复审技术）
PM        Project Manager（项目经理）
QA        Quality Assurance（质量保证）
QC        Quality Control（质量控制）
ROI        Return On Investment（投资回报率）
SCCB        Software Configuration Control Board（软件配置控制委员会）
SCE        Software Capability Evaluation（软件能力评价）
SDP        Software Development Plan（软件开发计划）
SEI        Software Engineering Institute（软件工程研究所）
SEPG        Software Engineering Process Group（软件工程过程组）
SLOC        Source Lines Of Code（源代码行）
SOW        Statement Of Works（工作说明）
SPA        Software Process Assessment（软件过程评估）SPI        Software Process Improvement（软件过程改进）
SRS        Software Requirement Specification（软件需求说明）
TQM        Total Quality Management（全面质量管理）
TWG        Technical Work Group（技术工作组）
UT        Unit Test（单元测试）
WBS        Work Breakdown Structure（工作分解结构）

谢谢各位

谈谈QA是否应该学习行业知识
是否应该持续坚持研发工作或增强研发知识？
是否应该学习一些质量管理的理论知识、工具？

很多公司都有软、硬件研发的
我们谈QA，SQA比较多，HQA比较少
欢迎大家对hardwareQA的工作开展畅谈自己的想法、经验或困惑

范围：
详细设计过程审核
概要设计过程审核
测试设计过程审核
需求开发过程审核

不仅仅是对工作产品审核
而是对设计过程的活动审核
如何开展？请大家发表意见

新年伊始，领导给偶们小组布置了一个工作之余的任务，任务详情如下：
1、任务名称
质量保证理论研究

2、任务范围
负责QA组在CMMI以及其他非工程技术领域理论的研究；
负责组织和制定质量保证相关规范、制度等；
负责组织质量保证理论方面学习和培训；
负责制定非工程过程方面检查单并组织非工程过程方面专题审核

3、与QA具体工作的结合
a、非工程过程检查单整理和优化
b、CMMI评估表翻译

4、我自己增加的一项任务大头
对CMMI各PA的学习，任务目标是整理一整套的PA教材。理想情况是能杀青成书。

请各位也多给点建议或意见。