BlogJava-Shao Fan-随笔分类-软件工程http://www.blogjava.net/shaofan/category/7859.html关于JAVA与软件工程zh-cnTue, 27 Feb 2007 12:33:06 GMTTue, 27 Feb 2007 12:33:06 GMT60被遗忘的一种提高软件质量的方法 -- 契约式设计 (Design by Contract)http://www.blogjava.net/shaofan/archive/2006/03/02/33103.htmlshaofanshaofanWed, 01 Mar 2006 16:55:00 GMThttp://www.blogjava.net/shaofan/archive/2006/03/02/33103.htmlhttp://www.blogjava.net/shaofan/comments/33103.htmlhttp://www.blogjava.net/shaofan/archive/2006/03/02/33103.html#Feedback4http://www.blogjava.net/shaofan/comments/commentRss/33103.htmlhttp://www.blogjava.net/shaofan/services/trackbacks/33103.html阅读全文

shaofan 2006-03-02 00:55 发表评论
]]>关于需求变更的问题（2）http://www.blogjava.net/shaofan/archive/2006/02/26/32465.htmlshaofanshaofanSat, 25 Feb 2006 23:22:00 GMThttp://www.blogjava.net/shaofan/archive/2006/02/26/32465.htmlhttp://www.blogjava.net/shaofan/comments/32465.htmlhttp://www.blogjava.net/shaofan/archive/2006/02/26/32465.html#Feedback0http://www.blogjava.net/shaofan/comments/commentRss/32465.htmlhttp://www.blogjava.net/shaofan/services/trackbacks/32465.htmlIf the problem was exploring requirements to lead them toward stability, the solution was seen to be prototyping. ... Prototyping and JAD continue to be used to this day, especially when requirements are poorly understood.

Meanwhile, management had to figure out how to deal with reuiqrements instability and the "moving target" problem. ... But eventually management came to realize that, although they could not freeze the requirements, they could insist that changing requirements lead to changing project terms and conditions. "You want new or revised features? Then let's talk about how much time and money that will cost over and above our original estimate." Unfortunately, that led us into the swampland of changing estimates while the project was in progress...

There is an interesting new twist evolving on the requirements instability problem. The extream Programming lightweight methodology calls for a representative of the user community to reside with the software project team during development. ... The questions remain, however, how many user organizations (a) will be willing to give up a first-rate person to such a full-time task, and (b) have one person who can represent all the potentially varying viewpoints of the customers and users?

为了更好得捕获需求，使它们有更好的稳定性，人们开始使用＂原型＂．＂原型＂和JAD（联合应用开发）在如今仍在被使用着，尤其当需求无法被准确理解的时候．

同时，管理者必需面对和解决需求不稳定，及＂移动靶＂的问题．最终他们认识到，虽然他们无法冻结需求，但是他们可以坚持＂需求变化导致合同条款变更＂的想法．＂如果你想修改项目的功能，那就需要考虑这些修改所需要的时间和资金成本．＂不幸的是，这致使项目陷入需要重新进行估计的泥沼之中（在项目进行之中进行重新估计会造成哪些问题？）．

此时极限编程浮出水面．它要求一个客户代表与开发人员一起，参与软件开发的过程．这可以解决一些问题，然而问题仍然存在，有多少组织(a)愿意放弃一个一线员工，让他全职参与软件开发，(b)能找到一个可以代表所有潜在的，持不同观点的客户和用户的人？（关于这点，个人认为光有客户代表可能还不够，还是要在需求捕获的过程中采用多种有效的手段，起码客户代表要与其他参与需求的客户和用户有一定的一致意见，否则，怎么起到＂代表＂的作用？）

[GLASS]　Facts and Fallacies of Software Engineering, Rober L. Glass, Addison-Wesley,2002


shaofan 2006-02-26 07:22 发表评论
]]>关于需求变更的问题http://www.blogjava.net/shaofan/archive/2006/02/25/32411.htmlshaofanshaofanSat, 25 Feb 2006 09:45:00 GMThttp://www.blogjava.net/shaofan/archive/2006/02/25/32411.htmlhttp://www.blogjava.net/shaofan/comments/32411.htmlhttp://www.blogjava.net/shaofan/archive/2006/02/25/32411.html#Feedback0http://www.blogjava.net/shaofan/comments/commentRss/32411.htmlhttp://www.blogjava.net/shaofan/services/trackbacks/32411.html
Early on, most people in the software field believed that the problem was weak software management, and the solution was to hold the line one the original set of requirements, insisting that when the software team had solved that problem, the customers and users would just have to accept that solution. It was during this era that computer scientists came up with the notion of formal specifications...

That approach really didn't work very well. The eventual solution didn't solve any problem the customers and users really needed solved, and, therefore, those slutions were ignored and eventually abandoned. All that time and money had been spent building a software solution that went straight to the refuse bin ... so did the relationship between the customers and the development organization


上面这两段话，选自[Glass]中的一章．作者认为导致项目失控的两大最常见原因之一，就是不稳定的需求．而另一个原因则是过于乐观的估计．需求不稳定其实是软件过程中固有的一个特性．它并不是单指需求本身不稳定，而是说在软件的开始阶段，用户的需求很可能无法被完全挖掘，因为客户本身并不能完全了解他自己想要什么．而随着开发的进行，各个方面越来越具体，客户对自己的需求的认识逐渐提高，因些导致需求的变更．

在早些年里，人们并未认识到＂不稳定的需求＂是软件开发本身固有的本性，而是把问题归咎于管理．基于此的解决方案就是，坚持在最初捕获的需求的基础上进行开发，否认和拒决需求变更．在这段时间里，FORMAL SPECIFICATION发展了起来．

然而这种做法并不很成功．基于这种做法产出的软件并不能真正解决客户的问题，结果是，这些产品无法投入使用而沦为废品，开发人员的努力和客户的金钱都付诸流水，而客户与开发组织间的关系也无法维持下去．

[GLASS]　Facts and Fallacies of Software Engineering, Rober L. Glass, Addison-Wesley,2002


shaofan 2006-02-25 17:45 发表评论
]]>