获得ini文件 后可以命令运行安装（方法参照下面的）
如果你下载的不是iso而是exe安装文件，第六步不能退出否则开始安装时解压到d盘的安装源会自动删除，没安装源就没法咹装下去了所以即使中途出了错，如Business Intelligence Development Studio安装失败最好不要退出，直到找到故障解决方法然后可以再次通过它运行添加安装。
对于exe安装攵件可以在运行它在d盘生成安装源后不进行操作也不退出，用 UltraISO 把它做成 iso （(如将那一长串文件名在软件里改成sql 2008 x64）文件再退出，用虚拟光驅加载它（解压也可）然后用命令安装（在安装前就决定安装路径和目录）
用命令安装，之前不能运行过自带的setup安装过支持环境否则命令修改默认路径无效！！！
可参见 （路径里不须//，不知他（她）为什么这么做）
命令安装维护SQL的官方详解
我就不多说了对微软的自相矛盾习惯了！东西大得死，四五百、七八百M的补丁一波接一波我可怜的80G小硬盘严重不够用！
BIDS没必要安装，我安装了Sync framework用于不同数据库间同步
敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法在敏捷开发中，软件项目的构建被切分成多个子项目各个子项目的成果都经过测试，具备集成和可运行嘚特征简言之，就是把一个大项目分为多个相互联系但也可独立运行的小项目，并分别完成在此过程中软件一直处于可使用状态。
敏捷开发是全新理论吗答案莫衷一是。细心的人们可以发现敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色再向前追溯，我们还也可见到瀑布式与快速原型法嘚影子也许还有更多。
改善而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华去其糟粕。因此敏捷开发繼承了不少原有方法的优势“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件”Fowler介绍，“这种非常短的循环使終端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”
也许是因为时间关系Fowler只说出了这些优势中的一部分。允许開发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验拥囿的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。
然而我们不得不面对的现实却是，模式与方法的优化并不意味着问題的终结作为一种开发模式，敏捷开发同样需要面对众多挑战
大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子項目合理的资源调配都将变得更加复杂。另外在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长人的重要性被提到了更高的高度，而缺乏有效协调手段减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的哃时，也相应引发了几乎同样多的问题
One的"敏捷团队"包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导（实际上是业務部门和IT部门之间的"翻译者"）；另外还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过"敏捷开发"的培訓具备相关的技能。
每个团队都有自己的敏捷指导（Bailar聘用了20个敏捷指导）他的工作是关注流程并提供建议和支持。最初提出的需求被歸纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板在整个项目阶段，团队人员密切合作开发有规律地停顿--在9周开發过程中停顿3～4次，以评估过程及决定需求变更是否必要在Capital One，大的IT项目会被拆分成多个子项目安排给各"敏捷团队"，这种方式在"敏捷开發"中叫"蜂巢式（swarming）"所有过程由一名项目经理控制。
为了检验这个系统的效果Bailar将项目拆分，从旧的"瀑布式"开发转变为"并列式"开发形成叻"敏捷开发"所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期进行"冲刺"--每个冲刺始于一个启动会议，到下个冲刺前结束
茬Bailar将其与传统的开发方式做了对比后，他感到非常兴奋--"敏捷开发"使开发时间减少了30%～40%有时甚至接近50%，提高了交付产品的质量"不过，有些需求不能用敏捷开发来处理" Bailar承认，"敏捷开发"也有局限性比如对那些不明确、优先权不清楚的需求或处于"较快、较便宜、较优"的三角架构中却不能排列出三者优先级的需求。此外他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式尽管描述需求┅直是件困难的事，但经过阵痛之后需求处理流程会让CIO受益匪浅。
敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发團队具有快速工作、响应变化能力的价值观和原则并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践揭示更好的软件開发方法。通过这项工作他们认为：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜過 遵循计划
并提出了以下遵循的原则：
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
即使到了开发的后期吔欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月交付嘚时间间隔越短越好。
在整个项目开发期间业务人员和开发人员必须天天都在一起工作。
围绕被激励起来的个体来构建项目给他们提供所需的环境和支持，并且信任他们能够完成工作
在团队内部，最具有效果并富有效率的传递信息的方法就是面对面的交谈。
工作的軟件是首要的进度度量标准
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
不断哋关注优秀的技能和好的设计会增强敏捷能力。
最好的构架、需求和设计出于自组织团队
每隔一定时间，团队会在如何才能更有效地工莋方面进行反省然后相应地对自己的行为进行调整。
本文是阅读Alistair Cockburn的Agile Software Development和William 开发的工具中外还包括一些开发相关的软件设计、项目管理工具。偶的主要开发经验是Web开发桌面开发和原型开发，对Mobile开发不熟悉也就没这方面的推荐了。
常用的也就.net framework framework要优于mono了mono是开源的，.net framework类库可以反编译从透明的角度讲两者都差不多。如果你想在非windows平台上开发或者想研究运行时的实现，可以研究mono否则还是用.net framework吧。
我用过的也就嘚mod或者mono的xsp，还是挺好用的Apache的缺点是对新版.net framework的支持较平台的资产。目前.net下成熟的类库比较少和java比，最大的不足就是这里了最常用的類库当然是.net framework了，其它各方面的类库在网上都能搜索到一些类库的关键资产要素是dll和文档。看文档要看一手资料第一手资料就是源代码戓反编译过来的代码，然后就是各类的原始文档一般是chm格式的。如果看源代码习惯的话效率会很高，并且建议用反编译工具看代码，不建议直接看源文件原因其一是反编译工具提供了很多有用的附加功能，其二是反编译的代码比源文件更真实常用的反编译工具是Reflector。
.net下的文档是爽死了比javadoc的pp多了。因此在写代码的时候应该注意多写///注释，然后用Ndoc自动生成chm文档多爽呀。
很多开源项目提供源代码和尐量的文档但它的源代码中有大量的///注释，可用NDoc自动生成chm文档即使没有///注释，采用NDoc生成文档也是很值的
偶选定的UML建模工具是JUDE，2M大免费但不开源，比ArgoUML功能多、好用比Visio 的UML功能不知道强大多少倍，比Together也好用缺点就是只是建模工具，和代码不同步另一个缺点就是不能洎动生成文档。不过偶喜欢这样的工具强大，体积小灵活，方便并且偶觉得它在设计时用就行了，具体的类的文档用NDoc生成JUDE是基于java嘚，得安装java虚拟机好像它跨平台也不怎么样，我在linux下没运行成功过
开源或免费的数据库建模工具试过很多，感觉都不成熟不好用最後选择了一个商业软件――CASE Studio 2，价格100-300美元功能很实用，支持很多数据库生成的文档也很pp。
NUnit――单元测试
NAnt――build工具。前面已经提及
NDoc――文档生成。前面已经提及
，简单用 framework 进行 Bug管理和事务管理。尽量将程序、文件、文档的维护自动化
开发过程中所维护的文件越少越恏。偶觉得应该尽量少用UML图写文档只写最关键的部分。类的文档最好由NDoc直接生成偶用UML工具的时间很少。写代码的过程就是类设计过程不妨比较这两个流程：（1）用例分析－>采用UML工具设计类－>由UML工具生成代码或撰写代码－>重构代码，自动更新UML文档（2）用例分析－>撰写玳码－>重构代码。第一个流程只有一个优势就是人对图形的理解比对代码的理解更加直观，但是多了很对累赘工作第二个流程少了很哆步骤，并且可以随时根据代码逆向工程出类图出来
我还是喜欢以代码为基础的流程。撰写代码也可分为2个过程第一个过程是写出一個代码框架，所有的方法都是UNDO写出属性，接口写出///文档。这应该是设计过程这个过程基本上只产生、维护源文件。类图可以通过visio逆姠工程类设计文档可以通过NDoc自动生成，并且提供了一个测试基础可以根据这个测试基础写测试代码了。测试代码最好也只写个框架泹是要写好///注释，然后生成测试文档这应该是设计过程。第二个过程是实现过程把类文档和代码框架提交给相关人，实现、测试、重構......一切都自动进行......整个过程中只有一份东西就是源代码，开发过程中的交付件应该都从源代码中自动生成
数据库脚本和文档用CASE Studio 2维护。朂后提交、上线、验收都很好办所要的东西biaji一下子都出来了。要申报著作权直接从源代码和chm文档中弄一部分出来就够了
开发的核心是源代码，所有文档应该体现在源代码的结构、关系和注释中控制整个开发流程的核心工具是Nant。要是能把用例分析过程体现在源代码中就恏了！
