软件项目技术总结报告.docx

软件工程技术总结报告团篇一：软件工程技术总结报告团附件 产品研制技术总结报告（参考提纲）一、产品研制的目的 和意义：从产品与国家产业、技术、行业政策的相符性，对促进 产品结构与产业结构优化升级的重要性，对主要应用领域需求的 迫切性来阐述。团二、产品研制的技术路线：产品研制过程中采取了哪些技术原 理、方法、工艺等内容，以获取该产品的核心技术。切不用产品 加工制作过程中，具体的工艺步骤或流程顺序等工艺路线来描 述。团三、产品的功能特点及主要技术性能指标（列表并说明）四、 技术关键及解决途径1、技术关键2、解决途径五、产品的创 团新性和先进性I、产品的创新性（应说明产品在新设计构思、新 技术、新结构、新 材质、新工艺、新配方等某几个方面的创新点、创新程度（首创、重大改进、较大改进）以及创新范围（国际首次或首批,内首次或首批、本市首次或首批）进性（指与同类典型产品比拟说明时，首先要同国内同类先进 产品比拟；假设属国际领先或国际先进，还需与国外同类典型产 品相比拟。保密申明：秘密级软件工程总结报告5开发工具和环境5.1开 发工具陈述开发工具及使用情况5.2开发环境陈述开发环境7 /26保密申明：秘密级 软件工程总结报告6风险管理6.1风险系数 在工程阶段中的变化趋势工程阶段 风险 说明风险1风险20.50 0 0 0 0 0 0.2 0.5 0 0 0 0需求分析设计编码测试实施风险系数在工程阶段中的变化趋势风险1 0.6 0.5 0.4 0.3 0.2 0.1 0需求分析设计工程阶段编码测试风险26.2降低风险的策 略风险说明说明风险系数8/26保密申明：秘密级软件工程总结报告7估计偏差率7.1进度估 计偏差率（）实际进度周期立项时估计工程周期需求/计划时 估计立项时进度估计偏差率（）需求/计划完成时进度估计 偏差率（）工程周期7.2工作量估计偏差率立项时估计工作 量 需求/计划时估计立项时工作量差率（）需求/计划完成时工 作量估计偏差率（）实际工作量工作量7.3代码规模估计偏差 率立项时估计代码规模需求/计划时估计立项时代码规模估计 偏差率（）需求/计划完成时代码规模估计偏差率（）实际 代码规模代码规模9/26保密申明：秘密级 软件工程总结报告8规模1）产品规模情况总 结采用“工作产品规模完成情况”指示器，总结各工作产品的 规模完成情况，应包括合 计规模完成比例，规模偏差率等。2） 偏差原因说明: 团假设规模偏差率超过设定的阈值，需要对偏差原因进行总结分 析。3）改进措施：团假设规模偏差率超过设定的阈值，需要总结改进措施。U0/26保密申明:秘密级 软件工程总结报告9工作量9.1工作量概况1） 工程工作量情况总工作量偏差情况，数据来源: 团“当前工作量情况”指示器: 团工程组人数估计的工作量实际的工作量总工作量偏差总工 作量偏差率 登一般/最大值340 person days = 2890 person hours （340x8.5）人 /天或人/小时3580 person hours = approximately 420 person days 人/天或人/小时从“当前工作量 情况”指示器”中拷贝图“阶段工作量情况”、“阶段工作量 相对偏差率”于下，总结各阶段工作量变化情况2）偏差原因说 明： 团假设工程总工作量偏差率超过设定的阈值，需要对偏差原因进行 总结分析。3）改进措施：团假设工程总工作量偏差率超过设定的阈值，需要总结改进措 施，。9.2工作量分布情况1）工作量按阶段、按活动分布的 情况: 团总结工作量按阶段、按活动分布的情况，应包括各阶段、各活 开工作量投入实际值和比例，及偏差率等计划 阶段需求分析 设计编码比例（%）工作量（人日）比例（）实际工作量（人日）保密申明：秘密级 软件工程总结报告测试 实施 合计计划 任务 类型需求分析 设计 编码 测试 实施工程管理 过程管理 配置 管理SQA合计比例（）工作量（人日）比例（）实际工作量 （人日）偏差（%）2）偏差原因说明：团假设工程工作量阶段分布、活动分布偏差率超过设定的阈值，需 要对偏差原因进行总结分析。团3）改进措施：团假设工程工作量阶段分布、活动分布偏差率超过设定的阈值，需 要总结改进措施。质量本钱统计工程阶段评审工作量测试工 作量返工工作量培训工作量SQA工作量当前质量相关 工作量合计计划工程总工作量质量本钱比例里程碑1里程 碑2里程碑3里程碑4里程碑5合计27 24.1 86 0 137.1165 132 29715 23.6 122.05 0 160.650 6.5 0 0 6.513.2 12.2 31.2 6 62.655.2 66.4 404.25 138 0 663.852728 2728 2728 2728 272827282.0% 2.4% 14.8% 5.1% 0.0% 24.3%12 / 26保密申明：秘密级软件工程总结报告10本钱1）本钱情况采 用“阶段本钱人员投入情况”指示器，呈现总本钱投入情况、各 阶段人力本钱的投入情况和人员数量的投入情况，应包括各阶 段人力本钱偏差率、总本钱偏差率、阶段人员数量等。明2）偏差原因说明：皿假设总本钱偏差率超过设定的阈值，需要对偏差原因进行分析说 明。3）改进措施：团假设总本钱偏差率超过设定的阈值，需要总结改进措施。13/26保密申明：秘密级 软件工程总结报告11生产率1）工程生产率 情况工程编码/工程总工 作量 单元测试 阶段工作 量 代码总 规模工程生命周期生产率（代码功能点/人月）工程编码/ 单元测试阶段生产率（代码功能点/人月）编码/单元测试阶 段生产率估计偏差率计划编码/单元测试阶段生产率2）偏差原 因说明: 团假设编码/单元测试阶段生产率估计偏差率超过设定的阈值，需要 对偏差原因进行总结分析。3）改进措施：耻假设编码/单元测试阶段生产率估计偏差率超过设定的阈值，需要 总结改进措施。14/26保密申明：秘密级 软件工程总结报告12质量12.1质量目标达 成情况总结1）质量目标的达成概况：严重等级 需求 架构设计 概要设计详细设计编码集成测试系统测段验收（试运行） 灾难级/严重缺缺陷注入率偏差率陷次严重缺陷一般/其它缺 陷灾难级/严重缺67%00%00%0.0%缺陷清除率偏差率陷次 严重缺陷一般/其它缺陷14.6%总缺陷清除率偏差率2）偏差原因 说明：团假设总缺陷清除效率偏差率超过设定的阈值，需要对偏差原因进 行分析说明。3）改进措施：团假设总缺陷清除效率偏差率超过设定的阈值，需要总结改进措 施。J15/26保密申明：秘密级 软件工程总结报告12.2缺陷注入率、缺陷清 除率的阶段分布总结严重等级需求架构设计概要设计详细设 计编码单元测试集成测试系统测段验收（试运行）灾难级/ 严重缺陷注入数工程实际缺次严重缺陷注陷注入率0000入数 一般/其它缺陷灾难级/严重缺陷工程实际缺陷清除率次严重 缺陷一般/其它缺陷12.3评审、测试活动总结1）评审活动总 结评审对象评审效率评审速度计划评审工作量实际评审工作 量 评审工作量偏差率 计划缺陷发现数量 实际缺陷发现数量 缺 陷发现数量偏差率需求架构设计概要设计详细设计编码16/26别和团）同国内、外同类典型产品比拟需列表提供企业名称、 公司及主要技术性能指标比拟。团六、产品知识产权状况1、专指该产品的专利、软件著作权等 状况（列表）；进展情况栏保密申明：秘密级 软件工程总结报告2）测试活动总结测试阶 段测试效率测试覆盖率计划测试工作量实际测试工作量测 试工作量偏差率计划缺陷发现数量实际缺陷发现数量缺陷发 现数量偏差率单元测试集成测试系统测试3）测试前缺陷清 除率及发现缺陷比例 缺陷总数 测试前清除的缺陷数量测试前 清除率测试前发现缺陷数量测试前发现缺陷比例（） 12.4缺陷分布情况参见测试总结报告12.5各质量活动发现的缺陷 比例总的缺陷数评审发现的缺陷数测试发现的缺陷数评审测 试发现缺陷数比例17/26保密申明：秘密级软件工程总结报告13需求13.1需求实现情 况D需求实现情况： 明采用“需求实现情况”指示器，应包括需求功能点总数，及各 个实现阶段的需求比例等。2）偏差原因说明：团假设需求实现情况出现较大偏差，需要对偏差原因进行分析说 明。3）调整措施：明假设需求实现情况出现较大偏差，需要说明调整措施。13.2需求 变更情况1）需求变更情况采用“需求功能规模和稳定性”指示 器，呈现需求变更情况，应包括需求变更率（需求稳定性）、 增/删/改的需求数量、需求总数等。2）偏差原因说明: 团假设需求总数的增长超过设定阈值或者在某阶段的变更超过当前 基线的偏差超过设定的 阈值时，需要对偏差原因进行分析说 明。3）改进措施: 因假设需求总数的增长超过设定阈值或者在某阶段的变更超过当前 基线的偏差超过设定的阈值时，需要总结改进措施。18/26保密申明：秘密级 软件工程总结报告14客户反应1）客户反应 情况：团采用“当前客户反应问题处理情况”指示器，呈现客户问题的 解决情况，应包括已解决问题比例、未解决问题比例等。2）偏 差原因说明：耻假设未解决问题比例超过设定的阈值，需要对偏差原因进行分析说明。3）调整措施：团假设未解决问题比例超过设定的阈值，需要总结改进措施。19/26保密申明：秘密级 软件工程总结报告15工程问题1）工程问题 情况：团采用“工程问题处理情况”指示器，呈现工程问题的解决情 因说明: 团假设未解决问题比例超过设定的阈值，需要对偏差原因进行分析 说明。3）调整措施：况,应包括已解决问题比例、未解决问题比例等。】2）偏差原明假设未解决问题比例超过设定的阈值，需要总结改进措施。20 / 26 保密申明：秘密级 软件工程总结报告16组间协调活动跟踪结果 协调小组/人 客户经理 协调方式 会议/ /电子邮件 不定期 客户一 XX部门定期会议 不定期（说明：发生的问题应该有问 题跟踪表作为附件，同时发生问题一栏中需备注问题跟踪表的编 号）协调内容发生问题 处理方式频率/时间21/26保密申明：秘密级 软件工程总结报告17培训列举本工程培训情况：团培训说明时间参加人 培训讲师 工作量 状态完成/h h h未完成 22 / 26保密申明：秘密级软件工程总结报告18过程改进建议总结在项目过程中的对组织标标准过程的相关改进的建议。23/26保密申明：秘密级软件工程总结报告19补充说明对工程开发及 管理的其它经验教训的总结说明。24/26保密申明：秘密级软件工程总结报告20提交产品清单工程结束 细设计、源代码、工程计划、配置计划、质量保证计划、系统测 试计划和验收测试计划等。25/26时所提交的各种产品清单,时所提交的各种产品清单,如合同、需求说明书、概要设计、保密申明：秘密级软件工程总结报告21工程总结说明工程是否 成功，并总结原因。26/26填受理或授权，专利范围栏填中国或国际专利；序号12专利名 称专利类型专利号进展情况专利范围2、技术标准状况：采 用何种标准，是否是标准的制订者，标准的先进性在哪里？ 3、产品商标、品牌状况。团七、结论 通过上面6个方面的论述扼要的总结产品创新的经 验，并从企业 管理创新的角度出发，进一步提高产品质量和性 能，应所采取哪些措施。团八、产品主要研制人员表 单位:序号12 345姓名 性别 职称 学历（盖章）从事研制的内容 本人签名团篇三：软件工程总结报告团软件工程总结报告范文I引言1.1编写目的XXX公司业务管 理系统的开发已经基本完成。写此工程开发总结报告，以方便我 们在以后的工程开发中来更好的实施工程的订制开发；让我在 今后的工程开发中有更多的有据的资料来 规范我们的开发过程 和提高我们的开发效率，从而创造更多公司效益。团L2背景工程名称：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 2.0.rar 7 .软件中使 用的平安Ikey驱动：Ikey Driver.rar以上参考资料是截止 2007-08-31是最新的资料文档。团如有修改，即使修改此处的参考文档名称。团2开发工作评价2.1对生产效率的评价1.系统开发已历时快 1年的时间了 2.开发的反复性比拟多。团3.对客户的需求理解不是很透彻。综合以上，此工程的开发效率不是很高，相反有相当一定时间的 浪费。团2.2对产品功能的评价 经过我们公司各位同事的共同努力协 作，XXX业务管理系统已经很好的完成了客户的业务流 需求。经 过对客户使用过程的观察，此工程开发的还是比拟成功，但是还 是存在着一些问题，造成这些问题的原因是多方面的。如：前期 系统数据库的设计缺陷和局部代码的构建缺陷、客户需求的理解 上也存在一定问题，这就需要我们用一定的时间来维护客户使用 过程中提出的新问题和存在的debug。总的来说，此系统的功能 开发还是一个比拟成功的案例。02.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开发团队在工程确立后，要尽快的建立起工程开发团队。团工程团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这样，在工程的开发过程中,1队才不会被难题困住不动。团另外，团队中要有一个工程负责人，这个人无论是在与客户的沟 通上，还是在技术上都要是 很出众的人，此工程负责人要能很好 的沟通客户与开发成员之间，以此来更好的理解客户的功能需 求。人的记忆力总是有限的，所以就要求开发团队成员要尽量的 书写一些开发文档，这些文档往往是我们在工程开发后期要用到 的可寻资料。工程团队士气是工程成功的一个因 素，我们需要不 断的来培养我们的团队气势，使我们的团队不断的壮大。团3.3需求的调研 在工程确立后，就到了需求调研分析阶段。团1.工程组对客户的整体组织结构、公司有关人员的关系、职责 等如果没有一个很好、足够的了解掌握，这样工程组就无法很好 的完整的整理到客户的需求、或者说客户真实的功能需求，如 此以来我们就为自己埋下了地雷，影响工程的开发周期，这就要 求我们要与客户搞好无论是工作上的还是生活上的朋友关系，要 深入的去了解客户需求。团2.我们要尽量的让客户也参与到工程的开发团队中来，也就是 说我们要使客户把自己也纳 入到工程的开发团队中来，如此一 来，我们掌握客户需求的真实性、可靠性就会大大的提高，也就 不会为工程的后期功能开发埋下陷阱3.在需求调研过程中，如 果缺乏足够用户参与，这样的需求调研也是失败的。很多程序员 不愿参与到客户的需求调研中去，为什么呢？很简单，与客户沟 通不如与代码沟通容易有意思。尽管这样，我们还是必须用足够 多的时间去和客户进行沟通，了解他们真实的需求。很多用户也 是如此，他们自己也不愿意参与到工程的需求调研中来，为什么 呢？需求调研有出去和朋友一块烂漫对吗。团。团虽然现状如此，我们还是要努力的使客户参与到需求的调研中 来。团4.模糊需求，也就是模棱两可是需求规格说明中最为可怕的问 题。一是指诸多客户对需求说明产生了不同的理解；一是指单个 读者能用不止一个方式来解释某个需求说明。针对对这种情况， 就要求我们的调研人员要能够从多个角度来分析客户的不同需 求，整理出最终的需求与客户确认，定出最终真实可靠的需求，我们绝不能凭借我们自己的单面理解来定立客户的最终需求。团5.在一个工程的开发中，文档的书写是极为中要的一项工作。因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也 是我们程序员在编码过程中要用到的重要文档。我们绝对不能认 为，凭借我们的大脑来记录所有的开发需求。乳；即使，你说你是天才，你要用你那 颗爱因斯坦的大脑来记录 所有的开发需求，那也是不可能的，人的精力总是有限的。这就 要求我们在需求调研中做好需求文档的记录和整理。团6.需求调研工具选择，客户一般对图形还是比拟感兴趣的，所 以我们在调研过程中，我要 尽量的采用图形化界面来和客户沟通 需求。团比方可以采用Rose工具，把客户的意思转换为用例图、时序 图、协作图、状态图、类图等，使表达的意思更加直观。这样客 户会更快的进行问题的实质。团3.5做好开发计划 在工程确立后，我们就需要做好工程开发计 划，需求调研用时，开发用时，测试用时，实施用时，维护用时。在我们做好了计划后，我们要随时的跟踪计划任务的完成进度, 从而使我们的工程进度掌控在我们的开发周期范围之内，今日计 划、行动，明日成功。团3.5很好的沟通 在其他行业中，人与人的之间的沟通只很重要 的。工程开发也不例外，很好的沟通能够加快工程的进度，这就 要求我们每一个开发人员要学会和善于沟通于客户和同事之间。在一个工程的开发过程中，我们与客户的沟通是一个不断交流和 沟通的过程。在开发到一定的阶段，我们就需要和客户沟通已有 功能，尽量的去防止一些隐藏的问题，及时的发现问题，解决问 题，从而按时或者提前完成工程的开发。团3.6做好工作总结 在工程进行的过程中，我们要不断去整理自 己的工作情况和做好总结，这样以来，无论是 在自己的技术还是 其它方面，都会对我们有很大的提高，在长期的积累后，无论是 我们个人能力，还是我们的团队能力都会有很大的提高。团篇四：软件工程总结报告 团Xxx系统软件工程总结报告部撰门:团写：团ProjName_M_PSjfe$：号文档编号：文档状态：正式版V1.1版权 属于亿阳信通所有，无亿阳信通的书面同意，任何个人或组织无 权拷贝。团篇二：软件工程总结报告团保密申明：秘密级 软件工程总结报告工程名称软件工程总 结报告编号：工程名称缩写 -CLOSUREREPORT版本:X.X作者: 团审批：SEPG日期：团日期：2002-8-81 / 26文档审批单版本：1.0审批人工程经理质量保证配置管理软 件经理其他备注：此页签字另存。 团签字日期文档修改记录版本号主要作者 修改记录 完成日期前言本模板的编制遵循亿阳信通质量管理体系工程管理册(CRI O PMV-PM_V1.0)的规定，文档模板采用亿阳信通质量管理体系工程管理册：模版：工程总结报告(CRI_O_PMV-PM_Template_PS_V1,0)。目 123 录 项 目 描述 6产品描 述7经验总结及改进建 议831经验总结 832 改 进 建 议 845 项 目 可 借 鉴 文 档9度量数 据 105.1 产 品 数 据 105.2 过 程 数 据11表 目 录 表产 品 数 据 10 表2测试缺陷统计表 10表3质量检查缺陷统计 表4工作量统计表11 表 5 进度 统计表12 表6开发本钱执行指标表12 表7生产率统计表131工程描述？工程编号工程名称 应用领域（电信、 交通、金融、平安、邮政）工程类型（预研、新开发、升级、维 护）工程相关方 应用技术（开发语言、数据库）过程模型工 程方法（分析方法、设计方法、开发方法、测试手段）使用的非 开发部件（重用部件、商业部件）2产品描述？产品名称；应用领域（电信、交通、金融、 平安、邮政）；技术特性（采用的技术、核心功能）；开发 技术（开发产品所需的技术）；用户；版本。3经验总结及改进建议3.1提示经验总结总结工程开发过程中在 工程管理及技术方面可供借鉴的经验。3.2提示改进建议列出组 织的过程体系文件在执行时的不适合之处及改进建议。4工程可借鉴文档提示列出工程开发过程中产生的可供借鉴的 文档名称，放入组织过程财富库中共享。保密申明：秘密级软件工程总结报告变更记录日期文档创立/修 改的日期版本x.x变更说明创立/修改某个地方作者和封面 作者保持一致2/265度量数据5.1产品数据表1产品数据表提示工程应尽量使用功能点数来计算软件规模，只有在工程或软件不适于功能点计 算的情况下，才可用代码行估计。实际规模需求总数（功能点 或代码行）（功能点或代码行）估计规模类的个数需求变更总 数模块个数（如果使用面向对象技术）表2测试缺陷统计表提 示测试中发现的BUG,按严重程度分为5个级别，其中，级别 1、2、3为主要缺陷。级别4为次要缺陷。团按来源设计编码子活动发现主要缺陷次要缺陷缺陷总计 按严重性统计类别发现的活动客户需求软件需求集成测试系 统测试总计表3质量检查缺陷统计表提示有阴影的单元格不用填写。团按来源客户需软件需求求设计编码按严重性子活动发 现 主要缺陷 次要缺陷 缺陷总计统计类别 发现的活动 需求文 档质量 检查 设计文档质量 检查用户手册质量 检查总计5.2 过程数据表4工作量统计表提示1）阶段是根据工程计划中定义 的；活动的类别主要包括: 团需求开发设计编码与单元测试质量检查测试用户手册项 目管理配置管理质量保证培训3）工作量的单位是人时阶 段活动的类别估计人时实际人时阶段活动的类别估计人时实际人时表5进度统计表提示1) 范围是指以下开发活动的进度是属于工程的哪个范围，一般来说 是整个工程，有时可能是另外两种情况：某个主要的产品部件单 独作为子工程进行开发的时候；或者是工程使用了增量交付的生 命周期模型；2)阴影的单元格不用填写。团计划范围整个工程/子工程客户需求软件需求设计编码 系统测试验收测试发布安装开发活动开始日期结束日期 开始日期结束日期实际表6本钱与进度执行指数表提示1） BCWP （实际执行工作的预算本钱），指的是最终的BCWPo团ACWP （实际执行工作的实际本钱），指的是最终的ACWPBCWS（计划执行工作的预算本钱），指的是最终的BCWSo团2）C叫本钱执行指数）。依据公式：BCWP/ACWP=CPI计算。团5） S叫进度执行指数）。依据公式：BCWP/BCWS=SPI计算。BCWSBCWPACWPCPISPI表7生产率统计表提示1）由软件规模获得软件的实际功能点数或代码行数；2）由进度执行指数获得实 际的总工 作量即ACWP； 3）工作量的单位应为人时。4）依据公式：生产率=软件规模/工作量，计算本工程的生产率。软件规 模工作量生产率团篇五：软件工程总结报告团软件工程总结报告范文I引言1.1编写目的XXX公司业务管 理系统的开发已经基本完成。写此工程开发总结报告，以方便我 们在以后的工程开发中来更好的实施工程的订制开发；让我在 今后的工程开发中有更多的有据的资料来 规范我们的开发过程 和提高我们的开发效率，从而创造更多公司效益。团L2背景工程名称：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 2.0.rar 7 .软件中使 用的平安Ikey驱动：Ikey Driver.rar以上参考资料是截止 2007-08-31是最新的资料文档。团如有修改，即使修改此处的参考文档名称。团2开发工作评价2.1对生产效率的评价1.系统开发已历时快 1年的时间了 2.开发的反复性比拟多。团3.对客户的需求理解不是很透彻。综合以上，此工程的开发效率不是很高，相反有相当一定时间的 浪费。团2.2对产品功能的评价 经过我们公司各位同事的共同努力协 作，XXX业务管理系统已经很好的完成了客户的业务流 需求。经 过对客户使用过程的观察，此工程开发的还是比拟成功，但是还 是存在着一些问题，造成这些问题的原因是多方面的。如：前期 系统数据库的设计缺陷和局部代码的构建缺陷、客户需求的理解 上也存在一定问题，这就需要我们用一定的时间来维护客户使用 过程中提出的新问题和存在的debug。总的来说，此系统的功能 开发还是一个比拟成功的案例。02.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开发团队在工程确立后，要尽快的建立起工程开发团队。团工程团队成员的团结合作、相互沟通是非常重要的，团队成员之间要相互学习彼此的优点和技术，使团队的能力不断的提高。这样，在工程的开发过程中,1队才不会被难题困住不动。团另外，团队中要有一个工程负责人，这个人无论是在与客户的沟 通上，还是在技术上都要是 很出众的人，此工程负责人要能很好 的沟通客户与开发成员之间，以此来更好的理解客户的功能需 求。人的记忆力总是有限的，所以就要求开发团队成员要尽量的 书写一些开发文档，这些文档往往是我们在工程开发后期要用到 的可寻资料。工程团队士气是工程成功的一个因 素，我们需要不 断的来培养我们的团队气势，使我们的团队不断的壮大。团3.3需求的调研 在工程确立后，就到了需求调研分析阶段。团1.工程组对客户的整体组织结构、公司有关人员的关系、职责 等如果没有一个很好、足够的了解掌握，这样工程组就无法很好 的完整的整理到客户的需求、或者说客户真实的功能需求，如 此以来我们就为自己埋下了地雷，影响工程的开发周期，这就要 求我们要与客户搞好无论是工作上的还是生活上的朋友关系，要 深入的去了解客户需求。团2.我们要尽量的让客户也参与到工程的开发团队中来，也就是 说我们要使客户把自己也纳 入到工程的开发团队中来，如此一 来，我们掌握客户需求的真实性、可靠性就会大大的提高，也就 不会为工程的后期功能开发埋下陷阱3.在需求调研过程中，如 果缺乏足够用户参与，这样的需求调研也是失败的。很多程序员 不愿参与到客户的需求调研中去，为什么呢？很简单，与客户沟 通不如与代码沟通容易有意思。尽管这样，我们还是必须用足够 多的时间去和客户进行沟通，了解他们真实的需求。很多用户也 是如此，他们自己也不愿意参与到工程的需求调研中来，为什么 呢？需求调研有出去和朋友一块烂漫对吗。团。团虽然现状如此，我们还是要努力的使客户参与到需求的调研中 来。团4.模糊需求，也就是模棱两可是需求规格说明中最为可怕的问 题。一是指诸多客户对需求说明产生了不同的理解；一是指单个 读者能用不止一个方式来解释某个需求说明。针对对这种情况， 就要求我们的调研人员要能够从多个角度来分析客户的不同需 求，整理出最终的需求与客户确认，定出最终真实可靠的需求，保密申明：秘密级软件工程总结报告1工程信息工程名称工程 经理工程编号提交时间3/26我们绝不能凭借我们自己的单面理解来定立客户的最终需求。团5.在一个工程的开发中，文档的书写是极为中要的一项工作。因为，某些文档就是我们在开发后期与客户沟通的可寻依据、也 是我们程序员在编码过程中要用到的重要文档。我们绝对不能认 为，凭借我们的大脑来记录所有的开发需求。乳；即使，你说你是天才，你要用你那 颗爱因斯坦的大脑来记录 所有的开发需求，那也是不可能的，人的精力总是有限的。这就 要求我们在需求调研中做好需求文档的记录和整理。团6.需求调研工具选择，客户一般对图形还是比拟感兴趣的，所 以我们在调研过程中，我要 尽量的采用图形化界面来和客户沟通 需求。团比方可以采用Rose工具，把客户的意思转换为用例图、时序 图、协作图、状态图、类图等，使表达的意思更加直观。这样客 户会更快的进行问题的实质。团3.5做好开发计划 在工程确立后，我们就需要做好工程开发计 划，需求调研用时，开发用时，测试用时，实施用时，维护用时。在我们做好了计划后，我们要随时的跟踪计划任务的完成进度, 从而使我们的工程进度掌控在我们的开发周期范围之内，今日计 划、行动，明日成功。团3.5很好的沟通 在其他行业中，人与人的之间的沟通只很重要 的。工程开发也不例外，很好的沟通能够加快工程的进度，这就 要求我们每一个开发人员要学会和善于沟通于客户和同事之间。在一个工程的开发过程中，我们与客户的沟通是一个不断交流和 沟通的过程。在开发到一定的阶段，我们就需要和客户沟通已有 功能，尽量的去防止一些隐藏的问题，及时的发现问题，解决问 题