事后诸葛亮分析报告

大学生健康管理与预警系统事后诸葛亮分析报告

一、设想和目标

1. 软件核心问题与用户定义

• 积极方面：软件核心目标明确，聚焦大学生作息不规律、运动不足、健康风险缺乏实时预警等校园高频痛点，定位“健康数据管理+风险预警”双核心功能，与目标用户需求匹配度高。《需求规格说明书》中清晰定义了备考熬夜学生、社团活跃少运动学生、体质较弱需监测学生三类典型用户及作息记录与提醒、运动打卡统计、健康数据异常预警、生成AI健康报告等核心使用场景，为开发提供了明确方向。
• 存在不足：典型场景覆盖不够全面，未考虑特殊群体个性化需求；部分功能的用户价值定义模糊。

2. 目标达成情况

• 功能完成度：原计划核心功能：作息、运动、睡眠、心情等健康数据录入与预警、基础数据统计、AI健康报告，均已实现，共完成8项核心功能，1项次要功能校医院预约因优先级调整未完全落地。
• 交付时间：按原计划时间节点交付Alpha版本，各阶段作业选题、需求说明书、系统设计、项目冲刺均按时提交，无延期。

3. 软件工程质量提升情况

• 提升表现：相比前期阶段，软件工程质量有显著提升：①文档规范性提高，从选题阶段的简单框架，到需求说明书、系统设计文档形成完整体系，关键文档覆盖率从30%提升至85%；②开发流程更规范，引入Scrum冲刺模式，任务拆分与进度跟踪更清晰；③代码复用率提升，核心模块复用率显著提高。
• 衡量方式：以文档完整性、任务按时完成率、代码复用率、Bug修复及时率为核心指标，其中任务按时完成率从前期的60%提升至冲刺阶段的88%。

4. 用户反馈与目标距离

• 用户接受度：核心功能健康数据管理、健康预警、AI健康报告使用率高，但测试用户反馈操作不够便捷，与预期有差距。
• 目标差距：核心功能达成度符合预期，但用户覆盖范围未达目标，离成为校园主流健康管理工具的长期目标仍有距离，需通过版本迭代扩大推广范围。

经验教训与改进方向

• 经验：明确核心功能与用户需求的强关联是项目成功的基础，清晰的典型用户定义能减少开发偏差。
• 改进：①前期开展更全面的用户调研，覆盖特殊群体需求，补充完善典型场景；②通过“用户价值优先级排序”筛选功能，剔除无核心价值的附加功能，提高操作便捷性；③提前制定用户推广计划，与校内社团、班级合作扩大测试范围。

二、计划

1. 计划时间充足性

• 积极方面：项目整体周期规划合理，各阶段时间分配相对均衡，选题10天、需求分析10天、系统设计10天、冲刺15天、测试与发布13天。
• 存在不足：单个任务的计划时间预留不足，如“生成AI健康报告”原计划2天，实际因逻辑复杂度超出预期，耗时3天；计划阶段未预留跨阶段衔接的缓冲时间。

2. 计划不同意见的解决方式

• 团队通过“需求优先级投票+核心成员论证”解决分歧：针对项目功能的争议，先统计成员对功能价值的评分，再结合用户需求调研结果，最终决定将该功能列为“二期迭代内容”，优先保障核心功能开发。

3. 原计划工作完成情况

• 核心任务均已完成，未完成的次要功能（校医院预约）主要原因：①优先级低于核心功能，冲刺阶段资源向核心模块倾斜；②部分技术实现难度超出预期，且用户需求反馈不强，故暂缓落地。

4. 任务交付件定义

• 核心任务：如需求说明书、系统设计方案、核心模块代码，均有清晰的交付件标准；但部分冲刺阶段的细分任务未明确交付标准，导致部分修改反复迭代。

5. 计划执行与未预期风险

• 项目整体按计划推进，但出现2项意外情况：①测试阶段发现多浏览器兼容性问题（IE浏览器无法正常显示部分功能），前期未考虑旧版本浏览器适配；②健康数据统计模块因数据计算逻辑漏洞，导致部分统计结果异常，未预估到“多数据源同步冲突”风险。
• 未预估原因：①前期仅在Chrome浏览器进行测试，忽略校内部分用户使用旧版本浏览器的场景；②需求分析阶段未梳理清楚多数据源（手动录入、第三方接口）的同步规则。

6. 未来计划修改方向

• ①设置“总工期10%”的固定缓冲区，按阶段拆分，需求、开发、测试阶段各预留部分缓冲时间；②避免无意义的加班，通过细化任务拆分减少“临时救火”式工作；③提前开展风险评估，制定“高风险任务清单”及应对方案。

经验教训与改进方向

• 经验：合理的优先级排序能保障核心目标达成，团队共识是计划顺利推进的关键。
• 改进：①使用“任务分解表”细化每个任务的交付标准、时间节点和负责人；②建立“风险评估矩阵”，提前识别技术、环境、资源类风险；③减少“锦上添花”类功能的开发投入，聚焦用户核心需求。

三、资源

1. 资源充足性

• 核心资源充足：团队7名成员均为计算机专业学生，具备编程、设计基础；拥有必要的开发设备和服务器资源。
• 稀缺资源：美工设计与文案撰写资源不足，仅1名成员负责界面设计和文档编写，导致部分界面美观度不足、文档更新不及时。

2. 资源需求估计精度

• 开发类任务时间估计精度较高（误差±1天）；但非开发类任务，如美工设计、文案编写估计偏差较大，低估了“多页面风格统一”的难度。

3. 测试与非编程资源评估

• 测试资源充足：配备2名成员专职测试，支持自动化测试；
• 非编程资源低估：美工设计难度远超预期，因团队无专业美工，需边学边做，导致界面设计反复修改；文案撰写缺乏规范，需多次调整格式和内容。

4. 工作效率优化空间

• 存在“专人专岗但效率不均”的情况：①编程能力较强的成员可协助完成部分简单的界面调整工作，减少美工成员的压力；②文档撰写工作可按“模块分工”，由对应开发成员编写模块相关文档，再由专人统一整理，提高文档编写效率。

经验教训与改进方向

• 经验：资源分配需结合任务类型和成员技能，避免“单一角色包揽所有相关工作”。
• 改进：①提前评估非编程资源的难度，若团队内部无专业人员，可寻求校内设计专业同学协助，或使用模板化工具降低难度；②建立“资源共享清单”，明确成员技能特长，实现跨角色协作；③测试阶段引入自动化测试工具，减少人力投入。

四、变更管理

1. 变更消息同步

• 变更消息通过“团队会议+线上群公告+文档标注”三重方式同步，确保每位成员及时知晓。如“健康预警阈值调整”“次要功能暂缓开发”等变更，均在当日团队会议中讨论确定，并同步更新至项目文档和线上群。

2. 功能优先级决策

• 采用“MoSCoW法则”划分功能优先级：①Must have：核心功能（健康数据记录、预警模块、AI健康报告）；②Should have：基础数据统计；③Could have：数据导出；④Won’t have：校医院预约。通过该法则快速决定“推迟”或“必须实现”的功能。

3. 项目出口条件定义

• 有基本的出口条件定义：核心功能无重大Bug、可正常运行；文档齐全；通过内部验收测试。

4. 变更应急计划

• 未制定明确的变更应急计划，应对需求变更时较为被动。如测试阶段临时新增“食物拍照识别”需求，因无预案，只能从核心功能开发中抽调资源紧急处理，影响了部分模块的优化进度。

5. 意外工作请求处理

• 团队成员能够处理部分意外工作请求，但效率不高。如收到“增加健康数据导出Excel功能”的临时请求后，通过查阅技术文档、分工开发，最终在缓冲时间内完成，但因缺乏预案，耗时比预期久。

经验教训与改进方向

• 经验：明确的优先级划分和及时的变更同步能减少混乱，跨角色协作是处理意外请求的关键。
• 改进：①制定详细的出口条件；②建立变更应急计划，针对高频变更场景预留备用资源；③设立“变更审批流程”，临时变更需经PM评估影响后再执行。

五、设计/实现

1. 设计工作的时间与人员分配

• 设计工作在“需求改进&系统设计”阶段完成，由2名具备系统设计经验的核心成员主导，其余成员参与讨论补充。时间节点合理，人员匹配度高，设计方案贴合开发实际。

2. 设计中的模糊问题与解决方式

• 设计阶段遇到“健康数据同步方式”的模糊问题：手动录入数据与第三方接口数据如何同步优先级，通过“查阅同类产品方案+团队技术论证”解决：确定“手动录入数据优先级高于接口数据，接口数据仅作为补充，同步时保留用户手动修改记录”的规则。

3. 开发工具与文档一致性

• ①工具应用：使用UML绘制系统架构图和类图，辅助设计；采用单元测试框架JUnit对核心模块进行测试，但未使用TDD模式。UML工具和单元测试工具有效降低了开发沟通成本和逻辑漏洞。
• ②UML文档差异：项目初期的UML文档与最终实现存在2处差异，差异原因是开发中发现原设计存在逻辑冗余，为优化性能进行了调整。需在Alpha版本迭代后更新UML文档，确保一致性。

4. Bug高发功能与未预见问题

• ①Bug高发功能：健康数据预警模块，原因是预警逻辑复杂，边界条件考虑不足，如未处理“数据缺失时的预警规则”。
• ②发布后发现的重大Bug：多设备登录时健康数据不同步，原因是开发阶段仅测试了单设备登录场景，未考虑“同一账号多设备同时在线”的数据同步机制。

5. 代码复审与规范执行

• 代码复审采用“团队交叉检查”方式：核心模块代码由2名非开发成员复审，普通模块由1名成员复审，制定基础代码规范。

经验教训与改进方向

• 经验：前期设计需充分考虑边界条件和多场景测试，代码复审是降低Bug率的关键。
• 改进：①设计阶段增加“边界条件分析文档”，明确异常场景的处理规则；②引入TDD模式开发核心模块，先编写测试用例再开发功能；③建立详细的代码规范检查清单，复审时逐项核对，引入代码规范检测工具自动校验；④及时更新设计文档，确保文档与实际实现一致。

六、测试/发布

1. 测试计划制定情况

• 制定了贴合项目规模的测试计划，明确了核心功能测试范围、测试人员分工及时间节点，测试覆盖了健康数据录入、体检报告、AI健康报告、预警提醒等所有核心模块，为测试工作有序推进提供了清晰指引，确保关键功能无遗漏测试。

2. 验收测试执行情况

• 进行了非正式验收测试：由团队内部成员和32名校内测试用户参与，通过填写反馈问卷收集问题，但未制定正式的验收测试流程和标准。

3. 测试工具应用与改进计划

• 使用 JUnit 对核心业务逻辑模块编写单元测试用例，覆盖关键代码分支，提前发现并修复了多处代码逻辑漏洞；通过 Postman 对系统所有 API 接口进行自动化测试。
• 改进计划：引入Selenium自动化测试工具，针对核心功能编写自动化测试脚本，生成测试报告，自动对比测试结果差异；每周执行1次自动化测试，减少重复手动操作。

4. 软件效能与压力测试

• 未专门测量软件效能，未进行压力测试。仅在测试阶段发现“同时有10人在线时，数据加载速度变慢”的问题，但未深入排查性能瓶颈。
• 改进方向：引入JMeter压力测试工具，模拟50人、100人同时在线的场景，测试系统响应时间和稳定性；使用性能分析工具定位代码中的性能瓶颈。

5. 发布过程中的意外问题

• 发布阶段发现2项意外问题：①部分旧版本IE浏览器无法正常显示运动打卡模块的图表，兼容性测试不足；②用户注册流程在网络不稳定时出现“注册成功但无法登录”的情况，未处理网络异常场景。

经验教训与改进方向

• 经验：测试是保障发布质量的核心，需覆盖兼容性、性能、异常场景等多维度。
• 改进：①制定详细的测试用例文档，明确每个功能的测试步骤、输入输出、预期结果；②开展多浏览器和多设备兼容性测试；③增加异常场景测试，如网络不稳定、数据输入错误、多设备登录；④引入自动化测试和压力测试工具，提高测试效率和覆盖度；⑤发布前进行“预发布环境演练”，模拟真实发布场景。

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

1. 角色分配与适配性

• 团队角色按技能特长分配：1名PM、2名前端开发工程师 、2名后端开发工程师、2名测试人员，基本实现人尽其才。

2. 团队成员互助情况

• 成员之间互助氛围良好：①开发工程师协助测试人员理解核心功能逻辑，编写测试要点；②文档兼推广人员帮助PM整理项目进度报告；③设计人员在开发阶段提供界面样式调整的实时支持。

3. 问题解决方式

• 当出现项目管理或合作问题时，通过“即时沟通+团队会议”解决：如冲刺阶段出现“开发进度滞后”问题，及时召开会议分析原因，调整任务分配，由技术能力较强的开发工程师协助解决难点，确保进度回归正轨。

八、总结

1. 团队CMM/CMMI等级

• 团队目前处于CMMI 三级（已定义级）：已建立标准化、文档化的项目过程体系，实现从项目管理到工程实践的规范化执行，且形成可复用的过程资产。

2. 团队发展阶段

• 团队处于“规范阶段”：已明确角色分工、工作流程和沟通机制，成员之间协作顺畅，能按既定计划推进项目，冲突解决方式成熟，具备持续改进的基础。

3. 里程碑改进对比

• 相比前一个里程碑，团队主要改进：①文档规范性显著提升，从“仅满足基本要求”到“形成完整文档体系”；②测试意识增强，从“开发完成后简单测试”到“提前设计测试要点，引入初步自动化测试思路”；③协作效率提高，任务拆分更细化，进度跟踪更及时。

4. 最需改进的方面

• 最需改进的是“测试流程与资源配置”：目前测试依赖手动操作，覆盖度不足，无专职测试人员，导致部分Bug未在发布前发现，影响用户体验。

5. 敏捷开发原则践行情况

• 做得最好的3个敏捷原则及事例：
  ①“个体和互动高于流程和工具”：团队每周召开2次短会同步进度，遇到问题即时沟通，而非依赖文档传递信息。如开发中发现设计方案的不合理之处，直接与设计人员沟通调整，避免流程繁琐导致效率低下。
  ②“可用的软件高于完备的文档”：优先保障核心功能可用，Alpha版本虽文档未完全完善，但核心功能可正常使用，及时交付给用户进行测试，收集真实反馈。
  ③“客户合作高于合同谈判”：测试阶段主动收集32名用户的反馈，根据用户建议新增了食物拍照识别功能，提高操作便捷性，快速响应用户需求。

6. 软件工程质量提升计划

（1）代码管理质量提升

• 代码分支管理：采用GitFlow规范，建立master、develop、feature、hotfix，明确分支创建、合并规则。
• 代码复审优化：建立“复审清单”（包含功能完整性、代码规范、注释完整性、边界条件处理），核心模块必须经2人复审通过方可合并，普通模块需1人复审通过。
• 代码规范强化：制定详细的代码规范文档，引入自动检测工具，未通过规范检测的代码禁止提交。

（2）程序架构提升

• 模块化重构：将现有系统按“数据层、业务逻辑层、表现层”拆分，降低模块耦合度；核心功能封装为独立组件，便于复用和维护。
• 质量衡量：使用代码质量分析工具，定期检测代码复杂度、重复率、Bug数量，设定指标阈值，持续优化。

（3）软件工具应用提升

• 开发工具：引入Jira进行任务管理和进度跟踪，使用燃尽图可视化冲刺进度；
• 测试工具：JUnit 实现自动化测试；
• 文档工具：建立团队知识库，统一文档模板，实现文档版本控制。

（4）项目管理提升

• 任务拆分：按“颗粒度≤2天”拆分任务，明确每个任务的负责人、交付件、时间节点；
• 进度跟踪：每日更新任务进度，使用燃尽图监控冲刺进度，及时识别滞后任务并调整资源；
• 风险管控：建立风险评估矩阵，每月识别1次潜在风险，制定应对方案和责任人。

（5）用户数据跟踪提升

• 集成百度统计或友盟统计工具，监测每日活跃用户数、每周活跃用户数、核心功能使用率、用户留存率等数据；每周生成1份用户数据报告，分析用户行为特征，为功能优化提供依据。

（6）文档质量提升

• 建立文档模板库（需求说明书、设计文档、用户手册、测试报告），明确每个文档的章节结构和编写要求；
• 指定文档负责人，定期更新文档，确保文档与实际实现一致；
• 建立文档审核机制，核心文档需经PM和相关模块负责人审核通过后方可发布。

（7）人员领导与管理提升

• 工作考核：建立“任务完成率+代码质量+协作贡献”三维考核指标，每周进行1次工作反馈，针对性提出改进建议；
• 激励机制：表彰表现优秀的成员，增强团队凝聚力。

（8）软件工程理论心得体会

• 软件工程是“计划与灵活的平衡”：前期需制定清晰的计划和规范，避免混乱；但同时要预留弹性空间，应对需求变更和意外问题。
• 测试和用户反馈是“质量保障的核心”：仅靠开发人员自查无法覆盖所有问题，必须通过多维度测试和真实用户反馈，才能持续提升软件质量。
• 团队协作的“效率源于规范”：明确的角色分工、流程规范和沟通机制，能减少内耗，提升项目推进效率。

九、团队成员在Alpha阶段的角色和具体贡献

名字	学号	角色	团队贡献分	可验证的贡献
黄怀瑾	3223004381	后端（组长）	23	后端开发学生端用户认证模块、饮食/睡眠健康数据记录接口、数据分析统计接口，实现 AI 健康报告生成算法与健康预警逻辑，完成管理员端数据统计功能开发； 协助PM协调项目整体进度
严展桐	3223004388	后端	22	负责管理员端用户认证模块开发，开发运动、情绪健康数据记录接口及个人信息管理接口，完成体检报告管理、Excel 数据导出功能，优化数据库查询
凌紫君	3223004383	PM\前端	21	负责项目整体进度协调与需求澄清沟通，同时承担技术落地工作，主导路由配置、状态管理，以及管理员端学生管理页面、数据导出功能的前端开发
何珊	3223004211	测试	20	在系统Alpha阶段负责功能与性能测试，设计并执行307条测试用例，覆盖用户认证、健康记录、AI分析及管理后台模块，发现并记录关键Bug，确保核心功能可用性与数据准确性
阿迪拉·米吉提	3223004683	测试	19	完成用户认证、健康数据记录、数据分析、AI 报告生成、体检报告、管理员端、数据导出 7 大模块功能测试；编写全模块测试用例文档，完成全场景功能验证，保障产品交付质量
吴泓霏	3223004647	前端	18	注册登录页面、个人信息页面、睡眠情绪页面、管理员端数据可视化前端开发
邓滢	3223004684	前端	17	饮食、运动记录前端页面开发、实现饮食记录的数据可视化图表、优化运动记录的数据持久化逻辑

十、诸葛亮会议照片