2。1。3 时间可行性

此系统从2017年4月启动开发，将近2个月的开发时间，加上自己有一定的开发经验，在时间可行性上是没有问题的。

2。2 需求分析

本系统是本人自发开启的一个系统，按照自己的项目经验对考勤系统的理解确定的基本需求。此系统最重要是权限控制，分不同权限角色，视角也不同。校领导拥有最高权限，可管理全校事项，但是校领导是宏观上的查看管理；院领导拥有对应学院最高权限，可管理全院事项，仍然是宏观上的管理；班级老师和班长拥有对应班级管理权限，可对负责班级做细节管理，但是班主任可管理班长，班长不能管理班主任。

2。2。1 院校领导权限确认

确定对象：成都理工大学冷主任（经我手上的一个项目和成都理工大学冷主任有联系，所以约了冷主任一个小时时间座谈关于院校领导权限事项进行咨询。）

确定需求如下：论文网

1：院校领导关于考勤系统的视角：整体把控，对细节不关心。

2：操作权限：发布公告、查看出勤记录（宏观）、管理院校领导（分上下级关系管理）

注：不关心细节，这很重要，区分关注点，不管理任课老师、单独学生。

2。2。2 老师权限确认

确定对象：大学班主任（班主任最熟悉具体事务）。

确定需求如下：

1：老师具有管理班级所有学生权限，以班级为单位，老师具有最高权限

2：老师可以对学生的出勤记录做增删改查操作。其中删除权限比较敏感，所以做二次提示“是否删除”；修改操作应在记录当天20点以前完成，过后不允许再修改，如果随时都可以修改就会造成院校领导查看总体出勤记录时出现信息不准确的情况，所以规定20点之后不再有修改权限。20点之后信息为存档信息

3：班主任可以给所管理班级的学生发送特定通知，老师可以在和我相关模块查看我发送的通知，学生可以在和我相关模块接收关于自己的通知。

4：班主任如果发送一个任务给学生，快到最后期限时，班主任可以催办学生完成任务。

5：如果班主任太忙，可以将出勤记录的修改和删除操作权限下放给班长，可以下放就可以收回权限。

2。2。3 班长权限确认

确定对象：周环（班长）

确定需求如下：

1：具有管理所属班级出勤记录权限，可进行增、删、改、查等操作，增加缺勤记录和查看缺勤记录是班长本身就有的权限，但是删除和修改权限是需要班主任下放给班长后才有对应权限。

2：可发送班级通知，此时会通知班主任，但是班主任并不是接收者，相当于邮件抄送。 

2。2。4 普通人权限确认

确定对象：学生

确定需求如下：

1：学生为最低权限，只能查看自己的缺勤记录

2：可以接收到和自己相关的通知

2。3 运行环境

2。3。1 软硬件环境

语言：java

操作系统：android

数据库：SQLite

2。3。2 网络环境

互联网

3。总体设计

3。1 设计思想

整体框架如图3-1整体架构图所示：

图 3-1 整体架构图文献综述

后端从老系统采用接口的方式拿数据，但是目前没有老系统支持，所以暂时在新系统中填入有规范的假数据。移动端采用post http请求获取数据。

3。2 系统划分和功能描述

分为后端和移动端，后端负责数据存储，移动端负责取数据展示。view层为视图层，负责和界面交互，与控制层唯一联系，通过接口实现交互；model为业务逻辑层，其实我更愿意叫它数据和结构层，存放基础数据和基础结构等底层数据，与控制层联系交互；controller为控制层，是视图层和业务逻辑层的纽带。