Github项目地址
PSP表格
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 20 | 20 |
| · Estimate | · 估计这个任务需要多少时间 | 20 | 20 |
| Development | 开发 | 1255 | 1425 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 100 |
| · Design Spec | · 生成设计文档 | 40 | 40 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 30 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 40 | 40 |
| · Design | · 具体设计 | 120 | 110 |
| · Coding | · 具体编码 | 800 | 1000 |
| · Code Review | · 代码复审 | 60 | 60 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 45 | 45 |
| Reporting | 报告 | 100 | 100 |
| · Test Report | · 测试报告 | 50 | 45 |
| · Size Measurement | · 计算工作量 | 30 | 35 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 1375 | 1545 |
解题思路
刚拿到题目时，则是运用第二次作业的成果，在此基础上做一个相应的界面即可，由于我们用过的语言是C和Java，所以我们选择了在VS上利用C#写相应的界面，完成题目的基本要求。对于题目中我们不熟悉的语言转换的问题，直接在网上百度相应的代码，稍加修改。网上前辈的方法也进行了相应的参考：http://www.cnblogs.com/1175429393wljblog/p/5267918.html 。
出现分歧时都会首先考虑到代码的实现难度以及用户在使用过程中的方便程度，进行相应的讨论，比如在进行多语言转换的过程中会存在界面的某些显示转换比较麻烦，界面看起来觉得会比较多余，没有什么必要的存在，我们最终选择删除，降低难度的同时也使界面看得更舒服。
设计实现过程
代码说明
测试运行
未清零的正确题数和错误题数都会保存并显示，完成基本需求。
实现中文到英文，以及繁体字的转换。
完成指定题目之后点击结束得到所得分数。
当想要对正确和错误题目数清零时，点击清零即可。
整个软件完成了基本要求。
测试过程中出现了些许问题是因为开始没协调好，但是后来交流沟通后都得到了解决。
合作情况
张宇光2017282110242：当我在码代码的同时，伙伴对我的一些指导，给出的建议对于我们的工作都很有帮助，感觉比一个人进行工作的时候更加顺畅，总会发现自己平时注意不到的问题。当队友在进行编程时，自己在旁边观察，有一些自己不会的东西，在他进行工作的同时还可以教我许多不会的知识，受益匪浅。在遇到问题的时候会一起讨论解决问题，会出现多种不同的解决方式，经过讨论之后的解决方法可能不是最好的，但是一定是在某种程度上，我们都觉得不错的方案。在角色切换的过程中，会出现队友的代码有的地方自己不太懂，缺少注释的问题，对于这样的情况一般都会在后面再加上一些注释，给自己的队友作相应的解释。这一次的作业很大一部分是我的队友指导我做的，他的得分应该比我高一些，我还需要学习，有很多的不会的知识，向我的队友学习。
项目小结
张宇光2017282110242：在此次的项目中，了解了结对编程中间可能会出现的一些问题，以及如何却解决相应的问题，在讨论的过程中对项目进行相应的改动。在解决问题的过程中，虽然是两个人，但是还是会存在一些不会的问题，有些想要实现的东西，由于时间和能力有限的关系，只能暂时搁置，能力还需要提升，不能得过且过。在写代码过程中，对于文件的调用以及修改还并不是很熟悉，缺少了某些关键步骤的时候，始终都解决不了，然后死脑筋觉得自己写的没问题，但是经过伙伴的指导之后，还是发现了问题，在出现问题的时候还是需要多找找资料之类的，能力不足的地方需要努力。在提交代码的过程中，并没有实时更新，最后两天找到以前的版本进行提交，再将最终的版本提交，所以只能看到我们组的两次提交，这个对于老师观察我们的进度有些影响，下次会进行改进。
结对照片