注：因为我们团队在分析第一版本题目时就考虑到了括号问题和运算数的上限问题，所以第二阶段主要是对于第一阶段代码的完善

一、组员职责分工

1. 题目分解

生成算式中的问题
- 在生成算式的问题中，我们是分成运算数和运算符来讨论：在运算符中，我们先是很快地想到用随机数生成，接着考虑到运算个数的问题，我们就想到先随机生成一个数作为运算数的个数；
- 由于各年级的数字域、精度的不同，我们就判断分成int和double两种类型来生成；运算符的生成上用’0’、’1’、’2’、’3’来表示加、减、乘、除；再次看题的时候发现，在表达式中还可能存在有括号的情况。
- 后来在结合运算讨论的时候，我们发现将生成的随机数和运算符转换为字符串的中缀形式更方便编写运算的相关模块。
关于生成的字符串如何计算出结果
- 我们团队也进行了比较长时间的讨论。一开始我们的想法是用后缀表达式计算可能比较快。所以我们考虑先将上一步随机生成的中缀表达式字符串转为后缀表达式，然后再进行计算。
- 于是，我们团队就按照这个想法进行了初步分工。但等到快要进入编码阶段的时候，有人提出了可以直接用中缀表达式计算，这样代码量也不会多到哪去。
- 于是，针对这个想法，我们团队又进行了新的一轮讨论。最终，我们团队采用了直接用中缀表达式计算的想法，最后也成功完成了代码实现。

通过这次的团队编程，明白了如何进行多人团队的 GitHub 协作。每个人将团队的仓库 fork 到自己的仓库中。仓库中主要创建几个 c++ 的文件，在这个文件中定义好接口（或者是事先设计好函数名），每个成员都对于函数进行实现。函数实现之后加入到团队的由接口组成的文件之中，进行 commit 。Commit 之后进行 Pull Request，经过审核之后，每个人写的一部分的函数就会出现在项目的总体的文件之中。
虽然在这次团队协作中会遇到例如 GitHub 无法登录，上传文件连接超时等不可控因素，但最终在团队所有成员的共同努力之下，最终还是成功完成了函数的拼接任务。
通过这次对于团队 GitHub 的使用，为将来整个团队的项目共同开发奠定了基础。因为基于 GitHub 平台上的团队合作更加明确化，版本的控制更加科学合理，每个人都在有序地对项目的总开发做出贡献。

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	10	10
· Estimate	· 估计这个任务需要多少时间
Development	开发	130	140
· Analysis	· 需求分析 (包括学习新技术)	10	10
· Design Spec	· 生成设计文档
· Design Review	· 设计复审 (和同事审核设计文档)
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)
· Design	· 具体设计	5	10
· Coding	· 具体编码	60	80
· Code Review	· 代码复审	15	20
· Test	· 测试（自我测试，修改代码，提交修改）	20	20
Reporting	报告	20	30
· Test Report	· 测试报告	15	25
· Size Measurement	· 计算工作量	5	5
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划
合计		170	180

原文地址：https://blog.csdn.net/olssa/article/details/121046625