立项

目录

• 辅助教学系统立项说明书
  • 1. 概述
    • 1.1. 项目要求
    • 1.2. 术语
  • 2. 可行性
    • 2.1. 可行性研究的前提
    • 2.2. 复查系统规模和目标
    • 2.3. 研究正在使用的系统
    • 2.5. 进一步定义问题
    • 2.6. 导出和评价供选择的解法
    • 2.7. 推荐行动方案
    • 2.8. 草拟开发计划
    • 2.10. 技术选型
    • 2.11. 过程模型选择
  • 3. 团队成员
  • 4. 分工
    • 4.1. 工做分解结构(WBS)的编制
    • 4.2. PERT时间估算
    • 4.3. 具体分工
  • 5. 质量保障
    • 5.1. 质量管理流程
    • 5.2. 项目质量评审
    • 5.3. 质量检查和确认技术
    • 5.4. 标准和约定

辅助教学系统立项说明书

目录：

修订历史：

日期	版本号	做者	说明
2016-03-23	v1.0	卫重波 杨柳	最第一版本
2016-04-14	v2.0	卫重波	按照立项说明书模板进行增删修改

1. 概述

PCAE^([1])的开发是为了利用我的计算机来帮助师生进行做业管理、相互学习和交流。目前，辅助教学类的软件已有不少，可是适用于单个老师和少许学生的辅助教学系统却很难找到。所以，此项目旨在开发出一个简单、高效、实用的我的计算机辅助教学系统，该系统能上传和发布老师的做业、想法，学生们也能提交做业、查看做业榜、相互评论，老师能够对做业进行评论、打分和统计。

1.1. 项目要求

1. 本系统是一个“我的”计算机辅助教学系统，为一个老师和其约百人规模的学生服务。
   
2. 能系统化的管理做业、项目、想法教学资源。
   
3. 主要功能有：
   • 老师：发点PPT、想法、文章、做业、评论、打分、统计
     
   • 学生：提交做业、看做业排行榜、评论
     
4. 操做方便。简单，实用，不支持多位老师共享平台，不支持链入教务系统等。
5. 并发数100以上。
6. 须要完整的权限控制，防止恶意攻击系统，修改数据的行为。
7. 对数据库中的数据定时备份，防止数据丢失。
8. 完成期限为2016-04-21日。

1.2. 术语

[1] PCAE： 我的计算机辅助教学系统
[2] QA： 质量保证

2. 可行性

2.1. 可行性研究的前提

2.1.1. 要求

1. 功能：本教学辅助系统主要功能有教师、学生的信息化管理、课程信息获取及资源共享。
   
2. 性能：本系统面对的使用者数量较小，并发性要求在100左右；设置必要的安全防范措施，以避免数据被恶意修改；简洁易懂的交互界面。
   
3. 输出：在资源共享部分学生下载课程信息中的课件文件，支持各类已上传类型的文件下载。
   
4. 输入：教师信息，由教师自行注册和管理；学生信息、课程信息，由后台管理员进行新增管理的操做；课件：由授课教师进行上传，数据类型与课件的实际类型为准。

2.1.2. 目标

1. 提升信息资源利用，减小人力与设备；
   
2. 不须要拷课件，提升教学效率；
   
3. 对教学管理系统的改进；
   
4. 管理信息服务的改进；

2.1.3. 条件、假定和限制

1. 系统的运行寿命的很多于3年；
2. 经费、投资方面的来源和限制；
3. 提示免责声明，本系统对使用过程当中的违法犯罪行为不负法律责任；
4. 普通PC电脑，有WEB浏览器，WINDOWS XP/7及以上系统版本，开发环境为MyEclipse和 Mysql；
5. 系统投入使用时间为2016年4月24日

2.2. 复查系统规模和目标

1. 实现一个供一个老师和百余名学生使用的PCAE。
2. 并发数100以上。
3. 系统须要操做方便。简单且实用。
4. 提供上传、下载文件，数据统计、评论等功能。
5. 安全性要求，防止恶意攻击和数据的篡改、丢失。
6. 系统须要练好的灾难恢复机制。
7. 完成期限为2016-04-21日。

2.3. 研究正在使用的系统

2.3.1. 流程简介

1. 教师经过博客发布题目。
2. 学生经过关注教师博客动态得到题目，并发表文章做答，以回复的方式将连接提交。
3. 教师给学生打分，并借助 Excel 表存储和统计分数。

2.3.2. 存在的主要问题

1. 博客是一个开放的平台，但也许教师并不但愿向外部公开教学详情或者一些教学资源。
2. 若是须要上传下载附件，又须要借助其余平台。
3. 没法系统的管理和方便的查找教学资源。
4. 用 Excel 表计分、统计很复杂。
5. 没法保证 Excal 中数据的安全性。

2.4. 新系统的高层逻辑模型

用数据流图来表示新系统的逻辑模型：

• PCAE 顶层DFD 图
  
  
  
  
• PCAE 第二层DFD 图
  

2.5. 进一步定义问题

新系统的逻辑模型已经基本知足用户需求，通过分析员和用户对 DFD 图的复审，发现：
1. 以上设计中缺乏用户身份校验模块
2. 未考虑数据的安全性问题
咱们将在第三层 DFD 图设计中，在以上四大模块中加入相应的校验和数据保护功能。

2.6. 导出和评价供选择的解法

2.6.1 方案一

• 拟建系统的目标
  • 管理一个科目的做业及资料文件
  • 教师上传与共享资源
  • 加快信息的查询速度和准确性
  • 简介的交互界面
  • 并发性知足约50人同时使用
  • 保证数据安全
• 初步方案
  • 采用B/S结构，客户端电脑经过浏览网页的形式与系统进行交互。
  • 教师发布做业与资料，以公告的形式推送给学生。
  • 使用MySQL数据库管理全部的资源信息。
  • 使用 Struts 框架与 JSP 技术实现。

2.6.2 方案二

• 拟建系统的目标
  • 管理多个科目的做业及资料文件
  • 加强资源共享
  • 加快信息的查询速度和准确性
  • 人性化的交互界面
  • 高并发
• 初步方案
  • 采用B/S结构，客户端电脑经过浏览网页的形式与系统进行交互。
  • 学生与老师之间能够进行相似 QQ 空间留言板方式的交流与沟通，符合当前建设信息化校园的理念。
  • 性能上，用比较高性能的服务器和数据库，加强其计算和并发能力
  • 输入输出方面，使用算法在 jsp 视图层上给管理员提供对系统的操做和维护、为教师留下上传接口，给课程配备相关的属性实现下载。
  • 使用 Struts 2框架与 JSP 技术实现。

2.7. 推荐行动方案

2.7.1. 方案描述

1. 在方案一的基础之上：
   • 使用某些措施来增强数据的安全性。
     
   • 优化文件上传、下载速度。
     
   • 严格限定教师和学生的权限。
2. 初步的资料信息处理的 DFD 图：

1. 初步的活动图：
   

2.7.2. 技术可行性

1. 在当前的限制条件下，该系统的功能目标都可以达到预期要求；
2. 利用 Struts 框架与 JSP 技术，该系统的功能能够实现；
3. 开发人员中两人对框架和技术熟练掌握；
4. 合理分配时间，能够在规定的时间内完成开发；

2.7.2. 经济可行性

2.7.2.1. 支出

1. 基建投资
   • 服务器一台 2000 元
   • 数据库系统 1000 元
   • 其它开支 1000 元
2. 常常性支出100元/月。

2.7.2.2. 效益

1. 广告费

1人用1月可产生1元广告费。

2.7.2.3. 收益/投资比

假定：

• 软件的生命期为3年；
• 平均每个月有500人次的使用量

总支出：2000元 + 1000元 + 1000元 + 100元/月 * 3 * 12月 = 7600元
总收益：1 元/人月 * 3 * 12月 * 500人 = 18000元

收益投资比：18000元/7600元 = 45/19 ≈ 2.3684

2.7.2.4. 投资回收周期

设回收周期为X，单位为月，则有：

1元/人月 * 500人 * X = 7600元，X = 15.2月，即约在在一年零3个月后进入投资回收期。

2.7.2. 操做可行性

该系统有以下特色：

• 系统采用菜单式实现用户与数据库的交互
• 界面简洁
• 菜单条目简单明了
• 关键的操做部分有传统惯用的标识符
• 全部功能严格划分界限，用户不会步入复杂的功能选择中。

基于以上特色，该系统的可操做性和常见的 windows 系统中的简单 Web 页面相似，符合用户的操做习惯。

2.8. 草拟开发计划

2.8.1. 工程进度表

阶段	主要工做	时间段
需求分析	收集用户需求	3/20 ~ 3/20
	验证项目可行性	3/21 ~ 3/21
	制定项目初步计划
	肯定系统功能及性能要求	3/22 ~ 3/23
	编写用户手册概要	3/24 ~ 3/24
	讨论并决定开发计划
	编写立项说明书	3/25 ~ 3/26
	编写需求说明书
概要设计	创建系统整体结构，划分功能模块	3/27 ~ 3/27
	定义各功能模块接口
	数据库设计	3/28 ~ 3/28
	制定组装测试计划	3/29 ~ 3/29
	对已完成的文档进行评审
	设计各模块具体实现算法	3/30 ~ 3/30
	肯定模块间详细接口	3/31 ~ 4/1
	制定模块测试方案
	编写程序源代码	4/2 ~4/7
	进行模块测试和调试	4/8 ~ 4/9
	编写用户手册	4/9 ~ 4/9
	集成测试	4/10 ~ 4/14
	编写集成测试报告	4/15 ~ 4/15
	测试整个软件系统	4/16 ~ 4/19
	编写开发总结报告	4/20 ~ 4/21

2.8.2.人员

2.10. 技术选型

2.10.1. 表现层：JSP

使用Java开发Web项目在表现层上占比最大的仍是JSP了。一方面，在以前的J2EE课程中已经接触过了JSP，而且以前的不少web项目的开发训练也都使用的JSP，组内成员对该技术都比较熟练；另外一方面，JSP的功能十分强大，整个项目的资源均可以经过它轻松访问，它也十分适合于该项目表现层的实现。

2.10.2. 控制层：Struts

两方面的缘由：

1. Struts框架功能全面，有着普遍的群众基础，网上的相关资料也不少。
   
2. 组内开发人员比较熟悉。

2.10.3. 数据持久层：Hibernate

主要缘由是该框架的下面的这些优势：

1. Hibernate充分体现了ORM的设计理念，提供了高效的对象到关系型数据库的持久化服务。
   
2. 它将持久化服务从软件业务层中彻底抽取出来，让业务逻辑的处理更加简单，更加有利于高效地开发和维护。
   使开发人员在程序中能够利用面向对象的思想对关系型数据库进行持久化操做。

2.11. 过程模型选择

瀑布模型。

1. 该软件的功能更需求简单明确，需求→分析→设计→编码→测试 各个阶段工做量较小，对于每一个阶段，都可以有时间完整的规划和完成。
2. 项目开发时间有限，采用瀑布模型并明确设定每一个阶段的截止时间，可以确保项目在规定时间内顺利完成。
3. 将功能的实现与设计分开，更便于组内成员的分工协做。
4. 每一个阶段全部人都参与，便于查缺捡漏和结合全部人的智慧。

3. 团队成员

角色	姓名
项目组长	祖庆庆
项目成员	杨浪
项目成员	卫重波
项目成员	杨柳
项目成员	李鑫
项目成员	何磊
项目成员	邹纯鑫
项目成员	高扬

4. 分工

4.1. 工做分解结构(WBS)的编制

4.2. PERT时间估算

1. 利用相似法，从网上搜集与之相似的项目的花费人时做为参考。
2. 当前的项目的复杂性较以前的简单。没有外部系统接入、课程共享等比较复杂的功能。
3. 当前团队人数为8人。

• T₀(乐观时间)
• T_m(最可能时间)

• T_p(悲观时间)

• 指望时间 = (T₀ + 4T_m + T_p) / 6

4.3. 具体分工

任务	截止时间	人员
需求分析报告	2016-3-26	全员
总体页面设计	2016-4-1	祖庆庆 何磊 李鑫 卫重波
各个模块网页连接	2016-4-10	祖庆庆 何磊 李鑫 杨柳 杨浪 高扬
创建数据库并录入数据	2016-4-12	杨浪 邹纯鑫 高扬
数据库的验证	2016-4-15	祖庆庆 卫重波 李鑫
数据库链接测试	2016-4-15	杨浪 邹纯鑫 高扬 何磊
网页链接调试	2016-4-17	祖庆庆 卫重波 李鑫 杨柳
系统测试	2016-4-20	全员

5. 质量保障

5.1. 质量管理流程

5.1.1. 交付文档质量监控流程

1. 项目经理和QAE^([2])在项目初期对项目交付文档的模板进行检查和审核，确保项目交付品的架构和内容大纲的完整性和正确性。
2. 在项目进行过程当中，QA、项目经理及各项目功能小组组长会分别对交付品进度和质量进行监控，确保在最后的项目完成阶段，客户对提交的交付文档能有满意的反馈。

5.2. 项目质量评审

1. 该系统质量监控将采用平常质量监控流程与按期质量评审制度。
2. 平常质量监控程序经过制定系统开发的统一的规范、流程、指南、模板等指导项目的开发过程，并监控这些流程和规范的执行状况，以确保全部交付品的质量。
3. 项目质量评审报告将根据各阶段质量检查点所应检查的内容做出质量上的评审。对在质量评审工做中发现的问题，将根据其性质、范围划分级别。相关人员以此为依据来肯定缺陷修复的优先级，缺陷严重程度高的修复优先级也高。
4. 项目质量评审报告将交由项目管理办公室讨论，质量保证经理与项目管理办公室将对项目质量评审报告中须要明显改善的质量问题做出具体地改进方案，以及时间上和人员上的安排。

5.3. 质量检查和确认技术

5.3.1. 工具和技术

项目管理软件：@Team
网站测试：host-tracker.com

5.4. 标准和约定

5.4.1 基本文档

• 立项说明书
• 软件需求规格说明书
• 概要设计
• 详细设计
• 软件测试计划
• 软件测试报告
• 开发总结

5.4.2 文档质量的度量准则

• 完备性：应按照GB8567的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的
• 正确性:在软件开发各个阶段所编写的文档的内容，必须真实的反映阶段的工做且与该阶段的需求相一致
• 简明性:在软件开发各个阶段所编写的各类文档的语言表达应该清晰、准确简炼，适合各类文档的特定读者
• 自说明性：在软件开发各个阶段所编写的各类文档应该具备较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不一样文档能独立表达该软件其相应阶段的阶段产品的能力。
• 规范性：在软件开发各个阶段所编写的各类文档应该具备良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。

5.4.2 代码规范

遵循java代码规范