软件工程生命周期各阶段介绍课件.ppt

1、软件工程软件工程课件课件张权范张权范软件工程软件工程 第一章第一章概述概述 第二章第二章软件计划软件计划 第三章第三章软件需求分析软件需求分析 第四章第四章软件总体设计软件总体设计 第五章第五章软件详细设计软件详细设计 第六章第六章软件编码软件编码 第七章第七章软件测试软件测试 第八章第八章软件维护软件维护 第九章第九章软件项目管理软件项目管理 第十章第十章面向对象技术面向对象技术第一章第一课时第一章第一课时几个基本概念软件及其组成软件的概念软件的组成软件危机（概念、表现、产生原因与解决办法）软件工程软件发展简史（无程序的阶段、程序阶段、软件阶段与软件工程阶段）软件生命周期（软件生存的七个阶段

2、：软件计划、软件需求分析、软件总体设计、软件详细设计、软件编码、软件测试、软件维护 ）第二课时第一章第二课时第一章第二课时软件开发模型瀑布模型快速原型瀑布模型的定义瀑布模型的定义瀑布模型遵循软件生存周期的划分，明确规定每个阶段的任务，各个阶段的工作顺序展开，恰如奔流不息拾级而下的瀑布。问题定义可行性研究需求分析概要设计详细设计编码测试运行维护开发时期计划时期有错运行时期 对应的文档资料与系统目标方案论证报告或计划任务书需求规格说明书系统功能结构图设计规格书程序规格书、源程序测试记录、用户操作手册评价报告、维护记录瀑布模型的特点瀑布模型的特点 (1)软件生存周期的顺序性：只有前一阶段工作完成以后

3、，后一阶段的工作才能开始，前一阶段的输出文档，就是后一阶段的输入文档。只有前一阶段有正确的输出，后一阶段才可能有正确的结果。如果在生存周期的某一阶段出现了错误，往往要追溯到在它之前的一些阶段。 瀑布模型开发适合于在软件需求比较明确，开发技术比较成熟，工程管理比较严格的场合下使用。 (2)尽可能推迟软件的编码：程序设计也称为编码。实践表明，大、中型软件编码开始得越早，完成所需的时间反而越长。瀑布模型在编码之前安排了需求分析、总体设计、详细设计等阶段，从而把逻辑设计和编码清楚地划分开来，尽可能推迟程序编码阶段。 (3)保证质量 ：为了保证质量，瀑布模型软件开发在每个阶段都要完成规定的文档，每个阶段

4、都要对已完成的文档进行复审，以便及早发现隐患，排除故障。 快速原型快速原型正确的需求定义是系统成功关键。软件开发人员需要反复多次地和用户交流信息，才能全面、准确地了解用户的要求。理想的做法是先根据需求分析的结果开发一个原型系统，请用户试用一段时间，以便能正确地认识到他们的实际需要是什么，这相当于工程上先制作“样品”试用后，作适当改进，然后再批量生产一样，这就是快速原型法。虽然此法要额外花费一些成本，但是可以尽早获得更正确完整的需求，可以减少测试和调试的工作量，提高软件质量。因此快速原型法使用得当，能减少软件的总成本，缩短开发周期，是目前比较流行的实用开发模式。根据建立原型的目的不同，实现原型的

5、途径也有所不同，通常有下述三种类型。 (1)渐增型 (2)用于验证软件需求的原型(3)用于验证设计方案的原型 快速原型（续）快速原型（续）类型之一类型之一先选择一个或几个关键功能，建立一个不完全的系统，此时只包含目标系统的一部分功能或对目标系统的功能从某些方面作简化，通过运行这个系统取得经验，加深对软件需求的了解，逐步使系统扩充和完善。如此反复进行，直到软件人员和用户对所设计的软件系统满意为止。 渐增型开发的软件系统是逐渐增长和完善的，所以从整体结构上不如瀑布型方法开发的软件那样清晰。但是，由于渐增型开发过程自始至终都有用户参与，因而可以及时发现问题加以修改，可以更好地满足用户需求。 快速原型

6、（续）快速原型（续）类型之二类型之二系统分析人员在确定了软件需求之后，从中选出某些应验证的功能，用适当的工具快速构造出可运行的原型系统，由用户试用和评价。这类原型往往用后就丢弃，因此构造它们的生产环境不必与目标系统的生产环境一致，通常使用简洁而易于修改的超高级语言对原型进行编码。 快速原型（续）快速原型（续）类型之三类型之三为了保证软件产品的质量，在总体设计和详细设计过程中，用原型来验证总体结构或某些关键算法。如果设计方案验证完成后就将原型丢弃，则构造原型的工具不必与目标系统的生产环境一致。如果想把原型作为最终产品的一部分，原型和目标系统可使用同样的程序设计语言。快速原形的开发过程快速原形的开

7、发过程原 型 设 计编码系统定义与用户需求分析测试原型产品系统的设计实现完善原型第三课时第一章第三课时第一章第三课时喷泉模型软件重用模型喷泉模型喷泉模型演化集成测试编程设计分析喷泉模型原理图 基于喷泉模型，基于喷泉模型，HodgeHodge等人提出将软件开发过程等人提出将软件开发过程划分为概念模型分析、系统设计、对象设计与实现、划分为概念模型分析、系统设计、对象设计与实现、测试和系统组装集成等五个阶段，它也体现出分析测试和系统组装集成等五个阶段，它也体现出分析和设计之间的重叠和设计之间的重叠 概念模型分析：这个阶段主概念模型分析：这个阶段主要目标是建立系统模型。系统模型中的对象是现实要目标是建

8、立系统模型。系统模型中的对象是现实世界中的客观对象的抽象，应结构清晰、易于理解、世界中的客观对象的抽象，应结构清晰、易于理解、易于描述其规范。在分析阶段面向问题域，建立起易于描述其规范。在分析阶段面向问题域，建立起对象模型和过程模型。对象模型和过程模型。系统设计：给出模型对象系统设计：给出模型对象和过程的规范描述。和过程的规范描述。对象设计与实现：面向对象对象设计与实现：面向对象设计方法强调软件模块的再用和软件合成，因而在设计方法强调软件模块的再用和软件合成，因而在对象设计和实现时，并不要求所有的对象都从头开对象设计和实现时，并不要求所有的对象都从头开始设计，而是充分利用以前的设计工作。在软件

9、开始设计，而是充分利用以前的设计工作。在软件开发时检索对象库，若是对象库中已有的，则可再用；发时检索对象库，若是对象库中已有的，则可再用；否则，重新定义新的对象，进行设计和实现。否则，重新定义新的对象，进行设计和实现。测测试；测试所有的对象及对象相互之间的关系是否符试；测试所有的对象及对象相互之间的关系是否符合要求。合要求。 喷泉模型（续）喷泉模型（续）系统组装集成：面向对象软件特点之一是软件重用和组装技术。对象是数据和操作的封装载体，组装在一起才构成完整的系统。软件是对象模块的复合，而软件设计是对象模块经过进程控制而构造生成。软件重用模型软件重用模型旨在开发具有各种一般性功能的软件模块，将它

10、们组成软件重用库，这些模块设计时考虑其适应各种界面的接口规格，可供软件开发时利用。主要优点是减少软件生产中的重复开发，避免软件开发人员的大量重复劳动，提高开发效率，缩短开发周期，降低开发成本。软件重用库的模块不仅要便于选择使用，而且还应具有允许扩充、积累其成分的性能。软件重用分两种：(1)重用程序以各种源程序形式存库；(2)重用程序是经过编译的目标程序。软件重用模式开发过程如下： 设计重用库模块：重用库中的模块要经历模块定义、功能规格描述、模块设计、编码、模块功能测试、模块登记、模块目录编制，此后可放人重用库中。软件系统设计：在重用库建立后，软件系统的设计步骤如下：需求分析，功能定义、设计，在

11、重用库中选择模块，编码，测试，验收，运行维护。 第四课时第一章第四课时第一章第四课时喷泉模型软件工程的任务与研究范围软件开发的原则与开发方法返回喷泉模型喷泉模型瀑布模型要求在软件开发的初期就完全确定软件的需求，这在很多情况下往往是做不到的。螺旋模型试图克服瀑布模型的这一不足。SM把软件开发过程安排为逐步细化的螺旋周期序列，每经历一个周期，系统就细化和完善一些。SM每螺旋周期由六个步骤组成： (1)确定任务目标： 根据初始需求分析项目计划，确定任务目标、可选方案和限制。(2)选择对象：对各种软硬件设备、开发方法、技术、开发工具、人员、开发管理等对象进行选择：并决定软件是进行研制、购买还是利用现有

12、的。(3)分析约束条件：软件开发的时间、经费等限制条件。(4)风险分析：评估目标、对象、约束条件三者之间的联系，列出可能出现的问题及问题的严重程度等，把最重要的问题作为尚未解决的关键问题的风险。(5)制定消除风险的方法：应有详尽的说明和周密的计划，并估计可能产生的后果。依此来开发软件，为制订下一周期的计划打下基础。(6)制定下一周期的工作计划：在第一个螺旋周期，确定目标、选择对象、分析约束，通过风险分析制订消除风险的方法，初步开发原型1，制定系统生存周期计划。 喷泉模型（续）喷泉模型（续）在第二个螺旋周期，进一步明确系统的目标、开发方案及约束条件，通过风险分析制定消除风险的方法，在原型1的基础

13、上开发原型2。进一步明确软件需求，进行需求确认，修改开发计划。 在第三个螺旋周期，再进一步确认系统目标、开发方案及约束条件，进行风险分析，制订进一步消除风险的方法，在原型2的基础上开发原型3。此时可进行产品设计，再对设计进行验证和确认，制订集成测试计划。在第四个螺旋周期，软件开发方案、系统目标和约束条件得到确定，在风险分析的基础上，开发具有实用价值的可操作性原型，此时可对产品进行详细设计，进入编码、单元测试、集成测试阶段，最后进入验收测试，验收合格后交付用户使用，进入运行、维护阶段。 喷泉模型原理图逐步执行评价方案，标识、消除风险计 划 下 阶 段工作运行维护验证测试集成测试单元测试编码详细设

14、计风 险 分析集成测试计划设计验证与确认产品设计原型3风险分析开 发 计划需求确认软件需求原型2风险分析需求计划生存周期计划确 定 目标方 案 约束原型1风险分析操作性原型确定目标方案与约束螺旋模型的开发过程开发验证下一级产品软件工程的任务与研究范围软件工程的任务与研究范围软件产品的特点软件工程的研究内容与方法软件工具与软件支撑环境软件管理软件开发的原则与方法软件开发的原则与方法软件开发的原则自顶向下与模块结构软件开发的方法1.非自动形式的系统开发方法（1）系统流程图（2）结构分析法（3）结构化设计法（4）数据结构法（5）层次输入处理输出方法(HIPO法) 2.半自动形式的系统开发方法（1）软

15、件需求工程法（2）问题说明语言与分析法 3. 自动形式的系统开发方法 （HOS方法）：由计算机自动确定规范、自动分析、自动编程、自动执行与模拟，以规范语言AXES、资源分配工具RTA为工具。能自动进行分析、设计，工作量少、设计规范，也能自动进行修改和维护。该方法适用于系统分析和设计。第二章第一课时第二章第一课时问题定义与可行性研究问题定义可行性研究问题定义问题定义问题是指用户的基本要求，就是确切地定义用户要求解决的问题，即确定问题的性质、工程的目标和规模。怎样定义问题？问题定义的来源是用户，是提出问题、请求解决的人。若问题是以书面形式提出来，那么分析员应该认真阅读和分析书面材料；如果问题是以口

16、头形式提出，那么分析员应该认真倾听并仔细记录要点，在适当的时候认真地请用户解释。分析员还应该通过对用户的访问调查进一步搞清楚，用户为什么提出这样的问题，问题的背景是什么，用户的目标是什么。问题定义的目的是要在短时间内，对用户的要求有一个比较准确的估计，对要实现的系统规模做到胸中有数。但仅有这些还不够，还要搞清用户不打算干什么，在这个系统中哪些内容不用实现。工作的宗旨是搞清要做什么并划清要实现的系统的范围边界。在完成问题定义的过程中，用户在一开始，可能会给你大堆大堆的表格，因为他们可能认为只要把表格给你讲清楚，你就会对这个问题定义（续）问题定义（续）系统全部弄清楚了。还有一些人可能会给你展示一些

17、企业的十分详尽的管理示图，如物资流管理图、生产管理图、计划财务管理图等。因为他们也可能认为，只要分析员把这些图看懂了，就会对他们要建立的系统搞清楚了。但是，在问题定义阶段千万不要陷入到这些表格和图纸中。因为不管是表格还是图纸，其中都包含了大量的、只有用户才能懂的术语。当然，并不是说在问题定义阶段，这些图纸表格没有一点作用。对一些关键性的语汇可以请用户讲清楚，这样有利于问题定义的准确性。 总之，在问题定义阶段，分析员应尽可能站在较高的角度去抽象、概括所要干的事情。 分析员对问题有了明确认识之后，应该把自己的认识写成书面报告，提交给用户和使用部门的负责人审查，以检验分析员对所要解决的问题的理解是否

18、正确。因为分析员对问题的理解为今后开发工作确定了方向。分析员对问题理解正确，这是确保今后系统开发成功的关键。反之，分析员对问题理解不正确，最终开发出来的问题定义（续）问题定义（续）系统必然不能解决实际要求解决的问题。如果一个系统，不能解决要求它解决的问题，那么这个系统就一点价值也没有，只不过是浪费了开发它所用的时间和资源。所以及时审查问题的定义是极端重要的。理想的做法是分析员、用户和使用部门的负责人一起阅读讨论这份报告，明确含糊不清的地方，改正不正确的地方。通过修改得到一份大家一致同意的文档。 在问题定义阶段，分析员应该对工程成本做出粗略的预算，并对下阶段可行性研究所需要时间和成本做出较精确的

19、估计。 对问题定义的书面报告应该尽可能清楚简洁，最好写在一页内。这份报告通常应包括工程项目的名字，对问题概括定义、项目的目标，项目的规模，对可行性研究的具体建议(既需要用的时间和成本)等等。 一旦分析员和用户及使用部门的负责人对所要解决的问题，取得完全一致的看法且在报告书上签了字，问题定义阶段工作就宣告完成，可行性研究就可以开始。可行性研究可行性研究所谓可行性研究就是分析员站在较高的角度去调查现行手工系统及用户提出的项目目标，并且去寻找是否有一种手段能够在现有条件下，实际地达到项目目标，并使用户满意。同时向用户指出该系统实现的意义，以使用户去权衡花费这样的代价去实现这样的系统是否值得。 可行性

20、研究的目的就是用最小的代价在尽可能短的时间内，确定问题是否能够解决，从而确定问题是否值得去解。如何才能达到这个目的呢？进行客观分析，通过对几种可能解法，分析其利弊，才能判断原定系统的目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程序。因此，可行性研究实质上是进行一个大大压缩简化了的软件分析和设计过程，也就是在较高层上，以较抽象的方式进行软件分析和设计的过程。可行性研究应在以下三方面进行：技术可行性；经济可行性；操作可行性。可行性研究（续）可行性研究（续）1.技术可行性 对技术可行性研究，首先应从对现行系统进行调查入手。因为现行系统是信息的重要来源。显然，如果目前有一

21、个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果现行系统是完美无缺的，用户自然不会提出开发新的系统要求，因此，现行系统必然有某些缺点。新系统必须能解决旧系统中存在的问题。所以，应先对现行系统的组成部分、功能和存在问题进行调查研究。但这种调查研究不可能做得很细，对一些内容细节必须先把它们暂时忽略，而先抓住主要的问题。此时，分析员应把调查到的现行系统的情况画成高层数据流程图(数据流程图的画法在第三章介绍)。其次，导出新系统的高层逻辑模型(数据流程图)。新系统的高层的逻辑模型建立在现行系统的高层数据流程图的基础上。因为通过前一步的工作

22、，分析员对目标系统(新系统)应该具的基本功能和所受的约束，已有一定的了解，使用数据流程图描绘数据在系统中可行性研究（续）可行性研究（续）流动和处理的情况，从而概括地表达出对新系统的设想。用数据流程图和数据字典来定义新系统的高层逻辑模型。其三，重新定义问题。新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。此时，分析员应该和用户一起复查问题定义、工程规模和目标。这次复查应该把数据流程图和数据字典作讨论的基础。如果分析员对问题有误解或者用户曾经遗漏了某些要求，那么现在是发现和改正这些错误的时候了。其四，导出供选择的解法。分析员应从他所建议的系统逻辑模型出发，推导出若干个较高层次的解决办法

23、，供比较和选择。最简单的途径，是从技术角度出发，考虑解决问题的不同方案。这些不同方案可以在数据流程图上划分不同的自动化边界而得到。所以分析员在确定了几组不同的自动化边界之后，再针对每组边界，考虑如何实现所要求的系统。当从技术角度提出了一些系统模型之后，应根据技术可行性的考虑，初步排除一些不现实的系统。例如，如果要求系统的响应时间可行性研究（续）可行性研究（续）不超过几秒钟，显然应该排除任何批处理方案。把技术上行不通的解法(方案)去掉之后，就剩下了一组技术上可行的方案。也就是根据现有的技术条件,考虑所提出的方案是否能实现。例如现有的计算机是否能达到所要求的速度,现有的输入输出设备能否承担得了要求

24、的数据输入输出量。一般来说，技术可行性还可以从硬件(包括外围设备)的性能要求、软件的性能要求(包括操作系统、软件包、数据库管理系统、各种软件工具)能源及环境条件以及软件系统所采用的技术是否先进，实现的可能性如何，实现软件系统的人员素质是否具备等方面进行考虑。2.经济可行性研究经济可行性，不仅仅是了解为完成用户提出的要求是否有足够的资金支持(这是目前很多分析员重点要做的事情)，而更主要是把成本与获利分析清楚。也就是对经济合理性进行评价，即带来的经济效益是否超过其开发和维护所需要的费用。这工作包括估计费用和估计效益两个方面。可行性研究（续）可行性研究（续）估计费用。主要考虑以下几部分：设备费用，包

25、括计算机硬件和软件的费用；人力费用，包括开发人员和维护人员的工资；材料费用；管理费用以及维护费用等。估计效益。可以从以下几个方面考虑：提供了哪些以前提供不了的信息，提供信息的速度提高了多少？质量有什么提高？对使用者查询和使用信息的方便程度有什么提高，节省多少人力？对组织的领导人和管理人员正确做出决策提供了哪帮助？有时不能直接用金钱来衡量效益，如一个邮购单位，由于能够及时、准确地处理订货，缩短了顾客收到货物的时间，从而在竞争中得到了更多的顾客。这一类的收益就不容易用具体金钱来衡量，只能由管理人员根据经验来做出大约的估计。在估计效益时，要谨慎把各种可能影响效益发挥的各种因素考虑在内，打上折扣。3.

26、操作和维护可行性人员操作和维护可行性的研究是了解当用户所要求的软件系统可行性研究（续）可行性研究（续）建立起来之后 ，用户对它的操作是否方便？管理和维护是否容易？如果对于一个软件系统的操作比原有的手工系统还麻烦，那么它是不会受欢迎的。另一方面，如果管理和维护这个软件系统的人员比原来的手工系统还多，素质要求还高，那么这个系统对用户来说负担太重了。 对于人员操作和维护的可行性，一般可从两个方面来考虑：一方面从技术的角度，研究是否能够给用户提供一个方便的操作环境；另一方面从设备的选择上来考虑，看看为了完成用户要求的功能，是否能够找到一些易于管理和维护的设备。 从上面的讨论中不难看出，可行性研究的出发

27、点应该是从当前的物理系统到新的物理系统的转换，它是整个可行性研究的基础，实际上也是整个系统开发过程的缩影。因为整个系统实现过程也就是把当前的手工系统转化为可用计算机实现的新系统的一个转换过程，只不过这工作比在可行性研究阶段更细致，更具体罢了。 上述从三个方面分别开展的，而实际上它们之间有着密切的联系，因此还必须对它们综合考虑，然后向用户推荐方案供其选择。 可行性研究（续）可行性研究（续）当用户选定方案之后，分析员应对在问题定义阶段所规定的实现目标进行修改。因为，这时对系统有了更深入的了解，原来的问题定义可能有的不能实现，还有些需要加上去，也就是说原有的问题边界不够准确，需要纠正，以便今后有一个

28、非常明确的工作目标。这是一步极有实质意义的工作，它使分析员和用户最后明确了要解决的问题的边界以及它的实现方案。一般来说，可行性研究的结果可导致以下两种情况：(1) 可行()不可行可行性研究结束后，要写出可行性研究报告，提交有关专家论证和上级主管部门批准。可行性研究报告作为所有软件文件资料的基础材料，它的格式可以很不相同，但大体的内容提纲是一致的。 可行性研究（续）可行性研究（续）可行性研究报告的内容提纲： (1)背景情况 国内外水平、历史现状、市场需求。 （2)系统描述 总体方案和技术路线、课题分解、关键技术、计划目标和阶段目标。 (3)价格利益分析 经济可行性，包括经费概算和预期经济效益。

29、(4)技术冒险评价 技术可行性，包括技术实力、设备条件和已有工作基础。 (5)操作方便性评价 操作可行性，一方面从技术的角度，另一方面从设备的选择上考虑。 (6)其他与项目有关的问题 根据可行性研究结果，如果是可行的，那么对这项开发工程就继续进行。此时，分析员应对开发工程制订一份软件计划。这样，开发工作转到下一阶段。第二课时第二章第二课时第二章第二课时软件计划软件工作范围（软件功能、性能、可靠性和接口等问题的描述）资源（软件、硬件与人力资源）成本估算代码行技术任务分解技术软件计划任务书的书写规范第三课时第二章第三课时第二章第三课时软件计划任务书案例学分管理系统软件计划任务书项目开发进度月报编写

30、规范上述内容请参看书本相应页面的内容！返回第三章第一课时第三章第一课时需求分析的定义软件需求分析(软件要求分析)是在可行性研究基础上进行的更细致的分析工作，是对软件计划阶段建立的软件工作范围的求精和细化。也就是在对软件计划阶段确定的工作范围内进一步对目标对象和环境作细致、深入的调查分析。需求分析过程实际上是一个调查研究、分析综合的过程，是一个抽象思维、逻辑推理的过程。通过调查研究和分析，充分了解用户对软件系统的要求。在此基础上，把用户要求表达出来，解决软件系统“做什么”的问题。也就是建立起系统的逻辑模型，把软件功能和性能的总体概念描述成具体的软件规格说明书。 需求分析的目标（1.理清数据流或数

31、据结构；2.通过标识接口细节，深入描述功能，确定设计约束和软件有效性要求；3.构造一个完全、精致的目标系统逻辑模型。 ）需求分析的任务（认清问题、分析与综合、逻辑模型导出与复审）结构化分析方法结构化分析方法结构化分析方法结构化分析方法的策略基本的系统模型结构化分析方法策略分析.输 入1.软件系统输出1输出2输出3输 入.x1231.12.23.33.13.23.43.5顶层0层1层3.3逐层分解方法示意图结构化分析方法（续）结构化分析方法（续）数据流图数据流图数据流图的定义数据流图的组成要素：源点、终点、数据流、数据文件、数据变换数据变换的两种类型：对数据结构的变换，如对数据的格式重新排列。在

32、原有数据内容基础上产生新的数据内容，如计算平均值或总计。数据流图的画法、画数据流图的基本原则（数据流程图中的图形符号只能包含四种基本元素。数据流程图主图上的数据流必须封闭在外部实体（外部项）之间，实体可以是一个也可是多个。变换框上至少有一个输出数据流和一个输入数据流。数据流程图上的每一个元素都必须有“名字”。）、方法与步骤（参见书本相关内容）注意事项（父子图的平衡、分解程度与数据存储文件，数据流图是静态图、与传统框图的差别、反复修改的过程）第二课时第三章第二课时第三章第二课时数据字典、数据字典的定义（数据字典就是对数据流程图中，数据、变换等进行精确定义。 ）、数据定义方法（对数据自顶向下的分解

33、。当分解到不需要进一步定义，对每个和系统有关的人都能清楚理解这些数据项的含义为止。 ）、数据定义中的数据结构（顺序、选择、重复、可选 ）、数据字典中的符号（ 表示等价、十 表示和(或连接两个分量)、 表示重复花括号内的分量、| 表示或即从方括弧内列出的若干分量中选择一个、( ) 表示可选即或括弧里的量可有可无、n.m 表示界域 ）、数据流、数据存储、数据变换的定义（参见书本相关内容）第三课时第三章第三课时第三章第三课时结构化分析的步骤1.研究目前正在使用的系统 现有的系统(包括人工系统)是信息的重要来源。因此，首先要去了解现有系统能完成哪些工作(即功能)，而新的目标系统必须也能完成它的基本功能

34、；另一方面，既然提出要开发新的系统，那么现有的系统必定存在某些问题，而新的目标系统必须能够解决旧系统中存在的问题，也就是给新的目标系统提出了新的要求(即功能要求)，所以了解现有系统是开发新的目标系统的基础。对现有系统(人工系统)的了解，是要了解对现有系统能做什么，同时画出描绘现有系统的高层数据流程图。2.导出新系统的高层数据流程图(即逻辑模型) 好的设计，通常总是从现有系统出发导出现有系统的逻辑模型，然后参考现有系统的逻辑模型，设想出新系统的逻辑模型。 通常第一步的工作，对新的目标系统应该具有的基本功能和所结构化分析步骤（续）结构化分析步骤（续）受的约束条件，已有一定的了解，把这些了解用数据流

35、程图概括地描绘出对新系统的设想。同时定义系统中使用的数据，构造初步的数据字典。这样，数据流程图和数据字典共同定义了新的目标系统的高层逻辑模型。(在可行性研究阶段完成)3.完善数据流程图 在第二步画出新系统的高层数据流程图中，许多数据的定义和一些细节都没有考虑进去。现在应着手解决这个问题。 （1）沿着数据流程图回溯 为了对数据流程图中的数据流和数据存储进行定义，通常是从数据流程图的输出端着手分析。这是因为软件系统的目标是产生这些输出，输出数据确定了软件系统必须具有的最基本的组成元素。 输出数据是由哪些数据项组成的，通过调查访问是不难搞清这个问题。那么每个输出数据项又是从哪里来的呢?因为它是新系统

36、的输出，那么它们或者是从外面输入到系统中来，或者是通过运算结构化分析步骤（续）结构化分析步骤（续）由系统中产生出来的。为了弄清这些，可以沿着数据流程图从输出端往输入端回溯，能够确定每个数据项的来源，与此同时也就初步定义了有关的算法。 在第二步得到的高层数据流程图中，许多具体细节没有包括在里面。因此，当沿着数据流程图回溯时，经常会遇到：为了得到某个数据项需要用到数据流程图中目前还没有的数据项，或者得出这个数据项要用的算法还不完全清楚。为了解决这些问题，需要向用户和有关人员请教，他们的回答使分析员对新系统的认识更具体更深入了。系统中更多的数据项被划分出来，更多的算法被搞清楚了。一般把分析过程得到的

37、有关数据项的信息、变换的算法简明地记在数据字典中。 （2）用户复查 通过沿着数据流程图的回溯过程，把一些数据项和变换的算法记录到数据字典中。这个数据字典是否准确完整?算法是否正确?还有没有必要的变换和数据项遗漏了?某些数据项的来源搞清楚吗?结构化分析步骤（续）结构化分析步骤（续）对这些问题必须请系统的用户(直接在这个系统上工作的)对前面步骤得出的结果仔细地进行复查。可以借助于数据流程图和数据字典，从输入端开始向用户解释输入数据是怎样一步一步地转变成输出数据。这些解释集中反映了分析员通过前面分析工作，所获得的对新目标系统的认识。这些认识是否正确，有没有遗漏?应请用户及时纠正和补充分析员的认识。通

38、过复查过程验证了已知的元素，补充了未知的元素。填补了文档中的空白。 由于复查可能获得新的知识，又可能引出新的问题。例如，对新补充进来的数据项是怎样得出来的?它的来源是什么?这些需要进一步的调查访问寻求对问题的解答，而且还应及时修改和补充数据流程图和数据字典，把对系统的新认识及时记录下来。所以，追踪数据流程图和复查软件系统的逻辑模型实质上构成一个循环。对数据流程图的分析产生一些问题，这些问题通过复查得到的答案使分析员对系统有更深人更具体的认识，同时可能又引出新的问题，寻找这些新问题的答案导致了对新系统的更进一步的认识这样，每经过一次循环都会对新系统了解更多的细节。结构化分析（续）结构化分析（续）

39、4.分解细化数据流程图 通过上面的分析及用户的复查，分析员对新系统已有了更进一步了解，此时可对数据流程图中的各个变换进行检查。如果某个变换的功能还比较复杂，也就是还比较抽象，就应将这个变换功能分解成若干个子功能。这些较低层的子功能就成为一张新的数据流程图上的变换。在新的数据流程图中，也应该包括自己的数据流和数据存储。数据流程图经过分解之后，得到一组新的数据流程图，在图上，不同的软件元素之间关系变得更清楚了。对这组新的数据流程图的分析追踪可能产生新的问题，对这些问题的解答，又可能在数据字典中增加一些新的条目，并且可能导致新的或精化的变换算法的描述。随着分析过程的进展，经过问题与解答的反复循环，分

40、析员越来越深入、具体地定义了新系统。通过上面各步就可以得到一套新目标系统的分层数据流程图和数据字典，也就是得到新系统的逻辑模型。 第四课时第三章第四课时第三章第四课时按功能逐层分解法(HIPO法) HIPO法的定义HIPO法组成图（参见书本上的相关内容）图（参见书本上的相关内容）第五课时第三章第五课时第三章第五课时软件需求分析报告书写规范（参见书本的相关内容）软件需求分析报告案例直通车系统的需求分析报告（参见书本相关内容）返回第四章第一课时第四章第一课时评价一个 “设计”的标准（有一个明确的设计步骤、良好的设计方法、鉴别优劣的准则、好的设计表示）软件总体设计的任务（从软件的需求规格说明书出发，

41、将设计对象用数据流或数据结构的形式表达成完整的抽象实体。这个实体应当是一个结构清晰、层次分明的模块组合，应当可以被评价和细化，也可以被修改。同时还要定义这个实体与外部环境的接口。）软件总体设计的目标 （1.软件实体应当具有明显的层次结构，便于软件元素之间的控制。2.软件实体应当模块化，这些摸块应具有完全独立的功能。 3.软件实体与环境的界面应当清晰。4.软件设计的最终表示软件设计规格说明应当清晰、简洁、完整和无岐义。 ）软件设计的工作流程（请参见书本上相关内容）软件总体设计基础（模块、软件结构、层次机构的几个特点、结构图、结构图的优点）第二课时第四章第二课时第四章第二课时软件模块模块特点（抽象

42、与封闭性）模块独立性的衡量（耦合和聚合 ）第三课时第四章第三课时第四章第三课时软件的总体设计准则1.评价软件初始结构，通过模块的分解与合并减少模块之间的耦合度增加聚合度在设计初始软件结构以后，常常会发现几个模块的功能有相似之处，这相似部分不仅增加了编程和调试的工作量，同时也给维护过程带来麻烦，应当消除这样的重复。（1）完全相似 这种情况只在数据类型上不一致，可采用完全合并，只需在数据类型的描述或变量定义上加以改进。（2）局部相似 如图4-23(a)中，模块Q1和Q2具有功能类似的组成部分和不同部分可通过模块分解消除重复功能部分。其方法是首先找出模块Q1和Q2的功能相似部分，如图中的虚线部分，然

43、后把这两个模块的虚线部分分离出来，构成它们的一个公共的下层模块Q，如图4-23(b)软件的总体设计准则（续）软件的总体设计准则（续）所示。如果分解后余下的模块Q1和Q2比较简单，则可以同它们的各自调用模块x和y合并，如图4-23(c)和(d)。这样图4-23中的(b)、(c)、(d)都消除了重复功能的组成部分，这样模块间的耦合较小、模块内的聚合较大。（图的内容请参见书本的相应页面）在图4-24(a)中如果模块B与模块C和D之间以及模块E和F之间耦合较大，可以把模块B、C、D合并成一个模块ABC，把模块E和F合并成一个模块EF，如图4-24(b)。这样就使得模块间耦合减少，模块内聚合增加。2.模

44、块功能的完善一个完整的功能模块应具有以下三个要素：(1)执行某项指定功能的部分 (2)如果需要返回一系列的数据给它的调用者，应在完成数据处理或结束时，告诉它的调用者“文件完”或其他标志。(3)出错处理部分，即在不能完成指定任务时，必须将产生这种例外情况的原因(出错标志)通知它的调用者。它们是一个功能模块的有机组成部分，不应当分离到其他模块中去，否则会增加模块间的耦合。软件的总体设计准则（续）软件的总体设计准则（续）3.模块调用个数最好不要超过五个一个模块拥有的直属下级模块的个数叫模块的扇出数。如果一个模块具有过多的调用模块，那么这个模块扇出数就过大，如图4-25(a)，这个模块就往往包含过多的

45、功能，一般是因为缺乏中间层次的控制模块，需要将其功能进行分解。如图4-25(b)。一个模块的直接上级模块的个数叫模块的扇入数。一个模块的扇入表明有多少个上级模块直接调用它，扇入越大，则共享该模块的上级模块数目越多，这是有好处的。但不能违背模块独立性而单纯追求高扇入。4.一个模块的作用范围应在其控制范围之内一个模块的作用范围就是这个模块内一个判定的作用范围。一个判定的作用范围是指所有受这个判定影响的那些模块，只要模块中含有一些依赖于这个判定的操作，那么这个模块就在这个判定的作用范围之内。一个模块的控制范围包括它自己及其所有的下属模块。控制范围软件的总体设计准则（续）软件的总体设计准则（续）是从结

46、构方面来考虑的，而作用范围是从功能方面考虑的。图4-26给出了不同的作用范围控制范围结构的实例，下面以此来讨论模块之间的联系。图 4-26 作用范围不在控制范围之内图 4-27 判断所处层次太高图4-26说明作用范围不在控制范围之内，模块B2做出判定之后，若需要模块A工作就必须把信号回送给模块B、Y。这样就增加了数据的传送量和模块间的联系。因此，这是一个不好的设计。图4-27中作用范围是在控制范围之内，但判定所处层次太高（TOP），这样经过不必要的数据传送，增加了传送量，这个结构可以用，但不太好。 图4-28 判定分支含有不必要的穿越图4-29 比较理想的结构软件的总体设计准则（续）软件的总体

47、设计准则（续）图4-28中作用范围在控制范围之内，只有一个判定分支含有一个不必要的穿越，这是个较好的结构。图4-29中是一个较理想的好结构。如果在设计过程中发现作用范围不在控制范围内时，可以通过下面手段将作用范围移到控制范围之内。(1)将包含判定的模块合并到它的调用模块中，这样可使判定处于足够高的层次。(2)将受判定影响的模块下移到控制范围之内。(3)将判定上移到足够高的位置。例如图4-30(a)中判定的作用范围不在控制范围之内。把含有判定的模块D合并到它的调用模块A中去，成了图4-30(b)所示。这样作用范围就处在控制之内。图4-30 将包含判定的模块合并到它的调用模块软件的总体设计准则（续

48、）软件的总体设计准则（续）又如图4-31(a)中的模块x不在模块A的控制之内，把它下移到控制范围之内。如图4-31(b)所示。图4-31 将受到判定影响的模块下移到控制范围之内5.力争设计单入口和单出口的模块，避免“病态联接”一个模块只有一个入口和一个出口时，这个模块是比较容易理解的，有利于结构化编制程序，也比较容易维护。但实际上这样的模块不多。病态联接是指转移到或引用到另一模块中去的内容耦合。要尽量避免这种病态联接，以减少模块间的耦合。6.力争降低模块接口的复杂性模块接口复杂性是软件发生错误的一个主要原因。因此，应该仔细设计模块接口，使得信息传递简单并且和模块功能相一致。为说明接口复杂性的影

49、响，请看下面的例子。例如，求一元二次方程的根的模块QUAD-ROOT(TBL，x)其中用数组TBL传送方程的系数，用数组x回送求得的根。但是模块QUAD-软件的总体设计准则（续）软件的总体设计准则（续）ROOT接口TBL和x意义不明确，不利于对这个模块的理解。因此可以将它简化如下： QUAD-ROOT(A,B,C，ROOT1，ROOT2)，其中，A，B，C是方程系数，ROOT1和ROOT2。是求出的方程的两个根。很明显，这样的接口既简单又与模块QUAD-ROOT的功能一致。在设计模块接口时，应尽量能设计这样的模块接口，以降低模块接口的复杂性。7.模块的大小模块大小就是模块含语句数量的多少。模块

50、的大小没有统一的标准。一般来说，模块的大小以一页左右为宜。一页(高级语言50行左右)在一个人智力之内，比较容易阅读和理解。在进行模块设计时，首先应根据模块的独立性来选取模块的规模。如果某个模块功能是独立的，那怕程序段较短也不要人为地加长；如果程序段只有一个独立的功能，那怕程序较长，也不要人为地把它分解成两个模块。第四课时第四章第四课时第四章第四课时结构化软件设计结构化软件设计的定义与特点结构化软件设计的类型变换设计事物型设计综合设计结构化软件设计步骤 结构化软件设计案例返回第五章第一课时第五章第一课时软件详细设计的定义：对软件模块的过程设计。 软件详细设计的任务：对总体设计所产生的功能模块进行