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

结对成员

031502516 李佳莹
031502528 苏媛

PDF

PDF文件地址

原型设计工具

最先我们是先尝试了GUI Design Studio，究其原因是我看一些人的评价说是它较为简单一点。就下载的角度来说它倒是确实不难，但在我们开始在网上寻找它的使用教程和自主钻研的时候，我才真正地意识到了小马过河故事的意义所在。小马在自己下河走之前不会知道河水到底有多深，而我们在亲自使用之前也永远不会明白一个软件到底适不适合自己。
总之在下完它之后我们一筹莫展了良久，主要问题在于我们的英文水平不够，无法很好的理解每一个功能和按键，而网上又很难找到比较有亲和力的教程视频，所以最后我们选择换一个工具使用。
这次选用的是Mockplus，是在好友的倾情推荐下开始接触的。不得不说语言真的是一个巨大的鸿沟，跨越了之后的使用感觉较之前真的是轻松了不少。这款原型设计工具使用前需要先注册账号，并不是冗杂的举动，在注册后会收到官方发来的邮件，里面有着该工具的使用教程链接，可以说是非常贴心了。将它与先前下的GUI Design Studio做对比的话，个人感觉优势最大之处是在页面链接时，Mockplus可以直接用鼠标连过去，相较起来真的是显得格外便利。

NABCD模型

• N（Need，需求）

  从本次题目中可以看出，我们总共有两种客户，一个是普通的，需要加入部门的学生，另一个则是部门里负责招生的那一部分管理员。
  从困扰的现状中，我们可以看出，学生最大的难题是无法集中地获得各部门的活动时间，从而导致了个人的时间安排不畅，平白浪费了时间与精力。所以对于一个刚步入校园，想要加入部门的新生来说，他的需求就主要表现在对各部门信息的获取上。
  而对于各纳新部门的负责人来说，他们手工发放申请表，手工汇总，再人工通知时间信息，太过混乱，所以需要一种更简便，更省时省力的信息处理手段。

• A（Approach，做法）

  我们可以建立一个网站，提供一个平台为客户获取信息。

• B（Benefit，好处）

  学生可以在上面获取自己想要的部门信息，如果有了想要加入的部门，也可以直接点击申请。他们还可以在上面看到自己所面临的面试和部门活动的时间地点，一目了然，不会出现因为遗忘或者疏忽而导致时间相碰无法处理的情况。
  而负责纳新的部门管理员则可以在上面发布自己部门的简介，在未来的部门活动中，也可以发布临时通知，从而能够统一告知部员临时活动等事情的具体信息。学生可以在上面直接报名，因此负责人也不再需要手工发放宣传单和报名表。非常直接地在物力人力方面免去了他们很大一部分负担。

• C（Competitors，竞争）

  呃，现在的竞争对手基本上应该是班里其他的结对CP 了。要论我方小组的优势的话，可能就是我们特别情比金坚了，我们将报名的手续最大的简化。只需让学生一次性在个人信息页面将基础信息填好，报名时就只要在报名页面点击报名按钮即可，无需重复填写报名表单。
  会有这样的想法，主要是当一个人报名多个部门时，报名表上的很大一部分基础信息都是重复的，反复填写这些信息很容易令人产生厌倦情绪，这极有可能会提前结束了部分学生探寻适合自己部门的步伐，在纳新期过去之后才觉得自己错过良多，这就很可惜了。嗯，当然，更主要的是，我们设计这个原型系统，最大的目标本就是能够将这段流程进行简化，能够让用户少动一点手，总归是没有坏处的。
  这个做法也可能会出现一点弊端，比如每个部门获取到的信息相同，没有差异性。但这个问题可以很轻易的在面试环节中更一步了解到，所以我们认为，瑕不掩瑜。

• D（Delivery，推广）

  理论上来说，推广一个用于学生与部门之间的产品，首先要从部门开始入手，部门接受了这个产品，就有了稳定的信息来源，自然就能吸引新生使用。

结对&照片

我们相性比较好，生肖比较配。

遇到的困难和解决方法

最大的困难就是最开头不得不更换原型模型工具，前面提过了，这里就暂不赘述了。
还有就是我们两人对于题目的理解在初级阶段发生了冲突，提出的想法也很有多相异之处。但万事胜在沟通，我们互相列举了自己思路的历程和提出这个想法的理由，在一条条慢慢梳理下达成了共通，也就形成了目前的这个设计。

设计说明

本次设计的项目树如下图：

登录界面

• 学生
  

• 管理员
  

学生登录

• 首页
  

• 部门列表
  

• 某部门界面
  

• 学生日程
  

• 个人信息
  

• 我的申请
  

• 我的社团
  

管理员登录

• 部门详情
  

• 部门纳新
  

• 部门成员
  

• 临时通知
  

PSP表格

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

转载于:https://www.cnblogs.com/shadeinblue/p/7576894.html