荔园在线
荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀
[回到开始]
[上一篇][下一篇]
发信人: Minatl (天地), 信区: Program
标 题: 流动的软件开发过程
发信站: BBS 荔园晨风站 (Fri Apr 16 17:32:03 1999), 转信
【 以下文字转载自 FreeDevelop 讨论区 xiaobo 所发表 】
传统的软件开发过程大致这样：需求分析 -> 设计 -> 编码 -> 测试 -> 发布；
目前Rational公司又提出一种迭代的开发方法，即需求分析、设计、编码、测试
都贯穿整个开发过程，而开发过程的各个时间段：初始、推敲、实现、交付，又
都遍历从需求到测试的一系列工序，即整个开发过程是二维的。（不知道我的理
解是否正确，请参考前面rivercool整理的笔记。）
同时，Linux的开发又是另一种集市方式的做法：尽量多尽量快的发布，让尽可
能多的人参与软件开发过程。（请参考精华区里Eric Raymond“大教堂与市集”
一文）
下面是我对于软件开发过程的一些想法。基于我上述的认识，同时也部分由周日
的讨论所触发。错误、幼稚、不成熟之处请多多包涵。欢迎大家讨论。
“软件就是过程”，一个软件除非已经死掉，或者开发到了终极（完美？），
不需要再加变动（这几乎是不可能的），否则它总是变化的。
需求的变化是流动的，我们对需求变化的认识也是流动的。（流动就是持续不断
的，就象水流一样。）然而传统的软件开发过程是以很大的阶段来划分的，版本
与版本之间、一个开发周期的各个阶段之间有很大的时间间隔，往往需求积累到
一定程度才对软件进行变动。那么我们为什么不把软件开发过程也变成流动的、
持续的呢？
下面我就基于这样的想法展开讨论。当我讨论软件的开发过程时，我的想法是：
软件开发是以需求为驱动的。
目录：
一、版本的连续推进
二、一个完整的版本应包括那些东西（从开发者应该作的工作的角度来看）
三、需求控制
四、需求的分解
五、单个版本的生产过程
六、人员的协作关系
七、分支与合并，并行协调
八、建立项目站点
说明：我在这儿提出的只是我觉得需要考虑的问题，并试着提出我的一些思考，
并不表明我对此有明确的回答。
一、版本的连续推进
所谓的版本的连续推进，就是Linux的尽量快、尽量多的发布，也就是缩短版本
与版本之间的时间差，缩短到版本的演变近似于流动的过程。具体的说，我理想
中的状态是：一天一个发布，甚至一天几个发布（或者说版本，这里的版本含义
恐怕和我们原来脑袋里所想的版本有些不大一样了）。
在我看来，一个版本是一个软件生产过程中统一一致的完整断面。（这里，统一
一致就是Feature的说明、使用说明、源码、设计、二进制代码、安装程序等的
相互一致，互相对应。）软件过程就是一系列断面不断推进的过程。
形成一个完整、统一的软件断面应该是迅速的，将断面的形成过程控制在尽可能
短的时间内，以保证它的统一一致性，避免混乱。
为什么要这样？
如我前面所言，需求的变化是流动的，如果我们能让软件做到紧随需求的变化，
而不出现混乱，那么这不正是我们所需要的吗？
另一方面，如果需求的变化能迅速而准确无误的反映到版本的变化上来，那么，
这无论对于用户还是开发人员，抑或是主管都是一种很好的激励。
这说明从需要到发布的途径是畅通的。
上述的理想状态能够达到吗？
下面的思考正是围绕这个话题。先看看我所说的统一一致的版本（断面）应该
包括那些东西（开发者应该做的工作）。
二、一个完整的版本应该包括哪些东西（从开发者要做的工作角度）
1、对于不需要源码的用户
a. 完整的Feature说明、以及相对于上一个版本的Feature修改说明。（功
能、BUG）
既然，需求是软件的驱动，那么Feature就是表征一个版本的最本质的东
西。
b. 程序（二进制代码）
c. 使用说明（手册、联机帮助、Demo）
d. 安装程序（安装程序如何引导使用者，包括对Feature的说明，国内好象
不太注意这些）
2、对于开发者
除了上述内容，还应该有：
e. 需求分析文档
f. 设计文档（可能是各种形式的，如Rose的文件、流程图......）
g. 源码
h. 测试报告
作为一个完整的统一一致的版本，上述内容应该是同步的，不能是Feature说明
里说了，而程序没变；或者设计变了，而源码没有改。
我的理想情况是，一个版本的变化对应一条最小化的需求变更。
三、需求控制
从各种途径汇集了需求的变更要求，那么哪些变更应该作出相应的变动，哪些
可以不予采纳，这需要有人进行控制。
下面是一个模型：
需求变更要求
-------------->需求控制人员
|
<---已经采纳------|-------------->开发人员---
| |
<---被拒绝--------| |
| |
<---已更改--------|<-------------------------
提出需求变更请求的人应该可以查询到对这个请求所作的处理。
有些象Rational的RequstPro了。:)
四、需求分解
一个大的复杂的需求应该被分解成最小需求。这样做的目的是为了保证上面说
的版本的流动。（或者说快速反应？）同时也可以让用户、开发者、主管能随
时了解到开发的进度。另外，对开发者自身的激励也是很重要的，能每天看到
自己工作的进展是让人欣慰的事情。
六、人员的协作关系
在上述过程中，人员应该怎样进行精炼的协作？
七、分支与合并，并行协调
如上所述，必然要产生分支。分支的另一个目的是并行开发。在这种新的开发
模式下应该如何进行分支与合并以及并行的协调？
八、建立项目站点
不管是否基于Internet的开发，建立项目站点，在我看来，是一个好注意。
站点有几个作用：
1、针对用户：
用户可以反馈意见、BUG，并查询或下载修改。如“大教堂与市集”所言，
用户也可能成为合作开发者。
而且，这也可以增加用户的“忠诚度”，因为他有更强的参与感。
2、针对开发者：
某种程度上，站点可能成为开发所围绕的核心。从站点，你可以了解到软
件的全面，包括它的现状、历史......
3、对负责人：
可能包括产品、市场人员。了解软件的动态，进行合适的包装......
我的一个站点模型：
---------------------------------------------------------------->
|需求变更(Feature) 设计 源码 测试 程序 手册 ......
|
|
|
|
|
|
|
|
|
V time
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
欢乐，如醉如痴的欢乐，好比一颗太阳照耀着一切现在的与未来的成就，
创造的欢乐，神明的欢乐！唯有创造才是欢乐。唯有创造的生灵才是生灵。
--《约翰.克利斯朵
夫》
※ 修改:·xiaobo 於 Feb 8 21:53:57 修改本文·[FROM: 166.111.69.51]
--
※ 来源:．BBS 荔园晨风站 bbs.szu.edu.cn．[FROM: 192.168.0.158]
[回到开始]
[上一篇][下一篇]
荔园在线首页 友情链接：深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店