软件工程第二节.ppt

1、软件工程概论Software Engineering,贾恒彬 E-mail: ,李恒 E-mail:,回顾,软件是计算机系统中与硬件相互依存的另一部分。它包括程序、数据及其相关文档的完整集合。 软件危机 软件工程三要素：方法、工具、过程。,1.3 软件生命周期,把软件从产生、发展到成熟、直至衰亡为止,特点： 上一阶段的变换结果 是下一阶段的变换的 输入，相邻两个阶段 具有因果关系，紧密 相联。,需求分析,问题定义,可性行研究,计划 时期,概要设计,详细设计,编 码,测 试,开发 时期,运行与维护,运 行 时 期,1.3 软件生命周期,制定计划 1、确定要开发软件系统的总目标； 2、给出功能、性

2、能、可靠性以及接口等方面的要求； 3、完成该软件任务的可行性研究； 4、估计可利用的资源 （硬件，软件，人力等）、成本、效益、开发进度； 5、制定出完成开发任务的实施计划，连同可行性研究报告，提交管理部门审查。,1.3 软件生命周期,需求分析和定义 当完成制定计划之后，需要对用户的需求去粗取精、去伪存真、正确理解，然后把它用软件工程开发语言表达出来。 其主要任务是： 对用户提出的要求进行分析并给出详细的定义； 编写软件需求说明书及初步的系统用户手册，提交管理机构评审。,1.3 软件生命周期,软件设计 其主要任务是： 概要设计：把各项需求转换成软件的体系结构。结构中每一组成部分都是意义明确的模块

3、，每个模块都和某些需求相对应； 详细设计：对每个模块要完成的工作进行具体的描述，为源程序编写打下基础； 编写设计说明书，提交评审。,1.3 软件生命周期,程序编写 其主要任务和要求是： 把软件设计转换成计算机可以接受的程序代码，即写成以某一种特定程序设计语言表示的“源程序清单”； 写出的程序应当是结构良好、清晰易读的，且与设计相一致的。,1.3 软件生命周期,软件测试 其主要过程是： 单元测试：查找各模块在功能和结构上存在的问题并加以纠正； 组装测试：将已测试过的模块按一定顺序组装起来； 按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用。,1.3 软件生命周期,

4、运行维护 保证正常而可靠地运行，并能使软件不断得到改善和提高，充分发挥其作用。软件维护有四种类型，它们分别完成以下各自的任务： 改正性维护：运行中发现了软件中的错误而进行的修正工作； 适应性维护：为了适应变化了的软件工作环境，而做适当的变更； 完善性维护：为了增强软件的功能而做的变更； 预防性维护：为未来的修改与调整奠定更好的基础而进行的工作。,1.3 软件生命周期,制定计划_解决什么问题，目标及其可行性（技术、人员、财力、社会） 需求分析_做什么、验收标准 总体设计_怎么做 详细设计_具体怎么做 程序编写_实现 软件测试_保证软件质量 运行/维护_保证正常而可靠地运用,1.3 软件生命周期,

5、基本原则 （1）用户参与的原则； （2）“先逻辑，后物理”的原则； （3）“自顶向下”的原则； （4）工作成果描述标准化的原则。,1.3 软件生命周期,核心思想 （1）严格区分工作阶段。 （2）自顶层向下层逐层开发，结构化，模块化。 （3）建立面向用户的观点，充分预料可能发生的外部环境、内部处理、用户需求的变化。 （4）加强调查研究和系统分析，推迟编程和保证开发质量。,1.3 软件生命周期,软件生命周期的内容 管理策略部分 软件开发的规划、进程安排、评估、监控和反馈。 开发策略部分 任务分解结构（各阶段） 优先级结构（软件开发所遵循的基本过程模型） 开发经验 软件开发标准（活动、职责、文档、质

6、量检验 ）,瀑布模型 原型模型 增量模型 螺旋模型 喷泉模型 混合模型 敏捷模型,1.4 软件过程模型,1.4.1 瀑布模型,瀑布模型（waterfall model）是由W. Royce于1970年提出来的。又称为软件生存周期模型。 瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。,1.4.1 瀑布模型,特点： 1.阶段间具有顺序性和依赖性 2.推迟实现的观点 3

7、.质量保证的观点,瀑布模型优点,提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。,瀑布模型缺点,1）在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。 2）在需求分析阶段，当需求确定后，无法及时验证需求是否正确、完整。 3）作为整体开发的瀑布模型，由于不支持产品的演化，缺乏灵活性，对开发过程中很难发现的错误，只有在最终产品运行时才能暴露出来，从而使软件产品难以维护。,瀑布模型适应场合,瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。例如操作系统、

8、编译系统、数据库管理系统等系统软件的开发。应用有一定的局限性。,1.4.2 原型模型,原型模型（prototyping model）的基本框架是软件开发人员根据用户提出的软件基本需求快速开发一个原型，以便向用户展示软件系统应有的部分或全部功能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤。,加工 原型,快速分析 和设计,建造 原型,客户 评价原型,1、原型系统仅包括未来系统的 主要功能，以及系统的重要 接口。,2、为了尽

9、快向用户提供原型， 开发原型系统时应尽量使用 能缩短开发周期的语言和工 具。,1.4.2 原型模型,快速原型的开发途径有三种：,1）仅模拟软件系统的人机界面和人机交互方式。 2）开发一个工作模型，实现软件系统中重要的或容易产生误解的功能。 3）利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能。 总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。,原型模型的适应场合,原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框

10、架。 它适合于那些不能预先确切定义需求的软件系统的开发，更适合于那些项目组成员（包括分析员、设计员、程序员和用户）不能很好交流或通信有困难的情况。,1.4.3 增量模型,增量模型把软件产品作为一系列的增量构件来设计、编码、集成和测试。 分解构件的方法： 第一个增量构件：核心功能 第二个增量构件：完善核心功能 第三N个增量构件：按照功能的重要性以此分解。 增量模型优点： 在较短时间内可以提供部分工作的产品 在逐步增加产品功能的同时给用户学习的时间 困难及维护的方便性： 软件体系结构是开放的，加入新构件必须简单。 总体设计更加精细，代价较高。,增量模型,风险更大的增量模型,1.4.4 螺旋模型,螺

11、旋模型综合了瀑布模型和原型模型的优点，即将两者结合，并加入了风险分析机制。 其基本思想是使用原型及其他方法来降低风险。 可以把它看作每个阶段都加了风险分析过程的快速原形模型。,生命周期计划 需求计划,风险分析,原型1,原型2,原型3,可操作 的原型,建模,模拟,评价,操作概念,软件需求,需求确认,开发计划,组装测试计划,风险分析,风险分析,风险分析,软件产品 设计,设计验证与确认,详细 设计,编码,单元 测试,组装 测试,验收 测试,实现,成本,顺时针为进展方向,计划： 明确目标、约束条件 选择方案,风险分析 构造原型,工程实现,用户评价；阶段评审,图1-4-4 螺旋模型,验收测试计划,需求精

12、化计划,需求评价,评审,决策,实现计划,1.4.4 螺旋模型,螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。 1计划（需求定义） 第一周期开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发计划（即整个软件生命周期计划）和需求分析计划。经过一个周期后，根据用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。,1.4.4 螺旋模型,2风险分析 根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径。此时根据风险分析的结果决策项目

13、是否继续。所以，螺旋模型是一个风险驱动的模型。 3工程实现 利用构造的原型进行需求建模或进行系统模拟，直至实现软件系统。,1.4.4 螺旋模型,4用户评价与阶段评审 将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等。 螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软件系统开发完成。,螺旋模型的优点,支持用户需求的动态变化。这就要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性。也支持软件系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期。 原

14、型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便。,螺旋模型的优点,螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力。 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险。,螺旋模型的缺点和适应场合,缺点： 如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间； 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高。 适应场合：支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软

15、件开发方法，是一种具有广阔前景的模型。,1.4.5 喷泉模型,喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。 该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。 由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙,优点：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发

16、过程。 缺点： 由于喷泉模型在各个开发阶段是重叠的，因此不利于项目的管理。 此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。,1.4.6 混合模型,混合模型（hybrid model） 过程开发模型又叫混合模型（hybrid model），或元模型（meta-model），把几种不同模型组合成一种混合模型，它允许一个项目能沿着最有效的路径发展，这就是过程开发模型或混合模型。 实际上一些软件开发单位都是使用几种不同的开发方法组成他们自己的混合模型。,1.4.7 敏捷开发与极限编程,极限编程诞生于一种加强开发者与用户的沟通需求，让客户全面参与软件

17、的开发设计，保证变化的需求及时得到修正。 极限编程把软件开发过程重新定义为聆听、测试、编码、设计的迭代循环过程，确立了测试-编码-重构(设计)的软件开发管理思路。,聆听,测试,编码,设计,极限编程的12个实践是极限编程者总结的实践经典：,1、小版本 为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。 2、规划游戏 就是客户需求，以客户故事的形式，由客户负责编写。极限编程不讲求统一的客户需求收集，也不是由开发人员整理，而是采取让客户编写，开发人员进行分析，设定优先级别，并进

18、行技术实现。当然游戏规则可进行多次，每次迭代完毕后再行修改。客户故事是开发人员与客户沟通的焦点，也是版本设计的依据，所以其管理一定是有效的、沟通顺畅的。 3、现场客户 极限编程要求客户参与开发工作，客户需求就是客户负责编写的，所以要求客户在开发现场一起工作，并为每次迭代提供反馈。 4、隐喻 隐喻是让项目参与人员都必须对一些抽象的概念理解一致，也就是我们常说的行业术语，因为业务本身的术语开发人员不熟悉，软件开发的术语客户不理解，因此开始要先明确双方使用的隐喻，避免歧异。,极限编程的12个实践是极限编程者总结的实践经典：,5、简单设计 极限编程体现跟踪客户的需求变化，既然需求是变化的，所以对于目前

19、的需求就不必过多地考虑扩展性的开发，讲求简单设计，实现目前需求即可。简单设计的本身也为短期迭代提供了方便，若开发者考虑“通用”因素较多，增加了软件的复杂度，开发的迭代周期就会加长。简单设计包括四方面含义：（1）通过测试。（2）避免重复代码。（3）明确表达每步编码的目的，代码可读性强。（4）尽可能少的对象类和方法。由于采用简单设计，所以极限编程没有复杂的设计文档要求。 6、重构 重构是极限编程先测试后编码的必然需求，为了整体软件可以先进行测试，对于一些软件要开发的模块先简单模拟，让编译通过，到达测试的目的。然后再对模块具体“优化”，所以重构包括模块代码的优化与具体代码的开发。重构是使用了“物理学

20、”的一个概念，是在不影响物体外部特性的前提下，重新优化其内部的机构。这里的外部特性就是保证测试的通过。 7、测试驱动开发 极限编程是以测试开始的，为了可以展示客户需求的实现，测试程序优先设计，测试是从客户实用的角度出发，客户实际使用的软件界面着想，测试是客户需求的直接表现，是客户对软件过程的理解。测试驱动开发，也就是客户的需求驱动软件的开发。,极限编程的12个实践是极限编程者总结的实践经典：,8、持续集成 集成的理解就是提交软件的展现，由于采用测试驱动开发、小版本的方式，所以不断集成(整体测试)是与客户沟通的依据，也是让客户提出反馈意见的参照。持续集成也是完成阶段开发任务的标志。 9、结对编程

21、 这是极限编程最有争议的实践。就是两个程序员合用一台计算机编程，一个编码，一个检查，增加专人审计是为了提供软件编码的质量。两个人的角色经常变换，保持开发者的工作热情。这种编程方式对培养新人或开发难度较大的软件都有非常好的效果。 10、代码共有 在极限编程里没有严格文档管理，代码为开发团队共有，这样有利于开发人员的流动管理，因为所有的人都熟悉所有的编码。 11、编码标准 编码是开发团队里每个人的工作，又没有详细的文档，代码的可读性是很重要的，所以规定统一的标准和习惯是必要的，有些象编码人员的隐喻。 12、每周40小时工作 极限编程认为编程是愉快的工作，不轻易加班，今天的工作今天做，小版本的设计也

22、为了单位时间可以完成的工作安排。,敏捷开发：,迭代 软件的功能是客户的需求，界面的操作是客户的“感觉”，对迭代的强调是缩短了软件版本的周期 客户参与 以人为本，客户是软件的使用者，是业务理解的专家，没有客户的参与，开发者很难理解客户的真实需求 小版本 快速功能的展现，看似简单，但对于复杂的客户需求，合理地分割与总体上的统一，要很好地二者兼顾是不容易的。,极限编程的思想体现了适应客户需求的快速变化，激发开发者的热情，也是目前敏捷开发思维的重要支持者。 敏捷开发强调：,第二章 问题的定义与可性行研究,当我们在着手做任何一件工作以前，必须明确工作的性质、任务，制定完成任务的计划，这是非常必要的。同样

23、对于软件产品的开发 ，显然也应该解决好这样类似的问题，明确该软件产品开发的任务，以及完成任务的价值从而制定出完成任务的计划。那么问题的定义和可性行研究就是制定软件系统的计划的第一步。 所以在软件工程中把这一步称为 计划时期,开始,问题定义,可性行研究,可行否？,项目实施计划,终止项目的建议,结束,Y,计划时期的工作流程图,N,Who,What,Why,3W,有用的软件,2.1 现状调查和问题的定义,目的:弄清楚用户要求计算机解决什么问题,任务:编写系统目标与规范说明书,系统目标与规范说明书 1、项目：教材销售系统 2、问题：人工销售教材手续繁琐，容易出错 3、项目目标：建立一个高效率、无差错的

24、计算机教材销售系统 4、项目范围：利用现有的计算机，软件开发费用不得超过2000元 5、初步想法：建议在系统中增加对缺书的统计与采购功能 6、可性行研究：建议进行大约10天的可性行研究，且研究费用不超过500元,2.2 可行性研究与论证,1、经济可行性:,进行成本效益分析，评估项目的开发成本。,基于计算 机系统的 成本由四 部分组成,其论证的焦点是:围绕着对系统开发的价值进行论证,举例：关于开发CAD系统的软件开发成本及效益分析,该系统节省经费,该系统成本,盈亏平衡点,投资回收期,-成本及效益分析图,2、技术可行性:,对系统的性能、可靠性、可维护性以及生产率 等方面的信息进行评价。,通过技术可行性的分析，将为新系统提交技术可 行性评估。以指明为完成系统的功能和性能需要什么 技术？需要哪些材料、方法、算法、或者过程等,可行性 论证报告,2.3 可行性分析所需工具 （系流程图与系统结构图）,1、系统流程图:,是用来描述系统物理模型的一种传统工具。,它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件（程序，文件，数据库