qinhl99的专栏-林鸿的技术博客

      在众多企业中没有做风险管理,本书给出了一般的不进行风险管理的借口：         1.客户或上级还没有成熟到坦然接受风险的地步；（实际不然，客户可能已经很成熟，另外，也取决于我们的沟通技巧）          2.不确定性的范围太大，让人无法接受；（面对现实，行业的经验告诉我们会很大）         3.不确定性的范围让低效成为借口；(目标和估算的区别：估算是考虑了各种不确定性的一

 需求的漫画：       关于需求问题，有一幅漫画十分生动地展现了这些问题（这幅漫画我其实最早是在07年一次“敏捷中国”一次软件开发技术人员日上上见到的），如果我们认真剖析后面的东西，还是会给我们的工作带来许多启发的：      究其原因，这幅漫画给人最大的启示就是在需求沟通过程中产生了严重的失真，从客户的描述到项目经理的理解、分析员分析并文档化、程序员的编码、商业顾问的诠释，每个角

计算环境由计算机、相关的软件平台和以及连通这些计算机和相关软件平台网络组成。不同的计算环境有不同的计算风格和编程模型，由一些特定于该计算环境的技术来支撑。      在面向服务的计算环境（其实更准确的说，是面向服务架构的计算环境）中，系统可以是高度分布、异构的。它一般包括服务运行时环境（Service Runtime）、服务总线（Service Integration Infrastructure

一、什么是SOA：        面向服务的体系结构（Service-Oriented Architecture，SOA）是一种 IT 体系结构风格，支持将您的业务转换为一组相互链接的服务或可重复业务任务，可在需要时通过网络访问这些服务和任务。当在战略业务目标的引导下进行 SOA 实现工作时，可确保对业务进行积极转换，并能够实现 SOA 的好处：IT 与业务的一致性和IT 资产的最大化重用。

1、所有软件活动包括：根本任务——打造由抽象软件实体构成的复杂概念结构。次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。2、软件任务中的必要活动，也就是那些和构造异常复杂的抽象概念结构有关的部分：  仔细地进行市场调研，避免开发已上市的产品。  在获取和制订软件需求时，将快速原型开发作为迭代计划的一部分。  有机地更新软件，随着系统的运行、使用和测试，逐渐添加

1、文档和程序对于软件产品一样重要，即使是程序的用户是自己；2、培训和管理人员基本上没有能向编程人员成功的灌输对待文档的积极态度——文档能在整个生命周期对克服惰性和进度压力起到促进和激励作用，这样的失败，使由于没有能够展示如何有效地、经济的编制文档；3、大多数的关键文档包含了软件设计的一些重要决策，因此它们应该在程序编制之前开始编写和完成；4、为了使文档和程序更容易维护和同步，将文档合

1、一天一天的进度落后比重大灾难更难以识别和防范、弥补，而进度的延误大多是一天一天的积累下来的，因为重大的灾难发生的概率不是很高；2、里程碑的定义必须是具体的、特定的和清晰可度量的，以至于自欺欺人时，程序员很少就里程碑的进展弄虚作假了；3、慢性进度偏离是士气杀手；4、不存在关键路径进度的替代品，使人们能够辨别计划偏移的情况；5、PERT图的准备工作是使用PERT图最有价值的部分，包

一、什么是业务驱动开发        业务驱动的开发(Business-driven development，BDD)是一种由业务需求驱动的端到端软件开发方法。其主要的手段是通过主要流程步骤对业务流程进行建模，建立业务部门通过投资回报 (ROI)、主要性能指标 (KPI) 或其他度量标准来对业务流程或主要用例进行评估过的BPM(业务流程模型)——业务部门和IT部门沟通业务需求的桥梁的主要机制。

1、对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的办法，即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤；2、一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可避免；3、用户的实际需要和用户感觉，会随着程

1、巴比伦塔项目的失败是因为缺乏交流以及交流的结果——组织。项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。2、缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定，开始出现偏差。3、团队如何进行相互之间的交流沟通：清晰定义小组内部的相互关系和充分利用电

    建议直接从转载处阅读：http://www.ibm.com/developerworks/cn/rational/rationaledge/content/dec05/kroll/index.html文档选项 <!--document.write(将此页作为电子邮件发送);/

 信息技术（IT）体系结构是软件密集的系统的基本组织状态。系统之所以是软件密集的，是因为 IT 体系结构的最重要部分是其应用程序，也就是支持用户执行其业务任务的部分。除了应用程序之外，IT 体系结构还具有其他方面。IT 体系结构中的应用程序需要基础设施，即赖以运行应用程序的基础。此基础由硬件服务器计算机、桌面工作站、存储和网络构成。它还由服务器软件构成，包括中间件应用程序服务器、数据库服务

       我个人觉得，我们对一个项目价值的认识比对风险的认识更为糟糕。其实对风险的量化本身就很难，对价值的量化就更难了。似乎量化价值只是客户的事情，正如书中所说的，我们一般忽视对价值的量化的理由是：       系统的规模太小，不知道这么做； 我们没有选择，我们只是必须完成它；上面的主管要这个系统；能有多少收益这取决于市场，特别是市场届时的发展情况有关；这个系统只是要替代现有的系统；命令是上面

 我们真的进行风险管理了吗？ 1.1、有一个风险清单； 2.2、有一个持续的风险发现机制； 3.3、不确定性图随处可见； 4.4、项目既有目标值又有估算值，两者从不相同； 5.5、每个风险都有明确的转化指标； 6.6、有一个不间断监控风险转化指标的机制； 7.7、每项风险都有应急计划和缓解计划； 8.8、每项风险的暴露值都得到了计算； 9.11、

 1.1、通过风险发现过程调查得到项目面临的所有风险； 2.2、确认风险清单里已经包含核心风险； 3.3、初始化每项风险的属性； 4.4、指出致命风险并进行风险交接，作为项目假设； 5.5、假设没有任何风险具现，进行一次日程估算； 6.6、用风险图来描述风险，并量化其不确定性； 7.7、创建一个完整的WBS，并估算其工作量； 8.8、在项目初期，要求项目参与各方

量化不确定       顾问的一段话：听着，这个项目根本不可能在明年1月前完成，它的可能性为零，最有可能的时间是明年4月，但也不能打保票，你最高不要承诺在明年5月1日前的任何时间交付，你最好承诺在五月以后某个时间交付，这样你成功的概率在50%以上。最保守的是承诺明年12月前交付，那是一个不可能失败的日期!       软件产业的整体经验：不确定性的范围与N点前的时间之比介于1.5到2.0之间最

     我们的软件产品或者项目，其需求都有三个层级和三个方面。     一、我们首先看需求的三个层次          软件需求包括3个不同的层次――业务需求、用户需求和功能需求。　　业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开