软件项目总结报告范文

1引言

1.1编写目的

XXX公司业务管理系统的开发已经基本完成。写此项目开发总结报告，以方便我们在以后的项目开发中来更好的实施项目的订制开发; 让我在今后的项目开发中有更多的有据的资料来规范我们的开发过程和提高我们的开发效率,从而创造更多公司效益。

1.2背景

项目名称：XXX业务管理系统

软件名称：XXX业务系统

客户：XXX

用户：XXX员工

1.3参考资料

项目开发文档：

１．软件开发数据模型：PDM_OperationSystem20070831.pdm

２．数据库开发文档： XXX业务管理系统数据库设计说明书2.0.doc

３．软件业务流程参考：XXX业务管理系统流程说明.doc

４．软件使用手册参考：XXX业务管理系统功能说明3.0.doc

５．软件业务流程参考：XXX业务管理系统流程说明.doc

６．软件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar

７．软件中使用的安全Ikey驱动：Ikey Driver.rar

以上参考资料是截止2007-08-31是最新的资料文档。如有修改，即使修改此处的参考文档名称。

2开发工作评价

2.1对生产效率的评价

１．系统开发已历时快１年的时间了

２．开发的反复性比较多。

３．对客户的需求理解不是很透彻。

综合以上，此项目的开发效率不是很高，相反有相当一定时间的浪费。

2.2对产品功能的评价

经过我们公司各位同事的共同努力协作，XXX业务管理系统已经很好的完成了客户的业务流需求。经过对客户使用过程的观察，此项目开发的还是比较成功，但是还是存在着一些问题，造成这些问题的原因是多方面的。如：前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定问题，这就需要我们用一定的时间来维护客户使用过程中提出的新问题和存在的debug。总的来说，此系统的功能开发还是一个比较成功的案例。

2.3对技术方法的总结

在此项目中使用到技术和工具：

１.使用代码生成器：使用代码生成器 [动软.Net代码自动生成器],此工具在很大程度上提高了编码效率，从而加快了项目的开发进程。在以后的项目中，我们要尽量的来使用一些类似的工具来在最短的时间内完成工作。在今后的项目开发中，我们最好是能开发出适合自己的代码生成工具，更大限度的节省开发周期和开发费用。

２.使用数据库建模工具；PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。

３.使用第三方控件：此系统中使用了ComponentArt Web.UI 第三方控件。此控件在很大程度上满足了客户对软件界面的需求，从而也给软件的操作带来了方便。本项目中只使用了ComponentArt Web.UI一种第三方控件，在今后的项目开发过程中，要继续使用第三方的控件。这样以来，无论是针对软件界面的美观性、友好性来说、易操作性而言，还是针对系统开发效率而言，这都是很好途径。但需要意的是：在是使用第三方控件时，要谨慎的选择一些网络中的比较常见的第三方控件。

４.使用自定义控件：此系统中使用了自定义控件(GhdGridView),此自定义控件可以很好的统一系统中的所有信息显示表格样式。如客户对数据显示样式有什么新的意见，我就不需要修改每一个页面的表格样式，我们只需要修改GhdGridView控件的样式，系统中的所有继承自GhdGridView的表格样式都可以改变。

５.系统开发框架：此系统的框架使用的是简单三层结构，此框架在开发一些中小软件是比较实用的。但是我们要是可以开发出自己的框架，把一些通用的功能开发到框架中。这样以来，在以后的系统开发中，针对系统中一些通用的功能就不需要再开发，从而也可以很好的提高我们的开发效率；减少很多维护费用。使我们的技术不断的更加成熟。

６.系统安全加密：此系统中针对客户提出的系统安全问题，我们采用了Ikey加密硬件钥匙来验证客户端登陆客户的合法性，此Ikey钥匙可以绑定到一个系统使用用户，也可以让多个用户来使用一个加密钥匙来验证登陆系统的合法性。这样以来，即使用户的密码不慎丢失，或者被不法人员取得（不法人员他也是无法登陆到我们的系统中来），这样就最大的提高了我们系统的安全性。Ikey加密钥匙是很好的加密B/S架构软件的硬件工具，在以后的软件安全方面可以借鉴。

3项目经验总结

3.1签定合同

一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。往往，很多一部分公司与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作两会越来越大，影响项目的竣工周期；而且，项目的开发费用一般是不会变的。这样以来，我们就大大的降低了我们的开发效益。虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的条件签定。

3.2开发团队

在项目确立后，要尽快的建立起项目开发团队。

项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这样，在项目的开发过程中，团队才不会被难题困住不动。另外，团队中要有一个项目负责人，这个人无论是在与客户的沟通上，还是在技术上都要是很出众的人，此项目负责人要能很好的沟通客户与开发成员之间，以此来更好的理解客户的功能需求。人的记忆力总是有限的，所以就要求开发团队成员要尽量的书写一些开发文档，这些文档往往是我们在项目开发后期要用到的可寻资料。项目团队士气是项目成功的一个因素,我们需要不断的来培养我们的团队气势，使我们的团队不断的壮大。

3.3需求的调研

在项目确立后，就到了需求调研分析阶段。

１．项目组对客户的整体组织结构、公司有关人员的关系、职责等如果没有一个很好、足够的了解掌握，这样项目组就无法很好的完整的整理到客户的需求、或者说客户真实的功能需求，如此以来我们就为自己埋下了地雷,影响项目的开发周期，这就要求我们要与客户搞好无论是工作上的还是生活上的朋友关系,要深入的去了解客户需求。

２．我们要尽量的让客户也参与到项目的开发团队中来，也就是说我们要使客户把自己也纳入到项目的开发团队中来，如此一来，我们掌握客户需求的真实性、可靠性就会大大的提高,也就不会为项目的后期功能开发埋下陷阱

３．在需求调研过程中，如果缺乏足够用户参与，这样的需求调研也是失败的。很多程序员不愿参与到客户的需求调研中去，为什么呢？很简单，与客户沟通不如与代码沟通容易有意思。尽管这样，我们还是必须用足够多的时间去和客户进行沟通，了解他们真实的需求。很多用户也是如此，他们自己也不愿意参与到项目的需求调研中来，为什么呢？需求调研有出去和朋友一块烂漫对吗。。。虽然现状如此，我们还是要努力的使客户参与到需求的调研中来。

４．模糊需求，也就是模棱两可是需求规格说明中最为可怕的问题。一是指诸多客户对需求说明产生了不同的理解；一是指单个读者能用不止一个方式来解释某个需求说明。针对对这种情况，就要求我们的调研人员要能够从多个角度来分析客户的不同需求，整理出最终的需求与客户确认，定出最终真实可靠的需求，我们绝不能凭借我们自己的单面理解来定立客户的最终需求。

５．在一个项目的开发中，文档的书写是极为中要的一项工作。因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也是我们程序员在编码过程中要用到的重要文档。我们绝对不能认为，凭借我们的大脑来记录所有的开发需求。。。；即使，你说你是天才，你要用你那颗爱因斯坦的大脑来记录所有的开发需求，那也是不可能的，人的精力总是有限的。这就要求我们在需求调研中做好需求文档的记录和整理。

６．需求调研工具选择，客户一般对图形还是比较感兴趣的，所以我们在调研过程中，我要尽量的采用图形化界面来和客户沟通需求。比如可以采用Rose工具，把客户的意思转换为用例图、时序图、协作图、状态图、类图等，使表达的意思更加直观。这样客户会更快的进行问题的实质。

3.5做好开发计划

在项目确立后，我们就需要做好项目开发计划，需求调研用时，开发用时，测试用时，实施用时，维护用时。在我们做好了计划后，我们要随时的跟踪计划任务的完成进度，从而使我们的项目进度掌控在我们的开发周期范围之内，今日计划、行动，明日成功。

3.5很好的沟通

在其他行业中，人与人的之间的沟通只很重要的。项目开发也不例外，很好的沟通能够加快项目的进度，这就要求我们每一个开发人员要学会和善于沟通于客户和同事之间。在一个项目的开发过程中，我们与客户的沟通是一个不断交流和沟通的过程。在开发到一定的阶段，我们就需要和客户沟通已有功能，尽量的去避免一些隐藏的问题，及时的发现问题，解决问题，从而按时或者提前完成项目的开发。

3.6做好工作总结

在项目进行的过程中，我们要不断去整理自己的工作情况和做好总结，这样以来，无论是在自己的技术还是其它方面，都会对我们有很大的提高，在长期的积累后，无论是我们个人能力，，还是我们的团队能力都会有很大的提高。

 

第二篇：软件_项目总结报告编写规范

《项目总结报告编写规范》

1 引言

1.1 目的

1.2 背景

1.3 定义

1.4 参考资料

2 项目概述

2.1 产品

简要说明项目所完成的产品的功能、特点。

2.2 项目组成员

描述项目所涉及的角色和人员，参与项目情况。

3 项目绩效总结

3.1 进度

项目实际进度与V1.0计划的对比。采用折线图来描述偏离计划的程度，在关键点上标明计划的变更。例图如下：

图1 项目进度实施偏离图

计划变更原因分析：

（需求变更、设计能力、工作量估算错误、风险估算不足、设备资源等）

3.2 工作量

项目实际工作量与计划工作量的对比。可以采用直方图来表示各阶段的差异及总工作量的差异。例图如下：

图2 项目各阶段工作量比较

工作量分析：

总工作量比计划超出 134/88 – 100% = 52%

各阶段工作量增加主要原因分析

3.3 成本

实际成本与计划成本的对比，软件项目主要成本是开发人员的工作量，硬件项目还可以计算消耗的材料（可选）。

3.4 规模

代码、文档实际规模统计。硬件项目还需统计PCB板布线面积、主要IC总数、新增模块数量（即原参考设计没有的，如以太网模块）。

生产率计算：

代码生产率：代码规模/工作日

文档生产率：文档规模/工作日

PCB生产率：PCB板布线面积/工作日

3.5 缺陷

统计各开发阶段中所注入的缺陷数及所发现的缺陷数。采用双折线图进行描述，例图如下：

图3 缺陷发现和缺陷注入分布图

缺陷率统计：

平均每千行代码产生的缺陷数：缺陷数/KLOC；

平均每个工作日产生的缺陷数：缺陷数/实际工作量；

平均每个工作周产生的缺陷数：缺陷数/项目跨周数。

3.6 风险

实际发生的风险、所造成的影响和采取的行动与计划的比较。非预计风险的数量及描述。采取表格形式。

3.7 技术方案评价

项目采用的技术的利弊。

4 经验及教训

根据第2节中项目状态总结，项目经理分析项目所获得的经验以及今后应该注意问题。

5 建议

针对项目中的实践，项目经理提出一些改进建议，例如对规范。

6 结论

说明项目是否成功，以完全满足验收标准为成功。