软件模型

编码-修补生命周期模型

编码修补模型可以说是最简单的模型,没有设计,没有规格说明,就是和平时写代码一样.新建一个项目就直接开始写,写完了改,加功能,找bug,不断重复直到完成

优点: 适用于不需要任何维护的小程序,开发软件最简单的方式

缺点: 维护工作昂贵,开发过程困难

并不是说这种模型不好,只是说并不适合大型的软件开发,如果大公司开发软件都是上手就来那不是乱成一锅粥了.反过来说我们平时写写代码谁还上来先需求文档设计文档啊,README写得好点不错了

瀑布模型

瀑布模型的特点其实就和瀑布一样,将软件项目划分为不同阶段,从一个阶段流动到下一阶段,每个阶段输出一个或多个评审通过的文档,后续阶段在上一阶段结束前不应该开始,每一个阶段的输出是下一个阶段工作的输入,典型的**计划驱动(文档驱动)**软件过程.

其实就是将需求/设计/编码/维护四个阶段分开,从前到后依次执行,完成的当前部分的文档然后提交给下一阶段,顺流而下故名瀑布

瀑布模型的优点：

各阶段文档齐全,减少沟通成本,维护比较容易
每个阶段评审通过才开始下一阶段,质量有保障

瀑布模型的缺点:

不适应需求变更,如果变更之前所有阶段都必须调整
每个阶段产生大量文档,管理困难,工作量大
用户不能很快看到软件产品,等使用后再提出变更,变更成本非常大

其实优缺点在模型描述的过程中就可以大概感受出来了,因为四个阶段是依次进行的,所以说每一阶段都可以保证文档齐全质量完善,但是对于用户来说只有在验收阶段才能看到产品,如果觉得不满意打算变更需求,那对于瀑布模型来说就是重来.

适合瀑布模型的项目类型：嵌入式系统、关键性系统、大型软件系统这类系统 用户需求非常明确,往往都是政府驱动资金、人员配套充足适合瀑布模型.这种系统往往可以直接根据用户的需求描述准确的实现软件设计,基本不会需要变更,比较适合

快速原型开发生命周期模型

快速原型顾名思义即先用相对少的成本,较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用,以便及早澄清并检验一些主要设计策略,在此基础上再开发实际的软件系统.

这个想法的提出也非常好理解,就是说如果现在来了一个甲方(客户)说你现在给我写一个电商的网站,和京东的哪种类似,要求基本功能都差不多的.但是对于开发者来说这个需求很不明确,要多大的并发,要什么样的页面设计,要什么样的网站结构等等这都并不明确,你现在要甲方马上就给出一个非常明确的需求显然是不合理的,他也说不出来.这时候快速原型就很有用了,先用一个基本的网站模板快速构建一个网站,然后再具体细化,这里怎么做,然后呢还要什么需求等等

相比于瀑布模型,快速原型的一个很大的特点就是去掉了需求模块

实现客户或未来的用户与系统的交互,经过和用户针对原型的讨论和交流,弄清需求以便真正把握用户需要的软件产品是什么样子的。充分了解后,再在原型基础上开发出用户满意的产品。在实际中原型化经常在需求分析定义的过程进行

优点:

克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险
适合预先不能确切定义需求的软件系统的开发

缺点:

所选用的开发技术和工具不一定符合主流的发展；快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。
使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

简单来说就是先搞一个已经差不多的模型,然后你要啥我就改啥

开源生命周期模型

开源软件通常由非雇用的自愿者进行维护,强烈鼓励用户提交缺陷报告包括故障报告和差错报告,少数具有提交故障报告（“修复”）的倾向、时间和必要技能的专业维修人员,他们负责管理这个开源项目,他们有权将修复内容融入程序

优点: 开源模型已经在某些基础结构软件项目得到相当成功

缺点: 开源生命周期模型由于它的实用性受到限制

开源工作通常来说都是由贡献者用爱发电,其他参与者感兴趣才会参与维护和开发的,在一个开源项目里通常没有规格说明和设计,开源项目的生产吸引了一些世界上最好的软件专家,它们的功能可以在没有规格说明或设计的情况下就能被充分实现,然而当开源产品不再可维护时它最终将达到终点

敏捷开发模型

敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

简单地来说,敏捷开发并不追求前期完美的设计、完美编码,而是力求在很短的周期内开发出产品的核心功能,尽早发布出可用的版本。然后在后续的生产周期内,按照新需求不断迭代升级,完善产品

特点:

不怎么强调分析和设计
很早就开始实现（认为：能工作的软件比具体的文档更重要）
响应需求变化
与客户密切协作

关键词：

测试驱动开发（TDD）：制定出任务的测试用例
结对编程（pair programming）
时光盒（timeboxing）：频繁交付软件

时光盒就是说一个开发周期,大概是两三周,在这一段时间内要开发一个新的版本,每隔两三周迭代更新一下
站立会议（stand-up meeting）

站立会议是说几天/几周开发人员在一起聚一下,然后提出问题,仅仅提出问题不解决问题,然后接下来再开解决问题的会议

长处：客户需求模糊时能很好地工作

螺旋模型

从中心出发向外螺旋,每一次都会经过风险分析

螺旋模型是一种演化软件开发过程模型,它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等

螺旋的特点正是体现在了一圈一圈的螺旋曲线上,每一次都会进行风险分析,多轮迭代. 风险驱动

优点:

可以在项目的各个阶段进行变更,具有很高的灵活性
很容易判断有多少测试工作
开发和维护没有区别
客户可以参与每个阶段的开发,有利于客户和开发者的相互交流,提高质量和效率,不会产生需求模糊的现象

缺点:

软件开发周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求
采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失。
过多的迭代次数会增加开发成本,延迟提交时间

迭代和增量模型

这是两个模型,他们的意思有一些区别

迭代的意思是先打一个大框,然后逐渐丰富细节

增量的意思是把一个问题分成几个部分,分步实现

在老师的PPT中这两个合在一起了,表示反复执行瀑布模型,就是一遍一遍的重来

喷泉模型

经典的面向对象(OO软件开发模型)!

喷泉模型主要用于采用对象技术的软件开发项目。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次,相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界,如分析和设计活动之间没有明显的界限,由于对象概念的引入,表达分析、设计、实现等活动只用对象类和关系,从而可以较为容易地实现活动的迭代和无间隙,使其开发自然地包括复用。

优点:

喷泉模型不像瀑布模型那样,需要分析活动结束后才开始设计活动,设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限,开发人员可以同步进行开发。其优点是可以提高软件项目开发效率,节省开发时间,适应于面向对象的软件开发过程。

缺点:

由于喷泉模型在各个开发阶段是重叠的,因此在开发过程中需要大量的开发人员,因此不利于项目的管理。此外这种模型要求严格管理文档,使得审核的难度加大,尤其是面对可能随时加入各种信息、需求与资料的情况