《《高级软件工程》PPT课件.ppt》由会员分享，可在线阅读，更多相关《《高级软件工程》PPT课件.ppt（296页珍藏版）》请在三一办公上搜索。
1、高级软件工程,Advanced Software Engineering,2,主要内容,一、软件工程概述二、软件需求三、软件设计四、检验和有效性验证方法五、软件进化六、软件项目管理七、Advanced Topics in Software Engineering,3,一、软件工程概述,软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容,4,1.什么是软件？,Software=program+data+documentCustom softwareGeneric software,Shrink-wrapped softwareEmbedded softwareSafety-cr
2、itical softwareCOTS（Commercial Off-the-shelf）I will create a software to update the database.(some software,a piece of software,a software system),5,软件的分类,可以按功能、规模、工作方式、可靠性高低等进行划分有关软件的词汇Custom softwareGeneric softwareEmbedded softwareSafety-critical softwareCOTS（Commercial Off-the-shelf）I will creat
3、e a software to update the database.(some software,a piece of software,a software system),6,2.什么是软件工程？,1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。Fritz Bauer在会议上首次提出“软件工程”概念。软件工程是一门研究如何用系统化、规范化、数量化等工程原则和方法进行软件开发和维护的学科。,7,Fritz Bauer:软件工程是为了经济地获得可靠的，能在实际的机器上高效运行的软件而建立和使用的科学的工程
4、原则。IEEE：软件工程是（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化思想应用于软件开发过程中，（2）上述方法的研究。软件工程的目标:低成本,高质量,按时交付,8,软件工程的本质特性,关注大型程序的构造软件工程的中心课题是控制复杂性软件需求不断变化旨在提高软件开发的效率团队合作是软件工程顺利实施的关键软件必须有效支持它的用户由一种文化背景的人替另一种文化背景的人创造产品,9,3.软件工程与计算机科学的区别,计算机科学研究的是构成计算机和软件系统基础的有关理论和方法，而软件工程则研究软件制作中的实际问题。理论上，所有软件工程都应该以计算机科学理论作为坚实的
5、基础，但对付实际的、复杂的问题时需要用软件工程的方法来解决。,10,4.软件工程与系统工程的区别,系统工程的产生比软件工程早。基于计算机的系统工程，研究由软件起主导作用的、有关负责系统的开发和进化的方方面面，包括硬件开发、系统决策、过程设计、系统实施和软件过程等。,11,5.什么是软件过程？,软件过程是指开发软件产品的一组活动及其结果。所有的软件过程都包含4项基本的活动：软件描述、软件开发、软件有效性验证和软件进化。不同的软件过程以不同的方式组织这4项活动，活动的结果会影响活动的进度。不同的机构可能用不同的过程来制作同一类产品。,12,过程定义的作用,一个过程定义了为达到确定的目标，需要什么人
6、在什么时间以何种方式做何种工作（Goal,Who,When,How,What）Process vs Music score对于 Customer,User,Developer,Manager，一个广泛适用的过程使得所有涉众更好地理解自己所扮演的角色、更清楚地知道自己及他人在什么时间做什么。促使过程的有机结合和改善，以获得“最好过程”。可以使公司内部的培训标准化。由于过程的可重复性，利于开发进度的安排，利于成本估算。,13,6.什么是软件过程模型？,模型与建模软件过程模型是从一特定的角度对软件过程的本质描述。软件过程模型包括构成软件过程的各种活动、软件产品以及所有涉众（stakeholder）,
7、14,从不同的角度对软件过程的描述，就得到不同的过程模型种类。如工作流模型、数据流或活动模型、角色/动作模型等。工作流模型：描述软件过程中各种活动的序列及其输入、输出和相互依赖型。其中的活动皆为人的活动。数据流或活动模型：把软件过程描述成一组活动，其中每个活动都完成一定的数据转换。该模型中的活动层次低于工作流模型。角色/动作模型：描述参与软件过程的不同角色及其所负责的活动。,15,通用模型或范型（Paradigm,Methodology）,Waterfall ModelThe Waterfall Model With Maintenance CircleThe Waterfall Model
8、With PrototypingThe Spiral Model（瀑布模型原型模型）The V ModelThe Phased Development ModelThe Incremental and Iterative ModelRUP,16,7.软件工程的成本及分布,软件成本分布取决于所采用的软件过程和所开发的软件类型。一般的成本分布：描述:设计:开发:集成与测试（15:25:20:40）需求极高的软件系统的集成与测试成本50%软件进化的成本软件维护的成本基于WEB的电子商务系统的成本模型,17,8.软件工程方法,结构化分析方法（DeMarco,1978,Yourdon E.和Consta
9、ntine L.等)JSD方法（Jackson,1983)OO方法(Booch,1994；Rumbaugh等,1991）,18,UML(Unified Modeling Language),1994，OO思想已经贯穿整个软件生存期，具有影响的OOA&D方法达50余种。UML是一种对软件密集型系统进行可视化、详述、构造和文档化的建模语言，主要用于分析和设计阶段的系统建模。,19,UML 2.0,1994Booch方法Rumbaugh OMT Coad/YourdonFire Smith 方法 Jacobson OOSE,1995.10发布Unified Method 0.8,1996.6发布UM
10、L 0.9不包含过程指导,Rational联合12家公司成立UML组织，形成UML 1.0，1997.1提交给OMG,1997.11.4，OMG采纳UML 1.1,2002发布UML 2.0,20,统一过程（RUP）,RUP的突出特点用况驱动（系统功能）以构架为中心（表现形式）迭代和增量开发（过程实施）,21,Tendency for Change when Using OO Paradigm(Jacobson et al.1995),22,9.什么是CASE？,Computer-Aided Software EngineeringCASE是支持软件工程实施的一系列工具的集合。低端CASE工具
11、支持实现和测试的工具高端CASE工具支持分析和设计的工具,23,10.优良软件的属性,功能属性非功能属性,24,11.软件工程所面临的主要问题,遗留系统的挑战多样性的挑战交付上的挑战,25,软件工程总体面临的困难与风险,复杂性与大量的细节（火星探测器的失败）技术的不确定性（技术的发展与开发人员对技术的理解程度都不同）由于交流障碍而引起的需求不确定性需求是持续变化的不断的修改所带来的错误使得软件退化人为和市场的风险软件费用、可靠性、生产率、重用问题难以解决,26,12.职业和道德上的责任,软件工程是应该具有良好的职业道德无论是否签署了保密协议都严格保守雇主或客户的机密。实事求是地表述自己的工作能
12、力，不接受超出自己能力的工作。应知晓控制专利权、著作权等知识产权使用的法律。避免计算机滥用。ACM,IEEE、英国计算机协会等组织颁布了职业行为准则和职业道德准则（只涉及基本的道德行为）,27,软件工程人员应当遵守的原则（IEEE/ACM,1999,节选）,公众感软件工程人员应始终与公众利益保持一致。客户和雇主软件工程人员应当在与公众利益保持一致的前提下，满足客户和雇主的最大利益。产品应保证其产品及其附件达到尽可能高的行业标准。判断力软件工程人员应具有公正和独立的职业判断力。管理软件工程管理者和领导者应拥护并倡导合乎道德的适合软件开发和维护的管理办法。职业感应弘扬职业正义感和荣誉感，尊重社会公
13、众利益。同事软件工程人员应公平对待和协助每位同事。自己软件工程人员应毕生学习专业知识，倡导合乎职业道德的职业活动方式。,28,一、软件工程概述,软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容,29,1.系统总体特性,功能特性非功能特性，如可靠性、安全性、保密性等。与系统总体可靠性紧密关联的3个方面：硬件可靠性软件可靠性（在第16、17章讨论）操作可靠性,30,2.系统及其环境,系统都是在一定的环境中存在的。系统环境必将影响系统的功能和性能。环境包含一系列相互作用的其它系统，有时，环境可能被看作是一个独立的系统。系统工程师一定要了解系统环境在许多情况下，系统的目的就是要改变
14、环境。一个系统的功能要受到环境变化的影响，这种影响可能很难估计。,31,3.系统建模,系统建模作为系统需求和设计活动的一部分，描述组成系统的组件以及组件之间的关系（系统体系结构）系统体系结构通常以方块图来描述。一个系统体系结构可以以功能为单位划分成子系统或功能组件，而不必关心由硬件还是软件实现。,32,功能组件可以分为六类：传感器组件：收集来自系统环境的信息。执行机构组件：引起一些系统环境的变化。计算组件：给定输入，执行计算并产生输出。通信组件：实现系统组件之间的彼此通信。调度组件：协调组件间的操作。接口组件：将一个组件中的表示转换成另一个组件中的表示。,33,4.系统工程过程,需求定义,系统
15、设计,组件开发,系统集成,系统安装,系统进化,系统退役,34,系统需求定义注重三种类型的需求：抽象的功能需求系统特性系统一定不能具有的性质系统设计所包括的活动有：分割需求（通常有多种分割方法，可以产生不同的方案）识别子系统为子系统分配需求（通常由于外购COTS子系统带来的限制而需要修改需求）描述子系统的功能定义子系统的接口,35,子系统开发所常见的问题:通常可以并行开发不同的子系统一些超出子系统范围的修改经常发生，但是对已经实现的硬件工程的修改往往带来非常昂贵的代价，这时修改往往落在软件上（软件的固有柔性，flexible），说明软件需求的变化更大更频繁。系统集成最好采取增量式过程，其理由是：
16、子系统的开发时间通常无法预计增量式集成可以减少错误定位的成本（错误定位可能引起不同子系统的承包商之间的争论，解决问题的谈判须花费时日）,36,5.系统采购,系统获得的过程包括选择最好的购买方式和最佳的供货商。在做出采购决策之前，一些相关的系统描述和体系结构设计必须完成，以便确定哪些子系统可以通过直接购买，而不必或避免重新开发。通常单个机构无法完成大型复杂系统所有组件的设计、制造和测试。此时，客户必须选择和确定主承包商和子承包商。,37,承包商与子承包商模型,38,一、软件工程概述,软件工程的基本概念基于计算机的系统工程软件过程软件项目管理的基本内容,39,1.软件过程模型,一个软件过程模型是软
17、件过程的一个抽象表示。一般使用过程模型区分或解释不同的软件开发方法。在实际的软件开发中，很少单独使用单一的过程模型，4类软件过程模型生命周期模型（瀑布模型）进化式开发模型形式化系统开发模型面向复用的开发模型,瀑布模型,瀑布模型（Waterfall Model）软件生存周期模型(Classic Life Cycle Model)线性顺序模型(Linear Sequential Model),41,瀑布模型的三个特点,阶段间具有顺序性和依赖性推迟实现的观点质量保证的观点,42,瀑布模型的优点,开发过程基本上是线性顺序的，便于管理基于“明确、完备的需求”，可以获得好的开发效果,Cost to cha
18、nge,After release,The impact of change,Definition,Development,1.56x,1x,60100 x,The Waterfall Model With Maintenance Circle,45,进化式开发模型,进化式开发的思想：基于最初的需求，先开发一个原型系统给用户使用，然后，根据用户的反馈意见不断地修改这个系统，直到形成最后成熟的软件产品。所强调的是，需求可以不断地被补充和完善。进化式开发有两类探索式开发：其目标式与用户一起工作，共同探索需求，直到最后交付系统。抛弃式原型：开发原型的目标是理解用户需求。,46,从工程学和管理学角度看
19、，进化式开发有三方面的问题：过程不可见系统结构通常较差快速原型工具和技术往往与主流的工具和技术不相容实际使用的过程模型通常是混合模型The Waterfall Model With PrototypingThe V ModelThe Phased Development ModelThe Incremental and Iterative ModelThe Spiral Model,The Waterfall Model With Prototyping,运行、维护,需求分析,概要设计,详细设计,编码,单元集成测试,验收测试,系统测试,Validate Requirements,Verify
20、Design,The V Model,The Phased Development Model,Build Release 2,Build Release 1,Build Release 3,Time,Production system,Development system,Developers,Users,The Incremental and Iterative Model,Incremental Development,Iterative Development,51,增量开发的优点,能在较短的时间内向用户提交可以完成主要功能的产品逐步增加产品的功能，使用户有充裕的时间学习和适应新产品，
21、减少一个全新的产品给客户组织带来的冲击,The Spiral Model,53,螺旋模型的优点,有利于已有软件的重用有助于把软件质量作为软件开发的一个重要目标减少了过多测试或测试不足所带来的风险软件维护与软件开发没有本质区别,54,形式化系统开发,形式化开发模型类似于瀑布模型，但是软件需求描述被精练成一个用数学符号表达的详细的精确的形式化描述。需求描述经过一系列的变换过程，最终形成可执行程序。净室过程(Cleanroom，最初有IBM开发，增量式形式化开发和验证)，一个形式化开发成功应用的例子。,Operational Specification Model,Transformational
22、Model,57,面向复用的开发,面向复用的开发依赖于可以存取的可复用组件集成这些组件的框架面向复用的开发过程需求描述组件分析需求修改使用复用的系统设计开发和集成系统有效性验证,58,2.软件描述,可行性研究需求导出和分析需求描述需求有效性验证,59,3.软件设计与实现,体系结构设计子系统的抽象描述（如包图）接口设计组件设计数据结构设计算法设计,60,4.软件有效性验证,单元测试功能模块测试子系统测试系统测试验收测试（如测试，测试）,61,5.软件进化,软件进化，即软件在其生命周期内不断地随着需求的变更而变更的过程。软件系统的柔性决定了软件进化的现实避免昂贵的硬件修改软件进化亦存在一些问题软件
23、进化可以看作是软件开发过程和软件维护过程的统一。,62,6.自动化的过程支持,计算机辅助软件工程（CASE）有两个因素限制了CASE工具的使用软件工程本质上是一个富有创造力的设计活动，已经存在的CASE能使一些常规活动自动化，但尝试用人工智能技术代替人的创造性活动远未成功。软件过程强调的是团队活动以及涉众者之间的交流，在此，CASE也不能提高更多的支持。,63,CASE分类(Fuggetta,1993),64,CASE工具的功能分类,65,一、软件工程概述,软件工程的基本概念基于计算机的系统工程软件过程软件项目管理,66,软件项目管理要点,软件项目管理是必要的。软件项目管理与其它的工程管理有明
24、显的区别。软件项目管理者需要承担多种不同的任务，其中最重要的活动是项目规划、估算和进度控制。项目里程碑是一个项目活动可以预期的结果，到达一个里程碑就要把项目进展报告提交到管理层。为了有效控制项目进度，可以借助于各种各样的图表跟踪、表示项目进度。应识别和评估重大的项目风险，判断这些风险发生的可能性和后果。,67,1.管理活动,管理活动包括：人员管理软件成本估算质量管理过程改善软件配置管理,68,2.项目规划,项目规划的实质是项目管理者必须预测可能出现的问题，并准备有效的解决办法。项目规划的主要内容是制定项目计划、质量计划、有效性验证计划、配置管理计划、维护计划、人员培训计划等,69,3.项目调度
25、,项目管理者要估算完成各项活动所需的时间和资源，并按照一定的顺序把它们严密地组织起来。具体活动包括：识别活动（任务）识别活动依赖关系估算活动的资源为活动分配人员创建项目图表（条形图和活动网络图）,70,4.风险管理,识别风险并制定计划，以最大限度地降低风险对项目的影响，这种活动叫做风险管理。（Hall,1998）三类风险产品风险：影响所开发软件产品的质量和性能的风险。项目风险：影响项目进度或项目资源的风险。业务风险：影响软件开发机构或产品购买机构的风险。风险管理过程风险识别风险分析风险规划风险监控,71,可能出现的软件风险,72,风险分析,73,风险因素分析,74,风险管理策略,75,高级软件
26、工程,一、软件工程概述二、软件需求工程三、软件设计四、检验和有效性验证方法五、软件进化六、软件项目管理七、Advanced Topics in Software Engineering,76,需求工程,软件需求（第5章）需求工程过程（第6章）需求建模（第7章）软件原型系统开发（第8章）形式化描述（第9章）,77,本章要回答的主要问题,什么是用户需求、系统需求？这些需求应使用不同的方法表示？功能需求和非功能需求之间的不同？描述系统需求的两种技术？在需求文档中如何组织需求内容？,78,1.用户需求、系统需求与软件设计描述,需求是对系统应该提供的服务和所受约束的描述。由于需求要向不同类型的涉众（读者
27、）传达不同层次的信息，可以将需求分为：用户需求(目标需求)用用户所熟悉的表达形式所给出的需求描述。系统需求（产品需求）详细地给出系统将提供的服务以及系统所受到的约束，比用户需求更具体，更形式化。软件设计描述(设计层需求)，在系统需求描述的基础上再加入更加详细的需求细节。,79,用户需求与系统需求示例,80,不同层次的需求示例,R1.预算误差应在5之内R2.产品应支持费用注册，以及根据经验数据报价R3.产品应具有记录、检索经验数据的功能R4.系统的屏幕图像应如附件xx所示,目标层需求,域层需求,产品层需求,目标需求,81,用自然语言描述的用户需求可能描述不够清楚（二义性、含糊不清、自相矛盾等）需
28、求混乱（功能需求、非功能需求、系统目标和设计信息无法清晰地区分）需求混合（多个不同的需求交织在一起，以一个需求的形式给出）系统需求描述可能包括许多不同的模型，如对象模型、数据流模型等,82,原则上讲，系统需求仅仅描述做什么，而不应该描述如何实现。然而，要给出细节上的需求而不提到任何设计信息，事实上也是不可能的：通常系统需求依照构成系统的各个子系统结构来给出，即由初始的系统体系结构来构造需求描述；通常目标系统和现存系统户操作，这就约束了目标系统的设计，同时这些约束又构成了新系统的需求；某些特别的设计（如N-版本设计）是系统的一个外部需求。,83,系统需求描述工具,84,2.功能需求与非功能需求,
29、另一种需求层次的划分领域需求（业务需求）用户需求功能需求非功能需求业务需求（Business Requirement）反映了组织机构或客户对系统、产品高层次的目标要求反映目标系统所处领域的特点在项目视图与范围文档中予以说明,85,用户需求（User Requirement）用户使用产品必须要完成的任务在使用用例文档或方案脚本说明中予以说明功能需求（Function,Behavioral Requirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求对系统应该提供的服务、如何对输入做出发应以及系统在特定条件下的行为的描述。涉及与本系统有接口的其他系统的所有
30、事情。可能需要明确声明系统不应该做什么。,86,非功能需求(Non_Requirement)对系统提供的服务或功能给出的约束，包括性能指标、对质量属性（quality attribute)的描述、外部接口以及设计与实现的约束（constraint）、时间约束、标准等。非功能需求最好是可以验证的，但实际上对需求量化通常很难。非功能需求与功能需求有时会发生冲突。非功能需求之间会发生冲突。,87,非功能需求分类,88,业务需求,用户需求,质量属性,外部接口,系统要求,约束,功能需求,项目视图和范围文档,使用实例文档,需求规格说明,业务需求,软件需求各组成部分之间的关系,89,功能需求示例(大学图书馆
31、系统),？功能需求以不同的详细程度重写（需求1和3）？含糊的表达，“适当的浏览器”,90,容易忽略的非琐碎要求（示例）,R1：根据客房类型而不是客房号进行预订R2：考虑到预订客房的客户有可能不入住，可以接受超过空闲客房数量的预订R3：授权的系统管理员可以自己定义电费的分类单价R4：,91,3.软件需求文档,SRS(Software Requirement specification)Heninger对软件需求文档提出的6点要求：应该只描述系统外部行为应该定义实现上的约束应该是容易变更的应该成为系统维护人员的参考工具应该记录系统的整个说明周期应该对未料到的事件给出可接受的反应,92,需求文档结构
32、(IEEE标准见第78页),引言：问题定义所确定的目标和范围术语：定义文档中的技术术语数据描述：数据流图，数据字典等等功能描述：功能要求文档（可形式化描述）性能描述：性能要求文档质量保证：描述交付前需要进行的各种测试和验收标准其它：运行要求、将来可能的要求附件索引,93,需求工程,软件需求（第5章）需求工程过程（第6章）需求建模（第7章）软件原型系统开发（第8章）形式化描述（第9章）,94,本章要回答的主要问题,需求工程活动及其之间的关系需求导出和分析的一些技术需求有效性验证和需求评审为什么说需求管理是必须的，它如何支持其它的需求工程活动,95,1.基本概念,需求工程是对服务和约束的发现、分析
33、、描述和检验的过程。需求工程的4个高层通用过程：可行性研究需求导出和分析需求描述和文档编写需求有效性验证,96,需求分析的涉众,合同监督人员，提出里程碑（Milestones）和约束系统开发进度的计划需求者：客户(Customer)和使用者(User)。开发者项目管理者，必须理解建立和使用目标系统所可能产生的后果。系统分析员，分析阶段活动的主体。设计员，依据需求提出可接受的解决方案。测试员，确保软件系统满足每一需求。,97,系统分析员应具有的素质,综合能力总体规划，抽象和分解，本质确认的能力过程能力保证整个过程的善始善终的能力交流能力理解和表达能力技术水平了解问题域和描述解空间的能力,98,应
34、该足够重视需求分析,软件项目中40%60%的缺陷都是由需求分析阶段的过失所致（Daivs 1993，Leffingwell 1997）对欧洲软件行业的大规模调查显示：确定和管理用户需求是问题最多的两个环节（ESPITI 1995）许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当信息收集方式不正规没有明确提出想要的功能常常存在未经沟通的错误假设需求的定义不够充分未经仔细考虑进行需求变更,99,2.可行性研究,可行性研究的焦点问题包括系统是否符合机构的总体目标？系统是否能在现有条件和预算内按时完成？目标系统能与已经存在的其它系统集成？软件可行性研究的任务技术可行性经济可行性社会可行
35、性操作可行性,100,可行性研究是高层的分析和设计,101,可行性研究报告,（1）引言（2）可行性研究前提（3）对现有系统的分析（4）所建议系统的技术可行性分析（5）所建议系统的经济可行性分析（6）社会因素可行性分析（7）其它可供选择方案（8）结论意见,102,3.需求导出和分析,通过对现实环境的研究，获得系统具体模型。去掉具体模型的非本质因素，抽取出当前系统的逻辑模型分析当前系统和目标系统的差别，建立目标系统的逻辑模型。对目标系统进行完善和补充，写出完整的需求分析。,a,b,c,d,103,104,学生在学校教材科购买教材的系统的例子,一、通过对现实环境的研究，获得系统具体物理模型,购书发票
36、,购书单,书,购书证明,购书申请,学生,学生,李保管,孙出纳,钱会计,赵秘书,105,学生在学校教材科购买教材的系统的例子,二、去掉具体模型的非本质因素，抽取出当前系统的逻辑模型,发票,购书单,书,有效单,购书单,学生,学生,发书,开领书单,开发票,有效性,106,学生在学校教材科购买教材的系统的例子,三、分析当前系统和目标系统的差别，建立目标系统的逻辑模型。,发票,购书单,书,购书单,学生,学生,发书,开领书单,审查并开发票,107,学生在学校教材科购买教材的系统的例子,四、对目标系统进行完善和补充，写出完整的需求说明。五、对需求说明进行复审，直到确认文档齐全并符合用户的全部需求为止。,无效
37、书单,发票,购书单,购书单,学生,学生,开领书单,审查并开发票,108,需求阶段所要获取的主要内容,物理环境(Physical Environment)接口(Interfaces)用户或人的因素(Factors)功能(Functionality)文档(Documentation)数据(Data)资源(Resources)安全性(Security)质量保证(Quality Assurance),109,设备的主要用途，在哪里发挥什么作用？所须设置的设备的多少？环境限制等，如温度、湿度或磁声干扰？,1）物理环境描述(Physical Environment),110,来自一个或多个其他系统的输入？
38、对一个或多个其它系统的输出？数据是否必须预先进行规定的格式化处理？数据是否需要预先存放的介质？,2）接口描述（Interface Description）,111,谁使用系统？有几种类型的用户？每种类型用户的技术水平怎样？对每型用户需要什么样的培训？用户理解、使用系统的难易度怎样？用户误用系统的困难程度怎样？,3）用户和人为因素,112,系统将做什么？系统将在何时做？有几种操作方式？系统能在何时、怎样被改变或增强？对执行速度，响应时间或数据流量有何限制和约束？,4）功能描述（Function Description）,113,5）文档（Documents）,需要多少文档？是联机文档还是静态文档
39、或者二者皆可？文档所面向的对象（读者）？,114,6）数据（Data）,I/O数据格式应该是什么样的？数据收或发的频度？数据的精确度系统流经的数据流量？数据必须在何时予以保存，保存多久？,115,7）资源描述（Resource Description）,建立和维护系统都要什么材料、人员或其他资源？开发者必须具有哪些技术？系统占用多少物理空间？对开发规定了时间表了？对用于开发或软硬件上的资金有限制？,116,对系统或信息的存取必须在我们的控制之下？不同用户的数据之间将如何实现隔离？不同用户程序之间，以及和操作系统间怎样隔离？系统如何备份？备份副本必须被存于一个不同的位置？应采取措施防火，防水防盗
40、等安全措施？,8）安全描述(Security),117,系统必须有效检测并隔离故障？平均无故障时间规定为多少？对一次失败后重启系统有一个最大时间？系统如何将变化合并到设计？维护仅仅是纠正错误，还是包括改进系统？对资源和响应时间使用什么样的有效度量？系统移植性、可维护性等要求？如何向别人示范系统的特征？,9）质量保证(Quality Assurance),118,对需求说明书的要求,正确性无二义性（需求确实是用户所需吗？）完整性（完备性，包括用户需要的每一功能或性能）一致性（需求之间不能互相矛盾）可检验性（非计算机人员可以理解）可实现性（有效性，需求是能够现实的吗？硬件系统的支持力度怎样？）可修
41、改性可跟踪性注释,119,4.需求规约的验证(1),验证是为了确保需求说明准确、完整地表达必要的质量特点审查需求文档以需求为依据编写测试用例写出黑盒功能测试用例编写用户手册要用浅显易懂的语言描述出所有对用户可见的功能确定合格的标准,120,需求规约的验证(2),验证的方法复审和进一步需求分析实现原型系统支持需求分析工具验证的主要内容一致性验证现实性验证（需求是现实的吗？）完整性（完备性）和有效性验证,121,5.需求管理,需求管理是对需求变更了解和控制的过程。需求管理的任务是“与客户就软件需求达成并保持一致”（Paulk 1995）持久的需求与易变的需求一个变更管理过程由三个阶段问题分析和变更
42、描述变更分析和成本计算变更实现,122,需求管理活动,需求管理活动包括：定义需求基线审查变更请求，评估可能产生的影响以决定是否批准以可控的方式将批准的变更融入项目中保持项目计划与需求的同步基于对需求变更影响的估计协商新的需求约定跟踪每项需求（找到对应的设计、代码和测试用例）在项目的开发过程中始终跟踪需求的状态和变更,123,需求变更,需求开发与需求管理的分界,分析、记录审阅、协商,需求变更过程,市场营销 客户 管理层,需求开发,需求管理,市场营销客户管理层,项目变更,项目环境,124,对项目需求状况作出快速评估（1）,项目前景（vision)和范围(scope)未曾明确定义客户太忙，没时间与需
43、求分析和开发人员一起讨论需求用户代理（如开发经理、用户负责人、营销人员等）自诩可以代表用户，其实不能准确说出用户的要求需求只存在于那些所谓专家的脑子里，没有被记录下来客户坚持所有需求都很重要，不愿排出它们的优先次序开发人员在编码过程中发现需求有歧义，缺少足够的信息，只能去猜测,125,对项目需求状况作出快速评估（2）,开发人员与客户沟通时只关心用户界面，忽略了用户需要用软件做什么客户签字确认了需求却又一直提出修改要求项目范围因接受需求变更而扩大，却没有相应地增加投入或剪裁功能，进度因而被延误需求变更的请求被弄丢，开发人员和客户都不了解所有变更请求的状态开发人员按照客户要求实现的功能无人问津需求
44、规格说明中的要求都实现了客户却不满意,126,需求工程,软件需求（第5章）需求工程过程（第6章）需求建模（第7章）软件原型系统开发（第8章）形式化描述（第9章）,127,本章要回答的主要问题,系统上下文建模的重要性行为建模、数据建模和对象建模UML用于不同类型的系统模型CASE工作平台是如何支持系统建模的,128,3.系统模型,模型是系统的抽象视图，它忽略了系统中的所有细节。从不同的角度（外部、行为或结构）表达系统，形成不同类型的模型：上下文模型、行为模型、结构模型。上下文模型（系统环境模型）表达系统在整个环境中与其它系统和过程的位置关系。如用例图模型是一种上下文模型。状态机模型用来描述系统的
45、行为，以响应内部和外部的事件。它是一种行为模型。结构模型包括体系结构模型和数据结构模型。,129,数据流模型用来描述数据是怎样一步步在处理序列中流动的，它不仅可以描述系统内的处理过程（行为），也能够有效地描述系统的上下文。E-R模型是一种最广泛使用的数据结构模型。对象建模在一定程度上是结构建模和行为建模的结合。UML已经被OMG认定为对象建模标准。,130,How to Express Requirements,Static descriptionsDynamic descriptionsObject-oriented specificationFormal Methods,131,1）Sta
46、tic Descriptions,数据流图、数据字典、加工说明等判定表（Decision Tables）判定树E-R模型层次方框图、Warnier图、IPO图UML中类图、包图,132,Warnier Diagrams,Softwareproducts,System,Application,OS(n1)Compiler(n2)Software Tool,Editor(n3)Test driver(n4)CAD tool(n5),133,IPO Diagrams,134,E-R模型（Entity-Relationship),概念模型（E-R图）逻辑模型（二维表的定义）物理模型（存储空间的定义，如
47、定义各个字段的大小）数据库的设计一般应经过由概念模型到逻辑模型，再到物理模型的映射过程。,135,数据结构的规范化,1970年，IBM的E.F.Godd提出关系模型，由二维表表示。按照属性间的依赖程度区分关系规范化的程度，由范式（Normal Form)来表示。1NF：表中不能有表（每个信息项必须是一个不可分割的数据项）2NF：非主属性由关键字唯一确定3NF：任何非主属性间不存在函数依赖，即非主属性相互独立。,136,Decision Tables,137,2）Dynamic Descriptions,Functional Descriptions and Transition Diagram
48、s Event TablesPetri Nets,138,Functional Descriptions,State i,State k,Condition j,139,Transition Diagrams,S i,S k,Event or Condition X,状态迁移图是描述系统的状态如何响应外部的信号进行推移的一种图形表示。圆圈“”表示可得到的系统状态 箭头“”表示从一种状态向另一种状态的迁移。,140,t1 中断事件t2 中断已处理t3 分配CPUt4 用完CPU时间,当有多个申请占用CPU运行的进程时,有关CPU分配的进程的状态迁移,141,可得到的状态就绪，运行，等待生成的事件
49、t1，t2，t3，t4 t1 中断事件，t2 中断已处理 t3 分配CPU，t4 用完CPU时间,142,状态迁移图的优点,状态之间的关系能够直观地捕捉到由于状态迁移图的单纯性，能够机械地分析许多情况，可很容易地建立分析工具,143,Fence Diagram showing State Transitions(Hotel reservations),(Null),Requested,On waiting list,Confirmed,Used,Canceled,Archive,144,Use UML to Represent OO,OMG(Object Management Group)ha
50、ve adopted UML as the OO notational standard.UML can be used to visualize,specify,or document a problem.UML can be used throughout the software development process.,145,UML由两大部分的组成,UML语义描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供简单、一致和通用的定义性说明，使开发者在语义上取得一致，消除了因人而异的表达方法所造成的影响。UML还支持对元模型的扩展定义。,146,UML表示法定义U
