个人第三次作业——结对编程
1.编码要求
(1)Fork github 项目https://github.com/Cherish599/PairProgramming到自己的仓库,在Github仓库中新建一个以一位同学的学号为名的文件夹,用于建立C#的项目和第二次作业类似。(结对的两人中任意一人的学号都可以)。
(2)在开始实现程序之前,在PSP表格[附录1]记录下你估计在程序开发各个步骤上耗费的时间,在你实现程序之后,在PSP表格记录下你在程序的各个模块上实际花费的时间。
(3)使用C#语言实现,C#请使用Visual Studio Community 2017进行开发。
- a) 制定编码规范,可以参考C#语言的规范:简版,讨论版。(邹欣老师在讲义“现代软件工程讲义 3 代码规范与代码复审”中所讨论的有关代码规范与代码复审的内容。内容短小精炼,适合快速入门。)
- b) 代码自审并修正,每个人都独立完成了自己的功能任务,对照编码规范,审查修改自己的程序代码并使其符合规范要求。
- c) 代码互审,按照共同制定的编码规范,审查合作伙伴的代码并记录发现的问题。
- d) 合并代码,两人协商,将两部分代码合并,形成初始版本。注意应设计合理的软件结构及模块划分。
- e) 使用Github[附录2]来管理源代码和测试用例,代码有进展即签入Github(至少三次)。签入记录不合理的项目会被助教抽查询问项目细节。
- f) 使用单元测试[附录3]对项目进行测试,并写出测试用例确保你的程序能够正确处理的各种情况。
- g) 在完成结对项目后,请按照预第二次作业的方式正确地发起一个Pull Request,并设置标题为本次统一使用的学号。
2.博客撰写要求
(1)在文章开头给出结对使用的Github项目地址和结对伙伴的作业地址。(两个人使用同一个)注意:GitHub的地址必须是用于clone的地址即如下图片中的地方获取。(如果不是这个地址,助教就无法批量编译运行你们的程序,出现问题的都会被助教抽中询问详情)
描述结对的过程,提供非摆拍的两人在讨论的结对照片(一起工作编码时的照片)。
(3)给出结对的PSP表格。
- a) 解题思路描述。即刚开始拿到题目后,如何思考,如何找资料的过程。
- b) 设计实现过程。设计包括代码如何组织,比如会有几个类,几个函数,他们之间关系如何,关键函数是否需要画出流程图?单元测试是怎么设计的?
- c) 给出你们制定的代码规范或链接,记录你们代码互审的情况,审查的模块名、发现的问题等。
- d) 代码说明。展示出项目关键代码,并解释思路与注释说明。
- e) 结合在构建之法中学习到的相关内容与结对项目的实践经历,撰写解决项目的心路历程与收获,以及结对感受,是否1+1>2。
注:两人都要提交博客,结对共同部分,可在其中一个人的博客给出(另一个人给出链接),不同部分分别写在自己的博客中。
3.项目需求说明
实现一个WinForm随机点名的程序或者骰子游戏
第一步、实现基本功能
- 1、winform界面设计
- 2、实现班级学生的随机点名
第二步、接口封装
- 1、体现类的设计
- 2、体现分层思想
第三步、增加新功能
- 1、学生数据的加载
- 2、进度条跟踪
第四步、附加功能
- 1、小组的创新性功能设计
第五步、设计单元测试
- 请各位使用单元测试对项目进行测试。 并给出测试用例
4.评分细则
博客评分规则(总分100)
(1) 在文章开头给出你们Fork仓库的Github项目地址。(5')
(2) 在开始实现程序之前,在下述PSP表格记录下你估计将在程序的各个模块的开发上耗费的时间。(5')
(3) 计算模块接口的设计与实现过程。 设计包括代码如何组织,比如会有几个类,几个函数,他们之间关系如何,关键函数是否需要画出流程图?说明你的算法的关键(不必列出源代码),以及独到之处。并讲讲你的设计是如何体现“Design by Contract”、“Information Hiding”、 “Interface Design”、 “Loose Coupling”等原则的。(45)
(4) 代码复审过程。代码互审情况、发现的问题等。(15‘)
(5) 计算模块部分单元测试展示。 展示出项目部分单元测试代码,并说明测试的函数,构造测试数据的思路。并将单元测试得到的测试覆盖率截图,发表在博客中。(15')
(6) 描述结对的过程,提供非摆拍的两人在讨论的结对照片。(5')
(7) 在你实现完程序之后,在附录提供的PSP表格记录下你在程序的各个模块上实际花费的时间。(5')
(8) 附加功能(5)
5、附录
1、PSP表格
PSP是卡耐基梅隆大学(CMU)的专家们针对软件工程师所提出的一套模型:Personal Software Process (PSP, 个人开发流程,或称个体软件过程)。
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
Planning | 计划 | ||
· Estimate | · 估计这个任务需要多少时间 | ||
Development | 开发 | ||
· Analysis | · 需求分析 (包括学习新技术) | ||
· Design Spec | · 生成设计文档 | ||
· Design Review | · 设计复审 (和同事审核设计文档) | ||
· Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | ||
· Design | · 具体设计 | ||
· Coding | · 具体编码 | ||
· Code Review | · 代码复审 | ||
· Test | · 测试(自我测试,修改代码,提交修改) | ||
Reporting | 报告 | ||
· Test Report | · 测试报告 | ||
· Size Measurement | · 计算工作量 | ||
· Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | ||
合计 |
- 一个功能完备的程序不是一蹴而就的。通过将WinForm随机点名的程序或者骰子游戏的需求划分为4个部分,可将一个大任务划分为可操作的小任务,同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此,在动手开发之前,要先估计将在程序各模块开发所需耗费的时间,以及完成整个项目所需的时间,将这个[估计值]记录下来,写成PSP 的形式。
- PSP的目的是:记录工程师如何实现需求的效率,和我们使用项目管理工具(例如微软的Project Professional,或者禅道等)进行项目进度规划类似。
- 有关PSP的更多内容,请自行阅读邹欣老师的博客:
http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html
2、 Github
请阅读邹欣老师的博客:源代码管理,了解源代码管理的10个实践问题。
本次作业要求使用Github进行源代码管理,代码有进展即签入Github。签入记录不合理的项目会被助教抽查询问项目细节。
对代码签入的具体要求如下:根据需求划分功能后,每做完一个功能,编译成功后,应至少commit一次。本例中,至少应区分基本功能和扩展功能,即分别针对基本功能、扩展功能,编译成功后,总共至少应commit两次。具体的功能划分,请自行定义,并在撰写博客时体现出来,遵循自己对需求的功能划分来提交代码即可。
对Commit不是很熟悉的话,请阅读阮一峰的博客:Commit message 和 Change log 编写指南,了解更多细节。
3、单元测试
请根据自己以往积累的测试经验,在编码完成之后,提交产品之前,设计测试用例,并编写单元测试,对自己的项目进行测试。
首先,至少应采用白盒测试用例设计方法来设计测试用例,其他测试方法不限。其次,要设计至少10个测试用例,确保你的程序能够正确处理各种情况。最后,结合测试评估的要求,对自己的测试设计进行评价,这些测试用例能满足该程序测试的要求吗?
另一个重要的措施是要把单元测试自动化,这样每个人都能很容易地运行它,并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的,这样每个单元测试的错误就能及时被发现并得到修改。
推荐阅读邹欣老师关于单元测试和回归测试的博客:
http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html
6、提醒
(1)代码不要出现抄袭或者直接拷贝的现象,一旦发现作业将没有成绩。(允许模仿,但一定要有自己的理解和改进)
(2)确保代码能够运行通过,代码不能通过,则博客成绩最多给60分。
(3)博客要体现出自己的思想,每个人遇到的问题和解决方法以及感获得的感受都应是不一样的,博客出现抄袭或者拷贝现象,一旦发现作业将没有成绩。
posted on 2019-09-24 11:15 Cherish599 阅读(673) 评论(2) 编辑 收藏 举报