第五次作业--原型设计（结对）

最新推荐文章于 2024-08-02 11:49:35 发布

dengzhai1963

最新推荐文章于 2024-08-02 11:49:35 发布

阅读量134

点赞数

文章标签：面试 ui php

原文链接：http://www.cnblogs.com/liyuken/p/7577177.html

版权

结队成员:

学号	姓名	性别	分工
031502618	林炜坤	男	学生端原型设计/博客
031502616	李语恳	男	管理端原型设计

为解决同学加入学生会部门时选择部门和课余时间冲突的烦恼，为避免因此浪费不必要的时间和精力，我们需要汇总学生会部门的情况，做一个系统将整个过程信息化，让学生和部门可以双向选择。

困难描述
初次设计原型，缺乏相关经验。
对于原型软件操作使用还不熟悉。
做过哪些尝试
在网上搜寻优秀的UI设计和相关的系统模板，发现都好厉害，想要从中学习借鉴。
是否解决
上手相对来说还是挺快的，但想要做好原型还有很长的路要走。
有何收获

初次原型设计涉水，为以后的挖坑奠定了小小的基础。

设计说明

首先我们考虑以网页形式来呈现这个学生部门管理系统，原型设计平台采用Mockplus（简单易用，适合初次设计，一款挺友好的国产原型设计工具）。
根据需求，在学生和部门的双向选择过程中我们认为需要设计学生端和管理端，学生端面向想要参与报名的学生和下级部员，管理端面向学生会部门的管理者。

N(Need,需求)

在开学初，一方面，部门宣传总要忙着印各种纸质材料，在贴海报、发传单的跑腿活动中浪费大量钱财和精力，另一方面，新生对学生会各个部门都不了解，即使有宣传单或者扫二维码关注微博公众号，也不一定能够面面俱到，信息渠道太少，往往只是靠片面印象，新生们对这些参与部门的过程也知之甚少，相对复杂，缺少一个有效权威的学生会部门信息展示平台，这对部门和学生双方都造成不必要的困扰。
部门对新生的了解几近为无，各种面试也可能产生冲突，双方信息经常产生断层，一个部门学生双向选择的管理系统尤为需要。
对于申请部门的学生筛选规则如下：

部门纳新人数和面试时间必须事先申报确定；
部门活动时间包括常规活动时间（如每周三19点-20点）和临时活动时间，常规活动时间在纳新时候就要公布；
如果一个学生常规部门活动时间请假超过6次，将面临被淘汰；
学生最多加入5个部门，但是要考虑部门活动时间冲突次数；
未参加部门面试的学生不能纳入部门。
A(Approach,做法)

我们首先考虑以Web端网页形式来呈现这个学生部门管理系统，汇集各个部门的详细信息，新生可以方便的在网上进行部门报名，及时得知面试通知和其他活动通知，部门也能够在线上初步筛选报名者，了解学生的具体信息，发布相关公告，提供疑难解答，搭建双方信息沟通网络，减少不必要的沟通活动，提高部门执行效率。

B(Benefit,好处)
极大方便了部门和新生的沟通交流，再也不用总是冒着大热天跑腿印材料宣传，既节省了精力又节省了纸质资源。无形之中，双向选择的效率通过线上互动形式将大大提高，学生能够直观了解部门信息，部门也能够提前清楚学生状况，目前加入学生会部门的迫切需求就体现了这些“被需要”的好处。
C(Competitors,竞争)
目前在学校还并没有这样的学生部门管理系统，有些工作室实现了很多教务或学生工作的功能但至于部门和学生的网络桥梁还未真正搭起来，虽有某在线工作室的存在，我们设计的管理系统还是挺有竞争空间的，这一方面有待开发。
D(Delivery,推广)

在此系统的推广上可能会受到一些阻力，从线下的宣传方式转变成线上需要一个过程，在向学生会部门推广这个系统的同时需要深入新生群体宣传，例如扫二维码，在通知群中推广，让学生部门管理系统融入到学习生活的血液当中。

学生端
登录

学生首页(提供部门列表、部门新闻和其他页面链接)

个人信息(可保存为简历)

部门详细信息(部门简介、部员信息、纳新答疑等等)

在部门页面可提交申请加入(提交简历)

面向部员的通知消息

我的部门界面（含有已入的部门、已报名的部门、已退出的部门）
提供退部的操作

查看申请的进度

退出的部门

我的行程(将部门活动按时间顺序展示，提供查询操作)

活动的请假
管理端
管理首页

点击部门管理进入正头戏
部员管理

活动页面（查看、发布、修改）

活动详情(选择部员的参与、修改活动内容)

简历筛选(简历形式和学生端一样，可以修改申请者的申请进度)

公告通知（查看/修改通知、发布新通知）

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	20
· Estimate	· 估计这个任务需要多少时间	30	20
Development	开发	230	350
· Analysis	· 需求分析 (包括学习新技术)	100	150
· Design Spec	· 生成设计文档	0	0
· Design Review	· 设计复审 (和同事审核设计文档)	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	100	150
· Coding	· 具体编码	0	0
· Code Review	· 代码复审	0	0
· Test	· 测试（自我测试，修改代码，提交修改）	30	50
Reporting	报告	50	100
· Test Report	· 测试报告	5	5
· Size Measurement	· 计算工作量	30	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	30
合计		310	470

第N周	新增代码（行）	累计代码（行）	本周学习耗时(小时)	累计学习耗时（小时）	重要成长
1	300	300	6	6	重拾C++，初学PHP
2	0	0	0	0	学习了原型设计软件的操作及NABCD概念

Thanks For Watching^_^
附件 https://files.cnblogs.com/files/kunza/%E7%AC%AC%E4%BA%94%E6%AC%A1%E4%BD%9C%E4%B8%9A.md.pdf

转载于:https://www.cnblogs.com/liyuken/p/7577177.html

关注