软件工程集成课件-涵盖所有内容.pptVIP

5点事实 （1） 软件生命周期中，一个错误发现得越晚，修复错误的费用越高 （2）许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来。 （3）在需求过程中会产生很多错误 Tom DeMarco（大西洋系统行会负责人）在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求规格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 （4）在需求阶段，代表性的错误为不正确的事实、疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。他们对海军A—7E—飞机上的”宅行操作程序进行实地测试，以验证许多新设想的可行性。得出的研究数据表明：A—7E项目中77％的需求错误特点是：不正确的事实，疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是： 49％不正确的事实，31％疏忽，l 3％不一致，5％二义性 （5）需求错误是可以被检查出来的 在需求过程中会产生很多错误(事实3和4)。 许多错误并没有在早期被发现(事实2)。 这样的一部分错误是能够在产生的初期被检查出来的(事实5)。 如果没有及时检查出来这些错误，软件费用会直线上升(事实1) 为什么说需求存在困难性 有几种主要原因使需求分析变得困难： （1）客户说不清楚需求； （2）需求自身经常变动； （3）分析人员或客户理解有误。 （4）业务的复杂性所导致的困难。 需求工程一般指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述出待开发系统及其行为特征和相关约束；通常是一些过程的集合：需求获取(需求引出)、需求分析和编写软件规格说明书(SRS)及验证(包括鉴定和证实)。 需求分析过程中涉及的人员 需求分析与程序分析的不同 需求分析的现状 需求分析的任务（原型系统的使用） 需求的表达 误解 交流障碍 缺乏共同语言 “完整性”问题 需求永远不会稳定 用户意见不统一 错误要求 认识混淆 可行性分析阶段已经粗略了解了用户的需求，甚至已经提出了一些可行的方案，但是，可行性研究的基本目的是用较小的成本在较短的时间内确定是否存在可行的方案。因此许多细节被忽略。 在系统开发前，还需要进一步确定 仍然回答“What”，而不是“How”， 但更细致、精确（合同的拟定） 开发原型系统(Prototyping) 在开发初期，要想得到一个完整准确的规格说明不是一件容易的事。特别是对一些大型的软件项目。 用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求。 软件开发者对于所要解决的应用问题认识更是模糊不清。 随着开发工作向前推进，用户可能会产生新的要求，或因环境变化，要求系统也能随之变化；开发者又可能在设计与实现的过程中遇到些没有预料到的实际困难，需要以改变需求来解脱困境。 因此规格说明难以完善、需求的变更、以及通信中的模糊和误解，都会成为软件开发顺利推进的障碍。 为了解决这些问题，逐渐形成了软件系统的快速原型的概念。 在软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。 探索型：目的是要弄清对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。 实验型：这种原型用于大规模开发和实现之前，考核方案是否合适，规格说明是否可靠。 进化型：这种原型的目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。 增进软件分析者和用户对系统服务需求的理解，使比较含糊的具有不确定性的软件需求明确化。 软件原型化方法提供了一种有力的学习手段。 使用原型化方法，可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。 需求说明语句 保持语句和段落的简短 采用主动语态的表达方式 编写具有正确的语法和标点的完整句子 使用的术语应该和词汇表中定义的一致 需求陈述应该具有一致的式样，例如“系统必须……”，或者“用户必须……”，并紧跟一个行为动作和可观察的结果，例如“仓库管理子系统必须现实一张在所请求的仓库中有存货的药品名单。” 为了减少不确定性，避免采用模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、必威体育精装版技术、优越的、可接受的和健壮的。 避免使用比较性的词汇，例如：提高，最大化，最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。 软件系统开发过程中必须考虑两方面的问题 “数据”及对数据的“处理” 为了把用户的