项目管理案例(校务通)

项目管理案例(校务通) 校务通管理系统-项目管理案例 st=MeasurePlan.htm 合同 劳动合同范本免费下载装修合同范本免费下载租赁合同免费下载房屋买卖合同下载劳务合同范本下载 生存期模型 需求规格 任务分解 规模估算 进度计划 质量计划 度量计划 风险管理计划 团队沟通计划 集成计划 配置管理计划 项目跟踪控制 合同登记编号: 项目总结 技术开发合同 项目名称: 校务通管理系统 委托人(甲方): XXXXX省教育委员会 研究开发人(乙方): 北京科力拓技术发展有限公司 签订地点: 北京市 签订日期: 2003 年 4 月 10 日 有效期限: 2003 年 4 月 10 日 至 2003年 12 月 16 日 北京技术市场管理办公室 根据《中华人民共和国合同法》的规定，合同双方就 校务通管理软件系统开发 项目的技术开发(该项目属于 / 计划)，经协商一致，签定本合同。 一、标的技术的 根据甲方要求进行系统 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 设计，要求建立B/S结构的,基于的Sql server数据库、NT服务器和J2EE技术的三层架构体系的综合服务软件系统。 2. 配合甲方，在与整体系统相融合的基础上，建立系统运行的软硬件环 境。 3. 具体需求见SOW 二、应达到的技术指标和参数 1、 系统应满足并行登陆,并行查询的速度要求。其中主要 系统的主要功能是应满足双方认可的需求规格,不可以随意改动。 三、研究开发计划 1、 第一阶段:乙方在合同签订后7个工作日 第二阶段:完成第一阶段的系统 设计方案 关于薪酬设计方案通用技术作品设计方案停车场设计方案多媒体教室设计方案农贸市场设计方案 之后，乙方于50个工作 日 第三阶段:完成第一和第二阶段的任务之后，由甲方配合乙方于 3个工作日内完成系统在XXX信息中心的调试、集成。 四、研究开发经费、报酬及其支付或结算方式 1、 研究开发经费是指完成本项目研究开发工作所需的成本。报酬指 本项目开发成果的使用费和研究开发人员的科研补贴。 2、 本项目研究开发经费和报酬(人民币大写):XXX万元整。 3、 支付方式:分期支付。 本合同签订之日起生效，甲方在五个工作日日在 北京 履行。 本合同的履行方式: 甲方责任 1、 甲方全力协助乙方完成合同 合同期 乙方按甲方要求完成合同 乙方愿提供在实现功能的前提下，进一步予以完善。 3、 乙方在合同商定的时间 乙方在项目验收后提供一年免费维护。 5、 未经甲方同意，乙方不得向第三方提供本系统中涉及专业的技术 内容和所有的系统数据。 七、技术情报和资料的保密。 本合同中的相关专业技术 专利申请权:/。 2. 技术秘密的使用权、转让权:/。 十、验收的 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 和方式: 研究开发所完成的技术成果，达到了本合同第二条所列技术指标，按国家标准，采用一定的方式验收，由甲方出具技术项目验收证明。 十一、风险的承担 在履行本合同的过程中，确因在现有水平和条件下难以克服的技术困难，导致研究开发部分或全部失败所造成的损失，风险责任由甲方承担50 %，乙方承担 50 %。 本项目风险责任确认的方式:双方协商。 十二、违约金和损失赔偿额的计算: 除不可抗力因素外(指发生战争、地震、洪水、飓风或其它人力不能控制的不可抗力事件)，甲乙双方须遵守合同承诺，否则视为违约并承担违约责任: 1、 如果乙方不能按期完成软件开发工作并交给甲方使用，乙方应向 甲方支付延期违约金。每延迟一周，乙方向甲方支付合同总额 0.5,的违约金，不满一周按一周计算，但违约金总额不得超过 合同总额的5%; 如果甲方不能按期向甲方支付合同款项，甲方应向乙方支付延期 2、 违约金。每延迟一周，甲方向乙方支付合同总额0.5,的违约金， 不满一周按一周计算，但违约金总额不得超过合同总额的5%。 十三、解决合同纠纷的方式: 在履行本合同的过程中发生争议，双方当事人和解或调解不成，可采取仲裁或按司法程序解决。 1( 双方同意由北京市仲裁委员会仲裁。 2( 双方约定向 北京市 人民法院起诉。 十四、名词和术语解释 如有，见合同附件。 十五、其他 1、 本合同一式6份，具有同等法律效力。其中正式两份，甲乙双方各执一份;副 本4份，交由乙方。 2、 本合同未尽事宜，经双方协商一致，可在合同中增加补充条款，补充条款是合 同的组成部分。 案例说明-《校务通管理系统》的规模成本估算 估算是循序渐进的过程，随着项目的不断发展，估算可以重复多次进行的，而且是逐步精确的。本项目采用自下而上和参数法综合的估算方法，具体过程如下: (一)、签订合同前 开始签订合同的时候，根据以往类似项目的经验，采用类比估算方法，进行粗略的估算:根据用户的要求采用B/S结构，公司JSP+SQL Server的技术比较成熟，以前成功完成过类似的项目，根据SOW的说明，基本上需要2-3个开发人员，2个月左右的开发时间，基本上是4-6人月的规模，所以，10-15万可以作为合同的参考价格。 (二)、合同签署后 合同签署之后，根据现有的资源和WBS分解的结果，进一步细化估算，由于WBS分解是针对项目的功能进行的分解，在成本估算的时候，首先估算每个任务的开发规模，然后在通过系数获得相应的质量、管理任务的规模，从而计算直接成本，然后计算间接成本，以及总成本，具体过程如下。 资源 人力资源 个开发人员 个项目管理人员 1个项目质量人员 个配置管理人员 设备资源(作为间接成本计算) 台电脑 台服务器 项目规模估算表 注:规模单位为人/天 估算步骤如下: 1. 获取项目分解结果WBS a) 任务分解是根据项目的功能进行分解的, 2. 计算开发成本 a) 由于任务分解的结果主要是针对开发任务的分解，管理任务和质量任务 可以通过计算开发任务得到，根据以往经验，管理任务和质量任务=20%*开发任务。 b) 从表6-3得知项目规模是103人天，开发人员成本参数=480元/天，则 加上外包外购的部分软件成本5000+3000+3000=11000元，则开发成 =49440+11000=60440元。 3. 计算管理、质量成本 a) 项目的管理和质量成本=开发成本*20%=12088元， 4. 直接成本=60440+12088=72528元， 5. 计算间接成本 a) 间接成本包括前期合同费用、房祖水电、培训、员工福利、客户服务等， b) 根据以往经验，采用公式:间接成本=25%直接成本=18132元， 6. 计算总估算成本 a) 项目总估算成本=72528+18132=90660元。 7. 重新评估项目的报价 a) 重新评估一下项目的报价准确性，当然这时候，项目的合同已经签署了， 报价是不能更改的，但是通过再次的评估可以进一步明确企业的项目运作和利润情况等， b) 如果项目的利润是30%，其中风险基金10%，利润15%，税费5%。则项 ,,应该说报价还是比较合适的。 目的总报价=90660*1.3=117858元 另外，可以采用简便的算法进行估算，企业的报价可以通过开发规模的估算直接得出，例如如果成本系数为2.5万元/人月，一个人月22人天，则项目报价=2.5*103/22=117045元。 (三)、成本预算 在下章的进度计划编制完成时，会根据各项任务的情况，安排各项任务的预算成本，最后可以得到比较详细的成本分配情况。见进度计划案例。 (四)成本的跟踪控制 在项目跟踪控制的每个阶段，会根据项目的具体情况重新估算，预测项目完成后的成本，详见 “项目跟踪控制”成本跟踪 案例说明-《校务通管理系统》质量计划 1.导言 略 2.项目组织 2.1组织机构 在项目实施期间成立项目质量保证组织，该组织由质量保证人员和项目经理组成，项目经理负责质量监督工作及项目进展过程中各环节的质量把关，开发经理负责质量控制的工作，质量保证人员负责质量保证的工作。组织结构图1如下: 用户 图1:项目的组织结构 2.2职责 在本项目中，质量保证组织的职责如下: 2.2.1 高层管理 高层管理是公司负责质量的高级管理，其质量职责如下: 受理项目 负责听取质量保证组的工作报告，评审质量保证活动和结果; 参加有关质量保证过程改进的评审。 2.2.2 项目的质量保证人员 质量保证人员的质量职责如下: 负责项目实施过程中对项目实施情况进行监督，包括对项目实施 过程和工作产品进行 监督检查; 实施项目组成员的质量保证培训; 制定质量保证计划; 按计划实施审计活动,依照质量保证计划执行评审/审计，并记录执行中发现的不符合项 对不符合问题提交不符合项报告，跟踪并验证纠正措施的执行情况 对项目 向项目经理报告项目质量工作状况和质量度量结果 定期向项目组报告质量活动的结果 制订质量保证的过程改进计划，记录过程数据 2..2..3项目经理 项目经理的质量职责如下: 评审质量计划; 与质量保证人员一起协商不符合项问题的纠正措施，并安排资源 定期或事件驱动的评审质量保证活动和结果 实施纠正措施; 3.质量目标 根据企业的质量方针和质量目标，结合本项目特点,制定项目的总体质量目标: 1) 基于需求的测试覆盖率为100%; 2) 软件功能测试用例通过率不低于95,; 3) 每个阶段评审中发现的问题都已经解决或得到适当处理。 4) 产品发布时不存在严重及其以上的缺陷。 注:严重问题指导致系统或模块不能正常工作的问题。 结合以往的项目经验和企业的质量相应标准，制定质量标准如下表 表1:质量计划标准 4.质量策略 为了保证提交用户的产品是高质量, 实施过程中采取的质量保证措施包括:1)将质量贯彻到日常的项目进展过程中，2)应该特别注意项目工作产品质量的早期评审工作，无论是质量保证还是质量控制采取的策略都是早期预防和早期排除缺陷。 5.质量保证活动 质量保证的主要活动包括过程评审和产品审计。过程评审和产品审计的目的是为了确保在项目进展过程的各个阶段和各个方面采取各项措施来保证和提高提交给用户的产品质量。每一次过程评审和产品审计都应填写相应的报告或活动记录。 5.1.产品审计 产品审计由质量保证人员来进行，检查项目产品是否达到质量目标。 质量保证人员对项目生存期中创建的工作产品可以有选择性的进行审计，以验证是否符合适当的标准，是否进行了质量检查。表2便是质量审计一览表 表2:审计产品一览表 5.2 过程评审 项目严格按照组织定义的软件过程进行开发，过程评审的具体依据参照企业的过程规范，保证项目中的所有过程活动都在实施范围 项目规划过程及产品标准 2) 项目跟踪管理过程 3) 需求分析过程及产品标准 4) 系统设计过程及产品标准 5) 详细设计过程及产品标准 6) 调试运行过程及产品标准 7) 代码走查过程及代码编写标准 8) 产品集成测试过程及产品标准 9) 开发环境中的执行规则 10) 测试环境中的执行规则 11) 质量保证过程及其标准 12) 配置管理过程及其标准 具体过程执行标准详见企业质量体系和项目计划的过程附件. 6.质量控制活动 质量控制活动包括代码走查、单元测试、集成测试、环境测试等，由开发人负责，详见进度计划。编码人员在编写代码时要进行同步单元测试，单元测试要达到分支覆盖，产品通过单元测试和编码检查后，应提交测试部进行集成测试、系统测试。测试部的测试应达到质量目标要求，软件发布时应达到测试通过准则的要求. 7.质量保证的报告途径 质量保证人员对每次审计活动发现的不符合项，应该和项目经理协商不符合项的纠正措施，及预定完成日期，若和项目经理存在意见分歧，质量保证人员可以 上报给高层管理者，高层管理者决定最后的措施。同时不符合项在项目周例会中汇报。 对不符合项，质量保证人员要在预定完成日期 发现的问题通知项目经理，协调纠正措施。 将项目组 的日常工作和过程数据要汇报给质量经理统一 收集、统计。 8.记录的收集、维护和保存 项目组应当保留项目执行过程中形成的各类文档、各种记录、各级周报、各级会议记录、对于项目中问题的处理也需要形成记录保存。每周由质量保证人员根据任务清单的审计任务进行审计活动，并收集各活动的过程数据。 案例说明-《校务通管理系统》风险管理计划 本项目的主要风险是开发人员对客户需求中的学校管理环境不是很熟悉，另外，客户要求的进度比较紧，而且具体需求不是很明确，下面的这个风险列表就是通过一系列的风险识别、风险评估、风险应对，最后得出项目TOP 10风险列表。 风险分析表 案例说明-《校务通管理系统》的项目集成计划 1(导言 略 2(概述 《校务通管理系统》是对学校教务和教学活动进行综合管理的平台系统，是基于Internet环境的综合信息系统，满足学校管理层、教师、学生、家长等日常工作、学习、管理、咨询等工作。目的是共享学校各种资源、提高学校的工作效率、规范学校的 工作流程 财务工作流程表财务工作流程怎么写财务工作流程图财务工作流程及制度公司财务工作流程 、便利校内外的交流。系统具有标准化、分布式存储和检索、易用、易维护、开放等特点。 3 项目任务范围 《校务通管理系统》项目需完成的任务总的分为两类:通用功能和学校日常业务管理功能。其中通用功能包括电子课表、会议通知和公告、日程安排、个人日记、通讯录、教师答疑、家庭作业等。学校日常业务管理功能包括招生管理、学生日常管理、教务管理、、教师备课系统、资源库系统、网上考试功能、聊天室、论坛等。图1是项目任务的范围图示。 图1:任务范围 4 项目目标 目前电化教育已经越来越普及，各地的学校纷纷建设自己的校园网，但是好多学校在投巨资建设校园网之后，未能高效利用校园网的资源。《校务通管理系统》提供了有效利用校园网，实现学校管理的电子化。本项目的产品可以达到以下目标。 • 提高生产效率，减少返工。 • 节省开支。 • 业务过程的流水线化。 • 先前人工劳动的自动化。 • 符合相关标准和规则。 • 与目前的应用产品相比较，提高了可用性或减少了失效程度。 另外，通过项目进一步验证和完善公司的质量体系,同时锻炼开发队伍的协同精神。 5 项目实施策略 实施策略是确定如何实施项目，以达到项目目标的策略。根据校务通项目特点和企业的战略要求，采取如下策略: 项目管理策略 1. 项目管理过程遵循公司质量体系中关于项目管理过程规范 2. 根据项目计划中的评审点进行跟踪和管理，并根据结果对项目计划进行适当的调 整 3. 评审采用定期评审、阶段评审和事件评审相结合的方式 4. 按周发布项目简报，通报项目进展情况及其他相关情况 软件开发策略 1. 采用OO技术逐步构造系统 2. 产品按阶段提交 3. 开发实施过程采用公司的复用技术，同时遵循公司质量体系中关于项目实施过程 规范 质量保证策略 1. 质量管理过程遵循公司质量体系中关于项目质量管理过程规范。 2. 加强对项目参与人员的质量保证概念的培训 3. 加强对过程的控制，重点确定该项目中需控制的过程 4. 加强对产品规范的审计，重点确定该项目中需审计的产品 5. 实施完整的软件配置管理 6 项目组织结构 由于该项目在实施过程中需要涉及不同组织的各方面人员，而各组织之间的利益、任务和职责也不尽相同，因此明确定义项目组织结构和各自职责可保证项目的顺利进行。该项目的组织结构图如图2: 其中: 市场部 - 负责与用户的协调工作 - 负责项目相关的商务活动 - 负责用户需求的接口 - 配合项目经理的资源协调活动 - 负责产品的验收活动 - 负责系统的维护活动 项目管理 - 负责项目的组织和规划 - 负责项目计划制定和维护 - 负责项目的跟踪和管理 - 负责资源的分配和协调活动 - 负责各组织和计划之间的协调活动 - 负责与市场部的协调活动 软件开发 - 负责项目的软件开发，包括设计，编码，单元测试和集成测试 - 负责产品质量控制的工作 - 负责配合质量保证的活动，如系统测试，文档编制等 - 配合产品验收的相关活动 质量保证 - 负责项目过程和产品规范的制定 - 负责项目过程的质量保证活动， - 过程评审 - 产品审计 配置管理 - 负责项目的配置管理活动 - 负责软件产品的提交 用户 - 确保相关责任的实施 - 参与项目的组织和规划 - 负责产品的验收工作 表1为角色映射表。 表1:角色映射表 7 项目生存期 根据该项目的特点并结合公司已有的软件生存期模型定义，本项目生存期采用增量模型如图3。 生存期中的各阶段定义如下: 项目规划阶段 阶段目标: 根据合同和初步的需求分析确定项目的规模、时间计划和资源需求。 输入: 合同文本 SOW 过程: 输出: 项目规划，计划确认 项目计划 需求分析阶段 阶段目标:确定客户的需求 输入: 过程: 输出: 设计阶段 阶段目标: 输入: 过程: 输出: 增量1实现 阶段目标: 输入: 过程: 输出: 增量2实现 阶段目标: 输入: 过程: 输出: 项目计划，SOW 需求获取，需求分析，需求控制 原型系统，需求规格 总体系统结构设计 原型系统，需求规格 总体设计 系统设计说明书，数据库结构定义 实现系统的通用功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,1 实现系统的招生管理功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,2 增量3实现 阶段目标: 实现系统的学生日常管理功能 输入: 过程: 输出: 增量4实现 阶段目标: 输入: 过程: 输出: 增量5实现 阶段目标: 输入: 过程: 输出: 增量6实现 阶段目标: 输入: 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,3 实现系统的教务管理功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,4 实现系统的教师辅助功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,5 实现系统的聊天室/论坛功能 系统设计说明书 数据库结构定义 过程: 输出: 详细设计,编码，代码走查，代码评审，单元测试 详细设计 说明书，源代码，可运行版本,6 集成测试 阶段目标: 通过集成环境下的软件测试 输入: 测试计划 测试案例 过程: 输出: 集成测试，系统测试 系统软件包,测试报告，产品说明书 产品提交 阶段目标: 产品可投入使用 输入: 过程: 输出: 系统软件包 产品提交 验收报告 8 时间计划 项目进度计划甘特图如图4所示(,详见进度计划.mpp,): 图4:进度计划 9 项目成本估算 项目估算是为了确定项目所需的人力、时间以及项目完成过程中耗费的人力、 物力、财力资源。图5是项目估算和预算的结果(详见估算计划.). :成本计划 10质量管理计划 图5 质量管理计划详见质量管理计划专题. 11 配置管理计划 配置管理计划详见配置管理计划专题. 12 项目风险计划 风险是指在项目进行过程中可能发生的事件，这些事件将会对项目按预期时间、资源和预算完成产生重大影响。风险分析的目标是识别这些事件，设法避免这些事件的发生并制定一旦这些事件发生后的处理措施。表2是本项目风险计划清单表。 表2:风险分析表 13.度量计划 详见度量计划专题 14 项目沟通与评审 项目评审的主要目的是根据项目计划对项目的执行活动进行检查，及时发现问题，研究解决对策，纠正偏差，保证项目的顺利实施。项目交流计划分为如下几类: - 每天17:00的沟通交流 - 定期评审 - 阶段评审 - 事件评审 各类交流评审安排见表3。 表3:项目管理交流计划 案例说明-《校务通管理系统》的生存期模型 针对本项目的开发特点，参考企业的生存期模型说明和软件过程体系，决定采用增量式模型如下图，理由如下: 1( 校务通系统的全部功能分成通用功能和日常业务管理功能两大类，因此 可以先基于通用功能作出一个最小的使用版本，再逐步添加其余的功能。这样一来，用户可以先试用最小版本的同时，提出更多明确的需求，这有助于下一阶段的开发，大大减小了开发的风险。 2( 在校务通系统需求规格中，要求系统有可扩充性。若使用增量模型，可 以保证系统的可扩充性。用户明确了需求的大部分，但也存在不很详尽的地方。如:“关于教师档案，比照所提供资料设计，现在也没有一个成形的东西”;资源库系统只提到“应提供一个标准的资源库解决方案。”这样只有等到一个可用的产品出来，通过客户使用，然后进行评估，评估结果作为下一个增量的开发计划，下一个增量发布一些新增的功能和特性。直至产生最终完善的产品。 3( “系统要求有可扩充性，可以在现有系统的基础上，通过前台就可加挂 其它功能模块”。也说明用户可能会增加新的需求。 4( 对一个管理方式已经比较成熟的学校，要完全舍弃原有的管理方式，用 校务通系统替代全部管理，这是不实际的。所以，可以从最基础的做起，逐步扩充其应用，所以选用增量模型来开发校务通系统。 5( 本项目具备增量式模型的其他特点 a) 项目复杂程度为中等。 b) 预计开发软件的成本为中等。 c) 产品和文档的再使用率会很高, d) 项目风险较低 生存期中的各阶段定义如下: 项目规划阶段 阶段目标: 根据合同和初步的需求分析确定项目的规模、时间计划和资源需 求。 输入: 合同文本 SOW 项目规划，计划确认 项目计划 过程: 输出: 需求分析阶段 阶段目标:确定客户的需求 输入: 过程: 输出: 设计阶段 阶段目标: 输入: 过程: 输出: 增量1实现 阶段目标: 输入: 过程: 输出: 增量2实现 阶段目标: 输入: 项目计划，SOW 需求获取，需求分析，需求控制 原型系统，需求规格 总体 系统结构设计 原型系统，需求规格 总体设计 系统设计说明书，数据库结构定 义 实现系统的通用功能 系统设计说明书 数据库结构定义 详细设计,编码，代 码走查，代码评审，单元测试详细设计说明书，源代码，可运行版本,1 实现系 统的招生管理功能 系统设计说明书 数据库结构定义 过程: 输出: 详细设计,编码，代码走查，代码评审，单元测试 详细设计 说明书，源代码，可运行版本,2 增量3实现 阶段目标: 实现系统的学生日常管理功能 输入: 过程: 输出: 增量4实现 阶段目标: 输入: 过程: 输出: 增量5实现 阶段目标: 输入: 过程: 输出: 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,3 实现系统的教务管理功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,4 实现系统的教师辅助功能 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,5 增量6实现 阶段目标: 实现系统的聊天室/论坛功能 输入: 系统设计说明书 数据库结构定义 详细设计,编码，代码走查，代码评审，单元测试 详细设计说明书，源代码，可运行版本,6 过程: 输出: 集成测试 阶段目标: 通过集成环境下的软件测试 输入: 测试计划 测试案例 过程: 输出: 集成测试，系统测试 系统软件包,测试报告，产品说明书 产品提交 阶段目标: 产品可投入使用 输入: 过程: 输出: 注:生存期模型中的过程定义可以参照企业的质量保证体系并结合项目的具体特点而决定，由于公司的流程已覆盖到了项目开发、管理的所有方面，包括从最开始的合同到最后软件的产品提交，都有相应的过程规定，基本上已形成一种工业化的软件开发，所以，为形成一个良好的软件开发环境奠定了基础。 系统软件包 产品提交 验收报告 例如系统设计过程及产品标准的定义如下: 参与角色 R1:项目经理 R2:开发经理 R3:设计人员 进入条件 E1:项目计划规定的系统设计时间到 输入 I1:需求规格 活动 A1:设计人员了解业务需求并仔细阅读需求规格 A2:设计人员收集了解同类项目的技术框架; A3:开发经理领导设计人员通过具体的业务分析和企业成熟的技术框架进行系统设计; A4:设计人员在进行系统设计时，应按照系统设计的标准模板进行，要求如下 完整，正确，如实地说明每个模块的流程和数据库表; 用中文进行描述，并用小四号字体 A5:开发经理负责监督设计人员设计文档的对等评审; A6:开发经理主持设计正式评审，同时要求项目经理和质量经理参加 A7:设计人员根据评审结果进行修订和补充，并形成最终系统设计文档。 A8:开发经理负责将系统设计过程中无法解决的问题以事件报告形式提交给项目经理，由项目管理 者进行跟踪解决; 输出 O1:系统设计文档(格式标准见企业质量体系) 完成标志 F1:系统设计评审通过，纳入配置库 案例说明-《校务通管理系统》度量计划 根据企业的质量策略和项目的特点制定本项目度量计划，主要目的是为本项目的控制提供实际数据，以及将来其它项目提供估算依据，表1给出项目规模的度量指标，表2是项目的时间度量指标，表3是需求变更度量指标。 一、规模度量 表1:项目规模的度量指标 :时间度量指标 二、时间度量 表2 三、需求变更度量统计表 表3:需求变更度量指标 案例说明-《校务通管理系统》团队组织和沟通计划 一、项目的组织结构如下图，它是矩阵型组织结构的一个具体化。 其中: 市场部 - 负责与用户的协调工作 - 负责项目相关的商务活动 - 负责用户需求的接口 - 配合项目经理的资源协调活动 - 负责产品的验收活动 - 负责系统的维护活动 项目管理 - 负责项目的组织和规划 - 负责项目计划制定和维护 - 负责项目的跟踪和管理 - 负责资源的分配和协调活动 - 负责各组织和计划之间的协调活动 - 负责与市场部的协调活动 软件开发 - 负责项目的软件开发，包括设计，编码，单元测试和集成测试 - 负责产品质量控制的工作 - 负责配合质量保证的活动，如系统测试，文档编制等 - 配合产品验收的相关活动 质量保证 - 负责项目过程和产品规范的制定 - 负责项目 产品审计 过程的质量保证活动， - 过程评审 - 配置管理 - 负责项目的配置管理活动 - 负责软件产品的提交 用户 - 确保相关责任的实施 - 参与项目的组织和规划 - 负责产品的验收工作 二、项目的沟通计划 为了保证项目开发过程的顺利进行和信息的有效沟通，特要求如下的沟通计划 1. 每天17:00—17:30项目组成员进行口头交流 2. 每周五的14:00前提交周报告，格式见模板 3. 每周五的15:00-17:00召开项目周例会，会后发布会议纪要给相关的项目人员， 其中说明项目的进展和存在的问题 4. 及时提交问题报告，问题可以通过网络提交，项目经理会及时获取问题信息 案例说明-《校务通管理系统》配置管理计划 1.引言 略 2. 组织及职责 (1)根据《项目计划》中的角色分配，确定配置管理者，SCCB(配置控制委员会)成员。 (2)项目经理是SCCB的负责人。 (3)配置管理的角色和职责见表1 表1:配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目,工期也不是很长,而且大家对SourceSafe也比较熟悉,所以采用SourceSafe做为配置管理工具。 3.1目录结构 表格 2:配置库的目录结构 3.2 用户及权限 表2:配置库的用户权限 4.配置管理活动 4.1 配置项标识 4.1.1 命名规范 命名规范适用于过程文档、生存期中各阶段的计划、需求、设计、代码、测试、手册等文件。 本项目文件命名规范由五个字段组成，从左到右依次为:公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线(-)分隔。 图1:文档命名规范 4.1.2主要配置项如下: 表3 配置项列表 4.1.3 项目基线 在SourceSafe中基线由LABEL标识，字母必须为大写。基线管理由项目执行负责人确认，SCCB授权，由配置管理员执行。 表4:基线发布计划: 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支，让它们分别对应4类工作空间。 主干分支 私有分支 小组分支 集成分支 上面定义的四类工作空间(分支)由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 对配置项的版本管理在不同分支而策略不同: 主干分支 系统缺省自动建立的物理分支——主干分支(/main)，BASELINE均以LABEL方式出现在主干分支上。 私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不予管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。 小组分支 如果出现小组共同开发该配置项，该分支可视为项目组变更管理 变更管理的流程是: 1) 由请求者提交变更请求，变更控制委员会召开复审会议对变 更请求进行复审，以确定该请求是否为有效请求。典型的变 更请求管理有需求变更管理、缺陷追踪等。 2) 配置管理者收到基线修改请求后,在配置库中生成与此配置 项相关的波及关系表 3) 配置管理者将基线波及关系表提交给SCCB,由SCCB确定是 否需要修改,如果需要修改, SCCB应根据波及关系表,确定需 要修改的具体文件,并在波及分析表中标识出来. 4) 配置管理者按照出库程序从配置库中取出需要修改的文件 5) 项目人员将修改后的文件提交给配置管理者 6) 配置管理者将修改后的配置项按入库程序放入配置库 7) 配置管理者按SCCB标识出的修改文件,由波及关系表生成 基线变更记录表,并按入库程序放入配置库 4.3 配置状态统计 利用配置状态统计可以记录和跟踪配置项的改变。状态统计可用于评估项目风 险，在开发过程中跟踪更改，并且提供统计数据以确保所有必须的更改被执行。 为跟踪工作产品基线，配置管理者需收集下列信息: 基线类型 工作产品名称 配置项名称,标识符 版本号 更改日期,时间 更改请求列表 需要更改的配置项 当前状态 当前状态发生日期 项目组每周提交配置项清单及其当前版本。 配置管理人员每半个月提交变更请求的状态统计。 案例分析-《校务通管理系统》的项目总结 1) 项目总体信息，包括项目总时间、总成本、总人力，总规模等信息。 项目总时间:2003/4/10-2003/6/11，共计45天，比计划多3天。 项目总成本: ,85,528.00 项目总人力:5人 项目总规模:157.80人天 规模比例见下图: 2) 项目评审记录 总评审次数:23 其中: 项目计划评审:1 设计评审:2 质量评审:2 定期评审:8 阶段评审:8 事件评审:2 3) 产品提交表 实际与计划的差异分析 4) 项目时间差异(天) 项目总规模差异表(人天) 项目成本差异表(元) 结论:1.从项目规模、成本差异表看，尽管略有差异，但基本控制在计划以项目管理的评估总结和建议 1( 基本遵循企业的质量体系实施项目管理过程。 2( 根据项目的具体情况，对企业的质量体系的执行活动进行了定制。 3( 由于大家对项目管理的认识不同，项目管理的磨合时间较长。 4( 建议:大家对项目管理过程应该有统一认识;力争有比较客观准确的项目计划 做基础，才可更好地实现项目跟踪管理。 5( 建议:项目计划前期应增加一个过程:项目计划的规划过程，对项目计划过程 做一个时间规划和任务规划。 6( 建议:项目计划期间，管理，开发，质量保证三方应相互明确各自任务的质量保证的评估总结和建议 1( 质量保证在项目中，基本按计划进行;达到了预期的效果，尤其对关键的质量 控制。 2( 系统测试阶段质量保证人员的参与，对产品的验错起到很好的作用。 3( 建议:以后的功能测试应增加质量保证人员。 7) 开发技术的评估总结和建议 1( 开发人员具有一定的敬业精神和实施能力 2( 开发人员对项目计划的时间概念不强 3( 建议:增强项目计划的时间观念。