项目结项总结报告模板(it项目总结报告模板)
项目结项总结报告模板
项目结项总结报告模板
在经济飞速发展的今天，报告与我们愈发关系密切，报告根据用途的不同也有着不同的类型。那么一般报告是怎么写的呢？下面是小编精心整理的项目结项总结报告模板，希望对大家有所帮助。
篇一：结项总结报告
1. 项目背景
{可参考原项目方案建议书中的项目背景描述。}
2. 项目信息
项目实施周期： 项目参与人：
产品实现的主要功能：
｛主要功能中需要说明针对立项范围对比：注明全部实现，没有实现部分以及新增实现部分｝
3. 主要成果
{工作成果可以是产品、文档或者某方面经验的成功应用，并在描述中对其进行介绍。
文档或产品可以描述其版本、主要内容，工作经验则描述主要应用与应用效果。结合总体计划中2.3项目交付成果描述，工作成果中可以在组织级复用或推广使用的，请在描述中说明}
4. 计划与实际情况对比
{以下数据项可根据项目情况做出调整，给出各数据项的计划、实际情况的数据，以及比较后的情况说明。数据MA004_项目测量数据表、测试工作阶段报告;如存在计划变}
5. 开发工作评价
{以下开发类项目工作的评价，结合《MA004_项目测量表》中测量指标给予量化评价。}
5.1. 对生产效率的评价
{给出实际生产效率，并与公司平均水平或计划数据作为对比，分析原因。数据，项目测量表}
5.2. 对产品质量的评价
{说明在测试中检查出来的错误发生率（缺陷密度），与目标值对比，分析原因。数据测试工作阶段报告}
5.3. 对过程符合性的评价
{说明在软件过程符合性，与公司平均水平或目标值对比，分析原因。数据QA工作报告}
5.4. 对技术方法的评价
{给出对在开发中所使用的技术、方法、工具、手段的评价。如存在技术问题，注明解决部门；对于可以列入公司公用构件库的构件，请说明}
5.5. 问题的分析
{针对项目管理进行统计分析以及根本原因分析。数据PMC007_问题跟踪表}
6. 经验与教训
{描述项目实施中来自产品实现、项目管理、关系处理、成本控制等各个方面经验与教训,对后续开发工作的建议以及对项目定义过程的评价。在结项评估中进行分析总结，纳入组织财富库}
7. 知识产权（可选）
{描述产品知识产品的申报情况。}
8. 项目维护建议
{产品开发类项目、维护开发类项目和合同开发类项目必须填写。
描述项目进入维护期开发工作主要内容，对维护工作量的估算和人力资源计划，建议本项目开发维护人员的人选和工作安排。}
9. 申请结项理由
{说明结项理由：正常结项和异常结项。异常结项必须说明结项原因。}
篇二：结项总结报告
摘要：和谐社会建设离不开社会道德问题的解决，最为其中翘楚的让座纠纷问题尚未从参与者心理层面进行研究。本文针对传统问题分析方式的种种不足，从让座者、座位需求者以及旁观者等角度去进行调查（问卷及访谈）以反思现状。并根据调查到的数据与资料哦分析出相应的对策，对让座纠纷问题解决的有效性进行研究，从而探讨出优化现行群众及官方纠纷解决的措施。从14年五月到15年九月我们课题组成员做出了大量富有成效的研究工作，并取得了一定的成果。
关键词：让座纠纷 心理 引导
一、引言
近年来关于公共交通的座位之争相关的新闻数不胜数，其作为社会道德问题的一个现实反映，却被称作新闻领域的“月经帖”，屡见不鲜，调侃的背后透露出几分无奈几分悲哀。随着网络普及，各种媒体曝光，让座纠纷问题日趋严重。在此本课题具体研究较为普遍的让座纠纷问题——公交车让座纠纷。
随着目前公共交通发展的日益成熟，公交车成为了较多人的出行选择，然而公交车作为最为普遍的一种大众运输工具，应该是最安全最快捷的，现在却成为一个危险的区域，还有生命之虞，不能不说是时代的悲哀。
然而公交车作为一种公共交通工具，必然不可能做到让每一个需要座位的人都得到满足，在这种情况下，让座纠纷看似无法避免，然而目前对于让座纠纷的研究，大多关注于公交设施资源问题、新时期道德体系建设问题等，因此研究公交车让座纠纷产生的心理因素有利于从另一个视角来看待此问题，也有利于帮助问题的解决。
二、研究方法
（一）文献研究法
文献研究法指对文献进行查阅、分析、整理，从而了解研究对象的一种研究
方法。本文主要通过搜索中国知网、维普中文期刊数据库、万方数据等中文数据库进行查阅，搜集有关大学生志愿服务活动的相关资料，全面了解学者对大学生志愿服务的研究，为本课题提供理论支持。
（二）调查研究法
（1）问卷调查法
本课题的研究总体范围较广，于是采用偶遇抽样法来选取研究对象。在兰州大学榆中校区采用随机抽样的预调查，后期将问卷分年龄层次随机发放。总计回收有效问卷纸质版67份，电子版146份，共计213份。有效问卷回收率为80％.调查中男女比例大体相同。
（2）半结构式访谈
问卷以选择题为主，对于不同年龄层次的不同群体设计针对性、选择性的问题。对于实地发放回收的问卷，我们挑选了一些参与者进行了简短的提问并记录。将此类同时填答问卷并参与微访谈的参与者单独分组。在研究后期对于此组资料进行较为深入的分析。同时，对于一些不能详细地出现在问卷上、需要进行深度交流的问题，进行了随机访谈。
三、研究过程和做法
让座纠纷的产生对象不仅仅局限于纠纷双方，其实在场所有乘客及司机都可以参与其中，所以研究不应局限于对参与过让座纠纷的人群，为了保证课题的全面性与实施的条理性，我们将研究分为以下几个阶段
（一）准备阶段
1.订立课题
2.选定研究人群
做好研究的信息搜集：根据小组分析的让座纠纷产生的可能情况，拟定调查问卷，对不同人群分发相同问卷，并按统一标准进行统计分析。
（二）实施阶段
实施阶段是完成本课题研究的.重要阶段，我们对不同人群分发问卷，收集并统计不同人群的数据资料。
（1）问卷拟定及预调查阶段
让座纠纷的产生原因不能简单归结为单方面的不道德，纠纷的产生可能有多方面原因，不能一概而论。
小组拟定问卷后，对此问卷进行了预调查与效度分析，删改了一些问卷内容。
（2）问卷定稿及发放回收阶段
由于第一次实地问卷回收并不理想，小组第二次发放问卷选择实地发放与网络调查同步进行。
在进行网络调查时，我们将同一份问卷分两个网页进行填答，较为成功通过分离不同网页的填答年龄层将两组问卷大致分为青年组与中老年组。从而减少了后期统计分析的工作量。
对于实地发放回收的问卷，我们挑选了一些对于“您是否参与过让座纠纷”这项问题填答“参加过”选项的参与者进行了简短的提问并记录。将此类同时填答问卷并参与微访谈的参与者分为A组。在研究后期对于A组资料进行较为深入的分析。
（3）数据整理与分析阶段
通过对参与问卷调查的人进行年龄段的分类，本研究假定青年人群鲜有对座位的需求，故不将青年人群作为座位需求者加以考虑。在基本信息采集部分年龄属于青年的共有101份（电子问卷59份，纸质问卷42份）。在此群体中填答表示参与过让座纠纷的共有14名，仅旁观未参与过让座纠纷的共有37名。
青年群体作为让座的主要人群，大部分在让座纠纷中属于让座方。
中老年群体作为座位的主要需求群体，大部分在让座纠纷中属于座位需求者。 通过如上的分类方式，课题组成员通过对不同年龄层次的分析来进行数据的整合与处理。
四、结果与分析
1、青年群体选择让座的主要原因分析
对于让座纠纷中的让座方（多数为青年人）极少数会因为外界压力或道德绑架而让座，他们的让座行为多数出于自己的个人选择（认为他人比自己更需要帮助）或是自身价值观（助人为乐）引导所致。
2、青年群体选择不让座的原因分析
对于在一些情况下不选择让座的人，他们的缘由较多为个人不愿意让座，多数认为自己对座位的需求要高于需求座位的人。
同时，责任分散效应也对让座行为产生较大影响，一些填答问卷者表示，在一些情况下自己会觉得坐在靠车前方一点的人将会让座或是坐在爱心专坐上的青年人将会让座，自己虽然有让座之意但也轮不到自己，从而造成个人做出不让座的选择。
由此看来，在让座纠纷中让座方拒绝让座并不是个人道德层次不高，在很多情况下是由于自身对座位较为需求，或没意识到身边的人有对座位的需求而导致的。
五、青年群体选择不让座时的一般表现分析
多数青年人在已经做出不想让座的选择之后，他们用以避免让座的方式多为坐在角落或忙自己的事（比如玩手机之类）。然而在一些较为冲动的座位需求者（或是围观群众）看来，青年人这样的行为无疑是不礼貌的，与他们心中的传统价值观与道德行为相悖，从而轻者恶语相向，重则推搡怒骂。又因为现在青年人逆来顺受之辈甚少，又对道德绑架之类嗤之以鼻，座位需求者（或是围观群众）的压力反而会激发起他们的逆反心理，更加拒绝让座，从而导致纠纷。
篇三：结项总结报告
一、绪论
说明：在绪论中简要说明设计工作的目的、意义、研究设想、方法等。应当言简意赅。有关历史回顾和前人工作的，可以适当综合评述。
1. 概述
介绍项目设计的背景，目的、意义，项目的设计环境，项目的应用范围，项目的研究方法等。
2. 国内外现状
说明项目所用技术国内外发展的现状和实际应用的产品等。
二、关键技术介绍
说明：对报告所涉及到的关键技术和所用的专有名词进行简要的介绍，在报告的其它部分一般不再叙述通用技术。
1. 专有名词介绍
对于报告中出现的专有名词进行介绍，例如SRAM，FPGA，状态机等。
2. 关键技术介绍
对于项目中用到的关键技术进行介绍，例如IP核复用，March C-算法等技术。
三、系统分析
说明：在本部分中分析项目所作测试电路应实现的功能，项目的可行性分析，待测的SRAM IP核的结构框图及功能说明，测试电路所采用的算法以及项目的流程图等部分。
1. 项目的功能描述 2. 项目的可行性分析 3. 待测目标SRAM 分析 4. 测试算法分析 5. 测试电路系统流程图
四、系统设计
说明：可分为模块初步划分和模块详细划分，分别说明每个模块的整体功能，端口界定，以及端口功能的详细描述，并且给出这几个模块端口之间的相互关系图和关系的说明等。
1. 初步划分
把整个项目初步划分成几个模块，分别说明每个模块的整体功能，端口界定，以及端口功能的详细描述，并且给出这几个模块端口之间的相互关系图（可从EDA工具中截取，或者用visio软件画出），然后对模块之间的相互关系进行说明。
例如本设计可分为Data_Path和Controller两个模块。分别说明。
2. 详细划分
对初步划分的模块进行详细的划分，每个模块又可划分成若干个小模块，详细说明每个小模块的功能，进行端口的界定，并对端口信号进行简单描述，然后给出模块之间的关系图。
it项目总结报告模板
it项目总结报告模板
it项目总结报告模板【1】
I 引言
1.1编写目的
说明编写这份项目开发总结报告的目的，指出预期的阅读范围。
1.2背景
说明：
a.本项目的名称和所开发出来的软件系统的名称;
b.此软件的任务提出者、开发者、用户及安装此软件的计算中心。
I.3定义
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
1.4参考资料
列出要用到的参考资料，如：
a.本项目的已核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件;
c.本文件中各处所引用的文件、资料，包括所要用到的软件开发标准。
列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
2 实际开发结果
2.1产品
说明最终制成的产品，包括：
a.程序系统中各个程序的名字，它们之间的层次关系，以千字节为单位的各个程序的程序量、存储媒体的形式和数量;
b.程序系统共有哪几个版本，各自的版本号及它们之间的区别;
c.每个文件的名称;
d.所建立的每个数据库。
如果开发中制订过配置管理计划，要同这个计划相比较。
2.2主要功能和性能
逐项列出本软件产品所实际具有的主要功能和性能，对照可行性研究报告、项目开发计划、功能需 .求说明书的有关内容，说明原定的开发目标是达到了、未完全达到、或超过了。
2.3基本流程
用图给出本程序系统的实际的基本的处理流程。
2.4进度
列出原定计划进度与实际进度的对比，明确说明，实际进度是提前了、还是延迟了，分析主要原因。
2.5费用
列出原定计划费用与实际支出费用的对比，包括：
a.工时，以人月为单位，并按不同级别统计;
b.计算机的使用时间，区别CPU时间及其他设备时间;
c.物料消耗、出差费等其他支出。
明确说明，经费是超出了、还是节余了，分析其主要原因。
3 开发工作评价
3.1对生产效率的评价
给出实际生产效率，包括：
a.程序的平均生产效率，即每人月生产的行数;
b.文件的平均生产效率，即每人月生产的千字数;
并列出原订计划数作为对比。
3.2对产品质量的评价
说明在测试中检查出来的程序编制中的错误发生率，即每干条指令(或语句)中的错误指令数(或语句数)。
如果开发中制订过质量保证计划或配置管理计划，要同这些计划相比较。
3.3对技术方法的评价
给出对在开发中所使用的技术、方法、工具、手段的评价。
3.4出错原因的分析
给出对于开发中出现的错误的原因分析。
4 经验与教训
列出从这项开发工作中所得到的最主要的经验与教训及对今后的项目开发工作的.建议。
软件项目总结报告范文【2】
1 引言
1.1 编写目的
XXX公司业务管理系统的开发已经基本完成。
写此项目开发总结报告，以方便我们在以后的项目开发中来更好的实施项目的订制开发; 让我在今后的项目开发中有更多的有据的资料来规范我们的开发过程和提高我们的开发效率，从而创造更多公司效益。
1.2 背景
项目名称：XXX业务管理系统
软件名称：XXX业务系统
客户：XXX
用户：XXX员工
1.3 参考资料
项目开发文档：
(1)软件开发数据模型：PDM_OperationSystem20070831.pdm
(2)数据库开发文档： XXX业务管理系统数据库设计说明书2.0.doc
(3)软件业务流程参考：XXX业务管理系统流程说明.doc
(4)软件使用手册参考：XXX业务管理系统功能说明3.0.doc
(5)软件业务流程参考：XXX业务管理系统流程说明.doc
(6)软件中使用到的第三方控件：ComponentArt Web.UI 2006.1252 for asp.net2.0.rar
(7)软件中使用的安全Ikey驱动：Ikey Driver.rar
以上参考资料是截止2007-08-31是最新的资料文档。
如有修改，即使修改此处的参考文档名称。
2 开发工作评价
2.1 对生产效率的评价
(1)系统开发已历时快1年的时间了
(2)开发的反复性比较多。
(3)对客户的需求理解不是很透彻。
综合以上，此项目的开发效率不是很高，相反有相当一定时间的浪费。
2.2 对产品功能的评价
经过我们公司各位同事的共同努力协作，XXX业务管理系统已经很好的完成了客户的业务流需求。
经过对客户使用过程的观察，此项目开发的还是比较成功，但是还是存在着一些问题，造成这些问题的原因是多方面的。
如：前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定问题，这就需要我们用一定的时间来维护客户使用过程中提出的新问题和存在的debug。
总的来说，此系统的功能开发还是一个比较成功的案例。
2.3 对技术方法的总结
在此项目中使用到技术和工具：
(1)使用代码生成器：使用代码生成器 [动软.Net代码自动生成器]，此工具在很大程度上提高了编码效率，从而加快了项目的开发进程。
在以后的项目中，我们要尽量的来使用一些类似的工具来在最短的时间内完成工作。
在今后的项目开发中，我们最好是能开发出适合自己的代码生成工具，更大限度的节省开发周期和开发费用。
(2)使用数据库建模工具：PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。
在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。
(3)使用第三方控件：此系统中使用了ComponentArt Web.UI 第三方控件。
此控件在很大程度上满足了客户对软件界面的需求，从而也给软件的操作带来了方便。
本项目中只使用了ComponentArt Web.UI一种第三方控件，在今后的项目开发过程中，要继续使用第三方的控件。
这样以来，无论是针对软件界面的美观性、友好性来说、易操作性而言，还是针对系统开发效率而言，这都是很好途径。
但需要注意的是：在使用第三方控件时，要谨慎的选择一些网络中的比较常见的第三方控件。
(4)使用自定义控件：此系统中使用了自定义控件(GhdGridView)，此自定义控件可以很好的统一系统中的所有信息显示表格样式。
如客户对数据显示样式有什么新的意见，我就不需要修改每一个页面的表格样式，我们只需要修改GhdGridView控件的样式，系统中的所有继承自GhdGridView的表格样式都可以改变。
(5)系统开发框架：此系统的框架使用的是简单三层结构，此框架在开发一些中小软件是比较实用的。
但是我们要是可以开发出自己的框架，把一些通用的功能开发到框架中。
这样以来，在以后的系统开发中，针对系统中一些通用的功能就不需要再开发，从而也可以很好的提高我们的开发效率;减少很多维护费用。
使我们的技术不断的更加成熟。
(6)系统安全加密：此系统中针对客户提出的系统安全问题，我们采用了Ikey加密硬件钥匙来验证客户端登陆客户的合法性，此Ikey钥匙可以绑定到一个系统使用用户，也可以让多个用户来使用一个加密钥匙来验证登陆系统的合法性。
这样以来，即使用户的密码不慎丢失，或者被不法人员取得(不法人员他也是无法登陆到我们的系统中来)，这样就最大的提高了我们系统的安全性。
Ikey加密钥匙是很好的加密B/S架构软件的硬件工具，在以后的软件安全方面可以借鉴。
3 项目经验总结
3.1 签定合同
一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。
往往，很多一部分公司与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作量会越来越大，影响项目的竣工周期;而且，项目的开发费用一般是不会变的。
这样以来，我们就大大的降低了我们的开发效益。
虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的条件签定。
3.2 开发团队
在项目确立后，要尽快的建立起项目开发团队。
项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。
这样，在项目的开发过程中，团队才不会被难题困住不动。
另外，团队中要有一个项目负责人，这个人无论是在与客户的沟通上，还是在技术上都要是很出众的人，此项目负责人要能很好的沟通客户与开发成员之间，以此来更好的理解客户的功能需求。
人的记忆力总是有限的，所以就要求开发团队成员要尽量的书写一些开发文档，这些文档往往是我们在项目开发后期要用到的可寻资料。
项目团队士气是项目成功的一个因素,我们需要不断的来培养我们的团队气势，使我们的团队不断的壮大。
3.3 需求的调研
在项目确立后，就到了需求调研分析阶段。
(1)项目组对客户的整体组织结构、公司有关人员的关系、职责等如果没有一个很好、足够的了解掌握，这样项目组就无法很好的完整的整理到客户的需求、或者说客户真实的功能需求，如此以来我们就为自己埋下了地雷，影响项目的开发周期，这就要求我们要与客户搞好无论是工作上的还是生活上的朋友关系，要深入的去了解客户需求。
(2)我们要尽量的让客户也参与到项目的开发团队中来，也就是说我们要使客户把自己也纳入到项目的开发团队中来，如此一来，我们掌握客户需求的真实性、可靠性就会大大的提高，也就不会为项目的后期功能开发埋下陷阱。
(3)在需求调研过程中，如果缺乏足够用户参与，这样的需求调研也是失败的。
很多程序员不愿参与到客户的需求调研中去，为什么呢?很简单，与客户沟通不如与代码沟通容易有意思。
尽管这样，我们还是必须用足够多的时间去和客户进行沟通，了解他们真实的需求。
很多用户也是如此，他们自己也不愿意参与到项目的需求调研中来，为什么呢?需求调研有出去和朋友一块烂漫吗?!虽然现状如此，我们还是要努力的使客户参与到需求的调研中来。
(4)模糊需求，也就是模棱两可是需求规格说明中最为可怕的问题。
一是指诸多客户对需求说明产生了不同的理解;一是指单个读者能用不止一个方式来解释某个需求说明。
针对对这种情况，就要求我们的调研人员要能够从多个角度来分析客户的不同需求，整理出最终的需求与客户确认，定出最终真实可靠的需求，我们绝不能凭借我们自己的单面理解来定立客户的最终需求。
(5)在一个项目的开发中，文档的书写是极为重要的一项工作。
因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也是我们程序员在编码过程中要用到的重要文档。
我们绝对不能认为，凭借我们的大脑来记录所有的开发需求。
即使，你说你是天才，你要用你那颗爱因斯坦的大脑来记录所有的开发需求，那也是不可能的，人的精力总是有限的。
这就要求我们在需求调研中做好需求文档的记录和整理。
(6)需求调研工具选择，客户一般对图形还是比较感兴趣的，所以我们在调研过程中，我要尽量的采用图形化界面来和客户沟通需求。
比如可以采用Rose工具，把客户的意思转换为用例图、时序图、协作图、状态图、类图等，使表达的意思更加直观。
这样客户会更快的进行问题的实质。
3.4 做好开发计划
在项目确立后，我们就需要做好项目开发计划，需求调研用时，开发用时，测试用时，实施用时，维护用时。
在我们做好了计划后，我们要随时的跟踪计划任务的完成进度，从而使我们的项目进度掌控在我们的开发周期范围之内，今日计划、行动，明日成功。
3.5 很好的沟通
在其他行业中，人与人的之间的沟通是很重要的。
项目开发也不例外，很好的沟通能够加快项目的进度，这就要求我们每一个开发人员要学会和善于沟通于客户和同事之间。
在一个项目的开发过程中，我们与客户的沟通是一个不断交流和沟通的过程。
在开发到一定的阶段，我们就需要和客户沟通已有功能，尽量的去避免一些隐藏的问题，及时的发现问题，解决问题，从而按时或者提前完成项目的开发。
3.6 做好工作总结
在项目进行的过程中，我们要不断去整理自己的工作情况和做好总结，这样以来，无论是在自己的技术还是其它方面，都会对我们有很大的提高，在长期的积累后，无论是我们个人能力，还是我们的团队能力都会有很大的提高。