结对项目原型设计
结队者：3006 梁旖 & 3010 艾晓晗
在《构建之法（邹欣版）》中，在竞争性需求分析的框架板块介绍了NABCD模型
N需求（need），解决用户的需求；
A,做法（approach），解决需求的手段；
B,好处（benefit），产品会给客户/用户带来什么好处；
C,竞争（competitors）,市场竞争，看清优劣事态；
D,推广(delivery)，如何把产品交到用户手中
设计过程
按照本次作业的要求，我们两人来自不同的课设小组。一开始我们没有什么好的想法，也想不出来能有什么创新点，看了不同版本不同牌子的手机备忘录，也问了一下周围同学使用备忘录的一些习惯，我们开始有了一点思路，在讨论过程中，虽然想法不一，但最终殊途同归，最终完成了作业。
同样地，我在此先用NABCD模型简要分析一下我们两人的设计过程：
N：在日常生活中，备忘录是对我们管理时间和帮我们记录重要事情的好东西，但是我们对备忘录的使用频率却不是很高，表现在经常会忘记一些待办的事务。这其实反应了目前为止，手机上自带的备忘录功能还不够完善也不够智能，所以我们没能使用好。这给了我们一个很好的思路就是——要是有一个智能的备忘录，不需要每次都是我们自己一个一个字地敲上去，甚至团队中有一个人做了可以提醒全队的人，效率不是更高吗？因此我们需要一个更为智能的备忘录来管理我们的时间和提醒我们待办事件的时间地点。
A：明白客户需求之后，我和我的队友便开始了分析和讨论如何解决问题、满足需求的方法：
1. 首先在web端和app之间，我们选择了后者；因为我们更多的时候是在移动端接收到提醒，我们很少会主动登陆网页页面查看。断网情况下网页也无法及时推送提醒。
2. 接着我们参考了一些我们自己手机本身已有的备忘录（针对界面设计）以及目前应用市场上已有的一些备忘录app（针对功能和用户反馈），我们简略地模拟出一些界面和功能。比如登陆、手动添加备忘录、系统主动识别信息的时间地点事件等主要信息并自动设置提醒等过程。
3. 完善和设计我们的亮点功能，明确各功能优缺点，完善我们的项目
4. 对模型做修改，不断完善。
此处我们采用的做法有以下的亮点：
- 设计亮点1：信息筛选和自动设置提醒功能。针对事件突然到来或者紧急的情况，我们可能在忙其他事情，没有来得及手动输入提醒，这时候只要把事件通知复制黏贴到备忘录app里，它会自动识别出时间、地点和主要事件等关键字，并且自动设置提醒。
- 设计亮点2：互动功能。 在传统印象里，备忘录就是自己一个人的事情，但是有些事件（比如班会、同部门的会议、考试）是和身边同学一起进行的，要是有人和自己一起使用这个app，并且添加为好友，一个人设置了提醒时可以选择想要提醒的好友，那么被“点名”的好友备忘录里也会自动添加这一提醒。
- 设计亮点 3：界面简洁友好 许多app界面颜色鲜艳多彩，其实不会引起用户太多的兴趣，甚至会让人视觉疲惫，简洁友好的界面可以使用户有更好的体验
B：改变了原先手动的“码字备忘”模式，不仅实现了信息提醒智能化，并且通过我们的设计，原本单一的“单枪匹马完成任务”可以变成和“队友”一起互相提醒，互相监督。当看到自己的要完成的事情一件一件一件地被完成，也会获得成就感。增加了交流功能，也可以减少我们设置备忘录时一些重要信息的错误输入等。
C：这个原型设计如果说存在竞争压力的话，首先是来自不同对的同学，其次是来自已有的备忘录软件和其他类似功能的小程序等。
D：如果老师接纳，该方案将作为我们结对项目的下次作业。如果老师不接纳，下周我们的结对就将无法继续编码本次的内容。如果能够完成，相比不那么智能化的传统备忘录，只要我们成功推荐给同学们，很快就能收到欢迎。
我们的项目目前处于原型阶段，无法提供诸如开发、记录用时的具体信息，但是我们可以完成的是对于项目用时的估计。
PSP
|
PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时时间 （分钟） |
|
|
Planning |
计划 |
10 |
30 |
|
|
· Estimate |
· 估计这个任务需要多少时间 |
10 |
15 |
|
|
Development |
开发 |
655 |
500 |
|
|
· Analysis |
· 需求分析 (包括学习新技术) |
30 |
10 |
|
|
· Design Spec |
· 生成设计文档 |
30 |
15 |
|
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
10 |
10 |
|
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
5 |
|
|
|
· Design |
· 具体设计 |
40 |
|
|
|
· Coding |
· 具体编码 |
5h*60 |
|
|
|
· Code Review |
· 代码复审 |
1h*60 |
|
|
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
3h*60 |
|
|
|
Reporting |
报告 |
290 |
|
|
|
· Test Report |
· 测试报告+博客 |
4h*60 |
|
|
|
· Size Measurement |
· 计算工作量 |
10 |
|
|
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
40 |
|
|
|
合计 |
955 |
|
|
心得
这次和不同组的同学一起结对，感觉收获很多，只有两个人一起合作，工作量也会相应地增多。从确定项目，到功能的设计和细化，还要考虑适用性和竞争对手等等，比自己一个人完成一个“XX系统”要难。很感谢“对友”的信任和耐心，合作愉快。
梁旖
