软件项目管理作业-数字化校园学工信息系统

软件项目管理作业-数字化校园学工信息系统内容摘要：

能按时、按预算完成 6 8 5 240 重新定义 事先与客户达成共识 设计 缺乏有经验的分析员 分析错误或不可行 4 10 5 200 培训或换人 配备有经验的分析员 设计偏离客户需求 软件不能满足需求，客户拒绝接受 4 8 5 160 修改设计 进行设计评审 软件功能漏项 客户不满意 5 10 5 250 增加相应的功能 进行设计评审、获得客户确认 编码 程序员对系统设计的理解上出现偏差 软件实现不了设计的功能，客户拒绝接受 6 9 5 270 修改代码 进行设计评审 程序员开发能力差 项目进度拖期、质量问题 3 9 4 108 培训或换人 配备精兵强将 程序员不熟悉开发工具 项目进度拖期 4 8 5 160 培训或换人 事先提供培训 开发环境没准备 好 项目进度拖期、质量问题 3 8 4 96 立即改进 提前准备 设计错误导致编码实现困难 质量问题 4 10 5 200 修改设计 编码之前进行设计评审 客户要求增加功能 项目进度拖期、成本超支 8 7 5 280 修改程序 事先确定项目范围 11 项目交付时间提前 质量问题 4 8 5 160 加班加点或增加资源 合同固定交付时间 程序员离开 项目执行不下去 5 10 4 200 临时替补人 与相关人员签订合同 开发团队内部沟通不够 接口混乱、质量问题 5 8 4 160 修改程序 制定内 部沟通计划 测试 没有切实可行的测试计划 项目拖期质量问题发现不了 2 9 5 90 修改测试计划 实现评审测试计划 测试人员不能按时到位 项目进度拖期 2 7 3 42 临时安排测试人员 制定出人力资源计划 测试人员经验不足 程序问题发现不了 4 6 3 72 培训或换人 选择有经验的测试人员 测试设备故障 项目拖期 3 8 4 96 修理或换设备 加强设备预防性维护 测试期间出现重大问题 客户拒绝产品 4 10 5 200 修改程序 分布测试 没有有效的备份方案 数据丢失无法挽救 4 9 4 106 重新开始 异地双重备份 测试发现的问题迟迟解决不了 项目进度拖期 3 9 5 135 加快解决 专家会诊解决 安装 设备不能按时到位 项目进度拖期 3 8 4 92 催设备供应商 提前采购或合同约束 运行时质量问题多 客户投诉 6 8 4 172 立即时解决问题 事先进行局部运行 12 客户突然要求增加功能 项目进度拖期、成本超支 7 8 5 280 做出相应修改 事先确定项目范围和功能要求 重要的记录、文件、数据丢失 客户投诉、要求赔偿 3 9 5 135 重新生成数据 做 好备份 系统崩溃 客户要求承担损失 2 10 3 60 加紧修复 事先备份 维护 出现故障，用户维护人员解决不了 客户投诉 8 8 8 512 派技术人员帮助解决 事先培训客户系统维护人员 用户手册错误多 客户投诉 3 6 4 72 修改错误 专人检查 培训手册没有按时准备好 客户投诉，培训不能按时进行 3 5 3 45 加班加点准备 提前准备出来 培训效果差 客户不满意 3 6 3 54 重新培训 确定标准、充分准备、把好培训师质量关 总体进度计划 WBS 法分解任务 13 14 项目活动时间表 甘特图 15 关键路径图（ CPM 图） 1. 系统设计 2. 系统实施 3. 软件测试 16 工期估算 任务名称 工期 乐观工期 预期工期 悲观工期 方差 标准差 0 软件项目计划制定 3 2 3 5 1 需求分析 4 12 19 26 需求捕获 4 3 5 7 抽象业务流程图 2 1 2 3 建立用例模型 2 1 2 3 编写需求规格说明书 2 1 2 3 需求规格测试 3 2 3 4 需求规格确认 1 1 1 1 2 系统设计 9 12 18 25 软件系统架构设计 5 3 5 7 数据库设计 5 3 5 7 系统详细模块功能设计 5 3 5 7 17 软件设计测试 3 2 3 4 软件设计确认 2 1 1 2 3 系统实施 28 18 26 38 数据持久层实现 3 2 2 4 系统框架搭建 2 1 1 3 系统表现层实现 8 5 7 10 系统服务器端应用实现 15 10 14 20 系统集成 10 6 10 14 4 软件测试 21 13 20 28 集成测试 5 3 5 7 功能测试 5 3 5 7 系统测试 6 4 5 7 验收测试 5 3 5 7 5 系统验收 3 1 2 4 软件交付 3 1 2 4 项目控制计划 质量保证计划 一． 目的 本计划的目的在于对所开发的 数字化校园学工系统 规定各种必要的质量保证措施，以保证所交付的软件能够满足项目委托书或合同中规定的各项需求，能够满足本项目总体组制定的且经领导小组批准的该软件系统需求规格说明书中规定的各项具体需求。 软件开发人员在开发软件系统所属的各个子系统（其中包括为本项目研制或选 用的各种支持软件）时，都应该执行本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经总 18 体组批准。 二． 管理机构 在本软件系统整个开发期间，必须成立软件质量保 证小组负责质量保证工作。 软件质量保证小组属总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及各个子系统软件质量保证人员等方面的人员组成，由项目的软件工程小组代表任组长。 各子系统的软件质量保证人员在业务上受软件质量保证小组领导，在行政上受各子系统负责人领导。 软件质量保证小组和软件质量保证人员必须检查和督促本计划的实施。 各子系统的软件质量保证人员有权直接向软件质量保证小组报告子项目的软件质量状况。 各子系统的软件质量保证人员应该根据对子项目的具体要求，制订必要 的规程和规定，以确保完全遵守本计划的所有要求。 三．任务 软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。 因此，对新开发的或正在开发的各子系统，要按照本计划的各项规定进行各项评审工作。 软件质量保证小组要派成员参加所有的评审与检查活动。 评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。 在软件开发过程中，要进行如下几类评审与检查工作： ：在软件开发过程中，要定期地或阶段性地 对某一开发阶段或某几个开发阶段的阶段产品进行评审。 在软件及其所属各子系统的开发过程中，应该进行以下三次评审：第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。 阶段评审工作要组织专门的评审小组，原则上由项目总体小组成员或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、质量保证人员、软件开发单位和上级主管部门的代表，其他参加人员视评审内容而定。 每一次评审工作都应填写评审总结报告（ RSR）、评 审问题记录（ RPL）、评审成 员签字表（ RMT）与软件问题报告单（ SPR）等四张表格。 19 b. 日常检查：在软件的工程化生产过程中，各子系统应该填写项目进展报表，即软件进展报表表头、软件阶段进度表、软件阶段产品完成情况表、软件开发费用表等四张表格。 项目总体组杨以通过项目进展季报表发现有关软件质量的问题。 c. 软件验收：必须组织专门的验收小组对开发软件系统及其所属各个子系统进行验收。 验收内容应包括文档验收、程序验收。