| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 这个作业要求在哪里 | 团队作业6——复审与事后分析 |
| 这个作业的目标 | 项目复审、“同行”评议 |
一、Alpha阶段项目复审
二、事后诸葛亮分析
一、设想和目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本系统主要面向于初学图形学与人机交互的同学，通过开源的方式为初学者提供一个较为轻量、易解读的图形交互界面。
典型用户：使用图形引擎的用户一般是计算机科学、软件工程、游戏设计等相关专业的学生，他们对图形学、游戏开发、虚拟现实等领域有浓厚的兴趣和热情，希望通过使用图形引擎来实现自己的创意和想法，或者完成课程作业和毕业设计。
典型场景：对于初学者而言，目前互联网上的学习资源良莠不齐，查询时费心费力，即使网络上比较成熟的开源图形交互软件都有较完整的文档，但体量较大，抽丝剥茧实属不易，此项目在教学场景下由于易读的文档与代码，可满足用户需求。
2、我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）
达到目标了。
原计划的功能有查看特定格式的3D模型、对3D模型添加光照效果、实现对场景与模型的交互、程序使用教程，均已实现。
按原计划交付时间交付了。
原计划在同级同学中推广，然而由于种种原因仅达到预计推广人数的1/4左右。（52/200）
3、和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
提高了。
我们对代码的模型导入部分进行了优化，实现了更简易的导入操作。从直接在源代码中修改路径变为通过直接修改Setting.csv文件实现修改导入模型路径，同时添加了Scale参数实现在导入初期作出对模型数据的简易变换，使图形程序的调试工作量大大降低。
4、用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？
用户量与用户对功能的接受程度与我们事先的预想存在一定差别。
产品的主要缺陷在于glut库内置的数学库与渲染辅助函数较少，免不了出现依赖文件较多等问题，在用户安装调试时，我们也发现由于.obj文件与程序编译时生成的二进制目标文件的后缀相同，上传至云端时需注意避免文件被忽略。毫无疑问我们离目标更近了，不论是日渐默契的团队协作还是不断完善的项目都让我们更加坚信了这一点。
5、有什么经验教训？如果历史重来一遍，我们会做什么改进？
如果历史重来一遍，我们会在开始项目前先统一glut库，避免后续的文件冲突，从而预留时间在推广前进一步优化用户体验。
二、计划
1、是否有充足的时间来做计划？
有。在每周的小组例会时我们会一起为接下来一段时间的工作做计划。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
在计划阶段我们推选了团体最信任了人作为最后敲板的队长，在发生分歧时作为协调人。
不过团队目标一致，并未发生重大分歧。
3、你原计划的工作是否最后都做完了？如果有没做完的，为什么？
原计划的工作最后都做完了。
4、有没有发现你做了一些事后看来没必要或没多大价值的事？
有，比如分支进行开发，于是直到最后合并项目时才发现依赖库不一致这样的问题。
5、是否每一项任务都有清楚定义和衡量的交付件？
有。项目的每一项任务都细分到每个模块，每位成员都负责自己的模块，各司其职，故每次交付都是确保质量的交付。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
项目的绝大部分过程都按照计划进行。
在最后合并项目时由于依赖库不一致，出了一点小乌龙。因为大家都没有开发图形程序的经验，故没有重视这个问题，好在影响不大。
7、在计划中有没有留下缓冲区，缓冲区有作用么？
在计划中有留下缓冲区，设置在周三，因为周三组内所有成员都没课，缓冲区可以用来缓和工作压力。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来计划设置更多的缓冲区，由于考试周将至，大家也会将生活重心偏向复习。有能力可以在复习间隙跟进项目，但不提倡加班，尤其深夜加班，透支身体不可取。
9、我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们学到了如何和之前不熟悉的同学们一起合作，做出一个优秀的产品。如果历史重来一遍，我们会添加一些更有趣的功能来吸引用户，增长用户量。
三、资源
1、我们有足够的资源来完成各项任务么？
有。
2、各项任务所需的时间和其他资源是如何估计的，精度如何？
所需时间的估计都是根据成员的自身能力来设定的。
由于可以实现实时反馈，精度不错。时间上确保了在原计划时间完成，其他资源的估计由于我们是本地开发，并不需要太多协调。
3、测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
测试的时间足够，我们预留了一整周用于测试。
人力资源足够，组内共有六位成员，测试时大家都使用自己的硬件进行测试，因此硬件资源也足够。
对于那些不需要编程的资源，在前期确实有低估难度，文案（即博客撰写）编写时为保证文风流畅，无法细分工作，在冲刺阶段作业提交频率高，协调工作杂，故投入了比预期更多的时间精力。
4、你有没有感到你做的事情可以让别人来做（更有效率）？
跟进项目，我认为需要一个人来专心做这件事，会让团队效率大大提升。
5、有什么经验教训？如果历史重来一遍，我们会做什么改进？
如果历史重来一遍，我们会在项目之初协商出跟进项目的队员，减少沟通成本。
四、变更管理
1、每个相关的员工都及时知道了变更的消息？
是的，每次变更管理都会在微信群进行通知，并确保每一位成员回复已阅。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能？
让所有人进行票决，来确定人力资源是否支持在本版本达成“必须实现”，若评估后决定推迟，再进行深入探讨。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
有，我们定义，当项目在6个不同设备实现计划功能，功能可以正常使用，无严重bug出现，用户体验感良好，就认为该项目已经达到出口条件，可以发布。
4、对于可能的变更是否能制定应急计划？
能，应急计划在紧急会议上由全体成员一同商讨。
5、员工是否能够有效地处理意料之外的工作请求？
能，一些突发的bug组员都会进行复现深入探究。
6、我们学到了什么？如果重来一遍，我们会做什么改进？
如果重来一遍，我们会在一开始做出PlanB，避免临时的加改。
五、设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在确认选题后的两周完成，参与人员为全团队成员。
我认为是合适的时间，因为我们在做出雏形后对设计进行了进一步优化，是合适的人，也提升了大家在项目中的归属感。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
为了保证软件质量，我们在每个模块开发完成之后，采用了单元测试的方法，使用了VS studio作为测试工具。由于开发进度紧张，我们没有使用其他测试工具。我们在项目初期就制定了UML文档，经过了两周周的设计讨论，充分考虑了团队成员的意见和建议。因此，在后续的开发过程中，我们对UML文档仅进行了较少修改。
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？
光照功能产生的Bug最多，由于glut的API在不同的平台上有不同的实现方式，导致了一些兼容性问题。在发布之后，我们发现了一个重要的bug，就是在某些情况下，光照效果会出现闪烁或者消失的现象。这个bug是由于我们在设计/开发的时候没有考虑到光照的更新频率和渲染的帧率之间的关系，导致了同步错误。为了解决这个问题，我们需要调整光照的计算方式，使之与渲染的流程保持一致。
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
使用非正式代码复审方法：由作者邀请其他开发人员对代码进行随意的查看和评论，不需要记录复审结果和建议，由作者自行决定是否对代码进行修改和确认。有严格执行代码规范。
6、我们学到了什么？如果重来一遍，我们会做什么改进？
如果重来一遍，我们会增加更多的线下协作和沟通，提高团队的效率和凝聚力，使用更多的测试工具和方法，提高代码的覆盖率和稳定性；
六、测试/发布
1、团队是否有一个测试计划？为什么没有？
有
2、是否进行了正式的验收测试？
产品发布后，我们联系了图形学与人机交互的老师，目前正在等待修改意见。
3、团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
有测试工具帮助测试。
由于我们做的是图形程序，故帧率是很重要的评判标准，我们将窗口帧率进行记录，这使得我们比较不同渲染方式的开销更简易。希望能对手动测试的团队有帮助。
4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
-
确定效能目标和指标，例如期望的渲染帧率、最大支持的场景复杂度、最大占用的内存和显存等。
-
设计效能测试方案，包括选择效能测试工具、制定效能测试场景、准备效能测试数据、配置效能测试环境等。
-
执行效能测试，模拟不同的负载和压力，收集效能数据，同时关注系统的运行状况和资源消耗。
-
分析效能测试结果，比较实际的效能数据和预期的效能目标，找出效能瓶颈和问题，提出效能优化建议和改进措施。
-
重复效能测试，验证效能优化的效果，持续监控和改进图形引擎的效能
从实际运行效果看，这些测试工作有用，但由于目前阶段程序的硬件开销并不大，故未进行优化。
5、在发布的过程中发现了哪些意外问题？
尚未发现意外问题。
6、我们学到了什么？如果重来一遍，我们会做什么改进？
如果重来一遍，我们会使用更加智能的自动化测试软件进行测试，可有效减少组员的工作量。
七、团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
团队的角色由成员自荐，是人尽其才。
2、团队成员之间有互相帮助么？
有，当某个模块出现问题时，大家都会集中讨论解决问题。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
项目的沟通不及时或不充分，团队成员可能会出现信息的缺失、误解或冲突，影响项目的协作和质量。
为了解决这个问题，团队成员会使用项目管理工具、定期召开会议、及时分享信息和反馈等，尊重和倾听他人的意见和建议，避免沟通障碍。
八、总结
1、你觉得团队目前的状态属于CMM/CMMI中的哪个档次？
我觉得团队目前的状态处于CMMI中的等级四，定量管理级。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队处于创造阶段。
我们的项目基本需求已经全部实现，成员之间团结合作，共同推动项目开发，团队已达到规范，正在尝试创造更多有趣的内容。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进？
我们比起前一个里程碑，提升了用户体验，让调试工作变得更简单，也更加符合了产品定位，即教学引擎。
4、你觉得目前最需要改进的一个方面是什么？
最需要改进的一个方面是大家都喜欢在宿舍开发，缺少线下沟通的情景。
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例
团队能够按照预定的时间和质量交付软件产品或功能，根据客户的需求和反馈，不断调整和优化软件的价值和质量。
团队成员对测试反馈十分重视，几乎是当天就会对测试的bug进行修复。
6、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用合适的代码管理工具（我们使用了Git），制定和执行代码命名和注释规范，根据自己的编程语言和工具，选择合适的代码命名和注释规范，并严格遵守和执行，同时注意避免过度或不必要的命名和注释。
建立和执行代码复审流程和机制（我们使用了非正式代码复审），制定和遵守合理的代码规范和标准，并在代码复审时，严格检查和评价代码是否符合代码规范和标准，同时注意避免过度或不必要的规范和标准。
7、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
架构设计是对项目的全面把握，涉及算法模型、前后端框架等多个方面。 为了保持架构的灵活性和一致性，每完成一个issue或每日任务，就要将新模块集成到程序中，并进行重构。
质量的评估要从程序的代码覆盖率和用户的使用体验两个维度来进行。
8、其它软件工具的应用，应该如何提高？
暂无其他软件工具。
9、项目管理有哪些具体的提高？
固定时间进行会议，避免紧急会议。发布通知时要一次性发布，避免朝令夕改。
10、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
我们将项目公开在了github上，网站会实时反馈浏览量。
11、项目文档的质量如何提高？
由对应任务的负责成员编写，组长审阅后给出修改意见，文档成型后让全体成员一起检查，查缺补漏。
12、对于人的领导和管理， 有什么具体可以改进的地方？
需要多安排一个成员进行项目跟进，从而便于领导与管理。
三、会议照片
四、贡献分
| 姓名 | 学号 | 团队分工 | 可验证的贡献 | 团队贡献分 |
|---|---|---|---|---|
| 潘俊羽 | 3121005138 | 开发、文档编写 | 开发 | 17.5 |
| 石云欣 | 3221004809 | 设计产品需求、文档编写 | 编写博客 | 16.5 |
| 杨恒 | 3121005146 | 开发、文档编写 | 开发 | 16.5 |
| 游烽 | 3121005148 | 测试、文档编写 | 测试 | 16.5 |
| 沈纪康 | 3121004750 | 开发、文档编写 | 开发 | 16.5 |
| 罗寰宇 | 3121005137 | 管理项目进度、文档编写 | PM | 16.5 |