• 1. 软件开发主讲人:方齐
  • 2. 目录软件开发 六阶段 计划 需求分析 系统设计 软件实现 测试 运行维护 软件开发 十模型 瀑布模型 边做边改模型 快速原型模型 演化模型 增量模型 螺旋模型 喷泉模型 智能模型 混合模型(元模型) RAD模型(快速应用开发模型)
  • 3. 软件开发 六阶段 回到目录
  • 4. 软件开发六阶段(一)——计划定义要解决的问题 要考虑的因素:技术、经济、社会 撰写《可行性报告》,并制定开发计划 回到目录
  • 5. 软件开发六阶段(二)——需求分析1为什么要做需求分析? 根据Standish Group对23000个项目进行的研究结果表明,28%的项目彻底失败,46%的项目超出经费预算或者超出工期,只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中,有约60%的失败是源于需求问题。 也就是说,有近45%的项目最终因为需求的问题最终导致失败。 回到目录
  • 6. 软件开发六阶段(二)——需求分析2步骤: 现场调查 确定需求 描述需求 复核需求 功能、性能、可靠性、安全、资源 等 编写《需求规格说明书》与客户一起复核回到目录
  • 7. 软件开发六阶段(三)——系统设计1为什么要做系统设计? 系统设计是软件开发阶段中最重要的步骤,它是软件开发质量得以保证的关键。 系统设计是将用户需求准确地转化为实际产品的唯一途径。回到目录
  • 8. 软件开发六阶段(三)——系统设计2方法: 结构化设计方法(SD) 面向数据结构的设计方法(JSD) 面向对象的设计方法(OOD)回到目录
  • 9. 软件开发六阶段(三)——系统设计3步骤: 概要设计(总体设计) 详细设计(过程设计,模块设计) 形成《数据库设计说明书》 编写《测试计划》初稿 设计软件的模块结构,确定总体结构与子系统的关系,绘制《设计结构图》。确定模块内部的算法和数据结构,形成《软件系统详细设计报告》。回到目录
  • 10. 软件开发六阶段(四)——软件实现定义:使用选定的编程语言,将详细设计的结果转换为计算机程序。 意义:软件编码是系统设计的继续,可影响软件的质量和可维护性。 步骤: 程序设计 设计审查 编写代码 代码走查 编译代码 测试代码回到目录补充剩余的详细设计。检查设计结果,发现设计缺陷。确保代码易验证。检查编码结果,发现编码缺陷。修改代码的语法错误。对代码进行单元测试,调试代码修改错误。
  • 11. 软件开发六阶段(五)——测试定义:在规定的条件下对程序进行操作,以发现程序错误,衡量软件质量,并评估其是否能满足设计要求。 测试策略: 功能测试 性能测试 负载测试 压力测试 容量测试 ……回到目录步骤: 制定测试计划 设计测试环境与用例 实施测试 单元测试 集成测试(组装测试) 系统测试 验收测试 总结测试
  • 12. 软件开发六阶段(六)——运行维护定义:软件产品交付给用户后,需要根据用户需求或硬件环境的变化,持续进行适当的修改。 软件维护并不仅仅是“修正错误”,软件维护一般包括以下四类活动: 纠错性维护(校正性维护) 适应性维护 完善性维护(增强) 预防性维护(再工程)回到目录改正在系统开发阶段已发生,而系统测试阶段尚未发现的错误。使用软件适应信息技术变化和管理需求变化而进行的修改。为扩充功能和改善性能而进行的修改。占整个维护工作的50%~60%。为了改进应用软件的可靠性和可维护性,主动增加预防性的新功能。
  • 13. 软件开发 十模型回到目录
  • 14. 软件开发十模型(一)——瀑布模型定义:瀑布模型(Waterfall Model)是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作,形如瀑布流水,最终得到软件产品。 地位: 这是一种经典模型,提供了软件开发的基本框架。 优点: 各阶段划分清晰 强调计划与需求分析 适合需求稳定的产品开发 缺点: 单一流程,不可逆 风险显露得晚,纠正机会少 测试只是其中一个阶段,缺乏全过程测试思想 回到目录计划需求分析系统设计测试运行维护软件实现
  • 15. 软件开发十模型(二)——边做边改模型回到目录定义:在没有需求规格说明和系统设计的条件下开发软件,反复对产品进行编码以得到正确稳定产品的方法。 地位: 或许这是开发员最常用的方式 优点: 适用于需求非常简单、容易明白,软件期望的功能行为容易定义,实现的成功或失败容易检验的工程。 缺点: 缺少计划和设计环节,软件结构容易越修改越糟 忽略了需求环节,风险极大 没有考虑测试和程序维护,也没任何文档,后期维护困难 建立新版本不断修改运行并评估不满意满意交付(发布)N多次…
  • 16. 软件开发十模型(三)——快速原型模型回到目录定义:先迅速建造一个可以运行的软件原型,以便理解和澄清问题。开发人员与用户针对原型反复讨论,直到达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。 优点: 克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险 适合预先不能确切定义需求的软件系统的开发 能快速吸引用户,从而抢占市场先机 缺点: 没有考虑软件整体质量和长期维护 大部分开发都不适合,往往只用于演示功能 若达不到质量要求,就会被抛弃,并重新设计 需求分析原型开发原型评价最终系统设计最终系统实现用户反馈
  • 17. 软件开发十模型(四)——演化模型回到目录需求设计实现集成反馈测试定义:是一种全局的软件(或产品)生命周期模型,属于迭代开发方法。 优点: 适用于需求模糊的项目 可导引出高质量的产品要求 每一轮经验教训均可辅助下一轮开发 销售工作可提前进行,客户可提前了解产品 缺点: 产品设计的完整性因需求的模糊可能会打折扣 如无严格过程管理,容易退化为“边做边改” 过早让客户接触尚未测试稳定的功能,可能对双方产生负面影响(?) 迭代1~N次
  • 18. 软件开发十模型(五)——增量模型回到目录定义:是演化模型的一种变式,整个产品被分解成若干个构件,开发人员逐个构件进行设计、实现、集成和测试,直至产品所有构件交付完成。 优点: 有效缩短开发时间,有效规避并降低开发风险 开发人员与用户可通过原型充分地交流 有利于用户培训、销售和开发的同步 模型的灵活性可使其适应需求的变化 缺点: 软件必须是开放式的体系架构 若缺乏严格的过程管理,容易退化为“边做边改模型” 对产品需求分析要求高,若需求不全面,会影响产品设计的完整性 分析增量时间设计编码测试增量1第1个增量发布分析设计编码测试增量2第2个增量发布分析设计编码测试增量n第n个增量发布……
  • 19. 软件开发十模型(六)——螺旋模型1回到目录定义:该模型是演化模型的另一种变式,兼顾了演化模型的迭代特征,以及瀑布模型的系统化和严格监控特点,加入并强调了对风险分析的重视。 步骤: 制定计划 风险分析 实施工程 客户评估 制定计划风险分析实施工程客户评估确定软件目标,选定实施方案评估所选方案,考虑如何识别和消除风险实施软件开发和验证评价之前工作,提出修正建议,制定下一步计划迭代1~N次
  • 20. 软件开发十模型(六)——螺旋模型2回到目录优点: 设计上灵活,各阶段都可变更 开发过程划分详细,成本计算更简单 客户参与各阶段开发,保证项目可控 强调风险分析,规避开发风险 适合庞大、复杂并且具高风险的项目 缺点: 需要相当丰富的风险评估知识与经验 过长的开发周期,导致产品交付时,技术可能落后 过多的迭代增加开发成本,延迟交付时间
  • 21. 软件开发十模型(七)——喷泉模型回到目录分析定义:是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程。 该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的,就像水喷上去又可以落下来,类似一个喷泉。 各个开发阶段没有特定的次序要求,并且可以交互进行,可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。 优点: 各阶段无明显界限,开发人员可同步开发 提高效率,节省时间 适用于面向对象的软件开发过程 缺点: 因为各阶段工作同步展开,因此需要更多开发人员 除了人多,文档产生的也快,因此需要严格的项目管理 改进的模型: 将需求分析和测试纳入迭代,实现整个开发过程无边界的交互(示意图 略) 设计实现维护演化
  • 22. 软件开发十模型(八)——智能模型回到目录需求分析知识获取和表示定义:这是一种基于知识的软件开发模型。它把瀑布模型和专家系统紧密结合在一起,利用专家系统来帮助软件开发人员的工作。 地位:软件开发不再是专业程序员的专利。 优点: 因为使用了四代语言(4GL),用户界面极端友好,即使没有受过训练的非专业程序员,也能用它编写程序 在专家支持下,能够解决特定领域的复杂问题 以瀑布模型为基本框架,在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点,适用于特定领域软件和专家决策系统的开发 缺点: 4GL目前主要限于事务信息系统的中、小型应用程序的开发,限制了智能模型的应用范围 对特定领域的专家要求高 知识库/专家系统推理机制软件原型系统体系结构设计软件实现
  • 23. 软件开发十模型(九)——混合模型回到目录定义:也叫过程开发模型,或元模型,几种不同模型组合成一种混合模型,它允许一个项目沿着最有效的路径发展。 地位:每个开发单位都有自己特色的混合开发模型。 优点: 可充分发挥各种模型的长处 缺点: 对企业的管理和技术都提出了更高的要求
  • 24. 软件开发十模型(十)——RAD模型回到目录定义:快速应用开发(RAD)模型是“瀑布模型”的高速变种,一个增量型的软件开发过程模型。该模型通过大量使用可复用构件,采用基于构件的建造方法赢得快速开发。 优点: 可以快速创建出功能完善的信息系统 缺点: 对大型项目而言,RAD需要足够的人力资源 开发者和客户都要实现承诺,否则将导致失败 不能合理模块化的系统、高性能需求并且要调整构件接口的系统均不适合用该模型 60~90天业务建模小组#3小组#2小组#1数据建模过程建模应用生成测试及反复业务建模数据建模过程建模应用生成测试及反复业务建模数据建模过程建模应用生成测试及反复
  • 25. 感谢各位!回到目录THE END