软件的发展

SoftwareModelingandAnalysisChapter2:RequirementsEngineering-----AnIntroductionEr-YuDing2007-11SoftwareInstituteofNJU软件的发展机器为中心应用为中心50's60's指令码、汇编语言BIOS批量事务处理、计算性工作3GL,OOLOS,VirtualMachine基本业务处理，应用处理SoftwareCrisisWhensoftwaregrowsfrommachine-centrictoapplicationcentric,softwarecrisishappened1968年北大西洋公约组织的计算机科学家在联邦德国召开的国际学术会议上第一次提出了“软件危机”(softwarecrisis)这个名词。软件危机指的是在计算机软件的开发和维护过程中所遇到的一系列严重问题开发成本超出预算，实际进度比预定计划一再拖延。用户对“已完成”系统不满意的现象经常发生。件产品的质量往往靠不住。Bug一大堆，Patch一个接一个。件的可维护程度非常之低。软件通常没有适当的文档资料。软件的成本不断提高。软件开发生产率的提高赶不上硬件的发展和人们需求的增长SoftwareEngineering概括来说，软件危机包含两方面问题：一、如何开发软件，以满足不断增长，日趋复杂的需求；二、如何维护数量不断膨胀的软件产品。SoftwareEngineeringisproposedtodealwithSoftwareCrisis[IEEEdefinition](1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)thestudyofapproachesasin(1).软件的发展机器为中心应用为中心企业为中心50's60's90's指令码、汇编语言BIOS批量事务处理、计算性工作3GL,OOLOS,VirtualMachine基本业务处理，应用处理4GL,CBDMiddlewareEAI,BPR,ERP,...StandishGroup1995Success,16.2%Challenged,52.7%Impaired,31.1%SuccessChallengedImpaired10018910022210061050100150200250费用时间功能预期值实际值365家公司的8380个项目SoftwareProblems大公司开发项目的平均成本是232.2万美元，中等公司是133.1万美元，小型公司是43.4万美元大约31％的项目在完成之前被取消，52.7％的项目成本是原来预算的189%大公司9%按预算交付，小公司16%按预算交付--------------------StandishGroup,1995StandishGroup1995成功项目的影响要素影响指数用户参与15.9％高层管理支持13.9％清晰的需求说明13.0％正确的项目计划9.6％切合实际的期望8.2％细化的项目里程碑7.7％员工能力7.2％主人翁精神5.3％清晰的目标和前景2.9％努力工作2.4％其他13.9％StandishGroup1995问题项目的影响要素影响指数缺少用户输入12.8％不完整的需求说明12.3％需求变化11.8％缺乏高层管理支持7.5％技术能力不足7.0％缺乏资源6.4％不切实际的期望5.9％目标不清晰5.3％不现实的时间要求4.3％新技术的影响3.7％其他23.0％StandishGroup1995失败项目的影响要素影响指数不完整的需求说明13.1％缺少用户输入12.4％缺乏资源10.6％不切实际的期望9.9％缺乏高层管理支持9.3％需求变化8.7％缺乏计划8.1％额外的无用功能7.5％缺乏IT管理6.2％技术能力不足4.3％其他9.9％StandishGroup1995需求因素用户参与（用户输入）高层管理支持清晰的需求说明切合实际的期望清晰的目标和前景需求变化额外的无用功能综合来看，需求因素对成功项目的影响指数为53.9％对问题项目的影响指数为55.6％对失败项目的影响指数为60.9％ESPITI，1996欧洲软件协会ESI欧洲软件过程改进培训计划项目ESPITI17个国家的超过3800个组织ConcreteexamplesoffailedprojectsPROMS（演出权益协会）,11M￡,1992,未能以常人能理解和检查的形式表述软件需求，软件规格说明也考虑不周RISP（西萨克斯地区信息系统计划）,43M￡,1990,缺少清晰的项目范围定义TAURUS(伦敦股票交易),75M￡(1.4B￡),1993,未能协调不一致的需求LASDS(伦敦救护车服务派遣系统),1992,社会服务领域糟糕的需求分析ATC(空中交通控制系统),1.8B￡,1998-2001,缺乏健壮的需求规格说明Peoplethinkrequirementsismaintroubles“Thereislittledoubtthatprojectrequirementsarethesinglebiggestcauseoftroubleonthesoftwareprojectfront.Studyafterstudyhasfoundthat,wherethereisafailure,requirementsproblemsareusuallyattheheartofthematter.”[GLAS98]'asmuchas90%ofsubsequenttroublescanbetracedbacktoerroneousoriginalspecifications.’[BRUC89]需求原因探究－－软件模拟性软件类别纯工具型软件应用型软件专业用户普通用户评判标准功能的复杂性使用的高效性技术的先进性功能的有用性使用的方便性技术的可行性功能的“模拟”性使用的方便性技术的可行性关注点创新性有效性模拟性示例系统编程环境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]需求原因探究－－技术因素非技术性和社会性因素组织机构文化、社会背景、商业目标、利益协商关注软件系统和现实之间的互动效应软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视解决方案和具体应用环境相关的不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商需求原因探究－－技术因素结构化分析和面向对象分析具有一定的先天缺陷编程－设计－分析设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以，它们在设计领域的应用也取得了成功但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实面向对象分析的问题对象的概念不同设计领域对象现实世界对象1.封住实体的属性和状态2.封住实体所能够提供的服务和操作3.继承以其作为成员之一的类的属性和服务1、代表现实世界中的某个实体2、封住实体的属性和状态3、封住实体所能够提供的服务和操作4、继承以其作为成员之一的类的属性和服务面向对象分析的问题对象的选择和运用不同设计的首要目的是构造高质量的软件需求分析的首要目的是理解现实，其次才是建立一个完整、一致的软件规格说明描述的角度不同设计描述的目的是说明“软件按照正确的方式工作”，即要求说明软件“做什么”（What）和“怎么做”（How）分析描述的目的是说明“软件做了正确的工作”，侧重于说明软件“做什么”（What）和“为什么做”（Why面向对象分析的问题描述的内容不同理解问题外部交互行为设计系统实现系统问题领域解决方案领域（软件系统）外部视图内部视图面向对象分析应用范围面向对象设计应用范围面向对象编程应用范围需求原因探究－－技术因素以“企业”为中心的软件反映了软件规模日益扩大一方面提高了需求处理中非技术性和社会性因素的影响比重另一方面也进一步放大了传统技术在需求处理阶段的不适应性需求原因探究－－技术因素需求错误的修复代价对比020406080100120140160180200需求设计编码编码测试验收测试运行代价So,REisneededandisveryimportantthemostcrucialactivity[INCE89]Themostimportant[phase]byfar[BRUC89]themostcriticalandproblem-pronearea[HOOP82]REisatthestart;-itformsthefoundations需求工程是软件工程的一个分支它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束同时它也关注以上因素和准确的软件行为规格说明之间的联系关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系需求工程基本活动需求工程需求开发需求管理需求获取需求分析需求规格说明需求验证需求工程与系统工程需求获取需求分析系统设计人力工程硬件工程软件工程系统集成系统测试需求产品需求阶段设计阶段编码阶段测试阶段系统需求开发软件需求开发需求工程需求工程与系统工程1981年，BarryBoehm[Boehm1981]发现项目费用的6％和时间的9-12％被消耗在需求阶段。在20年之后，随着需求工程的发展，[Hofmann2001]发现项目对需求工程的投入也加大了许多：项目工作的15.7％和时间的38.6％被用于进行需求工程NASA(U.S.NationalAeronauticsandSpaceAdministration)提供的数据显示[Young2002]：当在需求工程当中投入项目总成本的8-14％时，可以极大的降低项目的超支率。需求工程的必要性软件开发是这样一个工程问题利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的计算机应用于现实世界的广泛性新的问题和新的解决方案定义问题就是需求工程的任务需求工程的重要性FrederickBr