3032 俊杰
3006 志恒
一、需求分析（NABCD模型）
1、N（Need，需求）
- 塔罗牌占卜，预测自己的一些选择的情况。
- 当一些人需要塔罗牌占卜时，可以方便快捷的给出占卜结果。
- 通过抽卡的随机性，提升占卜的可靠性。
- 需求者可选择自己想要在爱情、事业、幸运这三方面上进行占卜。
2、A（Approach，做法）
占卜系统大致的运行流程如下：
- 在小程序中打开占卜系统；
- 点击开始占卜；
- 从爱情、事业、幸运这三个选项中选择你现在想要占卜的一个方向；
- 抽取塔罗牌
- 展示出塔罗牌并显示占卜结果
3、B（Benefit，好处）
- 能够给需要者提供便捷的占卜需求
- 让一部分人在占卜后能够寻求心灵上的安慰
- 能够适当的给占卜人解忧排难
4、C（Competitors，竞争）
- 目前还未出现大部分的塔罗牌占卜小程序，行业竞争小。
- 潜在竞争对手可视为目前参加软工实践的学生，其中有部分的优秀学生，他们或许对于适应时代潮流的一些小程序设计颇有兴趣。
5、D（Delivery，推广）
- 当原型系统被采纳之后，立马投入人力精力进行开发
- 通过博客以及软工课程进行初期的推广，预期让感兴趣的学生了解到该系统，并从学生角度出发期望得到建设性的意见
- 通过与导师们进行沟通交流，尽可能向学院所有导师推广这一个系统，并从中汲取到更为专业、更全面的建议并加以改进
小程序主页面显示 选择方向界面显示
抽卡界面 结果显示
二、效能分析
|
内容 |
时长 |
|
需求分析 |
1H |
|
进行原型设计 |
2H |
|
进行文档编写 |
2H |
|
系统后期完善 |
1H |
三、总结
想要设计一个程序的过程很简单，但是要设计一个好程序就不易，他需要很多次的update，每个团队成员，都需要发挥出各自的能力并且在不断的探索与无尽的建议中，寻求各种解决问题的方法。
分析方案的同时，不仅仅只考虑可行因素，更要多多考虑一些不可行的因素，这些不可行因素的存在，有相当一部分能够影响你的判断。
并且仅靠一次的分析是远远不够的，正如各个游戏都会有版本update，只有我们的项目接近无缺陷（85%以上），我们可能去停在分析，项目完结撒花。
所以想要我们的项目能够得到认可，就要在这很多次的分析之中得出改善方案。
|
PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
|
Planning |
计划 |
40 |
70 |
|
· Estimate |
· 估计这个任务需要多少时间 |
40 |
70 |
|
Development |
开发 |
380 |
680 |
|
· Analysis |
· 需求分析 (包括学习新技术) |
35 |
75 |
|
· Design Spec |
· 生成设计文档 |
40 |
75 |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
50 |
80 |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
50 |
85 |
|
· Design |
· 具体设计 |
50 |
85 |
|
· Coding |
· 具体编码 |
50 |
85 |
|
· Code Review |
· 代码复审 |
55 |
95 |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
50 |
100 |
|
Reporting |
报告 |
80 |
170 |
|
· Test Report |
· 测试报告 |
25 |
45 |
|
· Size Measurement |
· 计算工作量 |
25 |
45 |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 |
80 |
|
合计 |
|
500 |
920 |
