【1414软工助教】助教总结

一、开学初对自己的期望

最初自我介绍时，没有列出对自己的期望。我想做的是减少同学们完成作业的阻力，以及做一些方向性的引导。

为此我做了两件事：

二、班级

教师： 张敏老师（博客）

班级： 网络四班（博客）

三、发布的助教博客

本学期共发布了 25 篇与助教相关的博客。

其中评分博客 15 篇：
个人作业1：四则运算控制台 结对项目1：GUI 个人作业2：案例分析
结对项目2：单元测试 团队作业1：团队展示 团队作业2：需求分析&原型设计
团队作业3：需求改进&系统设计 团队作业4：Alpha版本项目冲刺 团队作业5：Alpha测试与发布
团队作业6：展示博客 个人作业3：Alpha总结 团队作业7：Alpha复审与事后分析
团队作业8：Beta版本项目冲刺 团队作业9：Beta测试与发布 团队作业10：Beta复审与事后分析

其余 10 篇博客为：
自我介绍 助教链接汇总 学生博客和Coding汇总
团队博客汇总 【福大软工】软件案例分析优秀链接汇总
在博客中插入代码 作业博客高分指南 冲刺博客指南
模块化（零）：综述 模块化一：提取模块

怎么一大堆汇总...
后面的模块化没有坚持写下去，后面的是跟面向对象相关的。但老实说我写的这份代码是否足够面向对象我都没有很大把握。

累计 评论博客 380 次左右，每页 20 个评论，共19页，但其中有一些跟助教无关的评论。

四、助教表现自我评价

整体来看，我对自己的表现相当不满意。初期没有明确主要任务，整个学期缺乏和老师以及同学的交流，经常评成绩拖到很晚。

但也不是一无是处。无论是给同学们的博客写评论或者评分，我都非常认真，虽然也因此花了很多时间。此外我还修改了几次作业的描述，力求作业要求更加清晰。我也制定了4次评分标准以及参与修改了几次评分标准。

  1. 在初期没有明确主线任务

    及时评论同学们的博客和尽快给出成绩是最基本的两项工作，而我却几次把它们的优先度调低。例如有一次在还没有给出成绩的情况下，就去写模块化教程；还有一次是为了写出单元测试 C++版 的空壳（相较于其他语言，C++版的真是麻烦），延迟评成绩……

    这暴露了我的两个缺点：

    • 虽然分清了任务的主次，但仍然忍不住要去做次要任务；
    • 容易对别人给出的新的期望做过度的回应（这可能就是栋哥觉得我做决定的时候“卡卡的”的原因）。

    这奇怪的【满足自己】的方式……这两点如果不改，在工作上还会吃到很多苦。

  2. 缺乏和老师以及同学的交流

    这学期主动跟老师和同学交流的次数实在是少，基本上是同学们有问题来问我。这个学期有和张老师讨论黄杉的分配问题，有和对给出的分数不解的同学的解释和交流，有去找 PM 询问关于团队的问题……

    不过对于如何主动跟他们聊天，我也蛮苦恼的。现在我才想起来，可以多向身边的人请教呀！

    我在 Beta 阶段开始的时候，和同学交流这个方面做了一定的改进，创建了一个微信群，把各个团队的 PM 都拉进去以讨论一些关于项目管理的问题。

  3. 评成绩拖到很晚

    前期 29 份作业都要评，而且评分项比较多，感觉还是蛮耗时间的。虽然耗时最大的部分在于评论博客，但评成绩的时候也花了很多时间。虽然用了 Excel 表格来处理一些数据，但操作起来还是挺麻烦。但是这都不是最大的问题。

    团队项目开始后，每次只要给五份博客评分就行了，但是还是一拖再拖。我想可能是我对看这些博客产生了一种恐惧感。每次评分都要看一大堆文字，评分完还要写一堆文字，实在是难受。这跟看代码不一样，看代码是一种享受（写代码就更是了）。

    通常评分博客要指出同学们的一些问题，以及优秀的博客。有些问题反复强调都没有任何改进，不得不说，我的积极性的确因此受到了打击。给的建议同学不听，给了好多评论，却少有人回复。虽然老师说这是正常的，但我仍然感到伤心。我不是随便给出评论的，有时候会反复看同一篇博客，争取找出至少三个可以改进的地方，或者询问问题。后来我发觉我这样做是不对的，这样是 自己间接地打击自己的信心 。于是减少到找出一个可以改进的地方，只有收到回复之后才继续寻找其他可以改进的地方，或者问其他问题。

  4. 评分严格

    我给的分数通常都很低，特别是那些说得很模糊的博客。做了什么，应该详细地说明，越详细越清晰就越好。我有时候在想，是不是我的要求太高了？

    到后期，我减少了倒扣分的次数。因为如果像前期那样倒扣分，团队的分数可能经常拿到负分……

    像这样自己做决定的地方还有几个，我太想在助教的工作中加入自己的想法。后来我发现这样做不合适，毕竟是第一次做软工助教，对很多问题的了解都不够深入，应该先照着老师的要求做。“严格执行已有的规则，以后再改进规则。”

    我发现在这次助教工作中，我犯的很多错误都是不应该的。很多道理我都懂，但是不知为何总是会做出与已经懂的道理相反的事情来。

  5. 评分标准

    在制定评分标准的时候，我想要减少主观因素带来的影响。因此这些评分标准的特点是详细，详细到每个评分项在碰到某个情况时应该扣多少分。我不太分得清这样做到底增加了工作量还是减少了工作量……

    这一点需要改进的地方是：在评分项内划分档次，针对某个情况只给出对应的档次，而不是某个分数。这样给了助教一定的决定权但又不会受到太多主观因素的影响。

五、作业的问题

表述的问题

在我自己查看作业描述的时候，发现读起来比较费劲。有的是表达不够简洁，有的是作业要求提出是不够直接。

拿两个例子来说明：

  1. 结对编程2——单元测试

    原文片段1：

    一旦我们分离出核心模块，就可以针对该核心模块一步一步开发并做好单元测试，什么是单元测试？请阅读并学习《构建之法》第二章关于单元测试，回归测试的内容。

好了，你一定针对单元测试做了一番学习：

* 阅读并学习了课本上单元测试例子，以及代码覆盖率的知识；

* 或者你还去bing.com，google.com了一把单元测试，JUnit；例如
    * http://www.cnblogs.com/greyzeng/p/4439080.html
    * http://www.cnblogs.com/zhengrui0452/p/6507630.html

* 如果你是C/C++写的，你还去挖了一遍CUnit；
    * http://cunit.sourceforge.net/example.html

* 或者你直接用了C的 #include

* 或者你用了C#，学习了课本上提到的Visual Studio的单元测试框架；
    * 请参考《构建之法》

总之，你找到了适合自己语言的一种可以进行单元测试的工具。

    问题在于好多“或者”以及多余的描述。

    修改后：

    一旦我们分离出核心模块，就可以针对该核心模块一步一步开发并做好单元测试，什么是单元测试？

    请阅读《构建之法（第二版）》第二章 2.1单元测试和2.2回归测试。

    语言 推荐测试框架或工具 参考链接
    JAVA JUnit 参考链接1 ， 参考链接2
    C 或者 C++ CUnit 参考链接
    C# VSTS 《构建之法》

    原文片段2：

    那么，勤快的你已经迫不及待的想要自己上手来测一把：

    1. 通过单元测试代码，测试加法是否能正确工作；
    2. 通过单元测试代码，测试加减乘除功能。
    3. 通过单元测试代码，测试计算类对于各种参数的支持：

        a. 输入是有错误的，例如 “1 ++ 2”，

        b. 在数值范围是 -1000 .. 1000 的时候，传进去 “10000 + 32768”,

        c. 或者是 “ 248 / 0” 怎么办?

        d. 怎么告诉函数的调用者 “你错了”? 把返回的字符串定义为 “-1” 来表示？

        e. 那么如果真的计算结果是 “-1” 又怎么处理呢?

    问题在于 1 和 2 有包含关系；d 和 e 不属于参数；问号太多，作业要求应尽量用陈述句表达。

    在查看同学们博客的时候，发现某些同学没有完成以上的某些要求。可能是他们能力不足，也可能是他们认为以上 a b c d e 不属于强制要求的部分。

    修改后：

    了解单元测试后，编写代码来完成以下单元测试：

    1. 验证加、减、乘、除四个功能的正确性

    2. 负责计算的类对各种参数的支持情况，保证以下几种情况不会使程序出错：

      • 错误的输入。如 “1 ++ 2” ；
      • 输入的数字大于程序规定的数值范围。如在数值范围规定为 [-1000, 1000] 的情况下，传入 “10000 + 32768” 这样的表达式；
      • 除零错误。如 “ 248 / 0” ；

      如果出现了以上几种输入，需要在负责计算或者验证的方法内给调用者返回错误信息。

      注：我们经常使用 “-1” 来表示出错了，但在这里如果使用 “-1” ，计算结果真的是 “-1” 的情况下该如何处理？

  2. 个人作业3——个人总结（Alpha阶段）

    原文片段：

    我们在alpha 结束之后， 每位写一个博客， 总结自己的alpha 过程， 同时，大家一定会在过程中产生了很多问题， 结合你的读书（教材，博客，参考书）， 实践， 提出关于软件工程的 5 个问题。

    在查看同学们博客的时候，发现几个同学漏掉了 “总结自己的alpha 过程” 这个要求。

    修改后：

    写一篇博客，内容包括两个部分：

    1. 总结自己在 Alpha 冲刺过程中的贡献、不足和体会；
    2. 结合你的读书（教材，博客，参考书）或实践，提出关于软件工程的 5 个问题；

检查点过多的问题

例如在 个人作业2——英语学习APP案例分析 中，我最初统计的检查点个数达到了 22 个。

是否能够针对不同学校的学生定制不同版本的作业呢？除了必须保留的核心部分，其余部分做适当增删。

其他细节问题

例如最初的准备作业中，强制规定一种格式。这样用程序自动获取同学们的信息时，就能准确地获取所有数据。

六、几点建议

张敏老师首次尝试这样的教学方式实在是不容易，但也做得挺好的。有些问题一开始很难意识到，因此不好防范。为了今后课程越来越好，我提几点建议：

  1. 强制要求同学们使用 Markdown 。这学期只是推荐使用Markdown （软件工程第一周预备作业），同学们的博客排版看起来不太舒服。
    当然也要考虑到同学们学习 Markdown 的难度。虽然在我们看来，Markdown 的语法超级简单，但是对于第一次接触 Markdown 的他们，可能需要有好的资料来帮他们适应。

  2. 强调 Git 和 Coding 的使用。源代码管理是软件工程的一项内容，而只有极少数人学到这一项。直到 Beta 冲刺结束后，4班的所有团队都没有用好 Git 和 Coding，我在他们博客下面反复说和扣除分数都没用。希望老师能当面强调。

    这一项是很重要的评分依据。可以看到同学们每天实际上都做了什么，做的东西是否跟博客上描述的【已完成任务】一致。但是几个团队都是好几天提交一次，那么【已完成任务】就可以造假。

    Coding 的使用主要包括：

    • Fork
    • Pull Request
    • issues （讨论）

  3. 用 Coding 上的 issues （也就是【讨论】）来代替 Leangoo 。Leangoo 的好处在于生成燃尽图，坏处在于不公开。在两个团队将我加入 Leangoo 后，我看到他们的燃尽图是假的，用于应付而生成。

    虽然可以让各个团队将助教加入他们的Leangoo，但是除此之外的其他人仍然看不到。

    不过如果不使用 Leangoo，那么如何生成燃尽图呢？这是一个问题。如果解决不了，只能忽略该建议。

    有人做出将 GitHub issues 转化为燃尽图的工具，但针对 Coding 的工具却找不到。

  4. 在作业布置前就让助教先做好评分标准，并放到作业博客上。这学期做的改进是在【评分基准】里给出了大致内容。之后最好能给出详细的评分标准，也就是这学期助教在评分博客中展示的评分标准。

    这样做的好处是让同学们能够随时知道自己哪一点没有做，哪一点没有做好，他们能得多少分自己能够大概知道。

七、同学们对课程的建议及其他

共有八个同学做了这次的附加作业，以下用 1. 2. 3. ... 8. 来标识不同同学的回答。

（1）你认为每次项目的评分标准存在哪些问题，你认为的合理评分准则是怎么样的

  1. 个人：发布的题目里没有具体的评分细则，个人作业环节的分数悬殊很大。个人认为可以在发布题目的时候就将各项分数写在题目要求中。

    结对：这部分很难断定两个同学分分数，容易出现只有一个人做了全部，另一个沾了光。应该设置相应分差值。

    团队：这部分分数主要是助教根据博客情况来评分，但其实在博客上容易掺假，有点团队可能一点代码都没怎么写，在最后展示环节根本展示不出来，但是博客的分数却十分高。建议展示环节的分值可以设得高一点。

  2. 从贡献度、完成度、完成质量、是否进步（比如因为专业知识掌握不多，第一次没有做出来，但是通过学习，第二次能自己顺利完成作业）等角度进行评分

    在个人作业方面，增加个人进步这一注重点，

    在结对编程中，要考虑角色分配的比重与个人贡献度

    在团队作业中，我希望能把alpha beta阶段的团队博客拆分出来，每个人自己当天的任务和都做到了什么，学到了什么都写在自己博客上，每个人都要写，不然很容易出现某些学生其实什么都没有做，博客也没有参与写，全程划水。然后在alpha beta阶段结束时，上交一份汇总博客（内容包括小组成员分工，项目完成度，燃尽图，各成员博客链接等）

  3. 个人：在得知项目分的时候才看到具体的得分点，容易丢失细节分。

    合理评分标准：在发布作业时应该明细各个得分点，方便同学根据要求写博客。

    结对：在coding部分结对两人分数不应该默认相同，应该有相对的贡献分，虽然大家比较主张贡献相同，但对一些队员完全没做事，自己完成所有工作的人来说至少有选择是否需要说明这种情况的机会。

    合理评分标准：设有结对贡献分，但不需要强制要求成员贡献分必须不同，给成员自己选择的权利。

    团队：评分以博客展示为主，未免有些不合理。这样的评分标准对一些表达的相对简单，但项目完成度较高的团队来说有很多的影响，团队分所占的比例较大，很影响团队中成员最终的成绩。

    合理评分标准：设有团队贡献分，但不需要强制要求成员贡献分必须不同，给成员自己选择的权利。以博客展现和项目完成度两方面来评分。

  4. 个人：感觉博客所占评分标准过重，有的时候花很长时间完善代码，但博客写的没别人好，或者没有写全得分点，导致最后分数偏低。导致大家更加关注如何写好博客，而不是代码，感觉有点轻重倒置。我认为可以把博客和代码的按一定的比重区分开，比如：博客占40%，代码占60%。

    结对：我认为可以要求小组公开任务分配情况，或者加入队员互评作为助教评分的参考。

    团队：对“每个人贡献分必须不一致”这一点不是很认同。作为一个学生团体，很多时候大家在团队中所做的贡献都是差不多的。即使可能有一两个作为主力在编代码，可是其他人也可能在其他方面也付出了很多（比如“写博客”）。我认为可以考虑附加分的形式，由团队自己决定是否给团队的某一或两位成员加分。且团队冲刺阶段所占的分数比重过大，因为一个点没有写被扣了分，7天累加扣了近10分，后面感觉再怎么努力也很难追回。我认为一个冲刺阶段可以按照1次作业分数计算，而不是7次。

  5. 在评分标准这一块，真的很详细，从个人到结对再到团队，真的越来越详细，我觉得老师和助教在这个方面真的很辛苦，做的很棒了。

  6. 个人作业：不知道具体的得分点在哪，结果博客没写出重点，分数就比较低了。可以在发布作业的时候公布得分点，这样能让我们充分展示自己的代码成果。

    结对编程：大家的任务分配不同，可以设置一定的贡献值。

    团队作业：冲刺阶段的博客评分可以最后统一评，不用依照每天的博客给分。

  7. 感觉不仅是个人项目，对于结对/团队项目而言也同样存在这样的问题，即过分重视博客的展现，实际做的努力往往在展示中不好体现出来，有的同学/团队态度很认真、做事很努力，但是由于基础比较差而没能写出漂亮的程序，但是在他（们）做的过程中获得的进步却并不比那些基础好的同学小。但是由于博客评分占比非常大，所以在博客上展示出来的成果由于并不突出而得到较低的评分，这样还是挺受打击的。我觉得做任何事情态度永远是第一位，三流的点子一流的执行远比一流的点子三流的执行要有效的多。所以我希望将展示博客的评分占比稍微降一下，多关注一下那些基础差但是很努力的同学（团队）。

  8. 1）在个人编程上有些编程能力比较强的人可能投入的时间并不是很多，但是对于编程较差的人需要花很多的时间来完成，这样的话基础差的人时间扫对于博客的编写质量就不会很 高，花很多的时间的的分还不高。这个真的是一个很难解决的问题。

    2）在结对上面不仅有编学程能力较好的和编程差的同学的结合会导致大部分编程好的同学在写可以说是付出较多的人，但是博客编写不怎样就会导致反而分不高的问题会让人失衡，编程水平相当的人也会有一定的问题存在。我觉得结对编程也可以出现贡献分的

    3）在团队评分上应该不仅是看表面很更应该关注背后的东西。

    总结：不论是个人还是组队和团队我觉得博客的比重真的占太多是的有的人实际做的很多的人或这是小组却因为博客的问题而没有得到对应的分数，这样的结果会很打击人。

（2）你的团队项目是否成功，如果重来一次你是否还会选择这个团队，为什么成功/失败

  1. 我个人认为是成功的，虽然我们团队在过程中遇到过一些困难和问题，但我们团队最终还是完成了，所以是成功的。

    重来一次我还会选择这个团队，因为我们相互磨合，配合还算默契。

  2. 算是成功。我都可以，我个人觉得我这个人适应能力强，而且没那么多挑剔，在哪里都可以，我都可以努力的去完成项目，真正的学到东西。
    这门课上，我确实花费了很多很多时间和精力。虽然最后分数不高（因为博客没有即时交），对于我个人的提升是非常大的

  3. 我的团队项目总体来说是成功的，虽然与最初的需求分析有些许偏差，但基本的功能都已经实现，可以使用。如果重来一次当然还会选择这个团队，虽然中间有懈怠，但成员们也都尽可能完成分内的工作，不存在有人什么都没做，有人包揽所有工作的现象，所以最终项目才能成功。

  4. 我认为团队总体还算成功的。如果再来一次我也还会选择这个团队。虽然在这整个团队合作的过程中，我们遇到了很多的困难，也经历了所有人心态都很低迷的期间。但大家也都没有放弃过，坚持到了最后。而且在这个期间，大家互相也变得更加了解，有了一定的默契。

  5. 我觉得我们团队是成功的，因为虽然在这个过程中我们可能会出现一点小问题，比如有时候博客没能及时上交，或者谁谁谁的任务太难没能及时完成，但是通过我们的共同努力，我们还是把一个app做出来了。虽然这个app没有完成全部的功能，像光荣榜这些功能没有能实现，但是我们基本的功能都有实现了，像随机发牌啊，计算啊，背景音乐啊等等，作为一个app，是能让人玩的起来的，所以我觉得也算是成功了吧，毕竟大家斗没经验。

  6. 我认为算是比较成功了，因为最后成品也做出来了，虽然部分功能没有实现。如果重来一次，我还会选择这个团队，因为我觉得我们配合很默契，分工也比较合适。

  7. 我认为我们团队起码在态度上是成功的，我们小组真的没有大神一般的人物，全是基础很差的同学，对于项目的实现基本上就是现学现卖，时间非常赶，虽说没有做出华丽的界面和强大的功能，但是我们确实花了大量时间做了很多事情。可能在成果上我们是失败的，但是我们态度上是认真对待的，也学到了很多东西，在这一点上我觉得我们还是成功的。如果重来一次，我还会选择这个团队。

  8. 为什么不要呢？团队合作会有推脱会有不愉快但这就是团队，团队的团结和认真态度做到了我觉得我们就是成功的。

（3）总结一下你们团队在做项目时大家的时间安排情况

  1. 我们代码部分是根据每次小组会议中商讨的去分配，也都有写在博客中，大家根据自己博客中所制定的计划自行进行安排。而撰写博客部分，每日博客是团队成员轮流根据团队实际情况轮流完成。

  2. 别人我不知道，这个学期所有空余时间都在图书馆写实验报告，做软工项目

  3. 团队在做项目的时候有估量每个任务需要花费的时间，对项目中每一个任务都安排相应的成员完成，但团队成员在完成过程中可能因为自身效率问题导致所花费的时间也不同。总之，大家都会在自己课余时间完成自己分配到的任务。

  4. 大家基本上是各写各的部分，然后利用课间期间和周末晚上开会讨论。即使有成员因为身体原因经常不在学校，也依然能够按照要求完成自己所分配的任务。

  5. 我觉得我的时间安排就不大合理，上次的个人总结就是个人原因没能及时上交，是我的问题，后面也没有问同学如何处理，做事情台拖拉，不够主动，也因此吃了亏被扣了分。也因此得到了教训，吃一堑长一智，以后再也Q不敢了。队友们基本都能按时完成任务，毕竟是团队，不能拖大家的后腿，所以大家完成的还算及时，不过大家也是在最后的时间里赶工，这个好像是大家的通病（QAQ），要改。

  6. 我们的代码分配是根据小组会议的商讨，然后大家各自完成自己的部分，每天晚上会有固定的交流。而撰写博客部分，博客是团队成员轮流根据团队实际情况完成，基本大家都有写。

  7. 我们团队中，队长分配的任务大部分都是很明确的，大家做好分内的事情就可以了，有些事情有交集大家也都会互相交流探讨解决方案，由于分配到的任务不一样，个人的基础也不一样，所以也很难量化每个人的工作，但是能肯定的是大家都认认真真做好了自己分内的工作。

  8. 嘿嘿！主要还是队长的安排，按时按量完成自己应该做的事情。

（4）软件工程这门学问有很多 “知识点”， 这门课强调 “做中学” - 在实践中学习知识点。请问你们在项目的 需求/设计/实现/测试/发布/维护 阶段（一共6 个阶段）中都学到了什么 “知识点”， 每个阶段只要说明一个知识点就可以。

  1. 需求：学会了如何撰写需求说明书，需要描述用户场景，从用户的角度去分析需求，怎么样将用户所提需求具体化成实际需要开发的功能。

    设计：主要是学会了整个设计的流程，具体需要做些什么，如何设计，如何实现。

    实现：主要是对整个项目的各个方面进行总结和分析，学会如何在总结中学习和进步。

    测试：之前对测试这块很不清楚，涉及不深。通过学习，知道了许多测试工具以及测试工具的使用，尤其是如何测试这部分。

    发布：知道了发布流程，如何展示项目，如何向用户说明我们的应用。

    维护：知道了维护阶段的具体做法，需要如何维护，如何使得用户得到最好的用户体验。

  2. 需求阶段：学会了在项目开发之前一定要了解用户需求，以及如何用图表等将收集到的有用信息清晰的展示给自己的组员

    设计阶段：学会了利用任务分解WBS等来清晰的构架项目轮廓，不仅能够清晰的划分出任务模块，还可以便于任务划分

    测试阶段：学会了如何设计测试计划，如何多方面去测试项目（如性能测试，压力测试，测试矩阵等）

    发布阶段：学会了如何去发布软件，并给出软件介绍和运行环境

    维护阶段：学会了运用腾讯的bugly来收集软件反馈的日志信息，再通过不断的完善优化对其进行维护

  3. 需求：学到通过用户调研来获取用户需求。

    设计：学习利用架构设计最大限度的满足获取的需求。

    实现：需要有明确的时间任务安排，按照设计文档完成代码实现项目需求。

    测试：通过撰写测试报告可以明确项目所需做的测试、时间安排等。

    发布：从代码完成到最后发布，经过了Alpha、Beta、ZBB等阶段，不断完善发布。

    维护：多次测试，发布后及时发现问题提供维护。

  4. 需求阶段：学会使用NABCD模型进行需求分析；

    设计阶段：学会了把功能进行细分，从而提高编程效率；

    测试阶段：学会使用Junit进行代码测试；

    实现阶段：学会使用燃尽图掌握项目进度；

    发布阶段：学会了发布的流程，以及展示博客的编写，如何对项目进行展示；

    维护阶段：对bug有了更深的理解，并学会根据用户反馈进行维护、改进。

  5. 在需求分析阶段我学会了NABCD模型分析，设计阶段学会使用墨刀来设计app的界面，在实现中学会搭建安卓坏境，用java语言编写并打包成app，在测试环节学会了如何弄代码覆盖率，发布之后开了诸葛亮会议，维护就是不断的升级和优化。

  6. 需求阶段：学会使用NABCD模型进行需求分析，还有如何撰写需求说明书；

    设计阶段：学会了使用功能优先级，选择最核心的杀手功能；

    实现阶段：学会使用燃尽图掌握项目进度；

    测试阶段：学会使用测试工具对代码进行测试；

    发布阶段：学会了展示博客的编写，如何对项目进行展示；

    维护阶段：学会了维护阶段的具体做法，需要如何维护，如何使得用户得到最好的用户体验。

  7. 在需求中，我们学会了一种获取用户需求的方式——调查问卷；

    在设计中，我们学会了用一些在线工具完成项目的原型设计；

    在实现中，我们学会了前端与后端的联系以及数据库在程序设计中的重要性；

    在测试中，我们学会了对项目bug进行自查；

    在发布中，我们学会了对项目进行相关的宣传；

    在维护中，我们学会了根据使用者的反馈进行相应调整。

  8. 需求：需求分析对于一个项目是一个里程碑的存在，需求分析好对接下来项目的进展少走弯路起到质的作用。需求分析工具的使用、需求报告的编写。

    设计：软件是怎么解决需求的？通过图形建模和思维导图。

    实现：代码模块化的编写。

    发布：要考虑用户体验是使用场景。

    测试：学会了使用测试工具和测试类。

    维护：保证服务器的正常运行。

八、致谢

感谢各位老师对我的包容与鼓励，我这个助教做的实在是不合格。

感谢邹欣老师和周筠老师提供给我一次做软工助教的机会。邹欣老师工作之余大量评论同学们的博客，实在令人佩服。我现在只能想着工作几年之后想办法为教育做一些贡献，而邹欣老师已经在教育方面做了很多贡献，是一个好的榜样。

感谢周筠老师和范飞龙老师与我分享经历和指出我的问题。当时头脑不冷静，想着反驳而不是冷静下来好好分析自己，做出了幼稚的表现。

感谢张敏老师对我的支持，同时也很抱歉，首次使用这种教学方式就碰到了我这样的助教。

感谢同学们，你们让我看到了我自己的很多不足之处，让我得以不断进步。这学期对你们太过于严格了，很少对你们的优秀之处进行表扬。

最后感谢张栋老师（栋哥），正因为您有改革的精神和实际的行动，我才有机会接触构建之法，进而才有这段宝贵的经历。

posted @ 2017-07-07 20:54  schaepher  阅读(684)  评论(16)  编辑  收藏  举报