第2章软件工程

第2章软件工程2.1软件工程的基本概念2.2软件开发过程2.3系统定义2.4软件实现2.5软件维护2.6软件开发管理2.1软件工程的基本概念2.1.1软件危机及其形成原因2.1.2软件工程的定义2.1.3软件工程的基本原则2.1.4软件工程的基本内容一、软件的概念

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。 其中，程序是按事先设计的功能和性能要求编写的指令序列；数据是使程序能正常操纵信息的数据结构；文档是与程序开发、维护和使用有关的图文材料。 注：程序并不是软件，程序只是软件的组成部分。2.1.1软件危机及其形成原因二、软件的特点（1）软件是一种逻辑实体。（2）软件的开发，是人的智力的高度发挥，而不是传统意义上的硬件制造。（3）软件维护与硬件的维修有着本质的差别。（4）软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。（5）软件的开发至今尚未完全摆脱手工艺的开发方式，使软件的开发效率受到很大限制。（6）软件的开发是一个复杂的过程。（7）软件的成本非常高昂。三、软件危机及其形成原因什么是软件危机软件不符合用户的实际需要软件价格昂贵软件开发项目超支和延期软件质量低，可靠性差软件缺少适当的文档资料难于修改和维护软件软件危机的形成原因软件本身是逻辑部件，质量难以评价，潜在的错误在所难免软件规模越来越大，软件结构越来越复杂忽视需求分析的重要性，急于开始编程轻视软件测试和轻视软件维护软件开发技术落后，生产方式落后，开发工具落后软件危机的解决方法

必须消除存在的错误认识、树立软件工程观念用工程化方法和途径来开发和维护软件

开发和使用更好的软件工具

应该采取必要的管理措施

总之:技术措施+组织管理措施按工程化的原则和方法来组织和规范软件开发过程，解决软件研制中面临的困难和混乱，从而根本上解决软件危机。所谓软件工程，就是研究大规模程序设计中的方法、工具和管理的一门工程科学。1968年北约组织在前联邦德国格密斯举行的国际学术会议上正式提出并使用了“软件工程”的概念，运用工程学的基本原理和方法来组织和管理软件生产。后来还发展了相关的心理学、生理学和经济学等方面的学科。软件工程诞生了，它是解决软件危机唯一有效的方法。定义一：软件工程是科学知识在设计和构造计算机程序以及开发、运作和维护这些程序所要求的有关文档编制中的实际应用。定义二：为了经济地获得可靠的能在实际的计算机上运行的软件所确立和使用的健全的工程原理。定义三：对软件开发、运行、维护、退役的系统研究方法。

定义四：对软件开发、运行、维护的系统化的、有纪律的、可定量的方法的应用，即对软件的工程化的应用。定义五：软件工程是指导计算机软件开发和维护的一门学科，它采用工程的概念、原理、技术和方法，把经过时间考验而证明是正确的管理技术和与技术方法结合起来用于开发软件。2.1.2软件工程的定义用分阶段的生命周期计划严格管理

坚持进行阶段评审

实行严格的产品控制采用现代程序设计技术

工作成果应当能够清楚地评审开发小组的成员应少而精

承认不断改进软件工程实践的必要性2.1.3七条基本原则软件生存周期模型指导整个软件开发过程软件分析系统分析、可行性分析、软件开发计划、需求分析软件设计总体设计、详细设计

软件实现编程序软件测试

软件维护

软件管理

成本估算、风险分析、进度安排、人员组织、软件质量保证2.1.4软件工程的基本内容2.2软件开发过程2.2.1软件开发的主要阶段2.2.2软件生命周期模型2.2.3模块化软件开发原则2.2.4软件开发方法软件从产生、发展到淘汰要经历定义、开发和维护三大阶段定义阶段细分成可行性论证、需求分析开发阶段细分成总体设计、详细设计、实现、集成测试和确认测试维护阶段细分成软件使用、修改维护、退役2.2.1软件开发的主要阶段软件产品从形成概念开始，经过开发、使用和维护，直到退役的全过程九个阶段：2.2.2软件生命周期模型软件生命周期瀑布模型将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件产品。瀑布模型的特点线性开发序列：每一阶段任务必须通过评审才能进入下一阶段，直线前进避免大的返工，允许局部的返工瀑布模型的局限性明确全部需求困难甚至不现实开发周期过长、用户不能及时提出修改意见软件生存周期渐增模型又称演化模型又称原型模型用主动的正常的迭代避免被迫的不正常的反复程序员与用户反复交互原型模型的特点采用软件重用技术和强有力的快速开发工具采用主动的、正常的迭代避免了瀑布模型被迫的、不正常的返工有助于用户和软件开发人员对需求的定义和确认原型模型的局限性不收敛于开发者预定目标资源规划和管理较为困难更新文档麻烦抽象自顶向下逐步求精模块化信息隐蔽与局部化模块独立启发式规则2.2.3模块化软件开发原则把大型软件按照规定的原则划分为一个个较小的、相对独立但又相关的模块的设计方法，叫做模块化设计（modulardesign）。模块（module）是数据说明和可执行语句等程序对象的集合，每个模块单独命名并且可以通过名字对模块进行访问实现模块化设计的重要指导思想是分解、信息隐藏和模块独立性。分解 设函数C(x)定义问题x的复杂程度，函数E(x)确定解决问题x所需要的工作量（时间）。对于两个问题Pl和P2，如果C(P1)＞C(P2)，

显然 E(P1)＞E(P2)

根据人类解决一般问题的经验，如果一个问题由Pl和P2两个问题组合而成，那么它的复杂程序大于分别考虑每个问题时的复杂程度之和，即

C(Pl＋P2)＞C(P1)＋C(P2)

综上所述，可得到下面的不等式

E(Pl＋P2)＞E(Pl)＋E(P2)模块化模块完成特定的子功能可以组合、分解、更换的单元，如过程、函数、子程序、宏等模块化解决一个复杂问题时，自顶向下逐层将软件分解成若干模块的过程目的：降低软件的复杂性模块化软件开发原则模块划分的指导原则模块可分解性：能把问题分解为子问题的系统化机制模块可组装性：能把现有的模块组装成新系统模块可理解性：一个模块作为独立单元无需参考其它模块来理解模块连续性：系统需求的微小修改只导致对个别模块，而不是对整个系统的修改模块保护性：一个模块内出现异常情况时，它的影响局限在该模块内部模块化软件开发原则模块与成本的关系模块化软件开发原则信息隐蔽与局部化信息隐蔽：一个模块内包含的信息(过程或数据)对于不需要这些信息的其它模块来说不可见（不能访问）局部化：将关系密切的软件元素的位置尽量靠近信息隐蔽与局部化有利于软件的可维护性，可以防止误操作和误修改模块化软件开发原则模块独立模块独立性：模块化、抽象、信息隐蔽和局部化直接结果模块独立的好处：使软件开发更容易、适合分工合作使软件测试和维护更容易模块独立的度量内聚：一个模块内部各元素之间彼此结合的紧密程度的度量耦合：不同模块之间互连程度的度量模块化软件开发原则启发式规则改进软件结构提高模块独立性模块规模应该适中模块之间的调用关系应当按照层次化组织模块的深度、宽度、扇出和扇入都应适当设计单入口单出口的模块模块功能应该可以预测模块化软件开发原则对软件分析方法、软件设计方法软件实现（编码）方法的总称。结构化方法（StructuredMethod）面向对象方法（Object-OrientedMethod）2.2.4软件开发方法2.3系统定义2.3.1可行性分析2.3.2需求分析可行性分析目的用最小的代价在尽可能短的时间内确定问题是否能够解决任务在澄清了问题定义之后，分析员首先应该导出系统的逻辑模型，然后从系统逻辑模型出发，探索出若干种可供选择的主要解法（即系统实现方案）。最后仔细研究每种解法的可行性。2.3.1可行性分析一般说来，可行性研究应该从下述几方面进行：（1）技术可行性：指使用现有的技术能否完成这个项目。（2）经济可行性：指通过对软件开发项目进行成本/效益估计，以确定软件系统可能带来的经济效益能否超过研制和维护此系统所需的费用。（3）社会因素的考虑：软件开发是否会侵犯他人、集体或国家的利益，是否违反国家的法律并可能由此而承担法律责任。步骤确定项目规模和目标研究正在运行的系统建立新系统的高层逻辑模型导出和评价各种方案推荐可行方案编写可行性分析报告软件开发计划通过可行性分析，如果开发软件系统可行的话，接着要制定软件的开发计划。内容资源计划：人力资源、硬件资源、软件资源成本预算：估计总的开发成本进度安排：确定最终的软件交付日期、在交付日期内安排和分配工作量需求分析需求分析目标解决“做什么(Whattodo)”，而不是“怎么做(Howtodo)”既是软件开发依据，也是软件验收标准与用户充分沟通，去伪存真，去粗存精通信瓶颈：用户vs

开发人员阶段性标志：软件需求规格说明(SRS：SoftwareRequirementsSpecification)

2.3.2需求分析一、需求分析任务确定软件系统的综合要求功能要求性能要求系统数据接口要求安全性保密性和可靠性要求系统运行要求异常处理要求等分析软件系统的数据要求建立系统的逻辑模型评估项目开发计划（成本、进度）二、需求分析工具层次方框图Warnier图IPO图（输入/处理/输出）三、需求分析方法结构化分析方法结构化分析方法（StructuredAnalysis，简称SA方法）是70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。结构化分析方法中使用的工具主要包括：数据流图、数据字典、结构化语言、判定表和判定树。 其中数据流图用以表达系统内数据的运动情况；数据字典用以定义系统中的数据；结构化语言、判定表和判定树都是用以描述数据流的加工的工具。面向对象分析方法2.4软件实现2.4.1总体设计2.4.2详细设计2.4.3编码2.4.4测试一、总体设计内容总体设计又称概要设计解决“如何做(Howtodo)”设计供选择的方案推荐最佳方案设计软件结构,划分功能模块，定义各功能模块的接口设计数据结构和数据库用户界面设计制定测试计划编写总体设计阶段的文档评审总体设计方案2.4.1总体设计软件实现二、总体设计的图形工具层次图HIPO图（层次图加输入/处理/输出图）结构图软件实现三、总体设计的设计方法结构化设计自顶向下基于数据流的设计方法面向对象设计软件实现

详细设计以总体设计阶段的工作为基础的，但又不同于总体设计，主要表现为以下两个方面：（1）在总体设计阶段，数据项和数据结构以比较抽象的方式描述，而详细设计阶段则应在此基础上给出足够详细描述。（2）详细设计要提供关于算法的更多的细节，例如：总体设计可以声明一个模块的作用是对一个表进行排序，详细设计则要确定使用哪种排序算法。在详细设计阶段为每个模块增加了足够的细节后，程序员才能够以相当直接的方式进行下一阶段的编码工作。2.4.2详细设计软件实现 详细设计的任务和原则一、详细设计的任务1）确定每个模块的算法。

2）确定每一个模块的数据组织。

3）为每个模块设计一组测试用例。

4）编写详细设计说明书。软件实现

二、详细设计的原则（1）模块的逻辑描述正确可靠、清晰易读。（2）采用结构化程序设计方法，改善控制结构，降低程序复杂度，提高程序的可读性、可测试性和可维护性。

软件实现三、详细设计的工具过程设计语言(PDL：ProcedureDesignLanguage)又称伪码，半形式化、易编辑、易自动生成程序流程图易上手、非结构化盒图（N-S图）结构化、功能域明确PAD图结构化、可用于数据结构、易自动生成软件实现四、详细设计的方法面向数据结构的设计方法：以数据结构为中心结构化设计方法以数据流为中心面向对象设计方法以对象为中心软件实现2.4.3编码编码（实现）：俗称编程序(Programming)编码任务选择一种程序设计语言将详细设计文档“翻译”为程序（源程序代码）单元测试（调试）编码原则高效+技巧安全+可靠时间、空间效率可用性、可维护性、可移植性良好的编程风格可以减少软件错误阶段性标志：源程序代码编码风格

编码风格实际上是一种编码原则。从20世纪70年代以来，编码的目标从强调效率转变到强调清晰。与此相应，编码风格也从追求“聪明”和“技巧”，变为提倡“简明”和“直接”。人们逐渐认识到，良好的编码风格能在一定程度上弥补程序设计语言存在的缺点。反之，如果不注意编码风格，即使使用了结构化的现代语言，也很难写出高质量的程序。一、代码文档化：指编码时适当选择标识符的名字、适当安排注释和注重程序的整个组织形式。二、数据说明：程序或模块在其可执行部分的前面都集中了一些说明语句，出于阅读理解和维护的要求，最好使其规范化，使说明的先后次序固定。三、语句构造：每条语句都应当简单而直接，同时也不应为了追求运行效率而使代码复杂化，这样会减低程序的可读性。四、输入/输出：源程序的输入输出风格必须满足运行工程学的需要。程序效率 尽管效率是值得追求的目标，但不应为了非必需的效率提高而牺牲代码的清晰性、可读性和正确性。应记住下面三条准则。（1）效率是一种性能需求，目标值应当在需求分析阶段给出。软件效率应以需求为准，不应以人力所及为准。（2）好的设计可以提高效率。（3）代码效率与代码的简单性相关。一、代码效率

（1）应先简化算术和逻辑的表达式。

（2）仔细研究嵌套的循环，以确定是否有语句可以从内层往外移。

（3）尽量避免使用多维数组。

（4）尽量避免使用指针。

（5）使用执行时间短的算术运算。

（6）即使语言允许，一般也不要采用混合数据类型。

（7）尽量使用整数表达式和布尔表达式。二、输入/输出的效率（1）所有输入/输出都应该有缓冲，以减少过多的通信次数。

（2）对辅存（如磁盘），应选用最简单的访问方法。

（3）辅存的输入/输出，应该以块为单位进行。

（4）终端和打印机的输入/输出，应当考虑设备的特性，以提高输入/输出的质量和速度。

（5）不应当采用不能被人们所理解的超高效的输入/输出。结构化程序设计采用自顶向下、逐步求精的设计方法；采用单入口单出口的控制结构；只包含顺序、选择和循环三种控制结构；软件实现一、软件测试的目标测试是为了发现程序中的错误而执行程序的过程；好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案；成功的测试是发现了至今为止尚未发现的错误的测试。二、测试原则测试不能证明软件没有错误应避免程序员测试自己的程序对合法的和非法的输入都要测试测试用例（包括输入及预期输出）必须高效2.4.4软件测试软件实现测试原则尽早地和不断地进行软件测试程序员应避免检查自己的程序要预先确定测试用例设计的测试用例应当包括合理的输入条件和不合理的输入条件充分注意测试中的群集现象严格执行测试计划，排除测试的随意性应当对每个测试结果做全面检查妥善保存测试计划、测试用例、出错统计和最终分析报告软件实现三、测试分类单元测试（又称模块测试）时期：编码阶段定义：对软件设计的最小单位（程序模块）进行的测试方法：采用白盒测试法辅之以黑盒测试法内容：模块接口测试、局部数据结构测试、路径测试、错误处理测试、边界测试组装测试（又称集成测试）时期：编码完成阶段定义：在单元测试的基础上将所有模块按照设计要求组装为完整的系统方法：渐增式测试和非渐增式测试内容：各模块的接口软件实现确认测试定义：验证软件的功能、性能及其他特性是否与用户的要求一致方法：测试、β测试内容：有效性测试和验收测试阶段：即将交付使用系统测试定义：把通过确认测试的软件作为整个计算机系统的一个元素与其他元素结合在一起在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试软件实现四、白盒测试前提：完全了解程序的结构和处理过程方法：穷尽测试、逻辑覆盖

逻辑覆盖的不同标准语句覆盖选择足够多的测试数据,使被测程序中每个语句至少执行一次判定覆盖条件覆盖判定／条件覆盖条件组合覆盖路径覆盖软件实现五、黑盒测试定义：只检查程序功能是否能按照需求规格说明书的规定正常运行，程序是否能接收输入数据并产生正确的输出信息，并且保持外部信息的完整性。方法：等价类划分仅选取少量最有代表性的输入数据边界值分析使程序运行在边界情况(下标,循环次数)下错误推测软件实现六、软件调试

任务：测试之后进一步诊断和改正程序中的错误步骤：确定错误的位置确定问题的原因方法：输出存储器内容适当插入打印语句使用专门的调试工具调试策略

试探法、回溯法、归纳法、演绎法软件实现2.5软件维护2.5.1什么是软件维护2.5.2软件维护分类2.5.3软件维护的过程软件维护是软件生命周期的最后一个阶段，它是指已完成开发工作，交付使用后，对软件产品所进行的一些软件工程活动。软件维护的必要性运行中发现错误适应软硬件环境变化适应功能需求变化维护成本通常高大开发成本的4倍2.5.1什么是软件维护软件维护决定可维护性的因素可理解性：理解软件的难易程度可测试性：测试和诊断软件中错误的难易程度可修改性：修改软件的难易程度各类文档软件维护的分类改正性维护：在软件运行中发生异常或故障时进行。适应性维护：为使该软件能适应外部环境的变动。完善性维护：为扩充软件的功能，提高原有软件性能而开展的软件工程活动。软件维护在软件维护时，必然会对源程序进行修改，为了正确、有效地修改源程序，需要经历下列步骤：分析和理解程序修改程序重新验证程序软件维护的组织维护文档的编写软件维护2.5.3软件维护的过程2.6软件开发管理2.6.1质量管理2.6.2进度安排2.6.3人员管理2.6.4风险分析2.6.5成本/效益分析软件质量：定量比较困难ISO软件质量模型的质量特性和质量子特性组成：功能性适应性、准确性、互用性、依从性、安全性可靠性成熟、容错、易恢复易使用性易理解、易学、易操作效率时间特性、资源特性可维护性易分析、易修改、稳定、易测试可移植性适应性、易安装、一致性、易替换软件开发管理2.6.1质量管理