软件项目管理课程设计数字化校园学工信息系统.docx
《软件项目管理课程设计数字化校园学工信息系统.docx》由会员分享，可在线阅读，更多相关《软件项目管理课程设计数字化校园学工信息系统.docx（37页珍藏版）》请在冰点文库上搜索。
软件项目管理课程设计数字化校园学工信息系统
数字化校园学工信息系统
小组成员
分工明细：
目录
一、引言3
1.1编写目的3
1.2背景3
1.3定义4
1.4参考资料4
二、项目概述4
2.1项目目标4
2.2产品目标与范围7
2.4假设与约束7
2.5应交付成果8
2.5.1需完成的软件8
2.5.2需提交用户的文档8
2.5.3应当提供的服务8
2.6项目开发环境8
2.7项目验收方式与依据9
三、实施计划9
3.1风险评估及对策9
3.2总体进度计划12
3.2.1WBS法分解任务12
3.2.2项目活动时间表14
3.2.3甘特图14
3.2.4关键路径图（CPM图）15
3.2.5工期估算16
3.3项目控制计划17
3.3.1质量保证计划17
3.3.2进度控制计划23
3.4配置管理计划27
3.4.1配置库目录结构27
3.4.2主要配置项27
四、预算28
五、总结29
一、引言
1.1编写目的
编写项目计划书，主要目的是使项目工作开展的各个过程合理有序，以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，以及项目团队开展和检查项目工作的依据。
1.2背景
项目建设背景：
随着信息技术的飞速发展和高等学校教育体制改革的不断深入使教育管理手段发生重大的变革,传统的以手工和纸张对学生信息及相关的管理工作已经远远不能适应新的发展需要尤其是随着计算机网络和Internet的普及,运用先进计算机技术对信息进行科学化和网络化管理已经成为高校信息管理的趋势。
对于高校的学生管理部门来说，学生管理工作面临着信息处理量越来越多、信息处理速度越来越高，管理人员的劳动强度越来越大的压力，倘若继续沿用传统的手工作业手段从事学生管理工作，势必不能适应教育改革的需要。
然而在学生管理工作中的现代管理手段主要体现在以计算机技术为核心，利用有效的网络化信息管理，使学生和教师之间，特别是学工队伍教师之间，进行数据共享。
就高校学生管理工作而言，管理对象的事务复杂且数据量大。
因此，利用计算机技术这个现代化管理手段来做好学生管理工作，是适应教育改革的需要，也是时代的要求。
项目预期的用户：
各大高校的学生，教师及管理人员；
1.3定义
甘特图：
是表示项目各阶段任务开始时间与结束时间的图形，从而反映出计划和进度的安排。
关键路径法：
是一种运用特定的、有顺序的网络逻辑和估算出的项目活动工期，确
定项目每项活动的最早与最晚开始和结束时间，并做出项目工期网络计划的方法。
网络图：
是活动排序的一个输出，它可展示项目中的各个活动之间的逻辑关系，表明项目任务将如何以什么顺序进行。
WBS分解：
以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
1.4参考资料
书名
作者
出版社
出版时间
软件项目管理
郭宁，周晓华
清华大学出版社、北京交通大学出版社
2009.8
二、项目概述
2.1项目目标
项目目标是要实现数字化校园学工信息系统的各个功能，实现校园文化综合整合的目的，展现数字化校园的优势。
项目目标总体可分为三个阶段：
一．需求分析阶段
需求分析阶段是所有阶段的基础和依据。
这个阶段是关系到整个项目的成败，在整体项目中占有举足轻重的地位。
这个阶段应完成的任务是：
（1）认真分析旧的学工管理信息系统，总结概括其优缺点，以及找出优势的原因和缺点的瓶颈；
（2）做好各项调研工作，对项目本身进行实际深入的了解和分析，从广大用户和网站开发人员手中积极获取第一手的资料和真实的需求，并做好最后的概括总结；
（3）对项目的可行性做出一定的分析；
（4）综合以上的内容和实际的情形，做出可行性研究报告和项目计划书，为整
体项目的进行把好方向以及奠定夯实的基础。
二．详细设计阶段
详细设计阶段是对项目要实现的功能进行整体的设计和初步的实现，为网站整体的运作做好坚实的基础，对网站的功能进行详细的分解和划分，为最好网站的实现做好准备。
本项目的主要实现功能如下：
1.个人基本信息管理
实现对个人信息的查询、更新操作。
个人信息包括学号、姓名、班级、籍贯、性别、民族、生日、政治面貌、联系方式、email、银行卡号、身份证、家庭详细地址、家庭情况、自我评价。
2.奖学金管理
支持学生成绩绩点、任职分值、荣誉分值、综合分值等计算、统计和分析，实现自动排名、审计奖学金，公示奖学金评审结果等功能。
3.就业信息管理
以“服务学生就业”理念为依托，构建一个针对性强，实时、方便的数据采集、分析和管理平台，逐步实现对学生就业信息的更好管理，提高信息化管理水平，为相关决策提供支持。
包括：
简历管理、应聘管理。
简历管理：
管理学生简历信息，简历信息包括姓名、籍贯、性别、民族、政治面貌、毕业院校、学历、专业、英语等级、联系方式、email、联系地址、求职意向、自我评价、实践经历、奖励情况。
应聘管理：
超级管理员管理各个企业的发布的应聘信息，企业管理员可对申请岗位的用户进行审核，应聘信息包括岗位编号、应聘企业、岗位名称、岗位类型、岗位详细信息、发布时间、状态。
4.党员综合管理
支持以支部为核心的党员管理方式，加强和改进党员的管理，有助于党员能够及时参加党的组织生活，接受党组织的教育、管理和监督,更好的发挥先锋模范作用。
未入党用户可提交入党申请书；已入党用户，可查看所在党支部信息和入党流程。
党支部信息包括支部名称，支部正式党员人数，预备党员人数，支部所属单位，支部简介。
5勤工岗位综合管理：
有岗位设定、学生申请、教师审批的功能。
提高了勤工岗位服务和管理的效率性和科学性。
学生需先登记个人信息，才能申请岗位，可查看可申请的岗位、岗位出勤情况，报酬情况和评价。
学院管理员可添加、删除岗位信息，
登记的个人信息包括学号、姓名、性别、联系方式、学院、专业，在校消费情况如月平均消费，勤工特长，家庭经济情况。
申请的岗位包括设岗单位、岗位名称岗位年份、报名结束时间、岗位所属部门、岗位所属单位。
岗位管理员需记录学生每次出勤情况，学生可查看自己岗位的出勤情况，出勤情况包括姓名、岗位名称、月份、迟到次数、缺岗次数、离岗次数。
报酬情况包含的信息有学生姓名、岗位名称、月份、发放时间、发放人。
6.困难生综合管理
从学生申请到教师审核，实现各项资助准确无误处理，有助于加强学校对困难生的服务和管理，简化困难资助申请的繁琐过程，给困难生提供更加简洁、方便的服务渠道。
学生提交的申请包括家庭情况、是否申请贷款、是否参与勤工、户口、奖学金情况、困难资助、家庭联系方式、家庭详细地址、申请理由。
教师审核需要给出认定结果，学生可查看自己的认定情况。
7.学业预警系统
对学习成绩较差学生学习状况的预警、跟踪和统计、报表的生成。
主要功能模块包括：
个人学习情况查看跟踪、个人成绩单导出、个人学业预警帮扶、整体学业情况预警。
8.成绩管理
记录每个学生每个学期的成绩，用户可查看自己不同学年、学期的成绩。
成绩信息包括年份、学期、课程名、学分、类型、成绩。
三．编码测试阶段
编码测试阶段是全面开发阶段，具体实现上个阶段的功能块，然后集成在一个系统中，完成网站的开发和实现；在网站发布前最后进行一次最全面的测试（当然测试是每个阶段所必须进行的一个过程。
2.2产品目标与范围
产品目标：
1、支持学院各项学生工作的数字化，促进学生工作线的协同办公，提高学生管理工作效率；
2、各类学生信息有效整合，实现数据共享和一致；
3、体现服务意识，整合并规范学生管理业务，为学生、教师、学生管理人员提供人性化的服务；
4、提供完善的查询统计、图表制作功能，能够直观的找到需要的信息和数据；
5、充分发挥计算机网络化管理的优势，有效提高工作效率。
数字化学工管理系统从学生工作的实际需求出发,基于优秀的技术框架构建为校园学生工作提供优质的信息化管理方法。
系统共有管理员、学生用户、班级用户三大角色。
产品范围：
各大高校及企业，主要用户是高校学生，教师，管理人员以及企业管理人员
2.4假设与约束
假设：
为了保证项目的正常顺利的进行，对项目的整体实施进行一次细致的分析，做出各种各样的假设。
具体如下：
假设1：
需求捕获时间过长，导致项目整体拖期，要求需求分析员第一时间到位，加班加点按时完成工作；
假设2：
设计开发人员进度缓慢，消极怠工，导致项目拖期，要求员工正视各阶段工作，力求保质保量；
假设3：
项目进行中途资金短缺，导致项目拖期，要求项目经理做好预算工作，备好意外紧急资金；
假设4：
项目进行中设备出现问题甚至崩溃，导致项目拖期，要求设备维护人员做好例行维护工作，维修人员能高效解决问题，让设备尽快恢复正常运行；
2.5应交付成果
2.5.1需完成的软件
程序名称：
数字化校园学工信息系统
编程语言：
java
提交网站的所有源代码，数据库文件，可执行程序，配置文件，第三方模块，界面文件，界面原稿文件，声音文件，安装文件等。
2.5.2需提交用户的文档
1.需求规格说明书
2.各个功能模块的详细设计书
3.帮助手册
4.故障排查手册
2.5.3应当提供的服务
1.培训客户使用软件
2.安装软件
3.提供软件的后续维护与技术支持
2.6项目开发环境
软件环境：
windows7系统火狐4.0
开发工具：
tomcat5.0以上版本以及Myeclipse,Dreamweaver可视化软件
数据系统：
SQLServer2008
硬件：
处理器Pentium166MHz或更高推荐256MHz
内存至少64MB推荐256MB
硬盘空间至少250MB推荐500MB
监视器VGA或更高分辨率
定位设备Microsoft鼠标或兼容设备
2.7项目验收方式与依据
验收方式：
交付前验收，交付后验收，试运行验收，最终验收，第三方验收，专家参与验收；
依据：
需求规格说明书
三、实施计划
3.1风险评估及对策
风险识别
风险评估
风险应对措施
项目管理过程
潜在风险事件
风险发生后果
可能性
严重性
不可控制性
风险等级
应急措施
预防措施
需求分析
项目目标不明确
项目进度拖期或成本超支
6
8
5
240
修改项目目标
实现明确项目目标
没有进行可行性分析
项目失败或执行不下去
5
10
5
250
取消项目或修改目标
进行认真分析和研究
需求分析报告没有得到客户的确认
客户拒绝签字、验收
5
10
4
200
按照客户要求修改
事先获得客户确认
需求不断变化
项目变得没完没了
8
9
5
360
提交CCB讨论、决定
建立范围变更程序
缺乏有效的需求变化管理过程
项目不能按时、按预算完成
5
8
5
160
对需求变化进行评审
建立需求变更程序
任务定义不够充分
项目不能按时、按预算完成
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
修改程序
事先确定项目范围
项目交付时间提前
质量问题
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
立即时解决问题
事先进行局部运行
客户突然要求增加功能
项目进度拖期、成本超支
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
重新培训
确定标准、充分准备、把好培训师质量关
3.2总体进度计划
3.2.1WBS法分解任务
3.2.2项目活动时间表
3.2.3甘特图
3.2.4关键路径图（CPM图）
1.需求分析
1.系统设计
2.系统实施
3.软件测试
5.系统验收
3.2.5工期估算
任务名称
工期
乐观工期
预期工期
悲观工期
方差
标准差
0软件项目计划制定
3
2
3
5
0.25
0.50
1需求分析
4
12
19
26
5.44
2.33
1.1需求捕获
4
3
5
7
0.44
0.67
1.2抽象业务流程图
2
1
2
3
0.11
0.33
1.3建立用例模型
2
1
2
3
0.11
0.33
1.4编写需求规格说明书
2
1
2
3
0.11
0.33
1.3需求规格测试
3
2
3
4
0.11
0.33
1.4需求规格确认
1
1
1
1
0.00
0.00
2系统设计
9
12
18
25
4.69
2.17
2.1软件系统架构设计
5
3
5
7
0.44
0.67
2.2数据库设计
5
3
5
7
0.44
0.67
2.3系统详细模块功能设计
5
3
5
7
0.44
0.67
2.4软件设计测试
3
2
3
4
0.11
0.33
2.5软件设计确认
2
1
1
2
0.03
0.17
3系统实施
28
18
26
38
11.11
3.33
3.1数据持久层实现
3
2
2
4
0.11
0.33
3.2系统框架搭建
2
1
1
3
0.11
0.33
3.3系统表现层实现
8
5
7
10
0.69
0.83
3.4系统服务器端应用实现
15
10
14
20
2.78
1.67
3.2系统集成
10
6
10
14
1.78
1.33
4软件测试
21
13
20
28
6.25
2.50
4.1集成测试
5
3
5
7
0.44
0.67
4.2功能测试
5
3
5
7
0.44
0.67
4.3系统测试
6
4
5
7
0.25
0.50
4.4验收测试
5
3
5
7
0.44
0.67
5系统验收
3
1
2
4
0.25
0.50
5.1软件交付
3
1
2
4
0.25
0.50
3.3项目控制计划
3.3.1质量保证计划
1、目的
本计划的目的在于对所开发的数字化校园学工系统规定各种必要的质量保证措施，以保证所交付的软件能够满足项目委托书或合同中规定的各项需求，能够满足本项目总体组制定的且经领导小组批准的该软件系统需求规格说明书中规定的各项具体需求。
软件开发人员在开发软件系统所属的各个子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经总体组批准。
2、管理机构
在本软件系统整个开发期间，必须成立软件质量保证小组负责质量保证工作。
软件质量保证小组属总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及各个子系统软件质量保证人员等方面的人员组成，由项目的软件工程小组代表任组长。
各子系统的软件质量保证人员在业务上受软件质量保证小组领导，在行政上受各子系统负责人领导。
软件质量保证小组和软件质量保证人员必须检查和督促本计划的实施。
各子系统的软件质量保证人员有权直接向软件质量保证小组报告子项目的软件质量状况。
各子系统的软件质量保证人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划的所有要求。
3、任务
软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。
因此，对新开发的或正在开发的各子系统，要按照本计划的各项规定进行各项评审工作。
软件质量保证小组要派成员参加所有的评审与检查活动。
评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。
在软件开发过程中，要进行如下几类评审与检查工作：
A.阶段评审：
在软件开发过程中，要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。
在软件及其所属各子系统的开发过程中，应该进行以下三次评审：
第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。
阶段评审工作要组织专门的评审小组，原则上由项目总体小组成员或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、质量保证人员、软件开发单位和上级主管部门的代表，其他参加人员视评审内容而定。
每一次评审工作都应填写评审总结报告（RSR）、评审问题记录（RPL）、评审成员签字表（RMT）与软件问题报告单（SPR）等四张表格。
b.日常检查：
在软件的工程化生产过程中，各子系统应该填写项目进展报表，即软件进展报表表头、软件阶段进度表、软件阶段产品完成情况表、软件开发费用表等四张表格。
项目总体组杨以通过项目进展季报表发现有关软件质量的问题。
c.软件验收：
必须组织专门的验收小组对开发软件系统及其所属各个子系统进行验收。
验收内容应包括文档验收、程序验收、演示、验收测试与测试结果评审等几项工作。
4、职责
在项目的软件质量保证小组中，其各方面人员的职责如下：
a.组长全面负责有关软件质量保证的各项工作；
b.总体组代表负责有关阶段评审、项目进展报表检查以及软件验收准备等三方面工作中的质量保证工作；
c.项目的专职配置管理人员负责有关软件配置变动、软件媒体控制以及对供货单位的控制等三方面的质量保证活动；
d.各子系统的软件质量保证人员负责测试复查和文档的规范化检查工作；
e.用户代表负责反映用户的质量要求，并协助检查各类人员对软件质量保证计划的执行情况；
f.项目的专职质量保证人员协助组长开展各项软件质量保证活动，负责审查所采用的质量保证工具、技术和方法，并负责汇总、维护和保存有关软件质量保证活动的各项记录。
5、文档
5.1.基本文档
为了确保软件的实现需求规格说明书中规定的各项需求，软件开发小组至少应该编写以下八个方面内容的文档：
a.软件需求规格说明书（SRS）；
b.软件设计说明书（SDD），对一些规模较大或复杂性较高的项目，应该把本文档分成概要设计说明书（PDD）与详细设计说明书（DDD）两个文档；c.软件测试计划（STP）；
d.软件测试报告（STR）；
e.用户手册（SUM）；
f.源程序清单（SCL）；
g.项目实施计划（PIP）；
h.项目开发总结（PDS）。
5.2其他文档
除了基本文档之外，对于尚在开发中的软件，还应该包括以下四个方面的文档：
a.软件质量保证计划（SQAP）；
b.软件配置管理计划（SCMP）；
c.项目进展报表（PPR）；
d.阶段评审报表（PRR）。
注：
前面两个文档由项目软件工程小组制订，属于管理文档，各个子系统的项目承办单位与软件开发单位都应充分考虑执行计划中规定的条款。
后面两类文档属于工作文档。
5.3文档质量的度量准则
文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。
验证和确认就是要检查各阶段文档的合适性。
评审文档质量的度量准则有以下六条：
a.完备性：
所有承担软件开发任务的人员，都必须按照相应的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。
b.正确性：
在软件开发各个阶段所编写的文档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。
c.简明性：
在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练，适合各种文档的特定读者。
d.可追踪性：
在软件开发各个阶
升级会员 