瀑布式开发_瀑布式开发流程 - CSDN
精华内容
参与话题
  • 瀑布式开发总结

    千次阅读 2013-05-30 08:49:58
    各类大中小型企业所运用的传统软件构建方法,即是众人皆知的“瀑布”型开发方法。此模型存在很多变体,其典型性是在开发初期制定详细的计划,在计划中最终产品已被仔细研究,设计,并且一切详细资料都记录在案。任务...

            各类大中小型企业所运用的传统软件构建方法,即是众人皆知的“瀑布”型开发方法。此模型存在很多变体,其典型性是在开发初期制定详细的计划,在计划中最终产品已被仔细研究,设计,并且一切详细资料都记录在案。任务已设计制定,并且在工作中使用如根特图表等工具和microsoft project项目管理软件进行项目管理工作。开发团队预计开发项目的时间是以累计其相关每一步骤而得出的。当项目管理者(stakeholder)全面审核开发计划并表示赞同,开发团队即时开始工作。团队成员完成他们所专长的部分工作,即刻转交给其他成员,形成生产流水线的形式。当全部工作都已完成,成品将转交给产品质量控制部门,在这里将会进行在产品到达客户手中之前的全面检测工作。在整个流程中,所有相对于原始计划的分歧都将受到严格的控制,以保证生产的成品与原始设计保持一致。此种模式优缺点明显。有点是非常有逻辑性,在构建之前思考,并全部记录下来,按照计划实施,保持各项食物尽可能的有组织性。弱点是人的参与。比如,要求所有的建议和想法都要在开发周期的最初阶段提出,此时建议和想法将可以被溶入到开发计划中,但是众所周知,好的想法和建议的出现会贯穿整个开发过程,在开发最初的阶段,在开发中期,也可能在产品交付前一天,如果整个开发过程中不容许变化的产生,那么将会遏制创新的产生;另一点就是诸如定型老产品用新技术重新替换之类项目,由于需求分析阶段的盲从性及时间紧迫等等因素的干扰,导致分析出现偏差,最终带来的后果是预估时间不够,项目进展达不到预期的目标,对整个产品开发带来危机。瀑布式开发方式特别注重将事件记录在案,以此作为传递重要信息的首要方法。因此最合理的假定是如果我们可以把想法尽可能地记录在案,这样将会使信息更可靠地传输到团队的每一个成员的头脑中,但是很多情况下没人会大量阅读文档,即便阅读了也会有产生误解的可能性。

    当人参与时,还有一种情况会发生――“实际应用中产生的灵感”――实际开发过程中很多创意是到开发的最后阶段才被提出并且实现的。在项目最初阶段无法准确判断开发的走向。

    人的预知未来的能力是有限的。不可预测的技术问题的突然出现,会强制开发方向的转变。此外,人们对于未来作出长远计划的能力的欠缺也导致了你无法估计出未来数月内每周你的工作安排。

    另外,瀑布式开发由于成员经常改动想法或不能对不能控制的东西负责等等此类容易促使团队成员产生敌对的关系,让工作毫无兴趣可言。事实上,进一步说,瀑布式开发是造成产品开发人员苦恼的根源,并且最终产品将不会体现出他们的创造力,技能和开发创造者的激情。人不是机器人,此种将人认为是机器人的流程将会造成人们工作激情的丧失。

    另外,一个拒绝变革的流程也会造成低劣产品的产生,最原始的需求未必和最终的产品相一致,拒绝开发团队在实践中不断发现可能性而是其尽善尽美的计划也会是一个失败的计划。

    许多使用瀑布型方式的团队不断的体验到了它的缺陷,但是它看起来是如此具有逻辑性的方式,因此第一的自然反映就是对内部工作的谴责:“如果我们尝试更好的使用它,如果我们的计划更加详尽,记录更加仔细,拒绝任何变革,一切将会很顺利地进行。遗憾的是,许多开发团队只得到的相反的效果;结果越差。”

    展开全文
  • 瀑布式开发和迭代式开发

    千次阅读 2019-03-28 11:17:37
    瀑布式开发 我收到一个开发任务,然后按照从需求到设计、从设计到编码、从编码到测试、从测试到发布这个流程去做;每个步骤都力求做到最好;上一个流程的输出作为下一个流程的输入,比如产品出一个需求文档,这个...

    瀑布式开发

    我收到一个开发任务,然后按照从需求到设计、从设计到编码、从编码到测试、从测试到发布这个流程去做;每个步骤都力求做到最好;上一个流程的输出作为下一个流程的输入,比如产品出一个需求文档,这个文档成为设计的依据;流程内是没有用户的反馈的。

    迭代式开发

    我收到一个开发任务,我依然按照瀑布式开发的流程去做事;但是区别是,这个过程中我不需要把每个流程都做到最好,而只是做好大体框架;比如写一个查询的功能,在用户输入关键字搜索之后,我能展示出结果就ok,至于分页、前端优化、搜索的算法以及其它细节,我先不做;然后去给用户使用,收集反馈,再按照反馈进行一次一次的迭代开发;迭代式开发适用于需求不能在最初完整确定或者在开发过程中会变化很多的场景。

    展开全文
  • 瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...

    瀑布开发模式:

    瀑布开发模式有以下显著的特点:

    1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。

    使用里程碑的方式,严格定义了各开发阶段的输入和输出。如果达不到要求的输出,下一阶段的工作就不展开。

    2.重视和强调过程文档,在开发的中后期才会看到软件原型,早起只能通过文档来了解系统的模样。

    在这种情况下,文档的重要性仿佛已经超过了代码的重要性。

    3.瀑布模型把每个开发阶段都定义为黑盒,希望每个阶段的人员只关心自己阶段的工作,不需要关注其他阶段的工作。

    好处是:可以让开发人员能够更专注于本职工作,提高阶段效率。

    坏处是:

    a.由于各阶段的开发人员只能接触到自己工作范围内的东西,所以对客户需求的理解程度高低不等,开发人员更像是定义为流水线上的工人。

    b.对于客户需求变更,编码人员会比设计人员更容易产生很强的抵触情绪。

    c.在每个开发阶段都会有一些信息刻意的不让其他开发阶段的人员知道(本意是为了提到效率,但实际上有时候产生的是互相的理解偏差)。

    4.瀑布模型产生的管理文档(计划书,进度表)等,能让不太了解该项目的人也能看懂项目的进度情况(只有能看懂百分比就行),很适合向领导汇报用。所以管理人员比较喜欢瀑布模型,但是开发人员不喜欢,因为它束缚了开发人员的创造性。

    5.既然叫做瀑布,就意味着不应该走回头路。否则如果出现返工,付出的代价会很大。

    软件生命周期前期造成的Bug的影响比后期的大的多。

    代价比较大的主要原因还是每个开发阶段的步子过大,每一次调整都可能伤筋动骨

    6.更适合需求相对稳定的大型项目。

     

     

    敏捷开发模式:

    核心是快速迭代,拥抱变化。

    因为最终目标是让客户满意,所以能够主动接受需求变更,这就使设计出来的软件有灵活性,可扩展性。

     

    宣言:

    个体和交互 胜过 过程和工具

    可以工作的软件 胜过 面面俱到的文档

    客户合作 胜过 合同谈判

    响应变化 胜过 遵循计划

     

    敏捷开发模式有以下显著的特点:

    1.story细化。

    2.简单设计,避免过度设计。

    3.重复迭代。

    4.减少不必要的文档。

    5.客户最关心的功能最先完成。

    6.要求客户有时间对每次迭代的成果进行确认,提出改进意见。

    7.showcase。

    8.沟通是非常重要的,所有的开发人员对项目活动的理解应该是一致的。加强团队之间和客户之间的沟通。

    9.测试驱动开发(TDD)

    10.需要更强的个人和团队能力。

    11.敏捷的管理是团队的自我管理和项目经理的服务式管理。

    12.敏捷开发不能在一开始就给出项目完整的成本计划。

    13.在有技术问题还没有解决的情况下不适合展开迭代。

    14.敏捷实践:晨会,deadline,负责人制等等。

     

    瀑布+敏捷开发模式:

    核心是减小瀑布模型的粒度,采用敏捷开发的优秀实践方式,提高开发的沟通效率,提供项目的全景视图。

     

     

    敏捷开发,首先把客户最关注的软件原型先做出来,交付或者上线,在实际场景中去修改弥补需求中的不足,快速修改,再次发布版本。再次上线或者交付。通过一些敏捷实践方式,细化story,可以提供更小的迭代。如此循环,直到用户(客户)满意。适用于需求不明确的项目、创新性的项目或者需要抢占市场的项目。

    瀑布式开发,要求明确的需求,大家按照需求一步步做好规划,在项目运作过程中严格产出各种文档,按着流程一步步走下去。这种模式一般适用于需求比较明确、to B端项目

    但总的来说,在现在管理项目过程中,并没有严格的按照完全的敏捷或者完全的瀑布模式,都是各自掺杂了其他的方式。在实际项目过程中,过于强调模式并没有意义,重要的是能不能预防问题的发生,在问题发生之后能不能用最小的成本解决,模式更多起一个参考作用

    1.瀑布模型

      1.1 瀑布模型介绍

      1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。

      1.2 瀑布模型核心思想

      瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

      1.3 瀑布模型有以下优点

      (1)为项目提供了按阶段划分的检查点。
      (2)当前一阶段完成后,您只需要去关注后续阶段。
      (3)可在迭代模型中应用瀑布模型。
      增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。

      1.4 瀑布模型有以下缺点

      (1)在项目各个阶段之间极少有反馈。
      (2)只有在项目生命周期的后期才能看到结果。
      (3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
      (4)瀑布模型的突出缺点是不适应用户需求的变化。
    --------------------------------------------------------------------------------------

    2.迭代模型

      2.1 什么是迭代模型

      在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:需求、分析设计、实施和测试工作流程。实质上,它类似小型的瀑布式项目。RUP认为,所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

      2.2 迭代模型的使用条件

      (1)在项目开发早期需求可能有所变化。
      (2)分析设计人员对应用领域很熟悉。
      (3)高风险项目。
      (4)用户可不同程度地参与整个项目的开发过程。
      (5)使用面向对象的语言或统一建模语言(Unified Modeling Language,UML)。
      (6)使用CASE(Computer Aided Software Engineering,计算机辅助软件工程)工具,如Rose(Rose是非常受欢迎的物件软体开发工具。)。
      (7)具有高素质的项目管理者和软件研发团队。  

      2.3 迭代模型的优点  

      与传统的瀑布模型相比较,迭代过程具有以下优点:
    (1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一个开发有误的迭代的花费。
    (2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险,可以尽早来解决而不至于在开发后期匆匆忙忙。
    (3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在,他们的工作会更有效率。
    (4)由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断细化的。因此,迭代过程这种模式使适应需求的变化会更容易些。
    --------------------------------------------------------------------------------------

    3.敏捷开发模型

      3.1 什么是敏捷开发

      是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法,是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”,更强调程序员团队与业务专家之间的紧密协作、面对面的沟通(认为比书面的文档更有效)、频繁交付新的软件版本。能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用。敏捷建模(Agile Modeling,AM)的价值观包括了XP的四个价值观:沟通、简单、反馈、勇气,此外,还扩展了第五个价值观:谦逊。

      3.2 敏捷开发特点  

      (1)人和交互 重于过程和工具。
      (2)可以工作的软件 重于求全而完备的文档。
      (3)客户协作重于合同谈判。
      (4)随时应对变化重于循规蹈矩。  
      项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为:作为一个整体工作; 按短迭代周期工作; 每次迭代交付一些成果:关注业务优先级; 检查与调整。
      
      最重要的因素恐怕是项目的规模。规模增长,面对面的沟通就愈加困难,
    因此敏捷方法更适用于较小的队伍,40、30、20、10人或者更少。

    4.螺旋模型

      详见 http://baike.baidu.com/view/551040.htm  

    5.快速原型模型

      详见 http://baike.baidu.com/view/1449532.htm  

    6.几种模型间的对比

    传统的瀑布式开发,也就是从需求到设计,从设计到编码,从编码到测试,从测试到提交大概这样的流程,要求每一个开发阶段都要做到最好。
    特别是前期阶段,设计的越完美,提交后的成本损失就越少。

    迭代式开发,不要求每一个阶段的任务做的都是最完美的,而是明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来为目的,以最短的时间,
    最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善。

    螺旋开发,很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

    敏捷开发,相比迭代式开发两者都强调在较短的开发周期提交软件,但是,敏捷开发的周期可能更短,并且更加强调队伍中的高度协作。
      敏捷方法有时候被误认为是无计划性和纪律性的方法,实际上更确切的说法是敏捷方法强调适应性而非预见性。 

    适应性的方法集中在快速适应现实的变化。当项目的需求起了变化,团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

     

     

    展开全文
  • 敏捷开发 以人为核心、迭代、循序渐进的开发方式 简化文档,提取文档重点,主要在于人与人之间的沟通, 对开发产品进行迭代,最终完成开发。 迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小...

    一. 敏捷开发

    以人为核心、迭代、循序渐进的开发方式

    简化文档,提取文档重点,主要在于人与人之间的沟通,

    对开发产品进行迭代,最终完成开发。

    迭代:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

    敏捷开发的一种实现方式就是Scrum方式:

    Scrum开发流程中的三个项目角色

    • 产品负责人(PO):主要负责确定产品的功能和达到要求的标准,指定软件的发布日期和交付的内容,同时有权力接受或拒绝开发团队的工作成果。

    • 流程管理员(SM):主要负责整个Scrum流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。

    • 开发团队(ST):主要负责软件产品在Scrum规定流程下进行开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每成员必须有很强的自我管理能力,同时具有一定的表达能力。

    sprint:是短距离赛跑的意思,这里面指的是一次迭代,而一次迭代的周期是1个月时间(即4个星期),也就是我们要把一次迭代的开发内容以最快的速度完成它,这个过程我们称它为 Sprint。

    1.首先我们需要确认一个 PB ( Product Backlog , 即按优先顺序排列的一个产品需求列表) ,这是由 PO(Product Owner) 负责的

    2.ST(Scrum Team) 会根据 PB 列表,进行工作量的预估和安排

    3.有了 PB 列表,我们需要通过 Sprint Planning Meeting( Sprint 计划会议)来从中挑选出一个 Story 作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog

    4.Sprint Backlog 是由 ST 去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)

    5.在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图)

    6.做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员。

    7.当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)

    8.最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中。、

    二. 瀑布式开发

    严格按照需求文档,明确个人目标的一种开发模式

    • 需求非常明确,
    • 工作量十分可控,
    • 对质量要求比较低,
    • 业务建模也比较简单,
    • 功能构成较少

    这种开发模式如果范围控制和风险控制做的比较好的话,就真的如瀑布一般,‘飞流直下三千尺’,迅速完成客户期望,部署运行,一般都是在外包公司常见

    阶段

    1. 计划
    2. 需求分析
    3. 概要设计
    4. 详细设计
    5. 编码
    6. 单元测试
    7. 测试
    8. 运维

    有个缺点就是瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑,上一个周期的结束需要输出本次活动的工作结果,本次的活动的工作结果将会作为下一个周期的输入。这样,当某一个阶段出现了不可控的问题的时候,就会导致返工,返回到上一个阶段,甚至会延迟下一个阶段。

    三. 螺旋型开发

    尤其注重风险分析阶段,适用于庞大且复杂,高风险的项目,“螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。 

    通常由四个阶段组成

    1. 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
    2. 风险分析: 分析评估所选方案,考虑如何识别和消除风险; 
    3. 实施工程;实施软件开发和验证; 
    4. 客户评估;评价开发工作,提出修正建议,制定下一步计划。

    螺旋模型中,发布的第一个模型甚至可能是没有任何产出的,可能仅仅是纸上谈兵的一个目标,但是随着一次次的交付,每一个版本都会朝着固定的目标迈进,最终得到一个更加完善的版本。很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。

    四. 迭代开发

    也被称作迭代增量式开发迭代进化式开发,是一种与传统的瀑布式开发相反的软件开发过程,它弥补了传统开发方式中的一些弱点,具有更高的成功率和生产率。
    什么是迭代式开发?
    每次只设计和实现这个产品的一部分, 
    逐步逐步完成的方法叫迭代开发, 
    每次设计和实现一个阶段叫做一个迭代. 

    在迭代式开发方法中,整个开发工作被组织为一系列的短小的、
    固定长度(如3周)的小项目,被称为一系列的迭代。
    每一次迭代都包括了需求分析、设计、实现与测试。
    采用这种方法,开发工作可以在需求被完整地确定之前启动,
    并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。
    再通过客户的反馈来细化需求,并开始新一轮的迭代。

    迭代式开发的优点:
      1、降低风险
      2、得到早期用户反馈
      3、持续的测试和集成
      4、使用变更
      5、提高复用性
     

    五. devOps开发模式

    https://blog.csdn.net/petpig0312/article/details/79616962å¨å¼æºæ¶æä¸DevOpsçå®è·µå¨å¼æºæ¶æä¸DevOpsçå®è·µ

     

    展开全文
  • 什么是敏捷开发瀑布开发

    万次阅读 2017-01-13 15:48:44
    一:敏捷式开发(极限编程思想的体现) 敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的...
  • 什么是敏捷开发和瀑布式开发

    千次阅读 2019-06-13 11:15:41
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了各...
  • 敏捷式开发与瀑布式开发的区别

    万次阅读 2018-01-17 07:56:23
    瀑布式 敏捷式 用户知道功能 用户不知道功能 要件–概要–设计–开发–测试–导入 最小系统 任务优先级 来源张永光的博客
  • 瀑布模型的特点 (传统的开发方式) 1、强调文档 前一个阶段的输出就是下一个阶段的输入,文档是个阶段衔接的唯一信息。所以很多开发人员好象是在开发文档,而不是开发软件,因为要到开发的后期才可以看到...
  • 瀑布式开发及与迭代式开发的区别

    万次阅读 2013-11-25 11:09:54
    瀑布式开发及与迭代式开发的区别
  • 瀑布开发模式和敏捷开发模式的区别和思考

    万次阅读 多人点赞 2017-04-12 14:18:54
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格定义了...
  • 瀑布式开发和敏捷开发区别

    万次阅读 2017-09-27 21:42:41
    瀑布开发模式: 瀑布开发模式有以下显著的特点: 1.严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格...
  • 敏捷开发与瀑布式开发的区别

    千次阅读 2019-03-04 11:30:30
    首先,说一下传统开发的方式流程,传统开发也就是本文最开始所说的来自于工程学的软件开发方式,是一种瀑布式的流程,在工程的起始阶段,进行详尽的需求调研,根据需求进行完全的架构设计,之后进入开发过程,在...
  • 瀑布模型、迭代模型和敏捷开发

    千次阅读 2017-02-18 10:27:14
    瀑布模型:  瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写...
  • 浅谈开发模式之瀑布模型

    千次阅读 2018-02-15 10:49:48
    前面分享了N多干货,不知道看客有没有看吐,反正本凯总是写吐了。之前在合计着跳槽那点事,因为是半路出家,工作经验也只有一两年这样... 众所周知,当下圈内的开发模式,可以说有四种(瀑布,敏捷,快速应用,Dev...
  • 瀑布式迭代与敏捷

    千次阅读 2014-09-23 19:22:06
    在采用敏捷开发的实践当中,有一种特别的开发过程,他融合了瀑布模型和迭代的思维,但又与敏捷的思维存在差异,我把这种过程称之为瀑布式迭代。 瀑布式迭代过程总体上采用迭代的方式,即像敏捷一样,以迭代为单位...
  •  1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。  1.2 瀑布模型核心思想  瀑布模型核心思想是按工序将问题化简,将功能的实现与...
  • 瀑布模型开发与敏捷开发的对比

    千次阅读 2016-02-29 11:35:36
    瀑布模型开发与敏捷开发的对比   瀑布模型开发: 严格把软件项目的开发分隔成各个开发阶段:需求分析,要件定义,基本设计,详细设计,编码,单体测试,结合测试,系统测试等。 使用里程碑的方式,严格...
  • 总结一下经常可以见到的系统开发周期模型。  在过去的几年里,可以很奇葩的碰到类似于“创业项目库”这种需求非常明确,工作量十分可控,对质量要求比较低,业务建模比较easy,功能构成比较少的“面子项目”。类似...
  • 软件开发流程(Software development process)即软件设计思路和方法的一般过程,包括设计软件的功能和实现的算法和方法、软件的总体结构设计和模块设计、编程和调试、程序联调和测试以及编写、提交程序。
  • 软件生命周期模型:是从一个特定角度提出的对软件过程的简化描述,是对软件开发实际过程的抽象,它包括构成软件过程的各种活动、软件工件以及参与角色等。 瀑布模型的优点: 有利于大型软件开发过程中人员的...
1 2 3 4 5 ... 20
收藏数 18,009
精华内容 7,203
关键字:

瀑布式开发