软件工程基础全套教学课件

软件工程基础第1章软件工程概述.pptx第2章可行性研究.pptx第3章需求分析.pptx第4章总体设计.pptx第5章详细设计.pptx第6章软件编码与测试.pptx第7章维护.pptx第8章面向对象设计.pptx第9章软件项目管理.pptx第10章软件产业前景.pptx全套可编辑PPT课件1.软件的概念12程序文档程序是实现相应功能的一些指令代码序列。文档是与软件开发、维护和使用有关的图文材料。程序≠软件软件2.软件的特点特点06010403软件的价值无法估量。软件是一种逻辑实体。软件的开发是一个复杂的过程件的开发对计算机系统有着不同程度的依赖性，有时甚至还需考虑社会因素。05软件在维护上也有本质差异。02软件是通过人的智力的高度发挥开发而成的。系统软件应用软件按软件的功能划分应用软件有商业数据处理软件、工程与科学计算软件、计算机辅助设计/制造软件、系统仿真软件等系统软件有操作系统、数据库管理系统等，如Windows7.0、VisualFoxPro8.0等。3.软件的类型按软件规模划分微型小型中型大型参加人员数1，研制期限1～4周。参加人员数2～5，研制期限1～12月。参加人员数5～20，研制期限1～2年。参加人员数＞20，研制期限＞2年。3.软件的类型3.软件的类型实时处理软件1423按软件工作方式划分分时处理软件交互软件批处理软件12按软件服务对象的范围划分项目软件（定制软件）产品软件（通用软件）4.软件发展史20世纪60年代中期～70年代中期20世纪70年代中期～80年代中期20世纪60年代中期以前20世纪80年代中期至今程序设计阶段。在20世纪60年代末期出现了“软件危机”。程序系统阶段——“软件工程”学科诞生。软件工程阶段。软件过程化、软件产业在世界经济中已经占有举足轻重的地位。1.软件危机概述20世纪60年代以前60年代中期1968年软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，采用密切依赖于计算机的机器代码或汇编语言，软件的规模比较小，文档资料通常也不存在，很少使用系统化的开发方法。大存储容量、高速度计算机出现，使计算机的应用范围迅速扩大，软件开发急剧增长。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出“软件工程”一词。从此，一门新兴的工程学科——软件工程学，为研究和克服软件危机应运而生。以前开发的一些软件如何维护？面对硬件技术不断发展，如何开发软件？软件危机是指在计算机软件开发和维护过程中碰到问题的集合。1.软件危机概述2.软件危机典型表现软件开发费用和进度失控1软件的可靠性差2生产出来的软件难以维护380年代后期，软件危机不仅没有消失，还有加剧之势软件成本比例居高不下，且逐年上升由于微电子学技术的进步和硬件生产自动化程度不断提高，硬件成本逐年下降，性能和产量迅速提高。然而软件开发需要大量人力，软件成本随着软件规模和数量的剧增而持续上升。

软件产品供不应求软件开发生产率提高的速度远远跟不上计算机应用迅速普及深入的需要，软件产品供不应求的状况使得人们不能充分利用现代计算机硬件所能提供的巨大潜力。2.软件危机典型表现3.软件危机产生的原因4123软件危机产生原因在一个软件漫长的维护期中，必须及时改正软件在使用中出现的错误，给用户一个满意的回答。轻视软件维护编程只是软件开发过程的一个小阶段，一般占软件总成本的10%～30%，甚至更少。缺少规范而盲目上阵编写程序是不可取的。开发过程没有统一、规范的方法做指导，文档资料不齐全许多软件开发人员不能正确地理解用户的需求，甚至根本不去深入了解用户的需求。忽略软件需求分析忽视测试工作一般来讲，软件测试占软件开发总成本的30%～50%。运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法。软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。软件工程定义1.3.1BarryBoehmIEEEFritzBauer计算机科学技术百科全书“”软件工程是研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并且满足用户需求的软件产品。软件工程目标1.3.2软件工程过程1.3.3包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。实现活动设计活动需求活动确认活动维护活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构。详细设计产生程序员可用的模块说明。把设计结果转换为可执行的程序代码。贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。包括使用过程中的扩充、修改与完善。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认及维护等活动。软件工程原则1.3.4（1）选取适宜开发模型必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。（2）采用合适的设计方法在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。（3）提供高质量的工程支持软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。（4）重视开发过程的管理软件工程的管理直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。软件工程原则软件开发模型软件过程软件开发环境软件经济学软件开发方法软件工具计算机辅助软件工程（CASE）软件工程学科的研究内容软件工程与其他相关学科的关系1.3.5软件工程知识体系结构计算机科学工程科学应用领域数学原理管理科学软件工程计算机科学、数学、工程学和管理学等基本原理应用于软件开发的工程实践中，并借鉴传统工程的原则和方法，以系统的、可控的、有效的方式生产高质量的软件。软件工程以计算机科学和数学为基础，在管理学科的支撑下，运用工程的思想和要求将这些学科的基本原理应用于研制软件的算法和模型，力求提出更系统化和更形式化的软件开发方法，并采用适当的方法验证开发的软件，以达到软件开发的最佳效果。软件工程方法学1.3.6方法工具过程软件工程方法学三要素软件工程方法是指要开发一个成功的软件，在各阶段中所涉及的技术方法总和，为软件开发提供了“如何做”的技术。软件工程的过程是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。软件工程的工具是为了实现软件开发的各项技术，所需提供的自动的或半自动的软件支撑环境。AB面向过程方法学面向对象方法学也称为生命周期方法学或结构化范型。它是一种传统的软件工程方法学，采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。它是把数据和行为看成是同等重要的，以数据为主线，把数据和对数据的操作紧密地结合起来的方法。4个要点：（1）把对象看为融合了数据及在数据上操作行为的统一的软件构件；（2）把所有对象都划分成类（3）按照父、子类的关系，把若干个相关类组成一个层次结构的系统；（4）对象彼此间仅能通过发送消息相互联系。C敏捷开发方法这种方法认为，开发方法就是解决问题的过程，不管采用哪种方法，无异于在实践中总结经验和方法，敏捷开发方法就源于开发实践的总结。软件定义期1包括问题定义、可行性分析、需求分析三个阶段软件开发期2可分为总体设计、详细设计、编码与测试四个阶段软件运行与维护期3软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程，一般称之为计算机软件的生存期。软件设计

需求分析

问题的定义及可行性分析此阶段由软件开发方与需求方共同讨论，主要确定软件的开发目标及其可行性。需求分析是在确定软件开发可行的情况下，对软件需要实现的各个功能进行详细分析。我们必须制定需求变更计划来应付这种变化，以保护整个项目的顺利进行。此阶段主要根据需求分析的结果，对整个软件系统进行设计，如系统框架设计、数据库设计等。软件设计一般分为总体设计和详细设计。123运行维护软件测试

程序编码此阶段是将软件设计的结果转换成计算机可运行的程序代码。在程序编码中必须要制定统一、符合标准的编写规范，以保证程序的可读性、易维护性，提高程序的运行效率。整个测试过程分单元测试、集成测试及系统测试三个阶段进行。测试的方法主要有白盒测试和黑盒测试两种。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试，以减少测试的随意性。软件维护是软件生命周期中持续时间最长的阶段。要延续软件的使用寿命，就必须对软件进行维护。软件的维护包括纠错性维护和改进性维护两个方面。456软件开发过程模型在软件开发过程中，任何一个软件工作者都希望有一套针对软件开发全部过程、活动和任务的结构框架，这个框架能直观地表达软件开发全过程，能明确规定要完成的主要活动、任务和开发策略，这就是软件开发模型，也称软件过程模型、软件生命周期模型。1.瀑布模型传统瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。实现的瀑布模型应该是可以反馈的。当有一个稳定产品定义和很容易被理解的技术解决方案时瀑布模型适用场合当对一个定义得很好的版本进行维护或将一个产品移植平台时当需要能够降低管理费用并可以预先完成所有计划时对于那些容易理解但很复杂的项目当质量需求高于成本需求和进度需求时当开发队伍的技术力量比较弱或者缺乏经验时2.快速原型模型快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前构造一个原型，在该原型的基础上逐渐完成整个系统的开发工作。快速原型模型第一步：建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求，通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么。第二步：在第一步的基础上开发客户满意的软件产品。快速原型模型优点克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。这种模型适合预先不能确切定义需求的软件系统的开发。缺点（1）所选用的开发技术和工具不一定符合主流的发展；（2）快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。3.增量模型增量模型也称渐增模型，它把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成并能够完成特定的功能。增量模型分批地逐步向用户提交产品，整个软件产品被分成许多个增量构件，开发人员一个一个地以构件向用户提交产品。增量04030201完成高级的页面布局功能实现拼写和文法检查功能完善的编辑和文档生成能力基本的文件管理、编辑和文档生成功能，它是最核心的增量4.螺旋模型该模型中加入了风险分析，通常用来指导大型软件项目的开发，这种模型沿着螺旋线旋转，采用4个描述分别表达制定计划、风险分析、实施工程、客户评估4个方面的活动。螺旋模型螺旋模型采用一种周期性的方法来进行系统开发，这会导致开发出众多的中间版本。项目经理在早期就能够为客户证实某些概念。

该模型是快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发就前进一个层次。5.喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。喷泉模型喷泉模型体现了软件创建所固有的迭代和无间隙的特征，是典型的面向对象的软件过程模型之一。“喷泉”这个词体现了面向对象软件开发过程迭代和无缝的特征。每一阶段中的圆圈相互重叠，表示两个活动之间存在交迭。6.Rational统一过程Rational统一过程Rational统一过程（RationalUnifiedProcess，RUP）是由Rational公司推出并维护的一个软件过程产品，至今已有30多年的历史，目前市面上已有很多版本。目前，全球有上千家公司在使用Rational统一过程，如Xerox、Volvo、Intel、Visa、Oracle等，它们分布在电信、交通、航空等不同的行业和应用领域，Rational统一过程有着多功能性和广泛的适用性。从软件过程模式的角度来说，RUP对软件过程模式中的四大要素及相互关系进行了详尽的论述：在“生命周期”方面，RUP构架了一个迭代与增量的二维生命周期结构。其横轴为生命周期的四个阶段——初始、精化、构建和移交，各阶段结束于一个项目里程碑，纵轴为九个核心工作流程——业务建模、需求、分析设计、实现、测试、部署、配置与变更管理、项目管理、环境。“人员”方面RUP定义了“角色”概念，并从角色视角对不同人员从事的不同活动进行了规范。“方法”方面RUP采用UML进行可视化建模、基于用例驱动且以构架为中心的分析设计，并且进一步为整个过程提供了一整套支持各种方法和技术实施的开发工具——RationalSolutions。“产品”方面RUP将各种中间和最终产品称之为“工件”，对不同工作流程中的输入、输出工件类型进行了规范，同时提供了多种工件的模板。Rational统一过程7.敏捷过程2001年2月，17个方法学家发起成立了敏捷软件开发联盟，通常简称敏捷联盟（AgileAlliance）。

敏捷联盟的成员将宣言价值观中表达的基本原理精炼为12条原则，这4条价值观和12条原则构成了敏捷过程（AgileProcess，AP）应遵循的标准。敏捷过程“产品”方面“生命周期”方面敏捷过程提倡“经常性地交付可用软件，从几个星期到几个月，尽可能做到较短的时间间隔”。“人员”方面定义了产品管理、程序管理、开发、测试、用户体验、发布管理6种角色，其中最具特色的是程序管理角色。“方法”方面对软件过程各阶段提出了一系列具可操作性的方法。敏捷过程规范了各阶段的输入输出产品，包括项目前景/范围说明书、功能说明书、源代码、测试说明书与测试用例等。。8.微软过程微软过程（MicrosoftProcess，MP）是由微软公司根据自身实践经验为企业设计的一套有关软件开发的准则。从软件过程模式的角度分析，微软过程也是紧密围绕软件过程模式中的四大要素及相互关系展开论述的，其开发周期如右图所示。“产品”方面“生命周期”方面微软过程分为构想、计划、开发、稳定和发布五个阶段，各阶段结束于一个主要里程碑，同时采用递进的版本发布策略“人员”方面敏捷过程提出“个体和交互胜过过程和工具”，同时强调客户的重要性，指出“客户合作胜过合同谈判”“方法”方面敏捷过程提出了简单化方法和面对面的交流工作方法。微软过程敏捷过程声明“可以工作的软件胜过面面俱到的文档”。瀑布模型快速原型模型增量模型螺旋模型喷泉模型Rational统一过程敏捷过程微软过程传统生命周期模式下的开发模型比较现代型软件开发过程的模式相对软件生命周期模型而言，软件过程模式这一概念的提出有如下理论和现实意义。软件过程模式不仅关注软件过程中各生命周期阶段中的活动，更重要的是它同时关注过程中的人员与角色分配、过程中采用的方法及过程各阶段的输入输出产品，认为软件过程中这四大要素相辅相成、相互作用，从而构成一个有机的整体，缺一不可。从软件过程模式的角度分析几种最新的、颇具影响力的软件过程，能迅速、准确地把握这些软件过程的思想本质、原则规范、主要特点和实现策略等各个方面。软件工程基础1.研究目的目的任务可行性研究不是解决问题，而是确定问题是否值得去解决。针对具体的问题用最小的代价、在尽可能短的时间内确定问题是否能解决。2.研究任务考虑方面经济可行性技术可行性操作可行性对技术做综合评估1技术方案的选择2技术的成熟程度的技术；市场技术需求；技术转换成本；支撑体系与条件；技术发展趋势及所采用技术的发展前景。制约条件：需求制约、资源制约、环境制约；技术选择原则：经济性原则、发展原则、兼容性原则、相关效果原则；选择视角：技术先进性、技术适用性。考虑方面操作可行性经济可行性技术可行性成本分析1效益分析2在成本方面，可将成本分为开发成本、安装成本、运行成本。效益包括直接效益、可见的间接效益、不可见的效益。考虑方面技术可行性操作可行性经济可行性现代社会是法制社会，在软件开发中还需从法律、社会效益等更广泛的方面研究每种解法的可行性。分析员应该为每个可行的解法制定一个粗略的实现进度。问题没有可行的解问题值得解决

分析员应该推荐一个较好的解决方案，并且为工程制订一个初步的计划。可行性研究需要的时间长短取决于工程的规模。分析员应该建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费。

可行性研究需要的时间长短取决于工程的规模。一般说来，可行性研究的成本只是预期的工程总成本的5%～10%。导出新系统的高层逻辑模型研究目前正在使用的系统

复查系统规模和目标在可靠性研究阶段，系统分析员要进一步分析和研究有关材料，对规模说明书进行仔细客观的审查，修改规格说明书中描述不准确的地方，准确地给出系统的所有约束，以保证系统将要解决的问题确实是需要解决的问题。现有正在使用的系统是信息的最重要来源，应该仔细阅读分析现有系统的文档资料和使用手册，也要实地考察现有系统，应该注意了解这个系统可以做什么，为什么这样做，还要了解使用这个系统的代价。优秀的设计过程通常从现有物理系统出发，导出现有系统的逻辑模型，再参考现有系统的逻辑模型，设想目标系统的逻辑模型，最后根据目标系统的逻辑模型建造新的物理系统。123推荐行动方针导出和评价供选择的解法进一步定义问题分析员应该和用户一起再次复查问题定义、工程规模和目标，对问题进行认真审定，不断循环这个过程，直到提出的逻辑模型完全符合系统目标。此过程分析人员应该从建议的系统逻辑模型出发，导出若干个较高层次的物理解法供比较和选择。从技术可行、操作可行及经济可行三个方面对多个解法进行删除，最终确定一种方案。通过上面的工作，系统分析员应给出定论：新系统是否值得开发。如果系统分析员认为新系统值得开发，就选择一个他认为最优的实现方案，并较详细地说明选择它的理由。此外，还应对它进行较细的技术、操作、经济方面的可行性分析，作为提交给决策者的推荐方案。456书写文档提交审查草拟开发计划78系统分析员应为推荐的实施方案拟订一份开发计划，给出对各类开发人员和各种资源（包括硬件和软件等）的使用计划，估算出新系统在开发各阶段的开发成本，并详细制订进度表和经费预算表。。应该把上述可行性研究各个步骤的工作结果写成清晰的文档，请用户、客户组织的负责人及评审组审查，以决定是否继续这项工程及是否接受分析员推荐的方案。这份文档即为可行性报告。1引言1.1编写目的1.2背景1.3定义1.4参考资料2可行性研究的前提2.1要求2.2目标2.3条件、假定和限制2.4进行可行性研究的方法2.5评价尺度3对现有系统的分析3.1处理流程和数据流程3.2工作负荷3.3费用开支3.4人员3.5设备3.6局限性4所建议的系统4.1对所建议系统的说明 4.2处理流程和数据流程4.3改进之处4.4影响4.4.1对设备的影响4.4.2对软件的影响4.4.3对用户单位机构的影响4.4.4对系统运行过程的影响4.4.5对开发的影响4.4.6对地点和设施的影响4.4.7对经费开支的影响4.5局限性4.6技术条件方面的可行性5可选择的其他系统方案5.1可选择的系统方案一5.2可选择的系统方案二6投资及效益分析6.1支出6.1.1基本建设投资6.1.2其他一次性支出6.1.3非一次性支出6.2收益 6.2.1一次性收益6.2.2非一次性收益6.2.3不可定量的收益6.3收益/投资比6.4投资回收周期6.5敏感性分析 7社会因素方面的可行性7.1法律方面的可行性7.2使用方面的可行性8结论可行性研究报告的基本内容参考系统流程图系统流程图是描绘物理系统的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件（程序、文件、数据库、表格、人工过程等）。系统流程图表达的是部件的信息流程，而不是表示对信息进行加工处理的控制过程。符号2.3.1符

号名

称说

明处理能改变数据值或数据位置的加工或部件，如程序、处理机、人工加工等都是处理输入输出表示输入或输出（或既输入又输出），是一个广义的不指明具体设备的符号连接指出转到图的另一部分或从图的另一部分转来，通常在同一页上换页连接指出转到另一页图上或由另一页图转来数据流用来连接其他符号，指明数据流动方向XITONGLIUCHENGTUO基本符号XITONGLIUCHENGTUO系统符号符

号名

称说

明穿孔卡片表示用穿孔卡片输入或输出，也可表示一个穿孔卡片文件文档通常表示打印输出，也可表示用打印终端输入数据磁带磁带输入输出，或表示一个磁带文件联机存储表示任何种类的联机存储，包括磁盘、磁鼓、软盘和海量存储器件等磁盘磁盘输入输出，也可表示存储在磁盘上的文件或数据库磁鼓磁鼓输出输出，也可表示存储在磁鼓上的文件或数据库显示CRT终端或类似的显示部件，可用于输入或输出，也可既输入又输出人工输入人工输入数据的脱机处理，如填写表格人工操作人工完成的处理，如会计在工资支票上签名辅助操作使用设备进行脱机操作通信链路通过远程通信线或链路传送数据系统流程图实例分析2.3.2利用图书管理系统对图书记录进行统一管理，包括新增图书记录、更改图书记录、删除图书记录等功能，实现图书管理工作的系统化、规范化和自动化。右图为图书管理系统的总体业务流程图。图中每个符号用黑盒子形式定义了组成系统的一个部件，然而并没有指明每个部件的具体工作过程；图中的箭头确定了信息通过系统的逻辑路径（信息流动路径）。分层2.3.3分层分层应用于复杂的系统，用一幅高层次的系统流程图描绘概貌，然后分别把每个关键功能扩展到适当的详细程度，画在单独的一页纸上，分层次地逐步描述。按书名查询显示所有书名相同的图书信息按编号查询一次只显示一本书按作者名查询显示所有作者名相同的图书按出版社查询显示出所有出版社相同的图书查询所有图书显示出所有图书的信息成本/效益分析开发一个软件系统也是一种投资，期望将来获得更大的经济效益。经济效益通常表现为减少运行费用或增加收入。成本/效益分析的目的是从经济角度评价开发一个新项目是否可行、是否划算，从而帮助使用部门的负责人正确地作出是否投资这个项目开发的决定。成本估计2.4.1基于计算机的系统成本04030201人员培训费系统安装、运行和维护费系统开发费购置并安装软件/硬件等有关设施费基于已完成的类似项目进行估算1使用简单的“分解技术”进行成本及工作量的估算2使用经验模型进行成本及工作量的估算3估算项目成本工作量的方法一般着眼于软件系统的整体，根据以往经验通过类比的方式来估计新开发软件所需的成本和工作量，也可称为自顶向下的成本估计方法。一般将开发任务分解成内容足够明确的任务单元，然后估算各任务单元的成本，再汇合成项目的总成本，可称之为自底向上的成本估计方法。采用历史数据导出的经验模型来预测项目所需的成本、工作量和进度等，可形成自动估算工具，并结合前面两种方法进行估算。1.代码行技术代码行技术代码行技术属于自底向上的成本估计方法。通常先根据经验和历史数据来估计实现一个功能所需要的源程序行数，然后估算每行代码的平均成本，最后累加起来得出软件开发的总成本。这种方法是一种比较传统的方法，对涉及全局的花费（如质量管理）可能估计不足甚至完全忽视，使成本估计可能偏低。2.任务分解技术任务分解技术该方法首先把软件开发工程分解为若干相对独立的任务，再分别估计每个单独的开发任务的成本，最后累加起来得出软件开发的总成本。这种方法的优点是工作量小，速度快；不足之处是对开发中某些局部问题或特殊困难情况易低估，甚至没有考虑。如果所开发的软件缺乏可借鉴的经验，则估计偏差可能较大。任

务人

力可行性分析需求分析设计编码和单元测试综合测试5%10%25%20%40%总

计100%估计每个任务的成本时，通常先估计完成该项任务所需要使用的人力（以人月为单位），再乘以每人每月的平均工资而得出每个任务的成本。划分任务时最常用的办法是按开发阶段进行，右表给出了典型环境下各个开发阶段所需的人力资源。实际上此表还可以进一步进行细分。3.自动估计成本技术自动估计成本技术采用自动估计成本的软件工具估算成本，可以减轻人的劳动，并且使得估计的结果更客观。

但是采用这种技术必须有长期搜集的大量历史数据为基础，并且需要有良好的数据库系统支持，否则分析的准确度会很低。效益分析的方法2.4.212经济效益社会效益经济效益是指使用新系统而增加的收入，包括使用新系统节省的运行费用，可采用货币的时间价值、纯收入、投资回收期、投资回收率等技术来度量。社会效益是一种无形的效益，主要从性质上、心理上进行衡量，很难直接量化，但在某些情况下，无形的效益可转化为有形的效益。效益效益分析的方法41按照银行利息计算相似的方法来计算投资回收率，用它衡量投资效益的大小。货币的时间价值一般来讲，投资在前，取得效益在后，因此必须考虑货币的时间价值。2投资回收期投资回收期是使累计的经济效益等于最初投资所需的时间。投资回收期应越短越好，其值为使累计的经济效益等于最初投资所需要的时间。3纯收入就是在整个生命周期之内系统累计经济效益（折合成现在值）与投资之差。投资回收率纯收入1.货币的时间价值货币的时间价值通常用利率的形式表示。假设年利率为i，如果现在存入P元，则n年后可以得到的钱数为：反之，如果n年后能收入F元钱，那么这些钱的现在的价值是：实例分析开发软件的费用一般如下，这里只对开发费用和每年运行费用进行分析。案例1（1）开发费用（1次）系统人员经费：2名系统分析员（450小时/名，45美元/小时） $40500 5名系统开发人员（275小时/名，36美元/小时）

$49500 1名数据通信专家（60小时/名，42美元/小时）

$2400 1名数据库管理员（30小时/名，42美元/小时）

$1260 2名技术写作者（120小时/名，25美元/小时） $6000 1名秘书（160小时/名，15美元/小时） $2400 2名在转换期间数据输入人员 $49500（1）开发费用（1次）培训费用：3天的开发人员内部培训课程 $7000 30个用户，3天的内部培训课程 $10000物资费用：复印 $500

磁盘、纸张等消耗品 $650购买硬件、软件费用：20台工作站Windows软件 $1000 20台工作站内存升级 $8000

网络软件 $17500 20台工作站办公软件产品

$20000

系统开发总费用

$161670（2）运行费用（每年）维护程序员/分析员（250小时/年，42美元/小时） $10500网络管理员（300小时/年，50美元/小时） $15000购买硬件、软件升级：硬件 $5000

软件 $6000物资和杂项： $3500每年总运行费用

$40000假设某软件生命周期为5年。现在投资20万元，平均年利率3%。从第一年起，每年年底收入4.2万元，问该项目是否值得投资？案例2到第5年底结算时，投资额及收入如下：投资额=200000×（1+3%）5=231855（元）收入=42000×[（1+3%）4+（1+3%）3+（1+3%）2+（1+3%）+1]=222984（元）。不合算软件工程基础需求分析的基本任务是准确地回答系统必须做什么。问题分析1分析与综合2编制需求分析文档3需求评审4这个问题是通过系统分析员与用户一起商定的，清晰、准确、具体地描述软件产品必须具有的功能、性能、运行规格等要求。软件需求分析阶段的目的是明确用户的要求，并把双方共同的理解明确地表达成一份书面文档——软件需求规格说明书。需求分析各组成部分及相互间的关系如右图所示。1.确定对系统的综合要求4123对系统的综合要求运行要求集中表现为对系统运行时所处环境的要求。例如，支持系统运行的系统软件是什么等。运行要求联机系统的响应时间，系统需要的存储容量及后援存储，重新启动和安全性等方面的考虑都属于性能要求。系统性能要求应该划分出系统必须完成的所有功能。系统功能要求将来可能提出的要求应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。2.分析系统的数据要求必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立概念模型的方法。复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和Warnier图。为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。3.导出系统的逻辑模型系统详细的逻辑模型描述方法数据流图实体联系图状态转换图数据字典主要的处理算法4.修正系统开发计划根据在分析过程中获得的对系统更深入、更具体的了解，可以较准确地估计系统的成本和进度，修正以前制订的开发计划。5.开发原型系统“样机”（更正确的名称应该是原型系统）建造样机建造样机通常有两个主要目的：检验关键设计方案的正确性及系统是否真正满足用户的需要。使用样机对于软件系统的开发，使用样机的主要目的是，使用户通过实践获得关于未来系统将怎样为他们工作得更直接、更具体的概念，从而可以更准确地提出和确定他们的要求。01由于人类认识能力的局限，不能预先指定所有要求；02在用户和系统分析员之间存在固有的通信鸿沟；03用户需要一个“活的”系统模型，以便获得更多潜在的实践经验；04在开发过程中重复和反复是必要的和不可避免的；05目前有快速建立原型系统的工具可供选用。把建立原型系统作为一种可能采取的策略的主要理由一次设计后大批量生产的产品软件在软件开发中采用样机策略的主要困难是成本问题特别是应用软件，通常一次只开发出一件产品，采用样机策略则成本增加很多，因此过去很少采用这种策略。如计算机硬件和绝大多数工业产品），设计和制造样机的费用可以分摊到每件产品上，因此每件产品的成本增加很少。近年来不仅在验证软件需求时使用软件原型，原型法还逐渐发展成为开发软件的一种重要方法。功能需求定义了系统应该做什么，系统要求输入什么信息，输出什么信息，以及如何将输入变换为输出。功能需求性能需求则定义了软件运行的状态特征，如系统运行效率、可靠性、安全性、可维护性等。性能需求用户需求需求分析的前提是准确、完整地获取用户需求。应该获取用户需求的内容06010403系统维护要求物理环境数据要求系统功能05系统文档规格02系统界面在获取上述需求过程中可能遇到以下典型问题。如何理解问题？大多数情况下，软件开发人员不是问题领域的行家，但是要准确、完整地获取需求，就必须对问题具有深入的理解与把握。分析员与用户的通信问题？与用户建立相互信任、有效的沟通是分析员的首要任务。用户需求的可变性？影响用户需求变化的因素可能是用户领域的业务扩充或者转移，市场竞争的要求，用户主管人员的变更等。抽象分解为了将现实世界中问题的求解映射为信息处理模型，对问题进行分解与抽象是普遍有效的基本法则分解是将复杂问题求解分解为若干相对简单问题求解的组合。分解的目的是降低问题求解的复杂性。如果子问题仍然较复杂，则可以进一步分解。抽象是认识问题的一般与特殊的关系。获取需求的方法结构化分析方法面向对象分析方法包括面向数据流的结构化分析方法，面向数据流结构的Jackson方法和面向数据结构的结构化数据系统开发方法。面向对象的分析方法按照需求分析建立的模型的特性又分为静态分析方法和动态分析方法。结构化分析12345通过对用户的调查，以软件的需求为线索，获得当前系统的具体模型；去掉具体模型中的非本质因素，抽象出当前系统的逻辑模型；根据计算机的特点分析当前系统与目标系统的差别，建立目标系统的逻辑模型；完善目标系统并补充细节，写出目标系统的软件需求规格说明；评审，直到确认完全符合用户对软件的需求；项目经理沟通关系与领导沟通与项目组成员沟通与客户沟通项目组内部的沟通是开发出有质量保障的软件的基础。项目成员间的沟通方式有Email、会议、电话、面对面交谈等。当项目经理传达任务给组员时，一定要注意自己的用语，务必清晰准确，以免造成任务完成以后才发现这并不是当初想要的结果。最好在传达后让组员确认他是否已经精确地了解了要求。项目经理沟通关系与客户沟通与领导沟通与项目组成员沟通作为项目经理，要及时地与领导交流，把项目当前的进展情况传递给领导，仅有正式的汇报（如每周的报告）是远远不够的，建议多一些日常的非正式交谈。

在领导的一些问询中很可能发现一些自己未预见到的问题，如果领导觉得有必要，要及时地做出调整，增加资源等。这样对项目、项目经理本人、领导自身都是有百益而无一害的。项目经理沟通关系与项目组成员沟通与客户沟通与领导沟通客户的交流很重要，项目经理有责任与客户进行交流，询问一些不清晰的需求，及时报告项目进展等。

但要注意到，要利用有限的机会，获得更多的、必须的信息，这样才是有效的交流。可以让组员最大程度地发现未知的问题，积累到一定量后再一次性询问客户。这样既不会影响客户，也提高了项目组提出问题的能力。数据流图符号3.5.1数据流图符号如下图所示。“”数据流图中的处理并不一定是一个程序，一个处理框可以反映一系列程序、单个程序或者一个模块；一个存储也并不等同一个文件，它可以表示一个文件、文件的一个部分、数据库的元素或者记录的一个部分等；数据可以存储在磁盘、内存及其他介质上。数据存储和数据流都是数据，仅所处的状态不同。数据存储属于处在静止状态中的数据，数据流则是处于运动中。命名3.5.2（1）名字应该代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分；（2）不要使用空洞的、缺乏具体含义的名字；（3）如果在为某个数据流起名字时遇到了困难，则很可能是因为对数据流分解不恰当造成的，应该试着重新分解。（1）先为数据流命名，然后再为与之相关联的处理命名；（2）名字应该反映整个处理的功能，而不是它的一部分功能；（3）名字最好由一个具体的及物动词加上一个具体的宾语组成；（4）通常名字中仅包括一个动词；（5）如果在为某个处理命名时遇到困难，也可能是因为分解问题而造成的。为数据流命名为处理命名数据流图实例3.5.3数据流图的成分源点或终点处理数据存储数据流第一步是从问题描述中确定数据流图中的4种成分：首先考虑数据的源点和终点，然后考虑需要做哪些处理，处理结果存储在哪里，数据整个流向是怎样的。一旦把4种成分确定了就可以画出数据流图了。从图2-1所示图书管理系统流程图中，可以画出顶层的数据流图及查询的数据流图。顶层的数据流图查询的数据流图为方便旅客，某航空公司要开发一个机票预订系统。其基本要求为：旅行社把预订机票的旅客信息（姓名、性别、工作单位、身份证号、旅行时间、旅行目的地等）输入系统，系统为旅客安排航班，印出取票通知和账单，旅客在飞机起飞前一天凭取票通知和账单交款取票，系统核对无误后即打印出机票给旅客。实例用途3.5.4数据流图的基本目的是利用它作为交流信息的工具，分析人员把其对现有系统的认识或对目标系统的设想用数据流图描绘出来，供有关人员审定确认。数据数图另一个主要用途是作为分析研究和设计的工具。为了把用户的数据要求清楚、准确地描述出来，系统分析员通常要建立一个概念性的数据模型：实体-联系图（简称E-R图）。概念性数据模型是一种面向问题的数据模型，是按照用户的观点建立的数据模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。0数据对象彼此间相互连接的关系数据对象的属性数据对象数据模型包含的信息数据对象3.6.1数据对象数据对象是对软件必须理解的复合信息的抽象。复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物（如宽度）不是数据对象。数据对象可以是外部实体、事物、行为、事件、角色、单位、地点或结构等。总之，可以由一组属性来定义的实体都可以被认为是数据对象。属性3.6.2属性属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”（通常简称为“码”）。应该根据对所要解决问题的理解，来确定特定数据对象的一组合适的属性。一对一联系（1:1）一对多联系（1:N）多对多联系（M:N）联系3.6.3例如，一个班只有一个班长，而每个班长只在一个班任职，则班长与班级的联系是一对一的。例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教。例如，学生与课程间的联系（“学”）是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。实例注意联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性。多对多联系（M︰N）联系3.6.4使用E-R图来建立的数据模型中包含相互关联的信息实体属性关系用矩形框表示；用椭圆形或圆角矩形表示实体或关系的属性；用连接相关实体的菱形框表示；实例图书管理系统借还E-R图1.状态图的状态状态状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。在状态图中定义的状态主要有初态（即初始状态）、终态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有0至多个。2.状态图的事件事件状态图的事件是在某个特定时刻发生的事情，它是对引起系统做动作或（和）从一个状态转换到另一个状态的外界事件的抽象，是引起系统做动作或（和）转换状态的控制信息。3.状态图的符号初态用实心圆表示终态用一对同心圆（内圆为实心圆）表示箭头“→”表示从一种状态向另一种状态的迁移实例图书借还系统状态图4.状态图实例实例电梯上下状态图数据字典概念数据字典是结构化分析方法的一个有力工具，它对数据流程图中出现的所有数据元素给出逻辑定义。有了数据字典，数据流程图上的数据流、加工和文件得到了确切的解释。分类数据字典的条目可以分成四大类，即数据流条目、文件条目、数据项条目、加工条目。数据字典中的数据构成如下图所示的层次关系。这些数据元素的定义通常用定义式的形式给出。根据所考虑问题的大小，一个数据处理系统的数据字典可能有几十、几百甚至几千个定义式。数据流条目数据流条目主要说明数据流条目是由哪些数据项组成的，以及数据在单位时间内的流量，它的来源、去向等。条目格式如下。数据流名：组成：流量：来源：去向：实例图书管理系统图书资料数据流可做如下定义。数据流名：图书资料编号：011别名：无组成：编号、图书名、出版社、出版日期……来源：模块1.3去处：用户简要说明：表明某册图书在某点的状态。人工建立和维护数据字典常采用卡片记载数据定义，也可以采用计算机进行数据字典的自动管理（机读数据词典），其管理功能包括对数据定义的修改、补充、查询、自身的一致性检查（发现冲突的定义式）及与数据流程图的一致性检查等。ABCD

1995年发布了UML0.8（UnifiedMethod）

1996年6月、10月、1997年1月、11月分别推出了UML0.9，UML0.91，UML1.0，UMLl.1。自1996年起，一些机构把采用UML作为其商业策略，宣布支持并采用UML，并成立了UML成员协会，以完善加强和促进UML的定义。

1997年11月，国际对象管理组织OMG批准把UML1.1作为基于面向对象技术的标准建模语言。方法方法与建模语言是不同的。一个方法告诉用户做什么、怎么做、什么时候做、为什么做（特定活动的目的）。

方法包括模型，这些模型用来描述某些内容，并传达使用一个方法的结果。模型用建模语言来表达，建模语言由记号（模型中使用的符号）和一组如何使用它的规则（语法、语义和语用）组成。

方法与建模语言之间的主要差别是建模语言缺少一个过程，或者说缺少对做什么、怎么做、什么时候做、为什么做的指示。视图从一个角度观察到的系统构成系统的一个视图（View），每个视图是整个系统描述的一个投影，说明了系统的一个特殊侧面。若干个不同的视图可以完整地描述所建造的系统。

视图并不是一种图表（Graph），它是由若干幅图（Diagram）组成的一种抽象。每种视图用若干幅图来描述，一幅图包含了系统某一特殊方面的信息，它阐明了系统的一个特定部分或方面。由于不同视图之间存在一些交叉，因此一幅图可以作为多个视图的一部分。UML语言建立在面向对象的基础上，它采用面向对象的概念和范型。UML语言的体系结构建立在4层元模型结构之上元-元模型元模型模型用户对象元-元模型元-元模型（Meta-metamodel）是建立元模型体系结构的基础结构。元-元模型定义描述元模型的语言，是任何模型的基础，用于对概念的形式化。UML语言的体系结构元模型元模型（Metamodel）层定义描述模型的语言。在UML语言的元模型中，定义了面向对象的范型的概念，如“对象类”、“属性”、“操作”、“组件”等，它们是元模型层的元对象。UML语言的体系结构元模型是元-元模型的一个实例。“对象类”是对一组具有共同的结构特征、行为特征、联系和语义的对象的描述。“对象”是“对象类”的一个实例。“关联”是对一组具有共同的结构特征、行为特征、联系和语义的链接的描述，“链接”用于为两个或多个实体（对象类）之间具有共同特征的联系建立模型。“链接”是“关联”的一个实例，“链接”用于为两个或多个对象之间的联系实例建立模型。用户对象层模型层

模型（Model）是元模型的一个实例，在模型层定义用于描述信息领域的语言。模型是对现实世界的抽象。无论是问题领域还是解决方案，都可以抽象成模型。模型是系统构建和更新的基础，用于对问题和解决方案的理解与交流，便于管理和控制系统的复杂性。UML语言的体系结构用户对象（UserObjects）是模型的实例，用户对象层定义一个特定的信息领域，用于表达一个模型的特定情况。为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。一般规范化有六级：1NF-2NF-3NF-BCNF-4NF-5NF。第一范式数据冗余度最大，第六范式的冗余度最小。但必须注意如下几个问题：一是范式级别越高，存储同样的数据就需要分解成更多张表，因此存储过程也就越显复杂；二是随着范式级别的提高，数据存储结构与基于问题域的结构间的匹配程度也随之下降，因此在需求变化时数据的稳定性较差；三是范式级别升高则性能将下降。综上所述，一般从实用角度分析最好选用第三范式比较恰当。数据规范化010302范式的定义第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定（而不是由关键字的一部分来决定）。每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述（即一个非关键字属性值不依赖于另一个非关键字属性值）。1引言1.1编写目的说明编写这份软件需求说明书的目的，指出预期的读者。1.2背景说明：待开发的软件系统的名称；本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；该软件系统同其他系统或其他机构的基本的相互来往关系。需求分析工作完成后，最终提交的是一份标准格式的文档——软件需求说明书，这里参照国家标准GB/T8567-88《计算机软件产品开发文件编制指南》，该标准将软件需求说明书列示如下。1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列出用得着的参考资料，如：本项目的经核准的计划任务书或合同、上级机关的批文；属于本项目的其他已发表的文件；本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2任务概述2.1目标叙述该项软件开发的意图、应用目标、作用范围，以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。2.2用户的特点列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。2.3假定和约束列出进行本软件开发工作的假定和约束，如经费限制、开发期限等。3需求规定3.1对功能的规定用列表的方式（如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、应怎样处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。3.2对性能的规定3.2.1精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。3.2.2时间特性要求说明对于该软件的时间特性要求，如对：响应时间；更新处理时间；数据的转换和传送时间；解题时间等的要求。3.2.3灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化；运行环境的变化；同其他软件的接口的变化；精度和有效时限的变化；计划的变化或改进。对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.3输人输出要求解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）及图形或显示报告的描述。3.4数据管理能力要求说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求做出估算。3.5故障处理要求列出可能的软件、硬件故障及对各项性能而言所产生的后果和对故障处理的要求。3.6其他专门要求例如，用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。4运行环境规定4.1设备列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括：处理器型号及内存容量；外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量；输入及输出设备的型号和数量，联机或脱机；数据通信设备的型号和数量；功能键及其他专用硬件4.2支持软件列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。4.3接口说明该软件同其他软件之间的接口、数据通信协议等。4.4控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。软件工程基础总体设计的基本目的是回答“软件系统总体上应如何实现”这一问题。因此，总体设计有时又称初步设计或概要设计，其关键是确定软件的总体结构，即确定软件系统的组成成分及其相互关系。详细设计是对总体设计结果的进一步细化，其主要任务是确定软件系统各组成成分内部的数据结构和算法的过程。总体设计详细设计软件设计需求分析需求分析介绍系统必须“做什么”的问题，并在需求规格说明中进行充分的描述。总体设计总体设计与详细设计阶段决定“怎样做”的问题。需求分析转换到总体设计时的对应分解总体设计的主要任务4.1.1总体设计的主要任务有两个：一是概要给出系统的实现方法，划分出组成系统的物理元素，如程序、文件、数据库、文档等；二是确定系统的软件结构，即组成系统的各个模块及模块间的关系。总体设计的过程4.1.2在此阶段分析员应该考虑各种可能的实现方案，并且力求从中选出最佳方案。设想供选择方案的一种常用的方法是：把数据流图中各种可能的处理方法进行分组，抛弃在技术上行不通的分组方法，余下的分组方法代表可能的实现策略，并且可以启示供选择的物理系统。推荐最佳方案选取合理的方案设想供选择的方案123功能分解4从前一步中选择若干个方案，通常至少选取低、中、高3种层次的成本方案，并对其进行全面分析。分析员应该准备以下4份资料：系统流程图、组成系统的物理元素清单、成本/效益分析、实现这个系统的进度计划。综合分析合理方案后，推荐一种最佳方案，并且为推荐的方案制订详细的实现计划。用户与有关技术专家认真审查分析推荐的方案，然后提交使用部门负责人审批。经审批接受分析员推荐的最佳实施方案后，才能进入软件结构设计。对程序的设计通常分为两个阶段完成：首先进行结构设计（确定程序由哪些模块组成，以及这些模块之间的关系，它是总体设计阶段的任务），然后进行过程设计（确定每个模块的处理过程，是详细设计阶段的任务）。功能分解后，可以用层次图、结构图来描绘模块组成的层次系统，即反映软件结构。当数据流图细化到适当的层次时，由结构化的设计方法可以直接映射出结构图。制订测试计划数据库设计与文档结构设计设计软件结构567书写文档8审查和复审9对于需要使用数据库的应用系统，软件工程师应根据系统的数据要求，确定系统的数据结构、文件结构，并在需求分析阶段所确定的系统数据需求的基础上进一步设计数据库。在软件开发早期阶段考虑测试问题，能促进软件设计人员在设计时注意提高软件的可测试性。这个阶段的测试计划指黑盒测试计划，详细设计时能制定出测试用例与计划。这个阶段一般要完成以下文档：系统说明；对最佳方案的概括描述，精化的数据流图；层次图；修改更正的需求分析阶段产生的初步用户手册；测试计划等最后应该对总体设计的结果进行严格的技术审查，在技术审查通过之后再由客户从管理的角度进行复审。模块化4.2.1模块概念模块是由边界元素限定的相邻的程序元素，如数据说明、可执行的语句序列，而且有一个总体标识符来代表它。过程、函数、子程序和宏等都可作为模块。属性（1）接口：指模块的输入与输出。（2）功能：指模块实现什么功能。（3）逻辑：描述内部如何实现要求的功能及所需的数据，即描述模块内部怎样做。（4）状态：指该模块的运行环境，即模块的调用与被调用关系。模块化模块化就是把程序划分成若干个模块，每个模块具有一个子功能，把这些模块集成起来构成一个整体，可以完成指定的功能，实现问题的求解。

为什么大型软件要模块化？对于一个大型软件，由于其控制路径多、涉及范围广而且变量数目多，人们对这样复杂的软件无论是理解还是处理和管理，其复杂性远远超过小型软件。它的理论依据如下：定义函数M（x）为问题x的复杂程度，函数N（x）为解决问题x需要的工作量（时间）。假设对于问题Pl和问题P2，如M（P1）＞M（P2），则说明P1比P2复杂，那么N（P1）＞N（P2），表示问题越复杂所需的工作量就越大。因为由P1和P2两个问题组合而成一个问题的复杂程度大于分别考虑每个问题时的复杂程度之和，即M（Pl＋P2）＞M（P1）＋M（P2）。这样可以推出：N（Pl＋P2）＞N（P1）＋E（P2）上述不等式表明，把复杂的问题分解成许多容易解决的小问题，原来的问题也就容易解决了。同时，从这一不等式中我们还可以得出这样的结论：如果把软件无限细分，那么最后开发软件所需要的工作量就小得可以忽略了。但是事实并非如此，因为影响软件开发工作量的因素还有许多。随着模块数目的增加，虽然开发单个模块需要的成本确实减少了，但是模块之间接口的复杂程度和接口所需的工作量也成倍增加，如右图所示。图中虚线所示为总成本曲线。从图中可以看出存在着一个开发成本最小的模块数目M区。虽然到目前为止还不能决定M的准确数值，但在考虑模块时软件总成本曲线确实给我们提供了非常有用的指导。模块独立性4.2.2内聚耦合模块独立程度定性标准耦合是衡量不同模块彼此间互相依赖（连接）的紧密程度。内聚是衡量一个模块内部各个元素彼此结合的紧密程度。模块独立性是软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他的模块接口是简单的。一个模块内部各个元素之间的联系越紧密，它的内聚性就越高，对应地它与其他模块之间的耦合性就会减低，模块独立性就越强。相反，模块内聚性越低，模块间耦合性就越强，模块的独立性也就越弱。在软件设计中应追求高内聚低耦合的模块，尽量提高模块的独立性。1.耦合耦合耦合是程序结构中各个模块之间相互关联的度量。耦合强弱取决于模块间接口的复杂程度、调用模块的方式及通过接口的信息。从耦合的机制上将耦合分为非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合7种类型。非直接耦合数据耦合标记耦合控制耦合外部耦合公共耦合内容耦合低高强弱耦合性模块独立性上图为7种耦合类型的关系图。需要注意的是，实际中模块之间的耦合并不是7种耦合类型中的某一种，而是多种类型的混合。标记耦合数据耦合非直接耦合如果两个模块之间没有直接关系，彼此之间完全独立，它们之间的联系完全是通过主模块的控制和调用来实现的，称之为非直接耦合。非直接耦合程度最低，因此模块的独立性最强。耦合如果两个模块彼此间通过参数交换信息，而且交换的信息仅仅是数据，那么这种耦合称为数据耦合。数据耦合是松散的耦合，模块的独立性比较强。如果一组模块通过参数表传递具有某一数据结构的记录信息，即标记耦合。这就意味着另一模块要共享这个记录，必须清楚该记录的数据结构，并按要求对此记录进行操作。这就使得在数据结构上的操作复杂化，在设计中应尽量避免或采用相应的其他方法消除这种耦合。公共耦合外部耦合控制耦合如果两个模块之间传递的信息有控制信息，则这种耦合称为控制耦合。控制耦合是中等程度的耦合，它增加了系统的复杂程度。耦合如果几个模块都访问同一全局简单变量而不是同一全局数据结构，且不是通过参数表传递该变量的信息，则称之为外部耦合。外部耦合程度较高，模块的独立性较弱。外部耦合可能引起数据的修改等。在程序设计时尽量少用外部耦合。当两个或多个模块通过一个公共数据区相互作用时，它们之间的耦合称为公共耦合。公共数据区可以是全程数据区、共享通信区、内存公共覆盖区、任何介质上的文件、物理设备等。公共耦合的复杂程度随耦合模块的个数增多而显著增。因此，在设计时还是使用耦合性低、模块的独立性比较高的耦合为好。内容耦合最高程度的耦合是内容耦合，它使得模块的独立性最弱，应该坚决避免使用内容耦合。如果出现下列情况之一，就发生了内容耦合耦合“”

在设计中处理耦合的总体原则是：尽量使用数据耦合，少用标记耦合和控制耦合，限制外部耦合和公共耦合的范围，完全不用内容耦合。2.内聚内聚内聚是程序结构中模块内各个元素彼此结合紧密程度的度量。理想内聚的模块只做一件事情。根据模块内部构成情况，可以分成高、中、低内聚3类。其中高内聚有功能内聚和顺序内聚；中内聚有通信内聚、过程内聚；低内聚有时间内聚、逻辑内聚和偶然内聚。功能单一功能分散功能内聚顺序内聚通信内聚过程内聚时间内聚逻辑内聚偶然内聚低高强弱内聚性模块独立性上图为这7种内聚类型关系图。从图中可以看出，功能内聚的模块独立性最强，偶然内聚模块独立性最弱。在设计时尽量做到高内聚，并辨别出低内聚的模块，然后对其修改，提高模块的内聚程度，从而得到高内聚独立性强的模块。通信内聚顺序内聚功能内聚如果一个模块内所有处理元素仅为完成一个具体的功能而协同工作，紧密联系，不可分割，则称为功能内聚。功能内聚是最高程度的内聚。在设计时应尽可能使模块到达功能内聚这一级别。内聚如果一个模块内的处理元素和同一个功能密切相关，而且这些处理必须按顺序执行（通常一个处理