论文答辩准备工作(转)

导师的答辩建议。

我的一些个人体会：毕业论文答辩首先是基于之前相当长一段时间的论文工作，有了这些坚实的论文工作成果才会有好的答辩效果。但有些同学虽然有了相当好的论文工作基础，却在答辩时没有得到很好的发挥。我觉得一些常见的原因是：

1、介绍论文工作的PPT制作不精良。常见问题包括：

1.1) 未能根据自己个人喜好和论文主题选择一种好的PPT风格。其实Microsoft PowerPoint已经定义了许多可用的模板；有了这些模板后尽量不要再更改其中的风格（字体、大小、颜色、背景等），除非你对自己的审美感很有信心 （呵呵，譬如你找的GF大家都觉得很PP）。

1.2) PPT的封面没有表达足够的信息。譬如：中山大学的规范化Logo（让观众感觉到你是为自己的学校而感到自豪的）、自己的论文题目、自己的个人信息（学 号、姓名、院系、专业、email联系方式等）、指导老师信息（不是每一答辩场合都允许写明自己的导师，有些答辩会要求你在介绍中避免暴露导师的任何信 息）等。

1.3) 如果在封面上注明当天的时间（甚至地点），这会让观众觉得你是很用心地专为这次presentation而准备了PPT。

1.4) 在每一逻辑段（譬如章节），都展示同一张完整的outline（大纲），在outline中用明显颜色或字体标注下面要讲的章节，从而将一个PPT内容分 而治之地组织起来。也许有其他的方案，但无论何种技巧，你都需要将PPT的内容有机地划分，特别是内容较多时。

1.5) 在每一页PPT内容中，特忌讳有一大段的文字。PPT只适合写提纲式要点，而不适合写整段的文字。这是一些同学从论文制作PPT中很常见的缺陷，也是copy-paste这种anti-pattern的易发毛病。

1.6) 在右下角注明每页PPT的页号和总页号。页号的作用自不必说，总页号有助于观众和你自己了解你现在讲的进度如何；这也是经验不足学生易犯的毛病。

1.7) 与写论文不同，若在PPT中有引用某一参考文献，最好直接用小字体将参考文献写在本页的最下方；如果你还是像论文那样写个[n]引用参考文献，那么观众的期望自然变失望了。

1.8) 可利用写在母版上的篇眉标注作者和论文题目等信息，但不宜太突出之。

1.9) 制作一个PDF版本作为备份。因为Microsoft PowerPoint版本兼容的问题，你在家可以好好播放的PPT可能到了展示的场合却会死机；多做一个PDF格式的备份可在此时避免尴尬。

1.10) PPT应该有一个封底，通常写一些感谢答辩委员指导之类的话。

2、在演讲过程中应注意的事项：

2.1) 切忌在presentation时对着PPT中的文字来念。我知道作为一个学生，通常不喜欢这样上课的老师，因而可推断答辩委员也不会喜欢学生这种风格的宣讲。更要命的是，有些答辩委员可能会认为你根本没有准备，而从能力不足问题上升到态度不好问题。

2.2) 演讲时，大多数时间应面对答辩委员，而不要过多地低头看控制台电脑或与答辩委员同一方向看投影。呵呵，除非你觉得自己的发型太有型了，想让答辩委员多看几眼。

2.3) 在演讲前准备好笔和纸，这样在演讲后答辩委员提问时，可以做一些记录。能够让答辩委员无障碍地问完问题（不打断人家的发问也是一种礼貌），你再连续地解答这几个问题，本身也展现了你的素质和风采。

2.4) 由于答辩时间的限制，你通常没有机会演示你的实验系统或原型系统（即使你提前安装好系统也没有足够的时间演示），因而预先制作好两、三分钟的屏幕录像并为 之配音，在演讲的最后留下少许时间让答辩委员看看你的小电影是非常有益的，这有助于答辩委员相信你真的如论文中所言地完成了实验系统。

2.5) 一定要学会控制演讲的进度。有些答辩小组组长会严格按规定控制时间，这样的话如果进度控制不好就会导致自己最关键的东西还没有讲完就被停止发言了。为每页PPT编制页号和总页数有助于你控制进度。

3、当然，上面的都是形式上的东东，最关键的肯定是在presentation时说什么了：

3.1) 我建议用“提出问题 -> 分析问题 -> 解决问题 -> 评价结果”的思路展示你的论文，其中的“问题”是最重要的，这是你的challenge，也是你的contribution。用一两个精心设计的例子 （motivating examples）来解释你的“问题”是一种常见的技巧。

3.2) 对于应用背景、基础知识等introduction部分千万不要展开来说，好像你要做一个搞科普的志愿者似的。这些内容如果占的比例太大，会冲淡你自己的 工作，甚至让答辩委员觉得你好像都在介绍别人的东东，而自己却没有做什么工作。演讲的主要内容应是自己的工作，如果你真的投入了应该投入的时间和精力做论 文，应该有许多自己的工作需要花时间讲的；用一两句话讲完introduction部分本身就让人觉得你急着把别人的已有工作介绍完，是因为你需要留下大 量时间来介绍自己的工作。

3.3) 一定要强调自己有什么contribution，即自己在理论、方法、技术、工具等方面有什么贡献。

3.4) 一定要强调自己所解决的问题是有challenge的，如果是一个让人感觉太trivial的问题，其解决方案是显而易见的，那么你的工作意义就不大了。

3.5) 一定要有related work的介绍以及与你的论文工作成果的比较。如果没有这一部分，会全人一种闭门造车的感觉。

3.6) 一定要有evaluation部分。通常你需要论证你做的论文工作解决了你在论文中提出的问题，但是否真的如你所言般解决了问题呢，这需要 evaluation。一种evaluation是从理论上建模并进行推导、证明；譬如说你在论文提出的某种算法改进了原算法的时间性能，那你可以通过算 法分析从理论上证明诸如从O(n*n)改进为O(n*log.n)等。另一种evaluation是通过实验的设计和执行、数据收集与分析得出结论，例如 通过算法的实际执行时间的图表（论文中应该图、表兼有，但PPT中最好有图就够了）支持你的结论；如果你能够对Empirical Software Engineering有一些基本知识，那么实验结果会表述得更好。将两种evaluation同时做好，更有利于让读者或答辩委员觉得你的论文结论令人 信服。

3.7) 在介绍自己的方案设计时，最好展示一个完整的design space，不要让人觉得你好像只知道这一种设计方案而不知有其他可选的设计似的。注意design本身就是一个trade-off and consequence的过程！

最近太多事情，没有时间写再多了。

欢迎各位老师也根据自己的经验给同学一些建议；欢迎各位同学拍砖。

javascript input 计时激活

qqqq:<input name="aaa" disabled type="submit" id="move_check_btn" value="点击重新激活" />

<script language="javascript">
var activeTime = 8;

if( activeTime > 0 ) {
document.getElementById("move_check_btn").disabled=true;
var timer = setInterval('flush()', 1000);
} else {
document.getElementById("move_check_btn").disabled=false;
}
function flush(){
document.getElementById("move_check_btn").value=activeTime + '秒后重新激活';
activeTime--;
if(activeTime <= 0) {
clearInterval(timer);
document.getElementById("move_check_btn").value='点击重新激活';
document.getElementById("move_check_btn").disabled = false;
}
}
</script>

M&P项目个人数据

1. 工期
工期2009年2月16号 到 2009年4月21号为止。
共46.5d折合工时344h

2. 功能点
27个wbs工作单元(简单认为function point)
344/27 = 12h/FC

12个UC
344/12 = 28h/UC

2.5FC/UC

永远的Sun

2009年4月20号 Sun 走完历程：

初始化是有顺序的

public class Abc{
private static Abc abc = new Abc();
private static Map STORE = new HashMap();

private Abc() {
_init();
}
public static Abc createAbc() {
return abc;
}

/**
* 初始化
*/
private void _init() {
STORE.size();//报Null异常
}
}

把代码中的2句颠倒即可：
private static Abc abc = new Abc();
private static Map STORE = new HashMap();
->
private static Map STORE = new HashMap();
private static Abc abc = new Abc();

这是初始化时，先执行了new Abc()，在Abc里再执行_init，所以还没有执行STORE赋值，所以为Null。

jvm知识点还真多

没记错的话这是出自bluedavy之手。

印度项目质量管理经验

对于没有任何流程的软件公司来说还是有参考意义。

原作者:佚名 由网友:转载


　　计算机和通信技术的迅速发展，特别是Internet技术的发展与普及，为企业内部、企业与外部提供了 快速、准确、可靠的信息交流渠道。信息化企业运作管理系统已成为企事业单位参与全球市场竞争的必备支持系统。正是由于这样的市场需求与技术发展现状，为我 国的IT行业带来了空前发展的机遇，特别是软件行业。软件企业能否抓住这样一个难得的发展机会需要多方面的努力，其中软件质量保障在其发展过程中占有重要 的位置。 众所周知，印度已成为世界上软件业增长最快的国家，目前每年软件业产值达数十亿美元，并且还在以每年30%～50%的速度增长。比较我国和印度的软件产 业，就不难发现:中国拥有巨大的软件市场和世界公认的软件开发资源，在基础研究和对技术前瞻性的把握上，也有自己的优势，就整体社会经济环境而言也优于印 度。此外，中国的软件开发人员费用比较低廉，仅是世界市场的1/3左右。虽然中国人并不缺乏软件开发的天赋，但是在越来越强调规模化经营的今天，先天不足 的管理痼疾使我们举步维艰，难以摆脱小作坊式的软件开发模式。而印度软件业从一开始就立足于为美国软件企业服务，并遵循其软件开发的管理模式，与国际标准 接轨。

　　管理上的问题不能得到彻底的解决，软件的质量保障就无从谈起。笔者最近在与印度一家通过了CMM4级评估的软件公司（以下 简称A公司）进行合作的过程中，较为详细地了解了他们有关项目管理的一些详细情况，更深刻地感受到了项目管理的规范化与企业软件质量保障之间的密切关系。 下面想着重从软件企业的构架，软件项目计划、项目管理、项目经理的职责等方面对印度软件的项目管理及我国软件质量保障应注意的问题进行一些经验总结，供业 内人士参考。

　　1.软件企业的组织结构

　　(1)A公司结构

　　图1是A公司的组织结构图，同国内公司差异较大的部门有QA、SSG和人力资源部门。


　　* 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而言，首先要求他能够比他的下属看得更远一步，顺利时不盲目乐观，遇到挫折时不茫然失措，使整个团队始终保持高昂的士气。

　　总结

　 　以上结合印度软件项目管理的经验总结了一些我国软件质量保障应注意的问题。曾有人提出:这样一味地学习模仿，民族软件工业没有多大希望。但笔者认为，在 这个问题上不妨采取"拿来主义"的办法，对于好的，事实证明是成功的经验，首先是"占有"，然后才是"挑选"和"创新"。如果能把印度的管理经验真正领会 并付诸实践，相信对我们的民族软件工业一定会起到积极的推动作用。