软件测试项目心得体会

关键词： 软件测试 结题 时间 项目

软件测试项目心得体会（精选6篇）

篇1：软件测试项目心得体会

软件项目心得体会

时间总是不经意间从身边溜走，从立项到现在，已经过去有一年左右的时间了。随着我们一起成长的还有我们的项目，现在我们的项目也来到了结题的时间。回想当初刚刚立项时我们还很迷茫，虽然有满腔热情，但是一切都还是未知的，我们需要一点一点地去探索，一点一点地去发现。到了现在，我们的项目马上就要结题了，我们没有像以前那样迷茫，我们已经有了清晰的目标，有了完整的方案，也有了具体的实施方法。当然没有任何人可以一下子就成功，这中间我们有过很多次失败，经历过很多坎坷，可是这些都没有阻挡我们的探索。在这一年当中我们虽然会觉得困难，但是，不可否认的是我们的确在这过程中收货了很多，也学习了很多。

每当在我们的项目进行过程中遇到难以解决的困难时，我们只能自己去寻找多方资源来帮助自己。比如，去网上找各种相关文献进行查阅，去学习新的不懂的技术，去图书馆查阅资料。这应该是我们在这个过程中收获最大的地方，因为我们获取了很多额外的知识，有时候经历过实践的知识总是更能让人记忆深刻。从最开始的寻找课题到申请立项、撰写项目申请书，再到确定研究目的和寻找创新点，并制定详细的实施方案和步骤，对项目进行相关调查和研究，到最后确定项目的可行性、创业计划书的编制等等，这一步步走来，艰难心酸有，但是收获的经验和成长也只有经历过的人才会分享和拥有。我们只能说，我们绝对不会后悔参加过这个项目。

作为这个项目的参与者我觉得，这个项目最大的特点就是它不是一个人单独完成的，它需要整个团队的合作。那么如何调配整个团队的各个人员，给每个人分配相应的任务是很重要的。不是说越精细的分工，才能有越完美的作品嘛。管理好一个团队是很不容易的，也是很锻炼人的。可能团队中的成员，性格迥异，互相之间关系不够融洽；可能在经历了一段时间低谷后，团队的斗志削减的很厉害；可能大家在对待项目这个问题上，都打着自己的小算盘，个人的顾虑成为了项目成功道路上的绊脚石。因此，队长在这里面起着很大的作用，可以说是整个团队的核心，但是好的队员的也是不可或缺的一部分。这就像一台正在高速运转的机器缺了哪一个部件都是不行的。所以说，这就需要我们进行经常的沟通，分享大家的意见和想法及时的做出相应的对策。于是乎，这一年来我们开了大大小小很多会议，每一次，我们都是在讨论中得到结果。对于我们这些大学生将来势必是要走上职场的，那么无论我们以后是从事哪一方面的工作，想必团队协作都是必不可少的一部分。那么这次对我们来说都是一次很好的积累经验的机会。再有就是，这个项目不像我们的实验课一样，它没有教材，没有老师按部就班的指导。我们都知道现在的学生总是习惯于在教室里在课本上学习知识，所以在一定程度上是缺乏创新方面的思维的。也是在做这个项目的过程中，我深刻地意识到自我动手能力的重要性。或许是因为，无论发生什么都需要我们自己解决。所以在这个过程中，每个人都尽可能的发挥了自己的能动性，我们每个人都在积极的思考，努力的寻找解决的办法，努力的寻求创新点。自然而然的，我们都在一定程度上学会了独立解决问题也养成了这种意识，不再有以前一遇到问题就想去问人的冲动了。就像有人曾今说过一样，不要做意见和答案的乞讨者，现成的答案有可能会禁锢人的思维。人类的智慧是无穷无尽的，创新也是无穷无尽的，说不定我们就会创造奇迹呢。

说实话，一开始的时候我们的构想和现在差的很多。就像我们的创造心理学的老师说过的一样，我们只是在做发散性思维，而不是在做创新。因为创新它是有逻辑的，它不是漫天空想。可能我们刚开始就是处在这个阶段。在之后经历了一段空想的日子，我们才学会静下心来，好好思考。切实的根据我们自己的能力，我们现有的资源，真正的定下了目标。然后按照我们的计划一步步规划，一步步向着成功迈进。当然后来我们的项目也在随着进度做相应的改善，但它绝对不会像最初那样被我们全盘否定。这也让我们所有人都学会了“现实”。也就是说创新也是需要切合实际的，理论要与实际相结合，任何事情都需要我们以实际为基准点再进行接下来的所谓创新，所谓发展。

最后，对这次创新创业项目我们的总结，也就是我们的收获，就是深刻认识到团队合作在一个项目中的地位的不可或缺性。当然与此同时在与项目有关的知识方面是一定会有很大的提高的。再有就是在创新意识，和创新态度上我们有了自己的理解。不在像以前一样，一提到创新就只会漫天胡想，我们学会更实际，更有可行性的创新。总而言之，很开心，能有这样的机会来提升和锻炼自己。当然不能说现在我们有多么大的成就，可是成功不就是这么一点一点累积起来的么。这有可能就是我们向着成功踏出的第一步。未来的我们一定会越做越好。

篇2：软件测试项目心得体会

软件测试项目实训这门课程，是本学期一门重要课程，对于课程的学习方面，主要是靠老师答疑和查询资料来完成的。这次我选择的是基于JAVA语言下的银行账户管理系统，这个设计在杨扬老师的指导和严格要求下完成，在本阶段学习和生活期间，也始终感受着杨杨老师的精心指导和无私的关怀，我受益匪浅。

在设计过程中我通过查阅大量有关参各种资料，与同学交流经验和网上查找信息，并向老师同学请教等方式，使自己学到了不少知识，也经历了不少艰辛，但收获同样巨大。不管学会的还是学不会的的确觉得困难比较多，真是万事开头难，不知道如何入手。此外，还得出一个结论：知识必须通过应用才能实现其价值！有些东西以为学会了，但真正到用的时候才发现是两回事，所以我认为只有到真正会用的时候才是真的学会了。

在整个过程中我从中懂得了许多东西，也培养了我独立工作的能力，树立了对自己工作能力的信心，相信会对今后的学习工作生活有非常重要的影响。而且大大提高了动手的能力，使我充分体会到了在创造过程中的探索的艰难和成功的喜悦。虽然这个项目还不是很完善，但是在设计过程中所学到的东西是这次设计的最大收获和财富，使我终身受益。在这次课程设计中，让我学会了如何去完成一个任务，去解决一个问题。当遇到问题要冷静，想办法一点一点的排除障碍，到最后获取成功，这应该就是学习的乐趣。有时候不懂的就需要问别人了，虚心请教，从别人的身上真的能学到自己没有的东西，每一次的挫折都会使我更接近成功。还有学会了在工作中与别人的合作与交流。这次课程设计在老师和同学那里学到了很多东西，使自己在处理问题方面有了很大的提高。

本设计基本实现了取款、查询余额、转账、修改密码等功能，但由于时间短、知识水平有限，经验不足，系统仍存在不足，该系统主要有以下特点：

1、程序可读性强，易懂易维护

2、用户界面简洁，方便了用户使用。

3、安全性好，系统仍然使用输入密码方式，保证了系统的安全。

4、系统稳定，基本达到预期的功能要求。

5、系统还存在着许多不足，特别是在数据库的链接上，在代码的编写上也存在着很多的不足，代码存在着很多的缺陷。

6、在系统的的界面效果上也存在不足，系统界面显示应在屏中间。本项目最大的一个不足就是运行时界面显示效果欠佳，在以后的学习中我会不断地改进，设计出漂亮的界面。课程设计中要求有扎实的理论基本知识，操作起来才顺心应手，我这时才明白什么是“书到用时方恨少”。这就激发了学习的欲望。“纸上得来终觉浅，绝知此事要躬行！”，在学习的过程中，让我深深感受到自己在实际运用中专业知识的匮乏。以前总以为自己学的还不错，一旦应用到实际就大不一样了。

篇3：软件测试项目心得体会

关于双语教学, 这早已不是个新鲜的事物了, 全国各高校包括一些高职院校均开设了一定比例的双语教学的课程, 然而我们究竟需要什么样的双语教学 (不仅仅是英文加中文解释的方法) , 通过双语教学使我们的学生到底收获什么, 这需要我们每位从事双语教学的老师在双语教学实践中不断总结和摸索的。我们南通大学计算机计算机科学与技术学院自2006年在软件工程专业的专业课《IT项目管理》里率先开展中英双语教学, 目前已上了五轮课, 掌握了大量的学生学习双语课程的情况, 我们对如何更好地开展双语教学实践活动进行一些总结和分析。

1 双语教学所用教材的选定

首先我们当初为什么会选择《IT项目管理》这门课作为双语教学试点的课程呢?我们考虑到既然是双语教学, 学生就必须具备一定的英语水准, 只有在高年级开设, 因为绝大多数学生都已通过了英语四级考试, 部分学生还通过了英语六级考试, 所以说学生们基本都具备了接受双语教学的语言条件, 另外《IT项目管理》不是一门纯技术的课程, 而是横跨计算机, 工程学, 管理学和经济学的交叉学科, 课程有很强的综合性实用性, 如果选择那些操作系统, 数据结构等理论性专业性很强的课程, 学生连中文概念都不大明白, 就更别说用直接用英文教材去学习了。我们最终还是选取了《IT项目管理》这门课程作为我们双语教学的试点课程。

学生学习最基本要素的就是要有本合适的教材, 双语教学特点之一就是要让学生学习经典的原版英文教材, 我们软件工程专业的许多课程的教材本来就是英语翻译过来的, 既然是翻译就难免有点“变味”, 所以我们坚持在双语课程里使用原版英文教材, 我们的大学生学了那么多年英文, 很多是为了通过考试而学习, 而没有主动用英文去实践, 那么使用原版英文教材就提供了让学生主动用英文去学习和思考的机会, 也体会下“原汁原味”的英文专业知识, 把英语翻译成中文再用中文去思考的学习习惯逐步变为尝试着用英文的思维习惯去学习和掌握知识, 这也是双语教学的主要目的之一, 而不是英译中的简单方法。

关于《IT项目管理》的中英文书籍也很多, 我们在众多书里确定了一本在国外高校计算机类专业使用很多的经典原版教材作为主教材, 就是McGrawHill出版社出版的JosephPhillips编写的《IT project Management, On Track from Start to Finish》, 这门书比较通俗易懂且实用性强, 作者不仅有渊博的理论知识还有丰富的实践经验, 还为许多知名大企业培训过IT项目经理。该书每章有理论介绍还有其他书没有的“From the filed” (业界观点) 部分介绍业界人士对每个理论环节的理解和认识, 这极大地帮助学生去更直观和形象地去理解理论知识。每章还附有习题和综合应用题让学生们去练习。

除了选定这本主教材外, 我们还根据每章的内容去搜集一些中英文的讲义和实际案例给学生们辅助使用。有的内容来自一些公司的培训课程, 以丰富教学的内容。我们让学生们课后精读教材, 学生们从开始看不大懂到后来很有兴趣去读完整本教材, 经过这样使用英文原版经典教材后, 学生们使用英文去阅读科技书籍和文献的能力有了很明显的提升。有的学生摄甚至认为用英文原版教材的效果比直接使用中文教材还要好, 对知识的理解更深。

2 双语教学的课堂教学的组织

选定好教材后, 最重要的教学活动就是组织课堂教学了, 我们传统的课堂教学有些是老师在上面一个人不停地讲, 学生在下面被动地听, 如果双语教学还是采用这种方法效果则会更不理想, 因为学生们不是在听他们的母语, 思想和注意力更不容易集中到老师讲的内容上来, 往往一节课下来, 学生除了听到几个新鲜的英文单词外什么都没记住和学到。

由于是使用的英文原版教材, 我们要求是课前要对上课所讲的章节阅读一遍或者几遍, 对所学内容课前有个初步的了解, 那么课上学生们才容易听懂老师讲的内容。我们在课堂上对所讲章节的重点部分用英文进行讲解, 过程中一定穿插着对同学的提问, 要和学生互动起来, 这样学生们的注意力和积极性才会被调动和激发出来, 学生们开始总是害怕用英文来回答问题, 要多鼓励学生们敢于用英语去回答问题, 后来学生们经过很多次练习后也慢慢习惯用英语来回答问题。

关于双语的双语比例问题, 到底讲多少英文和多少中文, 我们认为要根据内容而定, 不能一概而论更不是讲一遍英文再给一遍中文解释。在英文意思大家都比较懂的部分就直接全部用英文讲述, 有的英文比较难懂的部分给些相应的中文解释, 有的英文会产生好几层意思的地方我们就根据情况用中文进行讨论, 给一遍中文的表述方法, 因为有的地方用英文表述和用中文表述有不同的意境。我们总的基调是在英文的环境下进行讲解和讨论, 在必要的地方再用中文去表述去来比较两者的异同。中文是用来加深理解的, 而不是仅仅的英译中, 还是要学会慢慢用英文去思考和表述问题, 因为我们的学生将来可能要在国际化的企业工作, 其工作语言有可能就是英语, 尤其我们学院增加了的软件外包服务专业的学生, 他们将来很可能就要用英语作为其工作语言的, 我们想通过这门双语教学的课程来加强用英语交流和沟通的训练。

我们在课堂教学的环节中增加一个让学生们自己上台做讲演 (presentation) 的内容, 就是每次课中请一些同学就章节中的某个课题自己用英文做五到十分钟的演讲, 觉得用英文讲不清楚的地方就用中文来解释和描述一下, 其他学生在下面听, 有问题可以提问, 讲完后同学们用英文和中文就讲的同学作简单评价。一开始学生们自然很不适应这样的环节, 因为他们从小学读到大学从来都只是来听课的, 考试都是笔试, 从来没机会自己上台对所学知识来讲一遍, 更别说用英文讲了, 而这在国外大学里是经常有的训练。但是通过多鼓励和练习后, 同学们从没人愿意上去讲到慢慢地有同学要抢着上去作讲演, 时间从只讲一分钟不到发展成能讲了超过十分钟, 例如有个学生用英文完整地讲述里工作分解结构 (WBS) 的实施方法, 讲了十多分钟, 而且表述得很清楚到位, 这种转变是可喜的, 学生们既锻炼自己英语说的能力又加深了对书本知识的理解。

另外我们在课堂里还增加了一个案例分析 (Case Study) 的环节, 就是根据章节里的内容搜集一些相关的国内外企业在实际做IT项目的实施过程中的经典案例, 在课堂上供学生们自由讨论, 这部分内容由于是现实世界里企业中发生的各种故事没有理论知识那么枯燥, 学生们往往比较感兴趣, 但是重要的是要鼓励学生们拓展自己的开放式思维, 敢于表达自己的看法, 尤其开始用英文去讲还是有一定的困难, 我们就让学生们用英文夹杂着中文大胆地讲自己的观点, 只要敢讲就给予肯定, 让学生们自由地去发挥自己的潜能。通过对案例的分析学生们也掌握了一些自己将来在项目管理中的具体方法。

如果说使用英文原版教材课前预习有助于提高学生们英文“读”的能力, 那么课堂双语教学活动中老师和学生的互动就提高了学生们英文“听和说”的能力。

3 双语教学课后练习的安排

我们所用教材每章的背后都有一些习题, 我们要求学生们选做一些, 还每隔几周布置一个小报告 (report) , 我们鼓励学生们分组完成, 用英文撰写。为什么鼓励学生们分组做呢?因为我们的学生从小学到大学的课程里, 几乎所有的练习都是独立完成的, 从来没有团队合作的经历, 而软件工程专业的学生将来在工作岗位上往往需要与别人共同合作来完成项目, 所以通过分成若干小组来培养学生们团队合作的精神, 在小组练习里明确各自的分工与合作。

比较困难的是小组成员的分配, 我们的学生们还大多不习惯团队去合作完成一项工作, 我们开始鼓励学生自由组合, 没有落实小组的同学由老师硬性分配到各小组中, 我们布置的题目都是结合各章内容写的小的报告, 例如项目计划书, 可行性分析, 创建工作分解结构等。学生们也几乎是第一次开始用英文完整地写报告, 尽管写得比较生疏, 但是大多同学还是能按时完成, 老师就一些报告拿到课上去集体讨论, 对写得不好地方大家一起发现问题, 对写得好的地方大家共同借鉴。学生们合作精神普遍不强, 原本一起讨论完的事情, 结果大都变成了各自写一部分拼凑而成, 还有的同学在小组里根本不工作, 这个问题也很难监督, 需要我们学生的自觉性有很大的提高。

我们在理论课后还专门增加了几次上机练习课, 让同学们自己完成使用专门的项目管理的软件工具微软的“Project”的练习, 练习完后用英文写上机报告书, 加强学生动手实践的能力, 对于软件工程专业的学生来说, 这是件比较容易的事。

双语教学的课后练习是用来帮助学生提高学生英文“写”的能力, 消化和巩固所学的理论知识。

4 双语教学的其他事项

我们通过对《IT项目管理》双语教学中所学教材的选定, 课堂教学的组织以及课后练习的安排来全面提升学生实际应用英文“读, 听, 说, 写”的能力, 和英文情境下的学习和工作的能力。如何在双语教学里来考核学生的学习效果呢?采取通常的笔试方法是最简单的方法, 也客观公正, 但是不能真实全面反映学生的学习成果, 起不到促进学习的积极作用, 我们拟采取综合考量的方法, 出一部分客观题进行笔试考察学生对基本知识的掌握占40%, 另外布置一些综合应用题, 在一定时间内提交题目完成的报告 (英文) , 以考察学生对实际运用知识解决问题及英文写作的能力, 占30%, 最后学生就自己写的报告进行口头讲述 (中文和英文) , 以考察学生口头表述问题和沟通的能力, 占30%, 这种综合考察方法尽管比较全面和科学, 但组织起来需要耗费很多时间和人力。

开展双语教学的另外一个要素就是要建设一支双语教学的师资队伍, 我们南通大学计算机科学与技术学院这几年来越来越重视双语教学, 组织了一批有海外教育背景的教师, 搜集学生们的反馈意见, 根据大家在教学中发现的问题互相讨论, 共同探索出适合我们高校软件工程专业学生特点的双语教学的方法和模式, 形成了一支稳定的从事双语教学的师资队伍。另外开展双语教学活动也离不开学生和校内外各界的支持和帮助, 我们还有计划打算请IT业界人士在双语教学课程里做部分讲座, 以增加课程的实用性, 扩大学生们的视野。

5 结语

我们开展双语教学课程的目的不只是流于双语教学的这种外在形式, 而是借助于双语教学这个实践平台来给我们传统的教学作部分改革和尝试, 丰富我们的教学方法和手段, 学生通过双语教学收获了实际运用英文去学习和交流的能力与自信, 当然我们对于双语教学的认识还要在今后的教学实践中不断总结和摸索, 还要根据学生们的现实情况不断调整方法以适应学生们的变化和需求。

参考文献

[1]忻展红, 舒华英.IT项目管理[M].北京:北京邮电大学出版社, 2006.

[2]刘宏哲, 鲍泓.IT应用性教育双语教材的选用及建设[J].北京教育, 2004 (6) .

[3]张谦.双语教学论[C].香港:世界科学出版社, 2004:9.

[4]李萍, 等.依托双语教学模式促进学生素质全面提高[N].电气电子教学学报, 2006 (6) .

篇4：软件测试项目心得体会

关键词：软件实施项目；项目管理

中图分类号：TP3文献标识码：A文章编号：1007-9599 (2011) 08-0000-02

Multiple Service Providers,Software Implementation Project Management Experience of More Partners

Wu Xiaolan

(COSCO Network (Beijing) Co.,Ltd.,Beijing100031,China)

Abstract:On a multi-vendor,multi-partners in the implementation of large-scale software project management experience and understanding to explain the process of cooperation in the project,control,and other aspects of the interface elements defined for the implementation of other project management software to provide reference Comments and suggestions.

Keywords:Software implementation project;Project management

大型软件实施项目，比如一些深化应用项目，是在之前操作型软件项目的基础上，利用系统多年推广的

成果以及原始数据积累，进行企业业务应用更深层次的需求，比如现在较为流行的商务智能（BI）项目，旨在进行数据仓库（BW）建设、实现企业业务整合、财务合并、预算管理、数据分析、接口整合、门户建设以及系统监控，为领导决策提供数据依据。因项目范围大、包含内容复杂；实施项目的单位大多业务范围广泛，源头数据除了来自于早前建设的操作型软件项目，还有来自于专业财务或业务软件、专业报表系统等，数据源种类众多；而从BW数据仓库加工的数据也会导出到展示系统，如BO、久其等数据展示或系统，因此为即将实施的深化应用项目提供服务的IT服务供应商和咨询合作伙伴会有很多家，项目中与合作伙伴以及各合作伙伴之间的协调工作也就尤为重要，合作质量直接对项目成败造成影响。

合作伙伴多种多样，有的是权威原厂，有的是名不见经传的小公司；有的是民族产业，有的是国际知名世界500强。不同的企业背景和文化，在一个项目里能达到融合，确实需要一个磨合过程。项目经理可能会面临许多问题，比如客户、项目经理本身、每个合作伙伴或供应商对项目的视角和理解存在偏差；比如项目沟通渠道和路径复杂导致的沟通信息的不对称；比如项目计划制定的太理想而无法按期完工；比如项目按期完工了但质量无法保证；再比如合作伙伴比预想的实力弱而无法保证项目质量或合作伙伴太强势而无法控制。诸如此类种种，为项目管理带来不少困扰。那么究竟如何和合作伙伴合作呢？

一、项目合作，但求双赢

既然是合作，项目经理就要自始至终贯彻合作的理念，从选择合作伙伴开始就要有双赢的想法，即与合作伙伴双赢。为了实现双赢，作为甲方的项目经理应该明确项目目标和明确的工作范围，要有清晰的工作说明书（SOW）；同时从项目本身出发，了解侯选合作伙伴都有什么优缺点，合作伙伴参与项目的最大动因是什么，不同的侯选公司参与项目的核心动因往往不同，这就需要在项目目标与公司参与项目的两个目标之间要进行平衡。在考虑自己项目目标的实现的前提下，不是一味的追求自己目标的实现而不考虑合作伙伴的利益或目标。作为项目经理应始终关注两方利益与目标的平衡，才能选择最合适的合作伙伴，才能发展健康、高效的合作关系。合作伙伴带来先进的产品和解决方案，经由与我们的合作培养双方的专精人才，双方的技术和人才储备都有所提升，我们的项目成功了，合作伙伴的产品和解决方案也充实了，双赢是项目成功的前提。

二、仔细观审，知自知彼

有了双赢的思想，我们还要从多方面审核和观察，做到多方面的知己知彼。只有多方面的知已知彼，才能更加保证双赢的局面，平衡多方面的利益与目标。

在对合作伙伴的选择过程中，要了解每一个候选合作伙伴提出的各种方案的可行性，专家的参与度和承诺的可靠性，专家的水平以及以前实施过类似项目的经验等，同时统筹考虑自己方参与项目的人员经验，项目预算，相关的干系人对项目的期望等因素。我们要对候选合作伙伴提出的假设和前提逐个进行风险分析，对参与项目的主要专家一定要当面面试，明确专家参与项目的方式，并在合同中做出相应的约束。确定了SOW与公司的参与专家后，在商务谈判过程中，可能出现销售和售前夸大其词的情况，这时候要分析合作伙伴做出的承诺，一般来说对销售与售前顾问的承诺都应在合同中或工作说明书进行约束，同时还要注意不同的合作伙伴对承诺的态度不同，对一般的小公司，有可能做出不切实际的承诺，反之大公司做出的承诺可信度就高得多。另外，项目情况千差万别，合作伙伴就是再有经验，也可能遇到从没有遇见的问题，对之前的承诺大打折扣，这点需要在项目之初就和合作伙伴谈清楚，做好解决方案的制定，在项目过程中取得主动。

三、推己及人，严于律己才能严于律人

项目的实施过程中，不合理的需求或不切实际的方案都不是大家想要的。因此，作为项目经理的你也不应该将或代表将一些不切实际的承诺强加给合作伙伴，正所谓己所不欲，勿施于人，不切实际的承诺带来的结果最终是对项目的伤害。为了避免不切实际的承诺，在选择与确定合作伙伴之前一定要清晰的了解项目实施中各种方案的可行性，前提、假设等，并结合了解到的公司方参与项目的核心动因进行分析，尽可能对项目方向性风险进行评估，避免项目后期出现大的风险。只有这样，才能实现真正的双赢，同时能选到最合适的合作伙伴。不合理的需求与不切实际的方案一样，在实际的项目实施过程中有时是不可避免的，处理这类问题时也应做好甲方内部的沟通和协调工作。有时一个看似简单的需求需要项目花费大量的气力才能完成，而用户并不知情，那么就要想好折中对策后和用户进行沟通，在某种程度上说服用户采纳折中的办法。在做这样说服工作也要事先考虑周到，以理服人，否则可能既得罪用户也得罪乙方，对项目推进同样会造成极大影响。

在选定了合作伙伴、还不止一家合作伙伴后，多家合作伙伴完成同一个项目中不同的项目环节的时候，如何使不同背景、不同产品厂家、不同实施商整齐划一的完成同一个项目的任务目标，那合作伙伴之间的协调工作就非常重要。经过笔者多年的项目实施经验，总结出以下几点：

（一）项目规模控制是项目能如期上线的保证

前文提到每个参与项目的服务供应商或者合作伙伴都有参与项目的动因。在动因的驱使下，有些合作伙伴或者多个合作伙伴之中的某一个可能存在求好心切的心理从而一味迁就用户，承诺SOW之外的用户需求或者自行扩大项目范围而未考虑到用户方的相关沟通耗时，包括审批汇报、原型开发等成本对项目周期可能带来的影响。这种情况下，应该协调用户和合作伙伴，在有限的时间里先保证项目既定内容的如期上线，其他内容在维护甲方利益的前提下，签署“Change Request”（变更需求书），考虑在上线之后再进行实施。否则可能遇到的情况就是项目无法如期上线、项目质量无法保证、项目其他供应商会有怨言等问题，项目实施推进就会变得非常被动。

（二）贯彻项目全貌的同时制定清晰的工作界面

正所谓先小人而后君子，事先定好规矩强过事后互相扯皮。为各参与项目的合作伙伴定义清晰的工作界面，包括各自工作目标、内容的制定，包括两两接口的人员和规范等。如遇定义不清的地方，就多方坐下来进行商谈，直到定义清楚为止。清晰的工作界面使得每个合作伙伴都能专注于本职工作，避免在沟通协调上浪费成本。分工明确，职责清晰可大大提高项目实施的效率。项目全貌的宣传和灌输旨在让各合作伙伴了解自身在项目中所处的关键位置，服务于各自工作目标以及总体工作目标的实现。

（三）根据不同的项目实施内容在不同的项目阶段，定义主导合作伙伴

作为甲方项目经理，在项目实施过程中更多的依靠主导的合作伙伴可取的事半功倍的效果。多家合作伙伴中谁是主导的一方呢？我做过的一个深化应用项目中企业管理驾驶舱子项目，为其提供的服务的合作伙伴有三家，一家数据源（A伙伴），一家负责BW数据仓库建设，也就是数据源数据模型加工（B伙伴），一家负责BO数据展示，即加工数据的图表展现（C伙伴）。数据流向：A->B->C，需求流向：C->B->A。表面上看来主导合作伙伴非A即C，它们是流程的两端，实则不然。B作为数据的加工方才是主导的合作伙伴。对于数据，按照接收方原则，B要向A提出数据传输的规格；对于前台的报表展现，B要向C提供加工好的数据。B中数据加载、加工的效率，直接影响系统的性能。在这个项目的蓝图设计阶段，B就是主导合作伙伴。B需要提出系统最核心的系统架构和分析模型搭建架构，需要对项目的总体计划进行制定和监控。到了系统集成测试阶段，C就成为了主导合作伙伴。C要根据展示出来的结果和数据源头系统进行核对，检验数据的准确性，对于不准确的数据，C要根据和B的接口文件向B提出核对需求，B经核对无误后根据和A的接口文件向A提出核对需求，从而找出问题所在。在项目不同阶段定义主导合作伙伴后，甲方项目经理只专注主导合作伙伴的计划执行情况，而主导合作伙伴则在本阶段是工作的发起和监控权威，其他合作伙伴在主导合作伙伴的要求下完成各自相应的工作。

（四）目标统一，不分彼此

无论合作伙伴来自于什么样的企业，一旦参加项目就和甲方的派出代表形成一个项目整体，大家目标一致，就事论事，任何分歧都在桌面解决，形成良好的项目合作风气，促成项目成功。真知来自于争议和讨论，而争议越是尖锐越是到了问题快要解决的关键阶段，因此在目标一致的前提下，欢迎争议。面临同一个问题的不同解决方案，多方对比和评估，在项目组范围内无法决策的一定要快速提交到高一级别的组织进行决策，以保证项目进度不受影响。对于项目组内部可以处理解决的问题则不是高一级别组织关注的焦点。项目的结果不好，不是某一个合作伙伴的问题，项目的结果好，亦不是某一个合作伙伴的功劳。因此大家的目标是一致的，在项目工作中是不分彼此的。

（五）有始有终，项目收尾漂亮，项目才算漂亮

项目收尾除了必要的项目总结外，项目的回顾过程也很重要；回顾的重点是项目过程中问题的处理解决情况、项目文档的各个版本是否齐备、项目重大里程碑相关的文件及过程、此次项目取得的经验教训和成果。项目最终的汇报则是项目达到尾声的仪式，在这个仪式上每个参与项目的合作伙伴都要“浮出水面”，在汇报之后听取用户方代表的意见，开阔视野之后再去回顾项目的整个过程，回顾之后就会有更高的起点迈向未来。

篇5：软件测试项目心得体会

一． 项目要进行整体管理，善始善终

整个项目开始要做好项目整体计划，在项目的整个过程中，始终要按照项目计划执行，如若遇到项目发生变更，要进行影响分析，得到批准后制定变更计划，并按变更计划执行。变更的影响情况，如：费用，时间进度等要通知相关的项目利益干系人，说明变更的原因和产生的影响。

变更计划在软件项目中经常遇到。控制好软件项目的变更，首先需要做好项目的开始目标基准的确定，基准的用户需求明确，才能衡量出哪些是需要变更的。否则变更的东西和开始要求的东西混在一起，变更计划就无从制定，变更的界限也无从划清。

二． 项目范围管理的重要性

需求管理是项目范围管理中的问题，这是因为它实际上是开发过程中的所有管理原则的先决条件。只有在开发的目标被清楚明白地表述和理解的情况下，软件开发才能以一种有计划的有序的方式进行。实际上，没有文档化的需求，在开发工作完成前后都很有可能发生产品与要求的偏离。计划、追踪、配置管理以及软件质量保证这些在其他关键过程中涉及的原则，都是从一个稳定的基础开始的，那就是文档化的需求基线。

三．项目时间管理理论指导我们在项目管理中怎样抓主要矛盾

项目管理的实施最为直观的就是缩短项目时间。利用项目管理理论、方法，有许多缩短时间的例子。美国路易斯维化工厂检修时把检修流程精细分解，按导向图建立起控制关系。他们惊奇地发现，检修过程选择不同路径总时间是有差别的。通过反复压缩最长路径上的任务，将工期反复优化，最后只用７８个小时就完成了通常需１２５小时完成的检修，节省时间３８％。这就是至今项目管理工作者还在应用的著名的时间管理技术ＣＰＭ，即“关键路径法”。

所以我们在软件的项目管理中，也要将时间控制理论运用进来，结合软件工程的实际，将任务分解的更加详细，并用网络图将整个工作过程建立起来，估算好每个阶段的历时，找出关键路径，并通过快速跟进方法，将关键路径的工期缩短，以提高工效。

篇6：软件开发项目风险管理的几点体会

风险管理的达成必须包括三个要素：首先，在项目开发计划中必须制定风险管理计划；第二，在项目预算中必须包含解决风险所需的经费；第三，评估风险时，风险的影响也必须纳入项目计划中。

下面就软件开发过程中经常发生的风险，谈谈我们采取的预防措施。

2.需求不明确

需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：

(1)让用户参与开发

提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。

在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。

仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。

(2)开发用户界面原型

用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。

(3)需求讨论会议

对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求

研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。

(4)强化需求分析与评审

首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。

3.项目缺少可见性

当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成[1]。软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。

(1)n 迭代开发

采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是一些典型的迭代：

一次简短的先期迭代，以建立规模和前景并确定商业理由；

一次精化迭代，其间将为稳定的构架划定基线；

一次构建迭代，其间将实现用例并充实构架；

几次产品化迭代，将产品转移到用户群。

每次迭代，都要充分接收用户的评审意见，以便为自我纠正。渐近式的功能交付，有利于降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是最好的进展报告。

(2)技术评审

技术评审是确保软件质量的重要环节，技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查，或者是高级开发人员对普通开发人员的审查；会议评审一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业务两个方面的专家，经常性地让精通业务的用户专家参与项目评审，是项目成功的重要保证。

另外，充分利用质量审查的工具软件，也有利于提高代码质量。例如：在Eclipse开发环境中，可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。

(3)持续集成持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决[1]。

开发小组应制定持续集成的制度，一般情况下每日构建一次，可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后，及时向版本控制系统（如CVS）提交代码，而且不应该向版本控制系统提交有问题（编译通不过）的代码。

每日构建、持续集成，让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道距离整体完成还有多远。

4.新技术引入

技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术，不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。

(1)T形软件开发

在项目开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索。例如：基于JavaEE5构建全国联网售票系统，涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题，应该优先处理这些问题；对开发所涉及到的EJB3、JSF、JBoss Seam、Eclipse RCP等技术，要做深度探索。图1 在第一阶段以“T”形开发系统骨架[2]

越是技术复杂度高的项目，就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决，则为时已晚。

(2)充分论证

新技术开发是探索性很强的工作，潜在着许多失败的风险。在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。在制定决策时，情报的数量和质量致关重要。掌握的信息越多、越准确，才能作出正确的的决策，项目失败的风险也就相对减少；反之，承担的风险就会增大。

(3)同行经验

针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利用互联网，通过搜索同行经验，往往事半功倍。要充分利用世界日益平坦化的优势，对于不能尽快解决的问题，可

以先放一放，可能过不了几天，网上就有相类似问题的解决方案了。

5.技术兼容性风险

硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。往往系统集成的项目越复杂，兼容性问题就越有可能存在。

(1)设计先行

在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中，明确相关设备的技术参数和配置要求。

(2)售前产品测试

在做项目招投标工作时，要求投标方在售前提供产品兼容性测试，以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目，要在开发工作的早期，做技术兼容性测试，以避免在项目开发后期才暴露技术兼容性问题。

例如，我们在开发深圳市汽车客运站售票及站务联网调度系统时，为了确保技术兼容，在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作，并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时，暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题，如果这些问题在系统实施时才暴露或处理，势必会拖延项目进度。

6.性能问题

由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计。无论是用户还是开发者，谁都不希望出现性能问题。

(1)性能规划

在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计。在做数据库设计时，应争取DBA参与。

另外，在技术方法方面，尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等，尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题，既费钱又费时。

(2)性能测试

在开发过程中，要重视性能测试和压力测试，尽可能模拟现实使用环境，搭建测试平台。另外，由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配

置低的机器、较小的网络带宽进行测试。

(3)充足的调试时间

在项目开发计划中，为后期性能优化留有余地。在对系统进行性能优化后，要进行性能测试和压力测试，可能还要做几次回归测试。因此，应该留有充足的时间和人力。

7.仓促上线

在项目实施过程中，系统切换上线环节最容易出纰漏。项目好不容易开发完成了，却在最后最后时刻功溃一匮。如果项目小，影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。

(1)应急预案

面对各种不可预知的风险，要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周，都会做好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常工作时，准备手工票就是最坏的打算。

(2)分步切换

为了减少风险的影响，可以做系统分步切换的方案。例如：售票系统在切换时，往往用新系统售预售票，或者是用新系统售长途车站，用旧系统暂时售短程票。待新系统运行稳定后，再全面切换到新系统。针对多个用户单位的系统切换，也可分单位进行。

(3)交叉培训

新旧系统切换过程中，用户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班，让早班的用户在交班时培训中班的用户，中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。

8.可用性问题

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。

(1)了解用户

到用户工作现场，了解目标用户使用软件的真实目的，从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。例如：售票系统中，使用频度最高的界面是售票界面，售票员最关心的是钱不要出错（多了没收、少了要赔），因此，应收款和找余字体的显示应该突出、醒目；同样，票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计，尽量减少售票员敲击键盘的次数。否则，在日发旅客流量达七、八万人次的大型客运站，如果用户界面设计得不好，售票员一天工作下来，手指都会敲麻木。

(2)参与型设计

与用户协作，让用户参与用户界面的设计、评审与测试，确保用户能够全面地、及早地发现可用性等方面的问题，并及时纠正。

让客户参与设计，而不要让客户设计，项目经理或高级设计人员应该主导设计。

(3)竞争性分析

通过对市场上同类竞争性产品进行分析，或者对这些产品进行实验性测试，了解这些产品的用户界面问题，从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计，而是通过分析竞争产品的优势和弱点，能够比以前的设计做得更好[5]。

(4)一致性

如果用户知道同样的命令或同样的操作总会产生同样的效果，那么他们在使用系统时就会更加自信，同时也鼓励他们进行探索性学习，因为他们已经具备了使用系统新部分的基础知识[Lewis er al.1989]。

开发团队应遵循公司或小组制定的用户界面标准，就可以在很多方面保持一致性，切忌不要一个系统存在多种不同的界面风格。

9.结论