数字化校园学工信息系统
小组成员
分工明细：
目录
一、引言
1.1编写目的
编写项目计划书，主要目的是使项目工作开展的各个过程合理有序，以文件化的形式，把对于在项目生命周期内的工作任务范围、各项工作的任务分解、项目团队组织结构、各团队成员的工作责任、团队内外沟通协作方式、开发进度、经费预算、项目内外环境条件、风险对策等内容做出的安排以书面的方式，作为项目团队成员及项目干系人之间的共识与约定，项目生命周期内的所有项目活动的行动基础，以及项目团队开展和检查项目工作的依据。
1.2 背景
项目建设背景：
随着信息技术的飞速发展和高等学校教育体制改革的不断深入使教育管理手段发生重大的变革,传统的以手工和纸张对学生信息及相关的管理工作已经远远不能适应新的发展需要尤其是随着计算机网络和Internet的普及,运用先进计算机技术对信息进行科学化和网络化管理已经成为高校信息管理的趋势。对于高校的学生管理部门来说，学生管理工作面临着信息处理量越来越多、信息处理速度越来越高，管理人员的劳动强度越来越大的压力，倘若继续沿用传统的手工作业手段从事学生管理工作，势必不能适应教育改革的需要。然而在学生管理工作中的现代管理手段主要体现在以计算机技术为核心，利用有效的网络化信息管理，使学生和教师之间，特别是学工队伍教师之间，进行数据共享。
就高校学生管理工作而言，管理对象的事务复杂且数据量大。因此，利用计算机技术这个现代化管理手段来做好学生管理工作，是适应教育改革的需要，也是时代的要求。
项目预期的用户：
各大高校的学生，教师及管理人员；
1.3定义
甘特图：是表示项目各阶段任务开始时间与结束时间的图形，从而反映出计划和进度的安排。
关键路径法：是一种运用特定的、有顺序的网络逻辑和估算出的项目活动工期，确
定项目每项活动的最早与最晚开始和结束时间，并做出项目工期网络计划的方法。
网络图：是活动排序的一个输出，它可展示项目中的各个活动之间的逻辑关系，表明项目任务将如何以什么顺序进行 。
WBS分解：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围每下降一层代表对项目工作的更详细定义。
1.4 参考资料
| 书名 |
作者 |
出版社 |
出版时间 |
| 软件项目管理 |
郭宁，周晓华 |
清华大学出版社、北京交通大学出版社 |
2009.8 |
二、项目概述
2.1 项目目标
项目目标是要实现数字化校园学工信息系统的各个功能，实现校园文化综合整合的目的，展现数字化校园的优势。
项目目标总体可分为三个阶段：
一．需求分析阶段
需求分析阶段是所有阶段的基础和依据。这个阶段是关系到整个项目的成败，在整体项目中占有举足轻重的地位。这个阶段应完成的任务是：
（1）认真分析旧的学工管理信息系统，总结概括其优缺点，以及找出优势的原因和缺点的瓶颈；
（2）做好各项调研工作，对项目本身进行实际深入的了解和分析，从广大用户和网站开发人员手中积极获取第一手的资料和真实的需求，并做好最后的概括总结；
（3）对项目的可行性做出一定的分析；
（4）综合以上的内容和实际的情形，做出可行性研究报告和项目计划书，为整
体项目的进行把好方向以及奠定夯实的基础。
二．详细设计阶段
详细设计阶段是对项目要实现的功能进行整体的设计和初步的实现，为网站整体的运作做好坚实的基础，对网站的功能进行详细的分解和划分，为最好网站的实现做好准备。本项目的主要实现功能如下：
- 个人基本信息管理
实现对个人信息的查询、更新操作。
个人信息包括学号、姓名、班级、籍贯、性别、民族、生日、政治面貌、联系方式、email、银行卡号、身份证、家庭详细地址、家庭情况、自我评价。
2.奖学金管理
支持学生成绩绩点、任职分值、荣誉分值、综合分值等计算、统计和分析，实现自动排名、审计奖学金，公示奖学金评审结果等功能。
以“服务学生就业”理念为依托，构建一个针对性强，实时、方便的数据采集、分析和管理平台，逐步实现对学生就业信息的更好管理，提高信息化管理水平，为相关决策提供支持。包括：简历管理、应聘管理。
简历管理：管理学生简历信息，简历信息包括姓名、籍贯、性别、民族、政治面貌、毕业院校、学历、专业、英语等级、联系方式、email、联系地址、求职意向、自我评价、实践经历、奖励情况。
应聘管理：超级管理员管理各个企业的发布的应聘信息，企业管理员可对申请岗位的用户进行审核，应聘信息包括岗位编号、应聘企业、岗位名称、岗位类型、岗位详细信息、发布时间、状态。
支持以支部为核心的党员管理方式，加强和改进党员的管理，有助于党员能够及时参加党的组织生活，接受党组织的教育、管理和监督,更好的发挥先锋模范作用。
未入党用户可提交入党申请书；已入党用户，可查看所在党支部信息和入党流程。党支部信息包括支部名称，支部正式党员人数，预备党员人数，支部所属单位，支部简介。
5勤工岗位综合管理：有岗位设定、学生申请、教师审批的功能。提高了勤工岗位服务和管理的效率性和科学性。
学生需先登记个人信息，才能申请岗位，可查看可申请的岗位、岗位出勤情况，报酬情况和评价。学院管理员可添加、删除岗位信息，
登记的个人信息包括学号、姓名、性别、联系方式、学院、专业，在校消费情况如月平均消费，勤工特长，家庭经济情况。
申请的岗位包括设岗单位、岗位名称岗位年份、报名结束时间、岗位所属部门、岗位所属单位。
岗位管理员需记录学生每次出勤情况，学生可查看自己岗位的出勤情况，出勤情况包括姓名、岗位名称、月份、迟到次数、缺岗次数、离岗次数。
报酬情况包含的信息有学生姓名、岗位名称、月份、发放时间、发放人。
从学生申请到教师审核，实现各项资助准确无误处理，有助于加强学校对困难生的服务和管理，简化困难资助申请的繁琐过程，给困难生提供更加简洁、方便的服务渠道。
学生提交的申请包括家庭情况、是否申请贷款、是否参与勤工、户口、奖学金情况、困难资助、家庭联系方式、家庭详细地址、申请理由。
教师审核需要给出认定结果，学生可查看自己的认定情况。
对学习成绩较差学生学习状况的预警、跟踪和统计、报表的生成。主要功能模块包括：个人学习情况查看跟踪、个人成绩单导出、个人学业预警帮扶、整体学业情况预警。
- 成绩管理
记录每个学生每个学期的成绩，用户可查看自己不同学年、学期的成绩。成绩信息包括年份、学期、课程名、学分、类型、成绩。
三．编码测试阶段
编码测试阶段是全面开发阶段，具体实现上个阶段的功能块，然后集成在一个系统中，完成网站的开发和实现；在网站发布前最后进行一次最全面的测试（当然测试是每个阶段所必须进行的一个过程。
2.2产品目标与范围
产品目标：
- 支持学院各项学生工作的数字化，促进学生工作线的协同办公，提高学生管理工作效率；
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项目开发环境
软件环境：windows 7系统 火狐4.0
开发工具：tomcat5.0以上版本以及 Myeclipse,Dreamweaver可视化软件
数据系统：SQL Server 2008
硬件：
处理器Pentium 166 MHz或更高 推荐256MHz
内存至少 64 MB 推荐256MB
硬盘空间至少 250 MB 推荐 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.1 WBS法分解任务
3.2.2项目活动时间表
3.2.3甘特图
- 需求分析
2 系统设计 
3 系统实施
4 软件测试
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. 可追踪性： 在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性与横向可追踪性两个方面。前者是指在不同文档的相关内容之间相互检索的难易程度；后者是指确定同一文档某一内容在本文档中的涉及范围的难易程度。
e. 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。 文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。
f. 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。
6、评审和检查
对新开发的或正在开发的各个子系统，都要按照规定认真进行定期的或阶段性的各项评审工作。就整个软件开发过程而言，至少要进行软件需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。
6.1 第一次评审
第一次评审会对软件需求、概要设计以及验证与确认方法进行评审。
a. 软件需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性。
b. 概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合适性。
c. 软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。
6.2 第二次评审
第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。
a. 详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。
b. 编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，满足《C语言编程格式约定》。在满足这些要求之后，方可进行测试工作评审。
c. 测试工作评审应对所有的程序单元进行静态分析，检查其程序结构（即模块和函数的调用关系和调用序列）和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。在结构测试中，所有程序单元结构测试的语句覆盖率Co必须等于100%，分支覆盖率C1必须大于或等于85%。要给出每个单元的输入和输出变量的变化范围。各个子系统只进行功能测试，不单独进行结构测试，因而要登录程序单元之间接口的变量值，力图使满足单元测试的C1和Co准则的那此测试用例在子系统功能测试时得到再现。测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时，不仅要运行变量的等价值，而且要运行变量的（合法的和非法的）边界值；不仅要运行开发单位给出的测试用例，而且要允许运行任务委托单位或用户、评审人员选定的采样用例。
6.3 第三次评审
第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。
a. 功能检查（FA）应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求。
b. 物理检查（PA）应对软件进行物理检查，以验证程序和文档已经一致、并已做好了交付的准备。
c. 综合检查（CA）应验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。
7、工具、技术和方法
在项目所属的各个子系统（其中包括有关的支持软件）的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量活动的支持工具、技术和方法。这些工具主要有下列三种：
a. C软件测试工具。它支持用C语言编写的模块的静态分析、结构测试与功能测试。主要功能为：协助测试人员判断程序结构与变量使用情况是否有错；给测试人员提供模块语句覆盖率Co和分支覆盖率C1的值，并显示未覆盖语句和未覆盖分支的号码及其分支谓词，给出不同测试用例有效性的表格；同时提出功能测试的有效情况，并协助组织最终交付给用户的有效测试用例的集合。
b. 软件配置管理工具。它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户在不同文档相关内容之间进行相互检索并确定同一文档某一内容在本文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理。
c. 文档辅助生成工具与图形编辑工具。它主要协助用户绘制描述程序流程与结构的DFD图与SC图、绘制描述软件功能（输入、输出关系）的曲线以及绘制描述控制系统特性的一些其他图形，同时还可生成若干与开发软件文档编制大纲相适应的文档模块板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，还有助于提高文档的编制质量。
8、媒体控制
为了保护计算机程序的物理媒体，以免非法存取、意外损坏或自然老化，项目软件系统的各个子系统（包括支持软件）都必须设立软件配置管理人员，并按照软件配置管理计划妥善管理和存放各个子系统及其专用支持软件的媒体。
9、对供货单位的控制
开发项目所属的各个子系统开发组，如果需要从软件销售单位购买、委托其他开发单位开发、从开发单位现存软件库中选用或从项目委托单位或用户的现有软件库中选用软部件时，则在选用前应向项目总体组报告，然后由“软件选用评审小组”进行评审、测试与检查，只有当演示成功、测试合格后才能批准选用。
10、记录收集、维护和保存
在项目及其所属的各个子系统的研制与开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。在软件质量保证小组中，应有专人负责收集、汇总与保存有关软件质量保证活动的记录。
3.3.2进度控制计划
1、项目进度控制的前提
项目进度控制的前提是有效地项目计划和充分掌握第一手实际信息，在此前提下，通过实际值与计划值进行比较，检查、分析、评价项目进度。通过沟通、肯定、批评、奖励、惩罚、经济等不同手段，对项目进度进行监督、督促、影响、制约。及时发现偏差，及时予以纠正；提前预测偏差，提前予以预防。
在进行项目进度控制时，必须落实项目团队之内或之外进度控制人员的组成，明确具体的控制任务和管理职责。要制定进度控制的方法，要选择适用的进度预测分析和进度统计技术或工具。要明确项目进度信息的报告、沟通、反馈、以及信息管理制度。
项目进度控制应该由部门经理和项目监控人员共同进行，之所以需要部门经理参与，是因为部门经理负责项目一般要负责一定人事行政的责任，如成员的考核、升迁、发展等。他们只有通过软件开发项目才能更好地了解项目成员，项目也只用通过对他们有切身利益的管理者参与管理才会更加有效。
2、项目进度控制主要手段
项目计划书：作为项目进度控制的基准和依据，项目负责人负责制作项目计划书。项目进度监控人员根据项目计划书对项目的阶段成果完成情况进行监控，如果由于某些原因阶段成果提前或延后完成，项目负责人应提前申请并做好开发计划的变更。对于项目进度延后的，应当分析产生进度延后的原因、确定纠正偏差的对策、采取纠正偏差的措施，在确定的期限内消除项目进度与项目计划之间的偏差。项目计划书应当根据项目的进展情况进行调整，以保证基准和依据的新鲜性、有效性。
项目阶段情况汇报与计划：项目负责人按照预定的每个阶段点（根据项目的实际情况可以是每周、每双周、每月、每双月、每季、每旬等等）定期在与项目成员和其他相关人员充分沟通后，向相关管理人员和管理部门提交一份书面的项目阶段工作汇报与计划，内容包括：
a、对上一阶段计划执行情况的描述
b、下一阶段的工作计划安排
c、已经解决的问题和遗留的问题
d、资源申请、需要协调的事情及其人员
e、其他需要处理的问题
这些汇报将存档，作为对项目进行考核的重要材料。
在计划制定时就要确定项目总进度目标与分进度目标；在项目进展的全过程中，进行计划进度与实际进度的比较，及时发现偏离，及时采取措施纠正或者预防；协调项目参与人员之间的进度关系。
在项目计划执行中，做好这样几个方面的工作：
检查并掌握项目实际进度信息。对反映实际进度的各种数据进行记载并作为检查和调整项目计划的依据，积累资料，总结分析，不断提高计划编制、项目管理、进度控制水平。
做好项目计划执行中的检查与分析。通过检查，分析计划提前或拖后的主要原因。项目计划的定期检查是监督计划执行的最有效的方法。
及时制定实施调整与补救措施。调整的目的是根据实际进度情况，对项目计划作必要的修正，使之符合变化的实际情况，以保证项目目标其顺利实现。由于初期编制项目计划时考虑不周，或因其他原因需要增加某些工作时就需要重新调整项目计划中的网络逻辑，计算调整后的各时间参数、关键线路和工期。
3、进度控制内容
从内容上看，软件开发项目进度控制主要表现在组织管理、技术管理和信息管理等这几个方面。组织管理包括这样几个内容：
（1）项目经理监督并控制项目进展情况；
（2）进行项目分解，如按项目结构分，按项目进展阶段分，按合同结构分，并建立编码体系；
（3）制订进度协调制度，确定协调会议时间，参加人员等；
（4）对影响进度的干扰因素和潜在风险进行分析。
技术管理与人员管理有非常密切的关系。软件开发项目的技术难度需要引起重视，有些技术问题可能需要特殊的人员，可能需要花时间攻克一些技术问题，技术措施就是预测技术问题并制订相应的应对措施。控制的好坏直接影响项目实施进度。
在软件开发项目中，合同措施通常不由项目团队负责，企业有专门的合同管理部门负责项目的转包、合同期与进度计划的协调等。项目经理应该及时掌握这些工作转包的情况，按计划通过计划进度与实际进度的动态比较，定期向客户提供比较可靠的报告等。
软件开发项目进度控制的信息管理主要体现在编制、调整项目进度控制计划时对项目信息的掌握上。这些信息主要是：预测信息，即对分项和分阶段工作的技术难度、风险、工作量、逻辑关系等进行预测；决策信息，即对实施中出现的计划之外的新情况进行应对并做出决策。参与软件开发项目决策的有项目经理、企业项目主管及客户的相关负责人；统计信息，软件开发项目中统计工作主要由参与项目实施的人员自己做，再由项目经理或指定人员检查核实。通过收集、整理和分析，写出项目进展分析报告。根据实际情况，可以按日、周、月等时间要求对进度进行统计和审核，这是进度控制所必须的。
4、不同阶段的项目进度控制
从项目进度控制的阶段上看，软件开发项目进度控制主要有：项目准备阶段进度控制，需求分析和设计阶段进度控制，实施阶段进度控制等这几个部分。
准备阶段进度控制任务是：向业主提供有关项目信息，协助业主确定工期总目标；编制阶段计划和项目总进度计划；控制该计划的执行；
需求分析和设计阶段控制的任务是：编制与用户的沟通计划、需求分析工作进度计划、设计工作进度计划，控制相关计划的执行等。
实施阶段进度控制的任务是：编制实施总进度计划并控制其执行；编制实施计划并控制其执行等。由甲乙双方协调进度计划的编制、调整并采取措施确保进度目标的实施。
为了及时地发现和处理计划执行中发生的各种问题，就必须加强项目的协同工作。协同工作是组织项目计划实现的重要环节。它要为项目计划顺利执行创造各种必要的条件，以适应项目实施情况的变化。
5、关于进度落后时的“赶工”措施
进度落后的情况下，有几种措施来弥补，如加人、加班、加激励等等，这些都是增加资源而又未必会见效的方法。根据Brooks原则，在某些项目进度延迟的情况下增加人手，有可能会使项目的进度更加延后。因为对于新加入本项目的员工来说，对项目相关背景、需求、设计的培训、对项目环境的熟悉和项目团队成员之间的沟通路径的增加，可能会使项目的工作效率急剧下跌。而加班造成的疲劳会再次使工作效率降低。增加激励会造成工作成本却不断的向上攀升。这些措施并不是完全不可取，而是项目经理要考虑适度原则。最好是要全面分析项目进度延迟的原因，如果确实是不合理的项目交付时限要求，就应当通过沟通变更为合理的项目时限要求，以免因为这样一个不合理的时限要求造成对软件质量或团队成员心理上的负面影响，最终导致项目最终的失败。否则应从技术、团队成员心态、环境等方面查找原因，找到提高效率、加快进度的方法。
3.4配置管理计划
由于本项目属于中小型项目，而且项目组人员对SVN也比较熟悉，所以采用SVN作为配置管理工具。
3.4.1配置库目录结构
本项目配置项命名规则如下：
配置项目录结构如下表：
| 序号 |
配置项类型 |
说明 |
路径 |
||
| 1 |
TCM |
技术合同管理 |
$\ EMS \TCM |
||
| 2 |
RM |
需求管理 |
$\ EMS \RM |
||
| 3 |
SPP |
软件项目规划 |
$\ EMS \SPP |
||
| 4 |
SPTO |
软件项目跟踪与管理 |
$\ EMS \SPTO |
||
| 5 |
SCM |
软件配置管理 |
$\ EMS \SCM |
||
| 6 |
SQA |
软件质量保证 |
$\ EMS \SQA |
||
| 7 |
SPE |
软件产品工程 |
设计 |
$\EMS \SPE\DESIGN |
|
| 8 |
源代码 |
$\EMS \SPE\SOURCE |
|||
| 9 |
目标代码 |
$\EMS \SPE\BUILD |
|||
| 10 |
测试 |
$\EMS \SPE\TEST |
|||
| 11 |
发布 |
$\EMS \SPE\RELEASE |
|||
3.4.2主要配置项
| 类型 |
主要配置项 |
标识符 |
预计正式发表时间 |
| 技术合同 |
《合同》 |
EMS -TCM-Contract-V1.0 |
2018-4-11 |
| 工作说明书（SOW） |
EMS - TCM-SOW-V1.0 |
2018-4-11 |
|
| 计划 |
《项目计划》 |
EMS -SPP-PP-V1.0 |
2018-4-11 |
| 《质量保证计划》 |
EMS -SPP-SQA-V1.0 |
2018-4-11 |
|
| 《配置管理计划》 |
EMS -SPP-SCM-V1.0 |
2018-4-11 |
|
| 需求 |
《需求规格说明书》 |
EMS -RM-SRS-V1.0 |
2018-4-18 |
| 用户DEMO |
EMS -RM-Demo-V1.0 |
2018-4-18 |
|
| 设计 |
《总体设计说明书》 |
EMS -Design-HL-V1.0 |
2018-4-22 |
| 《数据库设计》 |
EMS - Design-DB-V1.0 |
2018-4-22 |
|
| 《详细设计说明书》 |
EMS -Design-LL-V1.0 |
2018-4-25 |
|
| 《设计术语及规范》 |
EMS -Design-STD-V1.0 |
2018-4-22 |
|
| 编程 |
源程序 |
EMS -Code-ModuleName-V1.0 |
2018-6-2 |
| 编码规则 |
EMS -Code-STD-V1.0 |
2018-4-22 |
|
| 测试 |
《测试计划》 |
EMS -Test-Plan-V1.0 |
2018-6-2 |
| 《测试用例》 |
EMS -Test-Case-V1.0 |
2018-6-2 |
|
| 《测试报告》 |
EMS -Test-Report-V1.0 |
2018-6-4 |
|
| 提交 |
运行产品 |
EMS -Product-Exe-V1.0 |
2018-6-5 |
| 《验收报告》 |
EMS -Product-Report-V1.0 |
2018-6-6 |
|
| 《用户手册》 |
EMS -Product-Manual-V1.0 |
2018-6-6 |
四、预算
| 任务名称 |
工期 |
人员数 |
费用/天/人 |
费用 |
累计费用 |
| 0 软件项目计划制定 |
3 |
3 |
120 |
1080 |
1080 |
| 1.1 需求捕获 |
3 |
3 |
150 |
1350 |
2430 |
| 1.2 抽象业务流程图 |
2 |
1 |
120 |
240 |
2670 |
| 1.3 建立用例模型 |
2 |
1 |
120 |
240 |
2910 |
| 1.4 编写需求规格说明书 |
2 |
1 |
150 |
300 |
3210 |
| 1.3 需求规格测试 |
2 |
2 |
180 |
720 |
3930 |
| 1.4 需求规格确认 |
1 |
3 |
180 |
540 |
4470 |
| 2.1 软件系统架构设计 |
5 |
2 |
350 |
3500 |
7970 |
| 2.2 数据库设计 |
5 |
3 |
350 |
5250 |
13220 |
| 2.3 系统详细模块功能设计 |
5 |
3 |
350 |
5250 |
18470 |
| 2.4 软件设计测试 |
3 |
3 |
180 |
1620 |
20090 |
| 2.5 软件设计确认 |
2 |
3 |
180 |
1080 |
21170 |
| 3.1 数据持久层实现 |
3 |
4 |
250 |
3000 |
24170 |
| 3.2 系统框架搭建 |
2 |
2 |
200 |
800 |
24970 |
| 3.3 系统表现层实现 |
8 |
4 |
200 |
6400 |
31370 |
| 3.4 系统服务器端应用实现 |
15 |
4 |
300 |
18000 |
49370 |
| 3.2 系统集成 |
10 |
4 |
280 |
11200 |
60570 |
| 4.1 集成测试 |
5 |
2 |
150 |
1500 |
62070 |
| 4.2 功能测试 |
5 |
2 |
150 |
1500 |
63570 |
| 4.3 系统测试 |
6 |
2 |
150 |
1800 |
65370 |
| 4.4 验收测试 |
5 |
2 |
150 |
1500 |
66870 |
| 5.1 软件交付 |
1 |
1 |
120 |
120 |
66990 |
| 其他费用 |
|||||
| 通信费 |
800 |
||||
| 交通费 |
1200 |
||||
| 培训费 |
1500 |
||||
| 资料费 |
300 |
||||
| 饮食补贴 |
600 |
||||
| 其他 |
100 |
||||
| 总计 |
71490 |
||||
五、总结
经过一个学期的学习，让我对一个项目的设计、开发、测试、验收，这个过程有了新的了解，到大三以来做过的项目也有好几个，每一个都是直接编写代码，从来不会做什么需求分析，写文档设计，出什么问题都是重新改写代码。例如上学期末和其他同学为学校做一个辅导员招聘网站，也没做需求分析，更别说项目计划书，只是凭着校方领导的说辞，就进行项目的开发了。在项目结束时，部分需求发生了改变，我们又不得不更改部分源代码，大大增加了工作量，在此次更改后，在该项目刚投入使用第一天，校方又提出了新的需求，我们又不得不在原来的基础上，尽快完成新的需求。从此次的项目开发过程，再结合此次编写项目文档，让我深刻认识到，在开发前，编写项目文档，做需求分析、设计的重要性。
