大家对设计变更（编程及以后阶段发生的变更）有什么理解呀？大家探讨一下吧

[wddll]

大家对设计变更（编程及以后阶段发生的变更）有什么理解呀？大家探讨一下吧

[cuiyue4420]

有可能重写

[bluesage]

第一是在分析、设计阶段尽量避免需求的变更
第二就是重构
最不幸就是重来

[futuredreams]

由于需求变更是所有项目中最为常见也是代价最高的部分，所有CMM2级以上对需求变更做了详细规定。
我们在处理需求变更时，对于必须变更的需求，经过项目核心小组讨论决定后与用户就详细变更要求，所需要付出的时间或者资金代价进行协商，达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改，对于任何变更需要进行从功能测试，集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪，最后项目总结部分需要进行变更统计。

[midthinker]

一直认为软件工程不过是批着工程学外衣的柔弱的羔羊，我认为软件开发的中心从根本上由三个词组成：人，变化，可测性。
无法向其靠拢，则软件工程在本质上永远无法成为真正的工程学科，而“变化”（包括需求变化在内）被我排名第二的原因是软件开发从根本上说就是对现实的抽象，我一直认为现实有多复杂，软件开发就可能会有多复杂，甚至更复杂；现实有多么变化多端，软件开发就有多么变化多端，甚至变化更快更剧烈，所以我认为我们永远无法消灭“变化”，小而精简的迭代开发是目前我唯一感觉可以控制变化的有效手段，这样即使在每次迭代的代码后期，需求发生变化，我们的改动也无需太大（至少没有传统的一站式编程来的改动剧烈，在那种传统模式里，瀑布模型是主流），而如果在多次迭代后发现初期迭代的需求发生了变化，则可以认为是二次改进开发，而不是在一次迭代中的活动，因为每次迭代的成果都是可验收的（所谓的可测性），既然验收就即成事实，通过验收意味着客户的认可，那么客户的改变必须被视为新的迭代开发过程去控制。
不过这样的方法在大工程和大客户中是否有效实在让我害怕，一旦牵涉到烦琐的行政问题，那么软件开发就不在那么单纯了，商业活动是复杂的，我认为交给老板们去探讨合同的问题吧，不是吗？

@.@||~

[Arqui]

变更的时候 就是向客户要钱的时候 毕竟谁也不喜欢失败.

[cuizhen7]

我认为，变化不以人的意志为转移，变化是不可避免的，一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。
楼上说到迭代开发，并不是所有开发团队，所有软件都适合迭代。
一个原因是团队和个人的能力成熟度，就是说有没有能力和资源进行迭代开发，这不是一件容易的事，起码需要一个优秀的分析设计来保证。
二是楼上所担心的行政干涉，这方面我不用多说。
要发生变化的时候付出最小代价，我们现在不是有很多如：模式，架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年？想想.net庞大的类库我估计也不是重新写的吧？

[midthinker]

cuizhen7(如花) ( ) 信誉：100 2006-3-3 9:37:05 得分: 0
我认为，变化不以人的意志为转移，变化是不可避免的，一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。
楼上说到迭代开发，并不是所有开发团队，所有软件都适合迭代。
一个原因是团队和个人的能力成熟度，就是说有没有能力和资源进行迭代开发，这不是一件容易的事，起码需要一个优秀的分析设计来保证。
二是楼上所担心的行政干涉，这方面我不用多说。
要发生变化的时候付出最小代价，我们现在不是有很多如：模式，架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年？想想.net庞大的类库我估计也不是重新写的吧？

--------------------------------------------------------
近期，一个如此清晰的目标渐渐站在我的面前，我终于漫漫看清了一些东西的本质（但愿如此），而这些本质问题所导致的理解误区在阁下的话中被如此正确无误的再次体现。

“我认为，变化不以人的意志为转移，变化是不可避免的，一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。”
这是任何一个被定义为标准话组织，标准化方法论的核心说法，但谁给出过一个合理且现实的解决方案？很高兴他还是被人关注着，只是我们有时确实需要再快一点！

“楼上说到迭代开发，并不是所有开发团队，所有软件都适合迭代。
一个原因是团队和个人的能力成熟度，就是说有没有能力和资源进行迭代开发，这不是一件容易的事，起码需要一个优秀的分析设计来保证。”
正是因为没有任何一个团队或个人的能力成熟度可以达到驱动整个软件的开发过程，我们才更有必要将问题切割，毕竟将问题切割可能是最佳的降低风险与提高软件可测性的简单方法。没有资源进行迭代开发？那就有资源被耗费在无进的抱怨，维护之中？耗费在被大量的基础修改之中？我当然不认为这是一件容易的事，事实上近期我越来越相信软件开发的每一个过程没有一个是容易的，优秀的分析与设计不过是骗人的把戏的一个原因是因为分析与设计的不可测试性！！！我还是非常自豪于自己是一个非常优秀的需求提取高手（自封的），我与客户能够最大限度的有效沟通与交流，我的客户总是对我的反馈非常满意，他们总是说：“是的，你的理解太正确了，甚至比我们阐述的还精确”，可问题并不如想象的如此完美，近期的一个项目中在一个需求点上变化了三次，而每一次，客户总是说：“是的，太棒了，与你交流太值得了，我完全理解了我想要的东西在计算机上的表现”，但直到界面的出现他才能够最终肯定，“是的，那是我要的，我确定我不再修改了”，而为此我们在基础结构上已经更动了3次！！！
是的，我知道我还不够好，应该是非常不够好，不过即使我拥有100%的理解能力，我还要保证自己有100%的表达能力，同时还要客户拥有相同的能力才能做到99%的正确，而这99%再现实中是如此的脆弱，因为客户告诉我：“抱歉，市场变化了，您对我们的理解非常正确，但您必须改变”，我发现我永远无法做到100%的正确，哪怕是50%，如果我无法在一个可测因子点上明确我的需求分析阶段是正确的我就永远无法封闭分析环，同样的情况再次发生在设计中，如果我们承认我们没有关闭分析与需求的环而直接进入了代码，那么我们怎么能够认同自己是完全依照流程来进行的呢？事实上在问题发生时，我们又再一次的和客户坐下确认每一个需求变更点，做设计，实现。。。这不是迭代的过程吗？

“要发生变化的时候付出最小代价，我们现在不是有很多如：模式，架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年？想想.net庞大的类库我估计也不是重新写的吧？
”
我完全赞同以上观点，不过可惜的是模式与架构是建立在经验的基础之上的，这很好，非常符合软件开发的现状。我们得承认我们目前更多的使用的是经验而非标准（当然我们可视之为事实上的标准，至少很多悬乎的技术书籍上总是那么说），标准一旦确立就必须被理论化，理论一旦成熟就会自动化，但很可惜，我们得承认我们很原始，从对工作量的评估、需求的分析、系统的设计、代码的实现，甚至是最终的测试都更多的依据我们的经验，还没有任何一种理论能够说服所有的开发者，那是一个正确的“理论”！！！如果问题无法被提升到理论的高度是悲哀的，那意味着无法被工程化，无法被自动化，也许大多数人认同，但不会写入教科书，不会写入韦氏大词典中，不会让更多的人不费吹灰之力的获得，回到现实之中，软件开发还是炻器时代，交流比报告更重要，测试比假设更重要，代码比模型更重要！

@.@||~

[cuizhen7]

midthinker(呵呵) 我觉得你比我更能看清本质，更能以实际经验为出发点来看待事物。

这是任何一个被定义为标准话组织，标准化方法论的核心说法，但谁给出过一个合理且现实的解决方案？
------------------------------------------------------------
当然没有标准准的解决方案，所谓“付出最小代价”，只是尽我们目前所能而已，

优秀的分析与设计不过是骗人的把戏的一个原因是因为分析与设计的不可测试性！！！
------------------------------------------------------------
几年来我都是在玩弄骗人的把戏吗？当程序员对我说：“现在的这个方法太好了，写起代码来真的又简单，又快速，不用我们再象以前那样费时费力。”这是后，你是否要说我在是愚弄他们，或者是骗取公司的薪水、增加公司成本？是没有绝对优秀的设计，但是相对合理比起拙略的设计的确能减轻程序员负担，使软件更加健壮，给下一次的变更留出余地，给下一次迭代提供保障。

直到界面的出现他才能够最终肯定，“是的，那是我要的，我确定我不再修改了”，而为此我们在基础结构上已经更动了3次！！！
事实上在问题发生时，我们又再一次的和客户坐下确认每一个需求变更点，做设计，实现。。。这不是迭代的过程吗？
------------------------------------------------------------
并不是我不赞成迭代，迭代也是科学的工程方法，任何事物都是因时、因地、因人来看待，并不见得所有项目都允许你迭代N次。

交流比报告更重要，测试比假设更重要，代码比模型更重要！
------------------------------------------------------------
这点我不赞同，他们都是相辅助相成的，无所谓哪个比哪个重要，看你在什么时候，站在什么角度，怎么看待。

[james_hunter]

Rober C.Martin 解释过一些问题。《Agile Software Development-Principles,Patterns,and Practices》里边有。我觉得，无论是哪个时期，尽量设计一个敏捷和灵活的，容易响应变更的系统是根本之道。书上的若干原则和模式都是用于帮助构建这样的系统的工具。但是实际上要能真做到没有多年的经验还是挺难。

[midthinker]

TO: cuizhen7(如花)

很高兴我们关注同一组问题，从另一个角度看，我们的看法是一致的，我们不应该走向任何极端，但我想有时候治乱需用重点，在中国是时候了。

“当然没有标准准的解决方案，所谓‘付出最小代价’，只是尽我们目前所能而已
”
我想我同意您的观点，非常的同意，只是您瞧，我们只是尽自己目前所能而已，而自己所能是一个没有标准衡量的观点，我是挺笨拙的人，所以拿我的标准去衡量那些聪明的程序员显然是不合适的。在我目前一直关注的两大有软件特色的工程文化中变化是其中最值得关注的因子，那确实是因为软件开发的不可预测性和变化多端性，她确实不已人类的意志为转移，但我们对软件为何如此复杂和变化没有百分之百的关注，工程的本质是什么？工程的本质不是产品，如果我们不使用任何工程方法，完成软件产品也是我们的最终目标，这并不因为我们在开发过程中引入了工程化的方法而变得有什么特殊的地方！那么工程的最终目标是什么？
是控制成本和识别风险
但是我们如何控制成本？软件开发如此难以预测，您想想最近一次交付延期是不是在最近的项目中？最近一次需求变更是不是在最近的项目中？最近一次加班是不是在最近的项目中？我们没有努力做到最好吗？为什么问题依然非常巨大？公司德高望众的教授说软件工厂是工程化的最终目标，无论10年20年都是如此，不会转移。是的，完全赞同，但在工厂化前我们必须先使得软件开发简单化。近期在与我的母亲，一位曾经的流水线装配工人的聊天中，我发现流水线作业的工人流出的是汗水，他们将复杂的高度重复化的工作教给了机器，而人们在流水线中更多的负责检验和控制，自动化成为流水线的主流。这使我相信无法降低软件开发的复杂性，就更本不能将软件开发导向工厂化，流水线化，期待用超重量级的管理手段管理自认为是全世界最聪明一族的程序员（程序员们心里多数都那么想，至少我是，呵呵），其难度可想而知。

"几年来我都是在玩弄骗人的把戏吗？当程序员对我说：“现在的这个方法太好了，写起代码来真的又简单，又快速，不用我们再象以前那样费时费力。”这是后，你是否要说我在是愚弄他们，或者是骗取公司的薪水、增加公司成本？是没有绝对优秀的设计，但是相对合理比起拙略的设计的确能减轻程序员负担，使软件更加健壮，给下一次的变更留出余地，给下一次迭代提供保障。"
好样的，事实上我想你误会了我的含义，我并没有说分析与设计完全是骗人的把戏，但糟糕的是，软件历史50年，软件工程历史40年（或更短），我们并没有总结出一套行之有效的分析设计方案，我们更多的依赖与我们的经验，前人的教训和大量运气。模式是好东西吗？是的，我沉迷与此，但告诉我哪个顶尖的软件工程师不会告诉你不要过分使用模式？哪本优秀的软件设计书籍中没有说过不要迷信他们？滥用模式与不懂模式一样可怜，回到现在，我们拥有优秀的设计，那是建立在大量代码验证的基础之上，大量前人的错误经验之上，而且为数并不众多（与其他工程学相比，当然软件工程的年龄也是一打因素）。灵活？健壮？冒昧的请问您最近一次二次开发项目中，您可曾觉得灵活？您最近一次项目维护中，您可曾觉得健壮？需求变化是否让您感觉严刻？我们可以为之复用的代码真的到了数量级别，以至于可以拿出来炫耀了吗？如果EJB的持久化过程很棒，那么JDO和ORM为什么那么流行？为什么软件技术始终缺乏标准？“事实上的标准”出现于许多的技术书籍与软件文章中，可惜“事实上”意味着我们依然依靠经验办事。
好东西弈会变成累赘，今天感觉很棒的设计方案，明天就可能一文不值，这在软件开发中确实存在（与我的设计能力太弱也有关系），人类在没有取得火种时，缓步前进；人类在没有自动化时，流汗流血，于是当很多东西显而易见时，我们将其交给了机器，生产力获得了解放，于是工业时代后人类的生产力以指数状扩大，可是在那之前，我们缓步前进，慢慢的，慢慢的。
软件开发处于石器时代，所以在生产力尚未爆发前，我们需要更多的漫步前进，急躁冒进会让我们输得很惨，最近得一个项目中，我们的客户提出了大量需求，我们认为无法在规定时间内完成所有需求，所以我们期望客户作出妥协，或者延长工期，或者削减需求，我们如实告诉了我们的客户“什么都想要，到头来可能什么都得不到，为什么不让我们稍微慢点，但将最重要的部门做扎实呢？”，客户最终认同了我们的想法，至今我们的组员很少因为工期问题而加班，这是双赢的结局。回过来，由于缺乏标准，缺乏测试，我们必须通过代码才能证明我们设计程序的正确性，有效性，我们尚无法依靠纯粹的设计方案获得成功。既然我们必须等到代码完成我们才能彻底相信自己的设计方案时切实可行的，那么在设计阶段告诉别人我们的设计时合理的，告诉程序员我们的设计不需要修改或需要少量修改难道不是骗人的把戏吗？

“并不是我不赞成迭代，迭代也是科学的工程方法，任何事物都是因时、因地、因人来看待，并不见得所有项目都允许你迭代N次。”
OK，这个我赞同，但人为因素和主观阻力在此起了更打的阻碍作用，其实我们细心观察就会发现，即使我们以为自己少有迭代，我们依然在迭代开发，一个巨大的需求变更时就是一次实实在在的迭代过程，不是吗？维护其实是一种迭代，二次开发也是迭代。迭代贯穿始终，只是我们不认为她是迭代而已，我们主观习惯了一气呵成。近期在于许多开发人员、项目经理和其他一些咨询人员探讨后，我得出的结论是，人类主观上排斥迭代，虽然在10年之前的教科书上就告诉所有开发者瀑布模型是过于理想以致不切实际的开发方法，但事实上大多数软件组织在开发过程中，基本沿用瀑布模型，只是在其上稍加改动而已，即使他们完全明白这是错误的，但这却易于管理。瞧，问题出现了，人类还是想通过大量的管理来解决软件开发的复杂性，但软件开发可能是自经济学之后，又一个以难以预测而闻名的学科，软件开发的每个过程依然充斥着大量的创造过程，她更向是人类意念的产物，而不是工程的产物！她需要大量的理解与交流，需要大量的智慧与体力，需要大量的金钱与时间，我们还非得认为近阶段（注意是近阶段）的软件开发过程是可以通过加强管理来得以控制的吗？您认为迭代科学，我到更愿意把迭代理解为不得已而为知，当我们面对过于未知的世界时，我们需要的是勇气、自信和耐心。

“这点我不赞同，他们都是相辅助相成的，无所谓哪个比哪个重要，看你在什么时候，站在什么角度，怎么看待。”
这点我还是赞同，但是凡是都又个标准，不是吗？否则什么又是共产主义呢？呵呵
我一直认为世界上没有对错，只有合适，就如同阁下在上面提到的“何事物都是因时、因地、因人来看待”，我完全赞同他们相辅相成，但是在特定时期，他们拥有优先级别，我总是努力说服我的客户将问题划分的更细致些，并尤其要求他们划定优先级别，他们一般总是告诉我“是的，这些需求对我都很重要，没有一个不是重要的”，我总是说“好的，那么请您在这些重要的需求中，划分出更重要的需求吧”，事实上我得承认从总体上看，那些东西确实都很重要，但在有限的人力资源，时间资源和经济资源得前提下，凡是还是具有优先级别得，即使那很脆弱。我只能说，就我得理解，软件开发得现阶段，标准尚不统一（什么时候CMMI不在嘲笑ISO，而XP们又能和RUP得同志们一起喝酒聊天时，应该不远了吧，哈）之时，我们也应该在我们得开发中理清优先级别，所以上面时我对优先级别得划分，仅限于个人经验，并不具代表性。

综合以上，我向很高兴我们在大目标中是一致的，但我依然坚持软件开发现阶段经验比标准的重要性更突出是一个现实（但那必然会倒转，只是我认为那可能还需要些时间），我认为现阶段，不成为一个优秀的程序员就更本不可能成为一个优秀的设计师（将来也会改变），在现在这个石器时代即使仅仅使用测试驱动开发和重构都可能给整个软件开发过程带来巨大的生产力提升。I Believe...呵呵

@.@||~

[otoexpert]

看场合说话,呵

[mengxianbao1521]

一般程序编程结束后，需求变更属于客户的需求增加，变更是无法避免的，如果系统结构设计的好，修改时间可能就很短，变更发生以后需要评估变更需要更改范围，针对需要修改的地方估算修改时间，然后的针对合同进行报价，包括修改时间和费用使用都需要有确定，经过同意后，可以进行修改了。这是系统交给客户以后发生的变更。在更改代码时需要重新对软件进行测试和重构。

[yunxiang_yang]

UP