结队项目——第一次作业
结队项目——第一次作业
1.结队成员
031502339 叶港晨，031502309 候振源
2.采用NABCD模型分析用户需求
1）N（需求）
①方便信息化的管理部门中的面试与活动。（站在部门角度）②学生方便地查看和管理自己所加入的部门的活动信息。（站在学生角度）③学生账户可以拥有自己的个人空间发表动态，部门账号则可以发表相关文章。（解决两者互不了解的情况）④部门内部存在一个交流平台可拥有部员群聊。（扩展需求）
2）A（做法）
①人脉：通过各自参加部门学生工作两年，对部门活动能有自己的了解和理解，同时所积累的人脉在推广测试的时候能够起到作用。
②学生可以通过个人空间展示自我，对于在部门的发展有明显的好处
③部员可以在活动安排表上直观的看到自己所在部门的活动时间地点，安排表的排版方式与课程表相似，可以直观的看到和自己的课程时间是否有冲突。
④学生可以通过手机APP可以随时随地的了解部门的最新动态。部门也可以更加方便的联系部员和发布通知。
3）B（好处）
①对学生部门来说使得两者都更加方便。
②市面上（至少学校范围内）并没有一个完善的部门管理app， 所以不存在用户迁移成本的问题。
③学生可以更方便申请部门，并且可以防止所在的两个部门甚至多个部门活动时间产生冲突。
4）C（竞争）
①优势：与之后可能出现的竞争者相比，我们的优势是拥有个人空间与部门空间，同时拥有部门内部的群聊，不需要想现在这样，部门中交往混在在qq与微信中，而是使两者分开社交，可能会更好。②劣势：为了完成成为优势的功能要耗费更多的时间和人力。
5）D（推广）
①利用人脉通过空间，朋友圈等途径推广。②尝试上架app store等应用商店。③可以向访问量较高的网站投递广告。④在人多的地方比如广场进行宣传，有奖下载等活动。
3.原型系统
①学生、部门登录界面
其中部门注册时就要说明纳新人数，面试时间和常规活动时间（之后可以在部门主页中修改）
②学生、部门主页
③学生申请部门界面
如果所加入部门已达5个或者活动时间产生冲突则会弹窗提醒
④学生查看加入的部门以及进入群聊
⑤学生查看公告以及活动
⑥部门发布公告以及活动
⑦个人空间与考勤表
考勤表部门管理与学生都可以在各自界面中点开查看，若超过6次请假，管理员可以选择开除
4.PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 30 |
| Development | 开发 | 440 | 500 |
| · Analysis | · 需求分析 (包括学习新技术) | 100 | 120 |
| · Design Spec | · 生成设计文档 | 40 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 30 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 30 | 30 |
| · Design | · 具体设计 | 180 | 200 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 60 | 60 |
| Reporting | 报告 | 140 | 160 |
| · Test Report | · 测试报告 | 60 | 90 |
| · Size Measurement | · 计算工作量 | 20 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 60 | 60 |
| 合计 | 600 | 690 | |
| 5.结队过程 |
6.心得体会
031502339 叶港晨
以前自己动手做一些小项目的时候，直接扫了一眼要求就直接开始动手写了，或许真是这样老是会出现漏掉需求需要立马修改的情况。看了构建之法中描述的NABCD模型之后，这一次结对项目我就尝试着拿来用了，发现用这个模型分析需求的时候不仅仅只做到了需求分析，而是会在设计这个模型的过程中找到需求的大致方向，很有实用性。这是我第一次结队项目，我发现最重要的不是技术，而是项目开始前的交流和分工，保证这两者才能使得整个项目过程有条理，使得项目能够顺利地完成。
031502309 候振源
这次作业和队友是第一次合作，一开始的确是有点不太适应，但是经过后面的讨论商量，明确的分工合作。慢慢的作业就顺利的进行下去。加上是自己班的同学，并没有和陌生人结对的尴尬感。从一开始看到作业要求时的毫无思路，到后面和队友的商量，思维的碰撞，慢慢的体会到了结对是有一个人单独完成任务所没有的好处的。这次的结对作业，让我理解到了完成一个项目并不是像以前一样的一上来就开始写代码似的。要完成一个项目，前面的准备工作是必不可少的。从NABCD模型到后面的原型模型的设计。真实的体验了一把编码前的项目流程。总的来说，这次的结对作为在我看来不管是对后面项目的完成还是以后工作上的任务，都是一个非常好的开始。
