Github项目地址：https://github.com/brisksea/PairProject2018
PSP表格：
| PSP2.1 |
Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 20 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 240 | 360 |
| Development | 开发 | 180 | 240 |
| Analysis | · 需求分析 (包括学习新技术) | 20 | 30 |
| · Design Spec | · 生成设计文档 | 20 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 10 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| · Design | · 具体设计 | 20 | 20 |
| · Coding | · 具体编码 | 180 | 200 |
| · Code Review | · 代码复审 | 20 | 30 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 30 |
| Reporting | 报告 | 30 | 60 |
| · Test Report | · 测试报告 | 30 | 30 |
| · Size Measurement | · 计算工作量 | 30 | 30 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 30 | 30 |
| 合计 | 240 | 360 |
注：对于PSP表格，因为工程量较小，因此对于其中的小环节有很多互相穿插，因此总时间下有许多并行时间过程，故而合计时间小于所有分项时间和
解题思路
乍一看本次培训的第一个题目是“实现一个能够对文本文件文件中的单词的词频进行统计的控制台程序。”，于是就第一瞬间的解题思路就靠在了传统的词频统计算法上面，我们都知道词频统计被广泛的用于计算机基础编程教学的过程中，在此之前我们也多次接触过有关词频统计的知识。再看题目有许多细微的小要求，使其有别于传统简单的词频统计，但是大体的架构还是不变的，于是有了基本的解题思路。
设计实现过程
在初步的观察完毕题目的细微设计要求后，我们有意图将主要功能分为以下几个类，如字符数统计、单词总数统计、有效行数统计、单词频数统计以及文件流处理等模块。在具体的实现过程中，我们使用了split分句，并对要求的单词进行筛选，筛选完毕后建立哈希表，并先做到了单词频数统计这一功能，在这一功能的基础上，将其和累加得到单词总数统计的结果。对于字符数统计，采取的是返回长度的方法。
改进思路
在处理单词频数统计这一子功能上，我们首先没有引入split方法，直接采用了传统的遍历分割的方式，导致本功能与其他功能混合在一起，一来不是很美观，二来从封装的角度来讲违反了程序设计的基本要求，改进后提升了程序子功能的独立性，优化了程序整体的组织结构。由于时间问题，以及本程序采用了java设计，因此暂时未能按照要求采用VS 2017自动生成性能分析图。
收获与经历
在以往助教的过程中，鲜有机会像今天一样，如同学生一般自己手动在上课这种很短的时间内与他人合作，密集而高强度的编写代码。这种体验令我印象深刻、感触颇多。事实上，一个人悠哉的编写代码和软件工程这种为了一个明确目的多人协作，在固定的时间和其他客观条件限制下的代码开发过程是截然不同的。而我们开设软件工程这门课的目的，恰恰就是训练学生这种面向实际问题的，企业导向式的工程开发能力，随着本次的体验，我也感受到了一些学生们在实际操作过程中可能遇到的问题，如基本功不过关不扎实，以及遗忘了部分函数以及语法，或者是调试过程中出现形形色色的问题等，这些暴露出的问题将有助于我未来参与助教工作，进一步的提高我的助教水平，使得我以后更能站在学生的角度改善我们的教学计划，使得我们的软件工程教学更加面向实际，达到我们设想的目标。