软件项目复习总结报告.doc

行政审批技术评审信息服务 项目总结报告 目 录 TOC \o 1-4 \h \z \u 1 一般信息 1 2 风险管理 1 2.1 风险类别统计 1 2.2 风险等级统计 1 3 工作产品规模 2 4 工作量 2 4.1工作量分配（人时） 2 4.2 工作量偏差分析 3 5 缺陷 3 6 主要工作产品归档 4 7 项目经验总结 4 8、项目组推荐优秀实践列表 5 TOC \n \h \z \c 表格 1 一般信息 项目编号 项目名称 客户单位 计划启动日期 计划结束日期 实际启动日期 实际结束日期 2 风险管理 2.1 风险类别统计 风险类别（分布） 商业风险 0 管理风险 1 技术风险 1 2.2 风险等级统计 风险等级（分布） 高（10~12） 1 中（6~9） 1 低（1~5） 0 3 工作产品规模 工作产品名称 估计规模 实际规模 偏差率 代码（行） 12000 12822 6.9% 4 工作量 4.1工作量分配（人时） 里程碑 计划工作量 实际工作量 工作量偏差率 需求/设计里程碑 331.00 320.00 -3% 编码/测试里程碑 800.00 832.00 4% 验收里程碑 97.00 97.00 0% 总计 1228 1249 4.2 工作量偏差分析 估计工作量： 1200人时 实际工作量： 1249人时 估计偏差率：（实际工作量-估计工作量） / 估计工作量 × 100% ＝ 4.1% 5 缺陷 分类 严重程度 合计 已修复缺陷 合计 缺陷修复率 测试缺陷密度（个/千行代码） 高 中 低 高 中 低 　 测试 15 35 27 77 15 35 27 77 100.0% 6.01 验收 0 5 0 5 0 5 0 5 100.0% 0.39 小计 15 40 27 82 15 40 27 82 100.0% 6.40 6 主要工作产品归档 序号 工作产品名称 备注 项目计划书 项目估算表 项目实施进度表 项目状态报告 里程碑报告 需求规格说明书 需求跟踪表 软件设计说明书 评审报告 测试用例 缺陷记录 测试报告 基线记录 变更申请单 变更管理表 决策分析报告 系统安装包 软件交付清单 安装手册 源代码 7 项目经验总结 7.1签定合同一个项目的开发成败或者说项目开发带来效益的大小，在很大程度上是受项目合同签定的影响的。往往，很多一部分公司与客户签定的项目合同都是很模糊的，也很难签定的比较清楚，这样以来就会导致在项目的开发后期，工作量会越来越大，影响项目的竣工周期；而且，项目的开发费用一般是不会变的。这样以来，我们就大大的降低了我们的开发效益。虽然需求范围很难签定的明确，但是我们在签定合同时，要尽量的去把合同功能边界和添加新功能的条件签定。 7.2开发团队在项目确立后，要尽快的建立起项目开发团队。项目团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这样，在项目的开发过程中，团队才不会被难题困住不动。另外，团队中要有一个项目负责人，这个人无论是在与客户的沟通上，还是在技术上都要是很出众的人，此项目负责人要能很好的沟通客户与开发成员之间，以此来更好的理解客户的功能需求。人的记忆力总是有限的，所以就要求开发团队成员要尽量的书写一些开发文档，这些文档往往是我们在项目开发后期要用到的可寻资料。项目团队士气是项目成功的一个因素,我们需要不断的来培养我们的团队气势，使我们的团队不断的壮大。 7.3需求的调研 在项目确立后，就到了需求调研分析阶段。 （1）项目组对客户的整体组织结构、公司有关人员的关系、职责等如果没有一个很好、足够的了解掌握，这样项目组就无法很好的完整的整理到客户的需求、或者说客户真实的功能需求，如此以来我们就为自己埋下了地雷，影响项目的开发周期，这就要求我们要与客户搞好无论是工作上的还是生活上的朋友关系，要深入的去了解客户需求。 （2）我们要尽量的让客户也参与到项目的开发团队中来，也就是说我们要使客户把自己也纳入到项目的开发团队中来，如此一来，我们掌握客户需求的真实性、可靠性就会大大的提高，也就不会为项目的后期功能开发埋下陷阱。 （3）在需求调研过程中，如果缺乏足够用户参与，这样的需求调研也是失败的。很多程序员不愿参与到客户的需求调研中去，为什么呢？很简单，与客户沟通不如与代码沟通容易有意思。尽管这样，我们还是必须用足够多的时间去和客户进行沟通，了解他们真实的需求。很多用户也是如此，他们自己也不愿意参与到项目的需求调研中来，为什么呢？需求调研有出去和朋友一块烂漫吗？！虽然现状如此，我们还是要努力的使客户参与到需求的调研中来。 （4）模糊需求，也就是模棱两可是需求规格说明中最为可怕的问题。一是指