- 1、本文档共40页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
(18常见开发模型调研报告
第二章 软件开发模型 Software Process Model 瀑布模型 快速原型模型 增量模型 螺旋模型 基于构件的开发方法 净室模型 目录 2.0软件过程软件过程模型 2.1瀑布模型 软件生存周期的瀑布模型 各阶段文档 瀑布模型的特点 瀑布模型存在的问题 2.2快速原型模型 模型 原型系统的注意事项 原型模型的分类 原型模型存在的问题 2.3软件演化模型 (1)增量模型 (2)螺旋模型 2.4面向对象开发模型 基于构件的开发方法 2.5 形式化方法模型 净室模型 软件过程软件过程模型 软件过程 软件开发机构(企业)为开发高质量软件所需完成的一系列任务的框架步骤。 包括工程技术和管理活动。 如方法使用的顺序,可交付产品和文档的格式… 软件过程模型 是软件过程的抽象表示,为各项软件开发活动的流程所确定的合理的框架 能直观的表达软件开发的全过程,明确规定要完成的主要活动和任务的框架 也称为软件过程模型,软件工程范型或软件生存周期模型 典型的软件过程模型 2.1瀑布模型(Waterfall Model) 也称典型生存周期模型(classic life cycle)或线性顺序模型(liner sequential model) 软件生存周期(Software Life Cycle) 如同任何事务一样,软件也有一个孕育、诞生。成长、成熟、衰亡的生存过程,称为软件的生存周期。 软件生存周期的瀑布模型 (1)计划时期 问题定义 要解决的问题是什么? ——确定系统总目标 目标和范围说明书 可行性研究 这个项目值得开发么?时间,投资? 对上一阶段所确定的问题有行的通的解决方案么? ——项目继续or终止? 可行性论证报告 (2)开发时期 设计(需求分析+软件设计)+实现(编码+测试)) 需求分析 为了解决这个问题目标系统必须做什么? ——用户对软件系统的全部需求 需求规格说明书 软件的功能需求 性能需求 环境和外部接口 约束条件 软件设计 将需求-软件的表现形式 总体设计: 软件的总体结构 详细设计 详细设计每个模块 确定模块功能所需要的算法和数据结构 目标:应使编码的程序员根据它们可很容易的写 出代码! 编码: 设计-产生计算机源程序 测试: 发现错误! 软件是否有错(功能上的,逻辑上的)? 软件是否达到需求规格说明书预定的要求? 软件是否满足用户需求? 单元测试 集成测试 确认测试 系统测试 (3)运行时期 软件维护 使软件在整个生存期内满足用户需求, 并延长使用寿命 改正性维护:诊断和改正使用过程中发现的错误 适应性维护:修改软件以适应环境的变化 完善性维护:根据用户要求改进或扩充软件使它 更完善 预防性维护:修改软件为将来维护活动预先做准备 各阶段文档 瀑布模型的特点 阶段间具有顺序性和依赖性 前—阶段的工作完成之后,才能开始后一阶段的工作; 前一阶段的输出文档就是后一阶段的输入文档 前一阶段的输出文档正确,后一阶段工作才能获得正确的结果。 推迟实现的观点 区分逻辑设计与物理设计尽可能推迟程序物理实现 质量保证的观点 每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务。 每个阶段结束前都进行评审,若确认,则进行下一阶段,否则返回前项。尽早发现问题改正错误。 瀑布模型存在的问题 这种生存期模型所基于的假设——只要当分析员能够作出准确的需求分析时,才能得到预期的正确结果 顺序性太过理想化,是文档驱动的,在对软件产品试用前,用户只能从静态的文档来了解产品,要用户完全精确和正确的对一个软件产品提出确切的需求,实际上是不可能的。 适合: 软件需求比较明确,需求反复性小,开发技术比较成熟的场合 2.2快速原型模型(Rapid Prototype Model) 思想:样机,样板房 模型 突出“快”,用户和系统分析员从纸上谈兵-真枪实弹, 如一个实际系统,使用原型比瀑布式的方法开销少40%,工作量少45% 原型系统的注意事项 思想来源于“样机”,但是不同于工业样机 原型应充分展示软件的可见部分 仅包括系统主要功能和主要接口,不包括细节 本质是“快速”,尽量缩短开发原型的时间 使用快速原型语言(shell,超文本,4GL) 采用软件重用技术 在算法的时/空开销方面也可以让步 原型模型的分类 抛弃型原型(Throw-away prototyping) 用于试验某些概念,试验完系统将无用处 进化型原型(Exploratory programming)
文档评论(0)