1.开发时间预估
|
PSP2.1 |
Personal Software Process Stages |
Time |
|
Planning |
计划 |
|
|
· Estimate |
· 估计这个任务需要多少时间 |
2day |
|
Development |
开发 |
|
|
· Analysis |
· 需求分析 (包括学习新技术) |
8h |
|
· Design Spec |
· 生成设计文档 |
4h |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
3h |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
2h |
|
· Design |
· 具体设计 |
8h |
|
· Coding |
· 具体编码 |
8h |
|
· Code Review |
· 代码复审 |
3h |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
4h |
|
Reporting |
报告 |
|
|
· Test Report |
· 测试报告 |
3h |
|
· Size Measurement |
· 计算工作量 |
2h |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
3h |
|
合计 |
48h |
2.实际开发时间
|
PSP2.1 |
Personal Software Process Stages |
Time |
|
Planning |
计划 |
|
|
· Estimate |
· 估计这个任务需要多少时间 |
2day |
|
Development |
开发 |
|
|
· Analysis |
· 需求分析 (包括学习新技术) |
12h |
|
· Design Spec |
· 生成设计文档 |
3h |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
2h |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
2h |
|
· Design |
· 具体设计 |
12h |
|
· Coding |
· 具体编码 |
12h |
|
· Code Review |
· 代码复审 |
2h |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
3h |
|
Reporting |
报告 |
|
|
· Test Report |
· 测试报告 |
2h |
|
· Size Measurement |
· 计算工作量 |
1h |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
2h |
|
合计 |
53h
|
3.性能分析&改进
a.测试输入为 -r 10 -n 10 时对应的性能分析图以及程序中各个函数的消耗。
b.测试输入为 -r 10 -n 100 时对应的性能分析图以及程序中各个函数的消耗。
c.测试输入为 -r 10 -n 1000 时对应的性能分析图以及程序中各个函数的消耗。
d.测试输入为 -r 10 -n 10000 时对应的性能分析图以及程序中各个函数的消耗。
e.针对生成的10000道四则运算题目，测试输入为 -e Exercises.txt -a Answers.txt 时对应的性能分析图以及程序中各个函数的消耗。
性能的优化以及改进
1.fopen函数在函数调用图中可以看出占用了大量的时间（特别是在生成四则运算题目较少时尤为明显），在一定程度上会影响性能，这也是由读取硬盘与读取内存速度差异造成的。由于程序设计是有两个要求，一个要求随机生成四则运算表达式并把答案写入文件，另一个要求读取文件评测并且输出结果至文件，所以没有必要同时打开多个文件，而在判断输入参数结束后才打开相应的文件，这样节省了之前全部打开文件时fopen操作所花的进一半的时间。
2.在四则运算评测的时候，由于我对于真分数采用字符串进行表示以及存储，所以不停地读写字符串，造成了sscanf，sprintf大量的调用因而耗费了大量的CPU时间，其实对于字符串的存取可以采用将真分数用struct结构定义的方法来替代，这样可以大量的省去读写字符串所耗费的CPU时间，而且struct的存取和字符串的存取相比空间占用差不多甚至可能更少，所以可以使用struct来提高程序性能。
4.测试用例&程序正确性分析
测试用例
1.测试输入为 -r 10 -n 10000，程序正常执行。
2.测试输入为 -n 10000 -r 10，程序正常执行。
3.测试输入为 -w 10 -s 10000，程序给出参数错误提示信息。
4.测试输入为 -r 10 ，程序给出参数不足的提示信息。
5.测试生成10000题目，能够生成10000道题目，并且均为自然数、真分数表示，且符合四则运算合法表达式的要求。
6.测试生成大量题目，输入为 -r 10 -n 50000，程序运行78s结束，输出结果。
7.测试生成大数题目，输入为 -r 100 -n 100，题目计算过程中可能产生越界，越界的题目计算结果为空，但是程序不会崩溃。
8.随机生成100题目，检查是否有中间结果产生负数，是否出现除法时候分母为0，经过检查，没有负数以及除零情况的出现。
9.随机生成10000题目，检查是否存在俩个相同的题目，经过检查，没有相同题目出现的情况。
10.手工写10个正确的四则运算题目，并且给出10道题的随机答案，经过程序运行能正确的进行评判。
正确性分析
程序能够实现问题描述的所有功能需求，且具备有一定的鲁棒性。
5.收获&感悟
1.由于对c语言的语法有些淡忘，所以在编写程序时候对于真分数的表示采用了直观的字符串处理，而没有把其作为一个具有内在联系的整体定义为一个struct，所以在代码编写后期陷入了字符串处理的泥潭不能自拔，导致开发速度下降而且频繁出bug，归根到底前期考虑不周到，准备工作不充分，因为害怕不能在规定时间完成而过早的投入到代码的编写过程中导致浪费了更多的时间，所以我会在之后的开发中更多的精力放在编码前的准备当中，以期达到事半功倍的效果。
2.从测试的角度来说，开始时我使用自己的程序生成的四则运算题目，继而读入自己生成的题目文件进行评测，或者根据自己认为可能出问题的点设计测试，发现结果没有问题，我就以为大功告成，后来通过其他同学的测试结果发现出现了几处错误，后经调试发现是自己在一个小点儿上出现了盲视，直接忽略了其存在的可能性，所以我觉得当你自己觉得没问题时候要善于接受不同的考验，这样才能发现自身忽略的细节，这也是结对编程和团队合作的优势所在吧。