软件工程实践2017-结对项目第一次作业
2017-09-21 21:08
429 查看
制作人:
A同学 : 031502610
B同学 : 031502609
工具:
墨刀原型设计
风格:
无配合
无组织
无纪律
目录:
一. 需求分析 ( N )
1.1 情景
1.2 存在问题
1.2.1 学生端
1.2.2 部门端
二. 软件设计 ( A )
2.1 逻辑图
2.2 功能设计
2.2.1 学生
2.2.2 部门
2.2.3 特色功能
三. 产品优势分析 ( B )
3.1 学生为什么要使用本产品?
3.2 部门为什么要使用本产品?
四. 市场竞争分析 ( C )
4.1 已存在的相关产品
4.2 竞争优势
五. 营销推广 ( D )
5.1 面向群体
5.2 推广策略
5.2.1 测试、改进
5.2.2 投入运营
六. 模型建立
七. 我们有话说
一. 需求分析 ( N )
1.1 情景: 部门纳新
1.2 存在问题:
1.2.1 学生端:大部分新生不能确定自己的兴趣点,或者不知道部门是否适合自己。
对部门情况了解有限, 不能及时了解并比较各部门的常规时间冲突情况 。
至多加入5个部门,且部门面试时间和活动时间可能存在冲突 。
没有参加面试就没有加入部门的机会 。
常规部门活动时间请假超过6次,将面临被淘汰 。
如何选择部门才能最大化减少时间和精力的浪费?
1.2.2 部门端:
部门纳新人数和面试时间必须事先申报确定。
纳新时候需公布常规活动时间。
部门与部门之间信息沟通不畅, 容易出现面试时间和常规活动时间冲突。
手工发放申请表, 手工收集汇总, 耗费人力和精力 。
有没有更加方便完成这些流程的工具?
二. 软件设计 ( A )
2.1 逻辑图
2.2 功能设计
2.2.1 学生关键字搜索部门 。
查看部门相关信息介绍 。
查看部门纳新人数以及常规活动时间和面试时间 。
填写相关信息(兴趣爱好, 申请加入该部门的理由等等)后,可选择立即申请 或者 加入意愿清单 。
清单中将根据面试时间/常规时间进行分块, 有冲突的部门处于同一块, 可删改, 可一键申请 。
2.2.2 部门
可编辑部门介绍信息,打足广告,吸引新生加入 。
发布纳新活动, 需要填写纳新人数、常规活动时间、面试时间 。
可查看当前申请列表,查看申请学生的详细信息和申请理由,可选择Accept 或者 Refuse 。
平时可发布部门公告、部门活动等对部门进行管理。
2.2.3 特色功能
学生申请加入部门后,有两周的考量期,既是部门对学生的考量,也是学生对部门的考量,双向性。
考量期间,学生可撤回加入部门的申请,考量期结束后一天,部门可驳回表现不满意的同学的部门加入申请。
三. 产品优势分析 ( B )
3.1 学生为什么要使用本产品?
了解更多的部门纳新信息,避免消息闭塞。了解详细的部门信息,便于权衡彼此。
在基于部门时间冲突上,通过考量期的亲身感受,更好地选择自己的兴趣部门。
及时了解部门动态,明确自身与他人对部门的贡献值。
3.2 部门为什么要使用本产品?
减少了纳新活动中发布/收集报名单的繁琐流程,节省人力。发布纳新面试时间时,将提示当前学校在此时间段也同时进行面试的部门,有利于面试时间的更改,尽量减少与其他部门的冲突。
自动按照专业归类申请学生,利于部门首次筛选。
考量期的应用,便于部门更好地淘汰部分不积极或者不适合该部门的学生。
记录学生出勤数及参与活动次数,采用积分制度,更好去了解统计部员对部门的贡献。
可更新部门动态,便于部员了解当前部门的活动及近况。
四. 市场竞争分析 ( C )
4.1 已存在的相关产品
超级社团区别与我们的优势 (此处为补充点. 2017.9.23)
超级社团更注重部门管理,缺乏解决纳新这等繁杂又容易产生时间冲突的活动有效的方法,更贴切说是功能。而我们的产品,基于解决部门纳新活动信息化的需求,再对部门管理部分内容进行拓展和实现。
超级社团在部员申请的流程是为单向的,即部员申请,部门管理人员同意,则入部流程结束。而我们的产品,提供考量期服务,能更有效地避免学生身陷部门活动之间的各种冲突,也减少学生精力与时间的浪费。
超级社团没有加强同校各部门之间纳新以及其他信息的流通性,而我们的产品,在多个部门统一活动时,例如纳新,保持各部门之间的信息流通,避免时间以及其他冲突。
软工实践其他小伙伴的产品
尚未上市,且针对需求一致,理解和解决上可能存在差异,不好比较。
4.2 竞争优势
功能针对性更强使用简便
符合使用者的需求
五. 营销推广 ( D )
5.1 面向群体 :
大学生和部门管理人员5.2 推广策略 :
5.2.1 测试、改进 :介绍给身边人使用,根据反馈意见进行改进。
5.2.2 投入运营 :
微信/QQ空间/新浪微博等常见方式推广。
向校园部门推广,多校推广。
六. 模型建立
主界面其余部分,点此体验,(部分修改, 2017.9.23)
七. 我们有话说
A同学 :“emmmm...之前就玩过墨刀,所以和队友一起讨论了下细节,定下了功能后,便直接将界面甩给他了,自己开始写起了博客。这次的作业,唤醒了我当初对那些部门纳新的疑问,也就是本次作业中部门与部门之间,部门与学生之间的矛盾所在,信息化过程能够更好地组织管理这些流程,主要还是吐槽手工收集报名表,再手工整理的效率上实在不敢恭维... 关于考量期的功能,其实我们还是考虑到给部门和学生之间留点'后路',毕竟尝试总是应该的,但是约法三章后,才能让自己更加知道该去做哪些事情,而对于部门来说也能够分辨出哪些学生不积极不适合这个部门...勤则留部,否则退部,也给彼此留点情面...(注: 两周考量期,学生意愿>部门意愿,也就是学生在两周内都可以申请退部,而部门只能在两周考量期结束才进行筛选留部人员)”
B同学 :
“一直以为我是抱大腿的那个,没想到第一个作业就甩给我。。不得不说,一个人做软件一个人写博客真的是shi一样的分工。。不过每次作业都能学到新内容这个目标还是达成了。虽然墨刀只能做出简单交互界面,而且对有强迫症的同学恶意很强,但是能做出一个自己设计的界面还是挺有成就感的。”
八. PSP
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 60 | 40 |
· Estimate | · 估计这个任务需要多少时间 | 60 | 40 |
Development | 开发 | 160 | 130 |
· Analysis | · 需求分析 (包括学习新技术) | 50 | 40 |
· Design Spec | · 生成设计文档 | 20 | 20 |
· Design Review | · 设计复审 (和同事审核设计文档) | 30 | 20 |
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
· Design | · 具体设计 | 60 | 50 |
· Coding | · 具体编码 | 0 | 0 |
· Code Review | · 代码复审 | 0 | 0 |
· Test | · 测试(自我测试,修改代码,提交修改) | 0 | 0 |
Reporting | 报告 | 60 | 90 |
· Test Report | · 测试报告 | 20 | 40 |
· Size Measurement | · 计算工作量 | 20 | 30 |
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
合计 | 280 | 260 |
相关文章推荐
- 软件工程实践2017结对项目——第一次作业
- 软件工程实践2017结对项目——第一次作业
- 结对项目第一次作业
- 结对项目第一次作业——部门与学生的双向选择需求分析
- 软件工程实践2017 结队项目——第一次作业
- 软件工程实践2017结对项目——第二次作业
- 结对项目-第一次作业
- 软件工程实践2017结对项目——第二次作业
- 结对项目——第一次作业
- 结对项目——第一次作业
- 软件工程实践2017结对项目——第二次作业
- 17秋 软件工程 结对项目 第一次作业(队友副本)
- 结对项目第一次作业——原型设计
- 实践作业3 结对项目--五子棋项目
- 软件工程实践2017第一次作业
- 作业4:结对项目—— 词频统计
- 团队作业4——第一次项目冲刺(Alpha版本)2017.11.14
- 团队作业4——第一次项目冲刺(Alpha版本)11.18
- 第一次作业:项目范围管理论文的提纲
- 17秋 软件工程 结对项目 第二次作业