社区
研发管理
帖子详情
大家对设计变更(编程及以后阶段发生的变更)有什么理解呀?大家探讨一下吧
wddll
2006-02-23 10:50:14
大家对设计变更(编程及以后阶段发生的变更)有什么理解呀?大家探讨一下吧
...全文
481
13
打赏
收藏
大家对设计变更(编程及以后阶段发生的变更)有什么理解呀?大家探讨一下吧
大家对设计变更(编程及以后阶段发生的变更)有什么理解呀?大家探讨一下吧
复制链接
扫一扫
分享
转发到动态
举报
AI
作业
写回复
配置赞助广告
用AI写文章
13 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
yunxiang_yang
2006-03-30
打赏
举报
回复
UP
mengxianbao1521
2006-03-25
打赏
举报
回复
一般程序编程结束后,需求变更属于客户的需求增加,变更是无法避免的,如果系统结构设计的好,修改时间可能就很短,变更发生以后需要评估变更需要更改范围,针对需要修改的地方估算修改时间,然后的针对合同进行报价,包括修改时间和费用使用都需要有确定,经过同意后,可以进行修改了。这是系统交给客户以后发生的变更。在更改代码时需要重新对软件进行测试和重构。
otoexpert
2006-03-22
打赏
举报
回复
看场合说话,呵
midthinker
2006-03-21
打赏
举报
回复
TO: cuizhen7(如花)
很高兴我们关注同一组问题,从另一个角度看,我们的看法是一致的,我们不应该走向任何极端,但我想有时候治乱需用重点,在中国是时候了。
“当然没有标准准的解决方案,所谓‘付出最小代价’,只是尽我们目前所能而已
”
我想我同意您的观点,非常的同意,只是您瞧,我们只是尽自己目前所能而已,而自己所能是一个没有标准衡量的观点,我是挺笨拙的人,所以拿我的标准去衡量那些聪明的程序员显然是不合适的。在我目前一直关注的两大有软件特色的工程文化中变化是其中最值得关注的因子,那确实是因为软件开发的不可预测性和变化多端性,她确实不已人类的意志为转移,但我们对软件为何如此复杂和变化没有百分之百的关注,工程的本质是什么?工程的本质不是产品,如果我们不使用任何工程方法,完成软件产品也是我们的最终目标,这并不因为我们在开发过程中引入了工程化的方法而变得有什么特殊的地方!那么工程的最终目标是什么?
是控制成本和识别风险
但是我们如何控制成本?软件开发如此难以预测,您想想最近一次交付延期是不是在最近的项目中?最近一次需求变更是不是在最近的项目中?最近一次加班是不是在最近的项目中?我们没有努力做到最好吗?为什么问题依然非常巨大?公司德高望众的教授说软件工厂是工程化的最终目标,无论10年20年都是如此,不会转移。是的,完全赞同,但在工厂化前我们必须先使得软件开发简单化。近期在与我的母亲,一位曾经的流水线装配工人的聊天中,我发现流水线作业的工人流出的是汗水,他们将复杂的高度重复化的工作教给了机器,而人们在流水线中更多的负责检验和控制,自动化成为流水线的主流。这使我相信无法降低软件开发的复杂性,就更本不能将软件开发导向工厂化,流水线化,期待用超重量级的管理手段管理自认为是全世界最聪明一族的程序员(程序员们心里多数都那么想,至少我是,呵呵),其难度可想而知。
"几年来我都是在玩弄骗人的把戏吗?当程序员对我说:“现在的这个方法太好了,写起代码来真的又简单,又快速,不用我们再象以前那样费时费力。”这是后,你是否要说我在是愚弄他们,或者是骗取公司的薪水、增加公司成本?是没有绝对优秀的设计,但是相对合理比起拙略的设计的确能减轻程序员负担,使软件更加健壮,给下一次的变更留出余地,给下一次迭代提供保障。"
好样的,事实上我想你误会了我的含义,我并没有说分析与设计完全是骗人的把戏,但糟糕的是,软件历史50年,软件工程历史40年(或更短),我们并没有总结出一套行之有效的分析设计方案,我们更多的依赖与我们的经验,前人的教训和大量运气。模式是好东西吗?是的,我沉迷与此,但告诉我哪个顶尖的软件工程师不会告诉你不要过分使用模式?哪本优秀的软件设计书籍中没有说过不要迷信他们?滥用模式与不懂模式一样可怜,回到现在,我们拥有优秀的设计,那是建立在大量代码验证的基础之上,大量前人的错误经验之上,而且为数并不众多(与其他工程学相比,当然软件工程的年龄也是一打因素)。灵活?健壮?冒昧的请问您最近一次二次开发项目中,您可曾觉得灵活?您最近一次项目维护中,您可曾觉得健壮?需求变化是否让您感觉严刻?我们可以为之复用的代码真的到了数量级别,以至于可以拿出来炫耀了吗?如果EJB的持久化过程很棒,那么JDO和ORM为什么那么流行?为什么软件技术始终缺乏标准?“事实上的标准”出现于许多的技术书籍与软件文章中,可惜“事实上”意味着我们依然依靠经验办事。
好东西弈会变成累赘,今天感觉很棒的设计方案,明天就可能一文不值,这在软件开发中确实存在(与我的设计能力太弱也有关系),人类在没有取得火种时,缓步前进;人类在没有自动化时,流汗流血,于是当很多东西显而易见时,我们将其交给了机器,生产力获得了解放,于是工业时代后人类的生产力以指数状扩大,可是在那之前,我们缓步前进,慢慢的,慢慢的。
软件开发处于石器时代,所以在生产力尚未爆发前,我们需要更多的漫步前进,急躁冒进会让我们输得很惨,最近得一个项目中,我们的客户提出了大量需求,我们认为无法在规定时间内完成所有需求,所以我们期望客户作出妥协,或者延长工期,或者削减需求,我们如实告诉了我们的客户“什么都想要,到头来可能什么都得不到,为什么不让我们稍微慢点,但将最重要的部门做扎实呢?”,客户最终认同了我们的想法,至今我们的组员很少因为工期问题而加班,这是双赢的结局。回过来,由于缺乏标准,缺乏测试,我们必须通过代码才能证明我们设计程序的正确性,有效性,我们尚无法依靠纯粹的设计方案获得成功。既然我们必须等到代码完成我们才能彻底相信自己的设计方案时切实可行的,那么在设计阶段告诉别人我们的设计时合理的,告诉程序员我们的设计不需要修改或需要少量修改难道不是骗人的把戏吗?
“并不是我不赞成迭代,迭代也是科学的工程方法,任何事物都是因时、因地、因人来看待,并不见得所有项目都允许你迭代N次。”
OK,这个我赞同,但人为因素和主观阻力在此起了更打的阻碍作用,其实我们细心观察就会发现,即使我们以为自己少有迭代,我们依然在迭代开发,一个巨大的需求变更时就是一次实实在在的迭代过程,不是吗?维护其实是一种迭代,二次开发也是迭代。迭代贯穿始终,只是我们不认为她是迭代而已,我们主观习惯了一气呵成。近期在于许多开发人员、项目经理和其他一些咨询人员探讨后,我得出的结论是,人类主观上排斥迭代,虽然在10年之前的教科书上就告诉所有开发者瀑布模型是过于理想以致不切实际的开发方法,但事实上大多数软件组织在开发过程中,基本沿用瀑布模型,只是在其上稍加改动而已,即使他们完全明白这是错误的,但这却易于管理。瞧,问题出现了,人类还是想通过大量的管理来解决软件开发的复杂性,但软件开发可能是自经济学之后,又一个以难以预测而闻名的学科,软件开发的每个过程依然充斥着大量的创造过程,她更向是人类意念的产物,而不是工程的产物!她需要大量的理解与交流,需要大量的智慧与体力,需要大量的金钱与时间,我们还非得认为近阶段(注意是近阶段)的软件开发过程是可以通过加强管理来得以控制的吗?您认为迭代科学,我到更愿意把迭代理解为不得已而为知,当我们面对过于未知的世界时,我们需要的是勇气、自信和耐心。
“这点我不赞同,他们都是相辅助相成的,无所谓哪个比哪个重要,看你在什么时候,站在什么角度,怎么看待。”
这点我还是赞同,但是凡是都又个标准,不是吗?否则什么又是共产主义呢?呵呵
我一直认为世界上没有对错,只有合适,就如同阁下在上面提到的“何事物都是因时、因地、因人来看待”,我完全赞同他们相辅相成,但是在特定时期,他们拥有优先级别,我总是努力说服我的客户将问题划分的更细致些,并尤其要求他们划定优先级别,他们一般总是告诉我“是的,这些需求对我都很重要,没有一个不是重要的”,我总是说“好的,那么请您在这些重要的需求中,划分出更重要的需求吧”,事实上我得承认从总体上看,那些东西确实都很重要,但在有限的人力资源,时间资源和经济资源得前提下,凡是还是具有优先级别得,即使那很脆弱。我只能说,就我得理解,软件开发得现阶段,标准尚不统一(什么时候CMMI不在嘲笑ISO,而XP们又能和RUP得同志们一起喝酒聊天时,应该不远了吧,哈)之时,我们也应该在我们得开发中理清优先级别,所以上面时我对优先级别得划分,仅限于个人经验,并不具代表性。
综合以上,我向很高兴我们在大目标中是一致的,但我依然坚持软件开发现阶段经验比标准的重要性更突出是一个现实(但那必然会倒转,只是我认为那可能还需要些时间),我认为现阶段,不成为一个优秀的程序员就更本不可能成为一个优秀的设计师(将来也会改变),在现在这个石器时代即使仅仅使用测试驱动开发和重构都可能给整个软件开发过程带来巨大的生产力提升。I Believe...呵呵
@.@||~
james_hunter
2006-03-20
打赏
举报
回复
Rober C.Martin 解释过一些问题。《Agile Software Development-Principles,Patterns,and Practices》里边有。我觉得,无论是哪个时期,尽量设计一个敏捷和灵活的,容易响应变更的系统是根本之道。书上的若干原则和模式都是用于帮助构建这样的系统的工具。但是实际上要能真做到没有多年的经验还是挺难。
cuizhen7
2006-03-04
打赏
举报
回复
midthinker(呵呵) 我觉得你比我更能看清本质,更能以实际经验为出发点来看待事物。
这是任何一个被定义为标准话组织,标准化方法论的核心说法,但谁给出过一个合理且现实的解决方案?
------------------------------------------------------------
当然没有标准准的解决方案,所谓“付出最小代价”,只是尽我们目前所能而已,
优秀的分析与设计不过是骗人的把戏的一个原因是因为分析与设计的不可测试性!!!
------------------------------------------------------------
几年来我都是在玩弄骗人的把戏吗?当程序员对我说:“现在的这个方法太好了,写起代码来真的又简单,又快速,不用我们再象以前那样费时费力。”这是后,你是否要说我在是愚弄他们,或者是骗取公司的薪水、增加公司成本?是没有绝对优秀的设计,但是相对合理比起拙略的设计的确能减轻程序员负担,使软件更加健壮,给下一次的变更留出余地,给下一次迭代提供保障。
直到界面的出现他才能够最终肯定,“是的,那是我要的,我确定我不再修改了”,而为此我们在基础结构上已经更动了3次!!!
事实上在问题发生时,我们又再一次的和客户坐下确认每一个需求变更点,做设计,实现。。。这不是迭代的过程吗?
------------------------------------------------------------
并不是我不赞成迭代,迭代也是科学的工程方法,任何事物都是因时、因地、因人来看待,并不见得所有项目都允许你迭代N次。
交流比报告更重要,测试比假设更重要,代码比模型更重要!
------------------------------------------------------------
这点我不赞同,他们都是相辅助相成的,无所谓哪个比哪个重要,看你在什么时候,站在什么角度,怎么看待。
midthinker
2006-03-03
打赏
举报
回复
cuizhen7(如花) ( ) 信誉:100 2006-3-3 9:37:05 得分: 0
我认为,变化不以人的意志为转移,变化是不可避免的,一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。
楼上说到迭代开发,并不是所有开发团队,所有软件都适合迭代。
一个原因是团队和个人的能力成熟度,就是说有没有能力和资源进行迭代开发,这不是一件容易的事,起码需要一个优秀的分析设计来保证。
二是楼上所担心的行政干涉,这方面我不用多说。
要发生变化的时候付出最小代价,我们现在不是有很多如:模式,架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年?想想.net庞大的类库我估计也不是重新写的吧?
--------------------------------------------------------
近期,一个如此清晰的目标渐渐站在我的面前,我终于漫漫看清了一些东西的本质(但愿如此),而这些本质问题所导致的理解误区在阁下的话中被如此正确无误的再次体现。
“我认为,变化不以人的意志为转移,变化是不可避免的,一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。”
这是任何一个被定义为标准话组织,标准化方法论的核心说法,但谁给出过一个合理且现实的解决方案?很高兴他还是被人关注着,只是我们有时确实需要再快一点!
“楼上说到迭代开发,并不是所有开发团队,所有软件都适合迭代。
一个原因是团队和个人的能力成熟度,就是说有没有能力和资源进行迭代开发,这不是一件容易的事,起码需要一个优秀的分析设计来保证。”
正是因为没有任何一个团队或个人的能力成熟度可以达到驱动整个软件的开发过程,我们才更有必要将问题切割,毕竟将问题切割可能是最佳的降低风险与提高软件可测性的简单方法。没有资源进行迭代开发?那就有资源被耗费在无进的抱怨,维护之中?耗费在被大量的基础修改之中?我当然不认为这是一件容易的事,事实上近期我越来越相信软件开发的每一个过程没有一个是容易的,优秀的分析与设计不过是骗人的把戏的一个原因是因为分析与设计的不可测试性!!!我还是非常自豪于自己是一个非常优秀的需求提取高手(自封的),我与客户能够最大限度的有效沟通与交流,我的客户总是对我的反馈非常满意,他们总是说:“是的,你的理解太正确了,甚至比我们阐述的还精确”,可问题并不如想象的如此完美,近期的一个项目中在一个需求点上变化了三次,而每一次,客户总是说:“是的,太棒了,与你交流太值得了,我完全理解了我想要的东西在计算机上的表现”,但直到界面的出现他才能够最终肯定,“是的,那是我要的,我确定我不再修改了”,而为此我们在基础结构上已经更动了3次!!!
是的,我知道我还不够好,应该是非常不够好,不过即使我拥有100%的理解能力,我还要保证自己有100%的表达能力,同时还要客户拥有相同的能力才能做到99%的正确,而这99%再现实中是如此的脆弱,因为客户告诉我:“抱歉,市场变化了,您对我们的理解非常正确,但您必须改变”,我发现我永远无法做到100%的正确,哪怕是50%,如果我无法在一个可测因子点上明确我的需求分析阶段是正确的我就永远无法封闭分析环,同样的情况再次发生在设计中,如果我们承认我们没有关闭分析与需求的环而直接进入了代码,那么我们怎么能够认同自己是完全依照流程来进行的呢?事实上在问题发生时,我们又再一次的和客户坐下确认每一个需求变更点,做设计,实现。。。这不是迭代的过程吗?
“要发生变化的时候付出最小代价,我们现在不是有很多如:模式,架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年?想想.net庞大的类库我估计也不是重新写的吧?
”
我完全赞同以上观点,不过可惜的是模式与架构是建立在经验的基础之上的,这很好,非常符合软件开发的现状。我们得承认我们目前更多的使用的是经验而非标准(当然我们可视之为事实上的标准,至少很多悬乎的技术书籍上总是那么说),标准一旦确立就必须被理论化,理论一旦成熟就会自动化,但很可惜,我们得承认我们很原始,从对工作量的评估、需求的分析、系统的设计、代码的实现,甚至是最终的测试都更多的依据我们的经验,还没有任何一种理论能够说服所有的开发者,那是一个正确的“理论”!!!如果问题无法被提升到理论的高度是悲哀的,那意味着无法被工程化,无法被自动化,也许大多数人认同,但不会写入教科书,不会写入韦氏大词典中,不会让更多的人不费吹灰之力的获得,回到现实之中,软件开发还是炻器时代,交流比报告更重要,测试比假设更重要,代码比模型更重要!
@.@||~
cuizhen7
2006-03-03
打赏
举报
回复
我认为,变化不以人的意志为转移,变化是不可避免的,一定会发生的。我们要做的就是“保证软件在整个生命周期里发生变化的时候付出最小代价”。
楼上说到迭代开发,并不是所有开发团队,所有软件都适合迭代。
一个原因是团队和个人的能力成熟度,就是说有没有能力和资源进行迭代开发,这不是一件容易的事,起码需要一个优秀的分析设计来保证。
二是楼上所担心的行政干涉,这方面我不用多说。
要发生变化的时候付出最小代价,我们现在不是有很多如:模式,架构之类的思想和方法来指导么。为什么MFC、VCL用了这么多年?想想.net庞大的类库我估计也不是重新写的吧?
Arqui
2006-03-03
打赏
举报
回复
变更的时候 就是向客户要钱的时候 毕竟谁也不喜欢失败.
midthinker
2006-02-25
打赏
举报
回复
一直认为软件工程不过是批着工程学外衣的柔弱的羔羊,我认为软件开发的中心从根本上由三个词组成:人,变化,可测性。
无法向其靠拢,则软件工程在本质上永远无法成为真正的工程学科,而“变化”(包括需求变化在内)被我排名第二的原因是软件开发从根本上说就是对现实的抽象,我一直认为现实有多复杂,软件开发就可能会有多复杂,甚至更复杂;现实有多么变化多端,软件开发就有多么变化多端,甚至变化更快更剧烈,所以我认为我们永远无法消灭“变化”,小而精简的迭代开发是目前我唯一感觉可以控制变化的有效手段,这样即使在每次迭代的代码后期,需求发生变化,我们的改动也无需太大(至少没有传统的一站式编程来的改动剧烈,在那种传统模式里,瀑布模型是主流),而如果在多次迭代后发现初期迭代的需求发生了变化,则可以认为是二次改进开发,而不是在一次迭代中的活动,因为每次迭代的成果都是可验收的(所谓的可测性),既然验收就即成事实,通过验收意味着客户的认可,那么客户的改变必须被视为新的迭代开发过程去控制。
不过这样的方法在大工程和大客户中是否有效实在让我害怕,一旦牵涉到烦琐的行政问题,那么软件开发就不在那么单纯了,商业活动是复杂的,我认为交给老板们去探讨合同的问题吧,不是吗?
@.@||~
futuredreams
2006-02-24
打赏
举报
回复
由于需求变更是所有项目中最为常见也是代价最高的部分,所有CMM2级以上对需求变更做了详细规定。
我们在处理需求变更时,对于必须变更的需求,经过项目核心小组讨论决定后与用户就详细变更要求,所需要付出的时间或者资金代价进行协商,达成一致后在详细规格说明书中由设计部门进行整体设计并考察其可能影响的模块变更。开发部门根据设计做相应的更改,对于任何变更需要进行从功能测试,集成测试到系统测试的全面测试。
对于每一次需求变更在项目中需要有详细记录跟跟踪,最后项目总结部分需要进行变更统计。
bluesage
2006-02-24
打赏
举报
回复
第一是在分析、设计阶段尽量避免需求的变更
第二就是重构
最不幸就是重来
cuiyue4420
2006-02-23
打赏
举报
回复
有可能重写
win10/win11共享打印机提示错误0x00000057,0x00000709,0x0000011b或者连接失败内存不足等故...
在Windows 10或Windows 11操作系统中,用户经常会遇到共享打印机时出现的一系列错误代码,这些错误代码可能会阻碍打印机共享功能的正常使用。常见的错误代码包括0x00000057、0x00000709和0x0000011b,这些代码通常指出了不同的问题,比如权限不足、服务未运行或配置错误等。除此之外,还有一些故障提示如“连接失败”或“内存不足”,这些都可能影响到打印机共享的稳定性。 要解决这些故障,首先要确保打印机已经正确地连接到网络,并且在需要共享的电脑上进行了设置。确保打印机驱动程序是最新的,并且在共享设置中没有错误配置。对于权限问题,需要检查网络上的用户账户是否具有足够的权限来访问共享打印机。同时,也要确保打印机服务正在运行,特别是“Print Spooler”服务,因为这是打印机共享服务的核心组件。 在某些情况下,问题可能与操作系统的更新有关,如升级到最新版的Windows 10或Windows 11后可能出现的兼容性问题。这时,可能需要查看微软的官方支持文档来获取特定的解决方案或更新。 对于错误代码0x00000057,这通常是由于没有足够的权限来访问网络打印机或其共享资源,解决方法是确保网络打印机的权限设置正确,包括在组策略中设置相应的访问权限。而0x00000709错误可能是由于打印机驱动问题或打印机端口配置错误,可以尝试重新安装或更新打印机驱动来解决。至于0x0000011b错误,这往往是因为打印机队列服务的问题,检查并重启“Print Spooler”服务通常是解决这类问题的常见手段。 至于“连接失败”或“内存不足”这类故障,通常与客户端和打印机之间的网络连接以及打印机本地资源的使用情况有关。检查网络连接,确保打印机所在的网络段没有故障或中断。同时,如果打印机的打印队列长时间得不到处理,可能会导致内存不足的情况,这时可能需要清理打印队列或增加打印机的内存配置。 为了帮助用户更快速地解决这些问题,市面上出现了各种打印机共享错误修复工具。这些工具往往通过预设的修复程序来自动检测和修正打印机共享中常见的问题。它们可以快速检查打印机驱动、网络连接以及共享设置,并且能够提供一键修复功能,大幅减少了用户自行排查和解决问题的难度。 然而,在使用这些修复工具之前,用户应确保这些工具的来源是安全可靠的,避免因使用不当的修复工具而引发其他系统安全或隐私问题。用户可以到官方平台或者信誉良好的软件提供商处下载这些工具。通过细心检查打印机的共享设置,及时更新驱动程序和服务,以及合理使用修复工具,大多数共享打印机的问题都可以得到有效的解决。
### 汽车车身密封条系统设计规范总结
内容概要:本文档提供了关于汽车车身密封条设计的全面指南,涵盖密封条的定义、分类、材料选择、结构设计、安装方式、生产工艺、设计流程及验证方法。具体内容包括密封条的分类依据密封功能和装配部位,详细介绍了EPDM、PVC、TPE等材料的性能特点及其生产工艺,强调了密封条设计中的关键参数如密封间隙、压缩量、压缩方向等,并通过典型断面设计和CAE分析确保设计合理性。此外,文档还详细描述了密封条在不同车身部位如发罩、行李箱、车门、玻璃导槽、前后风窗及顶盖的具体设计要求和注意事项。最后,文档列举了密封条设计和制造中的常见问题点,并提供了相应的解决方案。 适用人群:从事汽车车身设计、制造及质量控制的工程师和技术人员。 使用场景及目标:①帮助设计师
理解
并掌握不同类型密封条的设计要点和工艺要求;②指导工程师进行密封条的设计开发、材料选择及性能验证;③为生产和技术人员提供解决密封条常见问题的参考方案。 其他说明:文档内容详尽,结合大量
基于springboot+vue+mysql的疫苗发布和接种预约系统(源码+论文+开题报告).rar
采用前后端分离架构,包含数据库文件,代码经过完整测试,保证可以运行,内部包含详细的运行说明文档,如遇运行问题可私信博主。 本项目主要面向计算机相关专业中正在筹备大作业、毕业设计的学生,以及渴望通过实战项目提升编码能力的自学者,系统难度设计贴合教学需求,功能模块覆盖全栈开发核心知识点,所有代码与文档均经测试审核,学习者可放心下载参考或直接用于课程实践。
JAVA面试,知识总结
JAVA面试,知识总结
Huawei S6720EI-V200R023SPH220
Huawei S6720EI_V200R023SPH220,里面包含补丁说明书和补丁安装指导书,该补丁支持哪些型号,支持哪些版本可以安装当前补丁,请参考补丁说明书和补丁安装指导书。
研发管理
1,268
社区成员
28,284
社区内容
发帖
与我相关
我的任务
研发管理
软件工程/管理 管理版
复制链接
扫一扫
分享
社区描述
软件工程/管理 管理版
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章