事后诸葛亮分析报告

0.作业声明

这个作业属于哪个课程	信安1912-软件工程 (广东工业大学 - 计算机学院)
这个作业要求在哪里	团队作业6——复审与事后分析
这个作业的目标	事后诸葛亮分析报告

1.作业gitee链接

作业gitee链接

2.团队展示

1、队名：is-good-bro

2、队员学号

队员	学号
陈梓浩（组长）	3119005455
罗行健	3119005470
黄浩	3119005414
何子阳	3119005413
苏泽	3119005473

3、拟作的团队项目描述：基于知识图谱的医疗问答机器人

3.事后诸葛亮分析

一、设想和目标

1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

解决不同用户人群对医疗问题的咨询。定义清楚。对典型用户和典型场景的清晰描述如下：

面向学龄儿童，由于人口老龄化趋势导致年轻人的压力增大，越来越多的年轻人选择外出打拼，将孩子交给祖辈看护，但是祖辈的科学知识并不充裕，存在很多封建土方，比如孩子发烧通过厚被闷汗出热治病，但是这其实没有任何正效应，甚至可能导致加重发烧，需要一个准确的医疗诊断机器人，避免因误判或过晚发现身体上的异常，容易造成不可估量的无法挽回后果

面向青年群体，青年身体有异常习惯通过挺两天尝试自愈，但是并非每种情况都可以靠身体自愈，而且为了方便，通常选择网络查病，但例如百度，经常随便一问都是癌症征兆或者晚期，不仅没实际效果，而且会导致心理焦虑，需要一个即时的医疗咨询机器人，及时保障自身健康

面对中老年群体，他们的记忆力下降，容易忘记药物的服用时间和剂量频率，需要一个便捷的医疗问答机器人，防止影响治疗效果

2、我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么？）

达到目标了。原计划的功能有实体识别、关系抽取、数据导入、实体规范化、意图识别、对话机器人、多轮对话，均实现了。按原计划交付时间交付了。为了进一步提高用户的使用体验，我们推出的是微信端，即通过添加我们的机器人微信号，直接聊天咨询，因为推广效果不佳，仅达到预期的第一阶段用户数量（25）

3、和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

提高了，我们进一步优化了模型代码，找了更多的数据集进行训练，让机器人识别用户的输入识别得更加精准，提高了大约12%，衡量方法为观察优化前后同样输入识别正确的频率。

4、用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？

用户对功能的接受程度与我们事先的预想存在较小的差别，主要在于不同人群用户使用我们项目的目的与我们的预期不同，呈现混合情况，即不同人群询问内容差别不大。因为得出了真实的使用情况，所以我们得到了优化进步的机会，离目标更近了

5、有什么经验教训？如果历史重来一遍，我们会做什么改进？

如果重来一遍，提前加设一次调研，充分调查用户如果使用我们的项目，会是什么目的，确保主要思路不偏

二、计划

1、是否有充足的时间来做计划？

有，每周制定计划的时间均为周一早晨，早晨时间充足，且思考较为理性

2、团队在计划阶段是如何解决同事们对于计划的不同意见的？

通过投票表决，少数服从多数，但可以提出强烈建议，让计划进行重新讨论

3、你原计划的工作是否最后都做完了？如果有没做完的，为什么？

原计划的工作绝大部分都已实现，实现了机器人的version1本地端和version2微信端，但还有version3网页端正在进行最后的调试，因为涉及到项目过大，需要服务器具有更多的运行内存，正常租借的阿里云服务器只有2G运行内容，这是不够用的

4、有没有发现你做了一些事后看来没必要或没多大价值的事？

有，比如我会因为强迫症，反复修改自己编写的代码，包括代码里面的warning，但这些warning并不会对程序产生任何影响

5、是否每一项任务都有清楚定义和衡量的交付件？

有，项目的任务细分为每个模块和每个version，模块从选择、数据集、训练、优化、测试多个方面，都有具体的计划和分配，所以每次交付都是确保质量的交付

6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？

项目的绝大部分过程都是按照计划进行，出现的意外为项目过大，服务器运行内存不够用，容易导致出现服务器卡死的风险，这个风险就是没有估计到的，因为上传服务器之前，运行测试都是在我的笔记本上进行的，而我买的是游戏本，所以配置完全足够运行项目，因此忽略了服务器的承受能力

7、在计划中有没有留下缓冲区，缓冲区有作用么？

计划中的缓冲区均设置在周末，因为周一至周五需要上课，项目推进受到一定的影响，所以缓冲区可以用来缓和成员的压力，确保项目开发有条不紊的进行

8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）

将来的计划会在任务的时间设定上做修改，因为已经进入了考试月，所以需要设置更多的换冲区，但是如果越过缓冲区还是没完成任务，就需要在深夜进行加班

9、我们学到了什么？如果历史重来一遍，我们会做什么改进？

如果重来一遍，应该抛开个人不良习惯，杜绝强迫症，还因重新讨论前端界面的开发，因为团队中只有一名前端开发成员，团队应该再多招一位前端开发人员

三、资源

1、我们有足够的资源来完成各项任务么？

有，虽然过程中单个2G服务器不够使用，但我们后面再加了另外一个2G的服务器，最终项目可以上线

2、各项任务所需的时间和其他资源是如何估计的，精度如何？

所需时间的估计都是根据任务的具体难度设定的，且参照当天课内作业的数量做微调。其他资源主要为硬件资源和数据资源，硬件资源充足，数据资源靠各搜索引擎获取，精度均达一定程度，时间上确保了在原计划时间完成，其他资源上确保了项目的可信度和响应速度

3、测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？

人力资源足够，因为我们团队有5位成员，测试的时候都是一起测试，而测试所用软件/硬件资源都是成员及成员周围人的电子设备，因为做客户端使用，所以资源充足。

对于那些不需要编程的资源确实有点低估难度，美工设计方面因为都是学习网络上的优秀范例，没有什么大问题，主要是文案（即博客撰写），为了做到尽最大程度描述清楚本团队的工作，所以都是投入了大量精力

4、你有没有感到你做的事情可以让别人来做（更有效率）？

其实还是有的，比如模块的测试，我本身主要是开发人员，所以测试的时候容易思想偏向于我编程时的想法，测试效果往往不佳，影响团队的测试进度，这可以让其他成员来做

5、有什么经验教训？如果历史重来一遍，我们会做什么改进？

如果重来一遍，租用更大运行内存的服务器，确保项目部署的硬件需求得到满足，并进一步提高回复的响应速度

四、变更管理

1、每个相关的员工都及时知道了变更的消息？

是的，每次变更管理都会在gitee上发布issue，并在微信群复述，确保每个相关成员都及时知道

2、我们采用了什么办法决定“推迟”和“必须实现”的功能？

在需要变更的时候，临时让所有人做出决定，票决是否进行计划变更

3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

有，我们定义，当项目通过设定的16个不同配置的设备（6台笔记本+10台手机）的测试，实现在0.5s内回复本地端咨询，在1s内回复微信端咨询，就认为该项目已经足够好，可以发布

4、对于可能的变更是否能制定应急计划？

能，因为前面所提，变更都是根据票决得出的，所以在等待票决结果的时间段就可以利用起来制定应急计划

5、员工是否能够有效地处理意料之外的工作请求？

大致上可以有效地处理，主要是挂在服务器上运行时，因为项目比较大，在运行程序的时候，因为运行内存不够的时候，会自动关掉neo4j，这个时候只需要再跟服务器建立一个连接，再次开启neo4j数据库，程序就可以正常运行

6、我们学到了什么？如果重来一遍，我们会做什么改进？

任务和更改的及时通知是非常重要的，如果重来一遍，会提前确保任务不需要修改，避免临时的加改对项目开发进度的拖延

五、设计/实现

1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在确认选题后的一周内就完成，参与人员为全团队成员，之后的开发任务都是按照设计内容进行，后续没有出现较大的矛盾，所以是合适的时间，合适的人

2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有，比如设计界面的时候，因为选择困难症，难以做出决定，我们会选择票决和投骰子，因为团队总共五名成员，所以每次都可以得出决策结果

3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？

运用了单元测试，在每个模块开发完成之后，是用pycharm和VS studio进行单元测试，其他工具因为开发时间紧凑就没有使用。UML文档在一开始的设计工作就完成制定，因为设计工作前后持续了一周，且结合了全团队成员的想法，所以在后期开发过程中没有产生区别，没有更新UML文档

4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？为什么我们在设计/开发的时候没有想到这些情况？

多轮对话功能产生的Bug最多，因为多轮对话需要调用多个模块，实体识别，意图识别，对话缓存，特别是在对话缓存模块，因为是使用json文件进行缓存信息，且意图识别模块使用所需，存放缓存时还得确保是指定模板形式

在发布之后没有发现重要的bug

5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审是团队成员交换审核其他人写的代码，确保代码的可读性和易读性，同时执行代码规范

6、我们学到了什么？如果重来一遍，我们会做什么改进？

如果重来一遍，应该多督促成员线下一起编程，这样讨论问题的效率可以得到大幅提升，歧义想法也可以及时探讨

六、测试/发布

1、团队是否有一个测试计划？为什么没有？

有，每项测试，测试数据均为100条，30%为测试人员结合自身生活生成，40%为网络收集，30%为交叉测试人员生成，例如实体识别模块，测试数据为“我昨天晚上肠胃炎犯了，而且头痛”，实体识别模块识别出“肠胃炎”疾病实体和“头痛”症状实体，意图识别模块测试数据“你是机器人吗”，模块识别出这句话的意图是闲聊意图范围中的isrobot，多轮对话模块测试数据“心脏病是什么”->“那怎么治疗呢”，模块识别出“那怎么治疗呢”的意图是医疗咨询范围中的询问治疗方法，但对应槽位并没有填充信息，于是继承上一句对话的槽位信息，即做到了多轮对话

2、是否进行了正式的验收测试？

团队决定将项目上线后用户的使用记录作为验收测试，确保我们的项目确实达到我们的目标，且测试结果更具客观性

3、团队是否有测试工具来帮助测试？很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

团队的测试并没有使用测试工具，因为每个模块都是单独的程序文件，所以我们测试时候是将数据集存入csv文件，编写python脚本读取数据集文件，然后输入到模块程序文件，来获得测试结果，这其实也算半自动化的测试工具

4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

软件的效能，主要从识别的准确度，回复的准确度以及回复的速度跟踪测量。压力测试使用jmeter进行测试，模拟大量用户从终端同时登录和同时与服务器发送消息，测试系统正常运行的极限。从结果看，这些测试工作的作用并不明显，因为目前使用我们软件的用户量远不及压力测试的数量，应从实际出发，测试并加快响应速度，而不是一味的折磨服务器

5、在发布的过程中发现了哪些意外问题？

发布的过程中发现的问题主要在于原本的标识方法失效，该怎么标识用户，最后查看服务器收到的请求，找出唯一标识，如微信端使用NickName进行标识

6、我们学到了什么？如果重来一遍，我们会做什么改进？

如果重来一遍，应该使用自动化的测试工具，而不是仅仅依靠测试脚本，因为测试脚本的编写也是需要花费一定的时间，使用现成的测试工具可以更快的推进项目开发

七、团队的角色，管理，合作

1、团队的每个角色是如何确定的，是不是人尽其才？

团队的角色初步由成员自身推荐，然后在开发的过程中，逐步细化项目所需的角色定位，最后票决产生，因为票决都是根据所有人的想法而来，而想法来自于开发过程中的观察体会，所以做出的决定都是人尽其才

2、团队成员之间有互相帮助么？

有，主要体现在模块测试和模块训练的负责成员之间，以及前后端开发成员之间，出现问题时会在群里发问，然后成员之间帮助解答

3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现矛盾时，如前文所说，通过投票表决，少数服从多数，但可以提出强烈建议，让计划进行重新讨论，确保最终得出的解决方法都是客观最佳的

八、总结

1、你觉得团队目前的状态属于CMM/CMMI中的哪个档次？

处于CMMI中的等级四，定量管理级，因为团队软件开发过程可预测，开发过程得到测量和控制

2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？

团队处于规范和创造之间，因为我们的项目创意已经确定和大致实现，成员之间关系也已经熟络，之间相互帮助团结合作，共同推动项目开发，且各方面的想法均已统一，达到规范，正在向创造更多的内容而努力

3、你觉得团队在这个里程碑相比前一个里程碑有什么改进？

我们比起前一个里程碑，实现了机器人version2微信端，让我们的项目可以被开发成员外的人使用，且可以开始进行推广，使用微信号作为项目的使用入口，受益于微信的受众情程度，我们的项目推广也更加方便，机器人version3网页端目前正在进行最后的优化调整

4、你觉得目前最需要改进的一个方面是什么？

最需要改进的一个方面应该是，意图识别的精确度，因为医疗咨询能拿到的开源数据集实在是太少了，下一步应该与医院达成合作，获得医院的数据集

5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例

整个开发过程保持每1-2天线下开会一次，确保信息互换及时

成员之间有问题会相互探讨，因为宿舍离得比较近，必要的时候会直接串宿舍

6、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

代码编写的规范要求每位成员都遵守，且保留一定的注释，确保不同任务的成员之间不同任务的代码可以看懂，增强代码的易读性

7、整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

架构需要对整个项目都有比较深入的理解，从算法模型，到前后端框架

每次完成issue和每日任务的时候，将新模块加入到程序中，就重构一次，确保一日一重构

质量的提高可以从程序运行的代码覆盖率，以及用户的使用体验衡量

8、其它软件工具的应用，应该如何提高？

先通过搜索网络上别人关于软件工具的使用指导，学会基本操作之后，自己上手进行实操

9、项目管理有哪些具体的提高？

通过发布issue和群通知，每天制定一定的任务目标，周末作为缓冲区，确保每一小阶段的目标都可以完成，同时也确保开发过程中遇到的问题，可以及时得到解决

10、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

由于项目需要记录用户的对话缓存信息，用于多轮对话进行槽位继承，所以我们本身就需要跟踪用户数据，我们会将用户的对话信息以json文件进行记录，并在本地创建备份。通过将缓存文件夹中的文件进行最后修改时间排序，对应时间就是每日/周活跃用户

11、项目文档的质量如何提高？

用组长进行编写，对应任务的负责成员辅助编写，确保文档的正确性

12、对于人的领导和管理， 有什么具体可以改进的地方？

还需要多招一个前端开发成员来分担一定的开发任务，这样也能推进项目更快的开发

4.会议照片

5.贡献分

名字	角色	团队贡献分	可验证的贡献
陈梓浩	算法开发、架构	22	博客撰写、主要设计、对话机器人构建
罗行健	前端开发	21	前端网页开发、次要测试
黄浩	后端开发	20	后端缓存开发、次要测试
何子阳	后端开发	19	后端管理开发、次要测试
苏泽	测试	18	主要测试、次要设计