《软件工程生命周期各阶段介绍课件》由会员分享，可在线阅读，更多相关《软件工程生命周期各阶段介绍课件（82页珍藏版）》请在金锄头文库上搜索。
1、软件工程软件工程课件课件张张权范权范软件工程软件工程第一章第一章概述概述第二章第二章软件计划软件计划第三章第三章软件需求分析软件需求分析第四章第四章软件总体设计软件总体设计第五章第五章软件详细设计软件详细设计第六章第六章软件编码软件编码第七章第七章软件测试软件测试第八章第八章软件维护软件维护第九章第九章软件项目管理软件项目管理第十章第十章面向对象技术面向对象技术第一章第一课时第一章第一课时几个基本概念软件及其组成软件的概念软件的组成软件危机（概念、表现、产生原因与解决办法）软件工程软件发展简史（无程序的阶段、程序阶段、软件阶段与软件工程阶段）软件生命周期（软件生存的七个阶段：软件计划、软件需求
2、分析、软件总体设计、软件详细设计、软件编码、软件测试、软件维护）第二课时第一章第二课时第一章第二课时软件开发模型瀑布模型快速原型瀑布模型的定义瀑布模型的定义瀑布模型遵循软件生存周期的划分，明确规定每个阶段的任务，各个阶段的工作顺序展开，恰如奔流不息拾级而下的瀑布。问题定义可行性研究需求分析概要设计详细设计编码测试运行维护开发时期计划时期有错运行时期对应的文档资料与系统目标方案论证报告或计划任务书需求规格说明书系统功能结构图设计规格书程序规格书、源程序测试记录、用户操作手册评价报告、维护记录瀑布模型的特点瀑布模型的特点(1)软件生存周期的顺序性：只有前一阶段工作完成以后，后一阶段的工作才能开始，
3、前一阶段的输出文档，就是后一阶段的输入文档。只有前一阶段有正确的输出，后一阶段才可能有正确的结果。如果在生存周期的某一阶段出现了错误，往往要追溯到在它之前的一些阶段。瀑布模型开发适合于在软件需求比较明确，开发技术比较成熟，工程管理比较严格的场合下使用。(2)尽可能推迟软件的编码：程序设计也称为编码。实践表明，大、中型软件编码开始得越早，完成所需的时间反而越长。瀑布模型在编码之前安排了需求分析、总体设计、详细设计等阶段，从而把逻辑设计和编码清楚地划分开来，尽可能推迟程序编码阶段。(3)保证质量：为了保证质量，瀑布模型软件开发在每个阶段都要完成规定的文档，每个阶段都要对已完成的文档进行复审，以便及
4、早发现隐患，排除故障。快速原型快速原型正确的需求定义是系统成功关键。软件开发人员需要反复多次地和用户交流信息，才能全面、准确地了解用户的要求。理想的做法是先根据需求分析的结果开发一个原型系统，请用户试用一段时间，以便能正确地认识到他们的实际需要是什么，这相当于工程上先制作“样品”试用后，作适当改进，然后再批量生产一样，这就是快速原型法。虽然此法要额外花费一些成本，但是可以尽早获得更正确完整的需求，可以减少测试和调试的工作量，提高软件质量。因此快速原型法使用得当，能减少软件的总成本，缩短开发周期，是目前比较流行的实用开发模式。根据建立原型的目的不同，实现原型的途径也有所不同，通常有下述三种类型。
5、(1)渐增型(2)用于验证软件需求的原型(3)用于验证设计方案的原型快速原型（续）快速原型（续）类型之一类型之一先选择一个或几个关键功能，建立一个不完全的系统，此时只包含目标系统的一部分功能或对目标系统的功能从某些方面作简化，通过运行这个系统取得经验，加深对软件需求的了解，逐步使系统扩充和完善。如此反复进行，直到软件人员和用户对所设计的软件系统满意为止。渐增型开发的软件系统是逐渐增长和完善的，所以从整体结构上不如瀑布型方法开发的软件那样清晰。但是，由于渐增型开发过程自始至终都有用户参与，因而可以及时发现问题加以修改，可以更好地满足用户需求。快速原型（续）快速原型（续）类型之二类型之二系统分析人
6、员在确定了软件需求之后，从中选出某些应验证的功能，用适当的工具快速构造出可运行的原型系统，由用户试用和评价。这类原型往往用后就丢弃，因此构造它们的生产环境不必与目标系统的生产环境一致，通常使用简洁而易于修改的超高级语言对原型进行编码。 快速原型（续）快速原型（续）类型之三类型之三为了保证软件产品的质量，在总体设计和详细设计过程中，用原型来验证总体结构或某些关键算法。如果设计方案验证完成后就将原型丢弃，则构造原型的工具不必与目标系统的生产环境一致。如果想把原型作为最终产品的一部分，原型和目标系统可使用同样的程序设计语言。快速原形的开发过程快速原形的开发过程原型设计编码系统定义与用户需求分析测试原
7、型产品系统的设计实现完善原型第三课时第一章第三课时第一章第三课时喷泉模型软件重用模型喷泉模型喷泉模型演化集成测试编程设计分析喷泉模型原理图 基基于于喷喷泉泉模模型型，HodgeHodge等等人人提提出出将将软软件件开开发发过过程程划划分分为为概概念念模模型型分分析析、系系统统设设计计、对对象象设设计计与与实实现现、测测试试和和系系统统组组装装集集成成等等五五个个阶阶段段，它它也也体体现现出出分分析析和和设设计计之之间间的的重重叠叠 概概念念模模型型分分析析：这这个个阶阶段段主主要要目目标标是是建建立立系系统统模模型型。系系统统模模型型中中的的对对象象是是现现实实世世界界中中的的客客观观对对象象
8、的的抽抽象象，应应结结构构清清晰晰、易易于于理理解解、易易于于描描述述其其规规范范。在在分分析析阶阶段段面面向向问问题题域域，建建立立起起对对象象模模型型和和过过程程模模型型。系系统统设设计计：给给出出模模型型对对象象和和过过程程的的规规范范描描述述。对对象象设设计计与与实实现现：面面向向对对象象设设计计方方法法强强调调软软件件模模块块的的再再用用和和软软件件合合成成，因因而而在在对对象象设设计计和和实实现现时时，并并不不要要求求所所有有的的对对象象都都从从头头开开始始设设计计，而而是是充充分分利利用用以以前前的的设设计计工工作作。在在软软件件开开发发时时检检索索对对象象库库，若若是是对对象象
9、库库中中已已有有的的，则则可可再再用用；否否则则，重重新新定定义义新新的的对对象象，进进行行设设计计和和实实现现。测测试试；测测试试所所有有的的对对象象及及对对象象相相互互之之间间的的关关系系是是否否符符合要求。合要求。 喷泉模型（续）喷泉模型（续）系统组装集成：面向对象软件特点之一是软件重用和组装技术。对象是数据和操作的封装载体，组装在一起才构成完整的系统。软件是对象模块的复合，而软件设计是对象模块经过进程控制而构造生成。软件重用模型软件重用模型旨在开发具有各种一般性功能的软件模块，将它们组成软件重用库，这些模块设计时考虑其适应各种界面的接口规格，可供软件开发时利用。主要优点是减少软件生产中
10、的重复开发，避免软件开发人员的大量重复劳动，提高开发效率，缩短开发周期，降低开发成本。软件重用库的模块不仅要便于选择使用，而且还应具有允许扩充、积累其成分的性能。软件重用分两种：(1)重用程序以各种源程序形式存库；(2)重用程序是经过编译的目标程序。软件重用模式开发过程如下： 设计重用库模块：重用库中的模块要经历模块定义、功能规格描述、模块设计、编码、模块功能测试、模块登记、模块目录编制，此后可放人重用库中。软件系统设计：在重用库建立后，软件系统的设计步骤如下：需求分析，功能定义、设计，在重用库中选择模块，编码，测试，验收，运行维护。 第四课时第一章第四课时第一章第四课时喷泉模型软件工程的任务
11、与研究范围软件开发的原则与开发方法返回喷泉模型喷泉模型瀑布模型要求在软件开发的初期就完全确定软件的需求，这在很多情况下往往是做不到的。螺旋模型试图克服瀑布模型的这一不足。SM把软件开发过程安排为逐步细化的螺旋周期序列，每经历一个周期，系统就细化和完善一些。SM每螺旋周期由六个步骤组成： (1)确定任务目标： 根据初始需求分析项目计划，确定任务目标、可选方案和限制。(2)选择对象：对各种软硬件设备、开发方法、技术、开发工具、人员、开发管理等对象进行选择：并决定软件是进行研制、购买还是利用现有的。(3)分析约束条件：软件开发的时间、经费等限制条件。(4)风险分析：评估目标、对象、约束条件三者之间的
12、联系，列出可能出现的问题及问题的严重程度等，把最重要的问题作为尚未解决的关键问题的风险。(5)制定消除风险的方法：应有详尽的说明和周密的计划，并估计可能产生的后果。依此来开发软件，为制订下一周期的计划打下基础。(6)制定下一周期的工作计划：在第一个螺旋周期，确定目标、选择对象、分析约束，通过风险分析制订消除风险的方法，初步开发原型1，制定系统生存周期计划。 喷泉模型（续）喷泉模型（续）在第二个螺旋周期，进一步明确系统的目标、开发方案及约束条件，通过风险分析制定消除风险的方法，在原型1的基础上开发原型2。进一步明确软件需求，进行需求确认，修改开发计划。 在第三个螺旋周期，再进一步确认系统目标、开
13、发方案及约束条件，进行风险分析，制订进一步消除风险的方法，在原型2的基础上开发原型3。此时可进行产品设计，再对设计进行验证和确认，制订集成测试计划。在第四个螺旋周期，软件开发方案、系统目标和约束条件得到确定，在风险分析的基础上，开发具有实用价值的可操作性原型，此时可对产品进行详细设计，进入编码、单元测试、集成测试阶段，最后进入验收测试，验收合格后交付用户使用，进入运行、维护阶段。 喷泉模型原理图逐步执行评价方案，标识、消除风险计划下阶段工作运行维护验证测试集成测试单元测试编码详细设计风 险分析集成测试计划设计验证与确认产品设计原型3风险分析开发 计划需求确认软件需求原型2风险分析需求计划生存周
14、期计划确定 目标方案 约束原型1风险分析操作性原型确 定目 标方 案与 约束螺旋模型的开发过程开发验证下一级产品软件工程的任务与研究范围软件工程的任务与研究范围软件产品的特点软件工程的研究内容与方法软件工具与软件支撑环境软件管理软件开发的原则与方法软件开发的原则与方法软件开发的原则自顶向下与模块结构软件开发的方法1.非自动形式的系统开发方法（1）系统流程图（2）结构分析法（3）结构化设计法（4）数据结构法（5）层次输入处理输出方法(HIPO法) 2.半自动形式的系统开发方法（1）软件需求工程法（2）问题说明语言与分析法 3. 自动形式的系统开发方法 （HOS方法）：由计算机自动确定规范、自动分
15、析、自动编程、自动执行与模拟，以规范语言AXES、资源分配工具RTA为工具。能自动进行分析、设计，工作量少、设计规范，也能自动进行修改和维护。该方法适用于系统分析和设计。第二章第一课时第二章第一课时问题定义与可行性研究问题定义可行性研究问题定义问题定义问题是指用户的基本要求，就是确切地定义用户要求解决的问题，即确定问题的性质、工程的目标和规模。怎样定义问题？问题定义的来源是用户，是提出问题、请求解决的人。若问题是以书面形式提出来，那么分析员应该认真阅读和分析书面材料；如果问题是以口头形式提出，那么分析员应该认真倾听并仔细记录要点，在适当的时候认真地请用户解释。分析员还应该通过对用户的访问调查进
16、一步搞清楚，用户为什么提出这样的问题，问题的背景是什么，用户的目标是什么。问题定义的目的是要在短时间内，对用户的要求有一个比较准确的估计，对要实现的系统规模做到胸中有数。但仅有这些还不够，还要搞清用户不打算干什么，在这个系统中哪些内容不用实现。工作的宗旨是搞清要做什么并划清要实现的系统的范围边界。在完成问题定义的过程中，用户在一开始，可能会给你大堆大堆的表格，因为他们可能认为只要把表格给你讲清楚，你就会对这个问题定义（续）问题定义（续）系统全部弄清楚了。还有一些人可能会给你展示一些企业的十分详尽的管理示图，如物资流管理图、生产管理图、计划财务管理图等。因为他们也可能认为，只要分析员把这些图看懂
17、了，就会对他们要建立的系统搞清楚了。但是，在问题定义阶段千万不要陷入到这些表格和图纸中。因为不管是表格还是图纸，其中都包含了大量的、只有用户才能懂的术语。当然，并不是说在问题定义阶段，这些图纸表格没有一点作用。对一些关键性的语汇可以请用户讲清楚，这样有利于问题定义的准确性。 总之，在问题定义阶段，分析员应尽可能站在较高的角度去抽象、概括所要干的事情。 分析员对问题有了明确认识之后，应该把自己的认识写成书面报告，提交给用户和使用部门的负责人审查，以检验分析员对所要解决的问题的理解是否正确。因为分析员对问题的理解为今后开发工作确定了方向。分析员对问题理解正确，这是确保今后系统开发成功的关键。反之，
18、分析员对问题理解不正确，最终开发出来的问题定义（续）问题定义（续）系统必然不能解决实际要求解决的问题。如果一个系统，不能解决要求它解决的问题，那么这个系统就一点价值也没有，只不过是浪费了开发它所用的时间和资源。所以及时审查问题的定义是极端重要的。理想的做法是分析员、用户和使用部门的负责人一起阅读讨论这份报告，明确含糊不清的地方，改正不正确的地方。通过修改得到一份大家一致同意的文档。 在问题定义阶段，分析员应该对工程成本做出粗略的预算，并对下阶段可行性研究所需要时间和成本做出较精确的估计。 对问题定义的书面报告应该尽可能清楚简洁，最好写在一页内。这份报告通常应包括工程项目的名字，对问题概括定义、
19、项目的目标，项目的规模，对可行性研究的具体建议(既需要用的时间和成本)等等。 一旦分析员和用户及使用部门的负责人对所要解决的问题，取得完全一致的看法且在报告书上签了字，问题定义阶段工作就宣告完成，可行性研究就可以开始。可行性研究可行性研究所谓可行性研究就是分析员站在较高的角度去调查现行手工系统及用户提出的项目目标，并且去寻找是否有一种手段能够在现有条件下，实际地达到项目目标，并使用户满意。同时向用户指出该系统实现的意义，以使用户去权衡花费这样的代价去实现这样的系统是否值得。 可行性研究的目的就是用最小的代价在尽可能短的时间内，确定问题是否能够解决，从而确定问题是否值得去解。如何才能达到这个目的
20、呢？进行客观分析，通过对几种可能解法，分析其利弊，才能判断原定系统的目标和规模是否现实，系统完成后所能带来的效益是否大到值得投资开发这个系统的程序。因此，可行性研究实质上是进行一个大大压缩简化了的软件分析和设计过程，也就是在较高层上，以较抽象的方式进行软件分析和设计的过程。可行性研究应在以下三方面进行：技术可行性；经济可行性；操作可行性。可行性研究（续）可行性研究（续）1.技术可行性 对技术可行性研究，首先应从对现行系统进行调查入手。因为现行系统是信息的重要来源。显然，如果目前有一个系统正被人使用，那么这个系统必定能完成某些有用的工作，因此，新的目标系统必须也能完成它的基本功能；另一方面，如果
21、现行系统是完美无缺的，用户自然不会提出开发新的系统要求，因此，现行系统必然有某些缺点。新系统必须能解决旧系统中存在的问题。所以，应先对现行系统的组成部分、功能和存在问题进行调查研究。但这种调查研究不可能做得很细，对一些内容细节必须先把它们暂时忽略，而先抓住主要的问题。此时，分析员应把调查到的现行系统的情况画成高层数据流程图(数据流程图的画法在第三章介绍)。其次，导出新系统的高层逻辑模型(数据流程图)。新系统的高层的逻辑模型建立在现行系统的高层数据流程图的基础上。因为通过前一步的工作，分析员对目标系统(新系统)应该具的基本功能和所受的约束，已有一定的了解，使用数据流程图描绘数据在系统中可行性研究
22、（续）可行性研究（续）流动和处理的情况，从而概括地表达出对新系统的设想。用数据流程图和数据字典来定义新系统的高层逻辑模型。其三，重新定义问题。新系统的逻辑模型实质上表达了分析员对新系统必须做什么的看法。此时，分析员应该和用户一起复查问题定义、工程规模和目标。这次复查应该把数据流程图和数据字典作讨论的基础。如果分析员对问题有误解或者用户曾经遗漏了某些要求，那么现在是发现和改正这些错误的时候了。其四，导出供选择的解法。分析员应从他所建议的系统逻辑模型出发，推导出若干个较高层次的解决办法，供比较和选择。最简单的途径，是从技术角度出发，考虑解决问题的不同方案。这些不同方案可以在数据流程图上划分不同的自
23、动化边界而得到。所以分析员在确定了几组不同的自动化边界之后，再针对每组边界，考虑如何实现所要求的系统。当从技术角度提出了一些系统模型之后，应根据技术可行性的考虑，初步排除一些不现实的系统。例如，如果要求系统的响应时间可行性研究（续）可行性研究（续）不超过几秒钟，显然应该排除任何批处理方案。把技术上行不通的解法(方案)去掉之后，就剩下了一组技术上可行的方案。也就是根据现有的技术条件,考虑所提出的方案是否能实现。例如现有的计算机是否能达到所要求的速度,现有的输入输出设备能否承担得了要求的数据输入输出量。一般来说，技术可行性还可以从硬件(包括外围设备)的性能要求、软件的性能要求(包括操作系统、软件包
24、、数据库管理系统、各种软件工具)能源及环境条件以及软件系统所采用的技术是否先进，实现的可能性如何，实现软件系统的人员素质是否具备等方面进行考虑。2.经济可行性研究经济可行性，不仅仅是了解为完成用户提出的要求是否有足够的资金支持(这是目前很多分析员重点要做的事情)，而更主要是把成本与获利分析清楚。也就是对经济合理性进行评价，即带来的经济效益是否超过其开发和维护所需要的费用。这工作包括估计费用和估计效益两个方面。可行性研究（续）可行性研究（续）估计费用。主要考虑以下几部分：设备费用，包括计算机硬件和软件的费用；人力费用，包括开发人员和维护人员的工资；材料费用；管理费用以及维护费用等。估计效益。可以
25、从以下几个方面考虑：提供了哪些以前提供不了的信息，提供信息的速度提高了多少？质量有什么提高？对使用者查询和使用信息的方便程度有什么提高，节省多少人力？对组织的领导人和管理人员正确做出决策提供了哪帮助？有时不能直接用金钱来衡量效益，如一个邮购单位，由于能够及时、准确地处理订货，缩短了顾客收到货物的时间，从而在竞争中得到了更多的顾客。这一类的收益就不容易用具体金钱来衡量，只能由管理人员根据经验来做出大约的估计。在估计效益时，要谨慎把各种可能影响效益发挥的各种因素考虑在内，打上折扣。3.操作和维护可行性人员操作和维护可行性的研究是了解当用户所要求的软件系统可行性研究（续）可行性研究（续）建立起来之后
26、 ，用户对它的操作是否方便？管理和维护是否容易？如果对于一个软件系统的操作比原有的手工系统还麻烦，那么它是不会受欢迎的。另一方面，如果管理和维护这个软件系统的人员比原来的手工系统还多，素质要求还高，那么这个系统对用户来说负担太重了。 对于人员操作和维护的可行性，一般可从两个方面来考虑：一方面从技术的角度，研究是否能够给用户提供一个方便的操作环境；另一方面从设备的选择上来考虑，看看为了完成用户要求的功能，是否能够找到一些易于管理和维护的设备。 从上面的讨论中不难看出，可行性研究的出发点应该是从当前的物理系统到新的物理系统的转换，它是整个可行性研究的基础，实际上也是整个系统开发过程的缩影。因为整个
27、系统实现过程也就是把当前的手工系统转化为可用计算机实现的新系统的一个转换过程，只不过这工作比在可行性研究阶段更细致，更具体罢了。 上述从三个方面分别开展的，而实际上它们之间有着密切的联系，因此还必须对它们综合考虑，然后向用户推荐方案供其选择。 可行性研究（续）可行性研究（续）当用户选定方案之后，分析员应对在问题定义阶段所规定的实现目标进行修改。因为，这时对系统有了更深入的了解，原来的问题定义可能有的不能实现，还有些需要加上去，也就是说原有的问题边界不够准确，需要纠正，以便今后有一个非常明确的工作目标。这是一步极有实质意义的工作，它使分析员和用户最后明确了要解决的问题的边界以及它的实现方案。一般
28、来说，可行性研究的结果可导致以下两种情况：(1) 可行()不可行可行性研究结束后，要写出可行性研究报告，提交有关专家论证和上级主管部门批准。可行性研究报告作为所有软件文件资料的基础材料，它的格式可以很不相同，但大体的内容提纲是一致的。 可行性研究（续）可行性研究（续）可行性研究报告的内容提纲： (1)背景情况 国内外水平、历史现状、市场需求。 （2)系统描述 总体方案和技术路线、课题分解、关键技术、计划目标和阶段目标。 (3)价格利益分析 经济可行性，包括经费概算和预期经济效益。 (4)技术冒险评价 技术可行性，包括技术实力、设备条件和已有工作基础。 (5)操作方便性评价 操作可行性，一方面从
29、技术的角度，另一方面从设备的选择上考虑。 (6)其他与项目有关的问题 根据可行性研究结果，如果是可行的，那么对这项开发工程就继续进行。此时，分析员应对开发工程制订一份软件计划。这样，开发工作转到下一阶段。第二课时第二章第二课时第二章第二课时软件计划软件工作范围（软件功能、性能、可靠性和接口等问题的描述）资源（软件、硬件与人力资源）成本估算代码行技术任务分解技术软件计划任务书的书写规范第三课时第二章第三课时第二章第三课时软件计划任务书案例学分管理系统软件计划任务书项目开发进度月报编写规范上述内容请参看书本相应页面的内容！返回第三章第一课时第三章第一课时需求分析的定义软件需求分析(软件要求分析)是
30、在可行性研究基础上进行的更细致的分析工作，是对软件计划阶段建立的软件工作范围的求精和细化。也就是在对软件计划阶段确定的工作范围内进一步对目标对象和环境作细致、深入的调查分析。需求分析过程实际上是一个调查研究、分析综合的过程，是一个抽象思维、逻辑推理的过程。通过调查研究和分析，充分了解用户对软件系统的要求。在此基础上，把用户要求表达出来，解决软件系统“做什么”的问题。也就是建立起系统的逻辑模型，把软件功能和性能的总体概念描述成具体的软件规格说明书。需求分析的目标（1.理清数据流或数据结构；2.通过标识接口细节，深入描述功能，确定设计约束和软件有效性要求；3.构造一个完全、精致的目标系统逻辑模型。
31、）需求分析的任务（认清问题、分析与综合、逻辑模型导出与复审）结构化分析方法结构化分析方法结构化分析方法结构化分析方法的策略基本的系统模型结构化分析方法策略分析.输入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、，可以沿着数据流程图从输出端往输入端回溯，能够确定每个数据项的来源，与此同时也就初步定义了有关的算法。 在第二步得到的高层数据流程图中，许多具体细节没有包括在里面。因此，当沿着数据流程图回溯时，经常会遇到：为了得到某个数据项需要用到数据流程图中目前还没有的数据项，或者得出这个数据项要用的算法还不完全清楚。为了解决这些问题，需要向用户和有关人员请教，他们的回答使分析员对新系统的认识更具体更深入了。系统中更多的数据项被划分出来，更多的算法被搞清楚了。一般把分析过程得到的有关数据项的信息、变换的算法简明地记在数据字典中。 （2）用户复查 通过沿着数据流程图的回溯过程，把一些数据项和变换的算法记录到数
37、据字典中。这个数据字典是否准确完整?算法是否正确?还有没有必要的变换和数据项遗漏了?某些数据项的来源搞清楚吗?结构化分析步骤（续）结构化分析步骤（续）对这些问题必须请系统的用户(直接在这个系统上工作的)对前面步骤得出的结果仔细地进行复查。可以借助于数据流程图和数据字典，从输入端开始向用户解释输入数据是怎样一步一步地转变成输出数据。这些解释集中反映了分析员通过前面分析工作，所获得的对新目标系统的认识。这些认识是否正确，有没有遗漏?应请用户及时纠正和补充分析员的认识。通过复查过程验证了已知的元素，补充了未知的元素。填补了文档中的空白。 由于复查可能获得新的知识，又可能引出新的问题。例如，对新补充进
38、来的数据项是怎样得出来的?它的来源是什么?这些需要进一步的调查访问寻求对问题的解答，而且还应及时修改和补充数据流程图和数据字典，把对系统的新认识及时记录下来。所以，追踪数据流程图和复查软件系统的逻辑模型实质上构成一个循环。对数据流程图的分析产生一些问题，这些问题通过复查得到的答案使分析员对系统有更深人更具体的认识，同时可能又引出新的问题，寻找这些新问题的答案导致了对新系统的更进一步的认识这样，每经过一次循环都会对新系统了解更多的细节。结构化分析（续）结构化分析（续）4.分解细化数据流程图 通过上面的分析及用户的复查，分析员对新系统已有了更进一步了解，此时可对数据流程图中的各个变换进行检查。如果
39、某个变换的功能还比较复杂，也就是还比较抽象，就应将这个变换功能分解成若干个子功能。这些较低层的子功能就成为一张新的数据流程图上的变换。在新的数据流程图中，也应该包括自己的数据流和数据存储。数据流程图经过分解之后，得到一组新的数据流程图，在图上，不同的软件元素之间关系变得更清楚了。对这组新的数据流程图的分析追踪可能产生新的问题，对这些问题的解答，又可能在数据字典中增加一些新的条目，并且可能导致新的或精化的变换算法的描述。随着分析过程的进展，经过问题与解答的反复循环，分析员越来越深入、具体地定义了新系统。通过上面各步就可以得到一套新目标系统的分层数据流程图和数据字典，也就是得到新系统的逻辑模型。第
40、四课时第三章第四课时第三章第四课时按功能逐层分解法(HIPO法)HIPO法的定义HIPO法组成图（参见书本上的相关内容）图（参见书本上的相关内容）第五课时第三章第五课时第三章第五课时软件需求分析报告书写规范（参见书本的相关内容）软件需求分析报告案例直通车系统的需求分析报告（参见书本相关内容）返回第四章第一课时第四章第一课时评价一个“设计”的标准（有一个明确的设计步骤、良好的设计方法、鉴别优劣的准则、好的设计表示）软件总体设计的任务（从软件的需求规格说明书出发，将设计对象用数据流或数据结构的形式表达成完整的抽象实体。这个实体应当是一个结构清晰、层次分明的模块组合，应当可以被评价和细化，也可以被修
41、改。同时还要定义这个实体与外部环境的接口。）软件总体设计的目标（1.软件实体应当具有明显的层次结构，便于软件元素之间的控制。2.软件实体应当模块化，这些摸块应具有完全独立的功能。3.软件实体与环境的界面应当清晰。4.软件设计的最终表示软件设计规格说明应当清晰、简洁、完整和无岐义。）软件设计的工作流程（请参见书本上相关内容）软件总体设计基础（模块、软件结构、层次机构的几个特点、结构图、结构图的优点）第二课时第四章第二课时第四章第二课时软件模块模块特点（抽象与封闭性）模块独立性的衡量（耦合和聚合）第三课时第四章第三课时第四章第三课时软件的总体设计准则1.评价软件初始结构，通过模块的分解与合并减少模
42、块之间的耦合度增加聚合度在设计初始软件结构以后，常常会发现几个模块的功能有相似之处，这相似部分不仅增加了编程和调试的工作量，同时也给维护过程带来麻烦，应当消除这样的重复。（1）完全相似这种情况只在数据类型上不一致，可采用完全合并，只需在数据类型的描述或变量定义上加以改进。（2）局部相似如图4-23(a)中，模块Q1和Q2具有功能类似的组成部分和不同部分可通过模块分解消除重复功能部分。其方法是首先找出模块Q1和Q2的功能相似部分，如图中的虚线部分，然后把这两个模块的虚线部分分离出来，构成它们的一个公共的下层模块Q，如图4-23(b)软件的总体设计准则（续）软件的总体设计准则（续）所示。如果分解后
43、余下的模块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.模块功能的完善一个完整的功能模块应具有以下三个要素：(1)执行某项指定功能的部分(2)如果需要返回一系列的数据给它的调用者，应在完成数据处理或结束时，
44、告诉它的调用者“文件完”或其他标志。(3)出错处理部分，即在不能完成指定任务时，必须将产生这种例外情况的原因(出错标志)通知它的调用者。它们是一个功能模块的有机组成部分，不应当分离到其他模块中去，否则会增加模块间的耦合。软件的总体设计准则（续）软件的总体设计准则（续）3.模块调用个数最好不要超过五个一个模块拥有的直属下级模块的个数叫模块的扇出数。如果一个模块具有过多的调用模块，那么这个模块扇出数就过大，如图4-25(a)，这个模块就往往包含过多的功能，一般是因为缺乏中间层次的控制模块，需要将其功能进行分解。如图4-25(b)。一个模块的直接上级模块的个数叫模块的扇入数。一个模块的扇入表明有多少
45、个上级模块直接调用它，扇入越大，则共享该模块的上级模块数目越多，这是有好处的。但不能违背模块独立性而单纯追求高扇入。4.一个模块的作用范围应在其控制范围之内一个模块的作用范围就是这个模块内一个判定的作用范围。一个判定的作用范围是指所有受这个判定影响的那些模块，只要模块中含有一些依赖于这个判定的操作，那么这个模块就在这个判定的作用范围之内。一个模块的控制范围包括它自己及其所有的下属模块。控制范围软件的总体设计准则（续）软件的总体设计准则（续）是从结构方面来考虑的，而作用范围是从功能方面考虑的。图4-26给出了不同的作用范围控制范围结构的实例，下面以此来讨论模块之间的联系。图 4-26 作用范围不
46、在控制范围之内图 4-27 判断所处层次太高图4-26说明作用范围不在控制范围之内，模块B2做出判定之后，若需要模块A工作就必须把信号回送给模块B、Y。这样就增加了数据的传送量和模块间的联系。因此，这是一个不好的设计。图4-27中作用范围是在控制范围之内，但判定所处层次太高（TOP），这样经过不必要的数据传送，增加了传送量，这个结构可以用，但不太好。图4-28 判定分支含有不必要的穿越图4-29 比较理想的结构软件的总体设计准则（续）软件的总体设计准则（续）图4-28中作用范围在控制范围之内，只有一个判定分支含有一个不必要的穿越，这是个较好的结构。图4-29中是一个较理想的好结构。如果在设计过
47、程中发现作用范围不在控制范围内时，可以通过下面手段将作用范围移到控制范围之内。(1)将包含判定的模块合并到它的调用模块中，这样可使判定处于足够高的层次。(2)将受判定影响的模块下移到控制范围之内。(3)将判定上移到足够高的位置。例如图4-30(a)中判定的作用范围不在控制范围之内。把含有判定的模块D合并到它的调用模块A中去，成了图4-30(b)所示。这样作用范围就处在控制之内。图4-30 将包含判定的模块合并到它的调用模块软件的总体设计准则（续）软件的总体设计准则（续）又如图4-31(a)中的模块x不在模块A的控制之内，把它下移到控制范围之内。如图4-31(b)所示。图4-31 将受到判定影响
48、的模块下移到控制范围之内5.力争设计单入口和单出口的模块，避免“病态联接”一个模块只有一个入口和一个出口时，这个模块是比较容易理解的，有利于结构化编制程序，也比较容易维护。但实际上这样的模块不多。病态联接是指转移到或引用到另一模块中去的内容耦合。要尽量避免这种病态联接，以减少模块间的耦合。6.力争降低模块接口的复杂性模块接口复杂性是软件发生错误的一个主要原因。因此，应该仔细设计模块接口，使得信息传递简单并且和模块功能相一致。为说明接口复杂性的影响，请看下面的例子。例如，求一元二次方程的根的模块QUAD-ROOT(TBL，x)其中用数组TBL传送方程的系数，用数组x回送求得的根。但是模块QUAD
49、-软件的总体设计准则（续）软件的总体设计准则（续）ROOT接口TBL和x意义不明确，不利于对这个模块的理解。因此可以将它简化如下：QUAD-ROOT(A,B,C，ROOT1，ROOT2)，其中，A，B，C是方程系数，ROOT1和ROOT2。是求出的方程的两个根。很明显，这样的接口既简单又与模块QUAD-ROOT的功能一致。在设计模块接口时，应尽量能设计这样的模块接口，以降低模块接口的复杂性。7.模块的大小模块大小就是模块含语句数量的多少。模块的大小没有统一的标准。一般来说，模块的大小以一页左右为宜。一页(高级语言50行左右)在一个人智力之内，比较容易阅读和理解。在进行模块设计时，首先应根据模块
50、的独立性来选取模块的规模。如果某个模块功能是独立的，那怕程序段较短也不要人为地加长；如果程序段只有一个独立的功能，那怕程序较长，也不要人为地把它分解成两个模块。第四课时第四章第四课时第四章第四课时结构化软件设计结构化软件设计的定义与特点结构化软件设计的类型变换设计事物型设计综合设计结构化软件设计步骤结构化软件设计案例返回第五章第一课时第五章第一课时软件详细设计的定义：对软件模块的过程设计。软件详细设计的任务：对总体设计所产生的功能模块进行过程描述，开发一个可以直接转换成程序语言代码的软件表示。软件详细设计的步骤：1.将总体设计产生的构成软件系统的各功能模块逐步细化，形成若干程序模块；2.运用详
51、细设计工具对程序模块进行过程描述；3.确定各个模块间的详细接口信息；4.编写详细设计说明书；5.详细设计评审。结构化程序设计：模块内过程的结构化设计应遵循下列准则：使用的基本逻辑结构应尽量少；用基本逻辑结构将过程组成的“块”应容易识别；每个“块”都应是单入口和单出口；设计要易于转换成程序代码且容易修改。第五章第一课时（续）第五章第一课时（续）基本逻辑结构（顺序、选择、直到与当型循环）结构的嵌套（是把结构化的复合语句当作一个简单的语句来看待）详细设计工具（图形化工具、表格化工具与语言工具）第二课时第五章第二课时第五章第二课时案例详细设计工具应用案例代码设计代码定义种类代码的设计原则代码效验第三课
52、时第五章第三课时第五章第三课时界面设计软件安全控制设计软件安全的概念软件安全的控制方法软件安全的控制设计软件详细设计文档书写规范返回第六章第一课时第六章第一课时源程序设计要求结构化程序设计定义原则程序设计风格：源程序文档化（标示符的命名、程序的注释、视觉组织 空格、空行与缩进）、数据说明、语句结构、输入与输出程序效率：效率准则、算法对效率的影响、影响存储效率的因素 、影响输入/输出的因素 、语言选择第二课时第六章第二课时第六章第二课时编码出错的预防代码复查编码工具程序复杂性的度量（上述项目的具体内容参见书本）返回第七章第七章第一课时第一课时测试的概念测试的目的1.测试是一个程序的执行过程，它的
53、目的在于发现错误；2.一个好的测试用例是极可能发现至今未发现的错误；3.一个成功的测试是发现了至今未发现的错误的测试。测试的原则1.避免由程序编写者自己进行测试，目的在于克服盲目的自信心和对功能要求误解的延续性；2.测试用例的设计和选择，预期结果的定义要有利于错误的检测。无效的、异常的、临界的或可能引起问题变异的输入条件比正常的输入条件更重要。测试用例不仅要检查程序是否做了应该做的事，还要检查它是否做了不应该做的事；3.应当尽早地不断地进行软件测试；第七章第七章第一课时（续）第一课时（续）4.测试用例应当由测试输入数据及与之对应的输出数据构成；5.应当制定严格的测试计划；6.应当注意测试中的群
54、集现象，即已经发现了错误的位置很可能还存在错误，要继续重点测试；7.应当对每一个测试结果做全面检查；8.妥善保存测试计划与测试用例，为以后的维护提供方便。测试方法：黑盒测试（等价划分、边界值分析、错误推测法、因果图法 ）；白盒测试（逻辑覆盖）第二课时第七章第七章第二课时第二课时测试用例设计实用测试策略测试的步骤调试软件测试报告返回第八章第一课时第八章第一课时软件维护的概念软件维护的类型与工作量比重适应性改正性维维护25% 护20%完善性维护50%其它维护5%影响维护工作量的因素1.系统大小；2.程序设计语言；3.系统年龄；4.数据库技术的应用；5.先进的软件开发技术；6.其他：例如，应用的类型
55、、数学模型、任务的难度、开关与标记、IF嵌套深度、索引或下标数等，对维护工作量都有影响。此外，许多软件在开发时并未考虑将来的修改，这就为软件的维护带来许多问题。第二课时第八章第二课时第八章第二课时软件维护的策略维护成本软件维护活动软件维护机构软件维护申请报告 软件维护工作流程维护档案记录维护评价第三课时第八章第三课时第八章第三课时程序修改的副作用与程序修改的步骤程序修改的步骤分析与理解程序修改程序程序修改的副作用重新验证程序软件的可维护性软件可维护性的定义软件可维护性的度量第四课时第八章第四课时第八章第四课时提高软件可维护性的方法建立明确的软件质量目标和优先级使用提高软件质量的技术和工具进行明
56、确的质量保证审查选择可维护的程序设计语言改进程序的文档第五课时第八章第五课时第八章第五课时逆向工程和再工程软件配置管理软件配置管理工具软件维护报告返回第九章第九章软件项目管理软件项目管理软件项目管理的概念资源管理组织体制人员配备进度计划图工程网络图软件项目的追踪与控制风险管理：风险识别、估计、评价、控制软件过程成熟度模型(CMMcapability Maturity Model)质量保证小项目的管理返回第十章第一课时第十章第一课时面向对象简介是一种全新的软件开发方法。它有以下特色：方法的唯一性，即方法是对软件开发过程所有阶段进行综合考虑而得到的；从生存期的一个阶段到下一个阶段的高度连续性，即在
57、一个阶段所用到的部分与在下一个阶段所使用的部分是衔接的，所使用的技术经过生存期每一阶段后不改变；把面向对象分析、面向对象设计和面向对象程序设计集成到生存期的相应阶段。几个概念面向对象对象类继承多态性第二课时第十章第二课时第十章第二课时面向对象的开发过程面向对象方法改进了在生存期各个阶段之间的界面，因为在生存期各个阶段所开发出来的“部件”都是类。在面向对象生存期的各个阶段对各个类的信息进行细化，类成为分析、设计和实现的基本单元。、应用生存期维护组装测试实例建立信息系统描述论域分析应用分析高层设计类开发客户输入第十章第二课时（续）第十章第二课时（续）、类生存期类生存期类规格说明从既存类演变渐增式的
58、实现渐增式的测试求精与维护类的复用从废弃型开发实现测 试 用例 与 测试开发、综合方法把应用生存期与类生存期放在一起，给出面向对象的应用开发过程。（1）分析阶段第十章第二课时（续）第十章第二课时（续）分析阶段包括两个步骤；论域分析和应用分析。它们都要标识问题论域中的抽象。在分析中，需要找到特定对象，根据对象的公共特性把它们组成集合，直到最后能够标识出对这个问题的一个抽象。在分析阶段中还要标识抽象之间的联系，在分析过程中标识的对象不是孤立的，在给定的问题环境中，对象与其他对象相互影响。这些相互影响就构成应用系统的结构中对象之间的联系。这些联系在应用系统中常常用对象之间的消息来表示，叫做消息连接消
59、息是一个对象发出的让另一个对象做某个动作的请求。在面向对象的应用中控制流由两部分构成：每个操作内部的控制流加上对象之间的消息模式。()论域分析论域分析开发应用论域的模型。论域分析应在应用分析前进行，因为在了解问题前应当对问题敞开思想考虑。客户可能会改变需求，第十章第二课时（续）第十章第二课时（续）而且问题环境也可能改变，所以，论域分析应考察问题论域内的一个较宽的范围，分析覆盖的范围应比直接要解决的问题更多。论域分析最大的价值是抽象的开发，这些抽象表示了个问题论域中的基本概念，它们形成的软件库还可支持许多应用的开发。()应用分析应用(或系统)分析细化在论域分析阶段所开发出来的信息，并且把注童力集
60、中于当前要解决的问题。在分析阶段中有一些不能映像到设计阶段的类，这些类表示了落到应用分析外面的信息。因为通过论域分析，分析人员具有了较宽的论域知识，因而能开发出更好的抽象。传统的方法学人为地把系统分析与设计过程分离开来，这就把系统设计和开发人员与对问题了解最清楚的专家隔离开来。面向对象应用分析阶段是一个迭代的过程。分析阶段标识了在问题论域中的实体。可以使用在问题陈述中的名词作为对象。对象容易标识，这是因为问题论域容易访问。第十章第二课时（续）第十章第二课时（续）在系统分析与高层设计之间的界限逐渐变得模糊。分析员常常考察一个问题论域并注重抽象的概念，而不是只看单独的对象。例如，在空中交通控制系统
61、中，分析员不可能也不能指望标识每一架单独的将由系统处理的班机。必须标识班机概念，并把它作为该问题论域的一个重要的概念。（2）高层设计在一个纯面向对象环境中，系统设计与类设计常常处于同一过程中，但还是应当把系统与类的设计分开。在高层设计阶段，设计应用的顶层视图。这相当于开发一个表示系统的类的界面。通过建立一个应用类的实例并发送一个消息给它来完成系统的执行。（3）类的开发设计阶段基本上是类的开发，因为一个应用往往是用一个类表示，它亦可分成几个类。高层设计将标识对各个类的要求，且给出类的定义。这个阶段贯穿于类的生存期结果是一组类，它们的开发独立于待开发的应用，但可支持该应用。第十章第二课时（续）第十
62、章第二课时（续）（4）实例的建立这个阶段的结果就是对问题的最后解决。它集中在类的开发，这些类表示了解决的各个局部在此阶段，要建立对象的实例，这些对象对应于在分析阶段所标识的实体。在论域分析阶段所标识的联系是应用级的联系这些联系通过实例之间传送的消息来表示开发的最后一部分是建立实例之间的通信通道。这些通道可以通过把引用从一个对象传递到另一个对象来建立。（）组装测试这一阶段把系统组装成一个完整的应用来进行测试；各个类的封装和类测试的完备性可减少组装测试所需要的时间。面向对象应用的界面通常可像单个对象的界面那样进行定义。充分隔离单个操作，减少改变操作的次序所造成的综合影响。（6）应用维护第十章第二课
63、时（续）第十章第二课时（续）维护的要求将影响应用和各个类。继承联系可帮助扩充现有的应用，加入新的行为，或者改变某些行为的工作方式。信息隐蔽使得能在单个的类中调试一个代码过程而不致像水中的涟漪那样扩散，波及系统中的许多类。应用的维护包括在系统的操作中定位故障、在现有的系统中加入新的行为，有些缺陷产生于类实例间的不合格的连接，即不合理的消息应用的维护能够简化对类实例的定位、修改其类的实现、通过改变消息或接收消息的次序来改变应用中特殊对象的角色新的行为可通过定义新的类和建立实例来实现。多数维护活动发生在类级。把类的实现与其规格说明分离可局部化修改的影响。为了修正问题要求对类的界面做出改变的情况很少见
64、。然而，为了在系统中增加新的行为，偶尔改变界面的需求还是会有的。第三课时第十章第三课时第十章第三课时系统体系结构一个面向对象系统的体系结构通过它的成分对象和对象间的联系来确定。这种体系结构反映了问题论域，因为它主要由问题论域的对象构成。图9-6显示了一个系统的对象与处理体系结构间的相互影响。从软件库到独立的处理画出几根线，表明处理的内部由几个不同类的实例构成，而一个类可能为几个处理提供实例。在传统的开发模式情形下，把应用分成几个处理。需要设计面向处理的体系结构，建立问题论域的模型。若基础的硬件、编译器或操作系统改变，则处理的体系结构可能也需要改变。因此，把它移植或提到新的环境需要花费一定的代价
65、。而面向对象范型中的对象的体系结构是对问题论域的对象进行模型化，因此，设计相对稳定。同时可把对问题论域的考虑与环境相关的考虑分开。图9.7表明，类的软件库独立于处理的体系结构。一个类的实例可能出现在几个不同处理中，也可能仅出现在一个处理中。 类的抽象特性提供了模块化体系结构。把类的实现与它的界面第十章第三课时（续）第十章第三课时（续）分离，系统的行为可以相对容易地彻底改变例如应用用户界面的各个实例进行代换，可以得到不同的界面引入不同类的实例，可以提供不同的调度算法或不同的存储模式体系结构还要反映对象之间发送的消息，它应是很灵活的。客户-服模型比较容易实现和动态地修改。保持问题的体系结构模型将有助于重新配置以满足在问题论域中的改变。面向对象分析与高层设计面向对象分析、面向对象分析(OOA)、论域分析 、应用分析、面向对象模型技术高层设计 第四课时第十章第四课时第十章第四课时类的设计类设计的目标通过复用设计类类设计方法类设计的一个案例类的实现与测试应用程序的实现返回
