《软件系统开发与软件工程方法讲义34371.pptx》由会员分享，可在线阅读，更多相关《软件系统开发与软件工程方法讲义34371.pptx（45页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、第七章 软件系统开发与软件工程方法 n n一、软件危机n n二、软件工程一、软件危机1、软件开发的发展历程 1960 1970 1980 1990 2000 早期 第二阶段 第三阶段 第四阶段面向批处理 多用户 分布式系统 强大的桌面系统有限的分布 实时 嵌入“智能”面向对象技术自定义软件 数据库 低成本硬件 专家系统开发者=使用者 软件产品 人工神经网络 并行计算 网络计算机一、软件危机2、软件危机 1）案例思考1FAA的失败项目 20世纪80年代中期，更换空中交通控制系统已成为美国联邦航空管理局（FAA）非常优先的任务。1989年IBM公司获得更换该系统的合同，截止期为2001年，预计投入
2、25亿美元。由于面临着极苛刻的需求，该软件项目是已进行的最复杂的项目之一。例如，交通控制系统必须具备全局完整性并且每周7天，每天24小时不能停止工作，甚至在升级时或正常维护时，也不允许有停顿时间。任何错误的数据都会引起重大伤亡，任何停机均会导致世界范围的出行延误或潜在的危险。该系统的反应时间不能超过2-3秒。此外，该系统设计时必须考虑到允许私人飞机驾驶员继续使用旧设备，并要求软件能在未来移植到更新的硬件设备上。当IBM获得该合同后，该系统的主要花费为软件开发，用于硬件的投入仅为8万美元。1993年，负责该项目的IBM子公司IBM联邦系统公司被IBM卖给了Loral公司。到1994年，该系统已花
3、费了23亿美元，但尚未提交系统的任何程序段，而此时估算整个系统的花费将增至50亿美元。1994年底，FAA不得不承认该项目失败并进行调查。作为调查的结果，FAA取消或修改了系统的四个主要部分。面临当前空中控制系统存在的隐患，FAA不得不订购了一套作为权宜之计的系统，由另一家公司开发。你认为该项目的失败反映了什么问题？失败的主要原因可能是什么？FAA为什么选择取消和修改的方式而不是增加资源和生产力的方式？FAA对此项目调查总结出的原因为以下几条：FAA并没有明确掌握某些系统功能的需求。制定了过于急躁的开发和实现计划（包括费用与进度的估计）在给定的软件复杂度下，没有考虑到开发商的生产力，尤其是早期
4、阶段需要投入的资源。在人月神话一书中，Brooks将过去30年大型软件项目的开发比喻为史前陷入沥青坑的巨兽。恐龙、猛犸、剑齿虎等动物在焦油中挣扎，然而挣扎得越激烈，就陷得越快，最终都沉到了坑底。过去的大型软件项目中，大多数开发出了可运行的系统不过只有极少数满足了目标、进度和预算的要求。表面上看起来没有任何一个单独的问题会导致困难，每个问题都能获得解决，但这些问题纠缠和积累在一起时，团队的行动就越来越慢，并且很难再看清问题的本质。1995年美国的商业软件失败统计：一、软件危机2、软件危机 案例思考2遗传信息库建设 在 正 在 建 设 的 遗 传 信 息 库 如，假 设 你 要 开 发 一 个 管
5、 理 软 件。你 并 不 是 一 个 生 物 遗 传 方 面 的 专 家，甚 至 对 此 方 面 的 知 识一 窍 不 通，你 该 如 何 入 手？要 使 该 项 目 成 功，你 认 为 应 该有哪些保障条件？你的问题是什么：对遗传信息的管理需要什么条件：了解遗传信息的表示和管理流程如何实现：与遗传领域的专家交流。障碍是什么：难以沟通与交流。可能因误解产生错误的需求描述。一、软件危机2、软件危机 软件项目为什么会失败？软件项目失败的核心问题在哪里？答案只有一个：复杂性。软件要解决的问题本身是复杂的开发人员一般不是该问题领域的专家软件规模要求多人参与，而不同专业领域的人的交流是困难的软件规模使得
6、既要理解系统整体结构又要把握细节比较困难。n例:Windows95有1000万行代码 Windows2000有5000万行代码Exchange2000和 Windows2000开发人员结构Exchange2000 Windows2000项目经理25人 约250人开发人员140人 约1700人测试人员350人 约3200人一、软件危机2、软件危机 2）软件神话 1管理神话神话：有关软件开发的理论和方法已经很丰富，有很多可用的标准与规范，因而可以保证软件开发的顺利进行。现实：理论与方法在大多数实践中并没有得到真正的应用。使用者并没有对这些理论与方法建立正确的认识。神话：已经有很多强大的开发工具和先
7、进的计算机硬件，这些可以保证软件开发的质量与效率。现实：这些工具并没有得到合理的应用。神话：如果我们落后于进度，可以通过增加人手来赶上。现实：向一个已经延迟的项目增加人手，只会使延迟的项目更加落后除非项目中不需要交流。生一个孩子10个月，无论有多少人。一、软件危机2、软件危机 2）软件神话 1管理神话神话：通过把软件项目外包给实现强大的软件开发公司可以保证软件的成功。现实：再专业的软件公司，不了解客户的需求和业务流程，也不可能顺利完成软件开发项目。改正一个问题需付出的代价需求分析结构设计详细设计编码集成测试系统测试现场改正一个问题的估计费用改正一个问题估计的工作量20200200010005.
8、02.50.050.5(美元)(人天)一、软件危机2、软件危机 2）软件神话 2客户神话神话：有了目标系统的一般性描述就可以写程序了，细节可以逐步完善。现实：糟糕的系统定义是项目失败的主要原因。关于问题域、功能、行为、性能、接口、设计约束以及确认标准的形式化的、详细的描述是必要的，这些内容只能通过客户与开发者之间的交流才能确定。神话：软件需求是经常变更的，而这些变更可以容易的被满足，因为软件是灵活的。现实：软件需求确实是容易变更的，但变更的代价将随软件开发的进度不同而有很大的差异。如果重新项目早期的问题定义，需求变化则很容易被调节，而项目后期需求变更的代价可能是致命的。一、软件危机2、软件危机
9、 2）软件神话3实践者的神话神话：软件是艺术，软件开发是个人的舞台。现实：50年代可能是，现在不是。神话：一旦写完了程序并能正常运行，我们的工作就结束了。现实：越早开始写代码，软件开发花费的时间就越长。统计表明60%到80%的工作量是花在将软件第一次交付给客户以后发生的。神话：程序真正运行以前，没有办法评估其质量。现实：高质量的实现来自高质量的设计。从项目一开始就必须进行技术评审。神话：项目的成功来自于可运行程序的提交。软件开发过程中的文档是不必要的，延缓项目进度的东西。现实：软件项目的成果包含很多内容，文档是成功开发的基础，也是软件质量的保证。好的开发质量降低了重复劳动，从而提高了效率，导致
10、更短的交付时间。一、软件危机2、软件危机 3）软件危机及主要表现软件危机指在计算机软件开发和维护过程中所遇到的一系列严重问题软件开发不能满足日益增长的需求；难以维护不断增长的已有软件。1成本与进度的估计2用户需求与产品不一致3软件可靠性差4可维护性差5文档资料不完整6软件成本比例不断上升7开发生产率相对停滞一、软件危机2、软件危机 3）软件项目成败的因素分析1）失败项目的主要原因1用户需求不完整、被误解或经常变化2有限的用户参与3缺少行政支持4缺少技术支持5项目计划不充分6目标不明确7没有足够的资源（客户没有提供/开发者不具备相应生产力）2）成功项目的主要原因1大量的用户参与2上层管理人员的支
11、持3完整、详细的项目计划4符合实际的工作进度与里程碑5开发人员的培训、交流6良好的工作环境、团队协作机制一、软件危机2、软件危机 3）消除软件危机的思路1正确的观念a)软件不是程序软件是逻辑产品而不是实物产品软件的功能依赖于硬件和软件的运行环境以及人们对它的操作软件特征：功能的多样性 实现的多样性 能见度低 软件结构合理性差智力密集及知识产权保护b)软件开发不是个体劳动软件设计的复杂性一、软件危机2、软件危机 3）消除软件危机的思路2正确的过程管理与控制u软件开发技术:软件开发方法 软件开发过程 软件工具和软件工程环境 u软件工程管理:软件管理 软件经济 软件心理二、软件工程1、软件工程 将工
12、程管理思想引入软件开发过程：u 转变对软件的认识：上升 程序 系统u 转变思维定式：上升 程序员 系统工程师(系统分析员)n 工程化训练二、软件工程1、软件工程 将工程管理思想引入软件开发过程：用户 分析员程序员“一个好的工业，应有一套良好的标准来配套”软件的工业化生产过程应具备的特点：n明确的工作步骤n详细具体的规范化文档n明确的质量评价标准软件产品的标准化软件产品的标准化软件开发过程的标准化软件开发过程的标准化u 强调规范化u 强调文档化软件工程技术的两个明显特点：软件工程技术的两个明显特点：二、软件工程1、软件工程 Fritz Bauer在NATO会议上给出的定义：“软件工程是为了经济地
13、获得可靠的和能在实际机器上高效运行的软件而确立和使用的健全的工程原理（方法）。”二、软件工程1、软件工程 IEEE【IEE83】给出的软件工程定义：“软件工程是开发、运行、维护和修复软件的系统方法。”二、软件工程1、软件工程 IEEE【IEE93】给出了一个更加综合的定义：“将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。”二、软件工程1、软件工程 软件工程是应用计算机科学、数学及管理科学等原理开发软件的工程。它借鉴传统工程的原则、方法，以提高质量，降低成本为目的。软件工程所包含的内容不是一成不变的，而是软件工程所包含的内容不是一成不变的，而是随着人
14、们对软件系统的研制开发和生产的理解随着人们对软件系统的研制开发和生产的理解不断发展变化不断发展变化，应该用发展的眼光看待。应该用发展的眼光看待。二、软件工程1、软件工程软件工程是一种层次化的活动，a)质量软件工程的根基与目标b)过程建造一个高质量软件所需完成任务的框架c)方法提供了如何建造软件的技术手段d)工具为过程和方法提供自动或半自动化的支持（CASE）工具方法过程质量焦点二、软件工程2、软件工程一般视图 工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先 工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首先工程：对技术（或社会）实体的分析、设计、构造、验证和管理。首
15、先要问题的问题：要问题的问题：要问题的问题：要解决什么问题？要解决什么问题？要解决什么问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？实体的什么特征能解决这个问题？如何设计该实体？如何设计该实体？如何设计该实体？如何构建该实体？如何构建该实体？如何构建该实体？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何控制和避免构建过程中的错误？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？如何在用户要求修改、适应和增强时长期地支持这些实体？定义阶段：做什么 定义阶段：做什么定义阶段：做什么开发阶段：如何做 开
16、发阶段：如何做开发阶段：如何做支持阶段：应对变化 支持阶段：应对变化支持阶段：应对变化项目跟踪与控制项目跟踪与控制技术评审技术评审质量保证质量保证软件配置管理软件配置管理文档管理文档管理复用管理复用管理测试管理测试管理风险管理风险管理支持活动支持活动软件工程框架可用性 性 性确正合算选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视软件工程的管理基本过程原则 目标 过 程支支持持过过程程组组织织过过程程软件过程评估软件能力成熟度软件能力成熟度CMMCMM1-1-初始级：没有过程定义，个人能力。初始级：没有过程定义，个人能力。2-2-可重复级：基本项目管理过程，跟踪费用可重复级：基本项
17、目管理过程，跟踪费用与进度，有必要的规范以重复类似项目的成与进度，有必要的规范以重复类似项目的成功。功。3-3-定义级：过程管理文档化、标准化、集成定义级：过程管理文档化、标准化、集成化。使用统一的文档化的组织过程认可的方化。使用统一的文档化的组织过程认可的方法开发和维护软件。法开发和维护软件。4-4-管理级：对软件过程与产品质量进行详细管理级：对软件过程与产品质量进行详细地定量地收集与评估地定量地收集与评估5-5-优化级：通过定量反馈不断进行过程优化优化级：通过定量反馈不断进行过程优化与改进。与改进。二、软件工程3、软件开发过程软件生命周期 软件产品或软件系统从设计、投入使用到被淘汰的全过程
18、。软件生存期的阶段划分(1)可行性研究与计划(2)需求分析(3)总体设计(4)详细设计(5)实现(6)集成测试(7)确认测试(8)使用和维护二、软件工程3、软件开发过程软件开发模型 软件开发模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。软件开发模型也常称为：软件过程模型 软件生存期模型 软件工程范型二、软件工程2、软件开发过程瀑布模型 可行性研究与计划需求分析设计编码运行维护测试定义阶段开发阶段维护阶段按照传统瀑布模型开发软件的特点1.阶段间具有顺序性和依赖性。2.推迟实现的观点。3.每个阶段必须完成规定的文档;每个阶段结束
19、前完成文档审查,及早改正错误。二、软件工程2、软件开发过程原型模型 建造/修改 原型用户测试运行原型 听取用 户意见采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运 行和维护原型化含原型化的软件生存期二、软件工程2、软件开发过程增量模型 先完成一个系统子集的开发，再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。系统的总体设计在初始子集设计阶段就应作出设想。分析 增量模型设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 分析 设计 编码 测试 增量增量11增量增量22增量增量33增量增量nn 增量增量11交付客户交付客户 增量
20、增量22交付客户交付客户 增量增量33交付客户交付客户 增量增量nn交付客户交付客户日历时间日历时间.风险分析工程实施用户通信用户评估产品维护项目产品维护项目产品增强项目产品增强项目新产品开发项目新产品开发项目概念开发项目概念开发项目计划计划建造及发布建造及发布22、软件开发过程、软件开发过程螺旋模型螺旋模型V1.0功能时间时间V2.0V1.1二、软件工程进一步开发实现和集成阶段运行状态实现阶段计划阶段面向对象分析阶段需求阶段维护期22、软件开发过程、软件开发过程喷泉模型喷泉模型2、软件开发过程组件模型与软件生产线应用构件提取车间 应用构件库构件生产车间 构件库组装车间领域 1领域 2应用系统.12341基础构件，2功能构件 3接口构件，4用户界面构件