标签：第三方 sp2 review 领域 技术 button 没有想到 bug 开启
我们的软件为了解决用户对拼单的需求，解决用户没有拼单途径的问题，定义得比较清楚。原计划的功能做到了3个，未完成的部分为举报机制及发帖的部分，我们在交付时间内完成了这个软件，但有些功能还没有实现，总体而言完成了Alpha阶段的计划内容。获得的经验教训就是一定要注重配合，如果历史重来一遍，我们会制定更为详细的计划目标，让项目更完美地达成预计的目标，在下一阶段我们需要对目前组员的实力进行重新评估，已制定更好的计划以进行Beta阶段。对于计划我们用的时间较少，有一定的计划，但不够充分，在计划时未考虑具体进度和学习新知识的时间，计划不够详细现实。对于计划的不同意见我们通过讨论的方式寻求最优的解决方式。原计划的工作未能全部完成，主要原因是时间太赶而且恰逢其他科目有考试，导致原定计划未能全部实现。对于分配给每个组员的每一项任务都有明确的定义，但没有明确的衡量指标。整个项目总体上都在按照计划进行，没出什么意外。没有留下缓冲区，主要原因在于时间较少且要花时间去学习新知识，同时还要处理其他科目的学业，已无时间留下缓冲区。1、设置缓冲区 2、制定合理的计划 3、明确任务指标。我们学到了软件开发的相关知识，并懂得了团队的重要性，如果历史重来一遍，我们会多花些时间来制定一个合理的计划。缺少有过开发经验的成员是我们的一大问题。各项任务所需的时间和其他资源主要以该任务涉及的知识领域以及代码量进行估计，精度不高。由于时间较少，测试的时间不够，对于美工这类资源没有低估其难度。大家都在学习新的知识，所以没有这种想法。测试的时间需要提高，如果历史重来一遍，我们会多注重测试部分的时间，同时尽可能多地寻找需要的资源。对于变更的消息我们会及时在群里通知，由于宿舍的缘故也会直接告知负责的人。主要以可能花费的时间和学习成本来衡量，对于耗时大、学习成本高的推迟实现，比较容易实现的必须完成。我们的定义为所有计划中的功能全部实现且能运行即为项目出口条件。对于部分变更制定应急计划，如服务器的搭建未能成功时就采取直连数据库的方式。如果是与负责的部分相关的意料之外的工作请求能够有效地处理，而涉及不是负责部分外的工作请求可能需要学习新的知识，并不能很有效地处理。学到了临时变更发生时需要如何处理，如果历史重来一遍，我们会在计划中对每一部分可能发生的变更制定一个应急计划。设计工作在项目开始初期，由组长来完成，是合适的时间，合适的人。我们会在群中反馈工作中遇到的疑问，而设计人员会及时地参与讨论，避免模棱两可的情况发生。由于开发经验缺失，没有用到这些工具，这也是需要改进的地方。在登录注册功能上产生的BUG最多，可能的原因是与数据库的连接存在问题，发布后发现软件在退出后台重新开启时需要重新登录，不能自动登录上一次的帐号，目前原因尚不明确。代码复审由各个部分负责的人自行复审，严格执行了代码规范。我们学到了项目的设计与实现的一般步骤，如果历史重来一遍，我们会在计划中运用单元测试等工具来帮助设计和实现的过程。由于时间的关系及其他科目的考试，我们没有测试计划。目前还没有测试工具来帮助测试。我们目前还没有一个有效的测试跟踪效能的方法，这也是我们下一个阶段需要重点考虑的方面之一。一些手机的系统无法支持软件的安装。我们学到了对测试是一个很重要的部分，测试是一个发现问题的很重要的途径，如果历史重来一遍，我们会在各个功能实现以后进行相应的测试以消除潜在的BUG。团队的每个角色都是自己挑选想负责的部分，可能并不是人尽其才。团队成员间遇到问题都会互相寻求帮助，互相学习。我们会在群中进行讨论，必要时线下开会探讨，互相交流意见，互相学习，及时处理疑惑和问题。我们学到了在一个项目开发的过程中，一个团队是非常重要的，如果历史重来一遍，我们会按照个人能力进行评估，给不同的人分配更适合的任务。我们团队目前的状态属于CMM/CMMI中的可重复级。我们团队目前处于磨合向规范过渡的阶段。团队内交流更加频繁，开发效率更高，对于出现的问题能够共同解决。目前最需要改进的是测试方面的工作，由于时间的原因我们未能制定测试计划，这是我们下一个阶段需要进行改进的。我们小组做的最好的是原则4和原则7，对于原则4，我们的组员在编写代码时都是共同工作，有问题互相帮助互相学习，而对于原则7，我们一开始就以制作出一个可用的软件为衡量项目的主要指标。
| 组员 | 徐俊杰 | 范文辉 | 江列湫 | 李家涌 | 连振升 | 黄丽萍 | 杨文 | 朱雅珊 | 彭佳伟 | 李炜炜 |
|---|---|---|---|---|---|---|---|---|---|---|
| 贡献比 | 15 | 15 | 6 | 9 | 10 | 8 | 15 | 7 | 7 | 8 |
现场答辩得分:
其他组对本组提出的问题
其他组未对本组提出问题。
| PSP2.1 | 过程 | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 20 | 30 |
| Estimate | 估计任务时间 | 20 | 30 |
| Development | 开发 | 370 | 430 |
| Analysis | 需求分析 (包括学习新技术) | 60 | 70 |
| Design Spec | 生成设计文档 | 0 | 0 |
| Design Review | 设计复审 | 0 | 0 |
| Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| Design | 具体设计 | 300 | 350 |
| Coding | 具体编码 | 0 | 0 |
| Code Review | 代码复审 | 0 | 0 |
| Test | 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| Reporting | 报告 | 0 | 0 |
| Test Report | 测试报告 | 0 | 0 |
| Size Measurement | 计算工作量 | 0 | 0 |
| Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 0 | 0 |
| 合计 | 390 | 560 |
| 第n周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 0 | 0 | 10 | 10 | 通过设计原型，大致掌握了墨刀和PS的基本用法，并提高了网络调研能力 |
| 2 | 273 | 273 | 12 | 22 | 学习了Post和Get的使用，对JFrame有了一些了解 |
| 3 | 302 | 575 | 14 | 36 | 学习了JButton、JText等组件的使用，完善具体设计思路 |
| 4 | 851 | 1426 | 20 | 56 | 实现各个界面之间的逻辑调用 |
| 5 | 264 | 1690 | 7 | 63 | 对第三方api的调用有了稍稍那么一点点深入认识 |
| 6 | 243 | 1933 | 14 | 77 | 学习数据库网络配置等相关知识 |
| 7 | 226 | 2159 | 12 | 89 | 学习数据库维护的相关知识 |
| 8 | 112 | 2271 | 8 | 97 | 数据库的维护 |
| 9 | 53 | 2324 | 4 | 101 | 数据库相关知识 |
| 10 | 0 | 2324 | 2 | 103 | 数据库相关知识 |
标签：第三方 sp2 review 领域 技术 button 没有想到 bug 开启
原文地址：https://www.cnblogs.com/0x06c0/p/11918920.html
