软件测试失效案例简介
软件测试报告范例3篇
软件测试报告范例第一篇：软件测试报告范例一、背景我所在的公司开发了一款名为“XX路游”的APP，这是一款提供旅游路线推荐和酒店预订服务的应用。
本次测试的目的是针对APP软件功能进行测试，并发现其中的缺陷与需要的改进。
二、测试范围本次测试主要针对以下几个方面：1. 注册和登录功能的可用性和稳定性；2. 路线推荐功能的准确度和及时性；3. 酒店预订功能的流畅性和稳定性。
三、测试结果经过一周的测试，我们共发现了10个缺陷，其中有5个是严重问题，需要尽快解决。
以下是其中几个缺陷的详细描述：1. 注册时，系统未按照要求提示输入信息，导致用户不能成功注册；2. 部分用户在使用路线推荐功能时，出现了系统卡顿现象；3. 预订酒店时，系统提示错误信息，导致用户无法完成支付。
四、改进建议1. 在注册和登录功能上，建议增加错误信息提示的功能；2. 针对路线推荐功能，需要进一步优化系统性能，提升用户体验；3. 酒店预订功能需要加强支付流程的错误判断，避免用户支付失败的情况。
五、结论经过此次测试，我们认为该软件还存在许多需要改进的地方，需不断努力提升用户体验，提高软件稳定性和可用性。
第二篇：软件测试报告范例一、背景本次测试针对一款名为“XX地图”的软件进行，该软件是一款提供导航和地图查询服务的APP。
测试主要的目的是发现其中的缺陷与需要的改进。
二、测试范围本次测试主要针对以下几个方面：1. 地图查询功能的准确度和及时性；2. 导航功能的流畅性和稳定性；3. 软件性能和稳定性。
三、测试结果经过一周的测试，我们共发现了15个缺陷，其中有7个是严重问题，需要尽快解决。
以下是其中几个缺陷的详细描述：1. 用户在使用地图查询功能时，出现了系统卡顿现象；2. 部分用户在导航过程中，系统自动关闭；3. 软件启动速度较慢，影响用户使用体验。
四、改进建议1. 针对地图查询功能，需要进一步优化系统性能，提升用户体验；2. 针对导航功能，需要加强系统稳定性和流畅性，降低用户的使用门槛；3. 针对软件性能和稳定性，需要进一步优化软件开发过程和测试体系，确保软件的质量。
软件测试缺陷报告
软件测试缺陷报告软件测试缺陷报告是指在软件测试过程中发现的缺陷（bug）所编写的报告。
缺陷报告是记录缺陷信息的主要手段，对于软件开发过程的改进和提高软件质量具有重要的作用。
本文将介绍软件测试缺陷报告的作用和三个具体的案例。
作用软件测试缺陷报告的作用非常重要，主要有以下几点：1. 记录问题：缺陷报告是记录缺陷和问题的主要方式。
测试人员应该仔细记录问题，并清晰地描述问题的重要信息。
2. 保持沟通：缺陷报告是开发者和测试人员之间沟通的桥梁，有助于开发者了解测试人员发现的问题，并根据这些问题进行反馈和解决。
3. 提高软件质量：缺陷报告不仅提供了问题所在的位置，还可以说明将问题解决之后应有的结果。
这有助于开发人员对于软件的改进，进而提高软件的质量。
案例接下来，我们将介绍三个软件测试缺陷报告的案例。
1. Crash Bug缺陷：在使用应用程序时，软件会崩溃。
分析：这种情况可能是因为应用程序中出现了语法错误或数据结构问题。
测试人员应该记录崩溃的时机，以及导致崩溃的操作。
解决方法：开发人员应该检查代码错误，以修复缺陷，并确保再次测试通过。
2. UI Bug缺陷：应用程序的用户界面（UI）显示不正确。
分析：这种情况可能是由于开发人员在设计UI时出现了错误，或者是由于软件在不同设备上的显示问题。
测试人员应该记录UI显示的位置和表现形式。
解决方法：开发人员可以根据测试人员的反馈来检查UI设计，通过调整UI布局并重新测试来修复缺陷。
3. Security Bug缺陷：应用程序存在安全漏洞。
分析：这种情况可能是由于代码编写不安全，或是代码存在漏洞。
测试人员应该记录安全漏洞的位置和漏洞类型。
解决方法：开发人员应该检查代码中的安全注意事项，并通过修复漏洞和安全措施来确保安全性。
测试人员应该重新测试以确认安全缺陷是否已修复。
总结软件测试缺陷报告对于软件测试非常重要。
它可以记录所有的软件问题，帮助开发人员和测试人员沟通，提高软件的质量。
软件注册培训资料
医疗器械软件申报基本要求内容摘要¡¡¡¡¡¡1 失效案例与召回分析¡¡¡1.1 软件失效案例¡—¡——¡———1.1 软件失效案例¡———¡——1.2 FDA召回分析¡—¡——¡——1.2 FDA 召回分析¡¡¡¡ 5.6%—60.6%14.1%11.3%5.6%2.8%20098.8%1.1%33.2%34.9%12.7%8.1%1.2%1999～20057%3%30%19%10%21%10%1983～1997其他类手术类影像类检验类通用类心脏类麻醉类时期¡¡¡1.3 软件审评背景¡—————¡———2 软件与软件质量概述¡¡¡2.1 软件概述¡——¡—¡———2.1 算法概述¡—¡—————¡—2.1 软硬件差异¡¡¡¡¡¡¡¡2.2 软件质量概述¡—¡——¡———2.2 人为因素2.2 复杂性¡———¡——2.2 软件缺陷分析¡——¡—¡—¡——2.2 软件工程概述¡———¡———2.3 软件测试概述白盒测试黑盒测试静态测试动态测试内部测试用户测试第三方测试系统测试单元测试集成测试2.3 软件测试概述¡——¡—¡—————3 软件主要标准介绍¡¡¡¡¡¡3.1 标准概述¡¡—¡¡¡¡¡—¡3.1 标准概述¡—¡—¡—¡—3.2 术语定义¡——¡——3.2 术语定义¡——3.2 术语定义¡————操控（处理）操控（处理）处理处理核心功能软件组件独立软件PACS ——通用计算机处理型MRI 、CT操控通用计算机控制型ECG 、EEG 操控医疗器械固件嵌入式Holter 通信通用计算机数据型产品举例医疗器械硬件关系安装形式基本类型3.2 术语定义¡————¡——3.2 术语定义¡—¡—¡—3.2 术语定义¡——¡——3.3 YY/T 0664介绍¡——¡——¡——3.3 安全性级别¡———¡————3.3 安全性级别软件系统C级软件项B级软件项C级软件项B级软件项C级软件项A级软件单元B级软件单元A级软件单元C级软件单元B级软件单元A级软件单元A级软件单元A级3.3 生存周期过程¡—————¡———3.3 生存周期活动开发策划需求分析体系结构设计详细设计单元实现和验证集成和集成测试系统测试软件发行软件危害处境分析风险控制措施软件更改风险管理风险控制措施验证配置标识更改控制状态记录准备问题报告研究问题通知相关方应用更改程序保持记录分析问题趋势验证问题解决测试文档内容修改实施制定维护计划问题和修改分析3.3 软件开发3.3 软件开发3.3 软件开发3.3 软件维护¡———¡———3.3 风险管理*¡———¡————3.3 风险管理*¡——¡——¡——3.3 配置管理与问题解决¡———¡———3.4 YY/T 0708介绍¡——¡——¡—3.4 标准比较5.2 软件需求分析，7.2 风险控制措施52.206 需求规格说明 5.3 软件体系结构设计52.207 体系结构4.1 质量管理体系52.205 人员资格 4.2 风险管理，4.3 安全性级别7 软件风险管理过程52.204 风险管理过程 4.1 质量管理体系，4.2 风险管理52.201 文件 4.1 质量管理体系，4.2 风险管理5.1.7 软件风险管理策划52.202 风险管理计划 5.1.1 软件开发计划9 软件问题解决过程52.203 开发生存周期YY/T 0664YY/T 07083.4 标准比较5.4 软件详细设计5.5 软件单元实现和验证52.208 设计和实现5.5 软件单元实现和验证5.6 软件集成和集成测试5.7 软件系统测试52.209 验证 4.1 质量管理体系52.210 确认6 软件维护过程7.4 软件更改风险管理8 软件配置管理过程9 软件问题解决过程52.211 修改4.1 质量管理体系52.212 评定YY/T 0664YY/T 07083.4 标准比较¡——¡与其他标准共同使用适用于医疗器械软件开发和维护生存周期不覆盖医疗器械确认完善GB 9706.1适用于PEMS 开发生存周期包含安全性确认YY/T 0664YY/T 07083.5 GB/T 25000.51介绍¡——¡————3.5 标准比较¡——¡————3.5 标准比较GB/T 17544第3章GB/T 25000.51第5章3.1.2 h 要交付项3.1.5 e 使用效率和用户满意度5.1.3.5 法律或行政要求5.1.3.6 最大并发用户数5.1.3.8 特定软件和硬件5.1.4.3 关键功能5.1.4.4 软件组件5.1.6.6 可访问性5.1.10 使用质量陈述差异内容3.5 标准比较调整内容细化内容3.1.7 可维护性说明3.2.1 完整性3.2.5 可浏览性3.3.6 可移植性5.1.8 维护性陈述5.2.1 完备性5.2.5 易学性、5.2.6 可操作性5.3.6 可移植性GB/T 17544第3章GB/T 25000.51第5章3.1.2 f 要求的系统3.1.2 I 安装5.1.9.2 配置条件5.1.9.3 安装规程3.6 标准关系软件组件独立软件GB/T 25000.51相应产品标准YY/T 0664YY/T 07083.6 软件类型比较软硬件结合软件系统测试医疗器械产品软件产品开发策划软硬件结合软件设计软件软件编码软件软件单元测试软硬件结合软件集成测试医疗器械产品市场客户需求分析医疗器械产品软件产品发行结构组成内容子系统系统软件组件独立软件。
软件测试的综合实战案例分析
软件测试的综合实战案例分析在当今信息技术高速发展的时代，软件已经渗透到生活的各个领域。
然而，软件的质量却往往受到质疑，因此软件测试在保证软件质量方面起着至关重要的作用。
本文将通过一个综合实战案例，来详细分析软件测试的过程和技术，以及面临的挑战。
案例背景：某公司开发了一款用于手机支付的新型软件，该软件具备简便、安全、快速的特点，以提供更好的支付体验。
然而，在上线使用的过程中，用户反馈出现了支付失败、账户余额不准确等问题。
为了解决这些问题，该公司决定进行软件测试，找出潜在的缺陷并进行修复。
1. 需求分析首先，测试团队与开发团队一起对软件进行需求分析，确保对功能、性能、安全等方面的要求有一个明确的理解。
同时，还需要考虑到用户的使用场景和具体需求，制定测试策略。
2. 测试计划根据需求分析的结果，测试团队编制测试计划。
测试计划包括测试目标、测试范围、测试阶段、测试环境、测试资源以及测试进度等等。
通过明确测试计划，可以确保测试工作按照计划进行。
3. 测试用例设计基于需求分析和测试计划，测试团队开始设计测试用例。
测试用例应该涵盖各种场景和输入，对软件的不同功能进行全面覆盖。
例如，测试支付功能时需要考虑支付成功、支付失败、支付异常等情况。
4. 前期准备在进行测试之前，需要搭建测试环境和准备测试数据。
测试环境应该与用户的实际使用环境尽可能接近，以保证测试结果的准确性。
同时，测试数据应该具有代表性，包括正常、边界和异常情况。
5. 执行测试用例执行测试用例是软件测试的核心环节。
测试团队按照设计好的测试用例，一一执行，并记录测试结果。
测试结果应该包括测试通过、未通过以及出现的问题描述等。
6. 缺陷报告与修复在测试过程中，测试人员会发现一些潜在的缺陷。
测试人员应该及时记录并报告给开发团队。
开发团队根据缺陷报告进行修复，并再次交由测试人员进行验证。
7. 验收测试当软件经过多轮测试并修复后，执行验收测试以确保软件已达到之前制定的需求和质量标准。
测试管理典型案例
测试管理案例之一某软件公司在开发一个城镇居民保险系统时，为了追赶进度，开发人员与测试人员都没有介入单元测试和集成测试工作。
系统测试阶段，测试人员针对界面进行功能测试，借助缺陷管理工具，测试人员和开发人员交互进行测试与缺陷修复工作。
期间发现“扭转文档无法归档”等功能出现严重错误，开发人员在修改时，因为难度大决定暂停修改，得到测试人员认可。
在产品发布前，该问题在开发环境下得到解决。
测试人员在开发环境下进行了回归测试，回归测试结束后，开发人员直接把开发环境下的产品打包，发送给客户。
开发人员和测试人员的做法是否存在不合理的地方？不合理之一：测试介入太晚分析：不合理之二：系统测试方法不合理分析：系统功能测试应该追溯到用户需求，针对界面进行功能测试是错误的。
不合理之三：缺陷管理不合理分析：缺陷权限控制不合理：Ø开发工程师无权决定是否延期或者暂停修改某一缺陷Ø测试工程师认可缺陷的决定也是不合理的缺陷跟踪不合理：测试工程师应该跟踪缺陷状态，直至确定修改后关闭缺陷，才是完成了测试任务。
而不是执行测试发现缺陷就完成了任务，所有的缺陷应该经过验证后才可以发布产品。
缺少缺陷审核：产品发布前，应该对发现的缺陷进行评审，根据修改结果决定是否可以发布。
不合理之四：产品发布不合理分析：产品最后由开发人员直接发布不合理。
实际最后发布的产品应该从产品库中提取，而且基线库中的产品应该是最后经过测试的。
测试管理案例之二某企业有三大产品线，拥有强大的研发团队，测试部门约有8人，没有经过测试技术和测试管理的专门培训，测试类型主要是功能测试，测试阶段主要集中在产品上线前。
这种运作模式，企业和用户对产品质量会满意吗？如果不满意，我们应该采取哪些有些有效的方法来改进？改进方法之一：提高测试团队规模和研发团队相比，测试团队应该占有相当的比例，建议6到8比1。
目前的现状是用户需求多样化，用户看重产品的质量改进方法之二：提高测试团队技能产品的质量特性，不仅仅包括功能性，还包括可靠性、易用性、效率、安全性、维护性以及可移植性等等。
软件项目失败的案例
软件项目失败的案例
软件项目失败的案例很多,以下是其中一些比较常见的:
1. 需求变更:随着项目的进展,需求可能会发生变化。
一些软件项目在开始阶段是设计好的,但是在实施过程中因为需求变更而需要进行修改,导致项目进度延误,成本增加,甚至失败。
2. 技术难题:在软件开发过程中,可能会出现技术难题,例如开发环境配置困难、技术难点难以解决等。
这些问题可能导致项目进度延迟,开发团队士气下降,甚至导致项目失败。
3. 软件缺陷:软件开发中可能会出现软件缺陷,这可能会导致客户使用软件时出现错误,影响客户体验,甚至导致客户投诉。
4. 跨团队协作问题:在软件开发过程中,跨团队的合作是非常重要的。
如果团队之间的沟通不畅,协作出现问题,可能会导致项目进度延误,甚至失败。
5. 项目管理问题:软件开发项目的成功不仅依赖于技术,还依赖于项目管理。
如果项目管理不善,例如未能制定清晰的项目计划、未能有效的沟通和管理、未能控制项目风险等,可能会导致项目失败。
6. 资源不足:在软件开发项目中,人员、设备、材料等资源都是必要的。
如果资源不足,例如缺乏开发人员、缺乏设备、缺乏材料等,可能会导致项目失败。
以上是一些软件项目失败的案例,这些教训对于软件开发项目的成功非常重要。
失效分析案例
失效分析案例1：电浪涌导致器件失效
某产品在用户现场频频出现损坏，经过对返修单板进行分析，发现大部分返修单板均是某接口器件失效，对器件进行解剖后，在金相显微镜下观察，发现器件是由于EOS导致内部铝线融化，导致器件失效，该EOS能量较大。
进一步分析和该铝条相连的管脚电路应用，发现电路设计应用不当，没有采用保护电路，在用户现场带电插拔产生的电浪涌导致该器件失效。
通过模拟试验再现了失效现象。
解决方法：在用户手册中强调该产品不支持带电插拔。
预防措施：在今后的设计中，考虑用户的使用习惯，增加防护电路设计，对产品进行热插拔设计。
案例1
案例2：MSD控制不当导致产品在用户现场大量失效
某产品在用户现场使用半年以后，返修率惊人，达到30％，对产品进行分析，对主要失效器件进行失效分析，在扫描电镜下发现金属丝疲劳断裂导致器件失效。
进一步的原因分析，发现是该产品的生产加工控制出现了问题，对潮湿敏感器件的管理没有按照J-STD-033A 标准进行，导致受潮器件没有按照规定时间进行高温烘烤，在过回流焊时出现“爆米花”效应，对器件造成了损伤，降低了可靠性，导致在用户现场器件失效。
解决措施：对用户现场的所有有问题的批次产品进行召回。
预防措施：在生产加工过程中严格进行MSD的管理和控制。
案例2
案例3：电迁移
某产品在用户现场使用3年以后，返修率开始出现明显异常，进行失效分析发现，主要是某功率器件内部电迁移引起。
该问题属于器件厂家的设计和制造缺陷。
解决措施：和厂家联系，确定有问题的批次，更换有问题批次的器件。
预防措施：对器件可靠性认证体系重新进行设计，减少厂家批次性问题的发生。
案例3。
系统可靠性设计中的失效模式与影响分析实战案例分享(六)
系统可靠性设计中的失效模式与影响分析实战案例分享一、引言系统可靠性设计是工程领域中非常重要的一部分，它涉及到了产品的设计、制造、运营和维护等方方面面。
其中，失效模式与影响分析（FMEA）是一个关键的工具，可以帮助工程师在设计阶段识别潜在的失效模式，并评估这些失效对系统性能、安全性和可靠性的影响。
在本文中，将分享一个实际的案例，展示如何在实际项目中应用FMEA工具，以及其对系统可靠性设计的重要性。
二、案例描述某公司开发了一款新型工业机器人，用于自动化生产线上的装配工作。
在产品设计阶段，工程团队决定对机器人的控制系统进行FMEA分析，以确保其设计满足高可靠性和安全性的要求。
在整个分析过程中，团队共识别了三个主要的失效模式，并评估了它们的潜在影响。
失效模式一：电源故障在机器人运行过程中，由于电源供应不稳定或断电导致控制系统停止工作。
这种失效模式可能导致生产线停工，影响生产效率和产品质量。
失效模式二：传感器故障机器人控制系统依赖于多个传感器来感知周围环境和工件位置。
如果传感器出现故障，机器人可能无法准确执行任务，甚至导致碰撞或其他安全问题。
失效模式三：软件错误控制系统的软件是整个系统的核心，如果软件出现错误或漏洞，可能导致机器人行为异常，甚至对操作人员和周围设备造成危险。
三、FMEA分析在识别了上述失效模式后，工程团队进行了详细的FMEA分析，将每个失效模式的潜在影响进行了评估，并制定了相应的应对措施。
对于电源故障，团队首先对电源系统进行了设计优化，增加了备用电源和过载保护装置，以确保在电源故障时系统能够安全停机，并且可以快速恢复正常工作。
针对传感器故障，团队加强了对传感器的质量控制和故障检测，同时设计了备用传感器系统来保证在主要传感器故障时系统可以继续工作。
在软件方面，团队进行了严格的软件测试和验证，确保在发布前对所有可能的错误和漏洞进行了排查和修复。
四、实际效果通过FMEA分析和相应的设计改进措施，该公司最终成功开发出了一款高性能、高可靠性的工业机器人产品，并且在实际生产中取得了良好的效果。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
http://book.51cto.com/art/200909/151890.htm 失效案例简介 软件出现的问题有多种形式，会产生各种各样的后果。下面是一些例子。 受医用线性加速器的过度辐射，造成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通信公司很快发布了该软件的补丁，专门处理这一问题。对源程序作了广泛的测试之后发现，一个程序员对源程序中的三行代码作了修改，其中一行包含低级的打字错误，软件发布前，该段代码没有经过测试。