《(项目管理)微软项目-求生法则-09》由会员分享，可在线阅读，更多相关《(项目管理)微软项目-求生法则-09（25页珍藏版）》请在金锄头文库上搜索。
1、下载第 9 章质量保证软件品管( 质量管理) 的重要性绝不亚于软件测试，在一个高效的项目中应该包含测试、技术检查和项目规划，这些都是为了及早发现缺陷并修正它。9人们在谈到质量时，往往包含的不只一样东西。质量可以用来表示系统不会当机，可以表示软件是否达到使用者的期望，或者程序合用不合用的程度。质量可以表示对特定需求的吻合度，或是在开头对正确需求规格的实作程度。一个良好的定义是“软件可以满足在设计中明白交代出来的要求和没明确指出的需求” 。本章将解释如何保证这类型的质量。质量为何重要即使你的软件不必多么可靠，缺陷还是得受控制，因为这影响到开发速度、开发成本与其他项目特质。第 3章“求生概念”描述项
2、目的上下游效应：在下游找出错误并修正要比在上游高出5 0 2 0 0倍的代价。知道为何该重视质量了吧，不过伴随而来的还有其他冲击。人们有时会认为他们可以在目前的项目质量上取巧，到下个项目再来更正。在小型项目中（时间一两个月或更短的项目） ，这么做当然骗得过去。可是在时间较长的项目中，往往弄巧成拙。你不可能把所有不良效果通通延后到下个项目上；许多效果会直接影响到目前的项目。160微软项目 求生法则下载软件质量在推动事务的成本上也有着冲击。低质量的软件增加一般使用者支持负担。顶尖公司，如微软注意到这一点，所以向一般使用者的求助电话收费，以支付造成问题的软件带来的支持负担。开发低质量软件，根基一旦受
3、到侵蚀自然也会增加维护成本。你也许认为你的程序只会被使用 3 5年，可是一般程序实际上可以很长寿，需要前后十任的维护程序员来支持。由于程序5 0 % 8 0 %的生命期成本会在程序的初次发行之后出现，就经济角度来看，在第 1版的软件中就打下成功的基础总是比失败好多了。最后，你的工作中是否会出现低质量软件，完全掌握在你手中。我的强烈印象是顾客不会去管这类高低质量的软件是何时到他手中的，只会记得他们喜不喜欢用那个软件。快速地解决问题固然很好，但有些前辈提醒我们，当快速的结果是被遗忘时，敷衍了事的代价影响深远。161微软项目：求生法则 质量保证下载品管规划本书的一个主旨就是想要让一个软件项目生存下去
4、就得有求生技巧。其中包含了品管要求，它得做到下例几点：软件品管活动必须经过规划。软件品管活动的规划必须明文订定。软件品管活动必须在软件需求活动时期或更早就开始进行。进行软件品管工作的独立小组必须存在。依据项目规模，这“小组”也许只有一个人，也许有两名开发人员，交互替对方的项目进行品管工作。小组成员必须经过软件品管活动的训练。你不能光是指着一名没什么经验的程序员说， “你过来，你现在就去品管部门工作” 。必须有适当的经费提供给软件品管活动。品管规划的要素一个有效率的品管规划也许包含缺陷追踪、 单元测试、源代码追踪、技术检查、整合测试和系统测试。缺陷追踪在这些品管活动中进行。项目团队保留一份162
5、微软项目 求生法则下载详列每项已知缺陷及其源头、发现时间、解决时间、解决方式（修好了或还没修理）等等的追踪记录。缺陷追踪是项目追踪与控制关键的一环。完整的缺陷信息有助于决定项目上市的日期、质量以及开发程序的改进。单元测试是由撰写程序的人来进行非正式的源代码测试。 “单元”可以是一个副例程，一个模块，一个对象类别，甚至更大型的程序设计项目。单元测试通常非正式地进行，但却是在单元与源代码正本整合、交付独立的检查测试过程以前必须进行的工作。源代码追踪是在一个交谈式除错器中一行一行地追踪执行源代码。这项工作是由写程序的开发人员进行的。许多程序员发现这项活动在找寻程序写作缺陷上有着无比重大的意义，我个人
6、的经验也是如此。有趣的证据显示：开发人员在整合程序以前，若能够先在除错器中追踪执行程序状况的项目，比起不使用除错器的项目，容易整合得多。技术检查是由开发人员来检查别人完成的工作。这些检查被用来确认使用者接口雏形、需求规格、构架、设计与其他技术性工作成果的质量。新的源代码与源代码更动都应该被讨论到。技术检查一般由开发团队带领。品管人163微软项目：求生法则 质量保证下载员在检查过程中的角色，是确保检查过程中出现的缺陷，必须密切追踪并完成修改。整合测试是在新开发的程序代码与其他已经完成整合的程序代码合并时进行的。这种测试工作是由新程序代码的开发人员非正式地进行的。系统测试是指执行软件以找出缺陷。系
7、统测试由一个独立测试机构或品管小组进行。将这些品管活动合并在一起进行看来似乎负担较少，实际上刚好相反。多层次品管活动的要点在于尽可能及早找出缺陷，降低修正成本。缺陷追踪缺陷追踪是记录和追踪有关缺陷从发现到解决过程的工作。 缺陷从个别层次一个个的缺陷开始到统计层次，以开放缺陷数、缺陷解决率、修正缺陷平均需要时间等等数据来进行追踪。及早在项目中开始追踪缺陷，可及早了解消除错误的重要性，并在项目进行中提供软件缺陷数量的最精确信息。缺陷追踪应该在项目中及早开始，至少在需求规格定案、工作成果纳入变动管制后。当程序员在实作时期发现164微软项目 求生法则下载一项设计有缺陷和失误， 那缺陷和失误就开始受到追
8、踪了，因为设计方式早就定案了。如果同一位程序员在还没定案的新程序中发现程序写作错误， 那样的错误就不用被追踪。但是如果程序员在程序经过检查定案后才发现同样的缺失，那样的错误就该被追踪。缺陷报告应该纳入变动管制中。让所有缺陷和失误都公开成为软件质量的宝贵资料，让项目团队能将软件中剩余的缺陷和失误具体化。缺陷和失误数量的变动可用来追踪测试活动的进度。缺陷追踪活动听来也许相当费力，事实上有许多特定化的工具可以让这些工作轻轻松松地完成。表9-1列出了每项缺陷应该被追踪的信息。表9-1 缺陷报告中追踪的信息缺陷代号（一个数字或其他唯一的标识符）缺陷说明制造缺陷的步骤平台信息（微处理器类型、内存量、磁盘空
9、间、显示卡等等）缺陷的目前状态( 还没修好或修正好了)发现缺陷者发现缺陷日期165微软项目：求生法则 质量保证下载(续)严重性（14表示，或者以致命、严重、表面等等的字眼表示）缺陷产生阶段（需求、构架、设计、构建、缺陷测试项目等等）发现缺陷阶段（需求、构架、设计、构建等等）缺陷更正日期缺陷更正者更正缺陷所需代价（人员、小时）修正的工作成果或产品（需求叙述、设计流程、程序模块、使用说明、测试项目等等）解决方式（延后工程修正、延后工程检查、延后品管确认、修正、判定不当、无法重现等等）其他说明收集这些缺陷信息，让项目团队能够追踪与评估项目状态，以及做成对未来项目有用的图表与报告（我们在第16章“软件
10、发行”会有更多说明） 。技术检查由于可被利用在上游工作成果中找出缺陷并加以修正的功用，就控制成本与时间表而言技术检查至少与测试工作一样重要。 “技术检查”一般包括浏览、调查与程序阅166微软项目 求生法则下载读等几种检查。除了兼具有品管的功能外，这些检查也是新手与资深开发人员互相交流经验的机会。资深开发人员能够修正新开发人员程序中的问题，而新开发人员能够从阅读资深开发人员的程序中获得更多经验，也有机会让新开发人员向老的设计思想提出挑战。一般检查方式检查依循下列方式。通知与传递工工作成果的作者通知检查人员（如项目规划、需求、使用者接口雏形、设计、程序代码或测试项目）已经可以准备检查了。在正式设定
11、中，作者将给予检查会议主持人一些说明，让主持人决定检查工作成果和出席检查会议的人选。准备工检查人员检查工作成果，最好使用过去最常见的错误检查清单来辅助进行。检查会议应该在检查人员完成工作成果的检查后召开。检查会议工作者、主持人（如果有的话）跟检查人员聚会检视工作成果。检查报告工在会议后，作者或主持人应该记录检查会167微软项目：求生法则 质量保证下载议的统计结果，说明检查量、缺陷发现数与种类；检查会议进行时间、工作成果通过或没通过检查过程。后续工作工作者或其他人采取必要的更改，这些更改经过检查后，工作成果才被宣告为正式通过检查。成功使用检查方式的关键为了最佳结果，留意下列重点。1. 及早在项目
12、中开始检查在需求、构架、设计阶段建立的技术说明应该都被检查过。品管说明，如品管规划与测试项目应该由品管与技术人员的检查。检查工作应该在实作阶段持续进行，所有细节设计与源代码都应该经过检查。对工作成果的管理，包括项目日程与软件开发规划，也应该被检查过。2. 让技术检查着重在找出缺陷在技术检查时，焦点应该放在找出问题来。将会议时间用来建立与评估解决方案只会浪费大多数人的时间，这些最好另外处理。3. 让技术检查维持技术性如果检查失去焦点，就容易变成技术性的敲锣打鼓168微软项目 求生法则下载竞赛了。任何类型的权威人物出现在技术检查会议中都会变成焦点，因此管理阶层或顾客都不应该出席检查会议。为管理阶层
13、或顾客的利益进行检查也许相当适切，但是这些都不是技术检查所要讨论的重点，所以应该分开进行讨论。4. 记录下检查过的项目有哪些追踪设计与程序的检查进度也可变成另一项项目衡量方式。通过追踪每周检查的模块数，你可以了解有多少模块等待检查。如果项目检查的模块数比每周检查的平均模块数还多出许多，以便赶上期限，那些检查过程可能就会被匆匆略过；测试过程可能会在那些模块中找到超出平均数量的缺陷。5. 记录检查过程中发现的缺陷经过检查的工作成果会有一份检查报告。列出找到的缺陷，并提供一份修正和查验修正结果的时间表。6. 在检查进行中查验工作成果技术检查的一个常见弱点，就是项目没依照检查过程中发现的缺陷进行善后。
14、因此在技术检查中找到的缺陷应该一样纳入缺陷追踪系统中。直到如其他缺陷一样修好为止。169微软项目：求生法则 质量保证下载7. 对项目团队公布检查结果虽然检查会议应该只包含技术人员，但是检查结果应该公布出来（在项目团队中，非真的对外公布） ，好让其他项目成员也能利用这些结果，避免再犯。8. 在时程安排中加入检查和修正检查所需的时间如果项目主持人预期检查会议是在开发人员的工作时间之外进行， 检查会议就不能有效运作。 在成功的项目中，检查过程是开发人员正常工作的一部分，应该在时间表中安排时间。如果检查过程有效率，就会在规划、设计、测试项目或源代码中详细检查出问题来，时间表中应该列出修正这些问题所需的
15、时间。系统测试检查活动对于评估软件上游品管有着关键意义，系统测试则对评估软件下游品管有着关键意义。下列是成功进行软件系统测试的关键。系统测试应该由独立测试人员带领为求效率，软件须由开发人员以外的人来进行测试。170微软项目 求生法则下载开发人员也许可以在自己的程序中找出相当数量的缺陷，可是要彻底找出缺陷，就必须将心态从让软件可以运作改成让软件无法运作来进行，而很少有开发人员能够在同个项目中同时有两种心态的。测试规划应该在需求已知时尽快开始有效率的系统测试取决于有效率的规划。测试项目必须如源代码般被设计、检查和实作。如果你不要让测试变成软件发行的关键障碍，就应该让测试规划尽早开始最好在需求了解后
16、就开始。在第一阶段开始系统测试在阶段性完成方式中，可执行软件会在第一阶段中出现，而系统测试那时就应该开始进行了。系统测试应该以需求追踪表格准确涵盖完整的需求范围软件系统测试应该规划成能够涵盖软件全部功能。这一般是经由“需求追踪”的程序加以确定的。在需求追踪程序中，会建立一个大表格，表格各行标上测试项目，各列则标上需求项目。在行列交会处标上“ 1”表示行的测171微软项目：求生法则 质量保证下载试项目有助查验列的需求完成。没标上“ l”的行则表示列的测试项目查验不了任何需求项目，是可以被删除的。一列之中没有“1”的标记的话，则表示该需求项目没有任何测试可以查验得了。各行各列都应该至少有一个“l”才行。建立需求追踪表格是一项单调的工作，却是确保软件的整个范围都被测试过的最佳方式。提供系统测试适当的资源适当测试计算机软件所需的资源，会依据软件种类而异。对高质量商用软件而言，经验法则是每个开发人员分配一名测试者， 这是微软公司与其他顶尖软件公司的比率。这个数量的测试人员是必须的，因为大部分测试套件必须是自动化的，使品管人员能够在软件更改时经常将软件功能从头到尾
