《坐热板凳》第五次作业:团队项目需求改进与系统设计


团队项目需求分析改进总结
在上一次作业需求分析中出现的问题.
1.在上一次的作业中,我们缺失了最重要的类图,大家分工上出现了问题,每个人负责了几张图,导致最后拼凑的时候大家对于某类图叫什么的概念问题上出现了偏差,以至于最重要的类图没有放上,在这次改进过程中,我们加入了类图设计。
2.在调研工程中,我们由于时间原因,参加问卷调查的人数不足以构成对我们设计的小程序项目有牢靠的调查意义,所以我们这次把我们的原型设计图打印出来,在下课时间段放学途中,对西北师范大学的学生进行了面对面快速访问。随机调查了74个同学,不分年级和性别,最后得出的结果是有65名同学使用过或正在使用记账软件或者小程序或者自己手写记账;如果有一个功能简单方便记账的小程序,有70名同学表示愿意使用。与问卷调查的结果进行比较发现,面对面调查的时候,百分比更多的人愿意尝试使用记账本小程序进行记账。

参考《构建之法》8.5节功能的定位和优先级,给出功能分析的四个象限.

外围功能 杀手功能
必要需求 1.记录每日支出内容;
2.记录每日收入情况;
3.支出/收入可选择类型、金额、日期、备注;
4.可查询历史记录,每月详单。
自动生成报表,以空心饼图的形式显示消费/收入的总额和分类金额,可选定日期范围进行查询。
辅助需求 设置预算:有支出则同步减去支出金额 。

编制团队项目的WBS
书上的内容:
保证所有子节点覆盖了全部父节点包含的内容。比如在“四则运算”这个项目中,用户所能看到的全部功能有:注册、登录、记账,选择记账的相关分类以及信息。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点,当然就要再细分,直到每一个独立的子节点都被细分出来,这棵大树才会强建。
保证各个子节点不要相互覆盖。比如在“记账本”这个项目中,用户模块分为支出模块和收入模块都有“金额,日期,备注”这个叶子节点,则要在两个用户模块下分别列出, 而不能只在一个父节点中列出。
叶子节点要保证足够小,能在一个里程碑中完成。切得蛋糕要一口就能吃掉,否则就切得不成功,要不一口吃不掉,要不会噎死。做项目也是一样,把功能划分得细不要紧,一天多做两个功能呗,更有成就感,但你划分得不够细,很久很久都做不完,你就有可能慢慢就看不到希望了。
从结果出发构建WBS,而不是从团队的活动出发。这点其实是很重要的,“从结果出发”就是你想呈现给用户的样子,你的所有父结点和叶子结点都是用户能看得懂的,而不是你们团队将要使用什么技术来解决这个问题。就比如我们的项目记账本中用户模块中的“设置预算”,我说用户一定可以设置预算,用户一定可以看得懂,但我说要使用什么方法,针对这用户一定看不懂,因为这是团队要干的事,不是要呈现给用户的结果。

团队项目的WBS:

团队成员估计各自任务所需时间:


任务三:团队项目github仓库地址链接

github地址. https://github.com/jessiyx/sethotchair


任务四:具体分工及占整个系统设计文档任务的工作量比例

项目成员 具体任务 工作比例
朱艺璇 逻辑结构设计、作业整理 26%
王潇 需求说明书的完善和整理、类图设计 26%
达星斗 系统概要设计书的编写 24%
刘振华 WBS的编写、博客的编写 24%


团队项目系统设计过程总结
在上一次的作业中,我们缺失了最重要的类图,大家分工上出现了问题,每个人负责了几张图,导致最后拼凑的时候大家对于某类图叫什么的概念问题上出现了偏差,以至于最重要的类图没有放上,在这次改进过程中,我们加入了类图设计。在这次作业中,对整个项目进行了系统分析,尤其是系统架构和功能进行了详细分析,让我们更加清楚的认识到我们组要做的项目到底是个怎么样的小程序。不仅如此,我们还学习到了出功能分析的四个象限以及WBS分析,尤其在做功能分析四个象限的时候,小组成员集思广益,你一句我一句的分析时,让我感受到了团队的力量。

猜你喜欢

转载自www.cnblogs.com/happiers/p/10909734.html