第三次作业——结对编程开始啦

Deadline： 2015-09-30 22:00pm

       软件工程写代码吗？结对编程怎么不编程呢？在大家的期盼中，第三次作业开始要求编码啦！还是结对编程，还是第二次作业的结对的组合，不要拆分。

       首先我们回顾下上一次作业里的结对项目——报课系统的原型设计：

       “比我想象的要好很多，惊喜连连，第二次的作业里，要求大家，1、自学 《构建之法》及NABCD模型；2、自学 原型工具软件；3、分析客户语言描述的需求；4、细化讨论实现；5、随笔描述和Markdown排版。 每一项都挺费时费力的，很多组都做得很不错，有的具有专业的水准——“公司做的原型初始也不过如此吧”，有的实现了在线版本的原型，很惊艳。具体评分可以查看助教的评分 http://www.cnblogs.com/math/p/4833301.html ，同时也希望大家及时细致回复评论。 原型作业也存在着问题： 1、原型设计与功能实际使用间的差距细节，在考虑上还有所欠缺。 2、在原型设计体现出的功能上，各组大体分为三类：一种做成了邮件处理系统，发邮件、处理附件、收邮件、汇总附件的功能；另一种是做成基于web或APP排课报课系统，脱离原有邮件或附件这个约束。 第三种， 上述两者结合，包含web或APP上的功能处理，同时兼具邮件收发功能。”

      哪一种是客户原意想要的呢？第二种。 当然，客户的选择或原型的实现，原本也无所谓正确与否。 客户的考量是这样的：第一种方案是邮件处理，但除了 报课邮件，客户邮箱里还有其他邮件，还有其他各种附件，做成统一的针对排课的邮件收发系统，会不会使其他非报课相关的邮件或附件也受影响呢？所以是有点担心的。第三种太复杂了些，如果可以邮件催报课，客户更愿意希望是能够短信催报课。考虑到成本或实现的复杂因素，因此，综合权衡，需要第二种方案。

      那么，和第二种不一致的，就可以微调下，改进下你们的原型。

      接着我们来说 这次要求的结对编程吧：

      从报课系统中抽出一个困难度较大的功能，来做技术可行性探索的demo吧。选择的功能是： 将初始的排课excel空表导入系统，再将其展现在你们设计的原型里。 这个功能其实分为两步：1、将初始排课表（客户已经将其中一次的排课excel空表上传，作为附件提供在这篇随笔的最后，请下载）导入系统数据库；2、将系统数据库的排课数据 显示在 web或APP的界面里。仅考虑上述功能的实现，暂不考虑后续细节的可拓展性或全面需求的影响，将此作为一个技术可行性的突破demo。

      1、结对编程实现上述功能； 

      2、采用PowerDesigner 设计上述功能所需要的数据库；

      3、将整个项目上传到Github，命名为 CourseManagement，要求必须增量式开发-提交到github，github上要能看到多次commit的记录，同时必须有两个人各自的commit记录；

      4、阅读《构建之法》第二章，提供PSP表格。

      5、描述一篇随笔，包括：结对两个同学的学号、上述功能的分析、实现的思路、数据库设计的考量、PSP表格、源码的Github链接、Github上的commit的日志要求贴在随笔中、结对的两张照片、两次结对经历的小结。

      特别要求：两位同学都要参与本次作业的编码工作。 可将上述功能的两步分工，两个同学轮流作为主程序员。

      排课excel表 链接: http://pan.baidu.com/s/1o6zkffc 密码: 8gpp