2023年秋 软件工程课程第二次任务安排（结对项目1）

按照课上分组，完成程序需求分析和设计，完成基本功能的编码工作。

零、任务描述

给同学出四则运算练习题。  建议需求如下，第一阶段完成不少于6个需求。

1. 题目数量可以指定。
2. 支持加减乘除4种运算。
3. 每道题包含两个运算符
4. 运算数为100 以内的数字。
5. 保证答案在 0..100 之间。
6. 需要有答题功能并验证答案是否正确。
7. 判分，并对历史成绩进行存储和查询。
8. 题目避免重复。

一、编码要求

1. 在github或码云建立自己的代码仓库，代码仓库中首先建立readme文件，用于描述软件功能。
2. 按照里程碑方式进行计划管理，关联需求不少于5条。
3. 协作式开发，任务分配具体到人，实际代码提交要与任务分配一致。
4. 在开始实现程序之前，在PSP表格[按附录格式]记录下你估计在程序开发各个步骤上耗费的时间，在你实现程序之后，在PSP表格记录下你在程序的各个模块上实际花费的时间。
5. 提交的代码要求经过代码自动检查工具（IDE环境中和码云环境中）的分析并消除所有的警告。
6. 完成项目的首个版本之后，请使用性能分析工具来找出代码中的性能瓶颈并进行改进。
7. 使用代码仓库来管理源代码和测试用例，代码有进展即签入仓库。签入记录不合理的项目会被扣分。
8. 使用单元测试[附录3]对项目进行测试，并使用插件查看测试分支覆盖率等指标；写出至少10个测试用例确保你的程序能够正确处理各种情况。

二、博客撰写要求

1. 在文章开头给出代码仓库中项目地址。
2. 给出PSP表格，分析估计值与真实值的区别。
3. 建立每日软件工程学习日志，格式自定，但要体现学习时段、学习内容、收获体会、自我效率评价等。
4. 解题思路描述。即刚开始拿到题目后，如何思考，如何找资料的过程。
5. 设计实现过程。设计包括代码如何组织，比如会有几个类，几个函数，他们之间关系如何，关键函数是否需要画出流程图？单元测试是怎么设计的？分析单元测试的合理性与充分性
6. 记录在改进程序性能上所花费的时间，描述你改进的思路，并展示一张性能分析图（由性能分析工具自动生成），并展示你程序中消耗最大的函数。
7. 代码说明。展示出项目关键代码，并解释思路与注释说明。
8. 结合在构建之法中学习到的相关内容与个人项目的实践经历，撰写解决项目的心路历程与收获。

三、需求

按照需求的不同来源和类别，给出需求列表，并对需求的可行性、重要程度等做出初步分析。

选取在第一阶段准备实现的特色需求，给出详细需求描述和使用流程。

附录

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	· 事后总结, 并提出过程改进计划
	合计

一个功能完备的程序不是一蹴而就的。通过将词频统计的需求划分为4个部分，可将一个大任务划分为可操作的小任务，同时最好按照任务难度或紧急程度指定各个任务的完成次序。因此，在动手开发之前，要先估计将在程序各模块开发所需耗费的时间，以及完成整个项目所需的时间，将这个[估计值]记录下来，写成PSP 的形式。
PSP的目的是：记录工程师如何实现需求的效率，和我们使用项目管理工具（例如微软的Project Professional，或者禅道等）进行项目进度规划类似。
有关PSP的更多内容，请自行阅读邹欣老师的博客：现代软件工程讲义 2 工程师的能力评估和发展

2.Github、Gitee

请阅读邹欣老师的博客：源代码管理，了解源代码管理的10个实践问题。
本次作业要求使用Github进行源代码管理，代码有进展即签入Github或Gitee。
对代码签入的具体要求如下：根据需求划分功能后，每做完一个功能，编译成功后，应至少commit一次，每次修正一个代码错误，应提交一次。具体的功能划分，请自行定义，并在撰写博客时体现出来，遵循自己对需求的功能划分来提交代码即可。
对Commit不是很熟悉的话，请阅读阮一峰的博客：Commit message 和 Change log 编写指南，了解更多细节。

3.单元测试

请根据自己以往积累的测试经验，在编码完成之后，提交产品之前，设计测试用例，并编写单元测试，对自己的项目进行测试。
首先，至少应采用白盒测试用例设计方法来设计测试用例，其他测试方法不限。其次，要设计至少10个测试用例，确保你的程序能够正确处理各种情况。最后，结合测试评估的要求，对自己的测试设计进行评价，这些测试用例能满足该程序测试的要求吗？
另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。
推荐阅读邹欣老师的博客：现代软件工程讲义 2 开发技术 - 单元测试 & 回归测试