[讨论]怎么选择软件生命周期模型？

zhaoxichao 2003-12-24 11:55:59

加精

一般软件生命周期模型包括瀑布型、迭代型、增量型、螺旋型等等
那么怎么根据项目的特点选择合适的模型呢？

...全文

2098 39 打赏收藏转发到动态举报

写回复

用AI写文章

39 条回复

切换为时间正序

请发表友善的回复…

发表回复

w102272 2003-12-29

打赏
举报

我认为这些软件生命周期模型都是不矛盾的.
1.如果严格定义一个小粒度的软件功能,是可以做到瀑布模型的,正如所有的开发模式最后都要细化到一个人每天的工作任务表上去.所谓Task.在这个层面上任何开发任务都是单一而明确的.
2.然后,可选择把有关联的事务进行串行实现,或并行实现.串行实现就实现了增量开发模式
3.多个增量开发的模式在总体上,体现为多个具体事务的并行.
4.1,2,3在不同的粒度上完成了一个软件的开发过程.如果在需求管理的约束下,对软件持续
进行可控的改进(附加测试,功能和性能评估),就体现为一种螺旋式的演化开发方式.

所以螺旋演化模式才是最终的软件开发方式.具体体现为某软件开发模式,取决于如下因素:
1.问题的规模和复杂程度
2.组织或个人的能力,以及对现有知识或成果的重用程度
3.预期的目标在商业利益上,或技术上是否需要持续改进

ozzzzzz 2003-12-26

打赏
举报

slimsymphony(开始转向java,还是思念cpp)
项目的大小不是一个固定的标准，对于同一个项目在不同的组织看来规模是不同的，这就是水平的差距。比如你拿一个高可定制的产品去实施一个项目，肯定比别人什么也不拿去实施，成本和规模都要小的多。
增量的解决方法很多，比如设计模式和architecture的设立，还可以通过设计一个灵活的FRAMEWORK来解决这个问题。不同的人会有不同的解决方法，我是一个敏捷者，但是我也不否认可以设计出一个灵活适应变化的FRAMEWORK的可能性，我要考虑的就是多种方法的成本。
而重构要求的不是沟通，而是完备的测试环境和完备的SCM。这个问题以后我可以深入给大家介绍。沟通只是对于重构可能带来各方面后果的一种补偿，比如你重构了别人的代码，别人可能不高兴。这是一个组织管理的问题，而不是重构和设计本身的问题。

我觉得你的很多发言还是停留在书本上的言论，还没有经过你的深入思考。希望通过CSDN这个论坛上的讨论，使你深入的去研究那些书本背后的问题。毕竟解决问题最后还是要靠你自己。所以你积极参加讨论使非常好的，也是我希望看到。但是我更希望你能发表一些更有深度的论点，而这就只能依靠你把自己的实践和理论联系起来深入思考才可以达到。

humanlixin(呆呆李)
其实我前面已经说了，现在多数企业还是在混沌和瀑布之间徘徊的方法。根本不是瀑布的方法，瀑布对他们来说太难达到了。可以说可以实施瀑布的组织必然可以实施迭代，而迭代的风险更小，为什么不迭代呢。
而所谓新方法的引入会带来混乱的说法我不认同，因为我已经说了他们其实本身就是混乱的，新的方法只是让他们的混乱变得有条理起来。

Fusuli 2003-12-26

打赏
举报

humanlixin(呆呆李)
俺不同意你的观点，迭代开发的一大好处就是降低风险，适应市场，你不能以开发团队的状况不理想为理由而不去适应市场，难道市场会来迁就我们？所以说要么改变自己以适应市场变化，要么完蛋

humanlixin 2003-12-26

打赏
举报

ozzzzzz(希望敏捷)
对于你的说法我也不是完全赞同的，由于人员的素质和外在的因素，使得开发中的很多人都非常依赖提供给他开发资源（文档，代码，甚至是测试用例）的人，这样在实施迭代开发时，将出现比传统开发更大的混乱；因为他们习惯了传统的信息交流。任何一种方法，如果其能够提高生产力，那么都伴随着对使用者更高的要求，自动化方式除外。对于一个状况已经不太理想的团队中，怎么还能够希望他们投入更多的心思在学习和适应新的开发方法上，任何改变带来的首先是混乱。

Fusuli 2003-12-26

打赏
举报

ozzzzzz:
关于健壮的架构booch也有解释：简单有效，如经典的三层架构；
我觉得booch说的肯定不是指所有的项目，谁也没这个本事几句话概括所有项目。我有个朋友甚至从网上down了一个软件改了改dll的资源换成自己公司的名字就做成功了项目，前后不到一周（道德不道德先不说，这也是一种作项目的方法）

BirdGu 2003-12-26

打赏
举报

“设计要尽量简单变更才有可能？”
要使得变更容易需要增加模块的内聚度，降低模块间的耦合度，简化模块间的依赖关系，使系统容易扩展，以及使变更局部化。当然使用最简单的能工作的方法也能使以后的变更容易。但是说“设计要尽量简单化，变更才有可能”，这样的结论未免太简单了。
不仅仅重构需要沟通，沟通是贯串在软件开发的整个过程中，充斥于每个环节的。
大项目使得需要沟通的个体增加，他们之间的沟通联系更加复杂，用于沟通的开销更大，沟通环节增加使信息在传播中发生差错的可能性也增加。这些问题都是由项目规模增大而带来的。怎么办，一是把大项目划分为小项目；或是雇佣更好的人，使得整个项目需要的开发人员减少，人数减少，沟通的复杂性以及由此带来的种种问题也就减少了。

BirdGu 2003-12-26

打赏
举报

“设计要尽量简单变更才有可能？”
大没关系，大而化小嘛。
大型系统一定会分子项目、子系统。每个子项目、子系统可以保持在比较小的规模，使得沟通的难度和开销大大下降。

termite 2003-12-26

打赏
举报

很复杂的

slimsymphony 2003-12-26

打赏
举报

“瀑布唯一的一个可能实施的地方就是周期短“
那就是说应用瀑布都应该是非常小型的项目？
小到不能用演化软件过程模型来做？
那么大型项目实际上只有一个选择了，那就是迭代（螺旋更合适些，我也觉得并行开发无论对整体设计还是整合都要求太高了）
迭代就会出现这样的问题：因为是增量性质的，所以设计要尽量简单化，变更才有可能，
简单化的设计依赖于重构，重构要求高度的沟通度，而在大型性项目中，沟通是最大的问题
可能我自己的逻辑有问题，但是我不知道怎么解决我提到的这个困难？

ozzzzzz 2003-12-26

打赏
举报

Fusuli(大刀向鬼子们的头上砍去)
关于Booch的两个观点，我都不能完全认同。首先关于健壮的架构，我不认同的是如何定义什么是健壮的，然后就是健壮的又怎么样。不是所有的组织都能设计一个健壮的架构，更不是所有的组织在最初就设计那么一个架构。难道这些组件作的项目就必然以失败告终吗？那我们还研究软件工程干吗？都研究软件构架学完了。
迭代的开发方式这一点我也不认同，这个原因其实简单，就是因为现在又很多项目周期过于短的事情发生，让你还来不及去迭代（我最短的一个项目只有半天，程序员只修改了原来产品的个别代码，就给客户安装了。结果非常成功。）而我想大多数朋友都见过1周只能的项目，这样的项目我发现是成功比例最大的。所以我更认同，使用成熟产品代替定制软件的观点。
我买人月神话其实就是去看没有银弹和再论没有银弹的。绝对的值得经久推敲的文章。

zhaoxichao(小西)
其实在我看来模型的选择在我看来基本是无选择的，只有迭代和瀑布。而瀑布的选择十分明确就是项目时间太短，无法迭代。
而真正要选择的则是选择迭代的方式（串行、并行）、迭代的计划（时间、目标）。
而关键在于计划的制定。
我没有见过几个有良好迭代经历的组织，见到有良好瀑布经历的组织基本就是没有（只在传说中听到过）。其实大部分组织还是在混沌与瀑布之间徘徊，根本原因就在于他们普遍认为瀑布是一种简单容易掌握的方法。其实他们错了。

zhaoxichao 2003-12-26

打赏
举报

我觉得模型的选择人是很大一个因素，包括开发人员、管理人员和用户
开发人员的水平、团队的组织是一个因素，同时也跟管理者对风险控制、估计、策划以及对变更控制这些能力有关；与用户的关系也很密切，需求的变更以及用户参与项目的程度也有影响。
另一个因素我觉得与软件开发组织的相关项目经验、软件过程定义程度等等也有关系。

Fusuli 2003-12-26

打赏
举报

记得booch他老人家说现在成功软件项目的两个共同特点是：
1：健壮的架构
2：迭代的开发方式

ozzzzzz 2003-12-26

打赏
举报

humanlixin(呆呆李)
问题就在于通过我上面的讨论，你可以看到瀑布方法并不是一个简单易行的方法。其实迭代的做法唯一比瀑布复杂的就是迭代计划的制定，而这个也比早瀑布中设立里程碑简单的多。关键还在于你是不是可以抛开书本以现实的眼光看现实的问题。不客气的说现在的软件工程书籍中有非常多的地方都是极端错误的，关于瀑布的说法就是一个例证。
关于瀑布可以说是我看到的最要求水平和责任心的方法，稍有不慎就会成为灾难。往往实施瀑布的结果是最后走向混沌，人们的信心遭到极大的打击。
为什么我要强烈的推荐迭代呢？原因就在于迭代方法是考虑到人的特性，考虑到人做事的一般模式，考虑到人的心理需求，考虑到人所处的普遍环境。就是因为要以人为本，才要迭代。如果是机器来开软件，我肯定使用瀑布。

humanlixin 2003-12-26

打赏
举报

ozzzzzz(希望敏捷) ---------昨天没有来看帖子，现在回应你的批评。
其实，你的推论就是我的意思，对于水平不太乐观并且不太稳定的团队，也许是用传统的方式他们还可以完成项目，但是强迫他们使用迭代开发，那么项目的失败可能将远远高于使用传统方法；作为领队，不能不考虑这些问题。究其根本，关于开发方式的选择还是要依据人的因素。
谢谢你的指正。oz6。

BirdGu 2003-12-25

打赏
举报

从目前来看，迭代开发还是具有普遍意义的。区别是迭代周期的长短、每个迭代中的工作安排、文档正式化程度、使用的主要的沟通手段等等。
这些方面的选择主要取决于项目开发团队的规模、团队在地理上的集中和分散、项目的关键性程度、在这些方面外部对开发团队的要求、团队成员的经验和水平。
一般来说，地理上集中的小规模开发团队可以采用非正式的沟通手段，对文档正式化的程度也低一些，因此在沟通上的开销比较小，也比较容易采用较短的迭代周期。
项目关键性程度越高，对文档和开发过程的正式化的程度要求也较高。
小团队比大团队更容易才用短迭代周期。
小团队比大团队文档和过程的正式化程度要求要低。
团队成员经验比较少的话，应该尽可能采用较短的迭代周期，以便于较快得到反馈，不断发现开发工作中的问题，以做出改进。
等等、等等。
总之不同的项目需要不同的开发方法和生命周期模型，真正的Unified Process是不存在的。

zhaoxichao 2003-12-25

打赏
举报

我们不要只关注于瀑布模型的好坏
o6z你能不能说一下你认为什么样的情况下采用什么样的模型合适，为什么？（你不会认为都采用迭代模型吧？）
这样对我们来说可能更有指导意义

ozzzzzz 2003-12-25

打赏
举报

humanlixin(呆呆李)
这一次你又错了。强调人在开发中的作用是绝对有必要的，而且怎么强调都是不过分的。但是你这么说“就相对稳定并且水平较高的团队来说，迭代开发的代价最小”，似乎隐含着说水平低和不稳定的团队迭代的代价就高，似乎还隐含着水平低和不稳定的团队使用瀑布会好一些。但愿我的推论是错的，其实迭代最主要的还是解决了风险的问题，水平低不稳定的团队风险更多，更应该实施迭代。这样的代价和高水平的团队比代价是高，但是和自己实施瀑布比代价还是低。而水平也可以通过迭代的方法促进其成长，这是因为迭代给了大家更多的检查自己工作的机会，也给了更多的改进的机会。
然后你又说“就情况一般的团队，各种方法带来的问题差不多，尤其是开发跟MIS类似的过多依赖DB的项目”，这显然也有问题。人虽然是核心因素，但是绝对不是唯一因素，而且人还往往不是一个固定的因素，也就是说人这个因素往往是动态的，受其他因素影响的。工具和方法对人有影响，这是不用争论。
你最后说“对于情况不明了，或者不稳定的来说，所有的模型都没有用，等待你的就是无尽的烦恼，直到团队解散”，这依然是问题。而且任何问题都不可能一下解决，哪是不是说我们就不要去解决了呢？而且即使失败后果也不相同，是全军覆没，还是局部损失；是直到最后才知道不可能，还是早早的知道有缺陷？

为什么我们会讨论这些模型，就是因为它们对于人的行为和人的作用有内在的影响，讨论这些模型实际就是在讨论人在什么模型下工作更加适合。这在我看来就是在讨论人。

humanlixin 2003-12-25