摘要：在项目管理的进行过程中，经常用到的一种能力是沟通。沟通有很多种方式，包括一对一的沟通、一对多的沟通、多人之间的相互讨论，从沟通的载体而言，有口头、书面、肢体语言，包括面对面的、电话、通过网络、电视、广播等各种途径。 但是所有这些沟通方式，无论多复杂，实际上都可以简化成一对一的沟通一种形式，最终沟通都只是两个人之间的事情。沟通可以是相互的，但是具体到沟通的"一招一式"，都是一个信息发出者，一个信... 阅读全文

摘要：每一个项目都有其固有的特殊性，所以在每一个具体的项目中，项目关系人对项目结果和项目实施过程的期望会有所不同或各有侧重。所以，面对具体的项目，项目经理首先要主动地、系统地识别三类主要项目关系人对项目结果和项目实施过程的期望，然后对这诸多的期望进行科学管理，求同存异，达成一致。 当前，在IT客户项目的实施过程中，项目经理不再是以项目协调员、资源计划员、进度控制员、数据统计员、资料保管员或救火队员的角色... 阅读全文

摘要：文七　细节需求时期（下） 内容： ·1、"和其它阶段的关系"的再思考。 ·2、架构 ·3、模式 ·4、简单设计 ·5、如何统一 ·6、测试 ·7、分解 ·8、客户如何参与 ·9、小结 和业务建模时期不同的是，我不再花费笔墨讨论需求要如何做，因为做法、注意点和业务建模时期并没有什么太大的区别。而在完整的流程上，像RUP、XP之类的方法学可比我讲的要好的多。... 阅读全文

摘要：文六　细节需求时期（上） 内容： 1、细节需求时期和业务建模时期是不同的。 2、迭代 3、需求迭代的特殊性 4、迭代的代价 5、和其它阶段的关系 从这一篇开始，我们开始进入细节需求时期。和业务建模时期注重于软件概貌不同的是，细节需求时期讲究充分挖掘涉众的需求，并作为其它的活动的输入。细节需求时期和业务建模时期有着不同的做法，迭代、小版本发布的思想是非常重要的。 1、... 阅读全文

摘要：文五　业务建模时期（下） 内容： ·原则（Principle） ·实践（Practice） 和上一篇的理论不同，这一篇文章更注重于实际，举出了在业务建模简短需要注意的一些原则和实践，每一条都来自于实践之中，也都有理论的支持。其中的很多内容更是经过多次的失败才总结出来的。相信大家如果能够理解这些原则和实践的某些方面，至少能够避免重蹈覆辙。 原则（Principle） 1. 谁才... 阅读全文

摘要：文四　业务建模时期（上） 内容： ·所有的项目都有业务建模时期 ·建模原理 ·关于作者 在大规模的需求调研展开之前，有一个重要的工作要做。这项工作在项目中所占的时间跨度非常的小，但是却有非常重要的意义。不同的人、不同的方法对这项工作有不同的描述，在我们的文章中，根据UP的思想，称之为"业务建模"。 所有的项目都有业务建模时期 1. 业务建模是什么 业务建模（Busin... 阅读全文

摘要：文三 UML介绍—Customer Oriented而不是Program Oriented 内容： ·1. UML ·2. UML起源 ·3. UML是什么 ·4. 用例图和用例 ·5. 用例和需求，用例和过程 ·6. 使用用例的误区 ·7. 用例的观点 ·8. 用例的不足 ·9. 迭代式的需求分析 ·10. 小结 软件开发人员总是在困惑为什么软件分... 阅读全文

摘要：文二　能力和过程 内容： ·1、煮鸡蛋的启示 ·2、需求过程 ·3、需求过程和CMM ·4、需求过程和软件生命周期模型 ·5、RUP和XP ·6、结语 本文作为这个关于需求的软件工程专栏的第二篇，作者将继续花了一些篇幅来讨论软件工程中的一些基本概念，以求大家能够从整体的角度来理解需求过程。 1、煮鸡蛋的启示 有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮... 阅读全文

摘要：文一　软件和需求 内容： ·1.1. 从猴子说起 ·1.2. 项目和需求 ·1.3. 需求是根本 ·1.4. 需求是变化的 ·1.5. 需求是什么 ·1.6. 需求的层次 ·1.7. 需求的标准 在这个关于软件工程的新专栏里，作者将通过一系列的文章，结合理论知识，实践案例，优秀的工具介绍，经典文章导读，告诉您软件工程中最重要的一个过程――需求过程各方... 阅读全文

摘要：十四、进一步阅读 敏捷架构设计一文到目前已经全部结束，由于架构设计是一个很大的话题，要在一篇文章中完全把架构设计讲清楚是很难的。因此本文的最后一个章节中提供了一组书籍和文章，这些资料都和架构设计有关，本文的写作过程也从中获益良多，故而推荐给有兴趣的读者。 Refactoring To Patterns（Joshua Kerievsky）勿庸置疑，模式是软件设计的一种有效的工具。但是在将模式和... 阅读全文

摘要：十三、代码验证 要保证架构的稳定和成功，利用代码对架构进行验证是一种实用的手段。代码验证的核心是测试，特别是单元测试。而测试的基本操作思路是测试优先，它是敏捷方法中非常重要的一项实践，是重构和稳定核模式的重要保障。 面向对象体系中的代码验证 代码验证是保证优秀的架构设计的一种方法，同时也是避免出现象牙塔式架构设计的一种措施。我们在上一篇稳定化中提到说架构设计最终将会体现为代码的形式，因... 阅读全文

摘要：十二、稳定化 敏捷方法的兴起对设计提出了新的要求，其最核心的一点是针对无法在项目一开始就固化的需求进行演进型的设计。在项目一开始就进行细致、准确的架构设计变得越来越难，因此，架构设计在项目的进展中被不断的改进，这相应导致了编码、测试等活动的不稳定。但是，软件最终必须是以稳定的代码形式交付的。因此，架构设计必须要经历从不稳定到稳定的过程。而架构设计能够稳定的前提就是需求的稳定。 需求冻结 ... 阅读全文

摘要：十一、Refactoring 当架构模型进行迭代的过程中，必然伴随着对模型进行修改和改进。我们如何防止对模型的修改，又如何保证对模型进行正确的改进？ Context 架构模型通过精化、合并等活动之后，将会直接用于指导代码。而这个时候，往往就会暴露出一些问题出来，通常在实际编码中，发现架构存在或大或小的问题和错误，导致编码活动无法继续。这时候我们就需要对架构模型进行修改了。而架构设计的过程... 阅读全文

摘要：十、精化和合并 对于一个已经初步建立好的模型（分析模型或是设计模型）来说，对其进行精化和合并是必要的步骤。 Context 建立架构愿景，为架构的设计定义了主要的设计策略和实现思路。应用分层的原则则对整个的软件进行了结构上的划分，并定义了结构的不同部分的职责。而现在，我们需要对初步完成的模型进行必要的改进。 Problem 我们如何对初始架构模型进行改进？ Solution ... 阅读全文

摘要：九-- 分层 (上) 在定义了架构愿景之后，团队中的所有人员应该对待开发的软件有一定的了解了。但是，面对一个庞大的软件系统，接下来要做些什么呢？分而治之的思想是计算机领域非常重要的思想，因此我们也从这里开始入手。 要进行应用软件的设计，分层是非常重要的思想，掌握好分层的思想，设计出的软件是可以令人赏心悦目的。由于这一章的重要性和特殊性，本章的内容分为上下两节，并不采取模式描述语言的方式。 ... 阅读全文

摘要：八、架构愿景 从这一篇开始，我们将会进入另一个不同的主题，和前面所讨论的模式专注于组织、过程、方法不同，以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。 架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。 Context 在单次的迭代开始阶段，我们已经收集好了单次迭代的需求。 ... 阅读全文

摘要：七、组合使用模式 我们已经讨论了敏捷架构设计的4种过程模式，在这一章中，我们对这四种过程模式做一个小结，并讨论4者间的关系以及体现在模式中的敏捷方法论特色。通过这一章的描述，大家能够对前面的内容有更进一步的了解。 四种模式的着重点 我把源自需求、团队设计、简单设计、迭代设计这4种过程模式归类为架构设计的第一层次，这4种模式能够确定架构设计过程的框架。这里需要对框架的含义... 阅读全文

摘要：六、迭代设计 迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。 Context 在软件生命周期中，我们如何对待架构设计的发展？ Problem 架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？ 我们在简单设计模式中简单提到了"... 阅读全文

摘要：五、简单设计 XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这一章，我们就对简单性做一个全面的了解。 Context 架构应该设计到什么程度？ Problem 软件的架构都是非常的复杂的，带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中，我们提到了一些反对象牙塔式架构的... 阅读全文

摘要：四、团队设计 团队设计是敏捷方法论中很重要的一项实践。我们这里说的团队，指的并不是复数的人。一群人就是一群人，并没有办法构成团队。要想成为团队，有很多的工作要做。 我们之所以考虑以团队为单位来考虑架构设计，是因为软件开发本身就不是一件个人的事情，架构设计更是如此。单个人的思维不免有考虑欠妥之处，单个人的学识也不可能覆盖所有的学科。而组织有效的团队却能够弥补这些缺憾。 Context ... 阅读全文

摘要：三、源自需求 我们说，和重型方法偏重于计划、过程和中间产物不同，敏捷方法更加看重人和沟通。人和沟通永远是第一位的，而计划、过程和中间产物，那只是保证沟通、实现目标的手段。这并不是说计划、过程、中间产物不重要，只是不能够本末倒置 注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模型、代码。例如设计文档、数据模型等。参考RUP的Artifact。 评判软件成功的标准有很多，对于敏捷... 阅读全文

摘要：二、架构设计的敏捷视图 通过上一章的介绍，我们对敏捷和方法有了一个大致的了解，从这一章起，我们开始对软件开发过程中架构设计的研究。记住一点，我们并不是为了架构设计而研究架构设计，我们的目的在于敏捷方法学的应用。 架构设计是一种权衡（trade-off）。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看... 阅读全文

摘要：敏捷思维－架构设计中的方法学（1） 一、从方法论看架构设计 方法论对软件开发而言意味着什么？我们如何看待软件开发中的方法论？方法论能够成为软件开发的救命稻草吗？在读过此文后，这些疑惑就会得到解答。 在第一篇文章中，我们来了解标题中的一些词的含义。 ·方法学是什么？ ·敏捷是什么？ ·为什么讨论架构？ 方法论 方法论的英文为Methodology，词典中的解释为"A se... 阅读全文

摘要：配置 HTTP 访问的 OLAP 源 在我们开始构建基于 Web 的 OLAP 报告应用程序之前，我们必须配置由 Microsoft Internet 信息服务 (IIS) 访问的 Analysis Services 数据源。IIS Web 站点必须安装在安装 Analysis Services 的同一个服务器上，并且它还必须包含一个称为 msolap.asp 的单独文件。该文件是来自 HTT... 阅读全文

摘要：--------------------------------------------------—————————————————————————————————————实时取得数据的下拉框（WEBSERVICE实现）————————————————————————————————————— GetDropDownList.asmx： _ Public Function Get... 阅读全文