事后诸葛亮分析

事后诸葛亮分析

目录

• 一、 设想和目标
• 二、 计划
• 三、 资源
• 四、 变更管理
• 五、 设计/实现
• 六、 测试/发布
• 七、 总结

一、 设想和目标

1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
软件要解决的问题及相关分析
1.问题阐述
选课效率与公平性问题：随着高校规模扩大和学科细化，学生选课复杂性增加，传统人工选课方式效率低且易出现选课冲突、不公等问题。
管理不便问题：人工管理学生、教师、课程及成绩信息效率低下，难以快速准确地进行信息查找、修改、删除等操作。
2.定义清晰度分析
问题定义清晰：明确指出传统选课方式的弊端，如效率低、冲突多、不公等，以及人工管理信息的困难，使读者能清晰理解软件旨在解决的核心问题，为后续功能设计和开发提供明确方向。
3.典型用户和典型场景描述分析
典型用户
学生：使用软件进行选课、退课、查询成绩和个人信息管理等操作。
教师：通过软件管理所授课程的成绩，包括查询和修改学生成绩。
管理员：负责对学生、教师、课程信息进行全面管理，如录入、查找、修改、删除等操作。
典型场景
学生选课场景：学生登录系统，点击课程选修按钮，系统展示课程信息（编号、名称、性质、学分、专业、开课院系、教师等），学生选择课程后，系统显示已选课程，还可查询所选课程成绩。
教师成绩管理场景：教师登录后点击学生成绩按钮，系统显示其教授课程的学生成绩，教师可输入查询课程，筛选对应成绩，还能修改学生成绩。
管理员信息管理场景：管理员可分别点击学生管理、教师管理、课程管理按钮，对相应信息进行录入、筛选、修改、删除等操作，如录入学生学号姓名、根据学院专业等筛选教师、修改课程信息等。
4.描述清晰度分析
描述清晰：详细描述不同用户在系统中的操作流程和目标，使读者能直观感受到软件在不同场景下的功能和作用，有助于开发人员针对性设计和优化系统功能，也便于用户理解如何使用软件解决自身问题。

总结：该软件要解决的问题定义清晰，且对典型用户和典型场景有明确清晰的描述，有助于软件的开发和用户的使用。

1.2我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
目标达成情况分析：
功能实现情况
核心功能基本实现
选课退课功能：学生可点击课程选修按钮查看课程信息并选择课程，系统能正确处理选课操作，且学生可查看已选课程；同时，学生能点击课程退选按钮，系统根据学号查询并退选课程，满足了学
生选课退课的需求。
成绩管理功能：教师点击学生成绩按钮可查看教授课程的学生成绩，还能输入查询课程筛选成绩，并且可以修改学生成绩，实现了成绩查询与修改功能，方便教师管理学生成绩。
课程管理功能：管理员点击课程管理按钮后，能对课程进行筛选、修改信息和删除操作，如根据课程类型、开课院系筛选课程，修改课程信息，删除对应课程，达到了对课程有效管理的目的。
学生管理功能：管理员在学生管理模块，可进行录入学生信息、根据学号姓名等筛选学生、查找修改删除学生信息等操作，系统能根据管理员操作显示相应学生信息，实现了学生信息管理的各项要
求。
教师管理功能：管理员点击教师管理按钮后，能够录入教师工号姓名等信息，筛选教师，修改或删除教师信息，系统会显示目标教师信息，完成了教师管理的功能设计。
部分功能完整性待提升：
在学生管理、教师管理等功能中，虽然实现了基本的增删改查操作，但对于一些特殊情况或复杂筛选条件的处理可能不够完善，例如多条件组合筛选时的准确性和效率可能需要进一步优化。
交付时间情况：已按时提交相关报告与上传代码。
用户数量情况：尚未达到原定用户数量（原计划：200）

1.3用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
1.用户量情况分析
原定用户量目标为 200，但当前仅有五十左右，实际用户量远低于预期。这表明在吸引用户使用方面可能存在诸多问题，例如推广力度不足，未能让更多潜在用户知晓产品；产品知名度低，在市
场中缺乏足够的影响力；用户获取渠道不畅，没有有效触达目标用户群体等。需要深入剖析这些原因，以制定针对性的策略来提升用户量。
2.用户对重要功能接受程度分析
选课退课功能：学生能够借助系统便捷地进行选课和退课操作。系统展示的课程信息全面，涵盖课程编号、名称、性质、学分、专业名称、开课院系、上课教师等，为学生提供了充足的决策依
据。
操作流程简单明了，学生只需点击选修按钮选择心仪课程，点击退选按钮即可依据学号退选课程，这与事先预想的学生期望便捷选课退课的需求高度一致，学生对此功能的接受程度可能较高。
成绩管理功能：教师能够轻松点击按钮查看所教授课程的学生成绩，并且可以通过输入查询课程精准筛选特定成绩，还具备修改学生成绩的权限。该功能完全满足了教师日常管理学生成绩的工作
需求，与预期教师对成绩管理功能的需求完美契合，因此教师对这一功能的接受程度较好。
课程管理功能：管理员在课程管理方面能够顺利进行筛选课程、修改课程信息和删除课程等操作。系统能够依据管理员选择的操作做出准确对应处理，比如按照课程类型、开课院系进行筛选等，
成 功实现了对课程管理的基本功能，与预先设想的管理员管理课程的需求大体相同，基本符合管理员的操作期望。
学生管理和教师管理功能：管理员在学生管理和教师管理中能够开展常规的录入、查找、修改、删除操作，系统也能正确响应并显示相应信息。然而，随着管理数据量的不断增加，如果操作效率
和准确性受到影响，可能会降低管理员对功能的接受程度。目前在基本操作上与理想状态下高效管理信息的预想存在一定差距，需要进一步优化以提升管理员的使用体验。
3.与目标距离分析
功能方面：重要功能在基本操作和流程上与事先预想的用户需求相契合，这是朝着目标迈进的积极信号。但在功能的深度和广度上，仍有进一步优化的空间。例如，可以提升管理功能在处理大数
据量时的性能，增加个性化或高级的筛选、统计功能等，以更好地满足用户日益复杂多样的需求，从而更接近目标。
用户量方面：目前用户量远低于原定目标，这严重阻碍了向整体目标的靠近。需要全面审视产品策略，在持续优化功能质量的同时，加大市场推广力度，改善用户体验，精准定位产品，吸引更多
************用户使用，逐步实现预期的用户增长目标，否则难以实现整体目标。
总结：用户对重要功能的接受程度在基本层面与预想有一定一致性，但仍有改进余地。然而，用户量未达预期极大地影响了向目标靠近的进程，需要全方位优化产品策略，以提升功能质量和用户体验，同时加强市场推广，吸引更多用户，最终实现目标。

二、 计划

1. 是否有充足的时间来做计划?
时间上刚刚好，但是总体来算时间并不充裕，没有足够的时候进行更多的数据测试。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
通过会议，面谈等语言沟通，力求能理解到每一位成员对项目的展望与计划的异议，从而进行合理的协商。

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
大致上都已经实现，有一些测试尚未完成，时间不充裕，近段时间其他课程考试与课程设计任务繁重。

4.有没有发现你做了一些事后看来没必要或没多大价值的事?
客户端的系统相关的展示。

5.是否项目的整个过程都按照计划进行，项目出了什么意外？
主题在慢慢的协商中出现较大的变动，原计划为简单地学生信息管理系统，最后变成稍微复杂化的学生-教师-管理员端教务系统。

6.有什么风险是当时没有估计到的，为什么没有估计到?是否每一项任务都有清楚定义和衡量的交付件?
代码逻辑复杂，页面跳转功能没有想象中的简单易上手。因为自身对该项技术尚未熟练掌握。是的。

7.在计划中有没有留下缓冲区，缓冲区有作用么?
有留下缓冲区；有很大的作用；

8. 将来的计划会做什么修改？
更深层次的初始主题协商，更加深入的项目交流。为任务留有更加充裕的缓冲时间。

三、 资源

1. 我们有足够的资源来完成各项任务么?
没有，资源较为有限。

2.各项任务所需的时间和其他资源是如何估计的，精度如何?
按天估计。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
并不算充裕。是的【低估难度】。

4.你有没有感到你做的事情可以让别人来做（更有效率）?
各成员分工合理，尚未发现该问题。
四、 变更管理

1. 每个相关的员工都及时知道了变更的消息?
是的

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
集体讨论其去留。

3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
功能完整性方面：
核心功能正常运行：从文档描述来看，对于系统的主要功能如选课退课、成绩管理、课程管理、学生管理和教师管理等，在基本操作流程上有较为详细的说明，并且展示了系统在这些功能上的运
行
逻辑和处理方式。例如，学生能够完成选课、退课操作，教师可以查询和修改成绩，管理员能对各类信息进行有效管理，这表明在功能实现层面有一定的定义，但对于 “做好了” 的标准仅停留在
基
本功能可用阶段。
未涉及功能深度和扩展性：然而，对于功能的深度和扩展性并没有清晰定义。比如，在选课功能中，没有提及是否支持复杂的课程冲突检测算法（如考虑跨专业、跨学期课程冲突等），以及在大量
学生同时选课情况下系统的性能和稳定性标准；成绩管理功能是否能实现数据的深度分析（如成绩分布统计、趋势分析等）也未明确；课程管理中对于课程信息的批量处理、与其他教学系统的数据
交互等扩展性需求未作规定。
用户体验方面
基本操作流程描述为主：文档主要围绕系统功能的操作流程进行阐述，如学生、教师和管理员在各自功能模块中的操作步骤。虽然这在一定程度上反映了对用户操作体验的关注，但对于用户体验的
全面定义不足。
缺乏用户反馈机制相关定义：对于如何收集用户反馈以及根据反馈进行系统优化调整的流程和标准没有定义，这意味着在系统上线后，难以衡量用户对系统的满意度是否达到 “做好了” 的程度，
也无法有效持续改进系统以提升用户体验。
数据准确性和完整性方面
数据操作流程描述：数据在各个功能模块中的录入、查询、修改和删除等操作流程简单易上手【具备完善的提示内容】，如管理员录入学生信息、教师修改成绩等，

4.对于可能的变更是否能制定应急计划?
是的。

五、 设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在第一篇随笔期间，由组长组建团队初期召开相关会议协商决定。是合适的时间，合适的岗位合适的执行者。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，例如：用户的注册功能并不确认是否添加，后来经过团队协商，认为教务系统中的用户并不能注册，应该与其他系统相嵌合以导入。

3.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
选课功能Bug最多，因为后台逻辑较为复杂。暂时未发现什么严重的bug。

4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
小组成员分别对github仓库中的最终项目进行下载并且导入不同的数据进行测试，严格执行代码规范。
六、 测试/发布

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

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

3.团队是否有测试工具来帮助测试？
并没有统一的工具。

4.在发布的过程中发现了哪些意外问题？
项目测试并未完善，遗漏了一些并没有事先预想过的问题。
七、 总结

1. 每个成员在beta 阶段的实践和alpha 阶段有何改进?

成员	改进内容
杨殷（组长）	在 Beta 阶段相较于 Alpha 阶段在沟通协调、问题解决、任务规划与执行等方面均有显著改进，这些改进有助于提升项目的整体质量和推进效率，确保项目朝着成功的方向发展。
陈奕奕	Alpha 阶段的界面和体验设计较为初步，更多关注功能实现；而 Beta 阶段的重点是改善用户界面的易用性，收集实际用户的意见进行调整。
林闰埼	alpha阶段实现产品的基本功能，修复代码中的基本错误和bug，与团队成员协作，确保产品原型的实现，Beta阶段根据alpha阶段的测试结果，优化代码质量和性能，实现新的功能或改进现有功能。
坤杜孜阿依.吾舒尔	测试对一个项目十分重要，如果有充足的时间可以进行多测试
阿拉努尔.吾拉音	对团队的成员有了更对的了解，认识大家的特长，从而更合理的安排适合彼此的任务
迪力拜尔·赛买提	无论是在分析与讨论的环节，还是在实际设计的时候，都是临时发现一个问题然后再去解决问题，不断地循环往复。在beta阶段，因为有了经验，很多地问题可以早早地发现并解决，在分析与设计时都能更准确抓住关键。
刘宇婷	alpha阶段需要判断需求设计和原型设计是否明确。如果不够明确，需要在beta阶段加强前期的规划和设计工作，同时，注意数据库模型设计和代码风格是否规范。如果不规范，需要 制定更严格的规范并确保遵守。beta阶段需要反思是否制定了明确的开发计划，特别是对于不确定性较大的功能。如果计划不明确，需要在前期制定更明确的计划，并反思代码复审是否严格执行，代码规范是否得到遵守。

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

名字	角色	团队贡献分（30分）	可验证的贡献
杨殷（组长）	组长，后端开发，测试	29	推广，测试项目，组织制定计划，分工
陈奕奕	前端开发	26	根据需求文档，完成前端功能模块的开发，编写并执行测试用例，及时发现和报告BUG
林闰埼	前端开发	27	根据需求文档，完成前端功能模块的开发，负责验证bug并关闭
坤杜孜阿依.吾舒尔	负责博客编辑	24	分析关于报告内容与资料
阿拉努尔.吾拉音	负责博客编辑	24	书写开发文档，收集开发文档
迪力拜尔·赛买提	负责博客编辑	24	编写文档及测试
刘宇婷	后端开发，测试	27	根据需求文档，完成对应功能的后端代码开发；编写和执行后端接口、功能测试用例，发现修复回归并关闭bug

3.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
团队目前的状态处于初始级向可重复级过渡的阶段，但尚未完全达到可重复级。团队具备一定的基础开发能力，但在项目管理过程的规范性、软件开发过程的定义和优化等方面仍有较大的提升空
间。

4.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
团队目前处于磨合阶段向规范阶段过渡的时期。虽然已经取得了一定成果，但在项目管理的规范性、团队协作的高效性以及创新能力等方面仍需不断努力，逐步建立完善的工作流程和规范，加强团
队协作与沟通，培养创新意识，以推动团队向更高阶段发展。
5.你觉得目前最需要改进的一个方面是什么?
代码编辑能力。
八、其他
团队讨论照片