1 / 139

内容摘要

内容摘要. 软件的概念与特点 软件危机 软件工程 软件生命周期 软件过程 敏捷软件开发 CASE 工具与环境. 第一章 软件工程概述. … …. 传统工程. 水利工程. 建筑工程. 机械工程. 新兴工程. 气象工程. 生物工程. 软件工程. 本章将介绍软件的地位和作用、软件的特点、软件 的发展、软件危机、软件工程、软件生命周期以及软件 过程等方面的问题和基本概念. 1.1 软件的概念与特点. 1、软件. software. soft+ware. 软制品 (软体). 软件是计算机系统中与硬件相互依存的另一部分。

adelle
Download Presentation

内容摘要

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 内容摘要 软件的概念与特点 软件危机 软件工程 软件生命周期 软件过程 敏捷软件开发 CASE工具与环境

  2. 第一章 软件工程概述 …… 传统工程 水利工程 建筑工程 机械工程 新兴工程 气象工程 生物工程 软件工程 本章将介绍软件的地位和作用、软件的特点、软件 的发展、软件危机、软件工程、软件生命周期以及软件 过程等方面的问题和基本概念

  3. 1.1 软件的概念与特点 1、软件 software soft+ware 软制品 (软体) 软件是计算机系统中与硬件相互依存的另一部分。 它包括程序、数据及其相关文档的完整集合。

  4. 失效率 失效率 时间 时间 硬件失效率曲线 软件失效率曲线 2、软件特点 . 软件是一种逻辑实体,而不是具体的物理实体 . 软件的生产与硬件不同 . 在软件的运行和使用期间,没有硬件那样的机械 磨损,老化问题 修改点 实际曲线 磨合调整 磨损用坏 理想曲线

  5. 软件复杂性 成本% 软件需求 差距 硬件 软件技术 软件 时间 1950 1970 1985 1995 年份 软件技术的发展落后于需求 硬、软件成本比例的变化 . 软件的成本相当昂贵

  6. 1、按软件的功能进行划分 系 统 软 件 支 撑 软 件 应 用 软 件 3、软件的分类

  7. 支撑软件

  8. 按开发软件所需的 人力、时间以及完成的 源代码行数。 2、按软件的规模进行划分

  9. 3、按软件开发划分 软 件 项 目 开 发 软 件 产 品 开 发

  10. 1.2 软件危机 1、什么是软件危机   软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。 上个世纪60年代开始显现出来的“软件危机”催生了“软件工程”这门指导计算机软件开发和维护的工程学科。

  11. 2、 产生软件危机的原因 - 软件缺乏“可见性”。 导致“对软件开发成本、工作量、进度的估计不准确”; - 对用户需求没有完整准确的认识、不能适应用户需求的变化。 导致“用户对‘已完成的’软件系统不满意的现象经常发生”; - 缺乏对软件产品和开发过程的质量控制。 导致“软件产品的质量往往靠不住”; - 软件本身的可维护性差、开发商缺乏对维护的重视和准备、缺乏正确的维护方法。 导致“软件常常不可维护”;

  12.   - 开发、维护过程中文档化工作做得不好、缺乏配置管理。 导致“软件通常不具有良好一致性的文档资料”;   - 硬件成本逐年下降,但软件成本居高不下。 导致“软件成本在计算机系统总成本中所占的比例逐年上升”;   - 近10来年,软件开发生产率有较大的提高,但计算机应用普及深入的速度更快。 导致“软件开发生产率提高的速度,跟不上计算机应用普及深入的速度”。

  13. 3、 解决软件危机的途径 • 首先,应该对软件产品、系统有一个正确的认识。软件不仅仅是程序。 • IEEE对软件的定义:Computer programs, procedures, associated documentation and data pertaining to the operation of a computer system. • 应该充分认识软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。

  14. 应该总结软件开发的成功经验,应用软件工程领域的先进思想、原理、方法、技术(针对具体公司、项目进行定制)。应该总结软件开发的成功经验,应用软件工程领域的先进思想、原理、方法、技术(针对具体公司、项目进行定制)。   最后,应该(开发)、采用适当的软件工具,尤其是CASE工具,来帮助完成软件开发工作。

  15. 1.3 软件工程 • 1、 软件工程介绍 • 软件工程是指导计算机软件开发和维护的一门工程学科。 • 采用工程的概念、原理、技术和方法来开发和维护软件,并融合其他学科、行业(如:管理、建筑、客户服务)的原理、技术和经验,以规范、高效、可度量、可管理地开发出高质量的软件并维护它。 • “经济”?

  16. 软件工程特性: • 更多关注大型程序的构造; • 关注对复杂性、风险的控制,关注可度量、可管理性; • 重视软件系统的变化,要求软件系统对变化的适应性,要求变动控制; • 强调软件开发的效率(涉及方法、工具);

  17. 强调合作开发、团队协作、沟通 • 重视用户(需求、反馈、技术支持等),重视和用户的交流;强调软件系统应能为用户提供价值、可用性; • 强调开发团队应具备相关行业的业务知识、建立系统语境、通过有效沟通准确捕获用户需求。

  18. 2、 软件工程的基本原理 Barry W. Boehm总结既有的软件工程准则,提出了7条软件工程基本原理:   1 用分阶段的生命周期计划严格管理;   2 坚持进行阶段评审;   3 实行严格的产品控制(配置管理);   4 采用现代(先进的)程序设计技术;   5 结果应能清楚地审查;   6 开发小组的成员应该少而精;   7 承认不断改进软件工程实践的必要性;

  19. 3、 软件工程的方法学 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学methodology。 软件工程方法学包含3个要素:方法、工具和过程。

  20. * 软件工程传统途径(传统方法学) • 把软件生命周期的全过程依次划分为若干个阶段,顺序地完成每个阶段的任务。 每一个阶段的开始和结束都有准则或标准。 • 采用结构化技术(结构化分析、设计和实现)来完成软件开发各阶段的各项任务。 • 每个阶段结束前都进行正式的技术审查和管理复审。

  21. 技术审查 • 帮助即时、尽早发现、纠正工程技术方面的错误;保证软件质量。 • 软件错误的积累和放大效应图  • 目标主要是各个阶段的工程制品。 如:系统范围是否恰当?技术方案是否可行?架构是否稳定?模型是否正确?

  22. 管理复审 • 主要任务是对项目的开销、工作量、资源(人力)、进度、风险等进行审查。 帮助决定开发是否继续,帮助对下一阶段的工作进行计划、对软件开发过程进行改进。

  23. * 面向对象方法学 客观世界的问题都是由客观世界中的实体及实体间的关系构成的。 面向对象方法把程序看作是相互协作而又彼此独立的对象的集合;而不是工作在数据上的过程或函数的集合。 传统语言提供的解空间对象不能满足要求。 用计算机系统解决客观世界的问题,希望实现解法的解空间与问题空间的结构尽可能一致。 面向对象方法学提供的解空间与客观世界问题空间的结构更一致。 面向对象方法是把数据和处理相结合的方法。对象是由数据及可以施加于这些数据的操作所构成的统一体。

  24. 要点: • 1 面向对象方法学认识问题空间,分析、解决问题是用对象的观点。 • 2 把对象抽象为类,类中定义数据和方法;类实例化即为对象。 • 3 类层次结构 • 4 对象之间通过传递消息相互联系。

  25. 1.4 软件生命周期 • 不同时期,不同的目标、任务。 • * 生命周期各阶段的基本任务: •   1 问题定义 • - 要解决的问题是什么?性质、范围? • - 客户的目标?软件系统的价值? 最后系统分析员应提交开发方和客户都认可的书面报告。

  26. 2 可行性研究 •   对上一阶段提出的问题有可行的解决方案吗? - 技术可行性 - 经济可行性(时间、人员等) - 操作可行性 • 3 需求分析 •   用户有哪些具体需求?为了满足客户的需求,系统必须具备哪些功能? - 准确、完整地捕获用户需求。 - 系统分析员要提出经用户确认的系统逻辑模型。

  27. 4 总体设计 / 架构设计 •   要解决问题、满足用户需求,软件系统的总体架构是怎样的? - 首先,架构设计师应该考虑几种可能的解决方案(Windows/Linux、.Net/J2EE、C/S or B/S、满足不同需求功能集的不同方案)。 - 选择、推荐最佳方案。 - 对确定的方案进行更具体的设计、描述(建立模型图、说明),包括对软件系统进行模块化,划分子系统、确定接口。

  28. 5 详细设计 •   软件系统、子系统/模块 具体应该是怎样的? - 算法(PDL语言、流程图等)。 - 数据结构、函数/过程、类的定义。 - 建立模型图。 6 编码和单元测试 - 用选定的编程语言书写程序(子系统/模块、类/组件、函数等),然后编译/翻译/汇编为机器代码。 - 对这些子系统/模块进行单元测试。

  29. 7 综合测试 •   软件是否实现了功能需求和非功能需求? •   - 集成测试 •   - 系统测试 •   - 用户验收测试 写:测试计划(测试策略、进度)、测试结果记录、测试结果分析、评估、报告。

  30. 8 维护 •   - 改正性维护 •   - 适应性维护 •   - 完善性维护 •   - 预防性维护 维护要求、审查、计划(维护方案)、维护、回归测试、维护记录、复查验收。

  31. 1.5 软件过程 软件过程是为了获得高质量软件所需要完成的一系列任务的框架,它规定了完成各项任务的工作步骤。 通常使用生命周期模型简洁、直观地描述软件开发、运行、维护的过程。

  32. 能力成熟度模型CMM CMM(Capability Maturity Model)即能力成熟度模型,是美国卡耐基梅隆大学软件工程研究所(SEI)在美国国防部资助下于二十世纪八十年代末建立的,用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初,主要目的在于提供一种评价软件承接方能力的方法,为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来,又同时被软件组织用于改进其软件过程。

  33. 软件组织的成熟与不成熟 1. 不成熟的软件组织 软件过程一般并不预先计划,而是在项目进行中由实际工作人员及管理员临时计划 有时,即使软件过程已计划好,仍不按计划执行 没有一个客观的基准来判断产品质量,或解决产品和过程中的问题 对软件过程步骤如何影响软件质量,一无所知,产品质量得不到保证。而且,一些提高质量的环节,如检查、测试等经常由于要赶进度而减少或取消

  34. 产品在交付前,对客户来说,一切都是不可见的产品在交付前,对客户来说,一切都是不可见的 没有长远目标,管理员通常只关注解决任何当前的危机 由于没有实事求是地估计进度、预算,因此他们经常超支、超时。当最后期限临近,他们往往在功能性和质量上妥协,或以加班加点方式赶进度

  35. 2. 成熟的软件组织 具有全面而充分的组织和管理软件开发和维护过程的能力 管理员监视软件产品的质量以及生产这些产品的过程 制定了一系列客观基准来判别产品质量,并分析产品和过程中的问题 进度和预算可以按照以前积累的经验来制定,结果可行。预期的成本、进度、功能与性能和质量都能实现,并达到目的 能准确及时地向工作人员通报实际软件过程,并按照计划有规则地(前后一致,不互相矛盾)工作

  36. 凡规定的过程都编成文档 软件过程和实际工作方法相吻合。必要时,过程定义会及时更新,通过测试,或者通过成本-效益分析来改进过程。 全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中,每人在软件过程中的职责都十分清晰而明确,每人各守其责,协同工作,有条不紊,甚至能预见和防范问题的发生。

  37. 软件过程成熟度等级 CMM提供了一个成熟度等级框架: 1级-初始级、 2级-可重复级、 3级-已定义级、 4级-已管理级和5级-优化级。 1.初始(initial)级: 软件过程的特点是无秩序的,甚至是混乱的。几乎没有什么过程是经过妥善定义的,成功往往依赖于个人或小组的努力。 2.可重复(repeatable)级: 建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律,能重复早先类似应用项目取得的成功。

  38. 3.已定义(defined)级: 己将管理和工程活动两方面的软件过程文档化、标准化,并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。 4.已管理(managed)级: 收集对软件过程和产品质量的详细度量值,对软件过程和产品都有定量的理解和控制。 5.优化(optimizing)级: 整个组织关注软件过程改进的持续性、预见及增强自身,防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进。

  39. 5.优化级 持续改进的过程 4.已管理级 3.已定义级 2.可重复级 软件过程成熟度 的5个等级 1.初始级 标准、一致的过程 可预测的过程 有纪律的过程

  40. 能力成熟度模型的结构 CMM结构 成熟度等级 实现 解决 描述 表明 包含 包含 过程能力 目标 实施或制度化 活动或基础设施 关键过程域 划分为 共同特性 关键实践

  41. 能力成熟度模型的结构 成熟度等级表明了一个软件组织的过程能力的水平。除初始级外,每个成熟度等级都包含若干个关键过程域(Key Process Area,简称KPA)(见表1.2) 达到某个成熟度级别,该级别(以及较低级别)的所有关键过程域都必须得到满足,并且过程必须实现制度化。

  42. CMM提供了18个关键过程域,每个关键过程域都有一组对改进过程能力非常重要的目标,并确定了一组相应的关键实践 CMM提供了18个关键过程域,每个关键过程域都有一组对改进过程能力非常重要的目标,并确定了一组相应的关键实践 目标说明了每一个关键过程域的范围、界限和意义。 关键实践描述了建立一个过程能力必须完成的活动和必须具备的基础设施,完成了这些关键实践就达到了相应关键过程域的目标,该关键过程域也就得到了满足。 每个关键过程域的关键实践都是按照五个共同特性(执行约定,执行能力,执行活动,测量和分析,验证实现)进行组织的,主要解决关键实践的实施或制度化问题。

  43. 共同特性将描述关键过程域的关键实践组织起来。共同特性是一些属性,指明一个关键过程域的执行和规范化是否有效、可重复和可持续。共有5个共同特性: 执行约定,执行能力,执行活动,测量和分析,验证实现。 1)执行约定: 执行约定描述机构为确保过程的建立和持续而必须采取的一些措施。典型内容包括建立机构策略和领导关系。

  44. 2)执行能力: 执行能力描述了项目或机构完整地实现软件过程所必须有的先决条件。典型内容包括资源、机构结构和培训。 3)执行活动: 执行活动描述了执行一个关键过程域所必需的活动、任务和规程。典型内容包括制定计划和规程、执行和跟踪以及必要时采取纠正措施。

  45. 4)测量和分析: 测量和分析描述了为确定与过程有关的状态所需的基本测量实践。这些测量可用来控制和改进过程。典型内容包括可能采用的测量实例。 5)验证实现: 验证实现描述了为确保执行的活动与已建立的过程一致所采取的步骤。典型内容包括管理部门和软件质量保证组实施的评审和审核。

  46. 在执行活动这个共同特性中的实践描述了建立一个过程能力所必须完成的活动。所有其他实践共同形成了一个使机构能将执行活动中描述的实践进行规范化的基础。在执行活动这个共同特性中的实践描述了建立一个过程能力所必须完成的活动。所有其他实践共同形成了一个使机构能将执行活动中描述的实践进行规范化的基础。 各关键过程域的详细描述,参见《能力成熟度模型(CMM):软件过程改进指南》,卡耐基梅隆大学软件工程研究所编著,刘孟仁等译,电子工业出版社出版。

  47. 能力成熟度级别中的关键过程域 优化级 缺陷预防 技术更新管理 过程更改管理 已管理级 定量过程管理 软件质量管理 已定义级 机构过程焦点 机构过程定义 培训大纲 综合软件管理 软件产品工程 组间协调 同行评审 可重复级 需求管理 软件项目计划 软件项目跟踪和监督 软件分包合同管理 软件质量保证 软件配置管理 初始级

  48. 关键过程域实例 机构过程焦点 第3级的关键过程域:已定义级 机构过程焦点的目的是,为能改进机构整体软件过程能力的软件过程活动 建立机构的职责。 机构过程焦点包括,建立和维护机构的软件过程和项目软件过程(之间)的默契关系,并协调有关评估、开发、维护和改进这些过程的活动。 机构提供长期的约定和资源,以协调现在和将来的软件项目的软件过程的开发和维护。该项工作由某个小组实施,例如软件工程过程组。它负责机构的软件过程活动,特别是负责开发和维护机构标准软件过程和相关过程资源(如在机构过程定义关键过程域中说明的),并协调软件项目的过程活动。

  49. 目标 目标1:机构内部软件过程的制定和改进活动协调一致。 目标2:相对于过程标准,所使用的软件过程的优势和薄弱环节标识清楚。 目标3:机构级的过程开发和改进活动有计划。

  50. 执行约定 约定1:机构遵循书面的管理策略,协调整个机构范围内的软件过程开发和改进活动。 该策略一般规定: 1. 建立一个小组,负责机构级的软件过程活动,使这些活动与各项目协调一致。 2. 定期评估项目所使用的软件过程,以确定其优势和薄弱环节。

More Related