工作总结范文软件工程个人项目总结Word下载.docx

工作总结范文软件工程个人项目总结Word下载.docx

《工作总结范文软件工程个人项目总结Word下载.docx》由会员分享，可在线阅读，更多相关《工作总结范文软件工程个人项目总结Word下载.docx（4页珍藏版）》请在冰豆网上搜索。

之后还完成了logo管理模块中的投票项目添加优化与投票结果统计查询修正、logo、banner的管理与文本文件的生成。

还完成了客服管理模块中后台开通资料查询的改进，企业管理、个人管理模块查询功能的改进。

期间还完成了部分功能错误的修正，如校园招聘管理图片不能上传、文章类别不能修改、文章不能删除等。

　　三、目前新版是用jsp开发的，在这三个月里，我进一步对java，jsp的深入学习，了解了mvc模式开发，在这阶段的学习期间，我以一个小商务系统的开发作为学习任务。

还对当前流行的jive代码与开发思想进行了初步的学习研究。

　　四、作为一名系统开发与维护工作者，当然不能忽视对数据库知识的学习，在这段时间我也进一步对sql语句进行了深入的学习，对sql语句的查询进行了分析，比较重视数据库性能分析与调整这方面的知识学习。

通过这阶段的学习，把这些知识与方法运用到了

　　对后台管理系统会员查询的速度优化功能上，在实际工作中得以实践运用。

　　五、网站新版开发方面，主要还为新版做了几个数据库对照表。

　　六、还参加了网站新版的第二轮测试工作，主要以后台管理系统为主做测试，还参与了前台个人管理与企业管理的流程测试，测出了不少关键性的bug。

　　七、入职以来，还担任了网站部群发邮件的工作。

三个月内完成了好几批邮件群发的工作，每天定时定量地给在无忧无虑网站上注册的企业或会员群发几十万封邮件。

还配合客服部群发了两批特殊活动的邮件，配合网站营销活动群发了两批群件，每天坚持固定给注册会员群发。

　　在网站技术部工作的三个月里，自己感受非常多。

首先，作为刚从学校出来的毕业生，在实际开发中的经验尚不够成熟，还需要在工作中不断的提升自己。

其次，要进一步提高自己的开发技能，使自己的技能满足今后的需求，主动获取并学习当今最新技术信息，平衡自己的知识结构，在不断的学习中提高自己。

然后，要加强与同事们的沟通，融入团队，互相学习、相互提高，在团队中不断完善自己。

　　我相信，通过我的努力，一定能成为智通的优秀员工，一定会在优秀成绩之上提升自己。

同时我希望公司能根据情况给我培训深造的机会，也希望部门内能有经常性的专业技术学习。

　　软件工程个人项目总结2　　从软件工程的角度上来说,我们的项目是不成功的.从时间成本上来说,我们的时间成本太大,进度方面控制的一直不是很好.和预想的软件工程的进度相差太多.在从需求分析开始的整个软件工程过程中,从用例设计到编码以及测试阶段.我们一起遇到了各种困难,错误.整个原定计划的时间被一拖再拖.

　　但我要说,从这次失败的软件工程中我的确学到了很多,其他只是拷贝别人代码所学习不到的知识,这一刻我体会到了失败的苦涩,要避免再次的失败,唯有付出更多的时间在继续学习软件工程的知识,当然也不只是需求分析和编码方面的知识,要保证一个软件项目的正常执行,一定要学习项目管理知识,知道如何推行你的项目在给定的时间内以优秀的质量满足客户的实际需求.

　　软件工程是个很有深度的领域,在这次实践中所感悟最深的是,对于知识有没有彻底的理解,不能光靠一张嘴说,也不不能凭感觉.自己感觉掌握了就行,不去实践.软件工程是门实践的科学.一定要而且只有在实践上实现了才能说你掌握了这个知识点.而不是光会说,这个这个应该是这样的,没有自己去实践,程序运行的结果只是简单的copy书上的或是google来的答案.这样是要不得的!

　　从团队合作上来说,我和陈伟强都是实践型的,我们的学习方法基本上都是通过实践来学习知识.但是我和他也有不同,他更多的是关心一种思想上能否实现.而我可能偏向更为固执些吧,我个人觉得知识是一定实践的,不实践怎么能知道实际的运行结果是否和我们的预期一样呢?

不过另一方面,我还是要想他学习一些从更高层次思考问题的思维方式.

　　在这次软件工程的过程中,也是龚根华老师的推荐,我看了ErichGamma等人合著的一书.坦白的说,读完本书后对于软件工程的感受有了变化,对于它的认识不再仅仅是传统的数据结构加控制结构这种传统的设计思维.透过这本书,我看到了O-O所能提供给软件的更好的通用性,复用性,稳定性,依照这种思维我们可以设计出更加经济可靠的软件.只是限于我经历的开发经验还是太不够了,现在的我只是用到MVC这一个设计模式在这个项目中.但是这只是个开始,我会更加的努力学习软件工程的知识把设计模式,SPI,CMM方面的知识,早日成长为一名合格的软件工程师.

　　最后,感谢我和我一起奋斗的伙伴陈伟强,尽管我们这次的项目并不成功,但我们一直在总结,在学习,我们下次的合作会做更的好些的,感谢给予我们谆谆教导的龚根华老师,谢谢!

　　软件工程个人项目总结3　　总想着每天、每个月、乃至每年都有点进步。

XX年，对我来说，是起伏不定的一年，也是收获颇丰的一年。

当然，最大的收获是有了一个可爱的女儿。

　　在这一年，我跳了两次槽，一次是自愿的，还有一次是被迫的。

我目睹了一些公司从盛到衰的过程，也看到了一些脚踏实地的公司。

　　离开X1公司，是因为我觉得X1公司不是在做软件，所谓的印度模式，我想，绝对不是这么做的。

理想不合，不想浪费时间，也只能背负跳槽的恶名，挂冠而去。

去X2公司，是因为看到他是美国独资公司，做外包软件，能够接触美国的客户和技术，希望能够有所收获，何况，职位也不错。

的确很想好好做，也跳累了，只想稳定发展，毕竟，是做父亲的人了。

没有想到的是，竟然让我目睹了一场资产争夺的好戏。

公司易主，流言满天，诽谤四起，官司大战，这种平常只有在电视和电影里看到的情节，我实实在在的亲身经历了，也算是人生的重要一课吧，至少，让我看到了人性最阴暗和恶毒的一面。

自然，是做不下去了，只能又走。

　　也看到了一些踏踏实实做事情的公司。

园区的瑞博软件就是一个。

很少看到如此踏实做事的公司。

若干年后，只要他能够存活，必定是一个成功的公司。

虽然老板对我也很有诚意，只是，对于教育软件，我实在没有太大的兴趣，何况，如果想做教育，我何不选择安博呢?

毕竟，安博给于我很多。

回头想想，在其他公司，我都是在奉献，只有在安博，是学习了很多。

　　说起跳槽，其实，看看那些公司，有多少是在踏踏实实做事情的?

老板本不懂软件，都是看着软件行业能赚钱，想来捞一票，结果把中国的软件行业做坏了，也害苦了中国的程序员。

自己不好好做事，怎么怪别人跳槽?

同工作经历的坎坷相比，，在个人能力方面，今年的进步是非常大的。

今年上半年，我的进步集中在技术领域。

我更加深入研究了设计模式、EJB体系和.Net平台，还有UML建模，终于有所突破，设计了一套自己的基于.Net平台的系统架构和开发工具，并且得到了应用的证实。

在网上也陆续发表了一些文章，受到比较好的欢迎，还上了赛迪网的开发之星。

　　下半年，在软件工程方面收获是很多的。

　　看到网上对于印度模式从吹捧到批驳的吵闹，也看到X1公司学习印度的失败，加上自己从开始就对那些记者的怀疑，决定好好学习软件工程。

我一向认为，任何东西，不能道听途说，只有自己好好深入研究，才能得其精髓。

同时，软件工程绝对不能只看印度的，毕竟，美国才是软件业最发达的国度。

　　列举一些学习的参考资料：

《RUP软件工程过程》、《MSF微软解决方案》、《XP极限编程》、《CMM实践应用——Infosys公司的软件项目执行过程》、《人月神话》、《软件需求》、《软件工程Java语言实现》。

每本书，我都仔细研读了，颇有体会。

　　我开始就想，印度软件工程绝对不会象那些记者所说的那么简单，所谓的高中生编程说。

所以，我必须实际看看印度的软件工程。

《CMM实践应用——Infosys公司的软件项目执行过程》，是印度最大的软件公司Infosys公司的分管质量的副总裁写的，介绍他们的CMM4的软件工程，果然不同凡响。

这是我了解印度软件工程的主要窗口。

　　首先，同原来的想法不同的，也可能同大多数人（尤其是受那些软件记者影响很深的“专业”和非专业人士）想法不同的是，软件工程实际上不仅仅只是管理，而是一门涉及很广的交叉学科。

在软件工程中，大约一半的内容是专业性很强的，涉及到软件分析、设计甚至编码的技术。

所谓的结构化、面向对象，都在软件工程的范畴内，同样是软件开发和组织的重要内容，也是软件质量保证的重要内容。

至于软件开发的管理部分，只能算是软件工程中软件工程过程的部分，或者说项目管理部分。

脱离管理来开发软件是绝对不可行的，同样，抛弃技术基础，空谈管理出效益，便如无源之水、无本之木。

诚如《软件工程Java语言实现》中所说：

“软件工程范围极为广泛。

软件工程的某些方面属于数学或计算机科学，其他方面可归入经济学、管理学或心理学中。

”在这里，我强调了软件工程中的技术部分，并非轻视管理，只想在软件工程的概念上做一些拨乱反正，也希望多一些人来关心软件的核心技术，而不要空喊口号和概念。

毕竟，中国的软件太缺乏核心技术了。

　　其次，对管理要求的严格不说（这个谁都知道），实际上，不管是美国的软件工程，还是印度的软件工程，都是比较灵活的。

即便是印度这样的所谓“软件工厂”模式，对于软件工程过程管理极为严格，也有一个部分是专门讲述过程剪裁的。

整个软件工程过程是非常庞大和繁复的，然而，由于项目具体情况不同，如项目的规模，参与人员的数量、素质等的不同，对于软件过程的每个部分，不是都必须的，可以根据具体情况来进行剪裁。

这个部分对于我的启发是很大的。

以前做什么ISO9000等，开始做了一个以为很好的规范，但是，到具体项目，总是对不起来，到处有问题，现在想想，便是少了这个变通的部分。

不过，话说回来，这CMM也是老美想出来的，而不是印度。

　　第三，对于开发人员的选用，我发现，美国人是非常注重选用优秀的开发人员的。

MartinFowler曾经开玩笑的说，如果给他一批水平不高的开发项目，他会考虑全部解雇，重新招聘。

《人月神话》中也说，如果200人开发一个项目，其中25个人最能干，那么会考虑解雇其余的175个人，让项目经理来编程（当然，后面还有一些抉择分析，这里断章取义了）。

其结论的基础是基于以下研究结果：

优秀的开发人员和差的开发人员，其效率之差可以达到数量级。

另外，从管理的角度来说，只有人多了，才会有管理问题，当团队规模控制在一定的范围内时，便不会有太大的管理问题。

　　对于软件来说，很难实现同传统产业一样的工厂化生产，这是由软件开发的本质决定的。

软件的复杂性是软件的本质属性，在这个属性没有改变之前，软件便不会实现同传统产业一样的工厂化生产。

至于印度的所谓“软件工厂”，实际上，只是完成了软件代码的编写工作，并不是实现了整个软件研发工作，而代码编写工作，恰恰是软件开发中最简单的一环。

至于印度是否真的有很多高中生程序员，印度人的书上没有说，记者到说了不少，我也无从考证。

所以，软件的开发，还是需要选用优秀的人的。

除非，公司只想帮别人编写代码，而不希望有自己的产品和技术。

　　第四，软件开发中，最重要的还是团队合作和交流。

这个是我目前最深切的感受。

具体的，大家都知道，也用不着多说。

　　最后，对于软件开发来说，公司老板的想法是最重要的。

如果老板说“No”，那便是水平再高，管理再好，也终归无用。

年龄渐长，也做父亲了，却总是在漂泊，没有一个可以稳定发展的地方。

希望目前的公司能够有这个机会。

不想总是跳槽。