结对成员
170320075 解哲
170327078 张合胜
PDF文件
https://files.cnblogs.com/files/xiezhe1204/原型1.pdf
学生会部门纳新的现状与改善方向
现有的部门纳新都是以纸质表单为基础的。这样做的好处是内容正式，条理清晰，但是缺点也是显而易见的。例如，信息汇总不及时，不准确，无法直观的判断各个部门间的活动安排情况，信息发布不及时，信息获取渠道少，档案丢失率高等。
上述一些缺点是目前传统办公中比较普遍的现象。而采用数字化的处理流程和数字化的管理方法就能够比较好的保持信息的完整性和时效性，从而提高学生会纳新的效率和对学生会部门成员管理的效率，同时使考勤评价数字化，精确化。
本系统整体架构如下所示：
|---学生会
|---A部门
|---申请入会
|---申请成功
|---申请失败
|---请假
|---请假成功
|---B部门
...
-
1 N（Need）需求
本系统可以解决用户面临的流程繁琐问题。尤其是现有流程中关于考勤和活动时间冲突的判定和处理等费时费力的工作都可以通过本系统快速准确的完成。相应的，为了满足流程尽可能的简单，且不产生多余的数据。在申请人填写报表前无需登陆，系统只需要通过申请人填写报表的唯一学号来区别用户。在后续筛选完申请人之后，再要求入围学生完善信息。这样做的好处是简单化注册流程，提高申请人的积极性。另一方面，这样做使得系统储存更少的多余数据，并减少系统的复杂度。
新生申请入会时，不需要登录，直接进入x部门填写个人信息后提交。
学生会主界面：
A部门主界面：
填报个人信息页面：
-
2 A（Approach）做法
用户主要的担心在于不熟悉新系统的流程和对旧流程的依赖。我们的申请处理系统提供给申请人免登录的申请方式。可以提供给用户更便捷的流程，减少申请中因为注册问题带来的混乱。在申请入部时，我们拒绝或警告申请人对于不同部门中活动时间相同的同时申请。在后续流程----考勤中，我们通过用户页面实时反应给部员请假次数。
先申请部门不与已申请的其他部门例会时间冲突则提交成功，否则失败
提交个人信息成功页面：
提交个人信息失败页面：
申请请假页面：
-
3 B（Benefit）好处
本系统为用户带来数字化的申请流程，简化了传统流程中的汇总所需的工作量，并对部员的考勤进行数字化的管理，使得部员对自身学生会参与程度有直观的理解，督促部员参与学生会。对于部门负责人，可以横向的对比本部部员的出勤情况，加强对本部的管理效率。由于申请人申请失败之后的数据是无用的，再者为了简化申请人的申请流程，采用无登陆填写信息，提高申请效率。
成为学生会成员之后，需要登录来获取更多权限：
-
4 C（Competitors）竞争
管理系统的使用现在已经非常的普遍了，而如何让用户快速的接受系统便成为一种加强竞争力的重要手段。由于本系统面向的用户是学生会，所以是一种小型的管理系统，且流程相对简单。而本队的优势在于有快捷的申请流程，实时的信息展示。而在其他传统系统中存在的诸如的申请人处理，用户信息展示等方面本系统也有相关功能。而我们的劣势在于部门种类的维护和申请人的信息的修改还没有涉及到，我们主要考虑到的是这些流程或者功能是非核心的，可以在后续维护中逐步完善。
-
5 D（Delivery）推广：
我们的产品拥有简单易懂的流程，方便的使用环境，并且我们提供详尽的用户文档来帮助用户更好的来理解和使用此系统。使用网页访问方式，用户只需登陆特定网站便可完成一切操作。无需安装，无需关心配置。使用网页访问方式，我们可以获得比客户端系统更广泛的推广途径，以求获得更多的用户，更广泛的应用范围。
-
讨论原型设计：
-
效能分析：
此次工作的目标是设计出系统原型，我与结对同学共同参与完成了系统的原型设计工作，在这一过程中，我们通过QQ进行了多次交流，发现通过文字交流效率低下，于是在周一上午进行了一次面谈，大约持续了2个小时。在这期间，我们共同商讨了本次的任务和原型系统的核心功能和流程。在周一晚上我们汇总了彼此的工作成果，并加以讨论并优化，基本完成了本次作业的要求。
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 30 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 30 | 20 |
| Development | 开发 | ||
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 150 |
| · Design Spec | · 生成设计文档 | 60 | 100 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 60 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
| · Design | · 具体设计 | 100 | 120 |
| · Coding | · 具体编码 | ||
| · Code Review | · 代码复审 | ||
| · Test | · 测试（自我测试，修改代码，提交修改） | ||
| Reporting | 报告 | ||
| · Test Report | · 测试报告 | ||
| · Size Measurement | · 计算工作量 | ||
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | ||
| 合计 |