近些年来，计算机工业的许多部分越来越强调软件质量的重要性。缺陷预防是其中一项最重要的活动，一个全球性
软件开发的生命周期，这已直接影响到控制项目的成本和高质量的成果。
缺陷预防涉及：
1）测试遭遇弊端。
2）缺陷分析，找出造成了这一缺陷发生原因
3）确保这些缺陷不会重演防治技术。
花费在产品调整上的缺陷要比花费在产品缺陷预防上的费用高的多。由于延误检测缺陷的增加，成本的确定缺陷指数增加。因此通常最明智的估量能尽早的阻止缺陷传入产品之中。这些措施的成本相比在较后阶段约解决这些缺陷是非常轻微的。 Syntel被定位在在第5级的过程成熟度在斯德哥尔摩环境研究所的CMM。所有实践都定义在5级的CMM模型，被应用在实施的每一项工程中。本文的目的是为了突出的缺陷预防和通过各种缺陷预防的活动的执行在syntel公司讨论的议题，在这个文件里包括：
● syntel的政策缺陷预防活动
● 缺陷防治数据记录
● 缺陷的测量与分析
● 缺陷防治技术
组织政策缺陷预防活动
按该组织的政策
- 在组织水平缺陷预防的小组管理缺陷预防活动。
- 在项目一级缺陷预防协调员一名，由项目经理管理预防活动。
- 缺陷预防小组确立了一个长远的计划，为缺陷预防活动。
- 结果，缺陷预防的活动，是审查高级管理人员，以监察其成效
符合该组织的政策， syntel有一个缺陷预防组，其具有代表性sepg （软件工程过程组）。
缺陷预防小组每季计划，其中规定了组织水平的目标，各项活动即将进行的，以实现这些目标。它也决定以何种报告需要产生什么度量需要加以监测。基于质量管理（量化管理）董事会的投入，缺陷预防局针对具体的地方它需要集中缺陷预防的活动。当前的目标是缺陷预防局定于9月
2001年是5％，减少缺陷密度近一个时期以来的3个月。缺陷防治数据记录
在项目一级，缺陷预防协调员是由项目经理来协调缺陷预防活动项目。缺陷预防协调员，是由受过训练的缺陷预防组和软件工程过程组开展缺陷预防的活动。
syntel采用同级审查过程，并据此同级审查所有可交付的程序。缺陷被查处在审查过程中，是登录到缺损登记（附录一）。
缺陷等级分类
1）在它们发生的阶段，（要求，设计，编码，测试等）。
2）严重（甲，乙，丙，丁）。每个严重等急被分配一个等级（A= 8 ，B= 4，C = 2D= 1 ）。
3）类型的缺陷。该缺陷被归类为每正交缺陷分类ibm公司为8个不同的类型，分别为：f -功能，A-委派，转让 ，I-界面，C-校验，B-构建，D-文档，G-逻辑/运算，T-定时
4）检测机构（内部，像同级审查，外部由一个机构对外向项目和客户，像客户机/客户）
缺陷测量与分析
在每一个月的月末，整理记录的缺陷和准备因果分析报告。所有缺陷预防协调员开展这一活动通过各自的项目。抽样的因果分析报告附后，在附录二。
由于某些原因（错误）的缺陷得到纳入该计划。经过分析引起这一缺陷源头，能为缺陷的预防行动提供解决的方案。这将减少以后发生的若干缺陷。在因果分析加权缺陷将每个缺陷类型列出。缺陷预防协调员，然后决定何种类型的缺陷，需要加以分析一个根本原因。这需要不是那种其中有尽可能多的缺陷的缺陷类型。之后，针对这类缺陷，一份详尽的根本原因分析被完成，同时开展和成因的缺陷检测。随后，以这种预防性行动的建议，以防止再次出现这种类型的缺陷。鱼骨/石川图，还可用作复杂的根本原因分析。
因果分析是做定期由缺陷预防协调员（使用帕累托图）每月一次，其中审查，交付管理和软件质量保证（软件质量保证）。结果预防/纠正行动进行审查，在未来几个月的因果分析和利益记下。
除了传达有关预防措施给项目小组，缺陷预防协调员也送因果分析报告给缺陷预防组，并讨论了这一问题在每月一次的月度会议。缺陷预防组，然后通过对预防行动针对所有其他项目。如果这些行动涉及任何改变组织的标准软件过程，他们转达了这一进程变革管理董事会通过正式的"过程改进的建议" 。缺陷预防组巩固了所收集的数据，从所有这些项目中分发预防行动建议在每月的董事局会议针对所有项目。
缺陷预防组也将准备每季成本效益分析和报告调查结果向首席运营官（首席营运官）。这种分析包括：
1）过去这段时期总结
2）每个小时付出的心血
3）实际上获得的具体的结果，在定量期而言
a）努力削减百分比
b）若干缺陷削减百分比
4）的无形利益，例如。客户反馈，员工反馈等。
5）具体的结果，预计在未来12个月的量化计算
缺陷防治技术
缺陷预防协调员主持每月团队会议，他在其中介绍了调查结果的因果分析报告。引起缺陷的原因被讨论同事预防方法在开发团队中分享。行动项目决定和责任都是固定进行采取这些行动。在每一个项目的开始阶段，或在项目启动会议上，缺陷预防协调员负责宣传预防行动建议在工程起始到整个项目团队。缺陷预防董事会每月都会审查和分析从各个项目收到的因果分析报告。所有的行动建议通过计划和预防度量被提交，随后缺陷预防委员会将对此计划进行分析。这项分析对于这个组织的水平的所有人员都很有用处。该项目可以分享信息和学习，并防止错误发生在其他项目。在项目组织实施的部分或全部行动的提案建议，由缺陷预防的董事会。缺陷预防董事会也可提出一些行动建议，作为试点的基础。
本月刊现况报告（组织广泛，缺陷因果分析报告），包括：
- 简要介绍了重大缺陷类型报告在本月份
- 取得的主要成就和成功执行行动中的缺陷预防
- 不完全行动建议的状态
观察到的好处：
1）清单，回顾有很大提高的事情。
2）重复工作已经减少。
3）严重的缺陷/程式已减少。
4）培训计划已见改善。
5）项目，目前正在以较低的缺陷，即使在较小的百分比经历资源。
结论
缺陷预防活动涉及
1）认识机制缺陷检测和预防。
2）知道如何搜集，分类和使用缺陷的信息。
3）申请地点吸取的教训。
4）根本原因分析
5）适用于缺陷预防过程。
今天
工作中碰见一件事情，让所有人都觉得有点郁闷。
我们产品是一个底层的安装框架，对上层要支持平台软件，再上层还要支持产品软件。每个都是独立开发，每个产品都定时在货架服务器上上传新的相对稳定的版本，来支撑其他子域的测试和验证，整大产品的主要客户是电信运行商，规模比较的大。
我们的产品应为涉及到很多个平台（linux，solaris，windows）且每种系统上还有多种不同特征的版本（单机双机多机....），一个正常的转测试流程下来，涉及到的测试场景有10多种，平均每个测试人员要分配2-3个场景，而且不包含各种专项测试，任务量比较繁重。
一般情况的转测试，都只使用平台软件来配合，不会涉及到产品软件，偶尔零星的也会使用产品包，如果涉及到产品包，我们就称之为“联调”。进这个项目三个月以来，只见过几次联调，每次都是那个几个老员工来做。
每次转测试的各种包，都是开发的CMO从货架拿版本然后再转到测试，经由测试经理和TSE制定好测试策略以后转发给测试员测试，整个流程测试人员基本不会接触到货架，虽然一开始测试经理一直在强调每个测试员都需要熟悉怎么从货架获取最新的版本，但是一直都没有特别的测试要求从货架取版本，再加上测试任务繁重，新进的测试人员基本都不知道如何从货架取其它域的软件包。
这次的转测试，是星期六早上，测试员需要花大约一天的时间来准备测试环境，迭代开发的原因，转测试流程非常紧凑。周一晨会，测试经理宣布本次测试的所有场景都需要联调，所有测试员都要从货架上获取版本。几经周折以后才发现，包括测试经理，TSE在内的10个人，只有3个会从货架取平台包，只有一个会取产品包。于是所有的测试进度都停滞，等待产品包。偏偏不巧，产品的货架包又存在不确定因素，需要和产品域的人沟通，而产品域的联系人正巧又在开会，于是整个测试进度从上午到晚上下班，一直停滞。
导致这个个时间的根本原因就是技能储备不充分，总结一下自己对这个事件的看法以及解决办法：
1、对于测试策略传达不到位；
测试经理在转测试之后的第二天晨会才开始说明本次测试的策略，及特别注意事项，这忽略了测试人员应对新的测试需求的学习期。
再转测试之前的一天或者转测试后的第一个例会上，测试经理应该明确的指出本次测试涉及到的场景，功能点，所需要的配套软件，任务分配，测试周期，测试注重点。需要注意新的测试需求是否每个测试员都能理解和操作，虽然此类文档在服务器上都有，但是每个人的理解都是不一样的，是需要测试经理做说明解释。如果有三成以上的测试员对新需求不理解，需要预留时间，并组织专项培训。确保每个测试员都能独立动手操作。
2、技能储备不即时，不充分；
之前的多轮转测试中，没有特别检验过一些必备的技能，是否每个测试员都具备。
在测试的过程中对于测试员技能的储备，是一项非常重要的工作，不能总之把希望寄托在测试员本身，必须要有一些方法来强制性的让测试员对测试过程中需要用到的测试技能充分理解和运用，比如定期的组织测试员在一起讨论，实现将测试所需技能按照优先级罗列，要求每个员工说出自己对技能的理解和运用。只有这样才能确保每个测试员都把基本的必备技能吃透，而不是莫林两可。
3、测试员对于学习缺乏主动性，存在依赖思想
测试员总是这么想：我只是个测试员，按照测试经理提出的要求做事情就是，不需要特别的去学习，就算在测试过程中遇到不懂的事情，还是可以找老员工帮忙解决。我在这里学到的业务知识，到下一个项目就完全没用了，所以没必要那么认真。
如果存在这种思想，那测试员就一直是测试员，不会有提升。不可能一辈子只做一个项目，所以总会有心的开始，业务知识带不走，但是学习知识的方式方法却可以带走。只有经历这个学习业务的过程，你才能发现自己适合什么样的学习方式。如果养成了一个良好的学习习惯，无论做什么项目，你都会是优秀的。还有要相信一个道理，除了自己以外谁都靠不住，因为这个世界，你能控制的就只有你自己。
以上言论属个人想法，仅供参考。
出色的软路由系统ClearOS
对于中小企业来说，有很多免费且开源的路由器和防火墙解决方案，甚至可以作为企业的选择。这类产品中，很多都提供局域网服务，如VPN服务、热点网关和通过强制网络门户以共享无线网络。
这里，编者发现了一些开源且免费的路由器项目，这些产品适合于包括小企业、中型、甚至与思科和Juniper规模相当的企业。闲言少叙，我们一起看看这七款开源且免费的Linux下的网络操作系统。
出色的软路由系统ClearOS
ClearOS是一款基于CentOS和Red Hat Enterprise Linux，主要面向中小企业和分布式环境而设计的网关和网络服务器。ClearOS是一款出色的软路由系统，具备现有路由系统的大部分功能，如DHCP，端口转发，防火墙等。同时因为它基于Red Hat，能提供良好的功能扩展支持。
ClearOS
ClearOS由ClearFoundation开发与支持，是开源和免费的，用户可以从它的官网免费下载使用；如果是用于商业目的，ClearCenter保留收费的权利。
ClearOS Enterprise是一套服务器、网络和网关平台，它面向小型公司及分布式企业环境而设计。ClearOS Enterprise基于ClearOS Core，后者是Red Hat Enterprise Linux的改造。该发行灵活并且包含了大量的组件及集成服务，它们可以通过一份基于网页的界面来配置。
ClearOS Enterprise中的工具有反病毒、反垃圾邮件、虚拟专用网、内容过滤、带宽管理、文件服务器、电子邮件服务、打印服务、SSL证书、网页服务。ClearOS包含了一个电子集散中心，以简化包含第三方模块在内的软件安装。该发行通过免费下载提供，并且只要免费注册就能获取基本操作系统的更新。
基于Linux的无线路由软件DD-WRT
DD-WRT是一个基于Linux的无线路由软件，基于GPLV2发布。DD-WRT起源于2003年，它提供了许多一般路由器的韧体所没有的功能，例如支持XLink Kai游戏协议、基于守护进程的服务、IPv6、无线分散式系统(无线网桥和无线中继)、RADIUS、先进服务质量控制、无线输出功率控制、超频能力以及SD卡的硬件配置提供软件支持。
DD-WRT是一种可用于某些无线路由器的非商业的第三方固件，功能强大，可以提供很多"原版"路由器不支持的功能，如调整无线发射功率等。DD-WRT固件由BrainSlayer维护，放在dd-wrt.com。从第一个版本直至V22版本都是基于Sveasoft Inc公司的Alchemy开发出来，而Alchemy又是基于以GPL发放之Linksys固件及许多其它开放源程序。由于后来人们需要向Sveasoft支付$20才能下载Alchemy固件，于是从V23开始的DD-WRT几乎完全重写，linux核心部分基于OpenWrt核心。
DD-WRT
从本质上说，DD-WRT其实就是一个供无线路由器使用的嵌入版Linux，它可以在普通的家用无线路由器实现数千元的商用无线路由器功能，不仅如此，对于高手它甚至可以允许自行编译程序，自由扩展无线路由器功能。
DD-WRT的优点确实有很多，它具有友好的Web管理/配置界面，支持多语言（包括简体中文），可以让无线路由器支持QoS宽带设置、QoS L7过滤，优化带宽并限制最大上行、下行速度和最大连接数等，并可以封杀或者加速BT、电驴下载。支持多种客户端连接模式，如网桥、中继、客户端等模式。支持数种安全机制，支持客户WPA模式、VLAN、WPA2等安全模式和机制。还支持花生壳的DDNS，方便建立个人网站。它甚至有改造后的直接BT下载功能。
网络服务系统Zeroshell
Zeroshell是一款面向服务器和嵌入式设备的小型Linux发行版，其目标是提供网络服务系统。它可以通过自启动运行光盘或紧凑式闪存镜像的形式获得，并且可以用网页浏览器来配置。
Zeroshell
那么，总的来说Zeroshell的特性包括：负载均衡及多网络连接的失效转移，通过3G调制解调器的UMTS/HSDPA连接，用于提供安全认证和无线网络加密密钥自动管理的RADIUS服务器，用于支持网页登录的强制网络门户，以及很多其他内容。
路由操作系统RouterOS
RouterOS是一种路由操作系统，并通过该软件将标准的PC电脑变成专业路由器，在软件RouterOS 软路由图的开发和应用上不断的更新和发展，软件经历了多次更新和改进，使其功能在不断增强和完善。特别在无线、认证、策略路由、带宽控制和防火墙过滤等功能上有着非常突出的功能，其极高的性价比，受到许多网络人士的青睐。
RouterOS
RouterOS能将多张网卡组建为一个桥模式，是路由器变成一个透明的桥设备，同样也实行三层交换的作用，MAC层的以太网桥、EoIP 、Prism、Atheros和RadioLAN等都是支持的。
所有802.11b和802.11a 客户端的无线网卡（如station模式的无线）受802.11 的限制无法支持桥模式，但可以通过EoIP协议的桥接方式实现。为防止环路出现在网络中，可以使用生成树协议（STP） ，这个协议同样使冗余线路成为可能。
RouterOS在应用领域可以包括网吧、企业、小型ISP接入商、社区等地域网络设备的接入，基于标准的x86构架的PC。甚至是一台586的PC机就可以实现路由功能，提高硬件性能同样也能提高网络的访问速度和吞吐量。完全是一套低成本，高性能的路由器系统。
开源网关软件Untangle
Untangle Gateway是一款Linux下的开源网关软件，带有可插拔的模块以支持各种网络应用，能够支持垃圾邮件过滤、URL阻截、网页过滤、反病毒、反间谍软件、反病毒蠕虫、入侵阻止、虚拟专用网、SSL虚拟专用网、防火墙等多种功能。
Untangle
并且，除了一般的局域网服务，Untangle还免费提供隔离垃圾邮件、广告、恶意软件、入侵保护以及OpenVPN和强制网络门户等。同时，Untangle还增加网络包过滤、提高恶意软件的保，IPsec VPN以及广域网平衡和故障排除等功能。
Untangle同时又是一个支持中文的开源操作系统，可以安装和运行在pc机和基于X86的PC机和服务器上。它可以作为你的网络路由器和防火墙提供服务，或运行于你现有的路由器作为一个透明网桥。
Linux安全发行版本Endian
Endian Firewall是一个功能齐全的Linux安全发行版本，它保护网络安全并改善连接性能。
Endian操作简单，配置主要通过web界面进行，即刻生效。并且，Endian对硬件条件要求很低：x86兼容机、500MHz处理器、256MB内存和4GB磁盘空间即可安装使用。
Endian新版本
Endian可以将每一种系统变成一个功能齐全的安全设备，并拥有UTM的功能。基于Red Hat Enterprise Linux的Endian Firewall百分之百地源码开放，其还包括多种功能部件，例如状态检测防火墙、HTTP/FTP病毒防护、内容过滤、POP3/SMTP病毒防护、反网络钓鱼和反垃圾邮件工具、SSL/TLS虚拟专用网、入侵检测系统、状态数据包检测防火墙、多种协议（HTTP、FTP、POP3、SMTP）的应用程序级代理、反病毒和垃圾邮件过滤、Web通信过滤和VPN等功能。
最新版Endian添加了一个基于Web的管理控制台、OpenVPN服务器可运行在独立的区域中以及可正常过滤日文的垃圾邮件等。
路由系统Vyatta
Vyatta是一款可以帮助企业快速设置路由的路由系统。Vyatta的软件基于使用可扩展开放路由平台(XORP)开发的代码，此平台从2002年开始成为一个开源路由器软件项目。
Vyatta的代码将经过修改的Linux操作系统与XORP结合在一起。用户可通过从该公司的网站下载CD映像并将其安装在PC 硬件上来构建Vyatta路由器。Vyatta一直与Sangoma等合作伙伴合作，后者制造用于x86 PC系统的T-1和T-3 WAN接口卡，Vyatta还计划很快宣布更多的硬件合作伙伴。
Vyatta
而Vyatta同时也是一家开源技术公司，其目前的任务是将XORP(可扩展开源路由器平台)带入商用领域，使得它成为一款企业级的开源路由器软件。
Vyatta OFR可代替有上千个用户的小型企业的商业路由器。Vyatta路由器代码的开源特性可供公开审查及检查代码中潜在的错误及漏洞，这使得它比其他商业化产品更安全。Vyatta OFR软件可从Vyatta公司的网站www.vyatta.com下载。
由于中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：
1、完全检查点
在Oracle8i之前，数据库的发生的检查点都是完全检查点，完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，并且同步数据文件头和控制文件，保证数据库的一致。完全检查点在8i之后只有在下列两种情况下才会发生：
（1）DBA手工执行alter system checkpoint的命令；
（2）数据库正常shutdown（immediate,transcational,normal）。
由于完全检查点会将所有的脏数据库块写入，巨大的IO往往会影响到数据库的性能。因此Oracle从8i开始引入了增量检查点的概念。
2、增量检查点
Oracle 从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息，DBWR 根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息，里面的条目包含RBA（Redo Block Address，重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号）和数据块的数据文件号和块号。在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后，检查点的位置也要相应地往后移，CKPT每三秒会在控制文件中记录检查点的位置，以表示Instance Recovery时开始恢复的日志条目，这个概念称为检查点的“心跳”（heartbeat）。检查点位置发生变更后，Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是，多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的，这4个参数是用于控制检查点队列里面的条目数量，而不是控制检查点的发生。
（1）fast_start_io_target
该参数用于表示数据库发生Instance Recovery的时候需要产生的IO总数，它通过v$filestat的AVGIOTIM来估算的。比如我们一个数据库在发生Instance Crash后需要在10分钟内恢复完毕，假定OS的IO每秒为500个，那么这个数据库发生Instance Recovery的时候大概将产生500*10*60=30,000次IO，也就是我们将可以把fast_start_io_target设置为 30000。
（2）fast_start_mttr_target
我们从上面可以看到fast_start_io_target 来估算检查点位置比较麻烦。Oracle为了简化这个概念，从9i开始引入了 fast_start_mttr_target这么一个参数，用于表示数据库发生Instance Recovery的时间，以秒为单位。这个参数我们从字面上也比较好理解，其中的mttr是mean time to recovery的简写，如上例中的情况我们可以将fast_start_mttr_target设置为600。当设置了 fast_start_mttr_target后，fast_start_io_target这个参数将不再生效，从9i后 fast_start_io_target这个参数被Oracle废除了。
（3）log_checkpoint_timeout
该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为单位，默认情况下是1800秒。
（4）log_checkpoint_interval
该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS块表示。
（5）90% OF SMALLEST REDO LOG
除了以上4个初始化参数外，Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。
oracle 9i instance recovery
1、增量检查点
在checkpoint queue的基础上实现了增量检查点，每3秒发生一次checkpoint heartbeat，记录dbwr上次写成功的最大RBA(redo block address)。这样的话做instance recovery的时候就从这个rba开始，而不是从上次checkpoint scn开始，大大节省了恢复时间。
2、twice scan of redo log
在应用redo之前，redo将会被操作两次，第一次去扫描哪些redo record需要被应用，因为9i在redo里添加了dbwr写数据块的信息，所以dbwr发生前的日志将不会被应用。第二步就是选出需要被应用的日志然后开始rollforward。
3、rollforward
在做instance recovery时必须先定位到redo log 然后应用所有日志到datafile，这时候包括了committed和uncommitted的数据。当做完rollward，数据库就可以open了。
4、rollback
因 为rollforward产生了uncommitted数据，所以必须回滚这些数据。这将由smon和on-demand rollback来实现。smon将会扫描undo segment header去标志所有活动事务为dead，然后会逐渐去回滚这些事务。另外on-demand rollback提供了前台进程进行rollback，当前台进程企图获得被dead事务占用row lock，这时候前台进程将会去undo segment取得before image去回滚这个块，至于其他被这个dead事务lock的块就等待smon去回滚。
另外，如果 在数据库打开的过程中process crash导致transaction dead，resource不能被释放的情况，这时候如果另一个进程需要这些resource，那么这个进程将会等待直到pmon清理dead process释放出resource。
如果数据库Crash，重新启动，很久远以前的未提交事务并不在Redo的恢复序列中。
但是未提交事务一定在回滚段事务表上存在，并且State＝10，为活动事务。这就够了。
数据库启动之后，这些事务会被SMON逐个标记为Dead（不可能再活过来了），然后由SMON慢慢去回滚这些事务；也存在另外一种情况，后来的进程会去读这些未提交数据，发现Dead事务未提交，则主动进行回滚。
1、一个数据块发生更新，必然写回滚
2、回滚段的block变化也记录在redo中
一份未提交的数据必定在回滚中有相应的前镜像，任何正常的恢复都一定会把这些变化重新构建出来。
想像一下
1、update事务1更新了block 1
2、回滚段1记录了block1的前镜像
3、checkpoint
4、update事务2更新了block2
5、回滚段2记录了block2的前镜像
6、instance crash
现在重启数据库
1、根据redo重新构建block2
2、根据redo重新构建回滚段2
3、database open
4、SMON用回滚段2的数据回滚block2，SMON用回滚段1的数据回滚block1
最后一步也可能是
在另外一个select检索到block1或者block2的时候，发现这两个block的数据都是未提交的，此时再回滚block1和block2。
所以，只要有相应的回滚数据存在，无论什么时候oracle都可以找到一致的数据，oracle只需要知道这个事务是提交了的还是没提交了的，而这点在block header ITL中有记录。
很久没有积累东西了，碰巧前几天遇到一个的问题，虽然不大但是比较有意思，在这里稍微记录一下，以后可以作为
面试题之类的考验
其他人，想想也远比那些被我们诟病的题目要实际的多：
有表结构如下：
| T_SOME_TABLE{ crowid varchar(36); zrmb float(7,3); zjdw float(7,3); } |
问以下两段代码，哪段会出现错误，为什么？
代码片段一：
| String hqlStr="select SUM(t.zrmb) AS SUM_1,SUM(t.zjdw) AS SUM_2 from T_SOME_TABLE t where 1=1 "; List sumList=baseDao.find(hqlStr); request.setAttribute("sumList",sumList); String sum1=""; String sum2=""; ArrayList sumList=request.getAttribute("sumList")==null?null:(ArrayList)request.getAttribute("sumList"); if(null!=sumList){ for(int i=0;i<sumList.size();i++){ Object[] tempObj=(Object[])sumList.get(i); sum1=tempObj[0]==null?"0.0":tempObj[0].toString(); sum2=tempObj[1]==null?"0.0":tempObj[1].toString(); } } out.prinln("sum1:"+sum1); out.prinln("sum2:"+sum2); |
代码片段二：
| String hqlStr="select SUM(t.zrmb) AS SUM_1 from T_SOME_TABLE t where 1=1 "; List sumList=baseDao.find(hqlStr); request.setAttribute("sumList",sumList); String sum1=""; ArrayList sumList=request.getAttribute("sumList")==null?null:(ArrayList)request.getAttribute("sumList"); if(null!=sumList){ for(int i=0;i<sumList.size();i++){ Object[] tempObj=(Object[])sumList.get(i); sum1=tempObj[0]==null?"0.0":tempObj[0].toString(); } } out.prinln("sum1:"+sum1); |
实际运行会发现 代码片段2会出现错误 而代码片段1是正常可以运行的，这里是在功能开发过程中 片段2是在片段1的基础上惯性思维去实现的，而实际运行却会发现 结果并不是想要的那样，这个动手能力强的人可以实际调试一下就会很快明白里面的所以然。这里简单说一下：
做过hibernate的人都知道 用hibernate调用sql查询出的汇总语句，返回的结果是封装成Object的保存到List中的，而代码1和代码2相比较，差别只是在字段的多少上，如果是2个以上的字段 结果是封装成Object[]数组的，这个无可争议，但是如果是一个字段的话List里保存的是Object，而不是Object[]数组。
这样就可以推论这里hibernate内部是做了处理的。
代码2循环中应该是：
| Object tempObj=(Object)sumList.get(i); sum1=tempObj==null?"0.0":tempObj.toString(); |
微软产品开发中的“战争与和平”
冲突是微软开发工作时的常态，每个微软新产品的孕育过程概莫能外地充斥着质疑、抗争、苦闷、忐忑……理念的交击、智慧的冲撞让软件开发的各个阶段都弥漫着硝烟，直至产品发布，然后又要迈入下一个循环。对于微软工程师们来说，这样的经历就仿佛是一次次痛苦但不乏惊喜的涅槃。
这篇博客记录了微软Windows Server 2008 R2*中国团队的一些真实经历与感悟，例如“暗藏杀机”的季度性产品评审会议；微软工程师如何“向用户学习”；软件开发过程中只有对错、没有“权威”……
*Windows Server 2008 R2是与Windows 7同步研发、同时面世的微软新一代服务器操作系统。
Windows Server 2008 R2今天在北京正式发布，由我们负责开发的Active Directory Administrative Center（活动目录管理中心，以下简称“ADAC”）也将真正开始接受IT管理员们的检验。
为迎接这一天，我们准备了非同寻常的一年半。有过重重压力，有过混乱无序，甚至怀疑过这是否是“不可能完成的任务”。而当Windows Server 2008 R2预发布版本问市后，美国权威IT技术信息杂志《Windows IT Po》在一篇新功能点评文章中，将ADAC评价为最受关注新功能第一名，这让我们高兴了好一阵子——我们收获的不仅仅是一件令团队成员自豪的产品，更重要的是，我们证明了中国研发团队的能力。
在我们在踏上新的征程之时，谨以三个幕后故事来记录我们的努力和过往那些“硝烟弥漫”的日子。
测试主管Jun的故事：从虚无缥缈到事实
Windows Server 2008 R2即将发布第一个测试版时，Jun正在美国参加一个季度性产品评审会议。当时，他的测试团队因为对ADAC采取了与美国不一样的测试策略，在产品开发前期更激进地寻找bug，最后挖出了538个，“荣登”活动目录整个产品线所有新旧产品bug数榜首，并几乎与“活动目录”其他产品的总bug量相当——作为团队代表，如果Jun无法让管理层信服，整个中国开发团队能够在Windows Server 2008 R2发布前解决这些问题，那么这个项目很可能会被砍掉，这意味着十多位工程师一年多的努力将化为泡影。
当Jun不厌其烦地阐述、分析，并反复强调ADAC一定能够和Windows Server 2008 R2一起发布的时候，“活动目录”产品线的总经理，一位白胡子老者（真的很像圣诞老人）笑眯眯地转过头说：“你知道在英语中我如何来描述你的结论（可以和Windows Server 2008 R2 一起发布）吗？我比较喜欢这个单词：illusion （虚无缥缈）”。
那一刻，虽然Jun嘴上依然挂着笑容，但是阵阵冷汗已在后背泛起… …在强迫自己冷静之后，Jun回答道：“我们看到的不只是静态的数据，还是一个发展的趋势，基于bug数量递减的速度和趋势，我依然有信心，我们能够完成这一产品。”
知道是被中国团队的执着所打动，还是真的相信了Jun的“趋势论”，总之“圣诞老人”在会后并未将这个项目从Windows Server 2008 R2里砍去。但他设置了一个非常严格的时间表，要求中国团队在相应时间内将bug数量降低到可控的范围之内。像很多故事一样，不懈努力的结局是美好的。最终，Jun的测试团队因为出色的表现（自动化测试的稳定性和测试的代码覆盖率都超过了微软的标准）而受到了“圣诞老人“的特别肯定。
开发人员Elfe的故事：用户是最好的老师
在产品开发过程中，开发、测试人员和项目经理之间常常会有很多的争论：争论产品的某一表现究竟是错误还是本该如此的特性；受时间所限，开发人员不可能修正所有的bug，因此对于bug大家会争论它的严重程度与优先级，以决定是否需要修正。有时候实在是各有各的理，谁都说服不了谁，问题就只能暂时搁置。
当产品第三个里程碑结束时，用户体验小组邀请了几位IT管理员用户，请他们在产品上完成拟定的几项操作任务。用户体验小组架起了三个摄像头，分别对着电脑屏幕、鼠标与用户的脸部，通过录像分析用户执行任务的顺利程度，以衡量产品的设计。研究结束后，用户体验小组给所有开发团队发了长长的报告，列出产品所有成功与失败的地方；此外还精选了一部分录像供大家参考。
录像中是一张张困惑、受挫、惊奇甚至绝望的脸。有用户在一个没有提示的输入框里进行了十几次尝试却无一成功；有用户对一条简略的出错报告信息上天入地怎么都找不到错误的具体原因；有用户成功执行了操作却因界面未及时刷新而停在那里苦苦等待；有用户误操作不可恢复地删除了重要数据，把嘴张成O形呆坐在那里。
这些录像就像整蛊视频一样，实在是搞笑。在镜头前，可怜的IT管理员们就像不知情的被整对象手足无措。大家看得乐呀——“这么简单的事他们怎么就不会呢？”
但在笑过之后，大家又都脸上发烧：这可都是因为我们的错啊。赶紧回头找找，为什么有些问题我们在设计时没能考虑到，为什么有些bug我们没能发现，为什么有些bug我们会认为无关紧要而不去修正。用户是最权威的裁判，告诉了我们什么是对什么是错。
开发人员 Elfe 感叹：“此后每有争论，我脑海中就会出现用户那张绝望的脸。于是，慎重地从用户角度来考虑事情，而不敢为了追求进度推诿掩藏问题。用户的受挫体验，给我上了最生动的一课。”
测试人员Li的故事：不惧权威的质疑
除了开发新一代的活动目录管理工具外，中国团队还要维护一个从Windows NT4开始，被一代又一代的管理员沿用了十多年传统管理工具。确保它能在Windows Server 2008 R2上稳定运行，是一项至关重要的任务。
项目开始不久，Li就发现旧工具上的一个右键菜单项未作任何改动就莫名其妙失踪了！检查相关代码后也没有发现什么异常。这难道是其它小组的代码改动所致？虽然中国团队只负责ADAC的开发，但是同样有权限查阅和修改Windows的任何代码。没有理由说怀疑上述问题是别人导致的就放任不管。既然有了代码，Li就主动请缨负责寻找问题的根源。在结合多种排错手段后，终于把问题定位到美国团队负责的界面代码中。
接下来，Li把问题描述、对应的代码、代码修改前后的比较和逻辑分析发给了相应的美国团队。对方很快就着手分析，一名合伙人级别的开发工程师（微软某产品线或技术的首席代表）为此发信询问更详细的来龙去脉。他坚持认为，根据他原先的设计，相应的问题是不应该出现的，他怀疑是我们团队工程师的不当调用造成的——但Li并没有因为对方是“权威”而放弃质疑。他再次回信分析，最终说服了美国同事在相应的组件中修正了错误，消失已久的右键菜单项又恢复如初了。
类似的情景，在服务器与开发工具事业部中国团队，在整个微软中国研发集团，每天都在上演且永远不会结束。驱策我们不断克服困难、努力前行的动力是身为中国软件工程师的责任感和以创新影响全球用户的成就感。
一地鸡毛——软件项目中的人际困局
作者结合切身经历，展示了他之前所在团队软件项目延期的种种原因，而其中印象最深刻的是各种人事纷扰乃至于勾心斗角。
六年前，毕业未久的我在一家外企工作，我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周。这本身根本不是什么大事情，但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻。
公司
我的老东家是一家大型跨国电信设备开发商，曾具有辉煌的历史。我还记得在公司110周岁的生日庆典上，一位高管致辞说：“110年，这不是奇迹，是成绩”，令人不胜欷歔。遗憾的是，公司在.com泡沫中遭遇重创，一蹶不振。时任CEO为求摆脱困境，打起了人力成本的主意。当时，公司在美国雇用一名工程师的综合人力成本接近中国的2.5倍【注：工资只是其中一小部分】。至于法国，成本比美国还要略高一些，而且不要忘了，人家可是35小时工作周。大家都是聪明人，很快就看到端详：公司正在法国裁员，将项目转移到中国。
令人尴尬的是，我所在的中国团队恰好就在与法国团队合作。这一项目最早完全在法国，此后几年时间，中国团队大规模扩张人手（我就是这样进来的），将项目模块逐一从法国团队手中接过来。刚开始，法国工程师将原先的模块移交中国之后，便转而从事其他项目或职位，谈不上什么个人损失，双方共事可谓融洽。后来可就不是这么回事了。有一次，两位中国工程师去巴黎接手一个项目，一位法国工程师负责培训，为时2~3个月。在这位法国老师兢兢业业的帮助下，两位中国工程师成功掌握整个模块，按期于圣诞节前夕归国。告别巴黎时，没有一个法国同事去跟他们寒暄话别—那位法国老师被裁掉了，他的最后一个工作日恰好就在两位中国工程师离开的同一天，法国同事都去送他了。
到发生本文将要详述的交付延期之时，所有模块的开发工作都已从法国团队移交到中国团队，而集成测试虽然仍由法国团队负责，但从法国到中国的移交也已开始。不妨猜猜看，法国集成测试团队的工程师们此刻在想些什么。
团队
我很幸运，毕业后初入职场就遇到一位好经理H，坦率地说，她也是我到目前为止跟随过的几位经理中最好的一位。中国很多女经理都有一个共同的特点：没有私心。她们对于自己的晋升、提薪并无多大热情，更愿意把心思、时间和精力花在辅导和培养自己的团队上面。
H因分娩而“暂时”离开我们团队。经过短暂的过渡，接任我们经理的是T，一位新近招聘的职业经理人。他的风格与H大为不同。仅举一例说明。当年向H请一天年假，她总是微笑着说：“没问题。不影响工作吧？”T则会端起架子：“不影响工作吧？没问题。”语序上的变化，加上语气的差别，虽然只是细微末节，却反映了态度的不同、对员工是否尊重。除此之外，更严重的是工作态度问题。现在我们知道，T在北京待了不到一年时间，买下两套房、一辆车，还办妥了到加拿大的移民和那边的工作—而在当时，我们这些员工仅仅只是知道，我们的经理不太在办公室出现。
在团队内部，我所在的FM小组与另一个CM小组工作是紧密衔接的。但在CM小组的核心员工之间却存有罅隙：小组长B与技术骨干S矛盾日增。怎么说呢，这两位都是很好的同事，然而好人之间也会彼此鄙视的：S认为B不懂技术，瞎指挥；B认为S目空一切，难以共事。缺少一位好领导来调和，好员工也不能组成一个好团队。
流程
我们开发的是一个庞大的电信软件项目—3G接入网网管系统，采用的开发流程仍然是传统的瀑布式。简单来说，依时间顺序，一个软件工程师（首先是各小组的小组长）需要依次参与以下几个阶段。
需求阶段：跟踪和审阅由系统架构师撰写的需求文档，必要时要求澄清，然后预估工作量，经理据此调整人员安排。
设计阶段：分析需求文档，完成模块设计，据此撰写高层设计文档和底层设计文档，前者以定义模块接口为主，后者则涉及更多细节。
编码阶段：根据两份设计文档完成实际编码工作。
单元测试阶段：是的，你没有看错。根据本部门正式的、成文的流程，单元测试阶段在编码阶段之后安排时间进行。在实践中倒是没有这么僵化，大家尽可以测试先行，只要时间大致齐即可。
各开发团队在完成各自负责的一或多个模块的单元测试之后，将代码提交到统一的代码库，打上标签，然后将这些标签连同其他注意事项写成文档保存到指定目录。其后，就是集成测试阶段了—集成测试团队收集所有团队的所有标签，从代码库提出相应的代码进行编译，编译成功后即按照事先准备的测试用例进行测试，给开发团队提Bug。
我参与了前面几个版本3.X、4.0的开发，仅从技术角度而言，瀑布式开发流程工作得尚称流畅。但工程师是要领工资的，软件写出来是要卖钱的，一套经典的瀑布式流程走下来往往耗时几个月甚至年余，等到软件产品正式发布，用户需求已然发生变化，这怎么赶得上趟呢。公司不是没有意识到这一问题，但舍不得做伤筋动骨的巨变，只愿意在现有流程上做一些微调，效果甚微。
有一个例子很能说明问题。当时，中国的销售部门向总部反映，我们在中国市场遭遇到本土厂商的强力阻击，要想争夺中国市场，就必须在定制化方面下更大工夫。在大中华区乃至总部高层的大力支持下，我们部门成立了一个“快速特性”开发小组，专门根据中国客户的需求为我们的产品添加相应的特性。有一个快速特性是这样的：本来，我们的网管系统会在电脑屏幕上显示一台虚拟的机器，如果某个部件坏了，代表该部件的绿灯就会变成红灯并开始闪烁，提醒操作员注意。中国客户看过演示后说不错，但光红灯闪烁还不够，还应该放点儿警报声出来，不然操作员离开座位了怎么办。我们的销售一口答应下来。猜猜这个特性我们做了多久才交付给客户？三个月！这就是瀑布式流程下的“快速特性”！（当然，中国的销售部门和开发部门分别向国外的上司汇报，由老外负责协调中国的事情，这也是造成拖延的一个同等重要的原因。）
这样拖拖沓沓做出来的产品，其销路如何不问可知。公司应对的办法，就是一方面推新版本、新特性来吸引客户，另一方面强调开发速度的重要。很显然，这两者之间存在矛盾：新特性越多，开发时间就越长，客户不会买账；可是如果新特性太少，跟上一版本差异不大，客户同样不会买账。
作者结合切身经历，展示了他之前所在团队软件项目延期的种种原因，而其中印象最深刻的是各种人事纷扰乃至于勾心斗角。
六年前，毕业未久的我在一家外企工作，我所在团队开发的软件项目在交付到集成测试组时因种种原因延期一周。这本身根本不是什么大事情，但其间各种人事纷扰乃至于勾心斗角却着实令我印象深刻。
公司
我的老东家是一家大型跨国电信设备开发商，曾具有辉煌的历史。我还记得在公司110周岁的生日庆典上，一位高管致辞说：“110年，这不是奇迹，是成绩”，令人不胜欷歔。遗憾的是，公司在.com泡沫中遭遇重创，一蹶不振。时任CEO为求摆脱困境，打起了人力成本的主意。当时，公司在美国雇用一名工程师的综合人力成本接近中国的2.5倍【注：工资只是其中一小部分】。至于法国，成本比美国还要略高一些，而且不要忘了，人家可是35小时工作周。大家都是聪明人，很快就看到端详：公司正在法国裁员，将项目转移到中国。
令人尴尬的是，我所在的中国团队恰好就在与法国团队合作。这一项目最早完全在法国，此后几年时间，中国团队大规模扩张人手（我就是这样进来的），将项目模块逐一从法国团队手中接过来。刚开始，法国工程师将原先的模块移交中国之后，便转而从事其他项目或职位，谈不上什么个人损失，双方共事可谓融洽。后来可就不是这么回事了。有一次，两位中国工程师去巴黎接手一个项目，一位法国工程师负责培训，为时2~3个月。在这位法国老师兢兢业业的帮助下，两位中国工程师成功掌握整个模块，按期于圣诞节前夕归国。告别巴黎时，没有一个法国同事去跟他们寒暄话别—那位法国老师被裁掉了，他的最后一个工作日恰好就在两位中国工程师离开的同一天，法国同事都去送他了。
到发生本文将要详述的交付延期之时，所有模块的开发工作都已从法国团队移交到中国团队，而集成测试虽然仍由法国团队负责，但从法国到中国的移交也已开始。不妨猜猜看，法国集成测试团队的工程师们此刻在想些什么。
团队
我很幸运，毕业后初入职场就遇到一位好经理H，坦率地说，她也是我到目前为止跟随过的几位经理中最好的一位。中国很多女经理都有一个共同的特点：没有私心。她们对于自己的晋升、提薪并无多大热情，更愿意把心思、时间和精力花在辅导和培养自己的团队上面。
H因分娩而“暂时”离开我们团队。经过短暂的过渡，接任我们经理的是T，一位新近招聘的职业经理人。他的风格与H大为不同。仅举一例说明。当年向H请一天年假，她总是微笑着说：“没问题。不影响工作吧？”T则会端起架子：“不影响工作吧？没问题。”语序上的变化，加上语气的差别，虽然只是细微末节，却反映了态度的不同、对员工是否尊重。除此之外，更严重的是工作态度问题。现在我们知道，T在北京待了不到一年时间，买下两套房、一辆车，还办妥了到加拿大的移民和那边的工作—而在当时，我们这些员工仅仅只是知道，我们的经理不太在办公室出现。
在团队内部，我所在的FM小组与另一个CM小组工作是紧密衔接的。但在CM小组的核心员工之间却存有罅隙：小组长B与技术骨干S矛盾日增。怎么说呢，这两位都是很好的同事，然而好人之间也会彼此鄙视的：S认为B不懂技术，瞎指挥；B认为S目空一切，难以共事。缺少一位好领导来调和，好员工也不能组成一个好团队。
流程
我们开发的是一个庞大的电信软件项目—3G接入网网管系统，采用的开发流程仍然是传统的瀑布式。简单来说，依时间顺序，一个软件工程师（首先是各小组的小组长）需要依次参与以下几个阶段。
需求阶段：跟踪和审阅由系统架构师撰写的需求文档，必要时要求澄清，然后预估工作量，经理据此调整人员安排。
设计阶段：分析需求文档，完成模块设计，据此撰写高层设计文档和底层设计文档，前者以定义模块接口为主，后者则涉及更多细节。
编码阶段：根据两份设计文档完成实际编码工作。
单元测试阶段：是的，你没有看错。根据本部门正式的、成文的流程，单元测试阶段在编码阶段之后安排时间进行。在实践中倒是没有这么僵化，大家尽可以测试先行，只要时间大致齐即可。
各开发团队在完成各自负责的一或多个模块的单元测试之后，将代码提交到统一的代码库，打上标签，然后将这些标签连同其他注意事项写成文档保存到指定目录。其后，就是集成测试阶段了—集成测试团队收集所有团队的所有标签，从代码库提出相应的代码进行编译，编译成功后即按照事先准备的测试用例进行测试，给开发团队提Bug。
我参与了前面几个版本3.X、4.0的开发，仅从技术角度而言，瀑布式开发流程工作得尚称流畅。但工程师是要领工资的，软件写出来是要卖钱的，一套经典的瀑布式流程走下来往往耗时几个月甚至年余，等到软件产品正式发布，用户需求已然发生变化，这怎么赶得上趟呢。公司不是没有意识到这一问题，但舍不得做伤筋动骨的巨变，只愿意在现有流程上做一些微调，效果甚微。
有一个例子很能说明问题。当时，中国的销售部门向总部反映，我们在中国市场遭遇到本土厂商的强力阻击，要想争夺中国市场，就必须在定制化方面下更大工夫。在大中华区乃至总部高层的大力支持下，我们部门成立了一个“快速特性”开发小组，专门根据中国客户的需求为我们的产品添加相应的特性。有一个快速特性是这样的：本来，我们的网管系统会在电脑屏幕上显示一台虚拟的机器，如果某个部件坏了，代表该部件的绿灯就会变成红灯并开始闪烁，提醒操作员注意。中国客户看过演示后说不错，但光红灯闪烁还不够，还应该放点儿警报声出来，不然操作员离开座位了怎么办。我们的销售一口答应下来。猜猜这个特性我们做了多久才交付给客户？三个月！这就是瀑布式流程下的“快速特性”！（当然，中国的销售部门和开发部门分别向国外的上司汇报，由老外负责协调中国的事情，这也是造成拖延的一个同等重要的原因。）
这样拖拖沓沓做出来的产品，其销路如何不问可知。公司应对的办法，就是一方面推新版本、新特性来吸引客户，另一方面强调开发速度的重要。很显然，这两者之间存在矛盾：新特性越多，开发时间就越长，客户不会买账；可是如果新特性太少，跟上一版本差异不大，客户同样不会买账。
之前把软件工程中的
测试部分，文档管理部分都已经做了一些简单的介绍，因为都是我实际
工作中经常接触的，所以也算是我的一些经验吧，不过我也不是每个部分都接触得很深入，总是有些地方讲得不太好的，也请大家谅解，希望大家能提出宝贵经验，呵呵。
下面是之前讲过部分的链接（点击就可以访问），如果之前没看过我的文章的话，有空可以看看。
1、【浅谈在软件开发中的开发与测试】
2、【敏捷测试理论以及实践】
3、【谈软件开发过程管理系统、版本控制系统及它们之间的集成】
4、【文档管理】
但是软件工程中除了我已经讲过的部分，其实还有几个部分还没讲了，因为我们公司是用 TechExcel 的 DevSuite 系统的，所以还是借用他们的软件工程过程图来给大家讲一下。
看下图，之前讲了知识管理（文档管理），测试管理，开发管理（任务跟踪），PPM，这篇文章的话，我会讲一下需求管理，至于其它几个部分，比如项目规划管理，我还在考虑之中，因为有些知识在前面几篇文章里已经部分提到了，所以讲起来可能就重复了。Anyway，先不管了，反正我这篇“需求管理”还是会正常写下去，谢谢大家阅读！
PPM
PMI对组合管理的定义为“Project Portfolio management refers to the selection and support of projects or program investments. These investments in projects and programs are guided by the organization’s strategic plan and available resources .”，即项目组合管理是指在可利用的资源和企业战略计划的指导下，进行多个项目或项目群投资的选择和支持。项目组合管理是通过项目评价选择、多项目组合优化，确保项目符合企业的战略目标，从而实现企业收益最大化。
项目和项目组合管理（PPM）是项目型组织创新的系统化管理理论和实践，过去项目管理的理论和工具都是基于单个项目管理的，解决的问题是项目如何使干系人满意，如何按时、在预算内成功交付项目。对于组织级层面如何管理项目，例如如何使项目目标与组织的业务目标一致，如何跨项目优化利用组织的资金和资源等，一直没有很好的理论和方法的支持。组合（Portfolio）管理是金融领域的方法论，在2000年左右被引入到项目管理领域，尝试解决组织级项目管理问题。
自2002年初开始，PPM方法论首先在产品研发管理领域取得了重大成功，并逐渐扩展到IT治理和专业服务领域。这期间，欧美出现了一批非常成功的PPM独立软件厂商。从2005年开始，国际上PPM进入整合阶段，IBM、CA、HP、Microsoft、Oracle、蓝云软件等国际知名IT企业陆续通过收购进入PPM领域。PPM是未来项目型组织，尤其是IT组织管理优化的方向，这一点已成为业界共识。著名研究机构Forrester Research指出：“PPM已经成为IT企业的ERP”。
什么是软件需求呢？为什么它需要管理呢？
软件需求完全严格来解释就是：
（1）用户解决问题或达到目标所需条件或权能（Capability）。
（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
（3）一种反映上面（1）或（2）所述条件或权能的文档说明
也许看起来有点深奥，其实简单来说，软件需求就是一个软件要实现的功能，当然这里所谓的“功能”可能分为两种情况，一种是有形的，一种是无形的：
● “有形”的应该很好理解，你实际可以用到的功能，比如在Word文档里能把字加粗。
● “无形”的其实也好理解，虽然你平常用不到，但是还是能感受到的，比如说软件的运行速度，稳定性，还有比如这个软件要达到什么目的（比如Word的目的是可以让你处理文字信息）。
当然，其实最终所有“无形”的需求还是需要靠一个个的“有形”的需求来实现，只是有些“有形“的需求即使实现了客户也无法直接看到，只有设计、开发与测试才能看到它们。
那为什么要对需求进行管理呢？
软件需求是随着计算机的发展而发展的，在计算机发展早期，软件规模很小，所以当时大家关注的是编码，而对于需求并不怎么关注，后来随着“软件危机”的出现，诞生了软件工程，而需求阶段就是其第一阶段，至此，软件需求（也称之为需求分析）阶段开始慢慢被关注。
大家都知道，“软件危机”的原因是落后的软件生产方式无法满足迅速增长的计算机软件需求，软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出，原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发。
而软件需求分析阶段作为软件工程的第一阶段，需要为一个软件的开发搭好最初的框架并且还要考虑好后面可能的修改，所以对于软件可靠性、易用性、可扩展性和可维护性来说，需求分析阶段是及其重要的，直接关系到一个软件是否能够成功。
如果一个产品在需求分析阶段没有被设计好的话，在以后的各个阶段，开发与维护的成本就会非常高，导致最后失败的可能性就会非常大，著名的例子比如微软的Vista，设计初期没有考虑好兼容性与硬件，导致发布以后发现与其他软件的兼容性很差，而且硬件要求又很高，很多客户不买他们的账，所以最后匆匆收场，赶紧推出Windows 7来，要知道Vista的开发成本估计要接近百亿美金了，都还没怎么赚钱就赶紧推出另外一个产品，足见其失败了。
所以软件需求分析阶段对于软件工程而言，已经成为至关重要的阶段，其实按照我的理解，它已经成为软件工程最重要的阶段，记住，不是之一。（当然，我这里说的需求分析阶段是包含软件的设计阶段的）
一个软件的成功与否，在需求分析与设计阶段已经可以基本上预见了，因为需求分析与设计阶段从概念上其实已经把这个产品做出来了，而之后的编码阶段只是去实现它，让产品能真正可以去用。那这个“实现”阶段其实相对来说就不会那么重要了，所以现在很多跨国公司只在总部保留设计部门，研发部门都外包出去，就是这个原因。 “苹果”就是这样一个公司，把需求分析与设计工作做好，让台湾人去把产品做出来，最后得到一个完美的产品。
既然软件需求阶段已经变成如此重要，那对它的管理也就相应的变得特别重要了，只有把需求设计做好了，产品才有可能成功，所以我们就需要对这个阶段进行有效的管理，而且是非常有效的管理！
刚才脑子里一闪而过的几句话。想跟大家说说。
1、测试人的工资。
为什么我先谈工资，看了几天，此版块工资的帖子是最火的，回的人多，看的人多。超过了某些测试人呕心沥血写的技术文档。
即可以这么说，有很多人在看前景的时候死死的盯着工资不放。还有些没有进入此行业的人也在先问工资再决定进不进这个行业。
这种的思想，当然不可厚非的，生存嘛，谁不要吃饭呢，谁不想多拿点钱，找个好老婆，有个好孩子，幸福的生活呢。可是做测试，我认为，这样的技术工作，应该首先关注的是技术，这才是根本。我要说，我们是高尚的测试人，是为了祖国的IT事业添砖加瓦，为IT行业的成熟做出贡献，不惜一切的牺牲，这也是扯谈。
可是谈工资，谈多久也没人给你长的，只有从技术出发才能长，牛人工资就是高（不排除怀才不遇的现象）。有些人在痛恨工资不高的时候也没有想着拿这些痛恨领导的时间来多学点东西。这就有点不可原谅了。
先看看自己的实力，再看看现在的市场，再来评估自己能拿多少工资，这才是正确的做法。
技术高了，做测试的你，抬起头来，面试的时候说出自己的强项。总有伯乐在前面等着你。
抬起头来第一式：练好技术，再想工资。
2、学习方法。
很多人在问学习测试从哪里开始。这个问题简单到没人回答上来的地步。首先要明确几个问题。
你是不是愿意在这条路上走下去？
你有没有自己喜欢的方向？
你有没有了解现在的测试行业？
好了，下面开始谈学习测试方法。测试也有很多方向的，会越来越细分。所以要给自己选择一个方向。这个方向可以向前辈们请教一下，然后自己来选择，没有人能给你做得了抉断。估计也没有人能说出来现在哪个方向最后是能赚大钱的。
选择好了，开始学习。细节的东西就不用说了，枯燥乏味一定是有的。要学会学习，不能什么就张嘴就问。
有些东西，手册里查找就能找到的，就没必要再问了。有些人是那种，说一句做一步的人。不会主动。那就肯定进步不大了。
没有人能一步步的从网络上教你，当然有某些特殊关系的除外。
当身边没有人可以共同学习和讨论的时候，就到网上转转。
给自己定一个计划，至少让自己过去的一周里，把计划里的东西尽力做完。没有书面的也没关系。心里记着就行了。
有个人问我怎么学习LR，从哪看起，我说先安装，装完了看手册一步步操作，不懂没关系，做下去，以后再回来看，就明白多了。
还有，千万别看了一段手册就认为自己学的很多了，结果放在那里放了几个月，再回头看的时候就全忘光了。
这有什么用，不如不学呢。半途而废要是再想开始，比从头开始要难。这是我的看法。
关注细节，在技术上就是这样。工作中有一点没有想到可能就会出差错，所以学习的时候一定要踏实一点。把细节给做好，看论坛有些人就做的不好，问个问题，回一个提示，立马就会了。这就是没有更多的想下去，哪怕一小步。坐下来，冷静的看几个小时的资料，每天坚持，不出一个月，就会觉得不再是那么一无所知了。
所以，做测试的人，学习要踏实，别浮。浮在半空中，迟早是要破的。
抬起头来第二式：抓住细节，冷静学习。
3、测试规范。
很多人都看到当前的测试市场有点混乱。毕竟发展的时间不是很长，现在的状况是可以理解的。
那靠什么来提高规范？就是做测试的人了。慢慢的积累，一点点完善。法律不还是一点点写出来的？现在不是还在完善着吗？
规范是要有的，不然会一直乱下去。有些公司，可以说没有什么测试计划，经理说，你把这个测一下，然后测试人员就做，明天说，你把那个测一下，然后还是做。可是为什么这么做？也没有书面的文档。也没有时间表。这样的现象就很差了。现在很多公司在慢慢的重视这一点。
而干活的人要怎么来要求自己呢。我们要一点点的培养自己的完善的测试理念。从哪里开始。为什么这么做，下一步做什么，等等。
有人会说，时间紧，根本没时间做什么规范的流程。那就要测试人慢慢的来完善这个市场了，在个人重视规范的过程中，市场的规范也会慢慢清晰起来。
抬起头来第三式：严于律已，提高规范。
希望测试前景越来越好的同时，你拿的工资也越来越高。
查看Linux服务器下的内存使用情况 ，可以使用命令free -m。注意此命令只在Linux下有效，在FreeBSD中没有此命令。命令如下所示：
used：已经使用的内存数
free：空闲的内存数
shared：多个进程共享的内存总额
-buffers/cache：（已用）的内存数，即used-buffers-cached
+buffers/cache：（可用）的内存数，即free+buffers+cached
得出结论：
可用内存的计算公式为：
可用内存=free+buffers+cached，即2551MB+268MB+917MB=3737MB
很久以前在笔记本上用Ubuntu8.04时就觉得Linux管理内存的机制非常优秀，简而言之：Linux的内存是拿来用的，而不是拿来看的。我与一个朋友探讨Linux的使用情况时，他问我为什么Linux使用的内存这么高。他机器上1GB的内存free才232MB，而Windows XP才用了200MB不到的样子。这其实是被Linux的free命令之表象迷惑了，Linux的内存使用是很有讲究的。还是举例说明，如下的free命令所显示的是当前内存的使用情况，-m的意思是用M个字节来显示内容，我们来一起看看。
在第一部分Mem行中有如下参数。
total：内存总数，即1002MB
used：已经使用的内存数，即769MB
free：空闲的内存数，即232MB
shared：当前已经废弃不用，总是0
buffers Buffer：缓存内存数，即62MB
cached Page：缓存内存数，即421MB
其中，内存总数与已使用内存数和空闲内存数的关系是：
total(1002M)=used(769M)+free(232M)
在第二部分内容(-/+buffers/cache)中各参数如下所示。
(-buffers/cache)：used内存数，即286MB(指的是第一部分Mem行中的used-buffers-cached)。
(+buffers/cache)：free内存数，即715MB(指的是第一部分Mem行中的free+buffers+cached)。
可见-buffers/cache反映的是被程序实实在在用掉的内存，而+buffers/cache反映的是可以挪用的内存总数。
第三部分是指交换（swap）分区，大家应该都明白，这里就不再讲了。
有可能大家看了上面的解释还是不太明白。比如：第一部分(Mem)与第二部分(-/+buffers/cache)的结果有关，used和free为什么这么奇怪？其实我们可以从两个方面来分析。对操作系统来讲这两项是Mem的参数，buffers/cached都属于被使用，所以它认为free只有232MB；对应用程序来讲+buffers/cached等同于可用的内存，因为buffer/cached可提高程序执行的性能，当程序使用内存时，buffer/cached很快就会被使用。所以从应用的角度来看，应以(-/+buffers/cache)的free和used为主，即我们主要看与它相关的free和used就可以了。另外告诉大家一些常识，为了提高磁盘和内存的存取效率，对Linux做了很多精心的设计，除了对dentry进行缓存(用于VFS、加速文件路径名到inode的转换)外，还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者用于针对磁盘块的读写，后者用于针对文件inode的读写。这些Cache能有效地缩短I/O系统调用(比如read、write、getdents)的时间。
在Linux中，内存是拿来用的，不是拿来看的。而在Windows中，无论你的真实物理内存有多少，它都会用硬盘交换文件来读，即使是内存还有一大部分。这也就是Windows常常提示虚拟空间不足的原因。可以想见，硬盘怎么会快过内存，所以我们在观察Linux的内存使用情况时，只要没发现用swap的交换空间，就不用担心自己的内存太少。如果常常看到swap用了很多，那么你就要考虑加物理内存了。这也是在Linux服务器上看内存是否够用的标准。