-
从印度软件项目管理谈我国软件质量保障
2008-10-22 11:41:33
计算机和通信技术的迅速发展，特别是Internet技术的发展与普及，为企业内部、企业与外部提供了快速、准确、可靠的信息交流渠道。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备支持系统。正是由于这样的市场需求与技术发展现状，为我国的IT行业带来了空前发展的机遇，特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力，其中软件质量保障在其发展过程中占有重要的位置。
众所周知，印度已成为世界上软件业增长最快的国家，目前每年软件业产值达数十亿美元，并且还在以每年30%～50%的速度增长。比较我国和印度的软件产业，就不难发现:中国拥有巨大的软件市场和世界公认的软件开发资源，在基础研究和对技术前瞻性的把握上，也有自己的优势，就整体社会经济环境而言也优于印度。此外，中国的软件开发人员费用比较低廉，仅是世界市场的1/3左右。虽然中国人并不缺乏软件开发的天赋，但是在越来越强调规模化经营的今天，先天不足的管理痼疾使我们举步维艰，难以摆脱小作坊式的软件开发模式。而印度软件业从一开始就立足于为美国软件企业服务，并遵循其软件开发的管理模式，与国际标准接轨。
管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业内人士参考。
1.软件企业的组织结构
(1)A公司结构
图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。
图1
* A公司中，QA(Quality Assure)部门与研发部门独立，负责监督流程的执行。QA同时负责领导与研发部门组成的联合工作组，制定公司流程。
* SSG(System Support Group)类似我们的IT部门，负责公司所有计算机软件和硬件资源的分配和管理。所有的办公环境和开发/实验室环境由SSG负责安装和维护，计算机资源属于SSG，由各个项目向SSG提出需求，项目结束后，设备需要交还给SSG。个人和项目组没有固定的软件和硬件资源。SSG是与研发平行的部门。
* 人力资源部门负责公司的人力资源管理，并维护员工的技能数据库。项目开始时，项目组向人力资源申请人力，向SSG申请计算机硬件和软件。项目结束时需要释放计算机资源给SSG，释放人力资源到人力资源池，并同时更新员工的技能数据库。研发部门的人力资源由研发总负责人和其助手分配(类似我国各公司的人力资源部)。
(2)项目组结构
1) A公司对项目组进行独立核算，项目具体负责人为PC(Project Coordinator)，负责项目计划和执行，对项目具体成员进行分工。在每个阶段的结束会议上(如概要设计结束)，PC要接受QC(Quality Coordinator)的审查。除了PC与QC的接口外，所有其他外部接口都由EM(Engineer Manager)完成，EM负责与客户打交道，向SSG、人力资源要求资源，与其他项目组协调进度。
2) 汇报关系为:
Team Member->Team Leader->PC->EM->研发总负责人。
3) 印度工程师分为7级，半年一次考评，即半年有一次升级机会。
1级:Software Engineer，刚毕业的本科生和研究生。
2级:Senior Software Engineer。
3级:Project Leader。
4级:Project Manager。
5级:Senior Project Manager。
3级可以成为PC，4级可以成为EM。刚开始平均2年升一级，越往后升职越慢。
A公司规定，一人最多可以同时兼任两个项目的PC，EM管理的项目没有限制。
A公司通常的项目组为4到5人，最多不超过10人。
以上是A公司（同时也是印度大多数规范化的软件公司）的组织结构和项目组结构。可以看出，A公司的组织结构非常清晰，各个部门分类非常细，任务明确，软件生产的每一个步骤都有专门的部门、专门的人员负责，从最基础的开发人员到负责统领全局的总经理，层层管理，沟通渠道畅通。而在我国，管理的不规范往往首先体现在公司的组织结构上，集中表现为部门的缺失和管理的交叉上。我国的软件公司，大部分规模较小，开发人员超过100人的公司很少。在印度，软件公司无论大小，都是“麻雀虽小，五脏俱全”，绝不会因为公司的规模大小而改变合理的组织结构。因此笔者认为，国内的软件企业要想有效地保障产品质量，首先就要在构架合理的组织结构上下功夫，这就如同盖高楼首先要打好地基一样，地基不打牢，结构不合理，其他方面再下功夫也是徒劳。有人说，因为国内软件企业规模小，所以造成结构设置的欠缺，但笔者认为恰恰是因为没有建立一个规范化的组织结构，才会使软件产品质量不保，进而严重影响了企业的发展扩大。
2.项目计划
凡事预则立，不预则废。这里的“预”就是指计划。对于软件企业，计划的重要性是不言而喻的。让我们先看看A公司的项目计划是如何制定的:在A公司，项目开始之前必须先估计项目的规模（以代码行数来衡量）;然后制定项目计划。通常时间为2～3周，已知的最长有5周。EM负责制定项目 EWP(Engineer Work Paper)，其中定义了项目需要的人力和计算机资源，由相关部门同意，并报研发总负责人批准后才能开始项目。
项目的正式开始时间由项目组的Kickoff Meeting算起，Closeout Meeting结束。
大概很多人都听过这样一句话：“计划赶不上变化”。这种“变化”对某些行业而言也许并不会产生太大的影响，但对于软件企业而言，却会给软件产品的质量保证带来严重的负面影响。为什么会造成这种“计划赶不上变化”的现象？究其原因，笔者认为主要是因为对计划的重视程度不够，计划过于笼统、粗糙导致可执行性太差，再加上一些人为因素的影响，必然会产生这样的后果。
如果我们的软件企业都能像A公司这样，在作计划时能考虑到每一个细节，不是仓促做出决定，而是由所有的相关部门共同对产品计划进行反复研究、制定、讨论、修改，最终形成一套系统、严密、具有很强的可执行性的计划。计划一旦形成，就严格按照计划去执行，而不受某个人、某件事的影响，那么就不仅能够减少大量资源的浪费，产品的质量也得到了保障。
因此，对计划的高度重视、周密制定、严格执行是企业有效保障产品质量的一个重要环节。
3.项目管理
当企业构架了合理的组织结构并制定了缜密的计划后，就进入了产品的开发阶段。在这个阶段中，项目管理起了重要作用，它所涉及的环节相当具体复杂，下面先介绍一下A公司在项目管理上的具体细节：
(1)开发阶段和项目周期
开发阶段比较明显，注重各阶段应完成的功能，对本阶段应完成的工作不能留到下一阶段。
(2)流程
* A公司对流程比对项目更重视。
* 软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。A公司的流程已覆盖到了一个项目研发的所有方面，包括从最开始的意向到最后软件的版本发布(release)，都有相应的流程规定，基本上已形成一种工业化的软件开发。
* 人和流程是保证项目成功的两个最关键因素。由好的人按好的流程进行项目开发，才能最大限度地保证项目的成功。一个好的流程可以保证差的人做出来的东西不至于太差，但不能确保做出精品。通过流程可以实现一种规范化、流水线化、工业化的软件开发。
(3)计划
1) 计划详细、周到。
2) 流程中明确定义开发阶段。
3) 每个阶段都列出了该阶段的各项活动，并详细描述每项活动的属性:
* 进入条件，输入;
* 验证方法;
* 结束条件，输出。
4)每个阶段结束都要召开阶段结束会议。前一个阶段结束才能进入下一阶段。
5)计划中每个活动都比较具体，每个活动的时间以天（半天）为单位。计划包括了开展质量控制活动的时间。
(4)Review
按印度公司流程，一般把Review和测试作为保证软件质量两个主要手段。测试的重要性就不需说明了，而Review则是一个非常简单有效并能尽早发现软件中错误的方法，可以说，任何交付物都要经Review后才能进行基线化。目前A公司有很详细全面、可执行性很高的Review流程和各种交付物的Review Checklist。
在印度软件企业，现有这么一句口号：凡事有计划，凡事必review。
(5)QA
QC（质量经理）作为质量保证部门（SQA）的代表，监督和保证项目的进展遵循QMS各项流程和模板，并且收集项目中发现的一些问题和解决方法以优化流程。
(6)度量数据
CMM中比较强调用数据说话，对项目过程中基本上所有的数据都会有记录，最后把收集的数据提交质量保证部门进行分析，以改进流程。A公司的项目经理和质量经理很重视项目中的数据收集，包括各种Review数据、测试数据以及项目组员每天的活动数据等。项目经理也要维护一个项目档案，在这个项目档案中可以说包含了项目开发过程中所有的产出、开发活动、管理活动等的记录。可以这么说，有了这个项目档案，你就可以完全了解这个项目的开发过程。
(7)团队精神
印度公司都比较强调团队精神、合作精神，应该说，其流程本质上就要求员工之间的互相协调和理解。相对而言，印度员工的合作精神和协调精神都比我国员工要好得多。
(8)培训
印度公司都比较强调培训，一般有专门的培训部门进行协调。在新员工进入公司后都会有公司流程和其他一些公司普遍章程的培训，以保证员工对流程的理解和执行。对于具体项目，项目经理在制定项目计划时就会在项目计划中提出所有的培训需求，包括技术上的培训和其他所需的培训。
(9)配置管理
在项目正式开展前，项目经理就要制定配置管理计划，并且指定配置管理员建立起配置管理库，按配置流程严格进行配置管理。在配置流程中也详细提供了对更改的控制，没有经过批准的更改请求是绝对不能进行的。
(10)记录
记录及时、充分、比较准确。这些记录包括:重要的邮件、会议纪要、审核记录、缺陷报告、测试报告。
1)与客户和其他项目组的所有往来必须邮件记录。
2)对所有的活动都有一个跟踪落实的过程，比如对所有的Review记录和更改请求都会有一个状态标识，标识其当前状态，通过跟踪其状态来监督其落实。
3)对所有的活动，包括对文档和代码的更改都会有一个历史记录。
4)记录比较准确、比较客观。
5)许多记录都是通过定量的数值记录，强调以数据说话（CMM4级的重点就是量化管理）。
以上是A公司在项目管理中所涉及到的一些主要环节，很值得国内的软件企业在制定项目管理规划时借鉴。除此之外，我国的软件企业在产品开发管理的过程中，还易出现以下几个方面的问题:
1)需求说明差─需求不清楚、不完整、太概括、或者不可测试，都会造成问题。
2)不切实际的时间表─如果在很短的时间里要求做许多事，出现错误是不可避免的。
3)测试不充分─只能根据客户意见或系统崩溃来判断系统的质量。
4)不断增加功能─在开发正在进行过程中要求增加许多新的功能。这是常见的问题。
5)交流问题─如果开发人员对客户的要求不了解，或者客户由不恰当的期望，必然会导致错误。
这些问题的出现，将会对软件质量的保证产生不良影响，针对上述问题并结合A公司在项目管理方面的经验，笔者提出一些相应的解决方法，以供参考：
1)可靠的需求─应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。
2）合理的时间表——为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。
3)适当测试─尽早开始测试；每次改错或变更后，都应重新测试。项目计划中要为测试和改错留出足够时间。
4)尽可能坚持最初的需求─一旦开发工作开始，要准备防止修改需求和新增功能，要说明这样做的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。
5)沟通——在适当时机进行预排和检查;充分利用团组通信工具—电子邮件、群件(groupware)、网络故障跟踪工具、变更管理工具、以及因特网的功能。要确保文件是可用的和最新的。优选电子版文档，避免纸介质文档:进行远距离联合作业及协作;尽早使用模型，使客户的预想表达清楚。
4.PC（项目经理）
项目经理是项目成败的关键人物，其对项目的成败负主要责任。因此在这里将项目经理的有关内容单独提出，以A公司为例详细说明PC在整个产品研发过程中所扮演的角色，希望能对国内软件企业的项目经理有所启示。
（1)在A公司，按流程在一个项目正式开展之前，项目经理需要完成：
* 项目计划(Project Plan):在此描述整个项目所应完成的交付物、项目时间表、培训需求、资源需求、质量保证计划以及过程和交付物的定量质量目标等。
* 项目配置管理计划(Project Configuration Plan):在此指定配置管理员，描述项目配置项列表、配置管理库、版本管理计划等等。
*项目过程手册(Process Handbook):在此描述本项目所采取的裁剪后的生命周期模型和流程。
（2）在项目开发过程中，项目经理需非常了解项目进度，进行工作任务细化、具体计划和安排项目成员工作任务等工作。对突发事件项目经理需能及时合理地进行协调。
（3)总的说来，PC安排工作有这么几个特点:
a.PC对软件开发具有丰富的经验，了解软件开发的普遍流程，了解各个阶段所需完成的工作，这是安排好项目组成员工作的前提，在A公司对PC的整体素质要求非常高。
b.在项目正式开展前，PC准备项目计划文档，在项目计划中包含了项目进度时间表，但此时间表比较粗，只能给出各个阶段和各个子阶段的起始结束日期。对各个阶段和各个子阶段的详细工作安排和各项工作责任人只能在项目开展工程中根据项目实际情况进行安排，一般是在每周项目组例会上进行本周详细工作安排。
c.PC对工作安排往往精确到天，有时甚至精确到小时，要做到这一点，需要:
* PC对本项目进展非常了解。了解渠道通常是每周组员的状态报告和直接与组员接触了解，这也需项目组成员能如实汇报工作。
* 对现阶段或本周所需完成的工作非常了解。知道现在该做什么，并且能把各项工作进行合理细致地划分，因为各个分解的工作比较细致，因此能相对精确地评估出这些工作完成所需的时间。
* PC对项目组员的能力比较了解，安排工作时能做到有的放矢。当安排的员工对工作不熟悉时，会指定相应的组员进行协助。
* PC对组员的工作安排都比较细致饱满。一般不会出现有些员工有事干，有些员工没事干的情况，当出现这种情况或员工提前完成工作时，PC就会进行相应的协调。
d.PC在项目组例会上的工作安排一般只限于本周或甚至是过后的二、三天，一般不会太长，对长时间工作的安排容易失去精确并且不易控制。相对而言，短时间的工作安排就比较精确而且容易控制，并且能不断根据完成的工作进行调整。当然，这就要求PC能根据项目计划中的项目时间表进行整体进度的把握。
e.项目组例会一般一周一次（时间不能太长），但必要时（如组员工作已完成或其他事情），也可在中途召开项目会议进行工作安排，一般时间都比较短（十几分钟左右，一般不超过半小时，以免浪费时间），总之，当PC觉得需要时，就会召开项目会议。
f.当项目组出现意外事件或影响项目团结的事件时，PC能及时合理协调，解决项目组内的不和谐气氛。
g.PC善于鼓励手下，发挥员工的潜能，PC往往会赞扬很好地完成了工作的组员。
从上面可以看出，对PC的能力（包括技术和管理能力）要求是非常高的，我国的软件企业往往只重视PC的技术能力，但事实上，一个只精通技术的人往往不能成为一个合格的领导者， 笔者认为对PC而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。
总结
以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在这个问题上不妨采取“拿来主义”的办法，对于好的，事实证明是成功的经验，首先是“占有”，然后才是“挑选”和“创新”。如果能把印度的管理经验真正领会并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用. -
性能测试指标介绍
2008-10-22 11:40:13
TPC-C
作为一家非盈利性机构，事务处理性能委员会（TPC）负责定义诸如TPC-C、TPC-H和TPC-W基准测试之类的事务处理与数据库性能基准测试，并依据这些基准测试项目发布客观性能数据。TPC基准测试采用极为严格的运行环境，并且必须在独立审计机构监督下进行。委员会成员包括大多数主要数据库产品厂商以及服务器硬件系统供应商。
相关企业参与TPC基准测试以期在规定运行环境中获得客观性能验证，并通过应用测试过程中所使用的技术开发出更加强健且更具伸缩性的软件产品及硬件设备。
TPC-C是一种旨在衡量联机事务处理（OLTP）系统性能与可伸缩性的行业标准基准测试项目。这种基准测试项目将对包括查询、更新及队列式小批量事务在内的广泛数据库功能进行测试。许多IT专业人员将TPC-C视为衡量“真实”OLTP系统性能的有效指示器。
TPC-C基准测试针对一种模拟订单录入与销售环境测量每分钟商业事务（tpmC）吞吐量。特别值得一提的是，它将专门测量系统在同时执行其它四种事务类型（如支付、订单状态更新、交付及证券级变更）时每分钟所生成的新增订单事务数量。独立审计机构将负责对基准测试结果进行公证，同时，TPC将出据一份全面彻底的测试报告。这份测试报告可以从TPC Web站点(http://www.tpc.org)上获得。
tpmC定义: TPC-C的吞吐量，按有效TPC-C配置期间每分钟处理的平均交易次数测量，至少要运行12分钟。
1．TPC-C规范概要
TPC-C是专门针对联机交易处理系统（OLTP系统）的，一般情况下我们也把这类系统称为业务处理系统。
TPC-C测试规范中模拟了一个比较复杂并具有代表意义的OLTP应用环境:假设有一个大型商品批发商，它拥有若干个分布在不同区域的商品库；每个仓库负责为10个销售点供货；每个销售点为3000个客户提供服务；每个客户平均一个订单有10项产品;所有订单中约1%的产品在其直接所属的仓库中没有存货，需要由其他区域的仓库来供货。
该系统需要处理的交易为以下几种：
-
New-Order：客户输入一笔新的订货交易；
-
Payment:更新客户账户余额以反映其支付状况;
-
Delivery:发货(模拟批处理交易);
-
Order-Status:查询客户最近交易的状态；
-
Stock-Level:查询仓库库存状况，以便能够及时补货。
对于前四种类型的交易，要求响应时间在5秒以内；对于库存状况查询交易，要求响应时间在20秒以内。
逻辑结构图：
流程图：
2．评测指标
TPC-C测试规范经过两年的研制，于1992年7月发布。几乎所有在OLTP市场提供软硬件平台的厂商都发布了相应的TPC-C测试结果，随着计算机技术的不断发展，这些测试结果也在不断刷新。
TPC-C的测试结果主要有两个指标：
● 流量指标(Throughput，简称tpmC)
按照TPC的定义，流量指标描述了系统在执行Payment、Order-status、Delivery、Stock-Level这四种交易的同时，每分钟可以处理多少个New-Order交易。所有交易的响应时间必须满足TPC-C测试规范的要求。
流量指标值越大越好！
● 性价比(Price/Performance，简称Price/tpmC)
即测试系统价格（指在美国的报价）与流量指标的比值。
性价比越小越好！
3．结果发布
各厂商的TPC-C测试结果都按TPC组织规定的两种形式发布：测试结果概要(Executive Summary)和详细测试报告(Full Disclosure Report)。测试结果概要中描述了主要的测试指标、测试环境示意图以及完整的系统配置与报价，而详细测试报告中除了包含上述内容外，还详细说明了整个测试环境的设置与测试过程。
P690 tpmC测试值：76,389,839.00
$/tpmC：831.00
美国美金报价：6,349,223.0
CPU数：32
数据库：IBM DB2 UDB 8.1
操作系统：AIX 5L V5.2
中间件：TUXEDO 8.0
测试日期：2003.6.30
P690 TPC-C测试的配置：
1． 后台：1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory
2． 前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory
SPECweb:
SPECweb96: 在SPECweb96基准测试程序上实现的每秒钟超文本传输协议（HTTP）操作最多次数，响应时间无明显退化。
SPECweb99: 接入数，网络服务器可用预先确定的工作量支持的同时接入数。SPECweb99检测设备模拟客户通过慢Internet联接，向网络服务器发送HTTP工作量请求。
SPECweb99 测试Web服务器运行状况
SPECweb99 是由标准性能评估组织（SPEC）开发的Web服务器基准测试。它测量满足特定吞吐量和客户请求响应速率要求的WEB服务器的最大并发连接数量。并发连接的合计波特率在320 Kbps到400Kbps范围内，则满足相应规范。
SPECweb99 在一台称为主客户端的机器上运行，这台机器上包含有允许用户加载特定负载请求的配置文件。主客户端也要处理在客户端和服务器或测试中的系统（SUT）之间的传输协调问题。客户端通过许多子进程／线程生成独立HTTP请求流，仿真足够的负载发送给SUT。图二表示客户端／服务器的层次关系。
图：典型的SPECweb99实验环境
在这个测试中，客户端向测试中的服务器发送请求数据。测试规范要求客户端和服务器之间的连接不能使用片段大小大于1460比特的TCP协议。因此，每一个客户端读取1460比特或更少数据块的响应。
测试中使用两种类型的负载量：
静态负载. 静态负载具有四种类型的文件。最小的文件的增幅为0.1KB，第二种文件类型的增幅为1KB，最后两种类型的文件的增幅为10KB和100KB。每一个目录包含每种类型9个文件共36个文件。
目标请求的文件类型在各类型中分散使用。在每一类中的9个文件中又进行二次分布。最终目标文件混合为：
35％的请求文件小于1 KB
50％的请求文件小于10 KB
14％的请求文件小于100 KB，但是大于或等于10 KB
1％的请求文件小于1000 KB，但是大于或等于100 KB
动态负载.动态负载是基于广告和用户注册。共有四种在SPECweb99中使用的请求内容类型，分别是标准动态取操作、动态随机取操作、动态发送操作和客户图形接口动态取操作。标准动态取操作和客户图形接口动态取操作表现web服务器的简单广告轮转特性。带有广告轮转的动态取操作追踪用户和用户选择，所以广告可以由不同的方式来定制。最终，动态发布实施一个用户注册在相应的网站上。
P690 SPECweb99测试值：21,000
Web服务器：Zeus 4.0
操作系统：AIX 5L V5.1 (64-bit)
CPU数：16
测试日期：2001-10-1
测试配置：16 x 1.3GHz POWER-4 Processors w/1440KB unified on chip L2 cache, 192GB memory, 32 x 32 IBM Gigabit Ethernet-SX PCI controllers, 32 x Gigabit Ethernet network (1 Gigabit/sec ), 96 x Clients (4 x 375MHz POWER3-II, RS/6000 44P-270), Requested Connections = 21000, Max Fileset Size = 67319.6MB
P650 SPECweb99测试值：12,400
Web服务器：Zeus 4.1r3
操作系统：AIX 5L V5.2 (64-bit)
CPU数：8
测试日期：2002-10-1
测试配置：8 x 1.45GHz POWER4+ processors w/1.5MB(I+D) unified on chip L2 cache, 32MB unified off chip/SCM L3 cache, 64GB memory, 8 x Gigabit Ethernet-SX PCI-X controllers, 8 x Gigabit Ethernet network (1 Gigabit/sec ), 48 x Clients (6 x 668MHz RS64-IV, pSeries 620 Model 6F1), Requested Connections = 12400, Max Fileset Size = 39801.28MB
p630 SPECweb99测试值：6,895
Web服务器：Zeus 4.2r1
操作系统：AIX 5L V5.2(64-bit)
CPU数：4
测试日期：2003-2-1
测试配置：4 x 1450MHz POWER4+ Processors w/1536KB(I+D) unified on chip L2 cache, 8MB unified (off chip)/SCM L3 cache, 32GB memory, 4 x Gigabit Ethernet-SX PCI-X controllers, 4 x Gigabit Ethernet networks (1 Gigabit/sec ), 24 x Clients (4 x 375MHz POWER3-II, pSeries 640 Model B80), Requested Connections = 6900, Max Fileset Size = 22199.12MB
NotesBench:
NotesBench是测试各种不同Lotus Notes方面的驱动程序。目的是执行自定义工作量教本中的命令，模拟客户机的操作。NotesBench测试“仅测试邮件”和“测试邮件和数据库”。所有已经公布的IBM结果均为“仅测试邮件工作量”。
p680 NotesBench测试值：150,197
用户数：108,000
平均反应时间：0.584秒
Domino服务器版本：5.06a
操作系统：AIX 4.3.3
CPU数：4
测试日期：2001.11.20
测试配置：IBM eServer pSeries 680 (24*RS64 IV/600MHz; 96GB RAM, 30 Partitions)
-
-
被收容者孙志刚之死(二)
2008-10-22 11:01:34
-
被收容者孙志刚之死(一)
2008-10-22 11:00:34
本文发表于2003年
3月17日：在广州
街头被带至黄村街派出所 3月18日：被派出所送往广州收容遣送中转站
3月18日：被收容站送往广州收容人员救治站
3月20日：救治站宣布事主不治
4月18日：尸检结果表明，事主死前72小时曾遭毒打
孙志刚，男，今年27岁，刚从大学毕业两年。
2003年3月17日晚10点，他像往常一样出门去上网。在其后的3天中，他经历了此前不曾去过的3个地方：广州黄村街派出所、广州市收容遣送中转站和广州收容人员救治站。
这3天，在这3个地方，孙志刚究竟遭遇了什么，他现在已经不能告诉我们了。3月20日，孙志刚死于广州收容人员救治站（广州市脑科医院的江村住院部）。
他的尸体现在尚未火化，仍然保存在殡仪馆内。
《南方都市报》记者 陈峰
孙志刚死了
先被带至派出所，后被送往收容站，再被送往收容人员救治站，之后不治
孙志刚来广州才20多天。2001年，他毕业于武汉
科技学院，之后在深圳一家公司工作，20多天前，他应聘来到广州一家服装公司。 因为刚来广州，孙志刚还没办理暂住证，当晚他出门时，也没随身携带身份证。
当晚11点左右，与他同住的成先生（化名）接到了一个手机打来的电话，孙志刚在电话中说，他因为没有暂住证而被带到了黄村街派出所。
在一份《城市收容“三无”人员询问登记表》中，孙志刚是这样填写的：“我在东圃黄村街上逛街，被治安人员盘问后发现没有办理暂住证，后被带到黄村街派出所。”
孙志刚在电话中让成先生“带着身份证和钱”去保释他，于是，成先生和另一个同事立刻赶往黄村街派出所，到达时已接近晚12点。
出于某种现在不为人所知的原因，成先生被警方告知“孙志刚有身份证也不能保释”。在那里，成先生亲眼看到许多人被陆续保了出来，但他先后找了两名警察希望保人，但那两名警察在看到正在被讯问的孙志刚后，都说“这个人不行”，但并没解释原因。
成先生说，其中一个警察还让他去看有关条例，说他们有权力收容谁。
成先生很纳闷，于是打电话给广州本地的朋友，他的朋友告诉他，之所以警方不愿保释，可能有两种情况，一是孙志刚“犯了事”，二是“顶了嘴”。
成先生回忆说，他后来在派出所的一个办公窗口看到了孙志刚，于是偷偷跟过去问他“怎么被抓的，有没有不合作”，孙回答说“没干什么，才出来就被抓了”。成先生说，“他（孙志刚）承认跟警察顶过嘴，但他认为自己说的话不是很严重”。
警察随后让孙志刚写材料，成先生和孙志刚从此再没见过面。
第二天，孙的另一个朋友接到孙从收容站里打出的电话，据他回忆，孙在电话中“有些结巴，说话速度很快，感觉他非常恐惧”。于是，他通知孙志刚所在公司的老板去收容站保人。之后，孙的一个同事去了一次，但被告知保人手续不全，在开好各种证明以后，公司老板亲自赶到广州市收容遣送中转站，但收容站那时要下班了，要保人得等到第二天。
3月19日，孙志刚的朋友打电话询问收容站，这才知道孙志刚已经被送到医院（广州收容人员救治站）去了。在护理记录上，医院接收的时间是18日晚11点30分。
成先生说，当时他们想去医院见孙志刚，又被医生告知不能见，而且必须是孙志刚亲属才能前来保人。
20日中午，当孙的朋友再次打电话询问时，得到的回答让他们至今难以相信：孙志刚死了，死因是心脏病。
护理记录表明，入院时，孙志刚“失眠、心慌、尿频、恶心呕吐，意识清醒，表现安静”，之后住院的时间，孙志刚几乎一直“睡眠”：直到3月20日早上10点，护士查房时发现孙志刚“病情迅速变化，面色苍白、不语不动，呼吸微弱，血压已经测不到”。医生在10点15分采取注射肾上腺素等治疗手段，10分钟后，宣布停止一切治疗。孙志刚走完了他27年的人生路。
医院让孙志刚的朋友去殡仪馆等着。孙的朋友赶到殡仪馆后又过了两个小时，尸体运到。
护理记录上，孙的死亡时间是2003年3月20日10点25分。
孙志刚是被打死的
尸检结果表明：孙志刚死前几天内曾遭毒打并最终导致死亡
医院在护理记录中认为，孙是猝死，死因是脑血管意外，心脏病突发。
在向法医提出尸检委托时，院方的说法仍是“猝死、脑血管意外”。据3月18日的值班医生介绍，孙志刚入院时曾说自己有心脏病史，据此推断孙志刚死于心脏病。但是，这个说法遭到了孙志刚家属和同学的反驳，孙志刚父亲表示，从来不知道儿子有心脏病。
同样，法医尸检的结果也推翻了院方的诊断。在中山大学中山医学院法医鉴定中心4月18日出具的检验鉴定书中，明确指出：“综合分析，孙志刚符合大面积软组织损伤致创伤性休克死亡”。
虽然孙的身体表面上看不出致命伤痕，但是在切开腰背部以后，法医发现，孙志刚的皮下组织出现了厚达3·5厘米的出血，其范围更是大到60×50厘米。孙志刚生前是一个身高一米七四、肩宽背阔的小伙子，这么大的出血范围，意味着他整个背部差不多全都是出血区了。
“翻开肌肉，到处都是一砣一砣的血块”4月3日，中山大学中山医学院法医鉴定中心解剖孙志刚尸体，孙志刚的两个叔叔孙兵武和孙海松在现场目睹了解剖过程。“惨不忍睹！”孙兵武说，“尸体上没穿衣服，所以伤很明显。”
孙兵武说，他看到孙志刚双肩各有两个直径约1·5厘米的圆形黑印，每个膝盖上，也有五六个这样的黑印，这些黑印就像是“滴到白墙上的黑油漆那样明显”。孙兵武说，他当时听到一名参加尸体解剖的人说“这肯定是火烫的”。
孙兵武说，他看到在孙志刚的左肋部，有一团拳头大小的红肿，背部的伤甚至把负责尸检的医生“吓了一跳”，“从肩到臀部，全是暗红色，还有很多条长条状伤痕。”医生从背部切下第一刀，随着手术刀划动，一条黑线显现出来，切下第二刀的时候，显现出一砣砣的黑血块。
法医的检查还证明，死者的其他内脏器官没有出现问题，“未见致死性病理改变”。
法医的尸检结果表明：孙志刚死亡的原因，就是背部大面积的内伤。
鉴定书上的“分析说明”还指出，孙的身体表面有多处挫擦伤，背部可以明显看到条形皮下出血，除了腰背部的大面积出血以外，肋间肌肉也可以看到大面积出血。
“从软组织大面积损伤到死亡，这个过程一般发生在72小时内。”广州市第一人民医院一名外科医生介绍：“软组织损伤导致细胞坏死出血，由于出血发生在体内，所以眼睛看不见，情况严重会导致广泛性血管内融血，这一症状也被称作DIC。DIC是治疗的转折点，一旦发生，患者一般会迅速死亡，极难救治。所以类似的治疗，早期都以止血、抗休克为主，目的是阻止病情进入DIC阶段，没有发生DIC，患者生还希望极大。”
3月18日晚上11点30分，孙志刚被收容站工作人员送到医院（广州市收容人员救治站）。当天值班医生在体检病历“外科情况”一栏里的记录只有一个字：“无”，“精神检查”一栏里的记录是“未见明显异常，情感适切”，初步印象判断孙志刚患有焦虑症或心脏病。
对于孙志刚背部大面积暗红色肿胀，双肩和双膝上可疑的黑点以及肋部明显的红肿，病历上没有任何记录。在采访中，当晚的值班医生承认，由于当晚天黑，没有发现孙志刚的外伤，第二天，“由于患者穿着衣服，也没有主动说有外伤”，还是没有发现孙志刚严重的外伤。
“（护理记录中）所谓的睡眠很可能其实是休克”，广州市第一人民医院的外科医生：“由于内脏出血，血压下降，患者会出现创伤性休克，这是发生DIC症状的前兆之一，应该立即采取抢救措施。”
但是护理记录上，还只是注明“（患者）本班睡眠”。
按法医的说法，孙志刚体内的大出血，是被钝物打击的结果，而且不止一次。“一次打击解释不了这么大面积的出血”，一名不愿意透露姓名的法医在看完尸检结果以后说。
从尸检结果看，孙志刚死前几天内被人殴打并最终导致死亡已是不争的事实。
更值得注意的是，孙身体表面的伤痕并不多，而皮下组织却有大面积软组织创伤，法医告诉记者，一般情况，在冬季穿着很厚的衣服的情况下，如果被打，就会出现这种情况。
而3月17日至3月20日的有关气象资料表明，广州市温度在16℃—28℃之间，这样的天气，孙当然不可能“穿得像冬天一样”。
那3天，孙志刚在黄村街派出所、收容站和医院度过的最后生涯，看来远不像各种表格和记录中写得那么平静。
-
企业管理的精髓
2008-10-21 17:27:51
-
关系
2008-10-21 17:26:36
-
Java线程总结（转）
2008-10-21 16:43:23
Java线程总结（转）
在论坛上面常常看到初学者对线程的无可奈何，所以总结出了下面一篇文章，希望对一些正在学习使用java线程的初学者有所帮助。
首先要理解线程首先需要了解一些基本的东西，我们现在所使用的大多数操作系统都属于多任务，分时操作系统。正是由于这种操作系统的出现才有了多线程这个概念。我们使用的windows,linux就属于此列。什么是分时操作系统呢，通俗一点与就是可以同一时间执行多个程序的操作系统，在自己的电脑上面，你是不是一边听歌，一边聊天还一边看网页呢？但实际上，并不上cpu在同时执行这些程序，cpu只是将时间切割为时间片，然后将时间片分配给这些程序，获得时间片的程序开始执行，不等执行完毕，下个程序又获得时间片开始执行，这样多个程序轮流执行一段时间，由于现在cpu的高速计算能力，给人的感觉就像是多个程序在同时执行一样。
一般可以在同一时间内执行多个程序的操作系统都有进程的概念.一个进程就是一个执行中的程序,而每一个进程都有自己独立的一块内存空间,一组系统资源.在进程概念中,每一个进程的内部数据和状态都是完全独立的.因此可以想像创建并执行一个进程的系统开像是比较大的，所以线程出现了。在java中，程序通过流控制来执行程序流,程序中单个顺序的流控制称为线程,多线程则指的是在单个程序中可以同时运行多个不同的线程,执行不同的任务.多线程意味着一个程序的多行语句可以看上去几乎在同一时间内同时运行.（你可以将前面一句话的程序换成进程，进程是程序的一次执行过程,是系统运行程序的基本单位）
线程与进程相似,是一段完成某个特定功能的代码,是程序中单个顺序的流控制;但与进程不同的是,同类的多个线程是共享一块内存空间和一组系统资源,而线程本身的数据通常只有微处理器的寄存器数据,以及一个供程序执行时使用的堆栈.所以系统在产生一个线程,或者在各个线程之间切换时,负担要比进程小的多,正因如此,线程也被称为轻负荷进程(light-weight process).一个进程中可以包含多个线程.
多任务是指在一个系统中可以同时运行多个程序,即有多个独立运行的任务,每个任务对应一个进程，同进程一样,一个线程也有从创建,运行到消亡的过程,称为线程的生命周期.用线程的状态(state)表明线程处在生命周期的哪个阶段.线程有创建,可运行,运行中,阻塞,死亡五中状态.通过线程的控制与调度可使线程在这几种状态间转化每个程序至少自动拥有一个线程,称为主线程.当程序加载到内存时,启动主线程.
[线程的运行机制以及调度模型]
java中多线程就是一个类或一个程序执行或管理多个线程执行任务的能力，每个线程可以独立于其他线程而独立运行，当然也可以和其他线程协同运行，一个类控制着它的所有线程，可以决定哪个线程得到优先级，哪个线程可以访问其他类的资源，哪个线程开始执行，哪个保持休眠状态。
下面是线程的机制图：
线程的状态表示线程正在进行的活动以及在此时间段内所能完成的任务.线程有创建,可运行,运行中,阻塞,死亡五中状态.一个具有生命的线程,总是处于这五种状态之一：
1.创建状态
使用new运算符创建一个线程后,该线程仅仅是一个空对象,系统没有分配资源,称该线程处于创建状态(new thread)
2.可运行状态
使用start()方法启动一个线程后,系统为该线程分配了除CPU外的所需资源,使该线程处于可运行状态(Runnable)
3.运行中状态
Java运行系统通过调度选中一个Runnable的线程,使其占有CPU并转为运行中状态(Running).此时,系统真正执行线程的run()方法.
4.阻塞状态
一个正在运行的线程因某种原因不能继续运行时,进入阻塞状态(Blocked)
5.死亡状态
线程结束后是死亡状态(Dead)
同一时刻如果有多个线程处于可运行状态,则他们需要排队等待CPU资源.此时每个线程自动获得一个线程的优先级(priority),优先级的高低反映线程的重要或紧急程度.可运行状态的线程按优先级排队,线程调度依据优先级基础上的"先到先服务"原则.
线程调度管理器负责线程排队和CPU在线程间的分配,并由线程调度算法进行调度.当线程调度管理器选种某个线程时,该线程获得CPU资源而进入运行状态.
线程调度是先占式调度,即如果在当前线程执行过程中一个更高优先级的线程进入可运行状态,则这个线程立即被调度执行.先占式调度分为:独占式和分时方式.
独占方式下,当前执行线程将一直执行下去,直 到执行完毕或由于某种原因主动放弃CPU,或CPU被一个更高优先级的线程抢占
分时方式下,当前运行线程获得一个时间片,时间到时,即使没有执行完也要让出CPU,进入可运行状态,等待下一个时间片的调度.系统选中其他可运行状态的线程执行
分时方式的系统使每个线程工作若干步,实现多线程同时运行
另外请注意下面的线程调度规则（如果有不理解，不急，往下看）：
①如果两个或是两个以上的线程都修改一个对象，那么把执行修改的方法定义为被同步的（Synchronized）,如果对象更新影响到只读方法，那么只度方法也应该定义为同步的
②如果一个线程必须等待一个对象状态发生变化，那么它应该在对象内部等待，而不是在外部等待，它可以调用一个被同步的方法，并让这个方法调用wait()
③每当一个方法改变某个对象的状态的时候，它应该调用notifyAll()方法，这给等待队列的线程提供机会来看一看执行环境是否已发生改变
④记住wait(),notify(),notifyAll()方法属于Object类，而不是Thread类，仔细检查看是否每次执行wait()方法都有相应的notify()或notifyAll()方法，且它们作用与相同的对象 在java中每个类都有一个主线程，要执行一个程序，那么这个类当中一定要有main方法，这个man方法也就是java class中的主线程。你可以自己创建线程，有两种方法，一是继承Thread类，或是实现Runnable接口。一般情况下，最好避免继承，因为java中是单根继承，如果你选用继承，那么你的类就失去了弹性，当然也不能全然否定继承Thread,该方法编写简单,可以直接操作线程,适用于单重继承情况。至于选用那一种，具体情况具体分析。
eg.继承Thread
public class MyThread_1 extends Thread
{
public void run()
{
//some code
}
}
eg.实现Runnable接口
public class MyThread_2 implements Runnable
{
public void run()
{
//some code
}
}
当使用继承创建线程，这样启动线程：
new MyThread_1().start()
当使用实现接口创建线程，这样启动线程：
new Thread(new MyThread_2()).start()
注意，其实是创建一个线程实例，并以实现了Runnable接口的类为参数传入这个实例，当执行这个线程的时候，MyThread_2中run里面的代码将被执行。
下面是完成的例子：
public class MyThread implements Runnable
{
public void run()
{
System.out.println("My Name is "+Thread.currentThread().getName());
}
public static void main(String[] args)
{
new Thread(new MyThread()).start();
}
}
执行后将打印出：
My Name is Thread-0
你也可以创建多个线程，像下面这样
new Thread(new MyThread()).start();
new Thread(new MyThread()).start();
new Thread(new MyThread()).start();
那么会打印出：
My Name is Thread-0
My Name is Thread-1
My Name is Thread-2
看了上面的结果，你可能会认为线程的执行顺序是依次执行的，但是那只是一般情况，千万不要用以为是线程的执行机制；影响线程执行顺序的因素有几点：首先看看前面提到的优先级别
public class MyThread implements Runnable
{
public void run()
{
System.out.println("My Name is "+Thread.currentThread().getName());
}
public static void main(String[] args)
{
Thread t1=new Thread(new MyThread());
Thread t2=new Thread(new MyThread());
Thread t3=new Thread(new MyThread());
t2.setPriority(Thread.MAX_PRIORITY);//赋予最高优先级
t1.start();
t2.start();
t3.start();
}
}
再看看结果：
My Name is Thread-1
My Name is Thread-0
My Name is Thread-2
线程的优先级分为10级，分别用1到10的整数代表，默认情况是5。上面的t2.setPriority(Thread.MAX_PRIORITY)等价与t2.setPriority(10）
然后是线程程序本身的设计，比如使用sleep,yield,join，wait等方法（详情请看JDKDocument)
public class MyThread implements Runnable
{
public void run()
{
try
{
int sleepTime=(int)(Math.random()*100);//产生随机数字，
Thread.currentThread().sleep(sleepTime);//让其休眠一定时间，时间又上面sleepTime决定
//public static void sleep(long millis)throw InterruptedException （API）
System.out.println(Thread.currentThread().getName()+" 睡了 "+sleepTime);
}catch(InterruptedException ie)//由于线程在休眠可能被中断，所以调用sleep方法的时候需要捕捉异常
{
ie.printStackTrace();
}
}
public static void main(String[] args)
{
Thread t1=new Thread(new MyThread());
Thread t2=new Thread(new MyThread());
Thread t3=new Thread(new MyThread());
t1.start();
t2.start();
t3.start();
}
}
执行后观察其输出：
Thread-0 睡了 11
Thread-2 睡了 48
Thread-1 睡了 69
上面的执行结果是随机的，再执行很可能出现不同的结果。由于上面我在run中添加了休眠语句，当线程休眠的时候就会让出cpu，cpu将会选择执行处于runnable状态中的其他线程，当然也可能出现这种情况，休眠的Thread立即进入了runnable状态，cpu再次执行它。
[线程组概念]
线程是可以被组织的，java中存在线程组的概念，每个线程都是一个线程组的成员,线程组把多个线程集成为一个对象,通过线程组可以同时对其中的多个线程进行操作,如启动一个线程组的所有线程等.Java的线程组由java.lang包中的Thread——Group类实现.
ThreadGroup类用来管理一组线程,包括:线程的数目,线程间的关系,线程正在执行的操作,以及线程将要启动或终止时间等.线程组还可以包含线程组.在Java的应用程序中,最高层的线程组是名位main的线程组,在main中还可以加入线程或线程组,在mian的子线程组中也可以加入线程和线程组,形成线程组和线程之间的树状继承关系。像上面创建的线程都是属于main这个线程组的。
借用上面的例子，main里面可以这样写：
public static void main(String[] args)
{
/***************************************
ThreadGroup(String name)
ThreadGroup(ThreadGroup parent, String name)
***********************************/
ThreadGroup group1=new ThreadGroup("group1");
ThreadGroup group2=new ThreadGroup(group1,"group2");
Thread t1=new Thread(group2,new MyThread());
Thread t2=new Thread(group2,new MyThread());
Thread t3=new Thread(group2,new MyThread());
t1.start();
t2.start();
t3.start();
}
线程组的嵌套，t1,t2,t3被加入group2,group2加入group1。
另外一个比较多就是关于线程同步方面的，试想这样一种情况，你有一笔存款在银行，你在一家银行为你的账户存款，而你的妻子在另一家银行从这个账户提款，现在你有1000块在你的账户里面。你存入了1000，但是由于另一方也在对这笔存款进行操作，人家开始执行的时候只看到账户里面原来的1000元，当你的妻子提款1000元后，你妻子所在的银行就认为你的账户里面没有钱了，而你所在的银行却认为你还有2000元。
看看下面的例子：
class BlankSaving //储蓄账户
{
private static int money=10000;
public void add(int i)
{
money=money+i;
System.out.println("Husband 向银行存入了 [￥"+i+"]");
}
public void get(int i)
{
money=money-i;
System.out.println("Wife 向银行取走了 [￥"+i+"]");
if(money<0)
System.out.println("余额不足！");
}
public int showMoney()
{
return money;
}
}
class Operater implements Runnable
{
String name;
BlankSaving bs;
public Operater(BlankSaving b,String s)
{
name=s;
bs=b;
}
public static void oper(String name,BlankSaving bs)
{
if(name.equals("husband"))
{
try
{
for(int i=0;i<10;i++)
{
Thread.currentThread().sleep((int)(Math.random()*300));
bs.add(1000);
}
}catch(InterruptedException e){}
}else
{
try
{
for(int i=0;i<10;i++)
{
Thread.currentThread().sleep((int)(Math.random()*300));
bs.get(1000);
}
}catch(InterruptedException e){}
}
}
public void run()
{
oper(name,bs);
}
}
public class BankTest
{
public static void main(String[] args)throws InterruptedException
{
BlankSaving bs=new BlankSaving();
Operater o1=new Operater(bs,"husband");
Operater o2=new Operater(bs,"wife");
Thread t1=new Thread(o1);
Thread t2=new Thread(o2);
t1.start();
t2.start();
Thread.currentThread().sleep(500);
}
}
下面是其中一次的执行结果：
---------first--------------
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Husband 向银行存入了 [￥1000]
看到了吗，这可不是正确的需求，在husband还没有结束操作的时候，wife就插了进来，这样很可能导致意外的结果。解决办法很简单，就是将对数据进行操作方法声明为synchronized,当方法被该关键字声明后，也就意味着，如果这个数据被加锁，只有一个对象得到这个数据的锁的时候该对象才能对这个数据进行操作。也就是当你存款的时候，这笔账户在其他地方是不能进行操作的，只有你存款完毕，银行管理人员将账户解锁，其他人才能对这个账户进行操作。
修改public static void oper(String name,BlankSaving bs)为public static void oper(String name,BlankSaving bs)，再看看结果:
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Husband 向银行存入了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
Wife 向银行取走了 [￥1000]
当丈夫完成操作后，妻子才开始执行操作，这样的话，对共享对象的操作就不会有问题了。
[wait and notify]
你可以利用这两个方法很好的控制线程的执行流程，当线程调用wait方法后，线程将被挂起，直到被另一线程唤醒（notify）或则是如果wait方法指定有时间得话，在没有被唤醒的情况下，指定时间时间过后也将自动被唤醒。但是要注意一定，被唤醒并不是指马上执行，而是从组塞状态变为可运行状态，其是否运行还要看cpu的调度。
事例代码：
class MyThread_1 extends Thread
{
Object lock;
public MyThread_1(Object o)
{
lock=o;
}
public void run()
{
try
{
synchronized(lock)
{
System.out.println("Enter Thread_1 and wait");
lock.wait();
System.out.println("be notified");
}
}catch(InterruptedException e){}
}
}
class MyThread_2 extends Thread
{
Object lock;
public MyThread_2(Object o)
{
lock=o;
}
public void run()
{
synchronized(lock)
{
System.out.println("Enter Thread_2 and notify");
lock.notify();
}
}
}
public class MyThread
{
public static void main(String[] args)
{
int[] in=new int[0];//notice
MyThread_1 t1=new MyThread_1(in);
MyThread_2 t2=new MyThread_2(in);
t1.start();
t2.start();
}
}
执行结果如下：
Enter Thread_1 and wait
Enter Thread_2 and notify
Thread_1 be notified
可能你注意到了在使用wait and notify方法得时候我使用了synchronized块来包装这两个方法，这是由于调用这两个方法的时候线程必须获得锁，也就是上面代码中的lock[]，如果你不用synchronized包装这两个方法的得话，又或则锁不一是同一把，比如在MyThread_2中synchronized(lock)改为synchronized(this),那么执行这个程序的时候将会抛出java.lang.IllegalMonitorStateException执行期异常。另外wait and notify方法是Object中的，并不在Thread这个类中。最后你可能注意到了这点：int[] in=new int[0];为什么不是创建new Object而是一个0长度的数组，那是因为在java中创建一个0长度的数组来充当锁更加高效。
Thread作为java中一重要组成部分，当然还有很多地方需要更深刻的认识，上面只是对Thread的一些常识和易错问题做了一个简要的总结，若要真正的掌握java的线程，还需要自己多做总结 -
关于函数lr_eval_string
2008-10-21 16:20:24
-
SQA简介
2008-10-21 15:05:54
SQA
软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
软件质量保证的目的是使软件过程对于管理人员来说是可见的。它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些将使软件项目满足机构方针的要求。
一、基本目标
目标 1: 软件质量保证工作是有计划进行的。
目标 2: 客观地验证软件项目产品和工作是否遵循恰当的标准、步骤和需求。
目标 3: 将软件质量保证工作及结果通知给相关组别和个人。
目标 4: 高级管理层接触到在项目内部不能解决的不符合类问题。
二、QA的由来
我们知道，国外很多的大公司，QA的职责就是测试（主要是系统测试），比如IBM、CA、PeopleSoft等。其实在最初，几乎所有的公司都是这样的。后来，由于缺乏有效的项目计划和项目管理，留给系统测试的时间很少（注：我以前做的一个项目，项目经理就明确告诉我系统测试就1天，没得商量）。另外，需求变化太快，没有完整的需求文档，测试人员就只能根据自己的想象来测试。这样一来，测试就很难保障产品的质量，事先预防的QA职能就应运而生。
事先预防其实是借鉴了TQM的思想，而且也符合软件工程“缺陷越早发现越早修改越经济”的原则。这些思想的渊源还可以追溯到中国古代的典故中，比如曲突徙薪、扁鹊论医术等。特别是扁鹊论医术这个典故，我偶然在国外的一篇文章中看到了（后来在林锐的文章中也看到了），常感叹我们国人连祖先的思想文化遗产都丢的差不多了。
三、QA的现在
目前，实施CMM的企业越来越多了。CMM模型就要求建立QA角色。这里的QA类似于过程警察，主要职责是，检查开发和管理活动是否与已定的过程策略、标准和流程一致，检查工作产品是否遵循模板规定的内容和格式。在这些企业中，一般还要求QA独立于项目组，以保障评价的客观性。从国内来看，多数的QA没有技术背景，检查出的偏差多为鸡毛蒜皮，再加上自己没有令人信服的背景，领导也不支持，当然做起来就很困难了。
缺乏信任和支持只是一个方面，QA工作本身就很具挑战性。它要求QA具有软件工程的知识、软件开发的知识、行业背景的知识、数理统计的知识、项目管理的知识、质量管理的知识等等。
我们常常遇到这样的问题，改进到一定程度就很难突破，感觉心有余而力不足了，就开始郁闷了。后来通过学习、培训、交流，思想和技能得到升华，又发现了木桶中最短的那块，然后又开始改进，然后又遇到了玻璃天花板，然后……就这样处于郁闷的循环中。
假使我们掌握了所有的知识，能突破所有的玻璃天花板，那是不是QA就可以一帆风顺了。答案是否定的。QA角色定义本身就有很大的局限性。QA充当的是过程警察的角色，无论是否有意义，都专横地强制过程的执行，容易在项目组中造成敌对的关系，受到排挤，而且这种警察的姿态也破坏了团队精神。如此一来，QA工作还需要的是人际关系技能，就如我以前写的《质量平衡》和《QA应该独立于项目组吗？》一样，艺术化地处理这种关系。
四、QA的未来
从某种程度上说，独立的QA审查机制是瀑布模型的产物。随着现代软件开发技术的演变，螺旋模型和迭代模型的兴起，QA机制正在悄然发生变化。这种变化就是从独立专职的QA向贯穿过程的兼职QA演变。在CMMI模型中，这种兼职的QA也是被允许的。为什么会发生这种改变呢？无论是XP、RUP还是其它先进的方法论，都是先产生架构，然后再增量开发，直到完成。这种模式中，需求和设计缺陷在各个迭代周期被所尽早发现和修复，质量也内建于架构和过程中，项目的成本和进度也得到保障。
到那时，是不是独立的QA就不复存在了呢？有些成熟度较低的企业还是需要的，主要是保证过程执行的有效性和评价的客观性。
五、SQA的理论探索
1、过程的认识
我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道 IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA 工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。
软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 “人、过程、技术”。首先要明确的是这三个因素中，人是第一位的。
现在许多实施 CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。 “XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。
根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 “要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。
如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：
（1）质量重要
（2）规模较大
这是 CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。
上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨论 SQA。
2、生产线的隐喻
如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。 SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。
抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 “决策、执行、反馈”三个重要方面。
QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。
3、SQA和其他工作的组合
在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。根据 hjhza 的意见“中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。
下面根据本人经验对它们之间的关系进行一个说明。
4、QA和QC
两者基本职责
QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；注意区别检查和审计的不同
检查：就是我们常说的找茬，是挑毛病的；审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。
对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。
在这样的分工原则下， QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。
如果企业原来具有 QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。
5、QA和SEPG
两者基本职责
SEPG：制定过程，实施过程改进；
QA： 确保过程被正确执行SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。
QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。
如果企业的 SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进；但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。
管理过程比较成熟的企业，因为企业的文化和管理机制已经健全， SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。
另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的 SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选；这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。
这种情况在许多 CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因；因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛！6、QA和组织级的监督管理
有的企业为了更好的监督管理项目，建立了一个角色，我取名为 “组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。
为了有效管理项目， “组织级的监督管理者”必须分析项目的数据。
他们的职责对照上图的模型，就是执行 “反馈”职能。
QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。
如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理；而 QA来确保这个管理过程的运行。
五、SQA的工作内容和工作方法
1、 计划
针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：
有重点：依据企业目标以及项目情况确定审计的重点
明确审计内容：明确审计哪些活动，那些产品
明确审计方式：确定怎样进行审计
明确审计结果报告的规则：审计的结果报告给谁2、审计/证实
依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。
注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。
审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。3、问题跟踪
对审计中发现的问题，要求项目组改进，并跟进直到解决。
六、SQA的素质
过程为中心：应当站在过程的角度来考虑问题，只要保证了过程， QA就尽到了责任。服务精神：为项目组服务，帮助项目组确保正确执行过程
了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识了解开发：对开发工作的基本情况了解，能够理解项目的活动
沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。
七、SQA活动软件质量保证（SQA）是一种应用于整个软件过程的活动，它包含：
1、一种质量管理方法
2、有效的软件工程技术（方法和工具）
3、在整个软件过程中采用的正式技术评审
4、一种多层次的测试策略
5、对软件文档及其修改的控制
6、保证软件遵从软件开发标准
7、度量和报告机制
SQA与两种不同的参与者相关 —— 做技术工作的软件工程师和负责质量保证的计划、监督、记录、分析及报告工作的SQA小组 。
软件工程师通过采用可靠的技术方法和措施，进行正式的技术评审，执行计划周密的软件测试来考虑质量问题，并完成软件质量保证和质量控制活动。
SQA小组的职责是辅助软件工程小组得到高质量的最终产品。SQA小组完成:
（1）为项目准备SQA计划。该计划在制定项目规定项目计划时确定，由所有感兴趣的相关部门评审。
·需要进行的审计和评审；
·项目可采用的标准；
·错误报告和跟踪的规程；
·由SQA小组产生的文档；
·向软件项目组提供的反馈数量。
（2）参与开发项目的软件过程描述。评审过程描述以保证该过程与组织政策，内部软件标准，外界标准以及项目计划的其他部分相符。
（3）评审各项软件工程活动，对其是否符合定义好的软件过程进行核实。记录、跟踪与过程的偏差。
（4）审计指定的软件工作产品，对其是否符合事先定义好的需求进行核实。对产品进行评审，识别、记录和跟踪出现的偏差；对是否已经改正进行核实；定期将工作结果向项目管理者报告。
（5）确保软件工作及产品中的偏差已记录在案，并根据预定的规程进行处理。
（6）记录所有不符合的部分并报告给高级领导者。
八、正式技术评审（FTR）
正式技术评审是一种由软件工程师和其他人进行的软件质量保障活动。
1. 目标：
(1) 发现功能、逻辑或实现的错误
(2) 证实经过评审的软件的确满足需求
(3) 保证软件的表示符合预定义的标准
(4) 得到一种一致的方式开发的软件
(5) 使项目更易管理
2、评审会议
3-5人参加，不超过2小时，由评审主席、评审者和生产者参加，必须做出下列决定中的一个 :
（1）工作产品可不可以不经修改而被接受；
（2）由于严重错误而否决工作产品；
（3）暂时接受工作产品。
3、评审总结报告、回答
评审什么？由谁评审？结论是什么？
评审总结报告是项目历史记录的一部分，标识产品中存在问题的区域，作为行政条目检查表以指导生产者进行改正。
4、评审指导原则
（1）评审产品，而不是评审生产者。注意客气地指出错误，气氛轻松。
（2）不要离题，限制争论。有异议的问题不要争论但要记录在案。
（3）对各个问题都发表见解。问题解决应该放到评审会议之后进行。
（4）为每个要评审的工作产品建立一个检查表。应为分析、设计、编码、测试文档都建立检查表。
（5）分配资源和时间。应该将评审作为软件工程任务加以调度。
（6）评审以前所做的评审
九、统计软件质量保证
1、对所有错误进行分类统计
IES 规约不完整或规格说明错
MCC 未理解用户意图
IDS 故意偏离规格说明
VPS 违背编程标准
EDR 数据表示有错
ICI 构件接口不一致
EDL 设计逻辑有错
IET 测试不完全或有错
IID 不准确或不完整的文档
PLT 设计的程序设计语言翻译错
HCI 不清晰或不一致的人机界面
MIS 杂项错误
按严重，一般和微小级别统计各类错误的次数所占百分比，以及所有错误的数量及百分比。例如，建立一张类似如下的表格。
然后考虑“重要少数”的错误指标，提出改进意见。
2、根据软件过程中的每个步骤计算错误指标。
Ei = 第i发现的错误总数
Si = 严重错误数
Mi = 一般错误数
Ti = 微小错误数
PS = 第i步的产品规模( LOC，设计陈述，文档页数)
Ws，Wm，Wt分别是严重，一般，微小错误的加权因子, 推荐取值，Ws=10，Wm=3，Wt=1
软件工程 在过程的每一步中，计算各阶段的阶段指标
PIi = Ws（Si / Ei）+Wm（Mi / Ei）+Wt（Ti / Ei）
错误指标
Ei= ∑（i×PIi）/ PS
=（PI1 + 2PI2 + 3PI3 + … + i*PIi）/ PS
错误指标与上面表格中收集的信息相结合可以得出软件质量整体改进指标。七、质量保证与检验
确保每个开发过程的质量，防止把软件差错传播到下一个过程，因此，检验的目的有两个：
1．切实搞好开发阶段的管理，检查各开发阶段的质量保证。
2．预先防止软件差错给用户造成损失。
检验的类型有:
1．供货检验：对委托外单位承担开发作业，而后买进或转让的构成软件产品的部件，规格说明，半成品或产品的检查。
2．中间检验 / 阶段评审
目的是为了判断是否可进入下阶段进行后续开发，避免将差错传播到后续工作中。
3．验收检验：
确认产品是否已达到可以进行产品检验的质量要求。
4．产品检验：
判定向用户提供的软件产品是否达到令人满意的程度。
十、检验项目内容
1．需求分析
需求分析→功能设计→实施计划
检查：开发目的；目标值；开发量；所需资源；各阶段的产品作业内容及开发体制的合理性。
2．设计
结构设计→数据设计→过程设计
检查：产品的计划量与实际量；评审量；差错数；评审方法，出错导因及处理情况，阶段结束的判断标准。
3．实现
程序编制→单元测试→集成测试→确认测试.检查内容除上述外，加测试环境及测试用例设计方法。
4．验收
说明书检查；程序检查。
1．3质量保证实施
软件质量评价标准。
1．质量需求准则：着眼点是是否满足用户的要求
2．质量设计准则：开发者在设计实现时是否按软件需求保证了质量
3．质量度量准则：为质量度量规定了一些检查项目:
精密度量：根据质量度量准则进行详细度量
全面度量
简易度量
五个实施步骤
1．Target：以用户需求和开发任务为依据，对质量需求准则，质量设计准则的质量特性设定质量目标进行评价。
2．Plan：设定适合于待开发软件的评测检查项目，一般设定20—30个。
3．DO：在开发标准和质量评价准则的指导下，制作高质量的规格说明书和程序。
4．Check：以Plan阶段设定的质量评价准则进行评价，算出得分，以质量图的形成表示出来，比较评价结果的质量得分和质量目标看其是否合格。
5．Action：对评价发现的问题进行改进活动，重复Plan到Action的过程直到开发项目完成。
1．4 软件可靠性
可靠性统计定义：
在给定的环境和给定的时间间隔内，按设计要求成功运行程序的概率。
二、软件可靠性的主要指标
MTBF —— 平均故障间隔时间
MTTF —— 平均故障时间
MTTR —— 平均修复时间
MTBF = MTTF + MTTR
软件可用性是指在某个给定时间点程序能够按照需求执行的概率。
可用性 = MTTF /（MTTF+MTTR）×100%
1．5 ISO9000 质量标准
ISO9000标准被很多国家采用，包括欧盟的所有成员，加拿大、墨西哥、美国、澳大利亚、新西兰和太平洋区域。为了注册成为ISO9000中包含的质量保证系统模型中的一种，一个公司的质量系统和操作应该由第三方审计者仔细检查，查看其标准的符合性以及操作的有效性。成功注册之后，这一公司将收到由审计者所代表的注册实体颁发的证书。此后，每半年进行一次检查性审计。
ISO9001是应用于软件工程质量保证标准。这一标准中包含了高效的质量保证系统必须体现的20条需求。因为ISO9001标准，适用于所有的工程行业，因此，为帮助解释该标准在软件过程中的使用而专门开发了一个ISO指南的子集ISO9000—3。
ISO9001描述的需求涉及到管理责任，质量系统，合约评审，设计控制，文档和数据控制，产品标识和跟踪，过程和控制，审查和测试，纠正和预防性动作，质量控制记录，内部质量审计，培训，服务以及统计技术的主题. -
魔兽三秘籍,哈哈
2008-08-13 09:35:29
-
HP总裁孙振耀退休时的一封信-人生
2008-07-16 09:39:36
-
本科差点没能毕业，工作五年后年收入过百万
2008-07-04 17:42:13
-
【转贴】理解Java ClassLoader机制
2008-06-24 12:22:39
标题搜索
我的存档
数据统计
- 访问量: 192763
- 日志数: 75
- 文件数: 4
- 建立时间: 2008-06-23
- 更新时间: 2013-05-08
