第一章 软件工程基本概念.

Presentation on theme: "第一章 软件工程基本概念."— Presentation transcript:

1 第一章 软件工程基本概念

2 1.1 软件 什么是软件？ 软件一般认为由三部分组成： 程序：在运行时，能提供所希望的功能和性能的指令集。
1.1 软件 什么是软件？ 软件一般认为由三部分组成： 程序：在运行时，能提供所希望的功能和性能的指令集。 数据结构：使程序能够正确运行的数据结构 文档：描述程序研制过程、方法及使用的文档

3 1.1 软件 软件的特点 抽象性：逻辑实体，可记录，但看不到 可复制性：与开发成本相比，复制成本很低 无折旧 受硬件制约 未完全摆脱手工工艺
1.1 软件 软件的特点 抽象性：逻辑实体，可记录，但看不到 可复制性：与开发成本相比，复制成本很低 无折旧 受硬件制约 未完全摆脱手工工艺 开发费用高

4 1.2 软件危机 一、计算机软件发展的三个时期 1. 早期时代（60年代中期之前）程序设计阶段
1.2 软件危机 一、计算机软件发展的三个时期 1. 早期时代（60年代中期之前）程序设计阶段 硬件通用，软件专用；程序规模小，编写者和使用者为同一人（同组人）。 2. 第二代（60年代中期-70年代中期）程序系统阶段 出现“软件作坊”、产品软件；“个体化”开发方法。 3. 第三代（70年代中期之后）软件工程阶段 软件开发成为一门新兴的工程学科——软件工程。

5 计算机软件发展的三个时期及特点

6 计算机软件发展的三个时期及特点

7 1.2 软件危机 二、什么是软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是两个问题。
1.2 软件危机 二、什么是软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是两个问题。 1. 如何开发软件，怎样满足对软件的日益增长的需求。 2. 如何维护数量不断膨胀的已有软件

8 1.2 软件危机 三、软件危机的主要表现 1. 对软件开发成本和进度的估计不准确 2. 用户不满意 3. 软件质量不高、可靠性差
1.2 软件危机 三、软件危机的主要表现 1. 对软件开发成本和进度的估计不准确 2. 用户不满意 3. 软件质量不高、可靠性差 4. 软件常常不可维护、错误难以改正。 5. 缺乏适当的文档资料 6. 软件成本占系统总成本的比例逐年上升 7. 软件开发速度跟不上计算机发展速度

9 1.2 软件危机 四、产生软件危机的原因 1. 与软件本身的特点有关 2. 软件不易于维护
1.2 软件危机 四、产生软件危机的原因 1. 与软件本身的特点有关 软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。 2. 软件不易于维护 （1）软件维护通常意味着改正或修改原来的设计，客观上使软件较难维护。

10 1.2 软件危机 四、产生软件危机的原因 2. 软件不易于维护 3. 在软件开发过程中，或多或少地采用了错误的方法和技术。
1.2 软件危机 四、产生软件危机的原因 2. 软件不易于维护 （2）软件不同于一般程序，它的规模大，不易于维护。 3. 在软件开发过程中，或多或少地采用了错误的方法和技术。 4. 对用户需求没有完整准确的认识，就匆忙着手编写程序。

11 1.2 软件危机 五、解决软件危机的途径 1. 技术措施 2. 组织管理措施 使用更好的软件开发方法和开发工具
1.2 软件危机 五、解决软件危机的途径 1. 技术措施 使用更好的软件开发方法和开发工具 2. 组织管理措施 软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

12 1.3 软件工程 一、什么是软件工程 软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。 软件工程是一门涉及软件计划、需求分析、设计、编码、测试和维护的原理、方法及工具的研究和应用的学科。

13 1.3 软件工程 二、软件工程的基本原理 1968年在联邦德国召开的国际会议上正式“软件工程”术语。
1.3 软件工程 二、软件工程的基本原理 1968年在联邦德国召开的国际会议上正式“软件工程”术语。 目前有100多条关于软件工程的准则，其中最出名的是著名软件工程专家B.W.Boehm在1983年提出的7条基本原理。

14 1.3 软件工程 1. 用分阶段的生命周期计划严格管理 经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。
1.3 软件工程 1. 用分阶段的生命周期计划严格管理 经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。 Boehm认为，在软件的整个生命周期中应制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

15 1.3 软件工程 2. 坚持进行阶段评审 大部分错误是在编码之前造成的 错误发现与改正得越晚，所需付出的代价越高。
1.3 软件工程 2. 坚持进行阶段评审 大部分错误是在编码之前造成的 错误发现与改正得越晚，所需付出的代价越高。 因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程的错误

16 1.3 软件工程 3. 实行严格的产品控制 在软件开发过程中不要随意改变需求，因为改变某项需求往往需要付出较高的代价，但在实践中用户往往会提出需求变更，因此需要采取科学的产品控制技术。 目前主要实行基准配置管理：基准配置是指经过阶段评审后的软件配置成分，如各个阶段产生的文档或程序代码。 对涉及基准配置的修改，必须经过严格的评审，通过后才能实施修改。

17 1.3 软件工程 4. 采用现代程序设计技术 实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。
1.3 软件工程 4. 采用现代程序设计技术 实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。 80年代及之前：结构化分析、设计技术 90年代：面向对象分析、设计技术

18 1.3 软件工程 5. 结果应能清楚地审查 软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。
1.3 软件工程 5. 结果应能清楚地审查 软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。 根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，使所得的结果能够清楚地审查

19 1.3 软件工程 6. 开发小组的人员应该少而精 开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。
1.3 软件工程 6. 开发小组的人员应该少而精 开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。 开发小组人员数目的增加，使相互交流复杂、费用增加。

20 1.3 软件工程 7. 承认不断改进软件工程实践的必要性
1.3 软件工程 7. 承认不断改进软件工程实践的必要性 遵循前6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但不能保证赶上时代前进的步伐。 积极主动采纳新的软件技术，且不断总结经验。

21 1.3 软件工程 三、软件工程的传统途径 软件工程的传统途径是“生命周期法”，强调“结构化分析、结构化设计”。 1. “生命周期法”的起源
1.3 软件工程 三、软件工程的传统途径 软件工程的传统途径是“生命周期法”，强调“结构化分析、结构化设计”。 1. “生命周期法”的起源 人类解决复杂问题时普遍采用的一个策略是“各个击破”，也就是对问题进行分解，然后再分别解决各个子问题的策略。 软件工程采用的“生命周期法”，就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后再逐步完成每个阶段的任务。

22 1.3 软件工程 2. 生命周期划分的原则 3. 生命周期的划分
各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。 3. 生命周期的划分 软件生命周期一般分为：软件定义（问题定义、可行性研究、需求分析）、软件开发（总体设计、详细设计、编码和单元测试、综合测试）、软件维护等三个时期。

23 生命周期法各阶段的工作小结

24 生命周期法各阶段的工作小结

25 1.3 软件工程 4. “生命周期法”的特点 阶段具有顺序性和依赖性 推迟实现的观点 质量保证的观点 每个阶段都必须完成规定的文档
1.3 软件工程 4. “生命周期法”的特点 阶段具有顺序性和依赖性 推迟实现的观点 质量保证的观点 每个阶段都必须完成规定的文档 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

26 1.4 软件开发过程模型 一、瀑布模型 典型瀑布模型具有顺序性和依赖性

27 1.4 软件开发过程模型 瀑布模型的特征 从上一项活动中接受该项活动的工作对象，作为输入。 利用这一输入实施该项活动应完成的内容
1.4 软件开发过程模型 瀑布模型的特征 从上一项活动中接受该项活动的工作对象，作为输入。 利用这一输入实施该项活动应完成的内容 给出该项活动的工作成果，作为输出传给下一项活动 对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。

28 1.4 软件开发过程模型 软件维护往往经历软件生存期的各个阶段，从而构成生存期循环。

29 1.4 软件开发过程模型 具有维护循环的软件生存期的瀑布模型

30 1.4 软件开发过程模型 瀑布模型的缺点： 从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。 软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。

31 1.4 软件开发过程模型 二、原型模型 1. 基本思想 在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。

32 1.4 软件开发过程模型 原型：一个具体的可执行模型，它实现了系统的若干功能。
1.4 软件开发过程模型 原型：一个具体的可执行模型，它实现了系统的若干功能。 原型法：不断地运行系统“原型”来进行启发、揭示和判断的系统开发方法。

33 1.4 软件开发过程模型 2. 原型模型

34 1.4 软件开发过程模型 在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。

35 1.4 软件开发过程模型 在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。

36 1.4 软件开发过程模型 有了满意的系统原型，同时也积累了使用原型的经验，用户常会提出新目标，从而进一步重新原型周期。新目标的范围要比修改或补充不满意的原型大。

37 1.4 软件开发过程模型 3. 原型特征 软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征： (1)它是一个可实际运行的系统。

38 1.4 软件开发过程模型 (2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。

39 1.4 软件开发过程模型 (3)从需求分析到最终产品都可作原型，即可为不同目标作原型。 (4)它必须快速、廉价。
1.4 软件开发过程模型 (3)从需求分析到最终产品都可作原型，即可为不同目标作原型。 (4)它必须快速、廉价。 (5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。

40 1.4 软件开发过程模型 4. 原型法的评价 优点 1.原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信。 2.原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。 3.原型给用户以机会更改心中原先设想的、不尽合理的最终系统。 4.原型可低风险开发柔性较大的计算机系统。 5.原型增加使系统更易维护、对用户更友好的机会。 6.原型使总的开发费用降低，时间缩短。

41 1.4 软件开发过程模型 缺点 1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。
1.4 软件开发过程模型 缺点 1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。 2.原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分。 3.原型过快收敛于需求集合，而忽略了一些基本点。 4.资源规划和管理较为困难，随时更新文档也带来麻烦。 5.长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。

42 1.4 软件开发过程模型 适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替代生存期的部分或全部阶段，具体可以用于以下领域：
1.4 软件开发过程模型 适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替代生存期的部分或全部阶段，具体可以用于以下领域： 1.辅助分析和确定用户需求的任务。 2.作为软件设计的一种工具。例如：研究系统设计的可行性和适应性。 3.作为一种解决不确定性的工具。例如：研究一种新技术的效果，逐步使其适应预定的环境。 4.作为一种实验工具。 5.充作同步培训工具。 6.“一次性”的应用。例如写一个能运行的程序，一旦得到答案，该程序将不再使用。 7.作为软件维护的辅助工具。特别是在用户需求不稳定，维护工作量很大的情况下，要求大量的重新设计工作。

43 1.4 软件开发过程模型 不适用范围 1.嵌入式软件 2.实时控制软件 3.科技数值计算软件

44 1.4 软件开发过程模型 三、喷泉模型 喷泉模型认为软件生命周期的各个阶段是相互重叠和多次反复的。 主要用于面向对象方法中

45 1.4 软件开发过程模型 四、螺旋模型 在原型基础上，进行多次原型反复并增加风险评估，形成螺旋模型。

46 1.4 软件开发过程模型

47 1.4 软件开发过程模型

48 1.4 软件开发过程模型 螺旋模型分析 在螺旋模型结构中，维护只是螺旋模型的另一个周期，在维护和开发之间本质上并没有区别，从而解决了做太多测试或未作足够测试所带来的风险。 适用条件 内部的大规模软件的开发，不太适合合同软件。 一般只适用于大规模软件的开发

49 1.5 软件开发方法 结构化分析、设计 JACKSON设计方法 面向对象分析、设计

50 作业 1. 计算机发展三个时期及特点 2. 什么是软件危机？为什么会产生软件危机？怎样消除软件危机？
3. 什么是软件工程？软件生命期为什么要划分成阶段？怎样划分？各阶段有何特点？