第三次作业

作业地址：https://edu.cnblogs.com/campus/xnsy/SoftwareEngineeringClass2/homework/2879

github地址：https://github.com/Anzerl/-

1. PSP表格

PSP是卡耐基梅隆大学（CMU）的专家们针对软件工程师所提出的一套模型：Personal Software Process (PSP， 个人开发流程，或称个体软件过程)。

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	30
· Estimate	· 估计这个任务需要多少时间	20	30
Development	开发	290	330
· Analysis	· 需求分析 (包括学习新技术)	20	20
· Design Spec	· 生成设计文档	15	20
· Design Review	· 设计复审 (和同事审核设计文档)	15	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	20	20
· Design	· 具体设计	30	30
· Coding	· 具体编码	150	170
· Code Review	· 代码复审	20	20
· Test	· 测试（自我测试，修改代码，提交修改）	20	20
Reporting	报告	60	50
· Test Report	· 测试报告	15	20
· Size Measurement	· 计算工作量	15	10
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	20	20
	合计	370	400

 

2. 讨论与实现

   项目分析:

（1）首先我们需要设计一个能统计出文本的字符总数的函数；

（2）实现对行数的提取；

（3）进行单词数的相关操作；

（4）在原型程序的基础上实现进一步的功能拓展。

（5）对项目进行单元测试和效能分析。

     

   程序有三个类，分别是行数，字符数，以及单词统计wordCount，依据需求，按模块细分，关键程序如下：

 1.两个基本功能的结对编程1实现

   因为基本功能的简单，我们默契地进行结对编程，有效率地在短时间内完成了行数的统计以及文本字符数的统计。

   对于文本文件进行行数的统计。在这里，我们声明了一个类来实现这个功能。

    通过一个队行数的简单while循环来实现。

 

  在这里，我们声明一个int类，来实现对文件的字符数的提取。

  通过将字符储存到数组中，并得到数组长度来输出关键的文本字符数。

2.新功能的开发以及结对编程中分歧点的克服

   最关键的一步是对单词的统计处理，一开始我们对于如何进行单词的提取产生了一些分歧。但在经过讨论，我们选择通过while循环的连续判断来识别出单词，并进行输出。但由于我们对ASCII码的不够了解，使我们在whlie循环语句的判定问题上出现了连续的错误，得不到想要的结果，耗费了大量的时间。在这一步我们产生了一些分歧。

  最后经过讨论，我们决定放弃原来的思路，重新编程，通过对已经实现了的功能——字符数的提取的利用，我们在一个for语句下进行嵌套，最后成功实现了单词提取的功能。

3.设计

  以下是我们关于编程的设计图的简单表示

  

3. 后续测试分析与总结

1.测试

  利用C#单元测试功能，通过接口来实现预期功能的检验。我们使用的文本是《Pre-Parade》的歌词，预计有1811个字符，41行以及189个单词。我们分别进行了测试，均与预期相符。

  以下是功能的实现截图：

 

 2.效能分析

  VS自带强力的效能分析，这里是VS2013版本。我们可以快捷地得到各函数的执行时间以及其他性能的测试。

  以下是一次关于函数执行时间的效能分析截图：

 

3.总结与未来期望

  实际上我们这次结对编程所实现的功能还是很有限的，关于单词的提取与操作还有更多功能可以实现，但重要的是，我们通过这次作业体会了结对编程的优势，当处理双方都很擅长的任务时，可以快速地处理并实现。但一旦处理到了较有挑战的问题时，一旦双方的实力都不是很强，那么就容易发生分歧，走上弯路，凭空耗费时间。这是我理解到，结对编程是对双方编程能力的共同考研，一旦双方都同时缺乏某一问题的处理能力就容易陷入困境。

  通过这次结对编程的体验，我了解到不断学习，提升个人能力，以及和小队成员的默契互补都很重要。

 

 

   （以上为我们结对讨论的场景。）