HUBEI UNIVERSITY OF AUTOMOTIVE TECHNOLOGY
校园管理系统案例分析
目录：
1、导言
利用《校园管理系统》对学生的进行有效的管理，加强学生与老师的沟通，促进学生积极健康的发展，提高学生学生的素质，方便学生学习生活。
2、项目任务范围
在信息高度发达的今天，教育越来越普遍，大学生越来越多，并且互联网已经涉及到各个行业和领域。而应用网络技术进行工作，可以提高效率，促进科技发展和社会进步。推动了高效率的服。而为了提高效率，各个学校针对学生，也应该有自己的一套校园学生管理系统。这样不紧可以节省时间，还可以大大减少人力以及物力资源，提高了效率，而且减少了错误。高校校园管理系统开发的主要目的就是减轻管理员的工作量和劳动强度，辅助学校学生的管理，减少因为安排活动不合理或者添加课程而造成的错误不能及时修改，从而使学校能够以更高的效率正常进行教学工作。同时开发这个系统，大学校园管理系统能更好地服务好学生和老师，还可以提升管理水平。
任务分布图见图1
图1
3、项目目标
校园管理系统的目标是为了方便学生、教师对于日常生活的管理的一个信息共享平台。主要完成作业、活动的发布与报名、资源、网上考试、报名及方面等14个方面设计校园管理系统的整体架构。
4、项目管理策略
1、开发计划--阶段化。
2、管理业务--流程化。
3、工作步骤--程序化。
4、文档资料--规范化。
5、进度安排--网络化。
5、项目组织结构
由于该项目在实施过程中需要涉及不同组织的各方面人员，而各组织之间的利益、任务和职责也不尽相同，因此明确定义项目组织结构和各自职责可保证项目的顺利进行。
市场部：负责项目的相关商务活动、负责用户的需求调研、负责产品的宣传与推广
项目管理：负责项目的组织和规划、负责项目计划制定和维护
软件开发：负责项目的软件开发、配合产品的验收等相关活动
质量保证：负责项目过程和产品规范的制定、过程评审和产品审计
配置管理：负责项目的配置管理活动、负责软件产品的提交
角色映射表
6、项目生存期
根据该项目的特点并结合公司已有的软件生存期模型定义，本项目生存期采用增量模型如图：
生存期中的各阶段定义如下：
项目规划阶段
阶段目标：根据合同和初步的需求分析确定项目的规模、时间和资源需求。
输入：合同文本、SOW
过程：项目规划，计划确认
输出：项目计划
需求分析阶段
阶段目标：确定客户需求
输入：项目计划，SOW
过程：需求获取，需求分析
输出：原型系统，需求规格
设计阶段
阶段目标：总体系统结构设计
输入：原型系统，需求规格
过程：总体设计
输出：系统设计说明书，数据库结构定义
增量1实现
阶段目标：实现系统的旧书回收功能
输入：系统设计说明书、数据库定义结构
过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-1
增量2实现
阶段目标：实现旧书再利用功能
输入：系统设计说明书、数据库结构定义
过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-2 7、时间计划
项目进度计划甘特图如图所示见图2
8、项目成本估算
成本预算见图2
图2现金流图见图3
图3
9、质量管理计划
文档目的
能够保证完成《校园管理系统》质量
文档范围
【描述本质量管理计划涵盖的计划范围。本文档将定义可交付物的质量标准和检验标准】。参考
《软件向管理案例教程》第二版韩万江姜立新编著
项目背景
大学生越来越多，为促进学校便利管理，开发《校园管理系统》
项目结构
【描述项目质量管理团队成员组成，绘制组织结构图】。
【实施小项目时，项目经理负责保证质量。通常，可以指定一位质量监督员协助项目经理】。【实施大的项目时，可成立质量保证小组，指定人员担任专职的质量经理。质量保证小组成员包括客户和第三方人员】。
质量管理
量进行总结和评审，形成如下评审报告】：
各质量检查点
【列举项目的质量检查点和初步时间计划，如】：
参与人员和要求
【（可视项目实际情况而定）】。
项目计划阶段检查清单
需求调研阶段检查清单
需求分析阶段检查清单
设计阶段检查清单
开发阶段检查清单
集成测试阶段检查清单
系统测试阶段检查清单
工程实施阶段检查清单
质量检查和确认技术审计产品一览表
10、配置管理计划
软件项目配置管理计划案例
项目案例为《校园管理系统》，该项目的配置管理计划如下：
1. 引言
实现校园管理系统
2．组织及职责
配置管理的角色和职责见表1。
表1：配置管理角色职责表
3.配置管理环境
由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。
3.1配置库目录结构
表2：配置库的目录结构
3.2用户及权限
4．配置管理活动
4.1配置项标志
4.1.1命名规范
本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。
公司：3个字符
项目：最长10个字符
类型：最长5个字符
编号：最长8位数字/字符
版本号：V m.n
QTD-School–RM–SRS-v1.0
图1：配置项命名规范
4.1.2主要配置项
4.1.3项目基线
在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。
表5
4.1.4配置项的版本管理
配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。
这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。
对配置项的版本管理在不同分支具有不同的策略：
（1）主干分支
系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。
（2）私有分支
如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。
（3）小组分支
如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
（4）集成分支
集成测试时在主干分支的特定版本（由LABLE标志清晰）上建立集成分支，测试工作在集成分支上完成。
私有分支和小组分支均为可选，必要时建立。
4.2变更管理
变更管理的流程是：
（1）由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复审，以确定该请求是否为有效请求。典型的变更请求管理有需求变更管
理、缺陷追踪等。
（2）配置管理者收到基线修改请求后，在配置库中生成与此配置项相关的波及关系表。
（3）配置管理者将基线波及关系表提交给SCCB，由SCCB确定是否需要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的具
体文件，并在波及分析表中标志出来。
（4）配置管理者按照出库程序从配置库中取出需要修改的文件。
（5）项目人员将修改后的文件提交给配置管理者。
（6）配置管理者将修改后的配置项按入库程序放入配置库。
（7）配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变更记录表，并按入库程序放入配置库。
4.3配置状态统计
利用配置状态统计，可以记录和跟踪配置项的改变。状态统计可用于评估项目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被执行。为跟踪工作产品基线，配置管理者需手机下列信息：
●基线类型●工作产品名称
●配置项名称/标识符●版本号
●更改日期/时间●更改请求列表
●需要更改的配置项●当前状态
●当前状态发生日期
项目组每周提交配置项清单及其当前版本。
配置管理人员每半个月提交变更请求的状态统计。
11、项目风险计划
下图是本项目的风险计划清单表
一、规模度量
12.度量计划
根据企业的质量策略和项目的特点制定本项目度量计划，主要目的是为本项目的控制提
供实际数据，以及将来其它项目提供估算依据，表1给出项目规模的度量指标，表2是项目
二、时间度量
三、需求变更度量统计表
13质量沟通与评审
项目交流计划分为如下几类：
1、每日的沟通交流
2、定期的评审
3、阶段的评审
14总结
项目集成管理是为了实现项目目标，确保项目范围内的各项工作能够顺利协调的局部性，平衡项目各个目标之间的冲突，保证项目过程各阶层的正确实施，所展开的以整体思想为指导，从全局出发，以项目总体利益最大化为目标，以统一协调各个方面管理为内容进行的全面管理的过程，它具有综合性.全局性和内外兼顾性的特征。通过大学校园管理系统对项目的开发有了一定的了解，对以后的工作有一定的帮助。