望能分享你的项目的策划/模块设计经验和技术混来混去，我已接触asp.net2年多了。网站/管理系统也做了几个.
望能分享你的 项目的策划/模块设计 经验和技术[解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法] [解决办法]
探讨 [解决办法] 复古了,回到了结构化语言的年代..框架==结构?你认为呢?
[解决办法] 1.工欲善其事，必先利其器。
工具：
PowerDesigner 对象设计与分析，程序员使用。
Lucid.Spec、GUI.DesignConcept、Draw.WebWave 界面设计与演示工具 呵呵 ，多数行业外客户是属于眼见为实的人，你对他讲uml，数据库表是白搭，他不会理你的，你只能把原型界面先给他看
2.程序策略：
不要相信客户，别相信他的话----我宁可相信他实际要解决的问题本身，而不是他嘴上说的他想如何解决
大量使用xml来配置元数据，让你的程序依靠这些元数据他运行，而不是在程序里面硬编码。
对于可以预见的改变，事先就要做防御性编码
不事先决策任何事情，如果我无法确定程序的走向，我干脆就不做，我就把程序放在中间，至于你向左还是向右，客户自己说（呵呵，我这是推卸责任的做法，是你自己要向右的，那么你自己负责！如果结果你不满意也和我没关系，这个是你自己做的决定，当然你最终要改到左边，没问题!我可以改，不过这个责任本身我是不负的）
[解决办法] 别让沉了，顶起来，学习
[解决办法] 顶,不要沉
[解决办法] 学习
[解决办法] MARK,关注.
[解决办法] 关注下
[解决办法] Mark
[解决办法] 关注下。没经验~
------解决方案--------------------
up
[解决办法] 关注。。。
[解决办法] 探讨 [解决办法] 探讨 [解决办法] 帮你顶吧。
[解决办法] 探讨 [解决办法] 遇到与同楼主一样烦恼................
[解决办法] jf
[解决办法] 为同样的问题困扰!
关注!
[解决办法] 一个好的框架很重要，尽量做成OA模式的
[解决办法] 探讨 [解决办法] 哎··应该非常非常的抽象,要任何地方都可配就好了·哈哈·
[解决办法] 我也遇到过这种问题,相当崩溃型...严重关注!
[解决办法] 探讨 [解决办法] 多准备点设计文稿,要详细，设计多花点时间做调研.
和客户谈的时候一定要能忽悠，把客户先弄晕,尽量让他知道建一个项目的难度是非常大的,省得提出点希奇古怪的想法.
设计程序时,尽量多用接口,如果写的人多的话，要规定一行代码一行注释.
至于数据库扩充..必要的冗余还是要的...多放点死不了,反正大不了客户的服务器压力大点...只要别出错就行了.如果写好程序的话，尽量新建个表用外键关联,不要改表结构，不然很麻烦...
个人只做过一个程序的策划,设计...只有那么一点经验- -,继续等待各位前辈高见~
[解决办法] 我认为这种问题关键是项目的层次结构分明,构架很重要...数据层字段的改变不会引起业务层,界面层崩溃.
而在数据层的东西,涉及到增/删/改.大部分是可以用ORM工具完成的,特殊的地方手动改是不可避免的.既然用户都认同修改的这个代价了,你们慢慢改就是了.
关键还是构架...
其实我们大多用的都是还是瀑布式的开发,中间走了很多弯路对RUP有一些认识.但是象你所讲的经常涉及这样的变动.可能只有敏捷开发,极限编程什么的能适合你了.其实这种东西在中国还是用不上来,如果要开发团队能很快地响应客户在需求上的变动,做到敏捷,最起码的是要求团队成员都具备比较高的素质,比如说大家都精通UML,大家都精通ORM,大家都精通NHIBERNET.而我们通常做项目,公司都是找一两个高手,带一大批毕业生在做.敏捷方法实现不了的.
我觉得关键还是沟通,经验而谈..要努力给客户灌输版本的概念...你需求变了,但是我的项目快做完了,前面做完的测试也在跑着,这个版本就不变了,出来你们先用着,有FEEDBACK,你的需求变更我也接受,给你安排在下一个版本实现.
[解决办法] 以前收集过一篇关于数据库设计的帖子，结果找了半天没找着，唉算法，跟着牛人们顶！
[解决办法] 没事做个通用模版出来.以后做什么都简单..呵呵...
什么东西都要想的出的都想出来..让你程序尽量没有欠缺..
框架是程序的骨架..打好了就能随你怎么动.... [解决办法] Mark
学习中进步啊
[解决办法] 这不明显就是框架设计，那些老丫丫们整天在那叫的什么思想，AOP，切面，跨平台，移植，。。。
噢做。NET的我说怎么不知道，。。
在次呼宇：中国的东西不要做太像老古董。。看外国人的好东西，都是先简单后复杂，这样才空易和迅速的得到推广和应用吗，整天在那叫呀喧呀，让人觉得很古董很复杂，那并不能代表你的东西就好，其实不就是现在的这些小辈们发现的这些问题吗？同志们说是不？
------解决方案--------------------
探讨 [解决办法] 关注中, 学习中
[解决办法] 变动不怕，怕就怕变的不“明”
为了项目做到“明”，我把数据库关系连成了大图，贴在白板上。（我们的打印机是600毫米宽的）
见
http://www.dullwolf.cn/databaseinfo.swf
这样的表现在已经多到130多个了。
项目够大不？呵呵
[解决办法] 一言难尽............
事实上对于你的第2个问题,我一直有想法要写这么一本书(打算叫<弱势软件开发>)来探讨在非对等环境上的软件开发管理话题,需求变更问题是最重要的问题,可惜苦于繁忙. 这两年连上CSDN的时间都很少了(只是最近为忙招聘的事才经常上来溜达).
对于需求变更的控制和处理, 从我从事软件项目管理到现在有3年半的时间, 在这上面有各种成功和失败的经历,也摸索出一些 "非主流"的管理手段. 感觉很多"权威"的软件管理类书籍都合适大型正规的软件企业, 对作坊式的小软件企业(我称为弱势软件开发企业-----指的是对比自己的客户,自己处于弱势一方的软件公司)并不合适, 比如权威方式希望签完合同定好规格再开发, 假设你是一个注册资金几十万的小公司,而且处于倒闭边缘,现在接到一个1000万的大单子,但是客户提出很多不合理的要求,那你也是必须答应的,等等问题的一些处理.
不过不是三两句能说清楚, 如果你有兴趣的话我们可以以Email方式探讨, 我的地址是syeerzy@hotmail.com
[解决办法] 学习下
[解决办法] 探讨 [解决办法] 添加数据库字段检查时的一个笨办法
挨个页面检查添加数据库字段对此页面有影响没有
如果有影响看看需要更改哪里
然后再检查更改的引用的地方需要不需要更改
[解决办法] 深有同感，现在一直再补软件架构方面的东西，建议楼主可以看看，可能会有帮助
[解决办法] Advanced.C#.Programming.pdf
Apress - Accelerated C# 2008 (netbooks.wordpress.com).pdf
Apress - Beginning ASP.NET 3.5 in C# 2008 From Novice to Professional, Second Edition.pdf
Apress - Pro C# with.NET 3.0 Special Edition - Jan 2007.pdf
Apress - Pro LINQ Language Integrated Query in C# 2008.pdf
Apress Beginning C# 2008 From Novice to Professional Nov 2007.pdf
Apress.Beginning.Web.Development.Silverlight.And.ASP.NET.AJAX.Feb.2008.RETAiL.eBOOk-sUppLeX.pdf
Apress.Silverlight.and.ASP.NET.Revealed.Dec.2007.pdf
Building Secure Microsoft ASP.NET Applications.chm
C# - Apress - Net Game Programming With Directx 9.0 - 2003.pdf
C# Cookbook, 2Nd Edition (2008).chm
C#文档中文版(微软).pdf
C#程序员参考手册.pdf
C＃高级编程（第四版）Pro C# 2005.pdf
Inside C#, 2nd Edition.chm
Introduction to Design Pattern in C# vol_3 - IBM.pdf
Pro ASP.NET 3.5 in C# 2008.pdf
Sams - Managed DirectX 9 Kick Start - Graphics And Game Programming - CODE (C#).rar
Sams.ASP.NET.3.5.Unleashed.Jan.2008.pdf
Socket Programming in C#.pdf
UML - Asp Net Xml With C#.pdf
Visual Studio 2008 - Introducing Asp Net Ajax.pdf
Wrox - Beginning Visual C#.pdf
[Apress] Beginning C# 2008.pdf
下载地址 ：昆仑编程园 www.karakoram.org/download 有3G以上的.net电子书
[解决办法] 探讨 [解决办法] 框架设计是软件设计中的大脑，数据库设计是软件设计中的心脏，只是这么一比，不要拍砖
[解决办法] mark
[解决办法] 探讨
[解决办法] 需求是开发的生命线
要把需求做实，做全。然后围绕需求把系统做得灵活些，留下改善系统的空间。
其实这是多么的难啊（特别是对于我这种初级开发人员）
但我觉得和客户确定了需求的前提下，客户提出更改，所有代价有客户负责，返工也无所谓了。
我期待着大家讨论更多确定需求的方法。
[解决办法] 计划没有变化快,
客户的需求永远是在变化和前进的,
这就要求系统架构师,设计师能够把握客户的发展的方向,
灵活机动的设计系统,实现系统的低耦合,
广泛地覆盖用户90%以上的需求和功能,
这样对系统的修改和维护才会降到最低,
但是就目前来说,能够达到这样层次的软件,
国内好像不多,
大量的二次开发和维护,会拖垮一大批的软件厂商,
而少部分存活下来的厂商,就会逐渐走上标准化,模块化的道路.
那时候就是客户被厂商牵着鼻子走,而不是客户牵着厂商的鼻子走了,
[解决办法] 需求的调研就是冰山原理,
10%的是浮出水面的,
而90%的是暗藏在水里的,
这就需要相应的方法去调研,去挖掘.
[解决办法] 楼上的很有见地
[解决办法] 留个名，学习。。。。
[解决办法] 《从灵感到实现》这本书的项目流程感觉上很好。
[解决办法] 顶下
学习
[解决办法] 好东西 就要顶
[解决办法] 学习
[解决办法] 探讨 [解决办法] 学习
[解决办法] 探讨 [解决办法] up
[解决办法] 学习
[解决办法] 路过,看不懂也要顶一下.呵呵
[解决办法] up
[解决办法] 关注。
[解决办法] up
[解决办法] 学习
[解决办法] 写SQL的时候，注意对字段的把握，要养成查询/插入语句编写的习惯，一般查询能用*尽量用*，插入语句尽量写全字段，没写的自动用默认值。
另外，语句最好都用SP写，这样比较容易管理和维护，不要在程序里去拼接。
一个系统的修改，必须考虑周全，尽量不要动到核心的表，实在有必要通过视图扩展。
客户需求更改在软件开发时是大忌，如果没有成功的需求分析，一个软件开发就是失败的。象你说的这个问题，应该从开发流程上去把握。
不能客户说什么就什么，IT也是有成本的，不应该处在弱势
[解决办法] 我也是遇到了一些问题,每次去客户那,都有新的要求,结果一个项目做了半年了还没给客户,最后老板说我效率低,客户怀疑我们的能力,郁闷
顶...
希望专家们多出来说说
[解决办法] 头痛头痛
[解决办法] 呵呵，深有同感！
[解决办法] 探讨 ------解决方案--------------------
我们还是来看一下需求这东西
归根到底，还是需求的变化在作怪
如果需求的变动尽量小，程序的负担自然会变小
那么，我们就应该去思考根本的东西
虽然，通过可扩展的框架，良好的设计，也能够达到这一目的
但是实现起来还是有很大的代价
客户会改变他的需求，这是一个必然的事情，更何况他不是一个程序员
那么，我们怎么样才能尽量的避免他去改变需求呢？
需求是基础，是我们做一切的基础，基础都没有打好
那我们能做到最好吗？
[解决办法] 以上，个人愚见，如有不对
请尽量批评，给出意见
还有我所问的问题
希望大家讨论一下
给点意见
[解决办法] 探讨 [解决办法] 拿人钱财，就要给人办事，我们家的客户有时一天都改N次（我们是做网站的 ）
[解决办法] 程序发布后再对源代码或表结构的变更是不可避免的，楼主所遇到的“遗漏”说白了是项目管理流程上和制度上的风险。
首先在项目中每一个变更点的审批，评审和文档化是少不了的
再次所有的变更尽量用脚本或批处理去自动执行，减少手工miss.
再次搭建开发环境，测试环境，验收环境最后才到正式环境。
关于需求变更，程序修改不断是软件开发的一个古老的话题了。除了尽量的解耦，可配置，可插入外，在软件开发的各个阶段也应该注意产出工作的集体评审.
在需求分析中，尽量的去用原型和客户沟通，用详细的文档和工程师沟通。
[解决办法] 也都是具体问题具体分析。
至于什么后期维护、修改，就是把设计模式应用的再OK也不能100%避免自己不愿意见到的情况发生。所谓封装变化，也都是自己能凭借自己的经验来预测变化发生之处。
好的软件架构师，绝不只是技术高手，要对软件工程、市场营销、客户心理……都有较深层次的把握，才能引导出一个较为不错的项目来。
[解决办法] 看看学习啦！
[解决办法] 探讨 [解决办法] 深有感触，做了许多项目，也是经常会遇到像楼主
一样的问题，很是令人头疼……
解决的办法还是脱离不了需求分析和良好的框架设计
，但，说说容易，做起来难呀，继续改吧……
[解决办法] 关注。。。
[解决办法] 顶，关注。。。
[解决办法] 了解一下极限编程、敏捷开发这方面的理论思想吧。
[解决办法] 不知道用ORM的多不多,ORM是用自己开发的呢还是其他的?还有其他公司的架构方式有那些呢?
[解决办法] 学习
[解决办法] 做一個擴充性強,權限功能完善的系統,用戶再怎么變都不怕...
[解决办法] 这类人群多啊
[解决办法] 用户是上帝吗？ 是的，在回款之前
[解决办法] 对客户提出的各种各样的需求，你永远只能去满足他80% ，否则你永远也做不完
[解决办法] 学习、关注一下了
