You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
bilibili-spider/102201525/个人编程作业附录.md

44 lines
5.4 KiB

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Part·6 附录
## 6.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 Repor | · 测试报告 | | |
| · Size Measurement | · 计算工作量 | | |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | | |
| | · 合计 | | |
一个功能完备的程序不是一蹴而就的。可将一个大任务划分为可操作的小任务,同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此,在动手开发之前,要先估计将在程序各模块开发所需耗费的时间,以及完成整个项目所需的时间,将这个[估计值]记录下来写成PSP 的形式。
PSP的目的是记录工程师如何实现需求的效率和我们使用项目管理工具如微软的Project Professional或者禅道等进行项目进度规划类似。
有关PSP的更多内容请自行阅读[邹欣老师的博客:现代软件工程讲义 2 工程师的能力评估和发展](http://www.cnblogs.com/xinz/archive/2011/10/22/2220872.html)
## 6.2 https://code.educoder.net/projects
请阅读邹欣老师的博客源代码管理了解源代码管理的10个实践问题。
本次作业要求使用https://code.educoder.net/projects进行源代码管理**代码有进展即签入https://code.educoder.net/projects**。签入记录不合理的项目会被助教抽查询问项目细节。
对代码签入的具体要求如下根据需求划分功能后每做完一个功能编译成功后应至少commit一次。本例中至少应区分基本功能和扩展功能即分别针对基本功能、扩展功能编译成功后总共至少应commit两次。具体的功能划分请自行定义并在撰写博客时体现出来遵循自己对需求的功能划分来提交代码即可。
对Commit不是很熟悉的话请阅读[阮一峰的博客Commit message 和 Change log 编写指南](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html),了解更多细节。
## 6.3 单元测试
请根据自己以往积累的测试经验,在编码完成之后,提交产品之前,设计测试用例,并编写单元测试,对自己的项目进行测试。
首先至少应采用白盒测试用例设计方法来设计测试用例其他测试方法不限。其次要设计至少10个测试用例确保你的程序能够正确处理各种情况。最后结合测试评估的要求对自己的测试设计进行评价这些测试用例能满足该程序测试的要求吗
另一个重要的措施是要把单元测试自动化,这样每个人都能很容易地运行它,并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的,这样每个单元测试的错误就能及时被发现并得到修改。
推荐阅读[邹欣老师的博客:现代软件工程讲义 2 开发技术 - 单元测试 & 回归测试](http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html)