现代软件工程专题1(精)

上传人:xmg****18 文档编号:120157548 上传时间:2020-02-04 格式:PPT 页数:38 大小:752KB
返回 下载 相关 举报
现代软件工程专题1(精)_第1页
第1页 / 共38页
现代软件工程专题1(精)_第2页
第2页 / 共38页
现代软件工程专题1(精)_第3页
第3页 / 共38页
现代软件工程专题1(精)_第4页
第4页 / 共38页
现代软件工程专题1(精)_第5页
第5页 / 共38页
点击查看更多>>
资源描述

《现代软件工程专题1(精)》由会员分享,可在线阅读,更多相关《现代软件工程专题1(精)(38页珍藏版)》请在金锄头文库上搜索。

1、专题一 软件工程现状及其发展 软件发展现状软件危机软件风险软件工程及其发展阶段软件工程框架软件开发模型软件发展趋势 软件产业化 一 软件发展现状 1 已经存在大量正在运行的软件 金融 电信 航空航天等 2 软件的应用范围不断扩大 商务 交通 家电等 软件无处不在 3 软件的规模与复杂性持续增加非常大规模系统 从50万行增加到1000万行 扩大了20倍 复杂性 a 子系统数目越来越多 b 计算机应用从数值计算开始发展到几百万条指令的大型企业业务应用 再发展到几千万终端用户直接交互工作的网络应用 4 出现了大量与软件相关的标准 CORBA UML XMI TMN等 5 软件危机仍然存在 软件脱节

2、1968 2000 软件效率 质量 进度 预算无法控制 一 软件发展现状 问题 1 没有 计算机 和 软件 世界会是什么样子 人们的生活已经无法离开计算机软件 2 如何更多 更快 更方便 更好地开发出软件 工程化地管理软件开发 1968年NATO提出软件工程的概念 SE 倡导以工程的原理 原则和方法进行软件开发 以期解决当时出现的 软件危机 3 如何重用过去的经验呢 软件体系结构风格 设计模式 部件等 4 在分布式网络环境下如何提高软件的适应能力呢 CORBA COM DCOM JavaBean等 EAI 二 软件危机 1 什么是软件危机 指在计算机软件开发和维护过程中所遇到的一系列问题 1

3、软件开发无计划性 不能正确估计软件开发成本和进度 无法估计工作量 难于控制开发进度 2 软件需求不充分 需求是设计的基础 需求不充分直接导致软件产品不可靠 满足不了用户的需求 甚至无法使用 3 软件开发过程无规范性 各行其是 没有文档 软件工程过程中的四个基本活动 规格说明 开发 确认 演进 4 软件无评测手段 软件质量无法保证 软件产品质量度量 软件过程质量控制和保证 二 软件危机 2 什么原因导致软件危机的 1 软件的固有特征 软件是复杂的 实际问题的复杂性 感知接受的复杂性 理性表达的复杂性 另外 软件规模不断扩大 2 外部原因 软件开发范型 模型 软件设计方法 方法 软件开发支持 工具

4、 软件开发管理 过程 三 软件风险 软件危机的解决办法 软件工程软件工程技术和管理方法可以帮助人们克服软件危机问题 但不能解决软件风险 有可能造成的伤害或者损失 问题 软件风险是任何软件开发项目中普遍存在的问题 与项目的大小成正比 因为 在制定软件计划时 系统分析员必须回答 项目的需求是什么 不可能准确无误地回答需要投入多少资源 只能凭经验估计给出初步设想如何安排开发进度 这样就存在风险 三 软件风险 实践证明 项目规模越大 问题越复杂 资源 成本 进度等因素的不确定性就越大 承担项目所冒的风险也越大 因为 项目越大 了解项目的时间越长 系统状态的确定越长 而风险正是介于确定与不确定之间 无知

5、和完整知识之间的 风险是软件开发不容忽视的潜在的不利因素 可能损害软件开发过程和质量 三 软件风险 进度过分紧迫 预算过分紧张 性能过分的超群 软件可靠性要求过高 人员缺乏经验 组织结构不适宜 期望过高而不现实 没有明确或理解合同的条款 软件规模估计不恰当 管理部门缺乏经验 风险分析和管理不恰当 缺乏政策性支持 不熟悉技术或过程 不熟悉必要的硬件 需求不一致 或定义不充分 需求不断变动 软件开发计划不恰当 软件开发过程模型不适用 缺乏软件工程技术和方法 缺乏自动化工具的支持 常见的软件风险类别 进度 经费 性能 组织 管理 人事 过程 方法 工具等 如下例证 3 1风险估计 是否所有项目都要进

6、行风险分析 No 风险分析成本较高 只有当软件的成本 性能 作用 与其他系统间的关系对于重要的系统有比较大的影响时 即软件的风险对整个系统的成败有关键影响时 才有必要进行风险分析和管理 风险估计的步骤1 明确项目的目标 策略 可以使用的方法和资源 2 保证项目的目标和结果是可度量的 并标明使用的资源 3 制定项目成功的标准集合 见下页 4 根据估计的结果确定是否进行风险分析 3 1风险估计 度量项目成功的标准 1 最大限度的收益 2 最小的费用 3 最小的风险损失 4 最大限度的市场 5 最小的周期性波动 6 形成有益的形象 7 最佳的服务质量 8 最高的增长率 9 员工的满意度最高 10 公

7、司的声望最高 3 2风险分析 第一步 标识潜在风险项 收集信息 标明相关的风险 观察风险的征兆 理解其原因 收集信息 主要依靠过去的经验和一些著名的案例 考虑类似的因素并进行常识性的判断 如需求变动的风险 判断收集到的信息是否有用 信息分类 如 有风险 经常发生的情况 可预见的风险 较高概率发生 不可预见的风险 事前很难预料 原因可分为 缺乏信息 管理和时间等 3 2风险分析 第二步 估计每个风险的大小及其出现的可能性 度量风险的后果和严重程度 选择一种度量尺度 命名尺度 序次尺度 坐标尺度 比例尺度等 将待估计的风险信息 叙述性 定性 定量三种类型 与度量尺度相对应 确定风险等级 消除风险估

8、计中的主观判断的偏差 缺乏可以用来进行判断风险的信息 只能凭自己的观念和偏好进行主观理解 与客观情况必然存在着偏差 3 2风险分析 第三步 风险评估 要考虑风险间的相互作用 第二步考虑的是单个风险的影响 考虑各种风险的综合影响后 对已识别风险发生的可能性及其后果给出最终的量值 标明风险优先程度 以便予以适当安排 考虑其它可替代的方案 寻求可以避免风险的基本方法 3 3风险评估步骤 第一步 确定风险评估标准 确定风险的后果 判定该风险是否可以忍受 第二步 确定风险最终的级别 风险特征的三个方面 发生频率 损害的严重性 发生的时刻可知性 第三步 把系统风险和 对照风险 相比较 确定系统风险是否可以

9、接受 不可能接受 不适合接受 3 3风险评估步骤 什么是 对照风险 呢 对照风险是一组单个风险的集合 也可是对项目造成最大损害的一个或多个风险 对照风险考虑了风险间可能发生的耦合或复合情况 对照风险说明了在把系统作为整体条件下 风险会造成系统失败或成功的概率 3 4风险管理 风险管理的本质 制定防止风险的计划 并监管风险 风险是不可能消除的 只能防止 风险管理的时机 已经发现存在重要的软件风险 这些风险可能影响项目的目标 这些风险将使系统花费大量的运行费用及支持费用 这些风险是可能防止的 3 4风险管理 风险管理的任务 制定风险计划 风险管理计划 RMP和风险排除计划 RA version P

10、 确定风险可接受目标 调整新的 对照风险 寻求可替代的解决方案 进行风险控制 执行风险计划中体现风险排除策略的控制机制 确定风险排除策略 后果 时间和频率 确定风险排除战术 建立在软件工程过程基础上 建立风险管理计划 有关工作编入文档 风险状态估计RES说明项目的总体状况 风险管理计划RMP说明如何在一个项目中施行风险分析和管理程序 风险排除计划RAP是排除风险的详细计划 对风险进行监管 监管软件工程过程和产品 确定风险排除策略是否达到预期目标 是否有可能进一步改进风险排除计划 为控制新的风险提供一些必要的决策信息等 四 软件工程及其发展阶段 软件工程是一类求解软件的工程 它应用计算机科学 数

11、学 用于构造模型和算法 和管理科学 用于计划 资源 质量和成本等的管理 等原理 借鉴传统工程 用于制定规范 设计范型 评估成本 权衡结果 的原则和方法 创建软件以达到提高质量 降低成本的目的 软件工程是一门指导计算机软件开发和维护的工程学科 四 软件工程及其发展阶段 软件工程经历了30多年的历史 其发展大致可以划分为两个阶段 1 60年代末 80年代初状况 软件系统的规模 复杂性以及在关键领域的广泛应用 促进了软件开发过程采纳工程化的方法进行管理 研究 开发模型 支持工具 开发方法 成果 瀑布模型 结构化语言 pascal等 结构化方法 各种管理方法 如费用估算 文档复审 事件 前期主要研究系

12、统实现技术 后期则开始强调管理和软件质量 焦点 软件项目 四 软件工程及其发展阶段 2 80年代初 现在状况 软件工厂 的概念已经提出 研究 软件生产技术 特别是软件复用技术和软件生产管理的研究和实践 成果 提出了具有广泛应用前景的面向对象方法和相关的编程语言 事件 软件过程改进 在工业实践中建立起一种量化的评估程序 判定软件组织成熟的程度 焦点 软件过程 四 软件工程及其发展阶段 近几年 研究从过程管理转向产品开发 更加注重新的程序开发范型和软件生产 范围 面向agent语言 复用技术 需求分析规格说明的形式化研究 高智能高自动化的CASE成为热点 五 软件工程框架 软件工程的框架是由软件工

13、程目标 软件工程活动和软件工程原则三个方面的内容构成的 软件工程活动维 软件工程目标维 软件工程原则维 5 1软件工程目标 目标 生产具有正确性 可用性以及开销适宜的软件产品 正确性 软件产品达到预期功能的程度 可用性 软件基本结构 实现及文档为用户可用的程度 开销适宜 软件开发 运行的整个开销满足用户要求的程度 决定了 软件过程 过程模型和工程方法的选择 5 2软件工程活动 活动 生产一个最终满足需求且达到工程目标的软件产品所需要的步骤 1 需求 问题分析 需求获取和定义 又称软件需求规约 需求分析 生成软件功能规约 2 设计 概要设计 建立整个软件的体系结构 包括子系统 模块以及相关层次的

14、说明 每一模块的接口定义等 详细设计 产生程序员可用的模块说明 包括每一模块中数据结构说明及加工描述 3 实现 把设计结果转换为可执行的程序代码 4 确认 贯穿整个开发过程 对完成的结果进行确认 保证产品满足用户的要求 5 支持 修改和完善活动 5 3软件工程原则 软件工程的四条基本原则 1 采取适宜的开发模型 控制易变的需求 2 采用合适的设计方法 需要软件模块化 抽象与信息隐藏 局部化 一致性以及适应性等 需要合适的设计方法的支持 3 提供高质量的工程支持 软件工具和环境对软件过程的支持 4 重视开发过程的管理 有效利用可用的资源 生产满足目标的软件产品 提高软件组织的生产能力等 六 软件

15、开发模型 软件生命周期 制定计划 需求分析和定义 软件设计 程序编写 软件测试 运行 维护等六个步骤 软件开发模型 是从软件项目需求定义直至软件经使用后废弃为止 跨越整个生存期的系统开发 运作和维护所实施的全部过程 活动和任务的结构框架 6 1瀑布模型 6 1瀑布模型 1970年 W Royce提出瀑布模型 特征 活动的输入来自上一活动的输出 完成该项活动的内容 活动的输出传给下一活动 对活动的实施工作进行评审 适合 需求明确的任务 优点 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导 从而保证了软件产品及时交付 并达到预期的质量要求 缺点 成品时间长 缺乏灵活性 6 2演化模型

16、 项目开发初始阶段对需求的认识不够清晰 使得开发工作出现再开发在所难免 经验告诉我们 开发 两次 后的软件能较好地满足用户的要求 第一次 试验开发 目的是探索可行性 弄清楚项目的需求 第二次 在第一次的原型基础上进行开发 从而获得较为满意的软件产品 6 2演化模型 需求分析 软件设计 程序编码 软件测试 软件集成 软件评审 需求分析 软件设计 程序编码 软件测试 软件集成 软件评审 反馈 适合 事先不能清晰和完整定义需求的软件开发 第一次 第二次 6 3螺旋模型 对于大型项目而言 事先不能完整清晰地定义需求是常事 而且开发一个原型是远远不能解决问题的 需要开发内容逐步丰富的多个原型 大型项目的规模和复杂性增加 软件开发过程中必然存在着许多风险问题 风险分析是保证项目成功的必要手段 6 3螺旋模型 6 3螺旋模型 螺旋模型沿着螺线旋转 在四个象限上分别表达了四个方面的活动 即 制定计划 确定软件目标 选定实施方案 弄清项目开发的限制条件风险分析 分析所选方案 考虑如何识别和消除风险实施工程 实施软件开发客户评估 评价开发工作 提出修正建议 6 4喷泉模型 软件开发的固有特征 1 迭代多次

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 大杂烩/其它

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号