- 相关推荐
软件项目经理年度工作总结
总结是对某一阶段的工作、学习或思想中的经验或情况进行分析研究的书面材料，它能帮我们理顺知识结构，突出重点，突破难点，不妨让我们认真地完成总结吧。那么总结有什么格式呢？以下是小编帮大家整理的软件项目经理年度工作总结，仅供参考，欢迎大家阅读。
软件项目经理年度工作总结1
合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。
以下我从几个方面描述一下我认为比较合理的模式.
1.需求获取
在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。
软件项目可以大致分为专用软件和通用软件两大类。
对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。
但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。
对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。
为了比较好地与用户进行交流，使用一些工具是很有好处的。 为了讨论用户界面，可以用VB，delphi等做一个原型，根据原型有针对性地与用户讨论需求。(原型开发不仅仅可以用于准确获取用户的需求，开发出来的原型本身可以作为下一步开发的基础，增量式地完成开发)
为了讨论软件运行的流程，可以采用UML的UseCase图。
2.需求分析
在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的'各种关系来表示整个系统。
这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系，可能需要不断修改而形成一份分析文档。
我想强调几个问题。
一是要分清问题域与系统责任。系统责任是指所要开发的软件应该完成的功能，而问题域是包含所有相关的部分。例如你要开发一个程控机计费程序，程控机已经是现成，输出的数据格式也已经是固定的，你的程序仅仅需要从程控机中读取相应的信息，那么，程控机在你的系统里只是一个外部的东西，把它作为一个类也许就是不必要的，仅仅需要一个类来完成读数据的操作。又如，你需要在一个已经存在的数据库上开发一些应用，数据库的格式已经固定，并且已经有一个后台程序在运行，你需要开发一个新的前台程序，这时，服务器程序对你来说就是一个外部的东西。但是，象这种外部的内容必须在分析文档中有一些说明，作为系统的外在约束。
二是需求获取与需求分析的关系。
用什么方法来完成需求的获取，在很大程度上影响了需求分析的做法。
例如当初采用UseCase来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。
三是分析与设计过程的衔接。
分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。
对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份分析文档作为开发的基础。
对于需求变化频繁的项目，可能采用少量分析;少量设计少量编码测试的方式更合适，而且随时可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。
现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，CASE工具如同一支笔，如何用好还得还人。
3.设计过程
设计阶段的工作包括:
对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。
定义界面部分、数据访问(数据库)部分。
由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。
4.编码
进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。
5.测试
如前所述，即使是小项目，也应该严格地进行测试。
软件项目经理年度工作总结2
时光飞逝，日月如梭，转眼间，我来公司已经有x年了，业绩也已经到了平稳发展的阶段，这与公司的管理制度和严格的要求是密不可分的，再次，感谢上级领导部门的英明决定和同事的努力奋斗。
回顾今年的工作，总体形式较为可观，在上半年中，有个别单项完成过程中不为乐观，总结得出以下几点!
管理既是对工人的合理安排调度，明确分工，责任到人，监督是对现场施工工作进度的跟进，在每一阶段应注意的细节问题，每下一阶段可能出现的不利情况，监督及时才能确保不出现任何不良问题;正是此两点，我做得不到位，导致在三月份的一单项业务中出现纰漏，有负公司领导的期望及各位同仁的热诚帮助，实为惭愧。失败乃成功之母，日后，必须严格管理，责任明确到人，让工人明白其职责所在，这是确保质量的重要性;现场的监督要做到胸有成竹，了于指掌，及时跟进!
装饰行业日益精工化，市场紧促，竞争激烈，技术要求是生存的关键，没有只有更好!施工过程中技术人员的作业是质量的'根本保障!中国人口众多，但任何公司企业更需要的是人才，优秀的技术人员是公司发展中不可缺乏的人才之一。对员工加以指导培训，巩固技术，聚众之长，纳贤之优，因人致宜，掘其所长，才能不断提高技术含量。因此，计划在明年将继续扩建团队，优胜劣汰，做到技术不合格，坚决不上技术岗位!
顾客是上帝，服务提高产品负价值，在不影响公司及个人的利益和声誉的前提下，对客户应做到有求必应，巩固老客户，增强声誉。客户的需求就是我们的追求!
软件项目经理年度工作总结3
忙忙碌碌中一年又将悄然划过指尖!在感慨自己又大了一岁的同时，发现自己也进步了不少!回顾这一年来的工作,平淡中带点匆忙,平静中带点波澜,平凡中带点非凡。回首过往，公司陪伴我走过人生很重要的一个阶段，使我进步了很多，领导对我的支持与关爱，令我感受到公司的溫情，有你们的协助才能使我在工作中更加的得心应手，也因为有你们的帮助，才能使我在公司的发展更上一个台阶;在此我向公司的领导以及全体同事表示最衷心的感谢!现将近半年来的工作情况作以简要总结汇报：
在工作上，围绕公司的技术中心工作，对照相关标准，严以律己，较好的完成各項工作任务。始终保持严谨认真的工作态度和一丝不苟的工作作风，勤勤恳恳，任劳任怨。我始终坚持严格要求自己，勤奋努力，時刻牢记公司制度和全心全意为公司创造利益的宗旨，在自己平凡而普通的工作岗位上，努力做好本职工作。身为技术总工，我深深的明白它是公司运转的一个重要枢纽部门，除了做好标书设计方案和技术保障外，须对公司内外的许多工作进行协调、沟通，做到上情下达，同时也具备了一定文字表达能力和逻辑思维能力。过去的八年弱电行业经验，使我在工作上更加得心应手，在人际交往过程中所具备的良好基本素质及交际能力，也拥有了较好的沟通能力及表达能力。首先我非常感谢公司领导给了我这个发展的机会，这是对我工作的`肯定，对我个人而言是新的开始，也是新的挑战。我对新一年的工作充满信心，要彻底克服自己的急躁情绪，提高工作质量和效率，积极配合领导及同事把各项工作做得更好，严格要求自己做到以下几点：
1.要“想得到”工作中要多动脑筋，想办法，出注意，要勤于思考，增强工作的主动性、预见性和创造性。
2.要“做的细”工作中要细心、细致，从小事做起，工作要严谨细致，一丝不苟，做到不让领导布置的工作在我手中延误。
3.要“讲程序”工作要分清主次，分清轻重缓急。
4.加强学习，充分利用时间，抢着学;结合自身工作，切实学，广泛学。在学习中总结，在实践中提高。
5.以公司定制的新的标准、新的要求，加强自己思想道德的修养严格的要求自己。做到工作认真、务实，在工作中做到自重、自省、自警、自励。
6.要努力做好本职工作以外，要掌握更多的专业知识，不断提升自我，不断充实自己、完善自己。虽然我在一年的工作中取得了一定的成绩，但还存在一定的问题和不足：
1.是工作有急躁情绪，有时工作急于求成，反而影响了工作的质量;
2.工作细节方面还不够注意，有些细节工作忽略了;
3.在工作较累的时候，有过松弛思想;
4.自己会有畏惧情绪，缺少自信心。
为了更好的开展工作，适应__科技的发展，迎接更大的挑战，我把我进入公司后的所看、所想、所思考及建议分思想动态、技术设计、工程管理、制度建设、业务沟通、团队建设六个方面总结出来。通过总结，发现问题，查补漏洞，既是对公司一个参考，也是对自己的一个鞭策，从失败中接受教训，避免重蹈覆辙;从成功中总结经验，以指导下一步工作。通过对工作的总结得出一般性规律，形成有益的经验，达成一致的认识，使其对今后工作具有指导作用，以利于发扬成绩，纠正失误，变压力为动力，并不断的对工作进行改进，以期更适合公司的发展。站在公司的角度是一个总工，要对老总负责，做好老总的参谋和助手，多提出合理化的建议，为老总分忧;对我个人来讲，这一年意义深刻，它是我人生旅途中的一个转折点。
软件项目经理年度工作总结4
一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。本文的目的是从作者的经验来谈谈小项目开发的管理。
一、小项目的特点
大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点:
1.项目功能相对较少
2.开发人员较少
3.开发周期较短
另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实.
二、小项目开发中常犯的`错误
小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:
1、开发之前没有认真地进行项目可行性和工作量的估计。 往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别。
2、没有真正的设计过程
开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。
这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差(应该承认人是会犯错误的)。一个误解可能造成以后的返工。 另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。
第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。
3、不经过单元测试而直接进入系统测试
造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。例如，为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。但很多开发人员嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。
殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步步查找。由于模块间的调用关系，可能查了很久才发现是某个模块的问题。这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。但是如果对每个模块进行单元测试时都进行一下边界测试，就会很容易消除一些隐患。真可谓欲速则不达也。
【软件项目经理年度工作总结】相关文章：
软件项目经理试用期工作总结08-29
项目经理年度工作总结07-22
项目经理年度工作总结【经典】07-22
项目经理年度工作总结07-17
软件测试年度工作总结04-18
软件年终工作总结05-24
（必备）项目经理年度工作总结07-22
软件开发年度工作总结05-24
软件公司年度工作总结05-24