结队项目——第一次作业
结队项目——第一次作业
本次作业 deadline: 2017-9-22 10:00pm
1.阅读
阅读《构建之法》第4章和第8章的内容,并在下方作业里体现出阅读后的成果。特别是第8章中的NABCD模型。
2.结队合作
阅读下方的客户描述的现实困扰,请你们能将整套流程信息化,以共同发布一份博客随笔的形式,设计一套方案,向客户推销。描述大致方案,以向客户证明你正确理解了客户的需求(即进行需求分析)、提供给客户可行的优化的步骤建议,给出原型模型。要求:
- 文字准确、样式清晰、图文并茂。字数在1000字左右。
- 原型模型必须采用专用的原型模型设计工具实现:如Axure Rp、Balsamiq Mockup、Prototype Composer、GUI Design Studio、Adobe、墨刀设计组件等等。在博文中说明你所采用的原型开发工具。
- 再次推荐博客排版采用博客园的markdown排版,范老师提供了说明:http://www.cnblogs.com/math/p/se-tools-001.html 。 (纳入作业评分细项要求中)
- 结对成员不能是同一团队成员。
最终客户将以评论的方式给出接纳与否或修改完善的建议。如果客户接纳,该方案将作为你们结对项目的第三次作业。如果客户不接纳,下周你们的结对就将无法继续编码本次的内容,将完成老师命题的作业。
3.客户需求
开学初加入学生会部门的迫切需求——选择部门和课余时间冲突之烦恼
选择部门的现状:
各个部门在开学初占据学校青春广场有利位置,通过张贴海报、发传单等形式向学生宣传;对某个部门感兴趣的同学,填写加入部门申请表交给各部门负责人。各部门负责人通过一种说不清道不明的算法对申请的学生进行人工筛选,人工筛选留下的学生也面临被淘汰问题。筛选和淘汰的规则如下:
- 部门纳新人数和面试时间必须事先申报确定;
- 部门活动时间包括常规活动时间(如每周三19点-20点)和临时活动时间,常规活动时间在纳新时候就要公布;
- 如果一个学生常规部门活动时间请假超过6次,将面临被淘汰;
- 学生最多加入5个部门,但是要考虑部门活动时间冲突次数;
- 未参加部门面试的学生不能纳入部门。
现状困扰的是:流程繁琐复杂,各个部门手工发放申请表,手工收集汇总,各个部门之间信息沟通不畅,导致不少学生加入几个部门后,由于活动时间冲突而被淘汰,浪费时间和精力。学生在加入部门前对部门的情况了解有限;部门在学生申请之前对学生也不了解,稀里糊涂,不可言说,就接收了,导致后续配合存在隐患和困扰。
现在,现在,现在,我们很想做这样一个系统,请你和你的“对友” 设计一个原型系统,让部门选择的过程能够信息化起来,让学生和部门之间可以双向选择。
4.博文要求
将博文发布到个人博客上,且需包含以下6个内容。
1)随笔开头,给出结队两个同学的学号。(1‘)PS:结对成员不能是同一团队成员。
2)对客户需求进行需求分析 ,可采用NABCD模型。(5‘)
3)为客户需求设计一个原型系统,让部门选择的过程能够信息化起来,让学生和部门之间可以双向选择。要求样式清晰、图文并茂,并说明你所采用的原型开发工具。(5‘)
4)记录本次作业的PSP表格,包括预估耗时及实际耗时。(1‘)
5)描述结对的过程,提供非摆拍的两人在讨论、细化和使用专用原型模型工具时的结对照片。(1‘)
6)第一次和结队的TA合作肯定感慨万千,分享本次结队的心得和本次项目的总结 。PS:需注明是哪位同学的心得体会。(2‘)
5.评分规则
本次作业评分由2部分组成,共20分,分别是
(1)博客 — 15分,分数组成在博文规范中。
(2)客户评分 — 5分,由客户针对你的解决方案进行评分。
(3)注意事项:
- 按时间完成并提交——正常评分
- 晚交一周以内——0分
- 晚交一周以上或不交——倒扣本次作业分数
- 抄袭——倒扣2倍本次作业分数【严禁代码与博客等一切形式的抄袭!博客园支持了对博客的查重功能,我们也有专用的代码查重系统进行代码查重。请各位同学千万不要触碰底线,勿谓言之不预也!】
附:PSP 2.1表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
Planning | 计划 | ||
· Estimate | · 估计这个任务需要多少时间 | ||
Development | 开发 | ||
· Analysis | · 需求分析 (包括学习新技术) | ||
· Design Spec | · 生成设计文档 | ||
· Design Review | · 设计复审 (和同事审核设计文档) | ||
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
· Design | · 具体设计 | ||
· Coding | · 具体编码 | ||
· Code Review | · 代码复审 | ||
· Test | · 测试(自我测试,修改代码,提交修改) | ||
Reporting | 报告 | ||
· Test Report | · 测试报告 | ||
· Size Measurement | · 计算工作量 | ||
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | ||
合计 |