文章目录
引言
目的与背景
本文档旨在说明本项目高校教学系统的实施及验收工作，包括明确验收后的维护模式、维护过程整个实施环节的步骤和进度。
本项目组成员将按照本计划开展相关工作，同时项目经理也将按照本计划进行有效管理，最终保证项目达到维护要求。
术语（名词解释）
-
系统维护：为了清除系统运行中发生的故障和错误，软、硬件维护人员要对系统进行必要的修改与完善；为了使系统适应用户环境的变化，满足新提出的需要，也要对原系统做些局部的更新，这些工作称为系统维护。
系统维护的任务是改正软件系统在使用过程中发现的隐含错误，扩充在使用过程中用户提出的新的功能及性能要求，其目的是维护软件系统的"正常运作"。这阶段的文档是软件问题报告和软件修改报告，它记录发现软件错误的情况以及修改软件的过程。 -
项目风险管理计划：是制定风险识别、风险分析、风险减缓策略，确定风险管理的职责，为项目的风险管理提供完整的行动纲领。是确定如何在项目中进行风险管理活动，以及制定项目风险管理计划的过程。本计划主要针对项目开发涉及到的风险，包括在项目开发周期过程中可能出现的风险以及项目实施过程中外部环境的变化可能引起的风险等进行评估。
-
软件维护：是一个软件工程名词，是指在软件产品发布后，因修正错误、提升性能或其他属性而进行的软件修改。主要是指根据需求变化或硬件环境的变化对应用程序进行部分或全部的修改。其活动类型有四种：纠错性维护（校正性维护）、适应性维护、完善性维护或增强、预防性维护或再工程。除此四类维护活动外，还有一些其它类型的维护活动，如：支援性维护（如用户的培训等）。针对以上几种类型的维护，可以采取一些维护策略，以控制维护成本。
特别约定
无。
预期读者
| 预期读者 | 主要关注点 |
|---|---|
| 项目组成员 | 工作任务、维护周期、系统维护成果、系统维护周期划分 |
| 项目经理 | 工作任务、维护周期、系统维护成果、项目组织/职责/资源 |
| 教师 | 系统维护成果、维护周期、项目组织/职责/资源、软件维护问题记录 |
| 用户 | 系统维护成果 |
参考文献
-
Early Approach to Software Engineering, Pallavi Gore, Kritika Saxena.
-
Practical File of Software Engineering and Testing Laboratory, Aakash Raj.
-
Software Engineering, Principles and Practice, 3rd Edition, Hans van Vliet.
-
Program Manager’s Guidebook for Software Assurance, Dr. Kenneth E. Nidiffer,
Timothy A. Chick, Dr. Carol Woody. -
Experimentation in Software Engineering, Claes Wohlin, Per Runeson, Martin
Host, Magnus C. Ohlsson, Bjorn Regnell, Anders Wesslen. -
IEEE Computer Society/Software Engineering Institute Software Process
Achievement (SPA) Award 2009, Satyendra Kumar, Ramakrishnan M. -
Michael Felderer, Wilhelm Hasselbring, Rick Rabiser, Reiner Jung: Software
Engineering 2020, Fachtagung des GI-Fachbereichs Softwaretechnik, 24.-28.
Februar 2020, Innsbruck, Austria. LNI P-300, Gesellschaft für Informatik
e.V. 2020, ISBN 978-3-88579-694-7. -
Regina Hebig, Robert Heinrich: Combined Proceedings of the Workshops at
Software Engineering 2020 Co-located with the German Software Engineering
Conference 2020 (SE 2020), Innsbruck, Österreich, March 05, 2020. CEUR
Workshop Proceedings 2581, CEUR-WS.org 2020. -
Steffen Becker, Ivan Bogicevic, Georg Herzwurm, Stefan Wagner: Software
Engineering and Software Management, SE/SWM 2019, Stuttgart, Germany,
February 18-22, 2019. LNI P-292, GI 2019, ISBN 978-3-88579-686-2. -
Stephan Krusche, Kurt Schneider, Marco Kuhrmann, Robert Heinrich, Reiner
Jung, Marco Konersmann, Eric Schmieders, Steffen Helke, Ina Schaefer,
Andreas Vogelsang, Björn Annighöfer, Andreas Schweiger, Marina Reich, André
van Hoorn: Proceedings of the Workshops of the Software Engineering
Conference 2019, Stuttgart, Germany, February 19, 2019. CEUR Workshop
Proceedings 2308, CEUR-WS.org 2019. -
Peter Liggesmeyer, Gregor Engels, Jürgen Münch, Jörg Dörr, Norman Riegel:
Software Engineering 2009: Fachtagung des GI-Fachbereichs Softwaretechnik
02.-06.03. 2009 in Kaiserslautern. LNI P-143, GI 2009, ISBN
978-3-88579-237-6. -
Jürgen Münch, Peter Liggesmeyer: Software Engineering 2009 - Workshopband,
Fachtagung des GI-Fachbereichs Softwaretechnik 02.-06.03.2009 in
Kaiserslautern. LNI P-150, GI 2009, ISBN 978-3-88579-244-4. -
《软件工程——实践者的研究方法》，Roger S.Pressman，机械工业出版社
-
《软件需求（第三版）》，Karl Wiegers，Joy Beatty，清华大学出版社
-
《计算机软件产品开发文件编制指南》（GB 8567-88）
-
Information Technology Project Management, Second Edition, Kathy Schwalbe,
Course Technology. -
Successful Project Management, Gido, J. and Clements, J. South-Western
Publishing. -
On Time and Within Budget: Software Project Management Practices and
Techniques, 3rd Edition, Bennatan, E., Wiley. -
Software Project Management: A Unified Framework, Walker Royce,
Addison-Wesley. -
IS Project Management Handbook, Doss, G., Prentice Hall.
-
CMMI: Guidelines for Process Integration and Product ImprovementMary Beth
Chrissis, Mike Konrad, Sandy Shrum. -
CMMI® Distilled: A Practical Introduction to Integrated Process Improvement,
Second Edition, By Dennis M. Ahern, Aaron Clouse, Richard Turner. -
CMMI® SCAMPI Distilled Appraisals for Process Improvement, By Dennis M.
Ahern, Jim Armstrong, Aaron Clouse, Jack R. Ferguson, Will Hayes, Kenneth E.
Nidiffer. -
军用软件能力成熟度模型可重复级实施指南，石柱，中国标准出版社
-
战略管理(原书第6版)，Greey Johnson & Kevan Scholes，王军等译，人民邮电出版社
-
复杂产品系统创新管理，陈劲，科学出版社
-
Product Management，4thedition，Donald R. Lehmann & Russell S.
Winer，McGraw-Hill Companies，Inc. -
基于ITIL®的IT服务管理基础篇，Jan van Bon，章斌译，清华大学出版社
-
创新管理-获取持续竞争优势，宁钟，机械工业出版社
-
软件编档导论，金波，清华大学出版社
-
计算机软件工程规范国家标准汇编，中国标准出版社
-
《“软件需求工程”教学安排 20200926》
-
《[G25]“高校教学平台”项目可行性报告》
-
《[G25]“高校教学平台”项目章程》
-
《[G25]“高校教学平台”项目计划》
-
《[G25]“高校教学平台”需求工程计划》
-
《[G25]“高校教学平台”前景与范围》
-
《[G25]“高校教学平台”质量保证计划》
-
《[G25]“高校教学平台”软件需求规格说明书》
-
《[G25]“高校教学平台”软件需求规格说明书 更新版》
-
《[G25]“高校教学平台”系统设计计划》
-
《[G25]“高校教学平台”系统编码与实现计划》
-
《[G25]“高校教学平台”测试计划》
-
《[G25]“高校教学平台”需求变更控制文档》
-
《[G25]“高校教学平台”用户手册》
-
《[G25]“高校教学平台”需求变更控制会规程》
-
《[G25]“高校教学平台”工程部署计划》
-
《[G25]“高校教学平台”测试报告》
-
《[G25]“高校教学平台”软件概要设计说明书》
项目实施及验收简介
系统概述
本网站主要面向的用户群体是本校的教师、助教、学生、游客，主要功能有：信息的发布与获取、资料的共享、作业成绩的评定、沟通交流、用户权限和信息管理等。开发、测试和运行环境如下表：
| 开发环境 | Intel CPU，Windows 8 系统 /Intel CPU，Windows 10 系统/Intel CPU，Mac OS 系统。 |
|---|---|
| 测试环境 | Intel CPU，Windows 8 系统 / Intel CPU，Mac OS 系统 |
| 运行环境 | 服务器：Intel CPU，Linux Ubuntu 20.04 系统 客户端：能联网的 PC |
项目属性
| 项目名称 | 高校教学系统 |
|---|---|
| 项目类型 | B/S |
| 项目周期 | 三个月 |
| 项目客户 | 高校教师、助教、学生、管理员，游客 |
| 应用领域 | 教学辅助 |
| 采用的语言 | HTML、CSS、JavaScript、Node.js、python |
| 采用的数据库 | Mysql |
| 软硬件平台 | Intel CPU，Windows 8/10，Mac OS |
| 项目经理 | xxx |
| 团队规模 | 6个人 |
| 项目工期 | 三个月 |
| SQA人员 | 项目组全体人员 |
| SCM人员 | 项目组全体人员 |
| 开发组成员 | xxx |
| 测试组成员 | xxx |
| 本报告维护人员 | xxx |
| 本报告填写时间 | 2021/1/6 |
工作任务
-
系统应用维护：
系统的应用程序维护是系统维护的重要内容。因为对于高校教学平台的系统维护，一旦功能发生变化，出现问题和业务更新，就需要对程序进行修改和迭代。除此之外，为了后续的维护能够进行下去，开发团队需要将更新内容写到培训手册等相关的文档。因此，应用维护是开发团队致力于对系统维护的部分。
-
数据维护：
在本高效教学平台的运行过程中，有大量的数据将会被新增、修改、覆盖。数据维护包括数据内容的维护（无错漏、无冗余、无有害数据）、数据更新、数据逻辑一致性等方面的维护。而数据维护通常关联到数据库的维护，因此具体内容如下：
-
数据库的备份：在创建数据库后卸出，以为之后的备份提供装入基点。并且在之后定期周期表卸出。
-
事务日志的备份：日志与数据库系统运行在不同设备上。由于事务日志的备份周期会影响数据的恢复程度，因此每天备份。
-
数据库的恢复：如果数据库所在设备故障毁坏，则卸出数据库。并在另一运行正常的新设备上初始化并创建数据库，装入新的数据库。
-
只有数据库的所有者有此卸出数据库和事务日志缺省的权限，并且能传递此权限给其他用户。
-
数据安全的保证：系统管理员根据系统的实际运行情况，执行一系列的安全保障措施。在本项目中，多使用周期地更改用户口令的方式保障安全。
-
-
代码维护：
代码维护是指对原有的代码进行的扩充、添加或删除等维护工作。随着系统应用范围的扩大、应用环境的变化，系统中的各种代码都需要进行一定程度的增加、修改、删除，以及设置新的代码。并且系统由多人共同开发，因此团队将使用GitHub作为代码控制工具。
-
硬件设备维护：
本项目的硬件设备多为用户自己的3C设备。对于系统开发人员的硬件设备将根据开发人员在运行过程的硬件问题，对设备进行更新修护。
维护周期
出于对系统整体情况、维护对象、维护工作的复杂性与规模等因素考虑，小组制定了系统维护周期表，用于系统维护。
| 维护内容 | 维护周期 | |
|---|---|---|
| 系统应用维护 | 学生使用功能 | 一周 |
| 教师使用功能 | ||
| 游客使用功能 | ||
| 管理员使用功能 | ||
| 数据维护 | 数据库 | 一周 |
| 事务日志 | 三日 | |
| 代码维护 | 代码注释、版本管理等 | 至少一月一次 |
| 硬件设备维护 | 一月 |
系统维护成果
对客户的交付成果：满足用户对项目合理新需求的网站系统
对课程的交付成果：《系统维护计划》、《程序修改登记表》、《程序变更通知书》、《软件维护问题记录表》
项目组织、职责及资源
客户项目组信息
| 姓名 | 角色 | 联系电话 | 电子邮件 |
|---|---|---|---|
| 邢卫 | 项目发起人 | 13958030163 | wxing@zju.edu.cn |
| 林海 | 项目发起人 | lin@cad.zju.edu.cn | |
| 金波 | 项目发起人 | jb21cn@zju.edu.cn | |
| 邵健 | 项目发起人 | 0571-87951277 | jshao@cs.zju.edu.cn |
维护组信息
| 姓名 | 角色 | 联系电话 | 电子邮件 |
|---|---|---|---|
| 博主本人 | 项目经理 设计总监 开发人员 测试人员 | xxx | ZJU.SLM@gmail.com ZJU_SLM@studentambassadors.com |
| xxx | 软件质量监督 开发人员 测试人员 | xxx | xxx |
| xxx | 设计总监 美工 开发人员 测试人员 | xxx | xxx |
| xxx | 测试经理 开发人员 测试人员 | xxx | xxx |
| xxx | 质量经理 开发人员 测试人员 | xxx | xxx |
| xxx | 产品经理 开发人员 测试人员 | xxx | xxx |
系统维护周期划分
软件升级计划
| 时间 | 软件版本 | 说明 |
|---|---|---|
| 2020.12.20 | V2.0 | 需求变更控制，完成《 需求变更控制会规程》文档。 |
成本计划
| 成本项 | 成本费（元） |
|---|---|
| 技能培训 | 100 |
| 需求管理 | 350 |
| 项目管理 | 200 |
| 功能维护 | 100 |
沟通计划
| 沟通方式 | 参与人员 | 沟通对象 | 沟通时间 | 沟通内容 | 负责人 |
|---|---|---|---|---|---|
| 组会 | 项目组成员 | 项目组成员 | 每周二21:00-22:00 | 项目进展 文档分工 | 项目经理 |
| 需求访谈 | 项目组成员 用户代表 | 用户代表 | 共三次 10.31 13:15-13:45 11.28 13:15-13:45 12.26 13:15-13:45 | 需求开发 需求维护 | 项目经理 |
风险管理计划
风险评估
| 风险描述 | 风险后果 | 风险评级 | |
|---|---|---|---|
| 需求获取 | 产品前景不明确 | 项目目标未实现 | 高 |
| 项目范围不明确 | 项目目标未实现 | 高 | |
| 开发计划不明确 | 未按时交付 | 高 | |
| 需求规格说明不完整 | 项目组成员需求认知不一致，开发中有矛盾 | 高 | |
| 非功能性需求不完整 | 用户体验感差 | 高 | |
| 客户调研无效 | 用户需求未满足 | 高 | |
| 客户调研夸大 | 项目实现偏离目标，过片面化 | 中 | |
| 参考资源不正确 | 项目目标未实现 | 高 | |
| 需求分析 | 需求优先级不明确 | 开发迭代过程未满足 | 中 |
| 技术可行性未实现 | 开发失败 | 高 | |
| 需求规格说明 | 内容不正确 | 项目目标未实现 | 高 |
| 内容不完整 | 项目目标未完全实现 | 高 | |
| 内容不明确 | 开发困难，与项目目标偏离 | 中 | |
| 需求确认 | 未确认 | 导致需求有误 项目目标未实现 | 高 |
| 需求审查不准确 | 可能与项目目标偏离 | 中 | |
| 需求管理 | 需求变更过程不正确 | 项目目标未实现 | 高 |
| 需求范围扩大或缩小 | 可能导致开发不完善 | 中 | |
| 时间不充裕 | 项目目标未实现 | 高 |
风险控制
| 风险描述 | 控制方法 | |
|---|---|---|
| 需求获取 | 产品前景不明确 | 项目前期编写指导文档，明确产品前景，如《项目章程》、《前景与范围》。 |
| 项目范围不明确 | 项目前期编写指导文档，明确项目范围，如《项目章程》、《前景与范围》。 | |
| 开发计划不明确 | 项目前期编写指导文档，明确开发计划，如《项目总体计划》、《项目章程》；开发计划需安排合理，明确开发各阶段所需的时间。 | |
| 需求规格说明不完整 | 项目前期编写《软件需求规格说明书》，并得到项目组成员一致认可。 | |
| 非功能性需求不完整 | 《软件需求规格说明书》中涵盖非功能性需求及其验收标准。 | |
| 客户调研无效 | 挑选合适用户，采用产品代言人的方法，保证足够的客户代表及其对需求的权威规划决策；编些逆向工程提炼出的需求文档给客户评审，确保相关性、准确性。 | |
| 客户调研夸大 | 识别用户假设，及时沟通，反复确认； 提出开放性问题鼓励客户分享，精确提炼真正期望。 | |
| 参考资源不正确 | 选取权威性的参考资源。 | |
| 需求分析 | 需求优先级不明确 | 为每个需求设立优先级并对其评估。 |
| 技术可行性未实现 | 评估每个需求的可行性、所需技术及其难度，撰写《项目可行性报告》；针对较难技术或新技术采取合适的学习曲线进行掌握。 | |
| 需求规格说明 | 内容不正确 | 开发人员、测试人员、客户都对需求规格书进行评估，并记录负责人信息与日期，达成一致认可。 |
| 内容不完整 | 开发人员、测试人员、客户都对需求规格书进行评估，并记录负责人信息与日期，达成一致认可。 | |
| 内容不明确 | 创建数据字典等定义术语，帮助明确。 | |
| 需求确认 | 未确认 | 项目前期确认需求，撰写《质量保证计划》。 |
| 需求审查不准确 | 审查前对涉及人员进行培训，使用经验人员或专业顾问进行审查。 | |
| 需求管理 | 需求变更过程不正确 | 撰写《需求变更控制会规程》与《需求变更控制文档》，对每个变更进行影响分析，组织变更控制委员会做出抉择。 |
| 需求范围扩大或缩小 | 使用需求变更矩阵；推迟实现可能发生变更的需求。 | |
| 时间不充裕 | 项目前期对需求变更维护留有时间。 |
软件维护问题记录
用户将提出的所有问题记录在软件维护记录表中，软件维护记录表示例如下。
| 项目名称 | 编号 | 日期 | |||
|---|---|---|---|---|---|
| 用户信息 | |||||
| 问题描述 | 问题程度 | 记录人 | |||
| 原因分析 | 故障 | ||||
| 非故障 | |||||
| 处理意见 | 负责人 | 日期 | |||
| 解决结果 | 解决人 | 日期 |