软件工程(QLGY2015) 第三次作业点评（含成绩）
相关博文目录：
团队信息
本页点评团队1-22，其他组见：http://www.cnblogs.com/xiaozhi_5638/p/4490764.html
| 团队编号 | 博客园团队博客 |
|---|---|
| 1 | FOR THE DREAM |
| 2 | 思甜雅 |
| 3 | 平常心 |
| 4 | 沉睡魔咒 |
| 5 | 蓝色梦想 |
| 6 | 进击的代码 |
| 7 | 追梦人 |
| 8 | One Piece |
| 9 | 四傻大闹齐工大 |
| 10 | 粉末 |
| 11 | Dream high |
| 12 | 软件工程学习小组 |
| 13 | 蹿吧 妮儿 |
| 14 | 代码海洋 |
| 15 | KING |
| 16 | 奔跑的蜗牛 |
| 17 | 狩猎的时间到了 |
| 18 | 非常4+1 |
| 19 | 19 |
| 20 | 天天向上 |
| 21 | 翱翔的飞鹰 |
| 22 | 团队博客206 |
NABCD点评
团队项目里一下子要做的几个都是比较抽象的东西：
- 协作与分工
- 立项（NABCD大法。。）
- 功能设计
- 用例图、类图、时序图等
- 测试计划
前两次作业分别是PSP和结对编程，上述几个内容都没有得到充分的有效训练，导致同学们做这几个环节整体流于形式。不能抓住重点。
简单确定团队成员之后，不应该直接就分工了。一般来说立项是第一位的，如果不能确定软件要不要做，要做什么，分工有个屁用。而立项，根据《构建之法》，我们知道NABCD是一种有效的模型，大家称为NABCD大法。不过我的角度看来，大家还只是在字面意义上去使用NABCD了，有NABCD和没NABCD区别在哪？我认为以上的其他部分都可以围绕NABCD的去做。
那好，我们就说用NABCD了:
N，我认为N一定要分析目标用户群，搞清楚：谁是用户，他们的需求是什么，现有的软件解决了他们的什么问题，没解决的问题是什么，然后，我们的Team才决定去做一个软件解决这些用户的需求。用户可以是自己，也可以是班上的同学，也可以是网络上的其他人，但一定要有用户。没人用，你做的都是无用功。一般来说，能搞明白面向的用户是谁、能解决的核心问题，就是最基本的。需求也不是自己拍脑袋想出来的，多半你还是需要去和你的用户沟通，做用户需求分析，否则你想象出来的需求根本不存在，在整个项目周期内，需要反复从用户哪里得到反馈。
A，这个地方你大可以针对N里的需求做分析、设计。分析的话可以做个基本需求分析、高级需求分析、扩展需求分析等。设计，才是你们需要用上用功能设计、用例图、类图、时序图的地方。
B，好不容易做了分析、做了设计。总得说下如果要去实现的话，做好了这个软件。用户会不会被吸引去使用，怎样才能被吸引？B要思考的就是我们的软件经过A之后，会不会根本不够吸引用户去使用，如果是的话，那就要返回去思考N和A是否有问题。如果有问题，就一定要回归分析、设计了。如果连自己都说服不了，不值得写代码。
C、如今早就是满世界都是软件了，你做一个一模一样，完全功能都一样，甚至更全的软件估计都没什么竞争价值了。那么问题来了，怎样才有竞争力，竞争力意味着别人死活都比不过你。这个就要绞尽脑汁的。
D、请返回看你的N，如何让他们用上软件，解决他们的问题，并让它们得到B，你的软件他们会用多久呢？
以上几个点，并非一次了事的事情，会贯穿整个软件生命周期，需要随时更新和调整。然后，就开始开工了，无论是瀑布模型还是敏捷开发，尽早往github上提交代码啊。写了一堆东西，一行代码都没看到呢？第一天就可以初始化项目目录，工程文件，赶紧往github上提交呗。一个月时间不抓紧怎么能做出高质量的软件。在经验不够的多的情况下，能一个team在一起协作多写代码才更真实吧，那些抽象的名词也没办法不写代码只写博客就能理解。尽早做出有人用的软件才是真正的目标。
评分
7月8日更新，重要：
- 程序部分里的代码提交部分单独拆出评分，请还没提交或者提交不完整的团队，补交完整项目代码，截止日期2015年7月15号。Fixed!
- 博客作业逾期（超过一周）未提及的，会直接倒扣分数。
| 团队编号 | NABCD(10) | 程序(10) | 运行与总结（10） | 代码提交(10) | github | 备注 | 总分（3:2:3:2） |
|---|---|---|---|---|---|---|---|
| 截止时间 | 5月24 | 6月14 | 6月21 | 6月21 | |||
| 19 | 8 | 8 | 8 | 8 | 完整 | 80 | |
| 4 | 6 | 8 | 7 | 8 | 完整 | 71 | |
| 2 | 6 | 8 | 7 | 8 | 完整 | 71 | |
| 3 | 7 | 6 | 7 | 7 | 完整 | 68 | |
| 7 | 7 | 7.5 | 7 | 5 | 完整（7月10号更新提交） | 67 | |
| 13 | 7 | 7.5 | 7 | 4 | 提交了单个文件，无后缀名 | 请提交完整项目工程 | 65 |
| 14 | 6 | 7.5 | 7 | 4 | 提交了一个txt文件 | 请提交完整项目工程 | 62 |
| 20 | 5 | 7.5 | 7 | 4 | 提交了一个Md文件 | 请提交完整项目工程 | 59 |
| 12 | 7 | 7.5 | 7 | 0 | 无，博客有代码 | 请提交完整项目工程 | 57 |
| 18 | 5 | 7.5 | 6 | 4 | 项目不完整 | 请提交完整项目工程 | 56 |
| 22 | 4 | 5 | 6 | 7 | 完整 | 54 | |
| 6 | 6 | 7.5 | 6 | 0 | 无，博客有代码 | 请提交完整项目工程 | 51 |
| 10 | 6 | 7.5 | 6 | 0 | 无，博客有代码 | 请提交完整项目工程 | 51 |
| 11 | 6 | 5 | 4 | 4 | 提交了单个文件，无后缀名 | 请提交完整项目工程 | 48 |
| 15 | 3 | 3 | 7 | 5 | 有未实现代码 | 请提交完整项目工程 | 46 |
| 16 | 5 | 7.5 | 4 | 2 | 提交了单个文件，无后缀名（7月15号更新提交） | 命令行版变成GUI版？请提交完整项目工程；7月15更新：重写了命令行版的总结。 | 46 |
| 9 | 6 | 7.5 | 4 | 0 | 无，博客有代码 | 请提交完整项目工程 | 45 |
| 17 | 4 | 2 | 5 | 5 | 完整（7月10号更新提交） | 41 | |
| 21 | 6 | 2 | 6 | 0 | 无，博客有代码 | 请提交完整项目工程 | 40 |
| 1 | 5 | 3 | 5 | 0 | 无，博客有代码 | 请提交完整项目工程 | 36 |
| 5 | 5 | 4 | 2 | 3 | 提交了单个文件，无后缀名 | 命令行版变成GUI版？,请提交完整项目工程 | 35 |
| 8 | 7 | -5 | 2 | 2 | 提交了单个文件，无后缀名（7月10号更新提交） | 命令行版变成GUI版？,请提交完整项目工程,面向对象程序设计超过一周未提交 | 21 |
优：
- 总体上每个团队还是坚持到了最后，完成了大部分必要的环节
- 一部分同学至少学会了完整提交github，如果能整个开发周期都在github上协作就更好了
- 项目的立项和分析，NABCD环节，总体上有了个初步的接触，想必以后做其他项目的时候大家会想到这个大法
- 无论自己写的还是基于已有代码做的，都至少做了一些
劣：
- 老师布置的环节有的团队没做完整，比如面向对象程序设计，运行和总结
- 只要少数几个团队认真提交了github，一部分提交了单文件，另一部分没提交，还有的没看到代码，也说明了团队的程序开发并没有全程使用github的版本化功能
- 有很多博客内容摘抄的痕迹明显，其实如果是引用别人的文章，至少要加引用说明，可以引用，但是一定要有结合自己项目理解并认真写的部分，列个参考资料也比直接抄强
- 整个团队项目过程中，可能是由于期末同学们忙于各种考试的原因，体现出工程方法的比较少
- 团队的博客里应该说明团队里每个成员的实际做的事情，以及协作解决问题的过程中如何使用工程方法解决的，但很多团队博客只写了博主自己干了什么
- 团队项目代码做的质量并不如结对编程的代码质量，可能是由于期末的原因吧，多人协作的项目至少要有足够的代码数量吧，很多太简单了，还不如结对项目
- 如果是基于已有项目的代码，至少应该说明下，本项目基于之前谁谁谁的哪个版本的代码上开始做，自己做的部分主要添加了哪些东西，最重要的是，自己做的部分是什么
未来改进点
- 第一周个人项目的时候，一定要严格考核每个同学的Git使用能力。比如可以设置只有通过Git考核的才能进入下一个环节（结对编程）项目，而不进入下一个环节就不能得下一个环节的分数，这样宁缺毋滥的要求下，必然不会出现到了团队项目还不会正确使用Git以及在Github上协同开发。单元测试也要严格通过。
- 结对编程的时候，一定要严格考核每个小组的编码规范能力，以及两人协同开发的能力。如果一个班级都采用一种语言开发，比如Java，那么此时可以要求在教师指定的编码规范里挑选一种并且严格执行。协同开发，在Github上必须有两人协作开发的fork-pull-request记录。
- 团队项目的时候，必须一开始就说明团队博客地址+团队项目的Github仓库地址。必须为团队项目在第一天就建立团队项目的Github仓库，并且每个阶段都必须有所有团队成员的fork-pull-request提交记录。
- 选题要说明是重新开发的项目还是在已有项目上开发，如果是在已有项目上开发，应该在NABCD里重点说明已有项目的背景，及其需要改进的点，或者哪些新需求，这样才能有的放矢，在后续的环节里明确说明团队改进和新增部分的内容，而不能用已有项目本身的代码充数。
- 对于学生来说，还是应该围绕可运行的项目代码为核心，任何一个环节都应该保证Github上提交的代码是当前可执行的。
- 可以的情况下，应该要求必须反馈助教或者老师的建议，不反馈者直接扣分，否则给出的建议都没有跟进。
