软件工程课件

1第1章

软件工程概述内容1.0软件概念1.1软件危机1.2软件工程1.3软件生命周期1.4软件过程1.0软件概念软件软件的特点软件发展历程软件概念-软件软件（

Software）是计算机系统中与硬件相互依存的另一部分，它是包括程序（Program）

，数据（Data）及其相关文档（Document）的完整集合。Software=Program+Data+Document程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料软件概念-软件的特点抽象性软件是逻辑实体，没有明显的制造过程，运行和使用没有磨损与老化问题。依存性软件开发和运行依赖于计算机系统。工艺性软件开发至今尚未完全摆脱手工工艺的开发方式。复杂性软件逻辑结构、开发技术、项目管理复杂。成本高开发成本、维护成本高。风险大软件项目的成功率低。维护难维护不能依靠原开发者，理解软件代码难，维护也是开发，维护成本高软件工作涉及各种社会因素政策规章、管理思想、文化背景、信息素养、技术水平、系统接口等。软件的复杂性逻辑复杂软件的逻辑结构非常复杂开发复杂成本难以估算、进度难以控制、人员素质要求、质量得不到保证成本高例：软件成本风险大1995年美国Standish咨询集团的统计分析(至90年代初的软件项目执行情况)成功：16.2%失败：31％受到挑战：53.8%近几年来的统计数据成功：26％失败：28％受到挑战：46%维护难维护形式多样化改正性：修改故障完善性：增加功能适应性：移植维护成本越来越高55%到70％维护带来的问题可能引发新的错误，经维护后逻辑结构更复杂1.1软件危机软件危机软件发展历程，软件危机，软件危机的表现。产生软件危机的原因软件特点有关，开发中的问题，维护中的问题。消除软件危机的途径正确认识“软件”，重视软件过程，采用有效的软件开发技术和方法，引进工程管理方法。软件发展历程早期面向批处理有限的分布自定义软件第二阶段多用户实时数据库软件产品第三阶段分布式系统嵌入“智能”低成本硬件消费者的影响第四阶段强大的桌面系统面向对象技术专家系统人工神经网络并行计算网路计算机1950196019701980199020001968年10月，北大西洋公约组织（NATO）的科学家在德国召开的学术会议上正式提出了软件危机问题。软件危机软件危机是计算机软件开发和维护过程中所遇到的一系列严重问题。主要包括下列两个方面的问题：如何开发软件，以满足对软件的日益增长的需求；如何维护不断增多的已有软件。软件危机的典型表现对软件开发成本和进度的估计常常很不准确；用户对交付的软件经常不满意；软件产品的质量往往达不到要求；开发出来的软件通常难以维护；软件产品文档资料不适用和不完善；软件成本在整个系统总成本中所占比例逐年上升；软件开发生产率的提高不能满足对软件需求的增长；………成本问题计算机软件和硬件费用比越来越大IBM360OS,5000多人年，耗时4年(1963－1966)，花费2亿多美元美国空军：1955年软件占总费用(计算机系统)的18%，70年60%，85年达到85％美国全球军事指挥控制系统，硬件1亿美元，软件高达7.2亿美元软件质量问题软件应用面的扩大：科学计算、军事、航空航天、工业控制、企业管理、办公、家庭软件越来越多的应用于安全攸关的系统，对软件质量提出更高的要求80年代欧洲亚丽安娜火箭的发射失败，原因是软件错误美国阿托拉斯火箭的发射失败，原因是软件故障软件的复杂性越来越高英国1986年开发的办公室信息系统Folios经4年，因性能达不到要求，1989年取消日本第5代机因为软件问题在投入50亿美元后于1993年下马由于软件质量问题导致失败的软件项目非常多项目进度问题项目进度难以控制项目延期比比皆是由于进度问题而取消的软件项目较常见只有一小部分的项目能够按期完成软件维护问题软件维护非常困难软件维护的多样性软件维护的复杂性软件维护的副作用产生软件危机的原因与软件本身的特点有关成本高、风险大、难于维护、逻辑复杂。软件是计算机系统中的逻辑实体而不是物理实体，软件生产与硬件不同，在它的开发过程中没有明显的制造过程。软件是通过人们的智力活动，把知识与技术转化成信息的一种产品。在软件的运行过程中，没有“用坏”的问题。软件维护意味着修正原来的设计，较为困难。与软件开发与维护的方法不正确有关软件专业人员对软件开发和维护存在糊涂观念，在实践过程中采用了错误的方法和技术。如忽视软件需求分析的重要性；轻视软件维护。消除软件危机的途径正确认识“软件”软件≠程序，软件是相关程序、数据及文档的集合。正确认识“软件开发”软件开发不是个体劳动，而主要是一种有组织的团队活动。研究软件开发的技术手段在软件开发中使用已证明行之有效的技术，研究和探索新的技术。更好地使用软件工具，建立一个良好的软件工程支撑环境。研究软件开发的管理方法在软件开发中使用已证明行之有效的工程管理方法。组织良好、管理严密，使各类人员协同配合，共同完成软件开发的工程项目。软件工程学的是由于“软件危机”的出现和加重而产生的，研究用工程的方法来管理软件的开发。开发一个具有一定规模和复杂性的软件系统与编写一个简单的程序不一样。大型、复杂软件系统的开发是一项工程，必须按照工程化的方法组织软件的生产和管理，必须经过分析、设计、实现、测试、维护等一系列软件过程和活动软件工程学的产生提出有效的方法和工具支持软件开发1968年提出软件工程概念和思想20世纪70年代的结构化软件开发方法20世纪80年代的面向对象的软件开发方法新的技术:软件重用、快速原型、需求工程典型技术:COM,Java,C++,J2EE,.Net,….支撑工具和环境：Jbuilder,VisualStudio,WebLogic,…解决危机的技术途径20世纪80年代末，美国DoD和业界开始认识到管理的重要性美国DoD的一项研究表明，70%的项目由于管理不善导致难以控制进步、成本和质量；进一步的研究发现：管理是影响软件项目成功开发的全局性因素，而技术只影响局部如果软件开发组织不能对软件项目进行有效管理，就不能充分发挥软件开发方法和工具的潜力，也就不能高效率地开发出高质量的软件产品解决危机的管理途径1.2软件工程软件工程的概念软件工程的基本原理软件工程方法学软件工程概念软件工程是指导计算机软件开发与维护的一门工程学科。采用工程的概念、原理、方法和技术来开发和维护软件。将经过时间和实践考验而证明正确的管理方法和最好的技术手段结合起来，经济有效地开发和维护软件。软件工程是一门不断发展的学科。软件工程定义(FritzBauer,1968)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

软件工程就是建立和使用一套合理的工程原理，从而经济地获得可靠的、可以在实际机器上高效运行的软件。软件工程定义(IEEE,1990)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1990.）

软件工程是：（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；（2）研究（1）中提到的途径。软件工程定义(CMU/SEI,1990)

Engineeringisthe

systematicapplicationofscientificknowledge

increatingandbuildingcost-effectivesolutionstopracticalproblemsintheserviceofmankind.

Softwareengineeringisthat

formofengineering

thatappliestheprinciplesofcomputerscienceandmathematics

toachievingcost-effectivesolutionstosoftwareproblems.SEIsoftwareengineeringdefinitionfrom1990SEIReportonUndergraduateSoftwareEngineeringEducation(CMU/SEI-90-TR-003):软件工程定义软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它采用经过实践验证的工程的原则、方法，以提高质量，降低成本为目的。软件工程的本质特性关注于大型程序的构造控制软件复杂性适应软件的经常变化性提高软件开发的效率和谐合作开发软件使软件有效地支持它的用户需求软件是有一种文化背景的人为另一种文化背景的人开发的产品。软件工程的基本原理用分阶段的生命周期计划严格管理坚持进行阶段评审实行严格的产品控制采用现代程序设计技术结果应能清楚地审查开发小组的人员应该少而精承认不断改进软件工程实践的必要性软件工程包括技术和管理两方面的内容，是技术与管理紧密结合所形成的工程学科。通常把在软件生命周期全过程中使用的一整套技术方法的集合称为软件工程方法学(methodology)，也称为范型(paradigm)。软件工程方法学软件工程方法学三要素软件工程方法学包含3个要素：方法、工具和过程。方法完成软件开发各项任务的技术方法。工具为运用方法而提供的软件工程支撑环境（支撑分析、设计、开发等）。过程规定了完成软件开发各项任务的工作步骤。传统软件工程方法学传统软件工程方法学是生命周期方法学软件生命周期一个软件定义、开发、使用和维护，直到最终被废弃，要经历的漫长的时期，称为软件的生命周期。生命周期方法学这种方法学把软件生命周期的全过程依次划分为若干个阶段，然后顺序地完成每个阶段的任务。2面向对象方法学面向对象主要概念对象、类、继承、消息等。面向对象方法学这种方法学把数据和行为看成同等重要，它是一种以数据为主线，把数据和对数据的操作紧密结合起来的方法1.3软件生命周期软件生命周期概念软件生命周期模型软件生命周期各阶段任务常见的软件工程方法学（几大公司）软件生命周期概念软件生命周期基本阶段软件生命周期由软件定义、软件开发和软件维护三个时期组成，每个时期又可划分若干个阶段。生命周期方法学软件工程采用的生命周期方法学就是从时间角度对软件开发和维护的复杂性进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段都有独立的任务，然后逐步完成每个阶段的任务。划分软件生存周期阶段的基本原则使各阶段的任务之间尽可能相互独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂程序，简化不同阶段之间的联系，有利于软件开发工程的组织管理。1.4软件生命周期模型

问题定义软件定义可行性研究

需求分析

总体设计软件生命周期软件开发 详细设计

编码和单元测试（实现）

综合测试 运行维护

软件维护软件生命周期基本阶段的任务（1）软件定义时期总目标的确定，可行性，采用策略，系统功能，所需资源与成本，工程进度表，也称为系统分析时期，分为所定义，可行性研究和需求分析。（2）开发时期具体设计和实现前面所定义的软件。分为：总体设计，详细设计，编码和单元测试，综合测试。（3）维护时期使软件尽量地满足用户需要，纠错，适应新环境，满足新需求软件生命周期的阶段1.问题定义要解决的问题是什么？2.可行性研究问题能够解决吗？3.需求分析为了解决问题需要做什么？4.总体设计为了解决问题，大概怎样做？5.详细设计为了解决问题，具体怎样做？6.编码和单元测试编程实现，并测试每一个程序模块，验证程序达到设计要求。7.综合测试集成测试、压力测试、验收测试，验证系统满足需求。8.软件维护改正性维护、适应性维护、完善性维护、预防性维护，保障系统持久性满足用户的要求。问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护要解决的问题是什么？问题性质、工程目标和规模的报告分析员：实际用户+负责人是否有解决办法？分析员高层逻辑模型，准确和具体的工程规模和目标，成本/效益分析等可行性报告为了解决的问题，目标系统必须做什么？准确确定系统的功能系统的逻辑模型（数据流图+数据字典+简要算法）如何解决这些问题模块划分软件结构如何具体地实现系统：每个模块的流程图（程序的详细规格说明）通过各种类型的测试，使软件达到预定的要求写出正确的容易理解和容易维护的程序模块通过各种必要的维护活动使系统持久地满足用户的需要软件生命周期的各阶段任务软件工程层次模型软件工程：一种层次化模型质量关注点过程方法工具

软件工程层次图软件工程三个要素：工具、方法、过程基础层，综合方法及工具，定义方法使用的顺序，所需要的管理为软件开发提供“如何做”的技术为软件开发提供自动或半自动的软件支撑环境，建立计算机辅助软件工程(CASE)的软件开发支撑系统软件工程扩展模型软件工程方法学例ALM（ApplicationLifecycleManagement，应用生命周期管理）MSF（MicrosoftSolutionFramework，微软方案框架)RUP（RationalUnifiedProcess，统一软件过程

）OOA/OOD/OOPOOA

(Object-OrientedAnalysis面向对象分析)分析师拿到所有来自客户的需求了；了解需求，分析需求、技术实现等，分析出来一个方案，即项目需求。分析师们分析结果出来后，形成了最早的需求模型，包括可行性报告、需求分析报告、系统模型、草图等。OOD(ObjectOrientedDesign面向对象设计)设计师们拿到需求模型进行细化，模块化，定义所有的细节，设计软件的详图，这里就是详细的需求分析规格书和具体的设计文档。OOP(ObjectOrientedProgramming面象对象程序设计)程序员按照设计图的要求完成项目的实际操作部分，在项目里就是coding的工作和testing的工作。1.4软件过程软件过程是为了获得高质量的软件需要完成的一系列任务的框架，规定了完成各项任务的工作步骤。AprocessdefinesWhoisdoingWhat,When,andHow,inordertoreachacertaingoal.软件过程定义了软件工程的阶段、应用方法的顺序、应交付的文档、保证软件质量的措施、标志软件开发各阶段的里程碑。软件过程框架模型软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。工作任务里程碑、交付物SQA(软件质量保障)点公共过程框架辅助活动框架活动任务集合软件过程模型软件生命周期的每一阶段都有明确的任务，把规模大、结构复杂、管理复杂的软件开发变得容易控制和管理。各个阶段的活动如何衔接，开发过程中采用什么样的策略，应遵守什么样的规定和制约，将这些活动框架（忽略不必要的细节）用一种模型表示出来，称为软件过程模型（或软件开发模型或软件生命周期模型）。软件过程模型是软件开发全部过程、活动和任务的结构框架。常用软件过程模型（1）瀑布模型(WaterfallModel）（2）快速原型模型(RapidPrototypeModel)（3）增量模型(IncrementalModel)（4）螺旋模型(SpiralModel)（5）面向对象模型（喷泉模型、可重用组件模型）（6）统一软件开发过程（IBMRUP）（7）敏捷(灵活)过程与极限编程（8）微软过程（MicrosoftSolutionFramework）（1）瀑布模型(WaterfallModel)传统瀑布模型评审评审评审评审评审瀑布模型问题定义可行性研究需求分析总体设计详细设计编码与单元测试综合测试软件维护软件定义时期软件开发时期软件维护时期瀑布模型的特点阶段间具有顺序性和依赖性提供了软件过程模型的基本框架,强调了每一阶段活动的严格顺序。前一阶段产品（文档）驱动下一阶段的工作。推迟实现的观点程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。质量保证的观点每一个阶段必须完成规定的文档；以评审确认阶段工作，即上一阶段的结束，下一阶段的开始。传统瀑布模型存在什么问题？改进的瀑布模型及时反馈：开发时尽早知道上一阶段的错误。维护分类：根据软件维护的内容和程度，确定维护的阶段。评审评审评审评审评审反馈反馈反馈反馈软件维护瀑布模型的优缺点瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。“瀑布模型是由文档驱动的”，这个事实是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成。（2）快速原型模型

(RapidPrototypeModel)在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。建造/修改原型

听取用户意见用户测试运行原型原型实现范型快速原型模型快速原型法是一种新型的软件开发方法，它使用交互的，快速建立起来的原型取代了形式的、僵硬的大量的规格说明，用户通过在计算机上实际运行和试用原型系统而向开发者提供真实的反馈意见。建立原型系统修改原型符合用户需要的应用系统用户试用反馈意见快速原型模型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程采用不带反馈的瀑布模型，进行快速开发和修改。原型系统提交用户评测，反复修改，直到用户满意。原型模型存在的问题⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。

⑶开发过程不便于管理。有效的使用原型模式建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。3）增量模型(IncrementalModel)是一种渐进地开发逐步完善的软件版本的模型。需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户需求分析一步到位；功能模块作为增量逐步交付。增量模型分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2增量3增量4交付交付交付交付●●●●●反复地应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。早期的版本实现用户的基本需求，并提供给用户评估的平台。需求作为增量逐步交付。增量模型的优点在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。采用增量模型比采用瀑布模型和快速原型模型需要更精心的设计，但在设计阶段多付出的劳动将在维护阶段获得回报。增量模型的困难在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。此外，必须把软件的体系结构设计得便于按这种方式进行扩充，向现有产品中加入新构件的过程必须简单、方便，也就是说，软件体系结构必须是开放的。开发人员既要把软件系统看作整体。又要看成可独立的构件，产生观念上的矛盾。多个构件并行开发，具有集成的风险。4）螺旋模型(SpiralModel)软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件越复杂，承担该项目所冒的风险也越大。

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来，加入了风险分析。在该模型中，软件开发是一系列的增量发布，早期的迭代中，发布的增量可能是一个纸上的模型或原型，在以后的迭代中，逐步产生系统更加完善的版本。螺旋模型的基本思想是降低风险。简单的螺旋模型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证风险分析风险分析风险分析风险分析风险分析风险分析可看作在每个阶段之前都增加了风险分析过程的快速原型模型。每一个阶段都可能存在不同的风险！完整的螺旋模型原型版本当前进度

螺旋模型风险分析工程实施用户交流用户评估产品维护项目产品增强项目新产品开发项目概念开发项目计划建造及发布螺旋模型的优点和特点螺旋模型的优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标减少了过多测试或测试不足维护和开发之间并没有本质区别螺旋模型的特点风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大主要适用于内部开发的大规模软件项目，随着过程的进展演化，开发者和用户能够更好的识别和对待每一个演化级别上的风险随着迭代次数的增加，工作量加大，软件开发成本增加（5-1）面向对象-喷泉模型喷泉模型(FountainModel)是面向对象模型。主要用于支持面向对象开发过程，体现了软件创建所固有的迭代和无间隙的特征分析设计实现测试集成演化（5-2）面向对象-构件集成模型

(ComponentIntegrationModel)

构件（components)也称为组件，是一段实现一系列有确定接口的程序体，具有自己的功能和逻辑，能同其他构件集成起来协调工作。该模型（又称为可重用部件组装模型）支持软件重用（Reusability）

，对缩短软件开发周期、降低项目成本有重要的现实意义。同时，建造符合某应用领域体系结构标准的构件，可以用来搭建分布式的、跨越不同操作平台(集成化软件开发环境（ISEE）)的软件，扩展了软件的应用前景，促进了软件标准化、商品化的发展。在此基础上专家们又提出了“基于构件的软件工程”(CBSE)。构件集成模型

构件集成模型软件体系结构被建立后，必须用构件去充实，这些构件可从复用库中获得，或者根据专门需要而开发。整个过程可以演化地进行，面向对象方法给予技术上的支持。构件集成模型Sommerville提出基于组件开发有两种思路：完成高层设计，对设计中的组件给出描述，以便找出可复用的组件，这些组件可在体系结构层次上加入或更详细的设计层次上加入。先根据需求搜寻可复用组件，再将设计建立在获得的组件基础上。这两种思路可结合起来。设计系统体系结构描述组件搜寻可复用组件集成系统先完成架构设计的复用系统需求描述搜寻可复用组件对需求作某些修改体系结构设计集成系统复用驱动设计构件技术主要有三种流行标准对象管理组织OMG的CORBA微软的COM/DCOMSUN的EJB(EnterpriseJavaBean)OMG的CORBA对象管理组织OMG发布的公用对象请求代理体系结构(CommonObjectRequestBrokerArchitecture)。通过一个对象请求代理（ORB)提供一系列服务，使得一个构件和其他构件通信，而不管它们在系统中的位置，实现了远程对象通过接口进行通信的机制。为了解决CORBA对象引用不透明、缺少多重接口、系统过于复杂等问题，专家们又开发了新一代面向对象中间件平台ICE（InternetCommunicationsEngine—互联网通信引擎）。使构建分布式应用系统更容易、性能和伸缩性更好。微软的COM/DCOMCOM微软提出、开发的构件对象模型（ComponentObjectModel)，它提供了运行于windows之上的单个应用系统使用不同厂商生产的构件的规约。DOM基于分布式环境下的COM称为DCOM(DistributeCOM)。SUN的EJB(EnterpriseJavaBean)随着Java在企业级应用的地位日趋重要，Sun提出了一个统一的企业级Java平台—J2EE（Java2EnterpriseEdition）。在J2EE中，EJB负责最核心的业务处理。它为服务器端的应用程序提供了一种与厂商无关的Java接口，让任何符合EJB规范的构件都可以运行在每一台这样的服务器上。（6）统一软件开发过程统一软件开发过程（RationalUnifiedProcess，RUP)是由Rational公司的Booch、Jacobson、Rumbaugh提出的软件过程模型。RUP重复一系列周期，每个周期由一个交付给用户的产品结束。每个周期划分为初始、细化、构造和移交四个阶段，每个阶段围绕着五个核心工作流（需求、分析、设计、实现、测试）分别迭代。RUP的“最佳实践”软件开发经验迭代式开发按照原型模型，迭代开发产品，获取用户的反馈意见，加深对需求的理解，逐步趋向最终产品。管理需求人为需求分析是一个连续过程，使用有效的方法（如用例和脚本）捕获用户变化的需求，以驱动设计与实现。使用基于构建的体系结构提供使用现有构建和新开发构件定义体系结构的方法，采用构建来建造系统，从而减低软件复杂性，提供软件重用率。可视化建模采用可视化建模语言（UML）描述系统模型。验证软件质量建立贯穿整个开发过程的、全员参与的软件质量评估方法。控制软件变更控制、跟踪和监控软件的修改，确保迭代开发的成功。RUP软件开发生命周期RUP初始阶段：进行问题定义，确定目标，评估其可行性，降低关键风险。细化阶段：制定项目计划、配置各类资源、建立系统架构（包括各类视图）。构造阶段：开发整个产品，并确保产品可移交给用户。移交阶段：产品发布、安装、用户培训。在每个阶段的每次迭代的最后，用例模型、分析模型、设计模型、实现模型都会增量，每个阶段结束的里程碑处，管理层做出是否继续、进度、预算、是否给下一阶段提供资助等决定。不同阶段工作流的侧重点不同，前两阶段大部分工作集中在需求、分析和架构设计上；在构造阶段，重点转移到详细设计、实现和测试上。（7）敏捷过程与极限编程2001年，为了解决许多公司的软件团队陷入不断增长的过程泥潭，一批业界著名专家一起概括出了一些可以让软件开发团队具有快速工作、响应变化能力的价值观和原则，他们称自己为敏捷联盟。敏捷开发过程的方法很多，主要有：SCRUM，Crystal,特征驱动软件开发（FeatureDrivenDevelopment，简称FDD），自适应软件开发(AdaptiveSoftwareDevelopment，简称ASD)，以及最重要的极限编程(eXtremeProgramming,简称XP)。极限编程(XP)是于1998年由Smalltalk社群中的大师级人物KentBeck首先倡导的。观点在按照我的理解方式审查了软件开发的生命周期后，我得出一个结论：实际上满足工程设计标准的惟一软件文档，就是源代码清单。--JackReeves设计和编程都是人的活动。忘记这一点，将会失去一切。--BjarneStroustrup敏捷过程敏捷软件开发宣言个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到的文档客户合作 胜过 合同谈判响应变化 胜过 遵循计划敏捷宣言遵循的原则我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。工作的软件是首要的进度度量标准。敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。不断地关注优秀的技能和好的设计会增强敏捷能力。简单是最根本的。最好的构架、需求和设计出于自组织团队。每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。敏捷过程认为的软件设计“坏味道”僵化性很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其它改动。脆弱性对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。牢固性很难解开系统的纠结，使之成为一些可在其他系统中重用的组件。粘滞性做正确的事情比做错误的事情要困难。不必要的复杂性设计中包含有不具任何直接好处的基础结构。不必要的重复性设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。晦涩性很难阅读、理解。没有很好地表现出意图。敏捷开发避免“软件腐化味”的

面向对象的设计原则单一职责原则(SRP)：一个类应该仅有一个引起它变化的原因。开放-封闭原则(OCP)：软件实体应该是可以扩展的，但是不可修改。Liskov替换原则(LSP)：子类型必须能够替换掉它们的基类型。依赖倒置原则(DIP)：抽象不应该依赖于细节。细节应该依赖于抽象。接口隔离原则(ISP)：不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。重用发布等价原则(REP)：重用的粒度就是发布的粒度。共同封闭原则(CCP)：包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包中的所有类产生影响，而对于其他的包不造成任何影响。共同重用原则(CRP)：一个包中的所有类应该是共同重用的。如果重用了包中的一个类，那么就要重用包中的所有类。无环依赖原则(ADP)：在包的依赖关系图中不允许存在环。稳定依赖原则(SDP)：朝着稳定的方向进行依赖。稳定抽象原则(SAP)：包的抽象程度应该和其稳定程度一致。极限编程极限编程(eXtremeProgramming，XP)是敏捷过程中最有名的一个,适于小型项目。极限编程对于传统的软件工程中看来是“极端的”实践.极限编程的有效实践1、完整团队XP项目的所有参与者（开发人员、客户、测试人员等）一起工作在一个开放的场所中，他们是同一个团队的成员。这个场所的墙壁上随意悬挂着大幅的、显著的图表以及其他一些显示他们进度的东西。2、计划游戏计划是持续的、循序渐进的。每2周，开发人员就为下2周估算候选特性的成本，而客户则根据成本和商务价值来选择要实现的特性。3、客户测试作为选择每个所期望的特性的一部分，客户可以根据脚本语言来定义出自动验收测试来表明该特性可以工作。4、简单设计团队保持设计恰好和当前的系统功能相匹配。它通过了所有的测试，不包含任何重复，表达出了编写者想表达的所有东西，并且包含尽可能少的代码。5、结对编程所有的产品软件都是由两个程序员、并排坐在一起在同一台机器上构建的。6、测试驱动开发编写单元测试是一个验证行为，更是一个设计行为。同样，它更是一种编写文档的行为。编写单元测试避免了相当数量的反馈循环，尤其是功功能能验证方面的反馈循环。程序员以非常短的循环周期工作，他们先增加一个失败的测试，然后使之通过。极限编程的有效实践7、改进设计随时利用重构方法改进已经腐化的代码，保持代码尽可能的干净、具有表达力。8、持续集成团队总是使系统完整地被集成。一个人拆入（Checkin）后，其它所有人责任代码集成。9、集体代码所有权任何结对的程序员都可以在任何时候改进任何代码。没有程序员对任何一个特定的模块或技术单独负责，每个人都可以参与任何其它方面的开发。10、编码标准系统中所有的代码看起来就好像是被单独一人编写的。11、隐喻将整个系统联系在一起的全局视图；它是系统的未来影像，是它使得所有单独模块的位置和外观变得明显直观。如果模块的外观与整个隐喻不符，那么你就知道该模块是错误的。12、可持续的速度团队只有持久才有获胜的希望。他们以能够长期维持的速度努力工作，他们保存精力，他们把项目看作是马拉松长跑，而不是全速短跑。XP项目的整体开发过程XP迭代开发过程XPvaluesCommunicationSimplicityFeedbackCourageRespect（8）微软过程Microsoft解决方案框架(MSF)是一种成熟的、系统的技术项目方法，它基于一套制定好的原理、模型、准则、概念、指南，以及来自Microsoft的、经过检验的做法。MSF提供了一个灵活的和可伸缩的框架，其适应能力能够满足任何项目（不论其规模和复杂性）的要求，以规划、构建和部署业务驱动的技术解决方案。MSF的观点是，没有哪个单一的结构或者过程能够适应所有项目的环境和要求。尽管如此，但是它也认为：对指导的需求是存在的。作为一个框架，MSF就提供了这样一种指导，而不会强迫实施很多限制性的细节，否则这只会将其用处限制到有限范围的项目方案里。微软软件生命周期阶段划分和主要里程碑微软过程的生命周期模型95/27内容摘要基于计算机的系统系统工程的任务可行性分析96/27内容摘要基于计算机的系统系统工程的任务可行性分析97/27

所谓基于计算机的系统是指：通过处理信息来完成某些预定义目标而组织在一起的元素的集合或排列。组成基于计算机系统的元素主要有：软件、硬件、人员、数据库、文档和规程（Procedure）基于计算机的系统98/27系统元素软件—指计算机程序、数据结构和相关的工作产品，以实现所需要的逻辑方法、规程或控制硬件—指提供计算能力的电子设备、支持数据流的互连设备（如网络交换器、电信设备）和提供外部世界功能的电子机械设备（如传感器、马达等）人员—指硬件和软件的用户和操作者99/27数据库—指通过软件访问并持久存储的大型的有组织的信息集合。文档—指描绘系统的使用和/或操作的描述性信息（如模型、规格说明、硬复制手册、联机帮助文件、Web站点）。规程（procedures）—指定义每个系统元素的特定使用或系统所处的过程性语境的步骤。100/27系统的层次结构基于计算机的系统本身可以成为一个更大的基于计算机系统中的一个元素，称其为那个更大系统的宏元素。这样，基于计算机的系统可呈现一个层次结构。101/27工厂自动化

系统102/27内容摘要基于计算机的系统系统工程的任务可行性分析103/27计算机系统工程计算机系统工程是一个问题求解的活动，其目的是分析基于计算机的系统的功能、性能等要求，并把它们分配到基于计算机系统的各个系统元素中，确定它们的约束条件和接口。

104/27系统工程的任务识别用户的要求标识系统的功能和性能范围，确定系统的功能、性能、约束和接口。105/27系统建模和模拟通常可考虑建立如下模型：硬件系统模型：描述基于计算机系统中的硬件（包括计算机、受系统控制的其它硬件设备等）配置、通信协议、拓扑结构、以及确保基于计算机系统的安全性、可靠性、性能等要求的措施。软件系统模型：描述各软件子系统的功能、性能等要求，它们在硬件系统中的部署情况，以及软件子系统之间的交互。人机接口模型：描述人如何与基于计算机的系统进行交互，包括用户环境、用户的活动、人机交互的语法和语义等。数据模型：描述基于计算机的系统使用了哪些数据库管理系统，如果使用多个数据库管理系统，还应描述它们之间的数据转换方式，必要时可给出主要的数据结构。106/27系统模型通常可用图形描述，并加以相应的文字说明。必要时，在系统建模后可构造原型，进行系统模拟，以分析所建的模型能否满足整个基于计算机的系统的要求。107/27成本估算及进度安排对将开发的基于计算机的系统进行成本估算，并作出进度安排。可行性分析从经济、技术、法律等方面分析所给出的解决方案是否可行，通常只有当解决方案可行并有一定的经济效益和/或社会效益时才开始真正的基于计算机的系统的开发。生成系统规格说明108/27内容摘要基于计算机的系统系统工程的任务可行性分析109/27可行性分析开发一个基于计算机的系统通常都受到资源（人力、财力、设备等）和时间上的限制，可行性分析主要从经济、技术、法律等方面分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。110/27经济可行性分析经济可行性主要进行成本效益分析，从经济角度，确定系统是否值得开发。基于计算机的系统的成本主要包括：购置硬件、软件（如数据库管理系统、第三方开发的构件等）和设备（如传感器等）的费用系统的开发费用系统安装、运行和维护费用人员培训费用111/27效益经济效益包括使用基于计算机的系统后可增加的收入和可节省的运行费用（如操作人员数、工作时间、消耗的物资等）。在进行成本效益分析时通常只统计五年内的经济效益。社会效益指使用基于计算机的系统后对社会产生的影响（如提高了办事效益，使用户满意等），通常社会效益只能定性地估计。经济效益通常可用货币的时间价值、投资回收期和纯收入来度量。112/27货币的时间价值设：当前金额为P，年利率为i，n年后的金额为F，则计算时，累计经济效益应折合成当前金额例如，一个基于计算机的系统使用后，每年产生的经济效益为10万，如果年利率为5%，那么，五年内该系统的累计经济效益是43．2948万，而不是50万。113/27投资回收期：累计的经济效益正好等于投资数（成本）所需的时间。纯收入：累计经济效益–

投资数当纯收入大于零时，该工程值得投资开发当纯收入小于零时，该工程不值得投资（除非它有明显的社会效益）当纯收入等于零时，通常也不值得投资显然，纯收入越大越好。114/27技术可行性分析技术可行性主要根据系统的功能、性能、约束条件等，分析在现有资源和技术条件下系统能否实现。技术可行性分析通常包括风险分析、资源分析和技术分析。115/27风险分析：分析在给定的约束条件下设计和实现系统的风险。采用不成熟的技术可能造成技术风险人员流动可能给项目带来风险成本和人员估算不合理造成的预算风险风险分析的目的是找出风险，评价风险的大小，并有效地控制和缓解风险。116/27资源分析：论证是否具备系统开发所需的各类人员、软件、硬件等资源和相应的工作环境。例如，有一支开发过类似项目的开发和管理的团队，或者开发人员比较熟悉系统所处的领域，并有足够的人员保证，所需的硬件和支撑软件能通过合法的手段获取，那么从技术角度看，可以认为具备设计和实现系统的条件。117/27技术分析：分析当前的科学技术是否支持系统开发的各项活动。在技术分析过程中，分析员收集系统的性能、可靠性、可维护性和生产率方面的信息，分析实现系统功能、性能所需的技术、方法、算法或过程，从技术角度分析可能存在的风险，以及这些技术问题对成本的影响。技术可行性分析时通常需进行系统建模，必要时可建造原型和进行系统模拟118/27法律可行性分析研究系统开发过程中可能涉及到的合同、侵权、责任以及各种与法律相抵触的问题。1990年我国颁布了《中华人民共和国著作权法》，其中将计算机软件作为著作权法的保护对象。1991年国务院颁布了《计算机软件保护条例》。这两个法律文件是法律可行性分析的主要依据。119/27方案的选择和折衷一个基于计算机的系统可以有多个可行的实现方案，每个方案对成本、时间、人员、技术、设备都有不同的要求，不同方案开发出来的系统在功能、性能方面也会有所不同。因此要在多个可行的实现方案中作出选择。方案评估的依据是待开发系统的功能、性能、成本、开发时间、采用的技术、设备、风险以及对开发人员的要求等。由于系统的功能和性能受到多种因素的影响，某些因素之间相互关联和制约。如，为达到高的精度就可能导致长的执行时间，为达到高可靠性就会导致高的成本等等。因此，在必要时应进行折衷。120/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理121/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理122/42AlanDavis把需求工程定义为“直到（但不包括）把软件分解为实际架构构件之前的所有活动”

HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证…

…123/42本书将软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。124/42需求获取系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。需求获取的工作产品为进行需求分析提供了基础125/42需求分析与协商

需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题：用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求126/42系统建模

建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。127/42需求规约软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。128/42需求验证作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。129/42在实际的开发过程中，获取、分析、建模、编写规约和验证这些需求开发活动不会是线性地、顺序地完成。实际上，这些活动是交叉的、递增的和反复的。130/42需求管理需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。131/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理132/42软件需求包括功能需求性能需求用户或人的因素环境需求界面需求文档需求数据需求资源使用需求安全保密要求可靠性需求软件成本消耗与开发进度需求其他非功能性要求

133/42需求获取方法与策略建立顺畅的通信途径访谈与调查观察用户操作流程组成联合小组用况（UseCase）134/42建立顺畅的通信途径建立分析所需要的通信途径，以保证能顺利地对问题进行分析。135/42访谈与调查在具体的实践中，通常采用折衷的方法，即适当地计划好面谈，但不要过于详细，允许有一定的灵活性。一般按照如下原则进行准备：所提问的问题应该循序渐进，从整体的方面开始提问，接下来的问题应有助于对前面的问题更好的理解和细化；不要限制用户对问题的回答，这有可能会引出原先没有注意的问题；提问和回答在汇总后应能够反映用户需求的全貌。136/42例子：“赛艇比赛成绩计算系统”的第一次面谈的准备计划初次与Dartchurch航行俱乐部的航行秘书（DR）接触，面谈有关事宜。(在电话交谈时，了解到他们希望得到的是一个“价廉”的，基于PC的系统，以用于计算赛艇比赛成绩)时间：2005-6-5地点：对方场地主要问题确定基本问题。确定DR的角色――还涉及其它人员吗？调查财物方面事宜。系统（大致上）是如何运作的？当前存在的问题是什么？他们都希望做些什么？137/42观察用户操作流程到用户的实际工作环境中对用户的工作流程进行观察，了解用户实际的操作环境、操作过程和操作要求，对照用户提交的问题陈述，对用户需求可以有更全面、更细致的认识。138/42组成联合小组便利的应用规约技术(FacilitatedApplicationSpecificationTechniques,FAST)

：打破用户（需方）和开发者（供方）的界限，共同组成一个联合小组，发挥各自的长处，共同负责项目的推进，这样有助于发挥各自优势并增进解和协调139/42FAST基本原则在中立的地点举行由开发者和用户出席的会议；建立准备和参与会议的规则；建议一个足够正式的议程以便可以进行自由的交流；一个“协调者”(他可以是用户、开发者或其他外人)来控制会议；使用一种“定义机制”(它可以是工作表、图表、墙上胶黏纸或墙板)；目标是标识问题、提出解决方案的要素、商议不同的方法、以及在有利于完成目标的氛围中刻画出初步的需求。140/42FAST会议步骤1) 当举行了开发者和用户之间的初步访谈后，确定一个FAST会议的时间地点，并在会议日之前将产品请求发布给所有的与会者。2) 要求每个FAST出席者会前列出一组围绕系统环境的对象，以及对这些对象的操作或对象之间的交互功能，并开发出约束列表(如，成本、规模大小、权重)和性能标准列表(如，速度、精度)。这些列表可以不是穷尽的，但是，希望每套列表反映的是每个人对系统的感觉。3) 进行FAST会议时，当团队的每个成员提出单个列表后，整个团队将创建一个组合的列表，该组合列表删去冗余项，并加入在表达过程中出现的新思想。在建好所有主题的组合列表后，开始讨论活动。缩短、加长或重新组合列表以适当地反映将被开发的产品。141/42FAST会议步骤(续)4) 一旦创建了意见一致的列表，应该将团队分为更小的小组，每个小组力图为每个列表中的一个或多个项开发出小型的规约（即对包含在列表中的单词或短语的精细化）。每个小组然后将他们开发的每个小规约提交给所有的FAST出席者讨论，进行添加、删除或进一步的精化等工作。（在所有讨论过程中，团队可能提出某些不能在会议过程中解决的问题，此时要保留问题列表以使这些思想在以后的活动中产生作用。）5) 在小规约完成后，每个FAST的出席者提出一个针对产品的确切标准列表，并将该列表提交给团队，然后创建一个意见一致的确定的标准列表。这个列表作为需求获取的结果，为需求分析和建模提供基础信息。142/42用况（UseCase）当需求作为非正式会议、Fast的一部分而收集起来之后，分析员就可以创建一组标识一串待建造系统的使用场景。创建用况模型的主要步骤如下：确定谁会直接使用该系统，即参与者（Actor）选取其中一个参与者定义该参与者希望系统做什么，参与者希望系统作的每件事将成为一个用况对每件事来说，何时参与者会使用系统，通常会发生什么，这就是用况的基本过程描述该用况的基本过程143/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理144/42需求分析原则1．必须能够表示和理解问题的信息域2．必须能够定义软件将完成的功能3．必须能够表示软件的行为(作为外部事件的结果)4．必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节5．分析过程应该从要素信息移向细节信息145/42信息域信息域：包括信息内容、信息流、以及信息结构。信息内容表示了单个数据和控制对象，目标软件所有处理的信息集合由它们构成。例如，数据对象“工资”是一组重要数据体的组合：领款人的姓名、净付款数、付款总额、扣除额等等146/42信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息(数据和/或控制)，然后进一步被变换为输出信息结构表示了各种数据和控制项的内部组织数据或控制项将被组织为n维表还是树形结构？在结构的语境内，什么信息是和其他信息相关的？信息包含在单个结构中，还是使用不同的结构？在某信息结构中的信息如何和在另一个结构中的信息相关？147/42抽象、分解与多视点分析问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系首先关注一般问题的解决途径，进而指导特殊问题的解决方法。148/42问题分解的目的是要能以层次化的方式对问题进行分解和不断细化。较大规模或较为复杂的问题可以被分解为若干子问题进行理解和分析分解可以逐级进行，直至子问题被分解为一个容易分析理解的部分例如横向分解纵向分解149/42需求协商协商的过程就是讨论需求冲突，找出每个人都满意的折衷方案协商不是简单的逻辑或技术上的争论要注意组织和行政方面的因素①不一致的目标②责任的丧失或转移③组织文化④组织管理态度和士气⑤部门差异150/42通常会议是解决冲突最快的方式参加者应该包括发现冲突、遗漏或重叠的分析员，以及可以解决发现的问题的项目相关人员会议应该讨论那些非正式讨论不能解决的问题通常会议分为三个阶段：叙述阶段讨论阶段决策阶段151/42需求建模在软件需求分析阶段，所创建的模型，要着重于描述系统要做什么，而不是如何去做目标软件的模型不应涉及软件实现细节152/42常用的分析方法：面向数据流的结构化分析方法(SA)面向数据结构的分析方法面向对象的分析方法(OOA)153/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理154/42需求规约的原则1． 从现实中分离功能，即描述要“做什么”而不是“怎样实现”。2． 要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。3． 如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。4． 规约必须包括系统运行环境。155/42需求规约的原则(续)5． 规约必须是一个认识模型，而不是设计或实现的模型。6． 规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。7． 规约必须允许不完备性并允许扩充。8． 规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。156/42需求规约Ⅰ.引言A.系统参考文献B.整体描述C.软件项目约束Ⅱ.信息描述A.信息内容表示B.信息流表示：ⅰ数据流ⅱ控制流Ⅲ.功能描述A.功能划分B.功能描述：ⅰ处理说明ⅱ限制∕局限ⅲ性能需求ⅳ设计约束ⅴ支撑图C.控制描述ⅰ控制规约ⅱ设计约束Ⅳ.行为描述A.系统状态B.事件和响应Ⅴ.检验标准A.性能范围B.测试种类C.期望的软件响应D.特殊的考虑Ⅵ.参考书目Ⅶ.附录157/42引言：陈述软件目标，在基于计算机的系统语境内进行描述。信息描述：给出软件必须解决问题的详细描述，记录信息内容和关系、流和结构。功能描述：描述解决问题所需的每个功能。其中包括，为每个功能说明一个处理过程；叙述设计约束；叙述性能特征；用一个或多个图形来形象地表示软件的整体结构和软件功能与其他系统元素间的相互影响。行为描述：描述作为外部事件和内部产生的控制特征的软件操作。检验标准：描述检验系统成功的标志。即对系统进行什么样的测试，得到什么样的结果，就表示系统已经成功实现了。它是“确认测试”的基础。参考书目：包含了对所有和该软件相关的文档的引用，其中包括其他的软件工程文档、技术参考文献、厂商文献以及标准。附录：包含了规约的补充信息，表格数据、算法的详细描述、图表以及其他材料。158/42需求验证需求验证目的是要检验需求是否能够反映用户的意愿评审人员评审时往往需要检查以下内容：系统定义的目标是否与用户的要求一致；系统需求分析阶段提供的文档资料是否齐全；文档中的描述是否完整、清晰、准确地反映了用户要求；被开发项目的数据流与数据结构是否确定且充足；主要功能是否已包括在规定的软件范围之内，是否都已充分说明；设计的约束条件或限制条件是否符合实际；开发的技术风险是什么；是否详细制定了检验标准，它们能否对系统定义是否成功进行确认。

159/42内容摘要需求工程概述需求获取需求分析、协商与建模需求规约与验证需求管理第4章形式化说明技术4.1 概述4.2 有穷状态机4.3 Petri网4.4 Z语言4.5 小结4.1 概述4.1.1非形式化方法的缺点非形式化是指用自然语言描述软件需求（如系统规格说明书）。因此，可能存在矛盾性、二义性、含糊性、不完整性、抽象层次混乱等问题。4.1.2形式化方法的优点形式化方法是指在软件工程中引入数学方法和模型。利用数序的简洁性、严谨性、科学性，克服非形式化方法的缺点。4.1.3应用形式化方法的准则“软件需求”是软件产品的高层、概念模型，而“形式化方法”是严谨、科学的数学方法，因此，在形式化方法的应用方面应考虑适度性、实用性、实用性。常用的形式化方法较严格的形式化方法（语法和语义都严谨）：有穷状态机、Petri网、Z语言………半形式化方法（语法和语义都不太严谨）：系统流程图、数据流图、数据字典、ER图、数据库范式、状态转换图、层次方框图、Warnier图、IPO图、IPO表………4.1.1非形式化方法的缺点矛盾性在需求规格说明书（ReqirementSpecifications）中对同一问题前后存在不同的描述。二义性需求规格说明书的读者对其中同一问题的描述存在不同的理解。含糊性需求规格说明书中对某一问题的描述不清晰、不可理解、不知如何实现、不具可操作性。不完整性需求规格说明书中对某一问题的描述不完整。只说明了局部，没有说明整体；或者只说明了概要，未说明细节。因此不具可操作性。抽象层次混乱在不同层次的抽象模型中内容混乱，如在高层模型中混有底层细节，造成读者不能理解系统的整体功能和下级功能。4.1.2形式化方法的优点可严谨地描述软件需求中的问题可简介、准确描述物理现象、对象或动作的结果问题；适用于描述详细的需求规格；可用数学方法验证需求。可在软件工程不同阶段平滑过渡从需求、到设计、到实现都基于同一系统模型，平滑过渡。可提供高层确认手段可用数学方法证明软件工程各阶段的正确性（可回溯性），如“设计”符合“规格说明”、“编码实现”符合“设计”。形式化方法的适用性问题形式化方法能较好地解决需求的“二义性”、“含糊性”问题。但不能解决需求的矛盾性、完整性等问题，这些问题涉及工程管理。4.1.3应用形式化方法的准则应该选用适当的规格说明表示方法应该采用形式化，但不要过分形式化应该估算推行形式化的成本应该引入形式化方法的顾问与咨询应该结合传统的、证明有效的开发方法应该在采用形式化的同时，建立详尽的文档应该坚持质量保障活动应该不总是盲目依赖形式化方法应该重视测试应该重视重用4.2 有穷状态机4.2.1 有穷状态机概念4.2.2 有穷状态机例子4.2.3 有穷状态机方法评价4.2.1 有穷状态机概念通过简单例子引入有穷状态机的基本概念：一个保险箱上装了一个复合锁，锁有三个位置，分别标记为1、2、3，转盘可向左(L)或向右(R)转动。这样，在任意时刻转盘都有6种可能的运动，即1L、1R、2L、2R、3L和3R。保险箱的组合密码是1L、3R、2L，转盘的任何其他运动都将引起报警。引例——保险箱的状态转换图4.1保险箱的状态转换图

引例——保险箱的状态转换有穷状态机——概念一个有穷状态机包括下述5个部分：状态集J、输入集K、由当前状态和当前输入确定下一个状态(次态)的转换函数T、初始态S和终态集F。状态集J：有所有可能的状态构成的有穷集合；输入集K：引发状态变换的可能的外部输入（或操作）；转换函数T：由当前状态和当前输入变换到下一个状态(次态)的函数（或规则）；初始态S∈J，状态机的初始状态；终态集F∪J，状态机的终止状态集；引例——保险箱的有穷状态机状态集J：｛保险箱锁定，A，B，保险箱解锁，报警｝。输入集K：｛1L，1R，2L，2R，3L，3R｝。转换函数T：见“状态转换表”初始态S：保险箱锁定终态集F：｛保险箱解锁，报警｝有穷状态机——形式化表示一个有穷状态机可以表示为一个5元组(J，K，T，S，F)，其中：J是一个有穷的非空状态集；K是一个有穷的非空输入集；T是一个从(J-F)×K到J的转换函数；S∈J，是一个初始状态；F∪J，是终态集。扩展的有穷状态机——增加谓词集一个有穷状态机可以表示为一个6元组(J,K,P,T,S,F)，其中：J是一个有穷的非空状态集；K是一个有穷的非空输入集；P是一个有穷的非空谓词集