软件项目管理[001].ppt_第1页
软件项目管理[001].ppt_第2页
软件项目管理[001].ppt_第3页
软件项目管理[001].ppt_第4页
软件项目管理[001].ppt_第5页
已阅读5页,还剩36页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

2020 2 8 1 授课教师 罗洪Email luozhonghong QQ 56778838 软件项目管理 2020 2 8 2 1 1软件工程概述 1 3软件工程模型 第一节 软件工程知识回顾 1 2软件工程框架 问题 2020 2 8 3 1 1软件工程概述 要点 美国与我国的软件产业的发展软件危机软件工程定义软件工程的七条基本原理 2020 2 8 4 美国软件产业发展三个阶段 美国软件产业三个不同的发展阶段 1 70年代中期至90年代中期的软件结构化生产阶段 以结构化分析与设计 结构化评审 结构化程序设计以及结构化测试为特征 2 从80年代中期开始 软件生产开始进入以过程为中心的第二阶段 以提出过程成熟度模型CMM 个体软件过程PSP和群组软件过程TSP为标志 从1995年开始 正在逐步进入以软件过程 面向对象和构件重用等三项技术为基础的软件工业化生产时代 2020 2 8 5 美国1999年软件项目的统计 2020 2 8 6 我国软件产业的发展阶段及必由之路 我国软件技术人员在数十年来的研究和开发工作实践中 一直在寻找适合我国特点的发展软件产业的技术途径 积累了一些经验 也有不少教训 为了适应21世纪对信息技术的要求 软件产业必须走软件工业化生产的道路具体地说 一方面需要营造软件工程文化 培养大量既懂信息技术又懂企业管理的高级人才 建立必要的信息产业通用基础设施 另一方面还需要建立以过程工程 系统工程 面向对象技术 软件过程以及软件质量工程等五个支持环境为主要特征的软件产业基础设施 以全面支持和促进软件产业的建立和发展 2020 2 8 7 1 1软件工程概述 要点 美国与我国的软件产业的发展软件危机软件工程定义软件工程的七条基本原理 2020 2 8 8 软件危机 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题 2020 2 8 9 软件危机产生 个体化软件环境早期 程序通常针对又为一个特定硬件和目的而编制 软件的通用性很有限的 多数使用该软件的个人或机构研制 规模小 个体化的软件环境 使得软件开发没有什么系统的方法可以遵循 软件设计是在某个人的头脑中完成的一个隐藏的过程 除了源代码往往没有软件说明书等文档 案例 我国早期小软件公司的核心人员的决定公司的命运 中国龙 软件作坊60年代中期到70年代中期 出现了 软件作坊 专职应别人的需求写软件 2020 2 8 10 软件危机产生 急剧膨胀随着计算机应用的日益普及 软件的数量急剧膨胀 软件需求日趋复杂 用户有了新的需求是必须相应地修改程序 硬件或操作系统更新时 通常需要修改程序以适应新的环境 上述种种维护工作以令人吃惊的比例耗费资源 更严重的是许多程序的个体化特性使得他们维护的难度越来越大 最终成为不可维护的 软件的规模越来越庞大复杂度越来越高交付时间相对短开发成本令人吃惊地高失败的软件开发项目却屡见不鲜 软件危机 开始了 2020 2 8 11 美国IBM公司在1963年至1966年开发的IBM360机的操作系统 这一项目花了5000人一年的工作量 最多时有1000人投入开发工作 写出了近100万行源程序 据统计 这个操作系统每次发行的新版本都是从前一版本中找出1000个程序错误而修正的结果 这个项目的负责人F D Brooks事后总结了他在组织开发过程中的沉痛教训时说 正像一只逃亡的野兽落到泥潭中做垂死的挣扎 越是挣扎 陷得越深 最后无法逃脱灭顶的灾难 程序设计工作正像这样一个泥潭 一批批程序员被迫在泥潭中拼命挣扎 谁也没有料到问题竟会陷入这样的困境 IBM360操作系统的历史教训成为软件开发项目的典型事例为人们所记取 软件危机典型案例 2020 2 8 12 软件危机表现 软件成本日益增长开发进度难以控制软件质量差软件维护困难 2020 2 8 13 软件危机表现 软件成本日益增长 20世纪50年代 软件成本在整个计算机系统成本中所占的比例为10 20 到20世纪60年代中期 软件成本在计算机系统中所占的比例已经增长到50 左右 而且 该数字还在不断的递增 下面是一组来自美国空军计算机系统的数据 1955年 软件费用约占总费用的18 1970年达到60 1975年达到72 1980年达到80 1985年达到85 左右 2020 2 8 14 软件危机表现 开发进度难以控制在软件开发过程中 用户需求变化等各种意想不到的情况层出不穷 令软件开发过程很难保证按预定的计划实现 给项目计划和论证工作带来了很大的困难 盲目增加软件开发人员并不能成比例的提高软件开发能力 相反 随着人员数量的增加 人员的组织 协调 通信 培训和管理等方面的问题将更为严重 2020 2 8 15 软件危机表现 软件质量差由于缺乏工程化思想的指导 程序员几乎总是习惯性的以自己的想法去代替用户对软件的需求 软件设计带有随意性 很多功能只是程序员的一厢情愿而已 这是造成软件令人不满意的重要因素 2020 2 8 16 软件危机表现 软件维护困难由于在软件设计和开发过程中 没有严格遵循软件开发标准 各种随意性很大 没有完整的真实反映系统状况的记录文档 给软件维护造成了巨大的困难 特别是在软件使用过程中 原来的开发人员可能因各种原因已经离开原来的开发组织 使得软件几乎不可维护 有资料表明 工业界为维护软件支付的费用占全部硬件和软件费用的40 75 2020 2 8 17 软件生产存在的常见问题 软件生产存在的常见问题有 1 需求搞不清楚2 开发周期长3 成本高4 质量低 不能满足用户需要在过去应用系统开发中 得到的常见的体会 一直到采统交付 才明白用户的需求是什么 甚至系统运行半年之后 才会发现真正的需求问题 即企业所运行的软件系统伴随社会的不断适应展 软件需求就会不断变更 2020 2 8 18 以上的这些问题能够解决吗 问题讨论 如何克服危机 2020 2 8 19 1 1软件工程概述 要点 美国与我国的软件产业的发展软件危机软件工程定义软件工程的七条基本原理 2020 2 8 20 软件工程 一词是来自于1968年北大西洋公约组织 NATO 在联邦德国召开的一次会议上首次提出来的 它的主要思想是 把软件当成一种产品 并要求采用工程化的原理与方法对软件进行计划 开发和维护 软件工程的目标是实现生产高质量的软件产品 软件工程定义 2020 2 8 21 软件工程的七条基本原理 自从1968年提出 软件工程 这一术语以来 研究软件工程的专家学者们陆续提出了100多条关于软件工程的准则和信条 美国著名的软件工程专家Boehm综合这些专家的意见 并总结了TRW公司多年的软件开发经验 于1983年提出了软件工程的七条基本原理 2020 2 8 22 1 用分阶段的生命周期计划严格管理统计表明 50 以上的失败项目是由于计划不周而造成的 这条原理意味着 应该把软件生命周期分成若干阶段 并相应制定出切实可行的计划 然后严格按照计划对软件的开发和维护进行管理 Boehm认为 在整个软件生命周期中应指定并严格执行6类计划 项目概要计划里程碑计划项目控制计划产品控制计划验证计划运行维护计划 软件工程的七条基本原理 2020 2 8 23 软件工程的七条基本原理 2 坚持进行阶段评审统计结果显示 大部分错误是在编码之前造成的 大约占63 错误发现的越晚 改正它的代价就越大 3 实行严格的产品控制开发人员最痛恨的事情之一就是需求变动 但是实践告诉我们 需求的改动往往是不可避免的 这就要求采用变更控制 又叫基准配置管理 当需求变动时 其它各个阶段的文档或代码随之相应改变 以保证软件的一致性 2020 2 8 24 软件工程的七条基本原理 4 采纳现代程序设计技术采用先进的软件开发方法 采用先进的技术即可以提高软件开发的效率 又可以减少软件维护的成本 5 结果应能清楚地审查应根据软件开发的总目标及完成期限 尽量明确地规定开发小组的责任和产品标准 使所得到的标准能清楚地审查 2020 2 8 25 软件工程的七条基本原理 6 开发小组的人员应少而精开发人员的素质和数量是影响软件质量和开发效率的重要因素 应该少而精 这一条基于两点原因 高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍 开发工作中犯的错误也要少的多 当开发小组为N人时 最大的交流通道数为N N 1 2 可见随着人数N的增大 交流通道数将急剧增大 2020 2 8 26 软件工程的七条基本原理 7 承认不断改进软件工程实践的必要性遵从上述六条基本原理 并不能保证赶上技术不断前进发展的步伐 因此 Boehm提出应把承认不断改进软件工程实践的必要性作为软件工程的第七条原理 根据这条原理 不仅要积极采纳新的软件开发技术 还要注意不断总结经验 收集进度和消耗等历史数据 进行出错类型和问题报告统计 这些历史数据既可以用来评估新的软件技术的效果 也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术 2020 2 8 27 软件工程知识体系 SWEBOK 了解SoftWareEngineeringBodyofKnowledge 2020 2 8 28 2020 2 8 29 1 2软件工程框架 实现生产高质量的软件产品 选取适宜的开发模型采用合适的设计方法提供高质量的工程支持重视开发过程管理 2020 2 8 30 软件工程活动 1 问题定义主要是系统分析员和用户参与明确要解决的问题 形成经双方充分讨论通过的确认文档 问题定义 可行性研究 需求分析 设计和实现 支持 确认 2 可行性研究研究问题定义阶段的问题是否有解决办法 但不具体的解决问题 并进行成本和效益分析 结果是工程是否继续进行的重要依据 2020 2 8 31 软件工程活动 3 需求分析分析为了要解决问题 目标系统必需具备的功能 系统分析员和用户充分交流讨论后形成用户确认的系统逻辑模型 数据流图 数据字典算法等 注意教材 p3第一段关于程序员和用户在需求分析中阶段确认的重要性 问题定义 可行性研究 需求分析 设计和实现 支持 确认 2020 2 8 32 软件工程活动 问题定义 可行性研究 需求分析 设计和实现 支持 确认 4 设计总体设计 从概括的层面探讨如何解决问题 抽象概括的提出目标系统的解决方案 详细设计 把解决方案具体化 设计出详细需求规格说明书 5 实现根据需求规格说明书编写程序解决具体的问题 2020 2 8 33 软件工程活动 问题定义 可行性研究 需求分析 设计和实现 支持 确认 6 确认测试目标系统是否达到预定的要求 单元测试集成测试验收测试 7 支持软件的维护 改正性维护 适应性维护 完善性维护 预防性维护 2020 2 8 34 软件工程原则 选取适宜的开发模型采用合适的设计方法提供高质量工程支持重视开发过程管理 2020 2 8 35 1 3软件工程模型 软件工程的演化过程 对软件工程活动中的各个活动都必需进行管理 软件项目管理贯穿于软件工程的演化过程 2020 2 8 36 1 3软件工程模型 线性模型 瀑布模型 特点 1 阶段间具有顺序性和依赖性2 推迟实现的观点3 质量保证的观点 缺点 1 假设了错误都发生在编码阶段 错误修复只能在测试阶段完成 思考 需求错误会造成怎样的后果 2 假设了系统一次性的被构建 体会 需求总是会变的 2020 2 8 37 1 3软件工程模型 软件工程的螺旋模型 连接的线性模型 2020 2 8 38 1 3软件工程模型 软件工程的渐增式模型 分段的线形模型 每个阶段都有个可运行的系统 首先构建系统的基本轮循模块 写出每个功能的空子函数 保证运行 接着多次多阶段的逐个精华或重写模块 增量开发系统 思考 面对提不出需求的用户 需求分析能否借鉴 先做只有界面的系统 2020 2 8 39 1 3软件工程模型演化模型 由于在项目开发的初始阶段人们对软件的需求认识常常不够清晰 因而使得开发项目难于做到一次开发成功 出现返工再开发在所难免 做两次第一次只是试验开发 其目标只是在于探索可行性 弄清软件需求第二次则在此基础上获得较为满意的软件产品 正式开发 原形的不断迭代的过程 2020 2 8 40 GB8567 88计算机软件产品开发文件编制指南 可行性研究报告 GB8567 88 doc开发进度月报 GB8567 88 doc操作手册 GB8567 88 doc数据库设计说明书 GB8567 88 doc数据要求说明书 GB856T 88 doc文件给制实施规定的实例 GB8567 88 doc概要设计说明书

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论