作业地址: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.总结与未来期望
实际上我们这次结对编程所实现的功能还是很有限的,关于单词的提取与操作还有更多功能可以实现,但重要的是,我们通过这次作业体会了结对编程的优势,当处理双方都很擅长的任务时,可以快速地处理并实现。但一旦处理到了较有挑战的问题时,一旦双方的实力都不是很强,那么就容易发生分歧,走上弯路,凭空耗费时间。这是我理解到,结对编程是对双方编程能力的共同考研,一旦双方都同时缺乏某一问题的处理能力就容易陷入困境。
通过这次结对编程的体验,我了解到不断学习,提升个人能力,以及和小队成员的默契互补都很重要。
(以上为我们结对讨论的场景。)