软件测试管理案例分析

软件测试管理案例分析（13篇）

1.软件测试管理案例分析 篇一

案例分析任务：

1、me&city和ZARA在进行供应链设计时采用的什么策略？请简述这种策略。（20）

2、请以ZARA供应链为例，谈谈其供应链战略是如何与公司业务竞争战略相适应的？（25）

3、供应链设计的原则有哪些？你能从提供的me&city和ZARA的供应链模式案例中，发掘出他们各自是如何体现这些原则的？（能发现多少是多少，哪怕发现一条，只要说透了就有及格的可能）（25）

4、请仔细阅读“

二、采购”的案例内容，分析延迟策略在me&city和ZARA各自供应链模式中的体现，延迟的类别是什么？带来的好处是什么？如果能在案例其他地方发掘出延迟策略的应用并说明就更好。（25+5）

2.软件测试管理案例分析 篇二

在软件大规模开发的背景下, 软件测试管理工作也面临较大的工作量与技术难题。据美国质量保证研究所相关数据研究发现, 相比编码前的缺陷修改, 软件编码完成后修改其中缺陷所涉及的成本将提高10倍左右, 若产品处于交付状态并需进行修改将为交付前缺陷修改成本10倍左右, 充分说明以过程为基础的软件测试管理的重要性。这就要求测试工作管理不断加强, 引用先进的技术手段, 保证软件质量的提高。

2 软件测试管理的基本概述

2.1 软件测试管理的内容与目标

软件测试管理的实质在于跟踪与管理各测试阶段中的相关计划与流程, 并将测试管理的相关结果向系统研发人员与管理人员进行反馈, 同时要求根据软件系统中的缺陷生成相应的报告。测试管理的内容重要包括对过程的测试、对人员的测试以及对工作产品的测试。其中在管理测试过程方面主要考量软件的应用情况与测试是否具备有效性, 在此基础上做好后期测试过程的改进。在管理测试人员方面, 需对软件人员的工作状况等相关数据进行分析与收集, 判断是否与预期测试目标相吻合。而在管理工作产品测试方面主要对测试软件产品进行分析与测量并从中获取能够为决策提供参考的数据信息。因此, 软件测试管理的目标实质是控制与管理整个测试流程, 以此保证软件产品的质量[1]。

2.2 软件测试管理主要概念分析

软件测试过程中涉及的概念主要包括测试用例、缺陷以及协同等方面。其中的测试用例可细化为相关的数据与所得出的结果, 用于判断测试结果是否与测试计划目标相吻合, 确定软件应用程序中是否存在影响正常运行的问题。而缺陷的概念, 很多研发人员往往以Bug代指软件开发过程中存在的问题, 从狭义角度分析指为由程序编写过程产生的问题, 而在广义上认为软件应用使用过程中出现的错误。而对协同的概念, 根据以往学者将其应用于计算机中的定义为对空间分布与时间分离支持的同时, 使软件各部分共同合作[2]。

3 以P-TMS为例的软件测试管理系统分析

P-TMS软件测试管理系统中的相关角色主要包括软件项目负责人、系统分析人员、测试设计人员、软件开发人员以及用户等内容。利用这种工作模型的优势主要在于可在设计工作前设计测试用例, 有利于及时发现软件设计中存在的问题等。具体测试过程主要表现在以下几方面。

3.1 从需求跟踪管理角度出发

进行需求跟踪管理过程中所分析的主要为用户原始需求, 其中的测试用例集中所包含的用例具有一定的关联性, 且对应测试用例往往存在一定的缺陷问题。但值得注意的是许多需求项无需利用测试用例, 不必对其跟踪管理。另外, 在需求跟踪过程中, 由于用户对软件项目的需求不同阶段会存在一定的变化, 要求构建需求变更流程, 具体过程包括对需求变更的申请, 在此基础上制定变更的决策, 最后在落实阶段需对测试用例重新设计并修改测试用例库[3]。

3.2 从测试用例管理角度出发

软件测试工作的成败很大程度上受测试用例管理的影响。具体管理过程中首先需对其组织结构进行分析, 保证其中的上下级系统、子系统、功能模块以及测试用例集等设置合理, 通常各功能模块中往往包含许多功能项, 而功能项中集合部分测试用例集, 各测试用例集又存在许多测试用例。其次, 由于被测软件项目存在功能相似或同样的情况, 具有同样的测试要求。对此可引用复用技术, 测试功能项或需求项相同的软件过程中便可在测试用例库中寻找对应的测试用例完成测试过程。

3.3 从缺陷管理角度出发

软件生命周期内无论研发阶段或使用阶段都存在一定的缺陷问题, 要求做好缺陷跟踪管理工作。软件项目测试管理中的相关人员都可对存在Bug向测试主管提交, 而测试人员便需做好缺陷状态以及解决缺陷问题的相关数据统计, 以使项目进展情况可被及时掌握。同时, 应做好项目缺陷的分类, 如程序问题、数据处理中的错误、编码规范性问题、接口错误、内存管理、系统性能等方面, 在此基础上针对每种类型缺陷提出相应的解决方案并存档与缺陷方案库中, 再次出现该类缺陷时便可从方案库中找到对应解决方法[4]。

3.4 从软件测试度量角度出发

软件测试度量主要指量化分析整个软件测试过程, 其通过度量缺陷以及测试执行状态, 使缺陷位置得以确定并预测软件开发或使用阶段存在的缺陷, 以此为依据制定相应的测试计划, 很大程度上保证软件的可靠性。其中对缺陷的度量需构建缺陷的相关报告以及趋势图, 而度量执行状态的相关指标主要包括需求测试、功能测试以及测试用例等方面[5]。

4 关键技术在软件测试管理中的应用

根据前文中对P-TMS软件测试管理系统的分析, 在实际设计测试管理系统过程中需重点做好主要功能模块的设计工作。其中在设计主要功能模块过程中要求将模块覆盖整个测试管理过程中, 具体包括项目规模管理模块、需求项管理模块、测试用例模块、实施计划模块、测试用例模块、管理缺陷的模块、生成报表与系统整体管理模块等。而在设计数据库过程中需根据相应的模块内容, 保证各模块间的相关数据融于数据库系统中。这种设计测试款力模块的关键技术主要体现在以下几方面。

4.1 状态流转技术的应用

状态流转技术的提出主要针对软件中存在的缺陷问题, 设计过程中考虑到软件开发与应用的角色以及具体职责内容。同时, 在实际处理缺陷中除进行状态转换中的相关信息外, 其他许多流动信息都具有明显的缺陷属性, 对此需保证各处理环节的缺陷处理都需建立在前一环节处理完成的基础上。

4.2 前置测试的关键技术应用

前文在设计构建测试管理系统过程中应用的主要为前置测试技术, 其在应用过程中主要考虑到软件在开发初期便通过测试管理发现其中存在的问题, 避免开发中缺陷较多, 有利于软件开发质量的提高, 也便于后期维护工作。而除应用前置测试技术外, 实际构建测试管理系统中也应用测试驱动开发相关理念, 为各测试管理环节提供保障[6]。

4.3 测试信息共享的关键技术应用

软件测试管理过程中的测试信息共享主要体现在测试用例信息以及缺陷信息的共享。在测试用例信息方面可充分发挥测试用例库的作用, 要求设计人员将不同类型的测试用例存储于测试用例库中。同时, 在设计测试用例库中也可引入复用技术, 对需求项或功能相同的测试用例采取直接复用的方式。另外, 在缺陷信息共享方面, 可将不同类型的缺陷以及相应的分析解决方法存于缺陷方案库中。使软件中出现类似缺陷时, 可在缺陷方案库中寻找对应的解决方案。

4.4 度量与评估的测试关键技术应用

为使测试过程与效果得到正确评估, 可充分发挥度量与评估及时的应用。如前文所述可从三方面完成测试评估, 包括度量缺陷、度量测试执行情况以及测试的覆盖情况等。但需注意在度量测试覆盖情况以及执行情况中应引入相应的覆盖率指标包括测试用例、需求项、功能项以及测试执行等覆盖率。而在度量缺陷中需做好缺陷统计以及缺陷趋势图设计等工作。通过这种定量评估的技术, 能够使软件设计与开发决策提供重要的参考内容[7]。

5 结语

软件质量的保证需充分发挥软件测试管理的作用。通过文中基于过程的软件测试管理系统设计分析, 要求在实际构建过程中注重应用状态流转技术、前置测试技术、信息共享以及度量测试过程与效果的相关技术, 并保证测试管理系统中个模块如项目管理模块、测试的计划以及管理缺陷等模块都可发挥应有的效果, 这样才可有效监视测试管理的全过程, 为软件质量提供坚实的保障。

参考文献

[1]王立娟.基于过程的软件测试管理中关键技术的分析[D].大连:大连海事大学, 2010.

[2]王立娟.基于过程的软件测试管理系统的研究与应用[J].电脑知识与技术, 2010, 22 (2) :696-698.

[3]杨帆.基于系统测试的测试管理工具的开发及其应用研究[D].上海:同济大学, 2010.

[4]罗霄.基于过程的软件测试管理技术及支持工具的研究[D].西安:西北大学, 2010.

[5]许文瑛.协同软件测试管理模型及其平台架构的研究与应用[D].北京:北京工业大学, 2012.

[6]蔡立志.基于形式化的软件测试复用若干关键技术的研究[D].上海:上海大学, 2010.

3.软件测试管理案例分析 篇三

关键词：软件外包；项目管理；风险；措施

中图分类号：F272.92 文献标识码：A文章编号：1007-9599 (2011) 15-0000-02

Software Development Outsourcing Project Management Case Analysis and Study

Xu Fang

(Zhejiang Institute of Mechanical&Electrical Engineering,Hangzhou310053,China)

Abstract:Outsourcing is a very big market,currently in the country,many software companies in the software outsourcing industry,or their own part of the business awarded to the outsourcer,outsourcing software projects outsourcing software project management with the development in recent years,more and more attention,with the company's content management project and there are both associated with differences in the actual article on the outsourcing of specific business case risk analysis,the corresponding solutions,and summarizes the project implementation problems and improve opinion,for the outsourcing project management software companies to provide a reference.

Keywords:Software outsourcing;Project management;Risk;Measures

一、引言

软件外包就是企业为了专注核心竞争力业务和降低软件项目成本，将软件项目中的全部或部分工作发包给提供外包服务的企业完成的软件需求活动。作为品牌和实力正处于培育发展阶段的软件公司，在市场拓展过程中为了克服积累不够等弱点，把自己不擅长或非发展方向的项目进行外包是非常普遍的现象。近年来软件外包在我国发展势头迅猛，因此软件外包业孕育着广阔的市场前景。而搞好外包项目管理是关键环节。软件项目外包本质来说，是软件开发过程从公司内部部分或全部延伸到公司外部的管理规范与管理技术。与内部实施相比，管理难度有过之而无不及。本文结合公司外包项目实际情况，分析了软件项目外包管理中存在的风险和应对措施，为其他软件项目的外包管理工作提供一定的借鉴。

二、项目背景概述

某公司为中小型软件开发企业，有比较稳定的开发团队，测试团队刚刚组建，力量比较薄弱。需要开发的项目要求高、开发周期短，具有较大的压力。本次系统的开发，公司选择了将测试工作外包给某软件外包公司完成。

目前软件企业测试团队的建设中，不可避免地会遇到许多棘手的问题，诸如：（1）招募过程中无法评估相关人员的测试水准和能力；（2）招募后没有为测试人员提供良好的测试技术培训体系；（3）无法正确快速地组建测试团队以融合到研发过程中；（4）无法系统地使测试人员最快限度地掌握最新测试技术用以研发需求；（5）如果各个项目的进度不是连续性的，测试人员的工作有可能会出现阶段性停滞而增大了成本等等。

通过分析公司的实际情况，选择将测试工作外包主要是基于以下一些原因：（1）公司测试人员短缺。该系统实施时，其它多个项目处于测试阶段，如果为此项目招聘人员，考虑招聘时间和培训时间，可能难以保障项目进度；（2）公司缺少自动化的测试工具，在项目启动时，尚无相关购买决定；（3）表面上看，把测试工作发包给同一城市的公司，将导致成本上升，但如果选择的是一个比较专业的公司，考虑到测试工作效率问题，最终成本实际会降低。

因此在项目启动时，公司项目组很快就做出了将测试工作外包的决定。通过外包给企业和项目带来的好处如下：（1）人员外包成本低于自身招募的综合成本；（2）来自专业测试公司的人员将比自身招募人员获得更多的来自测试公司的技术支持；（3）专业测试公司能够为企业带来更多基于项目业务需求的技术支持。

在选择外包公司时，公司将同城市的某外包公司列为第一候选人并开始与对方进行洽谈。该公司在当地有较高知名度，并且公司与其母公司有较多往来，将其列为首选对象是一种比较自然的选择。

三、项目外包风险分析及应对措施

软件外包具有很多优势，如可以降低或保持软件开发成本和管理成本，使企业专注于核心能力和核心竞争力等。但由于发包方和承包方之间存在不可避免的地域、文化、法律、价值观及管理方法等方面的差异，使得软件外包在其生命周期全过程中存在各种风险。在外包项目所面临的诸多挑战和风险当中，有些风险与企业自己开发项目面临的风险相似，但更多会面临不一样的、比自己开发多得多的风险。除非这些风险能够得到更好的控制和管理，否则，可能会遭遇比企业自己開发项目更多的失败的可能性[1]。

（一）风险分析

软件外包工作由于天然存在的地理、文化差别，其失败的风险几率较大，所以从事外包的管理人员在项目启动之前尤其要对项目中可能存在的风险因素有一个比较全面地识别和分析。比较好的一种风险识别方法是结构化的头脑风暴法，通过集思广益找出所有可能影响到项目进度、成本、质量的因素。一个非常重要的风险因素的来源是项目计划的假设和约束，一旦项目成功所作的假设不能达到，这些就会成为未来影响项目正常进展的问题。

风险贯穿于软件外包的全过程，具体表现形式多种多样。一般情况下主要包括以下几方面：（1）成本容易超出客户预算；（2）内部的信息系统专业能力流失；（3）失去对信息系统的控制；（4）外包开发商倒闭；（5）使用的产品种类受限制；（6）难以对开发方的职能与安排进行控制；（7）形成对开发商的依赖；（8）存在损失战略信息的风险；（9）外包开发商的系统落后；（10）外包商的文化与人员的适应性差。

从事软件项目管理的项目经理可能都知道这么一个事实，一个项目经理85%的时间都用在各方面的沟通交流上。很多项目出现问题都不是在技术上碰到难题，而更多的是由于沟通不畅引发的后果。这是公司首次将测试工作外包给其它公司。作为项目经理，通过分析有以下潜在问题可能会导致项目进行不顺利甚至失败：（1）异地交流问题：由于目前公司场地座位紧张，对方测试组需要在自己公司场地工作，由于面对面的沟通比较少，可能导致沟通问题；（2）开发流程差异：双方开发、测试团队之间需要频繁交流，这些交流很大程度上依赖于项目文档以及项目管理方法，双方所使用的项目文档风格若存在较大不一致，将导致沟通问题；（3）文化差异：双方人员存在大的工作文化、工作习惯差异，使得开发团队和测试团队之间难以沟通；（4）绩效问题：对于测试工作，还难以建立一个定量的指标去衡量工作效率，如果对方测试团队中部分人员效率低下，公司可能难以及时发现，从而影响质量；（5）知识产权：对方缺少完善的知识产权保护机制；（6）人员流失：在项目执行过程中，对方发生项目组人员流失，可能影响项目进程；（7）冲突化解：在一个公司、项目组内，所发生的争执更加容易化解，但涉及到两家公司时，容易更多地寻找对方的失误，使得争执、冲突扩大。

另外还有一些常见的外包风险，例如对工作规模估算过低，由于采取了单位计价方式付费，因此，即使是发生由于公司开发质量过低、需求更改过于频繁导致递交测试版本过多等原因引起测试工作量增加，对于对方而言，并不存在问题，因为这会使得对方收入增加，但会影响团队积极性，对公司方而言，需要从质量保障、变更控制、成本管理角度解决问题，在外包管理上，规模增加导致的管理问题有限。

一旦识别出尽可能多的风险因素之后，需要对这些因素进行评估，并不是所有的风险都需要去规避，所以必须分析哪些风险会对项目产生重大影响，哪些风险发生的可能性非常高。根据这些分析结果排出项目中优先级比较高的风险因素，然后针对这些风险分别找出规避的措施以及风险发生时的应对举措。

（二）风险控制

对于每个风险都能找到一定的规避和减少损失的措施，而控制外包风险的一般方式包括：（1）建立各方可度量和实施的共享目标和回报；（2）引入多个供应商作为激励机制；（3）建立一个交叉职能的合同管理团队；（4）建立绩效矩阵；（5）执行定期竞争性评估和基准检查；（6）实施短期合同；（7）在合同中明确数据的所有权。

针对上述项目，在确定将测试工作外包，并且选择了候选公司之后，作为项目经理需要完成下列工作：（1）确认该公司是否确实有实力完成该系统测试工作；（2）了解对方工作文化和工作习惯，确认双方团队可以很好沟通、协同；了解对方工作流程，编写工作说明书，明确双方职责、递交工作件（包含内容、质量要求和时间要求）、协同规则；（3）建立外包项目管理计划。

为了明确问题（1），作为发包方，公司的项目管理人员、研发人员和测试部门几名工程师走访了该公司，请该公司介绍采用类似技术的项目案例，对方介绍了为国外客户完成类似测试工作的案例，通过这些案例，我们可以确认该公司具有相应技术能力实施测试工作。

在计费方式上，可以选择固定计划方式、单位计价方式或者混合的方式。由于测试工作量存在不确定因素，该项目确定采用单位计价方式付费：由对方公司在项目不同阶段提供我方所要求数量的测试工程师，发包方按照每月工作时间付费。接下去，对方公司提供一份候选人名单，在工作开始前，发包方需要对这些候选人进行面试，确保对方承接此测试项目人员具有对应能力。

在列出了前面所提的7大問题之后，作为项目经理组织了一个座谈会去确认这些问题存在的程度。这个座谈会由双方分别派出一个包含开发、测试团队的完整项目组参加，向对方展示典型的项目执行过程案例，从而使双方人员都建立对对方项目管理的了解。另外，也需要与对方一些管理人员进行交谈。

通过一系列的调查、分析，在上述7个问题中，后5个问题影响会比较小：（1）文化差异：双方在同一个城市，但非同一家公司。因此，双方将存在文化差异，但这个差异应该有限。（2）绩效问题：对方属于专业型外包公司，长期从事对欧美外包业务，已经建立起了很好的内部绩效管理体系，在了解该体系之后，可以确认对方可以管理好绩效问题。（3）知识产权：对方有一套完整的客户知识产权保护体系。实际上，对于外包公司来说，保护客户知识产权也是他们的“生命线”。（4）人员流失：对方年均人员流失率低于本市平均水平，并且有大量合格人员可以在流失发生时补充到该项目。在对对方测试组进行领域知识、系统需求培训时，要求对方按照增加15%人员的比例参加培训，这样，万一人员流失，可以从后备人员中挑选人员进入项目组，他们的适应时间会较短。（5）冲突化解：由于公司业务特点，对方有较好的内部管理、职员教育体系，问题出在发包方的概率更大。这可以从发包方日常管理中解决问题。

前面两个问题会有相对大一些的影响。下面是采取的一些解决方案：（1）异地交流问题：对方长期从事对欧美外包业务，其员工具备丰富的远程协同工作经验，而发包方员工该方面经验比较缺乏。表面上看，问题会更可能出在发包方，但分析对方项目后发现，由于对方一直从事欧美金融领域外包业务，项目文档极其详细，这超过了发包方项目文档详细程度。简单地由发包方提高项目文档详细程度并不可取。采取了这样一些解决方案：双方人员所使用的PC均安装摄像头，可以视频交流；使用远程桌面；对于我们所使用的项目文档中的递交报告进行修改，要求更加详细地给出所递交版本的详细变更信息和最期望先被测试的功能点。（2）流程差异：由于不同公司对于项目开发、质量保障会有自己的流程。在这个问题上，采取的做法是：以发包方现有流程为基准，安排对方测试人员熟悉该流程。另外，发包方也进行一些改进：在以往项目流程中作为发包方的递交报告不够细，现在需要加以改进。

（三）存在问题及改进

上述问题，通过处理在项目进行时都没有出现大的问题。但在异地交流问题上，还是碰到了一些麻烦。使用远程桌面，确实可以帮助测试人员与开发人员建立对问题的共同理解，但效率还是远低于面对面的交流。当再次执行类似外包工作时，建议可以考虑进行每周两次的、相对固定时间的开发、测试碰头会，而在这个项目中是每周一次。在开发流程上，以发包方的流程定义为蓝本，同对方讨论后进行局部修改。这样做法，减少了发包方的工作量，但代价是对方需要学习的内容变多。对方的基于内部网的过程管理系统更多、更完善，在今后项目实施时，如果项目内容、服务供应商情况类似，一个改进的方法是：仍旧是以发包方流程为基础，但会参考、使用对方内部网上自行开发的小工具。

四、结束语

从实际的外包项目管理经验中可以看出，对于类似外包工作，工作的重点，即最容易出问题的地方是如何保持好两个或者更多人组成的团队沟通代价最小化。发包方和外包方需要根据实际情况建立良好合作模式。此外，外包项目的管理比企业内部开发项目的管理更复杂，担负更大的风险，需要更紧密的进度和质量监控。外包项目除了需要部分技术人员和用户群体参与外，更增加了一组外包商的资源，可以考虑充分运用。最后，项目经理需要做出一个详细的、完整的项目计划，并认真分析存在的风险和应对措施，以确保外包项目的顺利实施。

参考文献：

[1]王梅源.软件外包项目全过程风险管理[M].武汉:华中科技大学出版社,2009

4.任我行客户关系管理软件分析 篇四

一、软件简介

任我行CRM，是集CRM、OA、OM、HR、KM一体化的集成软件系统CRM——客户关系管理OA——办公自动化 OM——目标管理 HR——人力资源 KM——知识管理通过建立组织运营管理铁三角（企业文化-知识复制-目标行动），一切围绕以客户为中心的全方位、透明化的业务管理（市场-销售-生产-服务），打造企业组织运营的高效协同管理平台。

二、功能介绍

任我行CRM包含了4大功能及应用：

1、业务管理标准化：客户管理-销售管理-服务管理-流程管理 ——打造透明化、全方位的业务管控平台加速客户成交周期客户关怀提升客户满意度精准营销工具邮件群发和短信群发，让企业不缺客户建立流水线业务流程控制，让事情卡在哪里不做都不行建立完整的客户中央数据库，离职不用交接。

2、工作模式标准化：目标管理打造一切围绕目标的协同执行系统，让执行过程透明化，100%执行到位。让员工知道“做什么－怎么做－做到什么程度” 让主管知道“管什么－怎么管－管到什么程度”。

3、知识体系标准化：人才复制系统-管理复制系统建立人才培训复制系统，相当于24小时开放的图书馆，让新人提速3倍，老员工快速成长建立像麦当劳一样的管理复制系统，相当于管理的孵化器，人在有改善、人走无影响。

4、文化建设标准化：企业文化网上输出和训练平台“笔杆子里面出政权”，建立企业文化训练平台，让员工天天被训练给一把手提供企业价值观传播的平台，让一把手声音无处不在 本着“复杂问题简单化、简单问题流程化、流程问题标准化、标准问题信息化”的思路，帮助企业实施规范化管理，实现“继管清楚帐后的第二次运营管理革命”。让企业高效协同、自动运营，让领导人轻松解脱，随时随地借助手机、平台电脑等上网工具掌控公司、随时随地处理各种审批，《每周只到公司一天》，从而实现真正的“局外管理”，让标准化建设和IT工具成为企业的战略资产。

三、软件的流程

企业成功实施CRM五个步骤：

第一步:理念导入

理念导入主要包括组建实施小组、确定人员和时间、项目动员和CRM理念培训。其中CRM的理念培训是实施中的重要价值点。“以客户为中心”的管理方式，将客户而非产品放在企业核心竞争力的位置上，企业要能够真正应用好CRM系统，必须首先从理念上了解、接受和认识这一点。

第二步：业务梳理

业务梳理是系统实施的重要步骤和控制实施周期的关键点。通过流程分析，CRM的咨询顾问可以了解企业现有的经营状况及工作方式，提炼出市场、销售、服务中各环节的关键点控制点，暴露出隐藏的问题。同时，咨询顾问可充分发挥“第三方”的优势，提出个性化的实施建议，并对实施中可能出现的阻力做充分准备，是进行下一个步骤“方案设计”的基础。

第三步：流程固化

流程固化的重点是在调整和优化原有工作流程的基础上，建立基于的CRM系统、规范的、科学的、以客户为中心的企业运营流程。在方案设计过程中，CRM咨询顾问将运用在相关行业的成功实施经验，根据在业务梳理过程中总结有关信息，重新进行流程规划调整。

第四步：系统部署

系统部署主要完成正式启用系统的数据准备工作。在系统部署过程中，咨询顾问将根据方案设计中规定的企业运营流程、工作传递关系、企业组织结构以及企业经营产品的特点等将基础数据录入或导入到系统，指导企业建立协调统一的信息标准(或参照ISO标准)。系统部署由咨询顾问和企业内部的CRM项目负责人共同完成，确保知识传递。

第五步：应用培训

在应用培训阶段，CRM认证讲师根据《实施方案》，结合应用流程对企业工作人员提供培训。通过培训，企业员工能够很快熟悉系统，了解自身工作在系统中的角色及如何利用系统提高工作效率，使系统得以尽快投入到实际工作中，解决现有的问题，加强工作协调。

四、主要客户分布及特点

任我行CRM主要客户分析

9%

五、软件的不足

1、技术方面：

首先，CRM是IT软件服务系统一部分的，这一点毋庸置疑，但是，我想假如没有好的硬件的支撑的话，一个再好的CRM的软件，也不会有好多效果，一个年久失修的服务器，一个不给力的网络服务系统，给CRM实施带来很大的困难，这说明CRM是依赖性比较强的软件。

其次，数据对于任何的IT服务都是至关重要的一个因素，因此一个企业在数据质量的高低上，决定能否顺利的上一些好的系统，CRM也不例外，在依靠人力输入客户资料以及有关销售的信息时，难免会出现错误，可是到目前为止，没有任何一家的CRM系统中可以自动的修复更正数据这也是CRM不完美很重要的一方面，其实这跟第一点提到的，提高企业人员的素质仍旧是关键。

2、管理方面：

第一，企业内CRM应用，应该是一个CRM program(客户关系管理计划)，而不是一个简单的CRM项目，应该是一组CRM项目的集合，并且需要长期在企业的各个层中灌输“以客户为中心”的管理思想。最终达到了解顾客，细分顾客，为不同顾客提供客户化的服务，通过顾客需求满足的最大化，以实现组织收益的最大化。

第二，公司应用CRM的目的不纯。许多公司利用CRM来猎取客户，而不是恳切地争取客户。不同行业、同行业的不同公司，以及同一公司的不同客户对客户关系都有着不同的要求，而管理者们在实施CRM计划时往往忽略这些，结果惹烦了那些潜在的客户。因此企业应该用积极的客户策略来应用CRM。

第三，多数企业是推出CRM计划在前，调整组织结构在后。他们通常会忽视在投资CRM技术之前先对内部结构和制度进行改革的必要性，而这就像不把墙壁磨光就试图重新粉刷一样，效果注定比原来更糟。

综上，一家公司的成败绝不是因为有了CRM系统就可以决定的，我们不能否认CRM的巨大作用，但CRM应用必须很好的服务于企业愿景，并长期贯穿于企业的营销活动之中。为达成这一目标需要企业全体人员积极配合，共同探索和完善CRM系统。

六、意见和建议

1、意见：

任我行-协同CRM的管理宗旨是每周只道公司一天，那公司的员工一定很少接触，通过电脑或电话不足以深入了解公司员工，由于缺乏沟通和了解可能在一定程度上阻碍公司的发展。

任我行-协同CRM管理软件让我们更依赖高科技设备，而随着科技的发展进入他人的电脑窃取资料也变得容易，常使用该软件也许会使公司一些资料流失。

2、建议：

（1）和商业智能集成鉴于当前经济形势，CRM领域出现了专业化的趋势，所以企业除了通过削减成本来应对经济衰退外，另一种常见的对策是更加注重销售效果和企业员工的执行力。企业应该重视销售信息的分析、细分、规划和最佳实践工作流程，改善成功率。

（2）后台式管理，保证数据安全

客户数据对于一个企业来说的重要性，是每个做企业的老板们都知道的，如果这些数据不能保证在自己的企业内部，后果和担心是每个企业家们都想到的，所以拥有一套CRM系统，同时自助管理这套系统的所有数据，并保证数据安全是每个有一定影响力或者需要行业同不断扩张的企业想做到的，而这一点，有技术支持到每一个企业用户。帮助企业更好更安全的实施CRM系统。

（3）CRM成为一种服务

软件即服务已经成为一种新的趋势，而其中最为成功的就是CRM。目前，大多数企业开始意识到要持续发展，就必须有自己可控的CRM系统，一次付款买入一套完全属于自己的系统，并厂商每半年免费为用户升级。

（4）移动CRM市场启动

移动CRM（客户关系管理）是一种利用现代移动终端技术、移动通讯技术、计算机技术等现代科技实现在移动中也能过完成通常要在办公室里才能过完成的客户关系管理任务。移动CRM系统具有传统CRM系统无法比拟的优越性。移动CRM 系统使业务软摆脱时间和场所局限，随时进行随地与公司业务平台沟通，有效提高管理效率，推动企业效益增长。

5.虚拟化波及CRM

虚拟化CRM技术目前运用的厂商并不多，有待大家的期待的研究，希望任我行企业能研究出来。

5.软件测试管理案例分析 篇五

第一题、单项选择题（每题1分，5道题共5分）

1、从行使职权的业务性质来划分，可分为一般权限的教育行政机构和专门权限的教育行政机构。教育行政体制是国家——A—中的重要组成部分。

A、行政体制 B、管理机构

C、组织系统 D、政权体制

2、教育行政上的—B—的缺陷是：容易使教育行政缺乏弹性，难于因地制宜地发展教育，也常束缚下级机关办教育的积极性、主动性和创造性。

A、分权制 B、集权制

C、合议制 D、首长制

3、合议制或者—D—，就是指政府组织法定的最高行政决策权力和责任由集体承担的制度。换言之，就是说一个集团中凡重大事项需经集体协商，才能做出决定的制度。

A、首长制 B、集权制

C、分权制 D、委员会制

4、世界各国社会政治制度、国家体制及文化传统等方面的差异是构成—A——形式不同的重要因素。

A、教育行政体制 B、教育管理机构

C、教育组织机构 D、教育教学机构

5、法国、美国是采用中央集权与地方分权制的代表，但是，两国—B——也并不是铁板一块。

A、教育组织 B、教育行政

C、教育管理 D、教育机构

第二题、多项选择题（每题2分，5道题共10分）

1、在教育上实行中央集权制的典型代表是法国。法国从教育事业是国家事业的观念出发，建立了代表国家权力的中央教育部，统一领导和监督全国的教育事业。其权力范围包括确定＿＿ABCD＿＿等等。

A、各级各类教育机构的目标

B、考试时间和内容

C、管理公立学校的教职员

D、确定教育经费

E、确定组织机构

2、人们通常把教育行政的本质定性为国家政权对教育进行领导控制及其管理的活动，这就说教育行政为国家权力所支持。各国＿ABC＿等方面的差异是构成教育行政体制形式不同的重要因素。

A、社会政治制度

B、国家体制

C、文化传统 D、政府机构

E、政府组织

3、这就是说，不管哪一种教育行政体制类型都有其长处与不足，所以问题并不在于二者择一即可，关键在于依据各国的＿＿ABCDE＿等方面综合地加以判断。

A、国情

B、民情

C、行政内容

D、行政区划的大小

E、中央集权制

F、地方分权制的特点

4、集权制的教育行政系统与分权制的教育行政系统在其职责的划分上、作用发挥上呈现出种种的不同，突出表现在＿ABCDE＿等职能方面。

A、计划

B、组织

C、管理

D、监控

E、服务

5、依据地方分权原则建立起来的教育组织系统则带有分权倾向和松散的特点，特别是中央教育行政组织与地方各级教育行政组织之间保持着一种＿ABC＿＿的非权力作用的关系。

A、指导

B、援助

C、建议

D、领导

E、控制

第三题、判断题（每题1分，5道题共5分）

1、（本题空白。您可以直接获得本题的1分）

2、（本题空白。您可以直接获得本题的1分）

3、（本题空白。您可以直接获得本题的1分）

4、（本题空白。您可以直接获得本题的1分）

6.计算机软件项目管理中的需求分析 篇六

众观国内计算机软件业的发展，除远不如欧美等西方发达国家外，与人均GDP不及我国的印度相比也相距甚远，软件业的劣势正严重制约着我国IT业的发展。我国软件业的劣势表现在自主开发的成熟软件不多，而开发的大量软件工程项目(如ERP等)存在缺陷或完全开发失败。目前，国家正在加大对软件工程的研究和对软件工程人才的培养。根据资料显示，属于需求分析造成软件设计的错误和缺陷约占软件失败的6400，而属于程序代码的错误仅占软件失败的360a，数据表明需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验，介绍在需求分析研究中探索出的一些有效措施。

项目用户方干系人，指所有可能受到项目结果重大影响的人，即项目的风险承担者，他可能是项目的受益者，也可能是项目的受害者。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。

有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，“从头再来”的部分比例很高，大大超过进度要求时间。因此，熟悉项目用户方干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目用户方干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;还应当在相关单位组织结构图基础上画出全体项目用户方干系人结构图，以便更好更全面地进行需求调研分析;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。

软件开发项目的目的就是要实现项目用户方的需求，项目用户方的需求包含明确的和隐含的，也可以分为NEED, WANT, WISH等不同的层次。如果对项目所有用户方干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则会出现客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极，或者是多个用户代表各说各话、昨是今非，项目后期需求变化随意等现象，这就会造成项目范围的蔓延，进度的拖延，成本的扩大，甚至项目的完全失败。

各种用户对系统具有不同的要求，如一个没有经验的用户关心系统是否简单易用，对于高级用户则关心产品的易用性和高效性。因而需要对用户进行分类，每一个用户类将有自己的一系列功能和非功能要求。在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同的需求。

7.软件缺陷管理方案分析 篇七

软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误, 或者隐藏的功能缺陷。软件缺陷管理是在软件生命周期中获取、管理、沟通任何变更请求的过程, 可以确保问题或缺陷被跟踪管理而不丢失。目前缺陷管理类的软件工具比较多, 主要功能比较一致, 但在一些细节, 如缺陷管理的流程, 与其它软件工程管理软件的集成, 甚至涉及到软件测试流程和软件质量管理的理念上, 都存在差异[1]。本文结合作者的软件开发和测试工作经历, 给出一套软件缺陷管理方案。

2. 软件缺陷的产生

软件测试从需求分析阶段就与软件开发同步进行, 软件缺陷在软件测试的各个阶段都会产生。图1是软件缺陷的产生示意图。

测试人员和开发人员首先根据测试需求创建各个测试用例, 测试需求与测试用例是一对多的关系;各个测试用例在运行后会产生相应的测试结果, 在一次测试过程中, 一个测试用例只会有一个测试结果, 但从整个软件测试流程中, 一个测试用例会产生多个测试结果, 比如在针对不同版本进行的回归测试, 从测试用例到测试结果一般测试人员和开发人员都会参与;最后, 如果测试结果完全满足对应的测试需求的要求, 即测试成功, 可以认为该测试用例测试通过, 若不满足, 即测试失败, 根据测试结果创建相应的缺陷, 测试结果与软件缺陷是一对多的关系[2]。

3. 软件缺陷管理方案

3.1 管理内容

从管理功能的角度, 软件缺陷管理会记录缺陷时间、严重度、异常的程序表现以及如何重现软件缺陷的细节;另外还有报告程序缺陷的人员身份和可能修正此缺陷的程序员信息。为了追踪与软件缺陷相关的测试用例和测试结果, 应该对测试用例和测试结果进行分类管理, 同时关联好测试用例、测试结果和软件缺陷三者的关系[3,4]。

从管理权限的角度, 软件缺陷管理过程中, 除了需要分配相关的人员对测试用例、测试结果和软件缺陷进行维护外, 还需要不断跟踪软件缺陷及与之相关的测试用例、测试结果在其生命周期中被分配的状态指数。在跟踪过程中应当允许管理员设定基于状态的权限, 可以结合软件缺陷的管理流程, 通过权限管理来维护在测试用例、测试结果和软件缺陷生命周期中的状态, 包括缺陷的确认、缺陷任务的分配等等。同时对各类状态进行定义和维护[3,4]。

下面首先分析软件缺陷的具体内容及生命周期中的状态关系, 然后定义相关的权限和角色, 并赋予角色对应的权限。

3.2 软件缺陷管理

一条测试用例的多次执行会产生多个测试结果, 当测试结果与预期结果不一致时, 可以通过该测试结果产生一个或多个软件缺陷, 当发现软件缺陷后, 需要设法找到引起这个缺陷的原因, 对软件缺陷进行分类, 分析对产品质量的影响, 然后确定软件缺陷的严重性和处理这个缺陷的优先级。一个完整的软件缺陷包括如下表所示的字段信息:

软件缺陷在其生命周期中的状态关系图如图2所示:

如图所示, 软件缺陷共有四个状态, 缺陷创建时为Active状态, 表明该缺陷激活, 需经过管理员的确认, 管理员确认通过后, 此时将该缺陷设置为Reviewed状态, 表明缺陷得到确认, 再将该缺陷分配给软件修复者 (通常为开发人员) 进行处理;软件修复者得到任务后对缺陷进行修复, 修复完成后, 将该缺陷设置为Resolved, 表明该缺陷已得到解决;当修复者处理好缺陷后, 创建者需要判断该缺陷是否得到了处理, 如果并未得到处理, 则将缺陷重新设置为Active状态, 表明该缺陷没有能正常解决, 然后交给管理员再进行确认;若创建者判断修复者已经完成了对缺陷的处理, 则由管理员进行确认, 确认通过后缺陷状态仍然为Resolved;当管理员认为该缺陷已经解决, 同时在后续开发过程中也无须跟踪该缺陷, 则可以将缺陷状态设置为Closed, 表明该缺陷为关闭状态, 后续测试和开发无须考虑该缺陷;对新创建和重新激活的缺陷, 管理员在进行确认过程中, 如果认为创建的缺陷无须修复, 直接可以设置为关闭状态, 或者对于创建者重新激活的缺陷, 管理员若认定该缺陷已经解决, 管理员可以将缺陷再次设置为Resolved状态;同样对于已经为Closed状态的缺陷, 在后续测试过程中重现, 可以重新激活, 设置为Active状态[3,5]。

设置为Resolved状态的软件缺陷, 并不表明该软件缺陷得到了修复, 仅仅表示该软件缺陷得到了处理, 有的情况下有些软件缺陷是不需要修复的, 比如无法复现的问题, 或者暂时不能解决的软件缺陷, 也有的情况下软件缺陷发现得比较晚, 当前的处理结果是在下一个版本进行修复;这里将Resolved状态的缺陷分为两大类:无效缺陷和有效缺陷, 该两大类将已解决的缺陷再分成如下的解决分类[5], 如表2所示:

3.3 软件缺陷权限管理

由前面分析可以看到, 在软件缺陷管理过程中, 所涉及到的角色较多, 因此必须要设置相应的角色和对应的权限。首先将权限分为软件产品管理、用户管理、测试用例管理、测试结果管理和软件缺陷管理五个方面, 将角色分为系统管理员、项目管理员、测试管理员、测试审核员、测试人员和开发人员六个方面, 各角色的具体权限分配如表3和表4所示:

4. 结语

本文给出了一套软件缺陷管理方案, 该方案从生命周期和管理内容两个方面详细分析了软件缺陷的管理方法, 并给出了软件缺陷权利管理中权限和角色分配方法。该方案更多的是结合本人在软件开发和测试工作中的经验总结而成, 在软件缺陷的状态关系中, 强调了审核和确认的机制, 管理方案略显繁琐, 在软件开发和测试的实际运行中比该方案相对简单;另外方案在团队工作和项目管理方面, 尤其是质量控制和质量保证方面, 考虑得不够全面, 在今后的工作过程应重点融入这部分内容。

摘要：基于作者软件开发和软件测试的工作经历, 给出了一套软件缺陷管理方案, 该方案对软件缺陷的管理内容和生命周期进行重点分析, 定义了软件缺陷在其生命周期中的各个状态, 以及状态之间的转换过程, 然后在软件缺陷权利管理中给出了权限和角色分配方法, 最后对方案提出了一些不足和改进。

关键词：软件缺陷管理,测试用例,测试结果,生命周期,权限管理

参考文献

[1]百度百科.缺陷跟踪管理系统[EB/OL].http://baike.baidu.com/view/107502.htm, 2013.

[2]张创基.软件缺陷管理系统的分析与设计[J].教育教学论坛, 2012.8.

[3]林璐.对软件测试中的缺陷管理的研究和实践[D].上海:复旦大学, 2011.

[4]闫振兴, 郑骏.软件缺陷度量与软件过程管理方法研究[J].计算机与数字工程, 2010.8.

8.计算机软件工程项目管理分析刍议 篇八

关键词 计算机软件 工程项目管理 问题 对策

中图分类号：TP311.5 文献标识码：A

计算机软件的大量应用，为人们的生产、生活带来了极大地便利，计算机软件工程项目管理受到了广泛的关注与重视，在很大程度上促进了社会各行各业的全面发展，为社会发展提供了强大动力。做好计算机软件工程项目管理工作成为了计算机软件发展的重中之重。在计算机软件为我们带来便利的同时，计算机软件工程项目管理也出现了很多问题，直接影响了计算机软件工程项目的可持续发展，把握管理中存在的问题，对管理对策进行探究势在必行。

1计算机软件工程项目管理中存在的问题

1.1 计算机软件工程项目管理团队协作问题

（1）管理团队分工不清。在进行计算机软件工程项目管理过程中，管理人员分工不清，权责不明，不能在规定时间内完成规定任务，团队成员互相推卸责任，造成工程项目进度延迟，影响整个软件工程项目的顺利进行。

（2）管理团队不合作问题。在计算机软件工程项目管理过程中，各个管理人员不能做到与他人通力合作，只是各忙各的，在工作中出现任何问题也不与他人进行沟通，共同解决，团队整体合作性差，直接影响软件工程项目工作质量和工作效率，阻碍软件工程项目的顺利进行。

1.2 需求分析与实际业务存在差距

在进行计算机软件工程项目管理过程中，没有根据实际工作需要及调查数据进行管理工作，造成需求分析与实际工作业务产生很大差距，在软件工程项目管理中出现偏差，缺乏合理性与可行性，直接影响工程项目管理质量，造成产品与实际业务之间的误差，导致企业经济损失，阻碍计算机软件工程项目的长足发展。

1.3 风险管理问题

风险管理作为计算机软件工程项目管理中的重要组成部分，对软件工程项目的顺利实施起着至关重要的作用，是软件工程项目安全运行，避免企业经济损失的关键所在。但是在实际管理工作中，很多管理人员缺乏安全意识，对软件工程项目风险管理工作缺乏足够的重视，给软件工程项目开发埋下安全隐患，影响软件工程项目的顺利进行。

2计算机软件工程项目管理相关对策

2.1有效进行风险管理和工作进度管理

在计算机软件工程项目管理过程中，要建立健全工程项目风险管理制度，提高管理人员风险意识，加强管理人员风险管理知识的学习，提高风险识别能力，充分掌握各种风险控制方法。在实际工作中，制定风险报告，做好风险防范工作。在进行软件工程项目管理过程中，定期对工程项目风险进行识别与及时的控制，总结出风险规避与转移方法，确保软件工程项目的安全进行。另一方面，要加强软件工程项目的进度管理，对项目进度进行有效监督，合理控制，在保证工程项目质量的前提下，按计划时间完成计算机软件工程项目管理工作。

2.2建立完善的计算机软件工程项目管理体系

管理体系是有效进行计算机软件工程项目管理的重要手段，完善的计算机软件项目管理体系是项目顺利进行的重要保障。建立、健全管理体系势在必行。同时还要加强相关管理人员的专业知识学习，提高管理人员的管理水平和综合素质，建立一支专业技能强，业务素质高的软件工程项目管理队伍。

2.3建立计算机软件工程项目合作团队

在企业内部要建立起一套完整的管理沟通制度，提高管理人员沟通合作意识，促进团队合作管理，对各个管理人员进行合理分工，使每个管理人员权责明确，在做好自己本职工作的基础上，加强团队合作，增强管理人员团队合作管理积极性，提高软件工程管理人员的工作质量和工作效率，培养管理人员团队合作精神，为企业带来更大的经济效益，促进计算机软件工程项目的可持续发展。

3总结

随着我国国民经济的不断发展，计算机软件得到广泛关注和应用，促进了社会生产方式的转变和人民生活水平的提高，为社会的整体发展做出了巨大贡献。与此同时，计算机软件工程项目管理工作也出现很多问题，直接影响了计算机软件工程项目的顺利进行，本文从计算机软件工程项目管理中存在的问题出发，对计算机软件工程项目管理的相关对策进行了深入分析和探究，不足之处还望指正，希望能为计算机软件研究贡献绵薄之力。

參考文献

[1] 林茂光，王建宇，吴中平.工程项目管理中的网络计划技术应用[J].国外建材科技，2010.10（02）：120-123.

[2] 邵美英.计算机软件工程项目管理之方略[J].城市建设理论研究（电子版）， 2012.10（05）：150-153.

[3] 罗永国.浅谈计算机软件系统工程项目的监理[J].广西现代职业技术学院，2012.10（12）：230-235.

[4] 杨志明，李丽，孟晓宇.软件项目管理过程[J].科教文汇（下半月），2011.06（15）：231-234.

9.软件测试管理案例分析 篇九

2.1系统可靠性建模模块

可靠性建模功能主要围绕如何实现系统的计算机辅助故障树建模这样一个问题来展开，也就是必须使计算机能辅助绘制故障树模型。绘制故障树模型功能包括模型可视化显示、模型图形属性编辑(图形的添加、删除、复制和缩放等)、模型事件属性编辑(事件的名称、失效概率分布和失效参数等的设置)和模型自动完整性检查等功能。

软件中将故障树模型的节点抽象为派生于CObject类的CFTANode类，模型节点的图形属性和事件属性都封装作为CFTANode类的成员，对模型节点的图形及事件属性编辑操作转变为通过鼠标消息处理函数来改变CFTANode类的相应成员值的操作。然后，我们再使用MFC中支持CObject指针的数组CObArray类存储大量模型节点CFTANode类对象，从而实现整个模型的生成，对数组的操作也就是对整个模型的操作。

2.2系统可靠性分析模块

本模块要求能够对已有的系统可靠性模型进行自动可靠性分析，即可以实现故障树的定性定量分析。

1)系统故障树模型的定性分析

对综合监控系统的可靠性定性分析要求分析出系统失效的所有故障模式、故障组合及能够保证系统不失效的所有有效途径，即是求出相应系统故障树模型的全部最小割集。对于含有非门的情况下，求出所有质蕴含割集;求出相应模型的全部小路集，对于含有非门的模型，求出所有质蕴含路集。

2)系统故障树模型的定量分析

对综合监控系统的可靠性定量分析要求分析出系统故障的发生概率、系统故障时系统下层子系统/设备对其的贡献大小，即是求出相应系统故障树模型的顶事件的发生概率及各底事件的重要度。本软件可以根据底事件的故障分布设置及分析时间参数计算出被分析事件按指定时间间隔的不同时间段内的失效概率，各底事件不同时间段内的概率重要度值，用户可以列表查看被分析事件失效概率及底事件概率重要度随时间的变化，同时，软件还可以从模型结构角度计算底事件的结构重要度。

软件中采用二元决策图(BDD)法对故障树模型进行求解。二元决策图(BinaryDecisionDiagrams)，简称BDD，由美国科学家SheldonB.Akers于1978年提出的，基本思想就是利用“图”的形式定义一种数字函数，通过函数可以直观地根据函数变量的输入值确定函数输出值，从而故障树顶事件可以通过BDD直接表达成不交化路径之和，它可以通过回溯BDD中所有叶节点为1的路径，写出相应函数的不交化表达式，再利用互斥事件和的概率公式可计算出顶事件发生的概率。由于文章篇幅的限制，本文中就不再对BDD算法进行详细的介绍，读者可以阅读参考文献加以了解。

2.3系统可靠性数据管理模块

本模块要求能够实现地铁综合监控系统/设备的可靠性数据管理统计功能，不但要能对系统/设备的基本信息、运行情况、故障检修数据、可靠性试验数据等实现统一的管理平台，而且要具有一定的统计分析功能，为系统建模时设备失效概率分布的确定提供参考作用。

2.3.1系统设备可靠性数据设计

本文中把系统/设备的可靠性数据分为三类：设备基础信息、设备可靠性信息和计算机生成数据，具体描述如下。

(1)设备基础信息

设备基础信息包括：设备名称、设备编号、设备类型、功能描述、设备制造厂商、制造型号、制造序列号、设备所在车站、设备所在系统、设备首次投入运行时间、设备安全等级、设备设计参数、数据采集开始日期、运行方式、故障方式或故障判断标准等信息。

(2)设备可靠性信息

设备可靠性信息包括：设备状态变换数据、设备故障数据(故障时间、故障等级、故障模式、故障简述、故障原因、解决措施、此次故障导致设备不可用的时间等)、设备检修数据(检修时间、检修原因、此次检修所用时间等)、设备试验数据(试验时间、试验类型、试验方案、可替换或不可替换、试验参数、此次试验所用时间、试验数据组(失效编号、失效简述、原因分析、解决措施、失效时间、备注))、备注等信息。

(3)计算机生成数据

计算机生成可靠性数据包括：设备累计运行时间，设备累计不可用时间，运行故障率、平均故障维修时间、平均试验间隔时间。

2.3.2软件中的数据库设计

软件中的数据库采用SQL设计，根据系统可靠性数据包含的信息，软件中设计了7了个数据库：设备可靠性数据库、设备所在位置信息库、设备状态信息库、设备故障信息库、设备维修信息库、设备可靠性试验信息库、设备可靠性试验失效库。其中设备可靠性数据库为主要数库，其它六个数据库都为其的子级数据库。

2.4地铁综合监控系统可靠性模型图库的设计

软件完成以后，利用软件的系统可靠性建模功能对地铁综合监控系统进行建模，可以从系统设备结构失效、系统常见故障、系统常用功能失效等多角度建模，并将建好的模型文件统一记录存档，使用户能够在需要时方便快捷的调用已有的模型进行可靠性分析，快速查找，精确定位系统故障部位，可以称之为地铁综合监控系统故障树图库，软件中已经对地铁综合监控系统中部分子系统或子设备故障进行了初步建模，但还远远不够。本文希望起到抛砖引玉的作用，吸引更多学者到地铁自动化系统可靠性分析领域来，进一步充实完善地铁综合监控系统故障树模型图库，最终形成以此为基础的地铁故障诊断系统。

3结束语

10.学生信息管理系统软件测试报告 篇十

【一】系统调试和测试

学生信息管理系统的测试方法主要采用黑盒测试和白色测试的方法，具体的说黑盒测试主要采用以下两种测试方法：

1.已知系统的功能设计规格，进行测试证明每个实现了的功能是否符合要求

2.已知系统的内部工作过程，通过测试证明每种内部是否符合设计规格要求，所有内部成分是否通过检验。

该学生信息管理系统主要采用黑盒测试的第一种测试方法，具体的测试如下：（1）查看学生表中的数据

（2）检测各个功能 a.检测登陆界面的功能

登陆界面

主界面跳转后的界面

b.验证学生信息资料显示，编辑，删除，查看详细信息的功能

学生信息资料的显示

学生信息资料的删除

学生信息资料的编辑

学生信息资料的详细显示

c.检测学生信息的查询，添加的功能

学生信息查询的主界面

学生信息的查询

学生信息的添加

学生信息的添加结果

【二】设计体会

11.软件测试管理案例分析 篇十一

【关键词】计算机 软件项目 需求分析

【中图分类号】TP311.52 【文献标识码】A 【文章编号】1672-5158（2013）04-0008-01

一、计算机软件项目管理涵义

项目是一件事情、一项独一无二的任务，也可以理解为是在一定的时间和一定的预算内所要达到的预期目的。具有明确的目标性、资源成本的约束性、项目实施的一次性、结果的不可逆转性以及创新性。

项目管理是指在项目活动中运用专门的知识、技能、工具和方法，使项目能够在有限资源限定条件下，实现或超过设定的需求和期望。

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。其对象是软件工程项目，和其他的项目管理相比有相当的特殊性。在计算机软件项目管理过程域中，主要包括：项目规划、立项管理、需求管理、项目监控、风险管理和结项管理等。

二、计算机软件项目管理中的需求分析内容

软件需求工程是计算机软件项目开发工作的一个重要源头，涉及到需求开发和需求管理。需求开发涉及到需求调研，需求收集，需求分析，需求开发等工作，其中的重点有业务流程，数据字典，业务规则，界面原型；需求管理工作涉及到需求的状态管理，变更管理，需求的跟踪，需求的验证和确认等重要内容。

软件需求分析特别重要，在软件开发的过程中具有举足轻重的地位，但是我们常常会忽视两点：一个就是缺乏需求分析和开发的过程，把用户需求直接作为了软件需求，没有需求建模和抽象的过程。另外一点就是对于性能，安全，易用性，可维护性和扩展性等非功能性需求没有考虑，导致开发出来的系统是一个不好用的半成品。

三、计算机软件项目管理中的需求分析目标

在计算机软件项目管理的实际工作中，管理者必须在每一项工作中，全面分析问题，正确评估任务，制定详细的计划表，从而实现既定目标。软件需求分析的主要实现目标包括：

1）对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整

性，促使用户在软件设计启动之前周密地、全面地思考软件需求；

2）了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；

3）为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。

四、计算机软件项目管理中的需求分析的步骤方法

（一）获取用户需求。这是该阶段的一个最重要的任务，可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。首先，了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。其次对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。再次，需求分析人员对收集到的用户需求做进一步的分析和整理。下面是几条常见的准则：（1）对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；（2）将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”，（3）分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。最后，需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动：（1）明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项），（2）使需求符合系统的整体目标；（3）保证需求项之间的一致性，解决需求项之间可能存在的冲突。

（二）分析用户需求。在系统设计之前和设计、开发过程中对用户需求所作的调查与分析，是系统设计、系统完善和系统维护的依据。可以通过审查业务流程、Demo界面和UML图，征求反馈意见。评审对软件系统运行时所处环境的要求。例如硬件、数据通信接口等等，在软件方面，采用什么支持系统软件运行（如操作系统、网络软件、数据库管理系统等）。从工作流程和数据流出发，逐步细化软件功能，找出系统各模块之间的联系、接口特性和客观限制，分析它们是否满足功能要求。针对可靠性、安全l生和扩展性评审，TCMS系统涉及公司内部最高机密，聘请第三方机构进行需求分析评审。

（三）文档编写。需求开发的最终成果是：客户和开发小组对将要开发的产品达成一致。为此，我们还必须编写软件需求说明书，进一步理解业务需求，用户需求，功能需求，为设计、开发和测试以及产品相关人员的提供参考。软件需求说明书采用什么样的形式能够把功能描述清楚，如何让使用人员尽快了解产品的功能，采用什么样的编写方式，是软件需求分析人员需要考虑的问题。经过最近的摸索和积累，个人觉得编写需求文档不一定要长篇大论，要多用表格和流程图，并且至少包括以下内容：（1）目的。即使用场景描述，先用几句话简要概括做该软件是用来解决什么问题。不要一开始就描述功能，至少让设计人员大致了解该功能的使用目的。（2）涉众。软件是让谁来使用，列举所有可能使用到此功能的用户或者角色。（3）功能列表。菜单树，展示具体包含的子功能和上下级关系。由于不同类型用户关注的重点可能不同，所以最好应给出各子功能中对应的默认用户权限。（4）数据字典。列表描述功能涉及的字段名称、数据类型、取值范围、默认值、备注信息等。（5）流程图。描述用户使用的正常流程和异常流程，如果涉及到状态转换最好给出状态迁移图。（6）UI。展示所涉及界面布局和原型，不必描述具体提示内容信息，可以在字符串资源表中去定义。（7）相关影响。该功能对其他相关模块的影响，还有其他相关模块对此功能的影响。

（四）需求验证。与客户经过沟通或验证，会产生两种结果：一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。包括以下内容：（1）审查需求文档：对需求文档进行正式审查是保证软件质量的很有效的方法。组织一个由不同代表（如分析人员，客户，设计人员，测试人员）组成的小组，对需求规格说明书及相关模型进行仔细的检查。另外在需求开发期间所做的非正式评审也是有所裨益的。（2）依据需求编写测试用例：根据用户需求所要求的产品特性写出黑盒功能测试用例。客户通过使用测试用例以确认是否达到了期望的要求。还要从测试用例追溯回功能需求以确保没有需求被疏忽，并且确保所有测试结果与测试用例相一致。同时，要使用测试用例来验证需求模型的正确性，如对话框图和原型等。（3）编写用户手册：在需求开发早期即可起草一份用户手册，用它作为需求规格说明的参考并辅助需求分析。优秀的用户手册要用浅显易懂的语言描述出所有对用户可见的功能。而辅助需求如质量属性、性能需求及对用户不可见的功能则在需求规格说明书中予以说明。（4）确定合格的标准：确定合格的标准让用户描述什么样的产品才算满足他们的要求和适合他们使用的。将合格的测试建立在使用情景描述或使用实例的基础之上。

参考文献：

[1]吴艳艳：周长伦：姜家轩：王春梅：许自国：：软件项目管理中的需求管理[J]：信息技术与信息化：2008年02期

[2]孙莉：：软件项目管理中的需求管理[J]：信息系统工程：2011年04期

12.职工收入管理软件的设计与分析 篇十二

目前医院财务科使用的《用友管理》软件主要集中对账务、账本进行管理,而没有针对每个员工工资、奖金等收入的处理。同时《HIS管理系统》中除了管理员工的人事信息,也缺乏员工收入的信息。员工的各种收入情况都是由各部门造表发送给财务科,财务科统一匹配银行卡,并由出纳交给银行,银行把钱打入员工的账户。整个收入的处理情况,缺乏信息系统的支撑,因此需要通过信息化手段,细化财务管理内容、规范收入的登记流程、提高财务管理水平。

2业务目标

2.1能够直接导入员工收入表

员工的各类收入一般由各个职能部门造表,并统一发送给财务科的工资核算人员,由该名财务工作人员审核并把收入表发送给出纳。

要求整个收入管理环节处理简单,只需直接从收入表中导入数据,不需要直接输入。

2.2能够对员工收入进行查询统计

能够统计每个员工或者所有员工在一个时间范围内的各种收入。

3需求分析

3.1业务目标定义系统边界

根据“直接导入员工收入表”这个业务目标的描述,我们知道这个目标是为负责工资核算的财务人员使用的,工资核算员就是系统的一个业务主角,同时定义出一个命名为“收入管理”的系统边界。

而“查询统计”这个业务目标,由于只是一个面向财务管理的软件,运用的范围规模比较小,就统一作为一个目标对待。

3.2系统边界图

3.2业务用例

1) 业务用例图

2) 系统用例规约

系统将实现一个较为简单的登录管理,程序启动后,显示主界面的时候,弹出登录窗口,用户需要输入正确的用户名和密码,才能使用系统,否则直接关闭主界面。

系统将提供一个查询,能够设置查询时间,选择某个职工或者全部职工,选择单个科目或者全部科目,根据用户的选择,系统显示查询结果。

显示的数据包括科目和金额2列数据,最后一行显示金额汇总,数据可以导出到EXCEL。

4数据库设计

根据用例分析中涉及的实体对象,主要有银行卡、科目、银行卡、操作用户四个对象。

其中的助记码分别作为银行卡、科目对象中的一个属性。

数据表描述如下:

银行卡包括(银行卡号,身份证号,姓名,开户银行,助记码,标记)。

科目包括(科目代码,科目名称,助记码)。

银行卡记录(银行卡号,操作时间,制单日期,金额,科目代码)。

操作用户(用户名,密码)。

涉及的业务规则,利用数据库的存储过程实现。

数据表可以单独放在新的数据库中,也可以直接加入医院目前运行的数据库中。

5小结

职工收入管理软件作为一个短小精悍的实用功能,细化了财务管理内容,操作简单,易于部署,以后会根据业务需要,将系统接入医院的整个信息系统中,统一用户名登录,统一员工人事信息。

摘要：财务科工作人员利用职工收入管理软件细化收入分类,记录每位员工的银行卡资金收入,能统计每个员工的收入明细以及单位的收入分配,有力促进了医院精细化管理水平的提高。

13.软件测试失效案例简介 篇十三

失效案例简介

软件出现的问题有多种形式，会产生各种各样的后果。下面是一些例子。

受医用线性加速器的过度辐射，造成6人严重烧伤或死亡。经查，管理加速器的软件包含了一系列程序错误，由于软件结构极差，错误再现困难，也使得机器生产者不愿意收回机器。

火星气候轨道航天器撞到了火星的表面。调查表明，由于测试不充分，没有发现程序中的一个简单的量纲转换错误。

几架“黑鹰”直升机撞毁，多人罹难。调查表明，灾难原因是无线电信号与机载计算机系统相互干扰。

称做CONFIRM的旅游预订系统在经过1.25亿美元的投资后流产。

F22战机的一个软件故障（边界值测试的漏洞）。2007年2月，美军F22战斗机从夏威夷飞往日本，途径日期变更线（东经180度，西经0度）时，软件缺陷爆发，飞机上的全球定位系统失灵，电脑系统崩溃。飞行员无法确定战机的位置，返回夏威夷的希卡姆空军基地。洛·马丁公司对软件进行了维护，48小时后提供了新的软件版本。

2007年北京机场信息系统瘫痪。2007年10月10日13时28分，设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障，短短50分钟内，北京、广州、深圳、长沙机场至少84个离港航班发生延误，受其影响的城市包括上海、长春、南京、南宁、温州、成都、郑州、太原、呼和浩特、重庆、兰州、香港、东京等。该系统是由美国某家公司研发，此事件引发信息系统安全的担忧。

2008北京奥运会售票系统于2007年10月30日上午11时瘫痪：北京奥运会的指定独家票务供应商-北京歌华特玛捷票务有限公司成立于2006年9月，由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后，公众普遍质疑歌华特玛捷公司是否具备承担2008北京奥运会的票务销售能力。

用户常常在软件开发初期就发现软件不是他们所期待的。在开发软件之前，需要进行必要的需求分析。充分的需求分析要求软件开发人员与用户进行良好的沟通，充分理解用户需求才能开发出更有用的产品。虽然这些软件故障的后果程度不一，但可以肯定的是，通过严格的软件工程可以极大地降低故障及因此而引发的种种恶果。

1.6.2失效原因

软件失效主要是由于开发组织没有采用好的软件工程方法。尽管软件开发人员知道不好的软件开发可能造成可怕的后果，但为什么大家还不能广泛采用软件工程的方法呢？原因是管理和开发队伍对软件工程早期的重要性的认识严重不足，认为代码的行数是项目进展的唯一尺度，任何与生成代码无关的事情都不是进展，因而也不值得花费时间和资源。

引起软件失效的原因包括：

1)软件复杂度；

2)非线性（多线程）软件；

3)对意外的输入或条件估计不足；

4)与外设接口动作异常；

5)硬件或操作系统与软件不兼容；

6)管理不善；

7)测试不充分；

8)粗心大意；

9)想走捷径；

10)不向管理部门通报问题；

11)风险分析不充分；

12)数据输入错误；

13)错误的输出解释；

14)对软件过于自信；

15)缺乏生产高质量软件的市场或法律压力。

以上是引起软件失效的原因列表，对我们很有帮助，我们应该谨记。考虑的潜在软件失效原因越多，系统就越不易出现失效。例如，如果完全按照一种软件工程方法学来开发软件，假设用户是未经过充分训练的，那么就应考虑可能会出现数据完整性错误，否则，系统可能是没什么用的。

下面来看几个实际的软件开发中的灾难故事，目的是让你充分理解软件开发中和谐工作方式的重要性，不论你是初学者还是计算机专家，均能获益。这些故事也可以让你为争取在你的工作环境下采用好的软件工程方法提供有力证据。

1.6.3 CONFIRM

CONFIRM是一个雄心勃勃的软件开发计划，它的目标是集成飞机订票、汽车出租和旅馆预订以及相关的决策支持机制为一体。它是由美国航空公司的子公司AMRIS提出的，项目开发了3年半，耗资1.25亿美元，结果生产了一个无用的系统。

CONFIRM的惨败虽然没有危及任何人的生命，但是如此巨大的经济损失最后都转嫁到了消费者身上。通过这种高的消费代价，大众觉察到如此灾难性软件开发的后果。为了更好地评估避免如此巨大经济损失而应采取的各种策略，将有关的大事列表如下：

1)1987年10月，Marriott,Hilton,Budget Rent-a-Car和AMRIS成立联盟，决定开发和运营CONFIRM，并让AMRIS管理开发。项目计划分两个阶段，计划于1992年6月完工。

2)1988年5月24日，AMRIS发布新闻，宣布CONFIRM设计阶段开始。

3)1988年12月30日，AMRIS向联盟呈报了系统基础设计，Marriott认为系统的功能规约还不够充分，用户需求还不够细，开发人员还不能据此进行开发。

4)1989年3月，AMRIS呈报一份开发计划，结果也未被联盟成员们接受。

5)1989年8月，AMRIS向联盟成员提交了项目经费预算。基于这一预算，其他成员决定继续维持该项目。后来的事实表明，这一预算对人员和操作成本的估计存在严重不足。

6)1989年9月，AMRIS终于完成了一个令联盟满意的设计，同时预算也增长至7260万美元。

7)1990年1月，AMRIS未能按第一合同期限完成终端屏幕的设计。

8)1990年2月，第二个项目里程碑即系统商务领域分析也未能如期完成。AMRIS承认有13周的滞后，但仍声明系统可以在原定的期限完成。

9)1991年2月，AMRIS向联盟成员提交了一份修改过的开发计划，要到1993年3月为Marriott提供完整功能的系统。后来Marriott声称其实AMRIS知道它不可能在新的期限内完成系统，但还是强迫雇员人为地延长工作时间表，否则会遭到解雇或重新调遣。AMRIS也在修改的开发计划中提高了开发的价钱，升至9200万美元。

10)1991年10月，AMRIS总裁以及20余名雇员辞职。

11)1992年5月1日，AMRIS的新总裁认可“系统接口和数据库不足以提供必要的性能和可靠性”，他还将这种状况归究于AMRIS对项目状态的错误认识。

12)最后，于1992年7月，联盟在花费了1.25亿美元后，不堪重负，终于解散。

大量的报刊对CONFIRM项目的无能的管理和技术上的幼稚等进行了无情的嘲讽。不过我们关心的是，如何利用适当的软件工程方法来避免这种灾难。虽然这个例子涉及一个重要的职业道德问题，但首先还是让我们来分析软件失效的根源。

很明显，AMRIS关于项目状态的管理是有问题的。项目是如何发展到管理部门被迫掩盖真相的呢其实在项目的早期就有一些不好的征兆，AMRIS是不能开发一个可行的产品的；第二个征兆是，经过7个月的努力后，AMRIS提交的设计文档技术上是不能令人满意的。这样的一个设计意味着AMRIS没有能力正确估计自己设计的质量。另外，AMRIS的行动表明它并不重视交付设计的质量，只重视初始设计的按期完成。第二次提交的设计再次遭到拒绝，这也再一次表明AMRIS确实太无能，不可能提出一个充分的开发计划。

以上大事记似乎反复强调了AMRIS不能提供高质量的软件工程报告，这意味着基础的软件开发阶段的有效性值得质疑。另外，某种基础的风险分析应能帮助联盟成员识别至少两种高风险目标。这些风险目标应能提醒联盟成员进行某些测验项目，以确定这些目标的可行性。CONFIRM系统的一个高风险目标是需要与联盟伙伴的现有系统连接，这样的连接要求CONFIRM同异构的软硬件能互操作；第二个高风险目标是需要将预订系统同每种商务领域的决策支持系统集成。初始时对这些目标的复杂性作一下分析，就会得到一个更合理的开发进度计划。

1.6.4 电话和通信

今天，人们很难找到比远程电话网应用技术更好的例子。它通过光纤将遍及世界各地的人们可靠地、即时地连在一起，这不能不说是技术上的奇迹。AT&T拥有多达115个交换站，将遍及世界的当地电话公司连接起来，每天可处理1.15亿次美国境内的呼叫和150万次的海外呼叫，每个交换站每小时能处理将近75万次呼叫。

一个交换站，又名4ESS，其实是一个庞大的专用计算机，它运行一个包含4百万行代码的软件。该软件需要仔细处理电话两端的连接、通话费以及其他许多与电话相关的服务，为维护该软件需要雇佣150人以上。有几次事故曾中断了电话服务，原因就是该软件过于复杂。

1990年1月15日的下午，AT&T的全球电话网络的管理人员发现显示网络状态的视频监视器上不断出现红色报警信号。报警信号说明网络不能完成呼叫，接下来的9个小时内，有近6500万个电话没有接通，造成大约6000万美元的损失。尽管系统的管理人员设法在9小时内解决了问题，但是要查明原因恐怕需要好几天。

大约在系统瘫痪前一个月，软件进行了升级，以允许某种类型的消息更快地通过系统。在升级软件的一小段代码中发现了一个错误，该错误在严格的测试和一个月的试用中没有被发现，因为那几行代码只在网络特别忙而发生了特定的事件序列时才会调用。各单个交换站工作都正常，但交换站之间的消息传递的快速步调引起系统反复重启动。当运行升级软件的交换站数减少到80台左右时，网络似乎又恢复正常。这时，其余的交换站仍然运行旧版软件，可以处理尽可能多的呼叫。

这种类型的“网络隐错”确实很难发现和想到，要在一个测试用的系统上精确模拟和预料真实世界中的网络通信是十分困难的。事实上，AT&T确实也在它的测试网络上测试了该软件，但没能发现该问题。

与首次瘫痪相隔6个月，又遇到了另一个控制交换站的软件失效。在1991年6月到7月间的三个星期内，8次电话不通事故影响了大约2000万电话客户。不通的原因难以捉摸，而且，本地电话公司之间似乎也不愿意彼此透露如何修复问题的有关信息。最终，由BellCore贝尔通信研究公司经过6个月的调查，认定引起这一问题的原因仍然是这个交换机软件。

这些事故的原因是制造交换机的软硬件公司DSC通信公司对软件的一次修改不当造成的。1991年4月，DSC通信公司发布了交换机的新版本。很快，华盛顿、宾夕法尼亚和北卡罗来纳州的用户碰到了这一问题。每次瘫痪首先由一个交换机的一个小问题引起，该问题与信号传输点（Signal Transfer Point，STP）有关。然后这一问题会触发大量的错误消息，结果导致STP被关闭，进而导致邻近系统的瘫痪。

最后，BellCore发现问题出在新版软件中的一个三位错：一个应是二进制数D（1101）的数误为二进制数60110）。在交换算法中，这三位错导致交换机允许错误消息饱和。通过网络，一个系统出错导致其他系统崩溃。正常情况下，饱和的交换机只简单地通告其他系统出现了拥塞情况。DSC通信公司很快发布了该软件的补丁，专门处理这一问题。对源程序作了广泛的测试之后发现，一个程序员对源程序中的三行代码作了修改，其中一行包含低级的打字错误，软件发布前，该段代码没有经过测试。

你也许会庆幸通信问题似乎已成历史，因为以上两个例子均发生在20世纪90代初。然而，事实上近年来也发生了大量的这类失效。例如，一位美国西部技师为科罗拉多州安装一个新的区域码软件时，不经意地关闭了该区域的911系统，结果一位在Longmont的名叫Thomas Carlock的男士死于心脏病，发病时他的妻子不能拨通911急救服务。当时，她至少试过3次，结果每次都没有回答，没有振铃，也没有线路忙信号。最后，她查了号码本，直接呼叫了一个急救室的电话，然后救护车才发往她的住地。在事故追查的过程中，技师一直不清楚911会有问题，Longmont急救人员也是直到事故发生后一个小时才知道911有问题的。按照美国西部的一份报告的说法，公司“已承诺采取措施确保软件安装不会影响到911服务”。

1.6.5阿丽亚娜5型火箭

1996年6月4日，阿丽亚娜（Ariane）5型火箭在法属圭亚那库鲁航天中心首次发射。当火箭离开发射台升空30秒时，距地面约4000米，天空中传来两声巨大的爆炸声并出现一

团桔黄色的巨大火球，火箭碎块带着火星撒落在直径约两公里的地面上。与阿丽亚娜5型火箭一同化为灰烬的还有4颗太阳风观察卫星。这是世界航天史上又一大悲剧。

阿丽亚娜5型火箭由欧洲航天局研制，火箭高52.7米，重740吨，研制费用为70亿美元，研制时间1985－1996年，参研人员约万人。事故原因报道：阿丽亚娜5型火箭采用阿丽亚娜4型火箭初始定位软件。软件不适应物理环境的变化。阿丽亚娜5型火箭起飞推力15900KN，重量740吨，阿丽亚娜4型火箭起飞推力5400KN，重量474吨。阿5型火箭加速度=21.5g，阿4型火箭加速度=11.4g。阿丽亚娜5型火箭加速度值输入到计算机系统的整型加速度值产生上溢出，以加速度为参数的速度、位置计算错误，导致惯性导航系统对火箭控制失效，程序只得进入异常处理模块，引爆自毁。箭载两套计算机系统由于硬件、软件完全相同，没有达到软件容错的目的。

导航系统负责参照基于惯性参考系统输入的特定轨道来计算航线矫正。一个惯性参考系统让一个移动体（例如火箭）仅根据来自加速仪和回转仪的传感器数据来计算其位置，也就是说，其计算不参考外部世界的数据。该惯性系统首先必须初始化起始坐标，用火箭的初始瞄准来校准其轴。导航系统在发射前，进行校对计算。为了把地球自转产生的影响计算在内，校对计算的结果需要不断更新。校准计算很复杂，大约需要45分钟才能完成。一旦火箭发射后，校准数据将传给飞行导航系统。根据设计，校准计算在数据传给导航系统后，还将继续50秒。这一决定使导弹发射前的倒计数得以在对准数据传出后、在发动机被点火之前终止，而不必重新启动校准计算（即，不必重新启动45分钟的计算周期）。当发射成功时，校准轮在起飞后为下一个40秒产生待处理的数据。

Ariane5的计算机系统与Ariane4不同，电子仪器多了一倍。有两个惯性参考系统来计算火箭的位置，两台计算机将计划中的轨道和实际轨道进行比较，并用两套控制仪器来控制火箭。如果某个构件出了问题，后备系统将随时接替现行系统。

专为地面设计的校准系统，使用16位字来存储水平速度(对由于风和地球运行产生的位移计算而言，16位是绰绰有余的)。飞行30秒后，Ariane5的水平速度计算产生了溢出，由此引出了一种意外，通过关掉机载计算机来处理这一问题，并把控制权交给后备系统。

讨论：由于校准系统没有得到充分测试，尽管它经过成千上万次测试，但没有一次测试包括了实际轨道上的测试。导航系统被单独地进行了测试。系统项目组制定测试计划，导航系统的构造者执行测试。系统项目组没有意识到在飞行中的校准会引起主处理机的关闭。这一实例充分说明了构件组与系统组缺乏沟通。