软件工程(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上提交的代码是当前可执行的。
可以的情况下，应该要求必须反馈助教或者老师的建议，不反馈者直接扣分，否则给出的建议都没有跟进。