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)软件中使用到的第三方控件：ponentArt Web.UI 2006.1252 for asp.2.0

(7)软件中使用的安全Ikey驱动：Ikey Driver

以上参考资料是截止2007-08-31是最新的资料文档。

如有修改，即使修改此处的参考文档名称。

2 开发工作评价

2.1 对生产效率的评价

(1)系统开发已历时快1年的时间了

(2)开发的反复性比较多。

(3)对客户的需求理解不是很透彻。

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

2.2 对产品功能的评价

经过我们公司各位同事的共同努力协作，XXX业务管理系统已经很好的完成了客户的业务流需求。

经过对客户使用过程的观察，此项目开发的还是比较成功，但是还是存在着一些问题，造成这些问题的原因是多方面的。

如：前期系统数据库的设计缺陷和部分代码的构建缺陷、客户需求的理解上也存在一定问题，这就需要我们用一定的时间来维护客户使用过程中提出的新问题和存在的debug。

总的来说，此系统的功能开发还是一个比较成功的案例。

2.3 对技术方法的总结

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

(1)使用代码生成器：使用代码生成器 [动软.代码自动生成器]，此工具在很大程度上提高了编码效率，从而加快了项目的开发进程。

在以后的项目中，我们要尽量的来使用一些类似的工具来在最短的时间内完成工作。

在今后的项目开发中，我们最好是能开发出适合自己的代码生成工具，更大限度的节省开发周期和开发费用。

(2)使用数据库建模工具：PowerDesigner 工具来建立系统数据库模型，以方便程序员很好的理解业务流和掌握系统架构者的架构思想，更好的满足客户的功能需求。

在今后的项目开发中，我们要更好的来完成系统的前期数据库模型的建立，最大的来优化系统功能。

(3)使用第三方控件：此系统中使用了ponentArt Web.UI 第三方控件。

此控件在很大程度上满足了客户对软件界面的需求，从而也给软件的操作带来了方便。

本项目中只使用了ponentArt 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)在一个项目的开发中，文档的书写是极为重要的一项工作。

因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也是我们程序员在编码过程中要用到的重要文档。

我们绝对不能认为，凭借我们的大脑来记录所有的开发需求。

即使，你说你是天才，你要用你那颗爱因斯坦的大脑来记录所有的开发需求，那也是不可能的，人的精力总是有限的。