nicklee .net framework 太爽了，好多web的UI控件，有些是网上收集的，有些是结合其它框架的，有些有可能是破解的，但不管怎样，对于像我这样的程序员来说是件大好事。
如果可以的话我也希望可以成为开发员的工份子。
1.需求分析及变更管理
2.项目模型及业务流程分析
3.系统分析及软件建模
4.界面设计、交互设计及程序开发
5.系统测试和文档编写
6.客户培训、技术支持和售后服务
虽然开发人员和管理人员很容易自认为他们了解用户需要，但实际情况常常不是这样。人们往往关注于用户应该如何执行任务，而不是用户偏好如何执行。多数情况下，偏好问题不仅仅是简单地认为已掌握了用户需要，尽管这本身就很值得研究。偏好还要由经验、能力和使用环境决定。”
*与用户交谈
*到办公地点拜访用户
*观察用户工作
*将用户工作录像
*了解工作组织
*自我尝试
*使用户在工作时边想边说
*让用户参与设计
*在设计小组中包括专家级用户
*执行任务分析
*利用调查和问卷
*制定可测试的目标
*真正以用户为中心的设计，到客户的实际工作环境中观察和记录；
*仔细查找各种业务主角，并表述不同主角的各种操作流程步骤；
*简化需求，将客户的需求归纳整理，抓住核心问题；
*细化需求，针对核心问题，模拟用户角色，进一步确认流程和规范；
为了避免需求遗漏或整理误解，需求方和开发商需要集中完成需求分析。
需求分析可以在合同需求的基础进行，但必须包含以下部分：
用例文档
功能的需求说明
非功能的需求说明
需求跟踪矩阵，保证需求变更的及时性
需求分析成果必须经过使用部门的审核，才能归档备案。
数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式
⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
需求类型：可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
⑵使需求符合系统的整体目标；
⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。
可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。 原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。
一直在Asp.net上试着开发orm,前段时间看过一编园里的文章,里面说到orm应该有一个缓存机制,刚好这个想法可以应用到我的统计系统中,所以打算加强前段时间写的一个orm的组件.加入缓存功能.