- 1、本文档共7页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
综述
软件过程定义了软件开发中采用的方法。软件工程是集成计算机软件开发的过程、方法和工具的学科。
软件工程的一般视图:定义阶段(做什么)、开发阶段(如何做)、支持阶段(变化)。
线性顺序模型
有时被称为“传统生存周期或瀑布模型”。
活动包括:系统/信息工程和建模、软件需求分析、设计、代码生成、测试、支持
为什么线性模型有时候不能奏效?
建议:虽然线性模型经常被嘲笑为“旧式的”,但是,在需求被很好理解的情况下,它仍然是一种合理的方法。
缺点:
1、实际的项目大部分情况难以按照该模型给出的顺序进行,而且这种模型的迭代是间接的,这很容易由微小的变化而造成大的混乱。
2、经常情况下客户难以表达真正的需求,而这种模型却要求如此,这种模型是不欢迎具有二义性问题存在的。
3、客户要等到开发周期的晚期才能看到程序运行的测试版本,而在这时发现大的错误时,可能引起客户的惊慌,而后果也可能是灾难性的。
4、采用这种线性模型,会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去,有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。
优点:
1、它提供了一个摸板,这个摸板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导。
2、虽然有不少缺陷但比在软件开发中随意的状态要好得多。
瀑布模型将软件开发活动分为需求分析、设计、编码、测试等几个阶段,这几个阶段是对工程活动的划分,瀑布模型没有再涉及其它方面的活动,因此瀑布模型关注于工程活动。
关于选取开发模型
有时开发模型的选取不是很容易判断的,这里面有时不单是需求及开发的问题,对于开发商有开发周期、开发费用的问题,对于用户同样有内部计划、公司发展计划等因素进行影响。
一般来说对于应用开发―――为客户开发软件,客户在开发及测试完毕软件后就要实际开始使用,那么就使用瀑布模型。
当然在需求明确的情况下自然也要使用瀑布模型
对于自主开发及客户需求不明并有较长的设计时间―――可以用演化模型。
而螺旋模型适于适合于大型软件开发,吸收了演化概念,不过有时也用于用户需求不明的情况下。
当然还有其他开发模型,没有在本文讨论。
名词定义:
瀑布模型:规定了各项软件工程活动。包括:制定开发计划、进行需求分析和说明、软件设计、程序编码、测试及维护。
特点:自上而下,相互衔接的固定次序,如瀑布流水、逐级下落。
演化模型:第一次只是试验开发,其目标只在于探索可行性,弄清软件需求;第二次则在此基础上获得较为满意的软件产品,通常把一次得到的试验性产品称原型。
特点:减少由于软件需求不明确而给开发带来的风险。
螺旋模型:将瀑布模型及演化螺旋模型结合起来,并且加入被两种模型都忽略了的风险分析,弥补了两者的不足。
瀑布模型的特点:
①????瀑布模型为软件的开发和维护提供了一种有效有管理模式,对保证软件产品的质量有重要的作用;
②????可根据这一模式制定出开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段,有效地对整个开发过程进行指导;
③????在一定程度上消除非结构化软件、降低软件的复杂度、促进软件开发工程化方面起到显著作用;
④????瀑布模型缺乏灵活性、无法通过开发活动来澄清本来不够确切的需求,这将导致直到软件开发完成时发现所开发的软件并非是用户所需求的。
原型实现模型
原型实现范型定义:
需求收集
快速设计
原型实现模型是迭代的,是帮助客户或开发者理解需求的,总体上讲,并不是交付一个最终产品系统。其流程从听取客户意见开始、随后是建造/修改原型、客户测试运行原型、然后回头往复循环直到客户对原型满意为止。由于这种模型可以让客户快速的感受到实际的系统(虽然这个系统不带有任何质量的保证),所以客户和开发者都比较喜欢这种过程模型(对于那些仅仅用来演示软件功能的公司而言或从来不考虑软件质量和不害怕长期维护的公司而言)。
缺点:
1、没有考虑软件的整体质量和长期的可维护性。
2、大部分情况是不合适的操作算法被采用目的为了演示功能,不合适的开发工具被采用仅仅为了它的方便,还有不合适的操作系统被选择等等。
3、由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计。
优点:
1、如果客户和开发者达成一致协议:原型被建造仅为了定义需求,之后就被抛弃或者部分抛弃,那么这种模型很合适了。
2、迷惑客户抢占市场,这是一个首选的模型。
原型实现仍然是软件工程的一个有效范型。关键是定义开始时的游戏规则,即客户和开发者达成一致:原型被建造仅是为了定义需求,之后就被抛弃了(或至少部分被抛弃),实际的软件在充分考虑了质量和可维护性之后才被开发。
建议:当你的客户有一个合理的续签,但对细节没有任务线索时,先开发
文档评论(0)