软件开发生命周期中的设计阶段_系统架构师之——软件开发模型

作为一名不合格程序员的你和我,是不是总是听说软件开发方法/软件开发模型?并且总是搞不清,什么是什么东西?

上一文中,我们分享了软件开发方法:《系统架构师之——软件开发方法》,很多时候你会把软件开发方法和开发模型搞混淆并不是你的错,而是不通的人不通的习惯导致的差异理解,其实可以结合。源于“开发”与“设计”的理解。

软件开发方法更多的是讲究如何进行软件的设计的方法,例如采用结构化分析设计方法/面向对象设计方法/面向服务的设计方法;软件开发模型更多的是讲究整个项目生命周期的开发的全过程/活动/任务/结构架构的模型。

简单说,软件开发(设计)方法是软件开发模型里面的一个子集,软件开发模型贯穿了整个项目的需求-设计-编码-测试-运维阶段。所以,软件开发模型,更多时候称之为软件过程模型。

软件开发方法比如房屋的设计建造方式,软件开发模型比如房屋项目的项目过程管理模型。

软件开发过程模型主要有:

  • -瀑布模型
  • -增量模型
  • -演化模型
  • -喷泉模型
  • -基于架构的开发模型
  • -形式化方法模型

目的:每一种模型都是为了更好的解决具体的需求而保障项目如期交付可靠高质量产品/成果

1d9f0763634def3d81359c9bcaf254df.png

一 软件生命周期

在进入了解学习具体的软件开发模型之前,我们有必要清楚一个软件的生命周期。因为软件开发模型就是根据自身业务需求,从而构建出不同的软件生命周期模型。

万物都有一个生命周期,从孕育-诞生-成长-成熟-衰弱-消亡等等多阶段多形态,形成自身的生命周期。

8122df02aa6c3c88cf0b838965c81e8b.png

软件的生命周期阶段如下:

  • -业务需求提出
  • -可行性分析与项目计划
  • -需求分析
  • -概要设计
  • -详细设计
  • -编码实现
  • -测试调试
  • -系统维护

每一个阶段做什么工作,顾名思义非常直观。不管你是做Web网站,还是Android/IOS移动端,或者是新兴的小程序平台,还是古老的PC应用程序,还是硬件嵌入式,Linux/Windows等什么平台什么系统什么业务,基本都是安装此生命周期进行,虽许阶段名称有所差异,但是本质如此。万物都逃离不了周期的诞生与泯灭,感叹造物主的神奇。


二 瀑布模型 Waterfall Model

根据软件生命周期,所有阶段都是顺序连接进行,如瀑布般一泻千里。此般开发模型模式,就是瀑布模型。生命周期每一个阶段排布如下:

e47597cef1744d7706206a36517aaf27.png

1-优点特点:

  • -根据计划,可有效控制成本预算
  • -以文档为驱动,适合需求很明确的软件项目

2-缺点缺陷:

  • -阶段固化,产生大量文档,工作量大
  • -线性模型,到尾阶段才能看到成果,风险大
  • -早期错误,后期严重
  • -客户需清楚完整表述出业务需求

三 V模型 (增强型瀑布模型)

V-model其实是针对瀑布模型的严重缺陷问题进行改进增强的模型,增加了每一个阶段的验证校验,形状如V字,故称之为V模型。

e9132f11ea9b15ba3a36a6c342989143.png

1-优点特点:

  • -为早期阶段提供了验证确认方法
  • -缩短开发周期,提高效率
  • -适用于传统信息化系统,模块化系统

2-缺点缺陷:

  • -把测试阶段放于编码阶段之后作为系统验证,需求分析阶段的问题难于发现验证
  • -需求分析阶段的问题不能很好测试验证发现
  • -客户需清楚完整表述出业务需求

四 增量模型 Increment Model

基于瀑布模型的缺点,集成瀑布模型的优点进行迭代进行,得到增量模型。也就是多个瀑布模型流水线(迭代)进行,将项目拆分成多个业务模块,基于基础版进行逐个增量开发。

模型结构如下:

1a415f2dea355d35e54a87dc0d5de4b2.png

1-优点特点:

  • -第一个可交付的版本时间成本少,错误发现早,风险降低
  • -增量版本发布后,可减少用户需求变更
  • -运行增量投资化,成本随着增量添加,可控制,量化操作

2-缺点缺陷:

  • -没有对用户变更进行规划控制,会导致增量不稳定
  • -早期系统架构设计没考虑周期稳定完整可扩展伸缩,导致后续增量添加困难
  • -管理版本成本/进度/配置/复杂情况可能超出预算和组织能力

五 演化模型 Evolutionary Model

源化模型指的是软件生命周期根据时间的推移而演化,根据业务/商业/产品的需求变化而变化。本质上是一种迭代演化的过程模型,为了是可以让我们那些苦逼的程序员能够快速应对万恶的产品经理的“突然莫名其妙不可思议”的新需求已及变化,使得开发人员能逐步开发出完整的软件版本。基本符合这种思想的都是演化模型。

1-经典的演化模型种类:

  • -原型模型 Prototype Model
  • -螺旋模型 Spiral Model

2-原型模型 Prototype Model

模型结构图

b4f472669e8a7cea16559f285c2e9a55.png

a-优点特点:

  • -适用于初期需求不明确业务不复杂的项目,需要原型设计进行业务确认
  • -初期能快速/低成本构建原型,迭代更新确认,最终演化成最终版本目标系统

b-缺点缺陷:

  • -大规模系统不适合,业务需求不明确,开发过程中会产生新需求,规模难于权衡
  • -不能支持风险分析

3-螺旋模型 Spiral Model

模型结构图

0b6ef7eccf43b09b1407379c71bffe56.png

a-优点特点:

  • -强调风险分析,具有高风险把控
  • -支持用户需求动态变化,方便关键决策,提高适应能力,降低风险

b-缺点缺陷:

  • -对开发人员的风险意识/管理能力知识有要求
  • -螺旋迭代次数增加会使成本增加,成本时间管理存在风险,延期交付

六 喷泉模型 Water Fountain Model

以用户需求为动力,对象驱动,适合面向对象设计方法的项目。开发活动之间无间隙,无需要明显划分阶段,交叉迭代进行,分析设计编码无边界同步进行。即在同一阶段进行项目全生命周期的工作,同时交叉进行,如一个喷泉。

cefe0ae597b7d2d9d3c2b4a33a0a6dee.png

1-优点特点:

  • -阶段无明显划分,开发可同阶段进行,提高开发效率,节省时间
  • -迭代式完善系统,

2-缺点缺陷:

  • -各个开发阶段重叠,需要大量开发人员,不利于项目管理
  • -对文档/版本管控严格,新增修改文档资料,审核难度加大

七 基于构建的开发模型 Component-based Development Model

基于构建组件的开发模型,Component Based Software Development,一般简称CBSD模型或者CBD模型。国内或者中小企业用得比较少,或者说没什么机会用这种方式。顾名思义是基于现有系统的组件模型进行快速搭建系统,例如常见的IBM的BPM,Siebel等产品都有现有组件,可以快速搭建开发新模块系统。软件开发过程模型的分析和设计阶段要比传统模型花费更多的时间,开发时间反而更少投入。适用于稳定成熟的中大型企业。

模型结构图:类似乐高积木

6b83547dc4fdd74aa7b35280ce24c45f.png

模型主流分类:

3e76654ff6741abe90ab3308895a9f99.png

不深入展开,需要可参考:http://article.sapub.org/10.5923.j.se.20120204.07.html#Sec1

1-优点特点:

  • -利用现有组件构建开发,开发投入小,成本低,风险可控
  • -关注分析与设计阶段,明确接口,对外部隐藏,适合大型系统分布式开发
  • -缩短开发周期,保障软件质量与统一风格

2-缺点缺陷:

  • -需要有现有组件,多样性少,缺乏灵活
  • -客制化功能不一定能完全满足

八 形式方法模型 Formal Methods Model

建立在严格的数学基础分析上,主要任务活动是系统形式化的数学规格说明,采用数学语言语义进行描述功能约束与规则,数学分析推导分析需求。而数学规范描述可以采用VDM或者Z语言实现。

生命周期模型结构图如下:

145fee1b76444932346823a43ded4e31.png

形式化描述后进行转换到可执行程序过程

06465f2a7eab4662415b5c50a47d6c2c.png

形式化描述例如长这样的:

714a40833098548dd33c143dac59efbe.png

1-优点特点:

  • -利用数学语言描述,易于发现需求中的歧义/不完整/不一致的内容,易于模型设计验证
  • -通过数学演算,可以使形式化功能/形式化约束/形式化设计到程序编码转换
  • 可以发现并纠正错误
  • 数学证明仅使用数值概念
  • -典型实现的设计方法就是:净室设计方法(IBM发明的产物),具体可以参考《系统架构师之——软件开发方法》

2-缺点缺陷:

  • -比较复杂,学习成本搞,需要对需求分析进行形式化转换成数学描述,形式化描述后还得优化,再转换,非常耗时
  • -对于大型项目,程序证明非常实用且不切实际
  • IBM发明的产物都比较羞涩难懂(规范,但不亲民)

九 统一过程UP 模型

通过用例(UserCase)和风险驱动,以架构为中心,迭代增量,使用UML方法和工具进行。典型代表为RUP模型/AUP模型(敏捷UP)。

更多知识参考白皮书《企业统一过程:扩展Rational Unified Process》

1c611aa5ad4083635b36dc2a9c2a7c7c.png

https://www.amazon.com/Enterprise-Unified-Process-

过程与阶段:起始阶段-精化阶段-构建阶段-移交阶段

94cbde37e6351031473e016428f44db1.png
152c711b2163150508fc0d466aadd028.png
51bbd49cc83206c226e56fd522884eab.png

https://sce.uhcl.edu/helm/rationalunifiedprocess/m

1-优点特点:

  • 强调正确的文档,用例
  • 这些流程能够解决客户使用“变更请求管理”流程添加或更改其需求时发生的所有风险
  • 集成是整个开发过程中的一个连续过程,因此不需要单独的集成时间表
  • 这些过程很容易获得在线教程和培训
  • 组件被重用,因此开发时间自然减少了

2-缺点缺陷:

  • 未经培训的团队成员对此过程将是不利的,培训将增加成本并不利地增加时间因素
  • 这种方法学的所有阶段并不总是有组织的,有时是复杂的
  • 有时,在过程中不断进行集成可能会引起混乱,尤其是在测试阶段。对于具有多个开发流的大型项目尤其如此
  • 重用组件并非总是可能的,尤其是对于那些使用最新技术的项目

十 敏捷方法 Agile Development

为了更快更早持续地对有价值的软件进行交付(逼程序员痛苦加班/(ㄒoㄒ)/~~),灵活加班敲码,方便用户再开发周期增加改变需求(坑爹!)^n,于是乎有了很多方法来逼你加班赶项目,每一种方法都有一套原则。这些原则实现了敏捷方法所宣称的理念——敏(压)捷(榨)宣(加)言(班)。大名鼎鼎的敏捷宣言,自行百科Wiki,如下图:

2c1c7fa8b57afcf69519ab8ee53a393c.png

所以,敏捷开发模型非常适合创业公司互联网公司,方便快捷。至于为什么,有机会我们详细写一篇文章分析《为什么敏捷开发模型更适合创业公司》,敬请期待。

生命周期模型结构图

e8437214852955cff5d50cb47272e619.png
3d440142935b46e7fdeab67e6221a4b2.png

经典的丧心病狂的压榨方式有:

  • -极限编程XP:24小时极限编程了解下
  • -水晶法 Crystal:小团队全方位无死角闪电式进行
  • -并列争求法 Scrum:30天一个迭代
  • -自适应软件开发 ASD:画好DL线,定好交付时间,疯狂加班赶项目吧
  • -敏捷统一过程 AUP:小型快速迭代,快速交付产品

1-优点特点:

  • 敏捷方法论具有自适应方法,能够响应客户不断变化的需求
  • 客户代表的直接沟通和不断的反馈使系统中没有任何猜测的空间

2-缺点缺陷:

  • 这种方法侧重于工作软件而不是文档,因此可能会导致缺少文档
  • 如果客户对项目的最终结果不太清楚,则软件开发项目可能会偏离轨道
  • 脱发,虚脱

十一 总结

对于一个项目选择什么样的软件开发模型/软件过程模型,需要具体根据项目系统的业务场景考虑,成本管理/时间管理/人员资源等多方面考虑选择出最合适的过程模型。只有初期对这个婴儿的整个生命周期进行规划——选择合适软件开发模型,才能让其稳定健壮成长,控制好成本,控制好风险,如期交付高质量的产品/软件给客户。

这才是一个好程序员,一个好架构师,一个好的项目经历,一个好的开发经理。(⊙﹏⊙)对于头发的事情,喝点枸杞水就好。

期待我们更多技术分享交流,请继续关注我们头条号甫义工作室

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值