软件项目管理大作业(doc 37页).doc

政府公文审批及工作通告系统大连理工大学软件学院软件项目管理大作业“政府公文审批及工作通告”应用程序软件项目管理2012年6月1日目录1 合同管理-41.1 需方合同环境-41.1.1 合同准备-41.1.2 合同签署-51.1.3 合同管理-51.1.4 合同终止过程-61.2 供方合同环境-61.2.1 合同准备-61.2.2 合同签署-61.2.3 合同管理-61.2.4 合同终止过程-61.3 内部环境-71.4 合同-72 生存期-93 需求管理-103.1 软件需求管理过程-103.1.1 需求规格-113.1.2 需求变更管理-124 任务分解-134.1 任务清单-134.1.1 功能分解清单-134.2 WBS-145 规模估算-155.1 直接成本-155.2 间接成本-185.3估算的误差-186 项目进度-186.1活动定义-196.2活动安排-206.3进度执行与优化-216.4工具使用-217 质量计划-217.1软件项目质量计划-22 7.2软件项目质量保证活动-23 7.3测试计划-257.4质量改善-258 配置计划-268.1配置管理过程-268.2配置管理人员组成-268.3配置管理活动-269 风险计划- 289.1风险识别与评估-299.2 风险规划-309.3风险分析表-319.4风险控制-3110 团队管理-3210.1项目组织结构-3210.2团队沟通管理-3311 项目度量-3311.1度量指标-3311.2数据收集-3412 集成项目- 3512.1项目集成计划-3513 跟踪控制-3513.1本案例分析-3513.2阶段评审报告模版-3614 项目结束-3614.1项目终止-3714.2结束计划-3714.3收尾工作-3714,4最后评审-3714.5项目总结-37第一部分 合同管理1.1 需方合同环境1.1.1 合同准备招标文件XX省委需要引入一套“政府公文审批及工作通告”应用程序，现向社会各软件公司进行公开招标，欢迎有资格的投标商参加。一招标项目名称：“政府公文审批及工作通告”应用软件二招标内容：XX省委“政府公文审批及工作通告”应用程序的设计，开发，安装、调试、使用教学及相应的后期维护升级。三资质要求：具有省级政府项目投标资格的企业或个人，详细要求见投标须知（投标须知略）四投标、开标有关说明： 1.投标文件发售时间：2012年6月8日至2012年6月18日工作时间内 2.投标文件发售地点：XX市XX省政府事务办公室 3.投标文件售价：￥10,000 （售后不退，不接受邮购） 4.投标地点：大连理工大学软件学院图书馆报告厅 5.投标截止时间：2012年6月30日北京时间10:00时 6.开标时间：2012年7月1日北京时间14:00时 7.开标地点：大连理工大学软件学院图书馆报告厅五有关规定： 1.超过投标截止时间、不按规定密封的投标或不按招标文件规定提交有效足额投标保证金（以汇票、支票、现金支付）的投标，恕不接受。 2.提交投标保证金户名：XX省委财务处 3.开户行：XX市渣打银行XXX路分行 4.账号：123456789012345六联络：XX省省政府详细地址：略联系人：略邮编：000000电话：（02X）10000000传真：（02X）10000000招标书详细内容包括技术要求、商务条款、投标人须知、评标方法标准和废标条款、合同主要条款以及投标文件格式此处略。验收标准后文有所体现。供方选择XX省委省政府（即需方）通过公布招标文件、招标、收集供方的建议书、评定供方、最终供方确定的程序确定最终的供方名单及其提供的建议书。合同文本准备XX省委省政府根据采购资料进行合同草案指定、草案评审、修订等程序，最终确定合同草案（合同草案略）。1.1.2 合同签署XX省委省政府与大连理工大学（本文假设大连理工大学投标成功，该项目由大连理工大学下发至大连理工大学软件学院承担设计、开发、安装调试等一系列工作，内部部门人员配置同软件企业相同，借用大连理工大学之名而已。即大连理工大学为供方）以XX省委省政府提出的合同草案为基础，经过确定谈判日程、合同草案提交、合同条款协商、确定合同签署文本、合同签署文本审阅、合同签署的流程完成合同签署。最终形成合同签署文本以及任务下达书。并将任务下达书分发给各中标单位（此处设该项目仅有大连理工大学一家全权负责软件的设计开发）1.1.3 合同管理验收过程XX省委省政府依据合同准备和合同签署时确定的需求资料及合同文本制定验收清单。对验收清单评审后制定验收计划，并按验收计划执行，得到验收报告。对发现的问题制定验收问题处理计划，最终确认验收报告。违约事件处理过程在合同执行期内，如果合同双方XX省委省政府或大连理工大学有违约事件。需根据违约事件报告进行违约事件通告，确定处理方式后按计划处理违约事件。之后形成违约事件处理报告。1.1.4 合同终止过程XX省委省政府与大连理工大学根据合同及相关文档，发布合同终止通知、项目执行总结。1.2 供方合同环境1.2.1 合同准备项目分析大连理工大学（仅以大连理工大学为例）根据招标书安排项目分析任务。经过需求管理者确定、需求分析、需求分析评审、项目规模估算、项目风险分析、项目初步实施规划、初步实施规划评审，最终得到需求分析报告和项目初步规划。竞标大连理工大学按照需求分析报告和项目规划进行竞标，通过技术能力要求确定、人力资源要求确定、实现环境要求确定、资金管理要求确定、能力判定、评估结果审评等评定，并进行需求成熟度评估、用户支持保证评估、用户资金保证评估、可行性分析、项目决策、编写项目建议书等步骤，根据项目建议书参加竞标。合同文本准备大连理工大学根据XX省委省政府提出的采购资料制定合同草案。在经评审和修订后确定己方的合同草案。1.2.2 合同签署同需方，此处略。1.2.3 合同管理合同执行跟踪管理过程大连理工大学以项目计划为基础，进行项目计划审批和合同执行管理规划。按计划完成项目进展报告、合同责任落实、需求变更处理和产品验收。合同修改控制如果需方即XX省委省政府提出变更请求，假设提出的是要求添加不用登录网页直接通过“政府公文审批及工作通告”应用程序即可向网内用户发送邮件，并根据不同层级用户的权限显示网内在线用户。则大连理工大学需依据合同和变更请求进行变更评估，并提出合同修改建议，确定修改策略。对当前计划进行调整，并需得出处理报告。违约事件处理过程同需方，此处略。（不过政府的项目，即便政府违约了供方也得忍着，一般的企业应该就当作什么也没发生过。不过大工校长跟省长貌似平级吧，情况可能会有点不一样。当然政府的项目会不会交给学校来做我也不是很清楚。）产品提交过程在产品的开发测试结束后向XX省委省政府提交产品，经过审查后正式提交给XX省委省政府。最终相方签字认可，通知相关各方。产品维护过程根据合同中的维护需求，制定维护需求记录。1.2.4 合同终止过程同需方，此处略。1.3 内部环境大连理工大学软件学院内部确定任务范围，使相关各方有效的配合。详细任务分解在第四部分任务分解中会有详细阐述。1.4 合同合同双方甲方：XX省委省政府乙方：大连理工大学协议形式协议形式：技术合同供应的商品和服务供应的软件：乙方为甲方提供所需的“政府公文审批及工作通告”应用程序提供的服务：乙方为甲方提供所需的日常维护和服务器管理。同时对甲方用户提供使用教学。提供的文档：乙方在交付软件时提供详细的软件规格说明书和使用文档。安装服务： 乙方为甲方提供软件的安装。公文处理： 乙方负责将甲方提供的公文资料加载入系统并进行分类维护协议： 当甲方在使用该产品时，在正常操作的情况下出现BUG或系统错误，乙方免费为甲方提供修复服务以保障软件的正常使用。当由于甲方的错误使用等非软件原因导致出现故障，乙方同样提供修复服务。由于甲方拥有该软件的源代码所有权，因此甲方需要承担部分维修和进一步开发的责任。当软件需要新的功能拓展或改版升级时，由双方共同协商决定。软件所有权该软件是由甲方向乙方定制，甲方拥有该软件的版权，乙方不能将该软件的任何版本卖个其他客户。软件提交时，项目源代码的所有权自动移交到甲方，乙方不得擅自对源代码进行修改。环境乙方为甲方安装软件和进行员工培训时，需要由甲方提供住宿和膳食，乙方在规定时间内完成任务。甲方要保证安装软件的硬件设备和合同初始规定一致，乙方只保证软件和规定的硬件兼容。由任何一方的单方面原因导致的延期产生的费用，由该方面支付。客户承诺乙方开发软件过程中，甲方通过人员协同乙方进行开发。该人员主要参与项目的规划设计和需求分析，阶段性验收和总体测试。当项目出现需求变更时，对乙方进行详细的阐述说明。乙方不负责这些人员提供食宿和联系设备。验收规程2013年3月15日，乙方为甲方安装所需套数的软件。3月15日至3月31日甲方代表对产品进行验收测试，并根据需求在4月30日前对产品提出更正请求。测试通过后，双方带白哦进行软件交付签字。乙方对甲方进行软件使用培训。标准乙方在开发过程中必须遵守ISO 12207关于软件生命周期和文档的标准。项目和质量管理甲乙双方前四个月每月初进行一次进展会议，后三个月每两周周末进行进展会议。会议内容为乙方向甲方提供最新进度的掩饰和下一阶段的工作安排和计划。甲方根据演示提出相应的整改意见，并对下一步工作进行提出意见和建议。时间表详细时间表见项目进度。此处略。价格和付款方式软件总价为230W。合同签订后，甲方向乙方支付50万元定金。项目的第三个月，乙方按计划时间表完成需求分析、系统分析、设计和完成系统的基本框架后，甲方向乙方支付80万元。该系统完成后，甲方进行验收测试，在签字验收后完成后，甲方向乙方支付全款。其他法律要求由任何一方的过失导致出现损失后的赔偿由双方协商决定。甲方法人代表：SSS乙方法人代表：XXX第二部分 生存期确定该项目的生存期模型按如下步骤进行分析：评审、分析项目的特性；选择适合项目的生存期模型；标识生存期模型与项目不一致地方,并进行裁减。“政府公文审批及工作通告”应用程序涉及到非常敏感的政府机密事务，因此很强调产品的性能和安全性。需保障产品能保持稳定运行，不会因为一定数量的用户同时处理公文等操作时挂机，以致宝贵的消息或通知无法及时传达。同时需保证对于计算机操作不是十分熟识的政府官员的错误操作不会导致严重后果。另外需保证产品的安全性，使非内部用户无法登录或盗取网内信息。总而言之该项目性能安全性为主，可操作性次之，界面美观度最末。虽然操作性的重要性不及安全性，但对于习惯了那种生活的领导们，简单方便的操作仍是必须的，这里与生存期关系不甚大，暂且不作讨论。虽然项目的需求可能会因领导“挑剔”的口味而一再改变，不过大体的需求是明确的。而且又考虑到项目安全性能的首要要求，以V模型为基础的生存期最为合适。同时参杂增量模型生存期的一些特点以应对可能会随时添加的功能需求。项目生存期模型如下：该生存期模型将V模型除最后的项目规划和验收测试以外的过程做一复制，套用增量模型在首先完成基本功能的基础上增加功能。第三部分 需求管理3.1软件需求管理过程XX省委省政府提出需求如下：设计开发、安装调试并后期维护满足需求的“政府公文审批及工作通告”应用程序。需要该程序为桌面应用程序，进入程序后需要弹出办公界面，该办公界面需与计算机自身系统分离，不得覆盖，具有独立窗口。内部需有公文处理、邮箱、事务表、内嵌Office、新闻速览、视频会议室6个主要功能，每个功能需在办公界面中有独立的快捷方式。每个功能的具体要求如下：公文处理：1.正式公文的发布与接收2.正式公文的审批（包括联合审批和分级审批），电子盖章，电子签名3.公文草案的提交与修改意见的回复4.公文的内容备案，内容备案需祛除盖章和签名并打水印，只且可读可删除储存在该用户ID下的公文，不可写不可复制。每个备案可以备注相关信息和用户意见5.公文可以按已通过，已驳回，待审批，新公文，垃圾箱分类6.公文真伪检验，根据公文号唯一性等依据判断收到的公文真伪网内邮箱：1.实现网内按用户ID分配邮箱名，且可以并只可以在网内发送接收邮件2.新邮件弹框提示3.其他功能模仿雅虎邮箱事务表 ：1.新建、删除、修改、查看事务表2.事务到时提醒，提醒时间可自行设定。到设定的提醒时间系统自动向自己的邮箱发送邮件提示3.可以将事务表内容以桌面小工具的形式放在办公页面上显示内嵌Office：在办公界面下也可以被使用新闻速览：可以通过该功能浏览各大门户网站的头版头条或相关新闻。同时可以通过该功能阅览党报等主流报纸视频会议室：顾名思义，不付赘言。3.1.1 需求规格需求规格说明书（简略版）系统定义：“政府公文审批及工作通告”应用程序应用环境：Windows2000；Windows XP；Windows Vista；Windows 7；LINUX；IOS etc.功能规格：公文处理（发布，接收，分类，审批，电子盖章签名，提交草案，修改意见回复，水印图片公文备案，真伪检验）；邮箱（网内，新邮件弹窗提醒）；事务表（增删改查，事务提醒，桌面小工具）；内嵌Office；新闻速览（门户网站链接，电子报阅览）；视频会议室。性能需求：保证政府内部所有人员同时登录服务器时也不会因处理的信息量过大而导致系统瘫痪。另必须保证系统的安全性，可以禁得住一般的黑客袭击和内部作假。对账户有足够的保护措施以防账户被盗。操作简单明了，提示明显，容易上手，界面整洁大方。产品提交：略实现约束：公文处理、邮箱、事务表、内嵌Office、新闻速览、视频会议室质量描述：如需求所述的足够用户承载量；可靠的系统安全性；操作简单易学。界面整洁大方其他 ：略签字认证：甲方（需方）：XX省委省政府乙方（供方）：大连理工大学3.1.2 需求变更管理需求变更假设XX省委省政府向大连理工大学提出如下需求变更：在办公界面做一个可收缩的列表，显示当前系统在线的人员，方便政府内部人员联系。并且可以通过该列表直接与列表中任意用户进行邮件联系，不用再输入对方邮箱地址。软件基线产品修改提交单申请人：XXX申请日期：2012年9月6日项目名称：“政府公文审批及工作通告”应用程序阶段名称：文件名称：修改内容：增加功能“可收缩的在线人员显示列表”，可之间与表中用户进行邮件联系，不必输入对方邮箱地址验证意见：同意变更，邮箱功能随之变更验证人：YYY验证日期：2012年9月7日SCCB：SSS、CCC、BBB填表人：ZZZ第四部分 任务分解4.1任务清单4.1.1 功能分解清单1“政府公文审批及工作通告”应用程序1.1 公文处理1.1.1 公文的发布和接收，即实现网内广播和接收广播1.1.2 处理公文文件，包括电子盖章、签名和驳回批示1.1.3 公文备案处理和加标签备注1.1.4 公文真伪检验算法1.1.5 界面1.1.6 单元测试1.2 邮箱1.2.1 收发邮件功能及快速回复1.2.2 联系人功能1.2.3 添加附件1.2.4 新邮件弹窗提醒1.2.5 即时消息功能，范本：hotmail的msn1.2.6 界面1.2.7 单元测试1.3 事务表1.3.1 事务表的编辑功能1.3.2 事务表的提醒功能1.3.3 界面并做成桌面小工具1.3.4 单元测试1.4 内嵌Office1.4.1 内嵌Office1.4.2 单元测试1.5 新闻速览1.5.1 添加各大门户网站头版头条的链接1.5.2 党报、主流报纸、及本地报纸的电子阅览1.5.3 界面1.5.4 单元测试1.6 视频会议室1.6.1 多人视频功能1.6.2 界面1.6.3 单元测试1.7 办公界面1.7.1 界面1.7.2 后台数据传输4.2WBS政府公文审批及工作通告应用程序项目规划1. 合同签署1.1 需求分析报告 & 项目初步规划1.2 项目建议书1.3 合同草案2. 计划编制2.1 时间表3. 确认计划需求分析1. 需求开发1.1 需求探索2. 需求管理2.1 需求规格说明书3. 系统测试计划编制总体设计1. 策略确定2. 开发标准确定（具体分配方式见任务清单）3. 架构设计（具体分配方式见任务清单）4. 集成测试计划编制详细设计1. 接口设计（具体分配方式见任务清单）2. 模块设计（具体分配方式见任务清单）3. 单元测试计划编制实现1. 编码（具体分配方式见任务清单）2. 代码复核3. 单元测试测试1. 集成测试2. 系统测试3. 测试总额4. 缺陷跟踪5. 手册编写第五部分 规模估算5.1 直接成本 成本估算的方法有1.代码行、功能点、对象点 。2.类比 (自顶向下)估算法。3.自下而上估算法。4.参数法估算法。5.专家估算法。在这个项目中我们主要采取功能点估算法，同时融合进入其他的估算方法进行验证。用系统的功能数量来测量其规模，与实现产品所使用的语言和技术没有关系的。5.1.1基本公式FP =UFC*TCFUFC：未调整功能点计数TCF：技术复杂度因子TCF=0.65+0.01(sum(Fi)： Fi:0-5,TCF:0.65-1.355.1.2 复杂度权重因素项简单一般复杂外部输入346外部输出457外部查询346外部文件5710内部文件71015本项目的功能点计算：功能点项简单一般复杂外部输入5 * 33 * 45 * 6外部输出7 * 46 * 51* 7外部查询5 * 31 * 43 * 6外部文件4 * 52 * 74 * 10内部文件10 * 71 * 101 * 15总计14870110UFC148 + 70 + 110 = 328TCF-技术复杂度因子：技术复杂度因子F1可靠的备份和恢复F2数据通信F3分布式函数F4性能F5大量使用的配置F6联机数据输入F7操作简单性F8在线升级F9复杂界面F10 复杂数据处理F11重复使用性F12安装简易性F13多重站点F14易于修改TCF = 0.65 + 0.0.1 * ( 5 + 4 + 3+2 + 1 5+2 2 + 3 +5+4+3+3) = 0.65 + 0.01 * 45 = 1.1。 功能点计算：FP=UFC*TCF。UFC=328。TCF=1.1.FP=328*1.1 = 360.8人月数计算：在本项目中，根据以往的经验使用经验导出成本模型（面向FP驱动的 ）中的kemerer模型来计算人月数。Kemerer模型 E=60.627.72810-8 FP3 。带入本项目的实际数据 E = 60.62 * 7.728 *10-8 *360.83 = 220、03（人月）直接成本计算直接成本组成:开发成本,管理成本，质量成本。简易估算：开发（工作量）规模：Scale(Dev) 220.03(单位：人月) 管理、质量（工作量）规模： Scale(Mgn)=a* Scale(Dev) = 220.03 *20% = 44a :比例系数：例如：20%-25%直接成本=规模*人力成本参数 = 264.03 * 0.15 = 40万元人力成本参数=1500/人月（由于校内开发，成本比较低）5.2间接成本间接成本= 规模*人力成本参数*间接成本系数（间接成本系数=1.53）本例中间接成本 = 220.03 * 0.15 * 1.5 = 60万元。估算成本=直接成本+间接成本 = 40 + 60 = 100万元5.3 估算的误差由于基础数据不足，缺乏经验的估算人员，签约前后不连贯，低劣的推测技术，估算对需求的敏感性等一系列原因，可能会引起估算的误差。对此项目的人月数定义考虑误差如下估算：220个人月 +40 -25+15人月：需求变更-15人月：学生的晚上时间的利用+5人月：学生期末考试-10人月：实验室采取奖励措施+20人月：寒暑假最佳情况：195人月。计划情况：220人月。最坏情况：260人月。第六部分 项目进度项目进度管理是指在项目实施过程中，对各阶段的进展程度和项目最终完成的期限所进行的管理。是在规定的时间内，拟定出合理且经济的进度计划（包括多级管理的子计划），在执行该计划的过程中，经常要检查实际进度是否按计划要求进行，若出现偏差，便要及时找出原因，采取必要的补救措施或调整、修改原计划，直至项目完成。其目的是保证项目能在满足其时间约束条件的前提下实现其总体目标。 项目进度管理是根据工程项目的进度目标，编制经济合理的进度计划，并据以检查工程项目进度计划的执行情况，若发现实际执行情况与计划进度不一致，就及时分析原因，并采取必要的措施对原工程进度计划进行调整或修正的过程。工程项目进度管理的目的就是为了实现最优工期，多快好省地完成任务。 项目进度管理是项目管理的一个重要方面，它与项目投资管理、项目质量管理等同为项目管理的重要组成部分。它是保证项目如期完成或合理安排资源供应，节约工程成本的重要措施之一。6.1 活动定义政府公文审批及工作通告应用程序项目规划1.合同签署1.1需求分析报告 & 项目初步规划2.1项目建议书3.1合同草案2.计划编制2.1时间表3.确认计划需求分析1.需求开发1.1需求探索2.需求管理2.1需求规格说明书3.系统测试计划编制总体设计1.策略确定2.开发标准确定（具体分配方式见任务清单）3.架构设计（具体分配方式见任务清单）3.集成测试计划编制详细设计1.接口设计（具体分配方式见任务清单）2.模块设计（具体分配方式见任务清单）3.单元测试计划编制实现1.编码（具体分配方式见任务清单）2.代码复核3.单元测试测试1.集成测试2.系统测试3.测试总额4.缺陷跟踪5.手册编写6.2活动排序描述任务前导任务时间/月项目规划A无1需求分析B无2总体设计CA，B1详细设计DA，B2编码EC，D3测试FE3甘特图 P E R T图关键路径是决定项目完成的最短时间,关键路径上的任何任务都是关键任务,关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟.在这个项目中首先按照时间顺序计算最早开始时间和最早完成时间,然后按照逆时间顺序计算最晚开始时间和最晚结束时间。从而得出关键路径是：开始 需求分析- 详细设计 编码-测试。6.3 进度执行与优化在项目的进行过程中可以通过1、分解关键任务2、给任务增加资源3、缩减关键任务的工期 4、重叠或延迟链接任务 5、设置日历增加工作时间 6 、通过分配加班工时来缩短关键任务来达到缩减项目工期的目的。6.4工具使用在整个项目中将使用Microsoft的项目管理软件产品microsoft project 2 0 1 0来进行项目的管理第七部分 质量计划7.1软件项目的质量计划71.1 项目经理的职责1.评审质量计划。2.与质量保证人员一起协商不符合项问题的纠正措施，并安排资源实施纠正措施。3.定期或事件驱动地评审质量保证活动和结果。7.1.2质量保证人员的职责1.负责项目实施过程中对项目实施情况进行监督，包括对项目实施过程和工作产品进行监督检查。2.实施项目组成员的质量保证培训。3.制定质量保证计划。4按计划实施审计活动，依照质量保证计划执行评审/审计，并记录执行中发现的不符合项。5.对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况。6.对项目内不能解决的不符合项问超；向高层管理提交报告。7.向项目经理报告项目质量工作状况和质量度量结果。8.定期向项目组报告质量活动的结果。8.制定质量保证的过程改进计划，记录过程数据。7.1.3质量目标1）基于需求的测试覆盖率为100%。2）功能测试完善3）每个阶段评审中发现的问题都已经解决或得到适当处理。4）产品发布时不存在严重问题以及以上的缺陷。5）严格满足合同的要求和规格6）用户领导满意7.1.4质量策略1. 控制产品的质量，及时纠正缺陷2应该特别注意项目工作产品质量的早期评审工作，元论是质量保证还是质量控制，采取的策略都是早期预防和早期排除缺陷。3将质量贯彻到日常的项目进展过程中；7.2软件质量保证活动7.2.1审计审计(Audit) 是对过程或者产品的一次独立评估。将审核的主体与为该主体以前建立的一组规程和标准进行比较目的是确保真正的遵循了这一个过程，产生了合适的文档和精确反映实际项目的报告，可以预先规划的，也可以是临时决定的。现在讲本项目中的预先规划审计列出如下。在整个开发过程中，会根据需要插入临时决定的审计。1. 审计软件项目计划 时间：计划结束 标准：合同要求2. 需求规划文档 时间：需求制定 标准：需求规格说明3. 总体设计文档 时间：总体设计制定 标准：软件项目计划4. 详细设计文档 时间：详细设计制定 标准：软件项目计划5. 编码规范 时间：详细设计制定 标准：软件项目计划6. 产品代码 时间：编码结束 标准：编码规范7. 测试文档 时间：详细设计制定 标准：企业质量要求8. 用户手册 时间：产品提交之前 标准：项目计划和需求将审计的结果编写审计报告及时提交。以下是制定的质量审计模版软件质量保证审核报告产品类别：项目名称：审核阶段：审核范围：审核标准：审核员：参加人员：审核日期：持续时间：好的实践经验序号KPA内容发现的问题序号KPA内容严重程度上报的不一致问题序号KPA内容状态问题解决活动计划状态问题序号解决方案负责人预计完成日期注释：1. 审核阶段：项目计划审核阶段、需求审核阶段、设计审核阶段、编码审核阶段、测试审核阶段、产品发布审核阶段2. 审核范围：CMM KPA名称3. 审核标准：所用的审核检查表4. 严重程度：严重（指与项目计划中定义的过程不符合） 轻微（指活动遵循了过程，但有质量问题）7.2.2 过程评审项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围内。在每次评审之后，要对评审结果做出明确的决策并形成评审记录。评审可采取文件传阅、评审会等形式。质量保证人员负责对项目过程迸行监督，将发现的问题和解决情况在每周的例会上通报，对没有解决的问题迸行讨论，对不能解决的问题提交高级管理者处理。每个周末，进行一次配置管理审核，确认配置管理工作是否正常进行7.2.3问题报告质量保证人员对于每次审计活动发现的不符合项，应该和项目经理协商不符合项的纠正措施并预定完成日期，若和项目经理存在意见分歧，质量保证人员可以上报给高层管理者，由高层管理者决定最后的措施。同时，不符合项在项目周例会中汇报。对不符含项，质量保证人员耍在预定完成日期内重新审计，验证不符合项的纠正情况，若超过预定完成日期1周仍然有没解决的不符合项，质量保证人员上报给高级管理者，由高级管理者决定最后的措施。质量保证人员有独立的汇报途径，日常的汇报途径如下：1.将发现的问题通知项目经理，协调纠正措施。2.将项目组内不能协调的问题汇报给茼级管理者，由南级管理者协调解决。3.将日常工作和过程数据汇报给质量经理，由其统一收集并进行统计。7.3测试计划 下面是本项目的测试大概计划，详细内容请查阅测试文档。1. 基本测试单元测试集成测试系统测试测试工作安排测试准备工作测试用例设计2.系统测试设计版本兼容性测试性能测试恢复测试安全性测试压力测试7.4质量改善为了达到更好的质量，现在制定质量改善要求：1软件质量活动必须经过规划2.软件质量活动规划必须明文规定3.质量活动必须尽早开始4.质量小组必须独立存在5.应该经过训练6.必须有适当的经费第八部分 配置计划本计划描述了关于“政府公文审批及工作通知”项目的软件配置管理组织结构以及贯穿本项目软件生命周期的由软件配置管理组织识别并定义的一系列的软件配置项的实践过程。计划软件配置管理工作必须在项目最开始时进行，和开发整个软件项目计划保持一致。软件配置管理计划，连同软件质量保证计划）和其他可能的特定约束计划都要符合本项目的软件项目计划。软件配置管理计划完成之后应该由本项目的项目经理、SQA经理和其他有关人员进行审阅和批准。8.1 配置管理过程1. 配置项标识、跟踪2. 配置管理环境建立3. 基线变更管理4. 基线审核5. 配置状态统计6. 配置管理计划8.2 配置管理的人员组成 角色人员职责、工作范围配置管理者王颖（1）制定配置管理计划（2）创建和维护配置库SCC负责人胡博（1）审批配置管理计划（2）审批重大的变更SCCB成员项目经理丁峰配置管理者赵海洋审批某些配置项或基线的变更8.3软件配置管理活动8.3.1配置项标识命名规范适用于过程文档、生存期中各阶段的计划、需求、设计、代码、测试、手册等文件。本项目文件命名规范由五个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如下图所示。这些字段用横线（-）分隔。公司：3个字符项目：最长10个字符类型：最长5个字符编号： 最长8位数字版本号： V m.n例如QTD-SchoolRMSRS-v1.08.3.2项目基线项目基线一览表编号基线名称说明创建时机创建/变更审批者发布I:内部O:外部1客户需求基线系统归于软件的客户需求，以及为满足客户需求，软件在实现上所应具备的处理功能需求获得批准配置控制委员会IO2设计基线对程序总体框架结构及各模块实现细节的设计详细设计获得批准【项目经理和项目组领导】I3代码基线程序开发所获得的代码完成原始软件单元编码、并通过检查和单元测试【项目经理和项目组领导】I4测试基线为测试而发布软件【项目经理】I5运行基线为运行而发布系统配置控制委员会IO8.3.3配置库序号内容说明路径1TCM技术合同管理$ prj School TCM2RM需求管理$ prj School RM3SPP软件项目规划$ prj - School SPP4SPTO软件项目跟踪与管理$ prj - School SPTO5SCM软件配置管理$ prj - School SCM6SQA软件质量保证$ prj - School SQA7SPE软件产品工程设计$ prj - School SPE DESIGN8源代码$ prj - School SPE SOURCECODE9目标代码$ prj - School SPE BUILD10测试$ prj - School SPE TEST11发布$ prj - School SP