大学校园管理系统案例分析1

HUBEIUNIVERSITYOFAUTOMOTIVETECHNOLOGY校园管理系统案例分析目录：TOC\o"1-3"\h\uHYPERLINK\l_Toc72011、导言 PAGEREF_Toc72013HYPERLINK\l_Toc269352、项目任务范围 PAGEREF_Toc269353HYPERLINK\l_Toc19613、项目目标 PAGEREF_Toc19614HYPERLINK\l_Toc207714、项目管理策略 PAGEREF_Toc207715HYPERLINK\l_Toc93285、项目组织结构 PAGEREF_Toc93285HYPERLINK\l_Toc2036、项目生存期 PAGEREF_Toc2035HYPERLINK\l_Toc308897、时间计划 PAGEREF_Toc308897HYPERLINK\l_Toc315368、项目成本估算 7HYPERLINK\l_Toc169989、质量管理计划 7HYPERLINK\l_Toc635410、配置管理计划 12HYPERLINK\l_Toc206811、项目风险计划 17HYPERLINK\l_Toc1604312、度量计划 18HYPERLINK\l_Toc1484613、项目沟通与评审 20HYPERLINK\l_Toc977514、总结： 20导言利用《校园管理系统》对学生的进行有效的管理，加强学生与老师的沟通，促进学生积极健康的发展，提高学生学生的素质，方便学生学习生活。2、项目任务范围在信息高度发达的今天，教育越来越普遍，大学生越来越多，并且互联网已经涉及到各个行业和领域。而应用网络技术进行工作，可以提高效率，促进科技发展和社会进步。推动了高效率的服。而为了提高效率，各个学校针对学生，也应该有自己的一套校园学生管理系统。这样不紧可以节省时间，还可以大大减少人力以及物力资源，提高了效率，而且减少了错误。高校校园管理系统开发的主要目的就是减轻管理员的工作量和劳动强度，辅助学校学生的管理，减少因为安排活动不合理或者添加课程而造成的错误不能及时修改，从而使学校能够以更高的效率正常进行教学工作。同时开发这个系统，大学校园管理系统能更好地服务好学生和老师，还可以提升管理水平。任务分布图见图1图13、项目目标校园管理系统的目标是为了方便学生、教师对于日常生活的管理的一个信息共享平台。主要完成作业、活动的发布与报名、资源、网上考试、报名及方面等14个方面设计校园管理系统的整体架构。4、项目管理策略1、开发计划--阶段化。2、管理业务--流程化。3、工作步骤--程序化。4、文档资料--规范化。5、进度安排--网络化。5、项目组织结构由于该项目在实施过程中需要涉及不同组织的各方面人员，而各组织之间的利益、任务和职责也不尽相同，因此明确定义项目组织结构和各自职责可保证项目的顺利进行。市场部：负责项目的相关商务活动、负责用户的需求调研、负责产品的宣传与推广项目管理：负责项目的组织和规划、负责项目计划制定和维护软件开发：负责项目的软件开发、配合产品的验收等相关活动质量保证：负责项目过程和产品规范的制定、过程评审和产品审计配置管理：负责项目的配置管理活动、负责软件产品的提交角色映射表项目管理组软件开发组质量保证组配置管理组负责人王扶夏孙立志张小龙范蠡植组成人11116、项目生存期根据该项目的特点并结合公司已有的软件生存期模型定义，本项目生存期采用增量模型如图：项目规划项目规划需求分析需求分析设计设计增量3增量增量3增量1增量2集成测试集成测试产品提交产品提交生存期中的各阶段定义如下：项目规划阶段阶段目标：根据合同和初步的需求分析确定项目的规模、时间和资源需求。输入：合同文本、SOW过程：项目规划，计划确认输出：项目计划需求分析阶段阶段目标：确定客户需求输入：项目计划，SOW过程：需求获取，需求分析输出：原型系统，需求规格设计阶段阶段目标：总体系统结构设计输入：原型系统，需求规格过程：总体设计输出：系统设计说明书，数据库结构定义增量1实现阶段目标：实现系统的旧书回收功能输入：系统设计说明书、数据库定义结构过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-1增量2实现阶段目标：实现旧书再利用功能输入：系统设计说明书、数据库结构定义过程：详细设计，编码，代码走查，代码评审，单元测试输出：详细设计说明书，源代码，可运行版本-27、时间计划项目进度计划甘特图如图所示见图2项目成本估算成本预算见图2图2现金流图见图3图3质量管理计划文档目的能够保证完成《校园管理系统》质量文档范围【描述本质量管理计划涵盖的计划范围。本文档将定义可交付物的质量标准和检验标准】。参考《软件向管理案例教程》第二版韩万江姜立新编著项目背景大学生越来越多，为促进学校便利管理，开发《校园管理系统》项目结构【描述项目质量管理团队成员组成，绘制组织结构图】。【实施小项目时，项目经理负责保证质量。通常，可以指定一位质量监督员协助项目经理】。【实施大的项目时，可成立质量保证小组，指定人员担任专职的质量经理。质量保证小组成员包括客户和第三方人员】。质量管理【可参照下表，描述在项目各生命周期阶段所需递交的交付物】。序号交付物交付时间负责人2软件规划2016..10.26王扶夏5需求开发2016.11.2王磊11设计2016.11.4张小龙16通用功能2016.11.9李玉环124招生考试管理－增量22016.11.18范蠡植30学生日常活动管理－增量32016.11.23孙立志36教师教务管理－增量42016.12.5王扶夏45教师辅助功能－增量52016.12.12张小龙50考研交流－增量62016.12.20李玉环1【描述项目质量控制过程中采用的评审方式。如：定期质量评审是对项目前一阶段的工作质量进行总结和评审，形成如下评审报告】：项目评审项目质量评审报告项目名称大学校园管理系统质量经理王扶夏时间2016项目阶段描述检查内容检查结果项目按规范流程执行情况合格项目文档情况充分系统设计与需求的符合性符合技术实现方法的合理性、可行性、用户认同性统一项目进度情况顺利人员安排情况合理资源保证情况优秀对外协作情况优秀问题列表序号问题描述带来的风险及影响严重程度解决办法、期限2不准确是项目不符合现实30%15不合格有漏洞有篡改入侵60%311不合格有漏洞有篡改入侵60%216不合格有漏洞有篡改入侵60%124不合格有漏洞有篡改入侵60%330不合格有漏洞有篡改入侵60%236不合格有漏洞有篡改入侵60%245不合格有漏洞有篡改入侵60%34其它意见和建议各质量检查点【列举项目的质量检查点和初步时间计划，如】：检查点日期项目计划阶段2016.11.2需求调研阶段2016.11.3需求分析阶段2016.11.4概要设计阶段2016.11.5详细设计阶段2016.11.6-2016.12.20编码/单元测试阶段2016.12.20-2016.12.23集成测试阶段2016.12.24-2016.12.25系统测试阶段2016.12.25-2016.12.26工程实施阶段2016.12.26-2016.12.27参与人员和要求【（可视项目实际情况而定）】。项目计划阶段检查清单检查内容检查时间完成情况负责人项目规模2016.11.2通过王扶夏时间计划2016.11.2通过王磊项目需求2016.11.2通过孙立志需求调研阶段检查清单检查内容检查时间完成情况负责人资源需求2016.11.3通过王磊计划设置2016.11.4通过张小龙需求分析阶段检查清单检查内容检查时间完成情况负责人项目计划2016.11.6通过孙立志sow2016.11.7通过张小龙设计阶段检查清单检查内容检查时间完成情况负责人总体实现2016.11.8通过张小龙2016.11.9通过王磊开发阶段检查清单检查内容检查时间完成情况负责人系统设计说明书2016.11.10孙立志数据库结构定义2016.12.20张小龙集成测试阶段检查清单检查内容检查时间完成情况负责人测试计划2016.12.21王扶夏测试案例2016.11.25王磊系统测试阶段检查清单检查内容检查时间完成情况负责人集成测试2016.12.25张小龙系统测试2016.12.25李玉环1工程实施阶段检查清单检查内容检查时间完成情况负责人系统软件包2016.12.26孙立志验收2016.12.26王磊质量检查和确认技术审计产品一览表项审计对象审计阶段参照标准1软件项目计划计划结束企业质量体系2软件配置管理计划计划结束企业质量体系3软件质量保证计划计划结束企业质量体系4总体设计文档设计结束企业质量体系和项计划5详细设计文档设计结束企业质量体系和项计划6数据库表和编码规范设计结束企业质量体系和项计划7产品代码每个阶段实施结束企业质量体系和项计划8测试报告测试结束企业质量体系和项计划9测试计划设计结束企业质量体系和项计划10用户文档测试结束企业质量体系和项计划10、配置管理计划软件项目配置管理计划案例项目案例为《校园管理系统》，该项目的配置管理计划如下：引言实现校园管理系统2．组织及职责配置管理的角色和职责见表1。表1：配置管理角色职责表角色人员职责和工作范围配置管理者王磊制定《配置管理计划》创建和维护配置库SCCB负责人王扶夏审批《配置管理计划》审批重大的变更SCCB成员王扶夏（项目经理），张小龙（质量保证人员），李玉环1（配置管理者）审批某些配置项或基线的变更3.配置管理环境由于本项目属于中小型项目，工期也不很长，而且项目组人员对VisualSourceSafe也比较熟悉，所以采用VisualSourceSafe作为配置管理工具。3.1配置库目录结构表2：配置库的目录结构序号内容说明路径1TCM技术合同管理$\prj-School\TCM2RM需求管理$\prj-School\RM3SPP软件项目规划$\prj-School\SPP4SPTO软件项目跟踪与管理$\prj-School\SPTO5SCM软件配置管理$\prj-School\SCM6SQA软件质量保证$\prj-School\SQA7SPE软件产品工程设计$\prj-School\SPE\DESIGN8源代码$\prj-School\SPE\SOURCE9目标代码$\prj-School\SPE\BUILD10测试$\prj-School\SPE\TEST11发布$\prj-School\SPE\RELEASE3.2用户及权限表3：配置库的用户权限类别人员权限说明配置管理者王磊负责项目配置管理，拥有所有权限项目经理王扶夏访问、读质量保证人员李玉环1访问、读开发人员孙立志张小龙访问、读高层管理王扶夏访问、读4．配置管理活动4.1配置项标志4.1.1命名规范本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。图1：配置项命名规范4.1.2主要配置项表4：配置项列表类型主要配置项标识符预计正式发表时间技术合同《合同》QTD-School-TCM-Contract-V1.02003-4-11SOWQTD-School-TCM-SOW-V1.02003-4-11计划《项目计划》QTD-School-SPP-PP-V1.02003-4-11《质量保证计划》QTD-School-SPP-SQA-V1.02003-4-11《配置管理计划》QTD-School-SPP-SCM-V1.02003-4-11需求《需求规格说明书》QTD-School-RM-SRS-V1.02003-4-18用户DEMOQTD-School-RM-Demo-V1.02003-4-18设计《总体设计说明书》QTD-School-Design-HL-V1.02003-4-22《数据库设计》QTD-School-Design-DB-V1.02003-4-22《详细设计说明书》QTD-School-Design-LL-V1.02003-4-25《设计术语及规范》QTD-School-Design-STD-V1.02003-4-22编程源程序QTD-School-Code-ModuleName-V1.02003-6-2编码规则QTD-School-Code-STD-V1.02003-4-22测试《测试计划》QTD-School-Test-Plan-V1.02003-6-2《测试用例》QTD-School-Test-Case-V1.02003-6-2《测试报告》QTD-School-Test-Report-V1.02003-6-4提交运行产品QTD-School-Product-Exe-V1.02003-6-5《验收报告》QTD-School-Product-Report-V1.02003-6-6《用户手册》QTD-School-Product-Manual-V1.02003-6-64.1.3项目基线在VisualSourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。表5基线名称/标识符基线包含的主要配置项预计建立时间需求《需求规格说明书》、用户DEMO2003-4-18总体设计《总体设计说明书》、《数据库设计》2003-4-11项目实现软件源代码、编码规则2003-6-2系统测试《测试用例》、《测试报告》2003-6-44.1.4配置项的版本管理配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。对配置项的版本管理在不同分支具有不同的策略：主干分支系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。私有分支如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。小组分支如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。集成分支集成测试时在主干分支的特定版本（由LABLE标志清晰）上建立集成分支，测试工作在集成分支上完成。私有分支和小组分支均为可选，必要时建立。4.2变更管理变更管理的流程是：由请求者提交变更请求，SCCB会召开复审会议对变更请求进行复审，以确定该请求是否为有效请求。典型的变更请求管理有需求变更管理、缺陷追踪等。配置管理者收到基线修改请求后，在配置库中生成与此配置项相关的波及关系表。配置管理者将基线波及关系表提交给SCCB，由SCCB确定是否需要修改，如果需要修改，SCCB应根据波及关系表，确定需要修改的具体文件，并在波及分析表中标志出来。配置管理者按照出库程序从配置库中取出需要修改的文件。项目人员将修改后的文件提交给配置管理者。配置管理者将修改后的配置项按入库程序放入配置库。配置管理者按SCCB标识出的修改文件，由波及关系表生成基线变更记录表，并按入库程序放入配置库。4.3配置状态统计利用配置状态统计，可以记录和跟踪配置项的改变。状态统计可用于评估项目风险，在开发过程中跟踪更改，并且提供统计数据以确保所有必需的更改已被执行。为跟踪工作产品基线，配置管理者需手机下列信息：●基线类型●工作产品名称●配置项名称/标识符●版本号●更改日期/时间●更改请求列表●需要更改的配置项●当前状态●当前状态发生日期项目组每周提交配置项清单及其当前版本。配置管理人员每半个月提交变更请求的状态统计。11、项目风险计划下图是本项目的风险计划清单表排序输入风险事件可能性影响风险值风险应对措施1客户的SOW需求不明确，增加需求，导致需求延迟%70%50%35采取加班的方法修改计划去掉一些任务与客户商量时间长一些2合同进度要求紧，合同金额有限%30%50%15可以请一些实习的学生做一些辅助工作，可以加快进度3历史项目信息开发人员对测试工作不重视%30%40%12强制性要求每段代码保留测试单元，由SQA检查加入专业的测试人员4WBS供货商、外包商的质量问题%20%50%10多选择几个可以作为备份的外包商和供应商5历史项目信息开发人员的流动%15%60%9注意项目团队的沟通，及时了解开发人员的动态控制好项目过程中的文档从其他项目组借调人员从外部招聘有过此类开发经验的人员一、规模度量表1：项目规模的度量指标12.度量计划根据企业的质量策略和项目的特点制定本项目度量计划，主要目的是为本项目的控制提供实际数据，以及将来其它项目提供估算依据，表1给出项目规模的度量指标，表2是项目的时间度量指标，表3是需求变更度量指标。任务名称规模度量单位计划实际需求规格说明书文本页数

26

28总体设计说明书HLD页数

13

15系统测试计划文本页数