软件开发流程与模式

软件开发角色与流程

软件生命周期: 制定计划,需求分析,设计,编码实现,测试,运行维护

软件开发流程与模式

主要模型介绍

1. 边做边改模型(Build-and-Fix Model)
  其实现在许多产品实际都是使用的“边做边改”模型来开发的,特别是很多小公司产品周期压缩的太短。在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。
  在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户和测试等等满意为止。
  这是一种类似作坊的开发方式,边做边改模型的优点毫无疑问就是前期出成效快。
  对编写逻辑不需要太严谨的小程序来说还可以对付得过去,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于:
  1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
  2) 忽略需求环节,给软件开发带来很大的风险;
  3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。

软件开发流程与模式

4. 增量模型(Incremental-Model)
(1). 起源与定义
在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:
(1) 由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
(2) 在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而使软件过程的控制失去整体性。
在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。
例如,使用增量模型开发字处理软件。可以考虑,第一个增量发布基本的文件管理、编辑和文档生成功能,第二个增量发布更加完善的编辑和文档生成功能,第三个增量实现拼写和文法检查功能,第四个增量完成高级的页面布局功能。
(2)优劣与评价
优点:
(1)人员分配灵活,一开始不需要投入大量人力
(2)先推出核心的产品,在后续增加相应的功能
(3)增量能够有计划的管理技术风险
(4)适用于需求经常变更的软件开发过程
缺点:
(1)如果增量包之间存在相交的情况未很好的处理,则必须做全盘的系统分析

软件开发流程与模式

7,敏捷开发模型(Agile-Development-Model)
2001
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中,软件项目的构建被切分成多个子项目,各个子项目的成果都经过测试,具备集成和可运行的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。
敏捷开发小组主要的工作方式:
(1)作为一个整体工作;
(2)按短迭代周期工作;
(3)每次迭代交付一些成果,关注业务优先级,检查与调整。
敏捷开发的4个核心思想:
(1)强调面对面的沟通,人和人的相互交流胜于任何流程和工具
(2)把精力集中在可执行的程序上,可以运行的产品胜于编制综合性文档,强调了原型、模型、demo等的重要性
(3)团队合作和团队激励,合作胜于谈判,敏捷开发能将需求、开发、测试等全部团队成员融合成一个整体,大家都是一条线上的蚂蚱
(4)超强的适应能力,适应变化胜于按部就班,敏捷开发的特点就是快速
敏捷软件开发要注意项目规模,规模增长,团队交流成本就上去了,因此敏捷软件开发暂时适合不是特别大的团队开发,比较适合一个组的团队使用。

敏捷开发模式有许多不同的形式,包括:Scrum,Crystal,Extreme Programming(XP)和Feature-Driven Development(FDD))。它通过迭代开发,关注互动沟通等方法来降低软件开发过程中的风险,同时也可以减少在开发中的资源消耗。好处是通过早期发现和修复缺陷来提高开发的效率。但这种模式比较依赖用户的信息反馈,而且这种模式比较适用于小规模的软件开发公司,习惯于“瀑布法”的程序员,管理层和组织可能难以适应敏捷。

软件开发流程与模式

比对与应用

在实际的使用中, 基本上很少使用单一的方式, 一般都是综合起来使用。根据项目、团队等状况统筹选取适合自己团队和项目的模式。

Model 说明 优点 缺点 适用
1 Build-and-Fix 无规格,无设计,客户需要就修改 前期出成效快 1. 修改困难 2.维护性差 不太严谨的小程序
2 Waterfall 严格遵循预先计划的需求分析、设计、
编码、集成、测试、维护
1. 简单
2.  阶段明确易控制
1. 自由度较低低
2. 变化成本高,风险大
3.不支持用户参与
需求易于完善定义且不易变更的软件系统
3 V model 强调测试过程应如何与分析设计等过程相关联 同Waterfall 相对Waterfall,可以提前发现风险 需求易于完善定义且不易变更的软件系统
4 Prototype 建造一个快速原型,调整修改开发 1. 整合Build-and-Fix和Waterfall优点
2.减少需求不明确风险
1. 系统设计差
2. 效率低
3. 难以维护
1.小型,交互式系统。
或是大型系统的部分.
2.需求复杂、难以确定、动态变化
5 Iterative 整个开发工作被组织为一系列的短小的、
固定长度(如3周)的小项目,每一次迭代都包括了需求分析、设计、实现与测试
1. 降低风险
2.得到用户早期反馈和变更
3. 高复用性
需要高素质的项目管理者
高技术水平的开发团队
需求难以确定、不断变更的软件系统
6 Incremental 软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。 1. 降低风险
2.人员分配灵活
3. 先推出核心产品
1. 容易退化为边做边改
2. 增量包之间的相交难处理
技术风险较大、用户需求较为稳定的软件系统
7 Spiral 瀑布模型和快速原型模型结合起来,螺旋模型沿着螺线进行若干次迭代:制定计划,风险分析,实施工程,客户评估 强调了其他模型所忽视的风险分析 软件开发人员应该擅长寻找可能的风险 1.内部的大规模软件开发
2.需求难以获取和确定、软件开发风险较大的软件系统
8 Agile 以人为核心、迭代、循序渐进。把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态 1. 市场快速反应能力
2. 前期满意度高
1. 需要项目中存在经验较强的人 1. 团队人数不能太多
2. 经常变更,高风险的项目
3. 开发人员可以参与决策
4.项目周期短
9 DevOps 增强了软件开发部门之间的协作,如开发,测试和运营。它着重于改进软件的上市时间,降低新版本的故障率,缩短BUG修复的交付时间,优先考虑最小的中断以及最大的可靠性

DevOps是在整个IT价值流中实施精益原则的结果。IT价值流将开发延伸至生产,将由程序员这个遥远的祖宗所繁衍的所有子孙给联合在一起。

1. 提高客户满意度
2. 提高产品质量
3. 提高员工的生产力和效率




来源:oscar999

声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2018年1月22日
下一篇 2018年1月22日

相关推荐