项目计划书7733297630

[键入公司名称]学生管理系统开发项目计划书马骏骅2010/12/13目录目录 2项目背景1.1项目名称学生管理信息系统开发 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 1.2项目情况简介采用C/S和B/S相结合的方式，开发学生管理系统，辅助一个学院办公室的辅导员日常管理学生的工作，能满足辅导员的工作需求，提高他们的工作效率，更好的为学生服务。1.3技术支持SQLSever数据库，VisualStudio2008开发工具，ASP.NET动态网页技术项目总体目标2.1项目成果成功开发出适用于中国石油大学的学生管理系统2.2项目工期要求2011年5月1日前完成系统开发并投入使用2.3成本要求总成本共计12000元2.4质量要求满足用户需求的功能，包括：1）WYSIWYG（What-you-see-is-what-you-get所见即所得）功能：人性化界面，自动安装，多级撤消（UNDO）和纠错，菜单操作等。2）支持多用户同时访问：采用并发机制。3）标准的数据库功能，能对数据库进行方便管理：具有安全性，完整性，并发控制，数据恢复等。4）生成 报表 企业所得税申报表下载财务会计报表下载斯维尔报表下载外贸周报表下载关联申报表下载 ，提供报表摸板；提供打印功能：可用摸板（综合测评，贫困困难补助名单，学生名单，宿舍名单，……），标准打印功能5）文件传输功能：在系统涉及范围内能方便的传输文件6）学生管理：每一客户（辅导员）都管理一定数量（100~500人）的学生，客户能通过该系统管理每个学生的基本信息，如学号，姓名，……；管理学生学籍，如退学，休学，复学，转班，……；管理学生住宿情况，如寝室号，地址，电话……；管理班级情况，如班长，团支书开会，……7）教师管理:提供在校教师的基本信息，如职称，联系方式8）教学管理:提供课程表查询，如可知道在某天某时那些班没课……；方便学生查询成绩，包括网上查询。9）年度学生综合测评管理叙述：年度综合测评是学校一年一次的对学生的综合 评价 LEC评价法下载LEC评价法下载评价量规免费下载学院评价表文档下载学院评价表文档下载 。它分德育（30分），智育（60分），体育（10），奖惩分（正负10分），加起来为100+正负10。德育由自评——自己给自己评分（30%）+互评——班上同学给自己评分（30%）+辅导员评分——辅导员给自己评分（40%）；智育由学生一学年的学习课程成绩来算，算法为……；体育……；奖惩分由一学年内获奖的情况来确定。学校根据综合分可对学生进行排名和奖学金的发放，奖学金的评定有成绩的硬性规定，如三等奖要平均分70以上，最底分62以上。10）辅导员个人管理:针对辅导员的工作辅助管理他日常的事务。他能根据个人管理更好管理每个学生，更好的为学生服务。11）系统自我管理：系统有自我管理功能，如有错误自动记录，提示，修复；数据库的自动整理，备份；……项目团队组织3.1项目组织结构项目经理：项目计划的制订和跟踪，包括进度、资源和成本的管理，还要负责团队的建立和管理系统分析员：需求分析、系统分析（OOA）、业务建模架构设计师：系统设计（OOD）测试设计师：测试用例的开发、测试计划程序员：编码实现、单元测试、集成测试测试员：执行功能测试和压力测试文档工程师：用户手册、开发指南、产品发布说明3.2生命周期初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）    设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）    实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署）    收尾阶段：安装及维护（大部分部署）项目工作分解4.1工作分解及编码4.2项目里程碑计划1)了解用户需求,确定开发系统要达到的目标2)完成系统的总体设计3)通过单元和功能测试4)通过系统测试,打包投入使用项目进度计划5.1项目工序时间 序号 工作名称 工作时间(天) 紧后项目 搭接项目 搭界时间 1 产品需求 5 2 2 产品目标 5 3，4 3 规格说明书 10 6 4 初步进度计划 5 5 5 高层设计 10 6 6 最终进度计划 5 7 7 低层设计 10 8，9 8 编码 15 10 9 测试计划 5 10 10 单元测试 5 11 11 系统测试 10 — 5.2项目工序网络图5.3关键路径 序号 工作名称 工作时间(天) 最早开始时间 最晚开始时间 最早结束时间 最晚结束时间 1 产品需求 5 0 0 5 5 2 产品目标 5 5 5 10 10 3 规格说明书 10 10 12 20 22 4 初步进度计划 5 10 10 15 15 5 高层设计 10 15 15 25 25 6 最终进度计划 5 25 25 30 30 7 低层设计 10 30 30 40 40 8 编码 15 40 40 55 55 9 测试计划 5 40 45 50 55 10 单元测试 5 55 55 60 60 11 系统测试 10 60 60 70 70项目总工期为:71天5.4甘特图项目资源计划6.1人力资源计划 序号 工作名称 工作天数 人力资源 工作量估计(工时) 平均每天工作量 每天安排人数 1 产品需求 5 管理人员 120 24 3 2 产品目标 5 管理人员 120 24 3 3 规格说明书 10 工程师 200 40 5 4 初步进度计划 5 管理人员 80 16 2 5 高层设计 10 工程师 200 40 5 6 最终进度计划 5 管理人员 80 16 2 7 低层设计 10 工程师 800 80 10 8 编码 15 程序员 1200 80 10 9 测试计划 5 程序员 80 16 2 10 单元测试 5 程序员 200 40 5 11 系统测试 10 程序员 800 80 106.2设备计划 序号 工作名称 设备使用情况 原材料使用情况 1 产品需求 电脑、打印机、电话 电、纸张 2 产品目标 电脑、打印机 电、纸张 3 规格说明书 电脑、打印机 电、纸张 4 初步进度计划 电脑、打印机 电、纸张 5 高层设计 电脑 电 6 最终进度计划 电脑、打印机 电、纸张 7 低层设计 电脑 电 8 编码 电脑 电 9 测试计划 电脑、打印机 电、纸张 10 单元测试 电脑 电 11 系统测试 电脑 电项目采购计划 设备/原材料名称 数量 采购方式 采购（租赁）地点 采购（租赁）成本（元） 电脑 10台 购买 中关村 30000 打印机 2台 购买 中关村 500 纸张 若干 购买 超市 600 项目成本预算每项工作的费用都包括人力费用和固定费用（材料、设备）8.1单位人力费用管理人员：40元/小时工程师：60元/小时程序员：30元/小时8.2费用预算安排 序号 工作名称 固定费用（元） 总费用（元） 每周平均费用（元/周） 1 产品需求 800 5600 5600 2 产品目标 800 5600 5600 3 规格说明书 1000 13000 6500 4 初步进度计划 800 4000 4000 5 高层设计 1600 13600 6800 6 最终进度计划 800 4000 4000 7 低层设计 2000 14000 7000 8 编码 600 48600 16200 9 测试计划 600 3000 3000 10 单元测试 800 6800 6800 11 系统测试 1000 25000 125008.3项目累计成本预算表 周数 本周费用（元） 已累积费用（元） 至本周累计费用（元） 1 5600 0 5600 2 5600 5600 11200 3 10500 11200 21700 4 13300 21700 35000 5 10800 35000 45800 6 7000 45800 52800 7 7000 52800 59800 8 19200 59800 79000 9 16200 79000 95200 10 16200 95200 111400 11 6800 111400 118200 12 12500 118200 130700 13 12500 130700 143200项目风险计划软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。随着项目的进展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。9.1风险识别 风险源与风险事件:1)初始阶段可能的风险事件：    1、项目目标不清    2、项目范围不明确（范围太大太小都不可以）    3、用户参与少或和用户沟通少    4、对业务了解不够    5、对需求了解不够    6、没有进行可行性研究2) 设计阶段可能的风险事件    1、项目队伍缺乏经验，如缺乏有经验的系统分析员    2、没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求    3、仓促计划，可能带来进度方面的风险    4、漏项，由于设计人员的疏忽某个功能没有考虑进去3)实施阶段可能的风险事件    1、开发环境没有具备好    2、设计错误带来的实施困难    3、程序员开发能力差，或程序员对开发工具不熟    4、项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）    5、项目进度改变（要求提前完成任务等）    6、人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大    7、开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差    8、没有有效的备份 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载     9、没有切实可行的测试计划    10、测试人员经验不足 4）收尾阶段可能的风险事件    1、质量差    2、客户不满意    3、设备没有按时到货    4、资金不能回收风险识别的有效方法:建立风险项目检查表、因果分析图、采访各种项目干系人等。 软件项目的风险可以从以下几方面检查：     产品规模风险    业务影响风险检    与客户相关的风险    过程风险    技术风险    开发环境风险    与人员的模式和经验有关的风险9.2风险综合评价 风险因素 权重W 风险发生的可能性 W*c 很大（1.0） 比较大（0.8） 中等（0.6） 不大（0.4） 较小（0.2） 计划不完善 0.2 · 0.08 工期紧张 0.2 · 0.04 人员变动 0.1 · 0.04 目标不明确 0.1 · 0.02 开发环境不可靠 0.15 · 0.06 编程能力 0.15 · 0.09 测试能力 0.1 · 0.06 W*C=0.399.3风险应对措施PMBOK提到三种应对方法 1）避免    通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。比如：如何避免客户不满意？    客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：    1、业务建模阶段要让客户参与    2、需求阶段要多和客户沟通，了解客户真正的需求    3、目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止    4、要有双方认可的验收方案和验收标准    5、做好变更控制和配置管理  2）减轻    通过降低风险事件发生的概率或得失量来减轻对项目的影响。也可以采用风险转移的方法来减轻风险对项目带来的影响。项目预算中考虑应急储备金是另一种降低风险影响的方法。比如：经过风险识别发现，项目组的程序员对所需开发技术不熟。可以采用熟悉的技术来减轻项目在成本或进度方面的影响。也可以事先进行培训来减轻对项目的影响。   3）接受    接收风险造成的后果。比如：为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。开发应对计划:针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。比如:在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：     1、进行调研，确定流动原因    2、在项目开始前，把缓解这些流动原因的工作列入风险管理计划    3、项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行    4、制定文档标准，并建立一种机制，保证文档及时产生    5、对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作    6、对每个关键性技术人员培养后备人员    在考虑风险成本之后，决定是否采用上述策略。项目质量管理10.1文档管理1）内部文档包括：项目开发计划;需求分析;体系结构设计说明;详细设计说明;构件索引;构件成分说明;构件接口及调用说明;组件索引;组件接口及调用说明;类索引;类属性及方法说明;测试 报告 软件系统测试报告下载sgs报告如何下载关于路面塌陷情况报告535n,sgs报告怎么下载竣工报告下载 ;测试统计报告;质量监督报告;源代码;文档分类版本索引;软件安装打包文件。2）外部文档主要包括：软件安装手册;软件操作手册;在线帮助;系统性能指标报告;系统操作索引。根据文档的不同，文档的来源也不同，文档的是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。特别是在系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。10.2系统维护质量保证系统交付后还需要后续的维护，一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。