软件开发项目工作总结第1篇20xx年底加入现在的测试开发团队，至今仍然在挣扎奋斗中，从几个问题和关键点入手总结下我的测试开发工作。测试开发组的第一用户群体是谁？20xx年在TID质量大会听了章屹的主题下面是小编为大家整理的软件开发项目工作总结,供大家参考。
软件开发项目工作总结 第1篇
20xx年底加入现在的测试开发团队，至今仍然在挣扎奋斗中，从几个问题和关键点入手总结下我的测试开发工作。
测试开发组的第一用户群体是谁？
20xx年在TID质量大会听了章屹的主题分享，印象比较深刻的是他说的测试工具开发的第一用户群体是“开发工程师”而不是“测试工程师”。我也逐渐认识到了这点。
首先从质量决定论上来说，测试越来越左右不了产品的质量，或者说从一开始就没有左右过产品的质量。“质量是构建出来的，而不是测试出来的”，相信很多人都认同这个观点。当然我们身为测试工程师本身总是觉得自己的工作很重要，你们开发应该遵守规则，按流程开发，测试不过关不能上线。可是实际情况是什么样呢？常常是“测试通过要上线，即使测试通不过只要有没严重问题也要上线”。有人说这是个人职业操守的问题，我却感觉这是“存在即合理”的现状。一刀切的质量标准不适用于追求快速迭代的互联网产品。那么我们要么帮助测试工程师逐渐提前介入到开发流程中，要么直接服务于从项目一开始就影响产品质量开发工程师。
再从用户数量上来说，原来2007年在Gladon开发测试比是1:1，现在是4~5:1，或者更高。很显然如果服务于用户群体占多数的开发比服务于测试价值更大。
还有一点很重要，从工具文化的接受程度来说，开发往往发牢骚最多的是“工具真TM难用”，而测试往往在心里嘀咕“MD，又让我用一个新工具”。所以如果定位用户为开发，那么只要站在用户角度开发出切实业务场景又好用的工具就可以了。但是面向测试群体，你非要把一个新的工具使用强加到现有的工作流程中真是难上加难。就拿部署来说，如果我是测试，我给开发说一声“帮我部署个xx应用”，总比拿一个本来不是很好用的工具费劲巴拉折腾半天仍然搞不定要好。
最重要的是业务落地
流程上属于关键节点的工具，比如出包、部署、代码质量等等公司级别的工具开发组已经实现了。其他刚需的工具也大都有成熟方案或者开源工具了。那么业务团队真正需要的是什么呢？我们工具开发组可以做的是什么呢？应该是找到现有工具方案和业务团队实际情况之间存在断层的衔接点，真正和业务结合起来，服务于业务，这才是我们业务部门的工具团队的价值所在。重复造轮子是可耻的行为，不能说为了学习Jenkins的原理，自己开发一套相同的系统出来，我们可以弥补开源方案的缺点，比如确实实际业务场景的支持，权限系统与公司的对接，数据的整合等等。
节奏一定要快
每个测试开发组的成员都应该真正去业务团队体验一下什么叫做996，尝试为了线上验证通宵熬夜的感受。参与过业务团队的具体迭代开发，面临真正的业务压力，才知道为什么如果不够快，就将面临生存的问题。而常常实际情况是，测试开发组慢条斯理做着与业务不怎么沾边的工具和系统，心里还在偷着乐，“还好我没在业务组做开发或者测试”。这样的结果只能是与业务脱节，逐渐边缘化。
避免闭门造车
把外部的先进的知识和工具引进来，并把内部的实践经验分享出去。常常是我们吭哧半天解决的问题，别人早就有成熟方案了。或者大家都在说代码质量很重要，线上质量很重要的时候，我们仍然在紧紧盯住测试环境质量，并且死磕自动化测试。
而且不光要与测试同行交流，还要多和开发交流，深入了解现有系统架构及技术的特点，比如我们部门处于公司整体技术架构的哪个层面（基础架构、中间管道、还是上层业务），我们应该关注的质量重点在哪块（代码质量、架构质量还是性能稳定），开发和测试团队对应的痛点是什么，我们应该提供什么样的工具。还要和业务和产品人员多交流，了解现有系统的业务组成，分析不同系统及应用的重要程度和关注点，帮助产品和业务人员提供工具支持和数据支持。
输出实践而不只是输出系统
很多工具和系统是结合实际场景使用的，比如持续集成系统，自动化测试工具，都是和工程实践紧密结合的。如果仅仅拿出来一个系统交给业务团队使用，往往结局是被废弃掉。应该首先找到试验团队形成系统与实践结合的案例，然后再给别的业务团队推广培训，才能够逐渐使用起来。
重视数据目标而不只是功能目标
做软件开发的都或多或少有这样的特点，总想开发出足够牛逼的系统，拥有足够多的功能。常常定目标的时候说，“我这次要实现什么什么功能，下次要增加什么什么功能”。最后功能越累越多，系统却越来越没人用。我们是不是应该换一种思路，以用户使用量、系统稳定性、团队业务数据提升等指标来衡量我们的工作更好一些呢。
软件开发项目工作总结 第2篇
08年顶着名校硕士的光环加入了一家非常有名的非软件公司做软件开发，刚开始一切其实都很美好。大外企的各种好在头一年给自己带来了很多光环，当然自己也学到了很多（主要是非技术的东西）。
可是从第二年开始，当自己被各种邮件，开会和扯皮的事包围后，技术能力急转直下。然而自己当时还没意识到这个问题，感觉钱还行，也不忙，再加上本来就很迷茫，就得过且过了。
直到去年，很多清华北大同事的离职，日复一日的简单重复工作，明显的天花板，不涨的工资，以及家庭原因的集中爆发才让自己后知后觉，才开始反醒，才开始下决心做转变。
然而转变是痛苦的，这五年技术上主要是在windows平台上做一些企业内部业务的处理和展示，主要用一点c++/c#，还有MFC，Winform，WPF，WCF。
技术基本上是做的皮毛，一般问题用MSDN，google和stackoverflow就能基本解决。用不到数据库，也用不到什么数据结构，用到一点点网络知识，主要精力都在业务展现上。这一切在我看来招个应届生用一年也能有和我一样的开发能力，唯一懂的多的业务，也长进不多，都是繁杂的重复。
所以在自己开始面试和找工作时被bs了很多次，顶着光环人家一般都给你面试机会，但是一旦聊到技术细节，自己很多都答不上来，也曾经一度非常沮丧。
庆幸最后找了个技术相关的职位，能够兼顾到家庭和自己后面发展的想法，还算可以，这是后话，暂不讨论。
软件开发项目工作总结 第3篇
一、总结：
1、自身定位：在过去一年，是我进公司的第一年，也是我工作的第一年，刚开始在我对工作竞争和自身都不甚了解的情况下，在领导和同事的指导下，我感觉自己已经慢慢对人与人的竞争和自身定位有了深刻的了解，因为有了自我目标，才能感受到自己的压力有多大！我的目标也不只是完成目前所要做的工作而已，要向其它方面拓展学习。
2、定下心来，踏踏实实：我学的是计算机专业，我的工作也是计算机方面的，以前有什么优势，但是踏入工作岗位后才发现，自己学的只是一个基础，只是有些方面或许比别人走的快一步，所以一切都要靠自己。自己要定得心下来学习，成功需要耐得住寂寞，不求最快，但求。
3、团队合作：以前在学校或许你可以靠一个取得好成绩，在工作上你必须要有一个团队，在一个部门之中，团队合作精神显得尤为重要。以前我做有些事都是一意孤行，但现在已经对自己改变了，多听听他人意见，会犯更少错误，会更长见识，所以要学会与同事之间的合作，做事才更有效。
4、工作情况：在公司一年，对mes大型系统有了个大概了解，对我们所要学习的mes已经可以说差不多都掌握，条码打印机的维修和设置掌握，a4打印机大多数情况可以维护，pda、条码枪已掌握，电脑的系统重装和维护已掌握，其它基本设置可以维护，对新出来的程序掌握和了解也比较快。
5、课外学习：sql该学的已经掌握，c#学习，简单的程序可以编写，但有时还要依靠于网络和朋友，需要进一步加强。但主要还是以网络为主。
二、自身缺点
1、沟通问题：自己的沟通能力只能算一般，因为对于某些事的阐释还是不怎么好，语言表达能力有点差，希望通过平时的交流和沟通来加强。
2、心态问题：自己对于做某些事过于着急，一心想急切完成，确反而误时，这个问题一开始就一直出现，现在虽然已经基本克服，但也要列入缺点方面，希望以后时刻注意！
3、学习问题：对于课外学习这方面，我在编程时感觉困难的时候有时候就不愿去做，现在虽然已经慢慢改进上网搜资料和问问朋友，但有时候还是克服不了自己。
软件开发项目工作总结 第4篇
本次软件项目设计的题目是场地预约系统，它是基于B/S模式实现的用于体育城场地管理预约的Web应用软件。为用户提供并接受用户提出的需求信息，同时通过数据库管理系统存储数据，给场地的管理带来很大的方便。本项目的实现分为前台与后台。其中前台，用户可以浏览场地所提供的可预订场地的信息，同时可以对需要的场地进行预订；
后台主要是针对管理员，管理员可以通过后台对场地的相应信息进行增添修改等操作。
我基本参与了本项目的全部实现过程，涉及项目的需求分析，概要设计，详细设计，代码编写，调试与运行。在需求分析阶段和小组其他成员认真分析讨论了本项目各方面的需求，主要是功能方面的需求，基本确定了本场地预约系统应该具有的基本功能。概要设计阶段通过讨论分析确定了所需表结构。详细设计阶段参与部分代码的编写，其中包括页面与数据库交互的实现，还有相应jsp页面代码的实现几布局的调整，修改。
在数据库设计实现阶段，通过和我们组其他成员的共同讨论，确定了场地信息、用户信息等表结构的详细信息，并实现了其数据库的`建立和相应表的具体信息的设计实现。同时针对个别表结构完成了相应代码的编写与实现。
在后台，实现了用户的信息的浏览查看，修改及删除等功能，同时完成了足球场等场地信息的浏览、增添、修改、删除等功能。
前台参与了主界面的设计与实现，通过查询数据库得到主界面显示所需场地的相关信息，通过这样，用户可以很清楚的获知所有可预订场地的信息，其主界面上的所有关于场地的数据都是动态从数据库获取的，这样当场地增添或删除时通过修改数据库可以很方便的实现界面呈现给用户的场地信息，能够很好的使实际情况跟提供给用户的信息保持同布，非常利于场地信息的管理和发布。
软件开发项目工作总结 第5篇
20xx年，公司规模迅速扩大，公司管理的自动化程度不断提高，许多软件系统已不能满足不断扩大的管理要求，除了要升级原有的软件系统外，新的系统开发需求成倍增加，因而，本年度内扩充了软件应用及开发工程师扩大到30人。20xx年与20xx年间，随着面向目标软件平台的普及，新的高效的软件开发模式也在中国软件业不断成熟，整体开发整体水平有了很大的提高，我公司也引进一些新的开发工具，实践了迭代开发等先进的管理方法。
xx年内我们主要完成了供应协同平台，固定资产管理，合理化建议，商用空调信息管理系统，基础文档管理系统等新的项目。由于开发管理的改进，本年度，软件开发效率提高较大，虽然用户需求增加很快，我们软件设计功能满足率仍然达到了95%，由于引进了专业的软件代码单元测试方法，软件测试的代码覆盖率增加到75%，软件的BUG率大幅下降，质量大幅提高，项目完成率提高到85%。虽然本年度软件开发从质量，效率上都有较大提高，但通过分析，仍然发现了一些不足之处，需要采取相应的改进措施：
一、由于人员效率的提高，对用户需求的响应时间缩短到4天，比去年提高了50%，但评估完成时间只提高了10%根据分析，评估响应时间较长的原因主要是：
（1）、使用的开发方法有所改变，对开发时间的评估不是太熟练；
（2）、开发人员的专业知识有所增强，但对由于开发任务较重，对有些专业领域的熟悉还不够。
二、关键用户访谈率及关键用户对需求的认同率都有所提高，都达到了90%以上，但仍然有所不足，主要原因如下：
（1）、在忙季，仍然有的关键用户抽不出时间来接受访谈；
（2）、由于有些需求分析人员经验不足，对部分需求的分析不够透彻、准确；
三、每个功能模块平均的BUG数仍然有2个，单元测试覆盖率只达到75%，
分析原因如下：
（1）、开发工具的限制，目前的开发工具，对界面部分进行单元测试仍然不能自动进行，而用户界面开发占系统功能的很大一部分；
（2）、软件开发人员的原因：由于软件人员紧张，项目任务多，交期短，所以
在开发时，所以，虽然在技术上，将界面程序进一步分拆开来进行更多覆盖率的测试可以提高测试率，但实际上，由于时间原因，大部分工程师都没有这样做，开发出的软件代码缺乏时间整理，并尽量通用化，也是软件质量没有进一步提高的原因；
四、项目的按时完成率仍然不够高，平均只有85%，分析原因如下：
（1）、用户需求变更太频繁：由于用户需求变更太随意，太频繁，仍然是按时完成率提高的主要障碍。
（2）、软件需求分析设计人员的原因：由于设计的不合理，分析用户需求不够
透彻和全面，架构设计不合理，导致软件开发变更及错误多，也导致了软件项目的开发延迟；
综上所述，为了顺利实现计算机中心xx年目标，我们计划改进措施如下：
内部的改进措施：
1、加大对新人培养力度，不但培养新进开发人员的技术能力，同时注意提高他们对业务的熟悉程度；
2、贯彻岗位知识能力模型，要求严格达标；
做到合适的人在合适的位置做合适的事；
3、加强软件开发管理，培养团队合作精神，加强软件过程控制；
4、优化设计开发方法：加强设计标准化、模块化；
提高软件开发效率；
外部的改进措施提议如下：
1、提高业务部门对软件开发过程的了解；
2、培养用户需求的分析能力；
3、加强与用户的沟通，让用户参与到设计中来；
