1.开发时间预估编程
PSP2.1函数 |
Personal Software Process Stages性能 |
Time学习 |
Planning测试 |
计划优化 |
|
· Estimate编码 |
· 估计这个任务须要多少时间spa |
2day设计 |
Development3d |
开发 |
|
· 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.从测试的角度来讲,开始时我使用本身的程序生成的四则运算题目,继而读入本身生成的题目文件进行评测,或者根据本身认为可能出问题的点设计测试,发现结果没有问题,我就觉得大功告成,后来经过其余同窗的测试结果发现出现了几处错误,后经调试发现是本身在一个小点儿上出现了盲视,直接忽略了其存在的可能性,因此我以为当你本身以为没问题时候要善于接受不一样的考验,这样才能发现自身忽略的细节,这也是结对编程和团队合做的优点所在吧。