11-401-高级软件工程-第3章-软件分析与建模

第3章软件分析与建模软件的需求问题——什么做，什么不做需求之难用户需求描述项目经理的理解系统分析员设计程序员编码商业顾问的诠释项目文档编写安装程序如此简洁投资者的投入肤浅的技术支持实际需求。。。需求有三难雾里看花——需求说不清客户对需求只有朦胧的感觉隔靴搔痒——需求说不准分析人员或客户理解有误刻舟求剑——需求说不全“等闲变却故人心，却道故人心易变”，需求自身经常变动90年代的软件生产状况调查——StandishGroup1995Success,16.2%Challenged,52.7%Impaired,31.1%10018910022210061050100150200250费用时间功能预期值实际值365家公司的8380个项目成功项目Success：在预计的时间之内，在预算的成本之下，完成预期的所有功能问题项目Challenged：已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全失败项目Impaired：因无法进行而被中途撤销，或者最终产品无法提交使用90年代的软件生产状况调查——StandishGroup1995大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元大约31％的项目在完成之前被取消，52.7％的项目成本是原来预算的189%大公司9%按预算交付，小公司16%按预算交付90年代的软件生产状况调查——影响因素[StandishGroup1995]成功项目的影响要素影响指数用户参与15.9％高层管理支持13.9％清晰的需求说明13.0％正确的项目计划9.6％切合实际的期望8.2％细化的项目里程碑7.7％员工能力7.2％主人翁精神5.3％清晰的目标和前景2.9％努力工作2.4％其他13.9％90年代的软件生产状况调查——影响因素[StandishGroup1995]问题项目的影响要素影响指数缺少用户输入12.8％不完整的需求说明12.3％需求变化11.8％缺乏高层管理支持7.5％技术能力不足7.0％缺乏资源6.4％不切实际的期望5.9％目标不清晰5.3％不现实的时间要求4.3％新技术的影响3.7％其他23.0％90年代的软件生产状况调查——影响因素[StandishGroup1995]失败项目的影响要素影响指数不完整的需求说明13.1％缺少用户输入12.4％缺乏资源10.6％不切实际的期望9.9％缺乏高层管理支持9.3％需求变化8.7％缺乏计划8.1％额外的无用功能7.5％缺乏IT管理6.2％技术能力不足4.3％其他9.9％90年代的软件生产状况调查——影响因素[StandishGroup1995]需求因素用户参与（用户输入）高层管理支持清晰的需求说明切合实际的期望清晰的目标和前景需求变化额外的无用功能综合来看，需求因素对成功项目的影响指数为53.9％对问题项目的影响指数为55.6％对失败项目的影响指数为60.9％90年代的软件生产状况调查——ESPITI，1996欧洲软件协会ESI欧洲软件过程改进培训计划项目ESPITI17个国家的超过3800个组织0102030405060需求规格说明文档需求管理文档制作软件测试项目管理编码%主要问题次要问题不是问题90年代的软件生产状况调查——需求问题的典型案例[Bray2002]PROMS（演出权益协会）,11M￡,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周RISP（西萨克斯地区信息系统计划）,43M￡,1990,缺少清晰的项目范围定义TAURUS(伦敦股票交易),75M￡(1.4B￡),1993,未能协调不一致的需求LASDS(伦敦救护车服务派遣系统),1992,社会服务领域糟糕的需求分析ATC(空中交通控制系统),1.8B￡,1998-2001,缺乏健壮的需求规格说明需求问题的原因分析应用软件模拟特性：软件的三种类型软件类别纯工具型软件应用型软件专业用户普通用户评判标准功能的复杂性使用的高效性技术的先进性功能的有用性使用的方便性技术的可行性功能的“模拟”性使用的方便性技术的可行性关注点创新性有效性模拟性示例系统编程环境DBMSOffice语言翻译MISEAI应用软件的模拟特性：软件的分析活动创新：1）观念创新2）技术创新功能分析：有用性设计、实现与集成发布设计、实现与集成发布现实分析：目的、问题领域知识设计、实现与集成移交功能分析：“模拟”性A)面向专业用户的工具型软件B)面向普通用户的工具型软件C)应用型软件功能分析应用软件的模拟特性：软件模拟性的实践调查对应用型软件的“模拟”特性理解及应用问题CapersJones[Capers1996]在调查了几百个公司之后发现超过75％的企业在需求处理环节存在不足。2000年Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现[Nikula2000]：在以30分为标准线的情况下，75%的公司竟然在10分以下。Hofmann等人在欧洲的需求工程实践调查中发现仅有约1/3的项目有明确的需求处理过程[Hofmann2001]。Juristo等人在对欧洲的150多名RE实践者进行调查后发现，在需求处理的诸多技术当中，需求获取和冲突协商的技术没有得到充分的应用[Juristo2002]。研究也发现当软件生产面临时间、市场等其他压力时，漠视“模拟”特性的情况就更为严重[Lubars1993，Francisco2003]需求问题的技术原因分析非技术性和社会性因素组织机构文化、社会背景、商业目标、利益协商关注软件系统和现实之间的互动效应软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视解决方案和具体应用环境相关的不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商需求问题的技术原因分析结构化分析和面向对象分析具有一定的先天缺陷编程－设计－分析设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实需求问题的技术原因分析以“企业”为中心的软件反映了软件规模日益扩大一方面提高了需求处理中非技术性和社会性因素的影响比重另一方面也进一步放大了传统技术在需求处理阶段的不适应性需求问题的技术原因分析需求错误的高代价性020406080100120140160180200需求设计编码编码测试验收测试运行代价软件需求工程问题域与解系统软件系统现实世界环境接口解系统现实世界接口问题域共享现象问题域解系统共享现象现实世界需求的涵义需求是用户对问题域当中的实体状态或事件的期望描述R2.2.3-1：一旦书籍被借出，则在归还之前，它不能被再次借阅。R2.2.3-2：在归还的书超过30天的归还期限时，归还后应该进行超期处罚。直接需求间接需求问题域解系统共享现象现实世界需求规格说明规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征，主要包括两个部分：（1）对共享现象（模型）的描述；（2）系统对共享现象所施加的操作的描述。也可以看作是一种需求完全针对系统行为发出的期望一种理想的、完全不需要进行任何额外努力即可以转换为系统行为的需求。解系统共享现象现实世界软件问题域问题域解系统共享现象现实世界规格说明问题域特性问题域自治的规律性称为问题域特性包括结构特性和行为特性等问题域特性的重要性要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来要防止解系统的引入在问题域当中引发未预见的连锁反应需要关注的问题域特性间接特性约束和假设从问题域、需求和规格说明的关系看需求工程描述明确的问题域特性E;定义良好的系统行为S;预期的需求R需求工程的目的就是根据E，构建S，使得需求工程的困难之处：（1）不存在描述明确的E；（2）不存在确定的针对S的评估标准R；（3）是一个创造性的过程。需求工程的主要工作需求开发,确定R研究问题背景，描述问题域特性E构建解系统，描述解系统行为S，使得RSE,SRE⇒,RSE,认识软件需求工程的艰巨性软件需求是软件工程中最复杂的过程之一应用领域的广泛性，它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏，及其与功能性需求有着错综复杂的联系，大大增加了需求工程的复杂性。沟通上的困难，由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景，给需求工程的实施增加了人为的难度。什么是软件需求？（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。需求工程系统目标系统服务软件约束运行环境什么是需求工程？需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。提供用户在现实世界的需要和软件能力之间的桥梁。软件需求工程三个活动组成的系统化过程：通过一个迭代合作的问题分析过程开发需求用各种形式的表示格式将所得到的观察文档化检查所获得的理解的准确性要解决的问题……开发需求……的系统化过程在这个过程刚开始的时候存在很多未知因素的情况下，这个过程怎样才能是系统化的？当我们并不知道需要多少步或者当什么时候可以结束还不清楚的时候，我们怎么能采取步进的方法？要解决的问题……通过一个迭代合作的分析问题的过程…需要多少次迭代？我们怎么知道已经采集了‘足够’多的需求？‘足够’是什么意思？‘合作’涉及人与人的合作，那谁将会被这个过程涉及呢？他们怎样相互沟通？他们将就这个过程达成什么样的协议？用户应该是主动参与者吗？他们应该被牵扯进决策过程中吗？还是他们仅仅只作为信息源？要解决的问题……用各种形式的表示形式将所得到的观察文档化……应该采用什么表示形式？结果应该怎样文档化？应该采用什么标准和哪种表示法？为什么？要解决的问题……检查所获得的理解的准确性我们怎样才知道这个过程完成了？需求需要有多准确？这里的“准确”是什么意思？参与需求工程的每个人都将具有相同的理解吗？软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出软件需求内容系统需求功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么领域需求是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束非功能需求产品需求机构需求外部需求互操作需求道德需求立法需求性能需求空间需求交付需求实现需求标准需求隐私需求安全性需求可用性需求效率需求可靠性需求可移植性需求需求开发的层次性业务需求指导需求获取业务需求用户需求转化用户需求为系统需求系统需求目标任务系统行为业务需求用户需求系统需求需求工程过程和基本活动需求抽取需求分析和协商需求文档化需求有效性验证用户需要，领域信息，存在系统信息，规定条例，标准，等需求文档系统规格说明一致同意的需求需求获取需求分析需求规格说明需求验证系统环境涉众硬数据需求基线需求跟踪信息变更控制项目活动当前基线修订的基线项目当前状态项目进展需求变化系统开发需求开发需求管理需求工程与系统工程需求获取需求分析系统设计人力工程硬件工程软件工程系统集成系统测试需求产品需求阶段设计阶段编码阶段测试阶段系统需求开发软件需求开发需求工程需求获取(requirementelici