从需求分析看软件开发的挑战
从需求分析看软件开发的挑战
part1 项目简述
本次高等软件工程课程，我们小组的题目是《社区疫情防控追踪系统》，基于对生活社区的疫情防控需要，建立一个轻量级易用的追踪系统，可以追踪社区每天进出的个人、每个人的状态，并能在社区间共享相关信息以实现风险评估和预警传播。该项目要求在手机上实现个人使用的程序（诸如微信小程序）。
part2 第一次需求分析
从项目的最开始阶段，团队就开始致力于确定软件的功能性需求，在选题的第一周，作为组长，我就组织了第一次线下的会议，主要作用有二：作用之一是，这是一个陌生的团队，对我而言，团队里一人是同实验室的同学，还算熟悉，一人是开学时因缘巧合认识的同班同学，也只说过几次话，另外两人，一人是同学的同学，一人是课程群里随缘拉到的同学，大多数人都比较陌生，需要进行简短的认识，了解大家的研究方向和擅长的内容，便于大家后续可以轻松交流，也方便根据每个人的特点分配任务。作用之二是，需要大家一起讨论，根据题意，确定项目的功能名称。
在第一次会议，团队成员，各抒己见，发表了对题目的看法，并经过深入的讨论，得到了一个较为完整的软件功能分析成果，也对团队成员进行了较为明确的分工。但是在后续的工作中，还是发现对软件功能的分析和团队分工有较大的问题。
在第一次需求分析的演示过程中，作为队长，我为组内每个成员分配了不同的任务，包括用例图，类图，RUCM，活动图，状态图，顺序图等，从分配任务开始，就存在了不少的问题，在我查看组员各自的“战斗”成果时，这些问题就逐渐显露出来。
- 问题1：时间分配问题，用例图，类图，我是要求全员参与，每个人负责思考一小部分的功能的用例图和类图，并在规定时间内向负责画用例图/类图的同学汇报自己的工作成果，但是，各个组员都有自己的“活动时间”，尤其是类图的汇总，没有在规定时间内完成。
- 问题2：成员之间的能力水平不一问题，在最初阶段，没有考虑到组员之间几近“悬殊”的实力差距，我也抱着锻炼和考验组员能力（手动狗头）的想法，在已经意识到负责类图的组员无法保证类图质量的情况下，继续让组员承担这一艰巨的任务，结果是，到最后，我自己演示前一小时含泪画完了类图。
- 问题3：不同人都不同功能理解不一致的问题，在完成任务的过程中，我发现，团队中的每个人，都对任务有不同的理解，有的人，把功能想象的过于简单（不排除偷懒的可能），有的人，会把问题的各个细节够考虑的非常细致，总之，在第一次需求分析的阶段，不同的人，对于同一个功能，有不同的理解。这也导致，当有其他人对功能的看法不一致的情况，会出现群内投票battle的问题。
在第一次需求分析演示之后，最大的问题是，存在我们对系统的理解不清晰，没有体现出系统的防控功能，并且难以实现，这是我们团队总体对题目理解有误导致的问题。
part3 需求评审
在第二次需求分析之前，我作为队长，花了接近两天时间，根据老师的建议，重新设计了一个系统，重新定义了系统的使用场景，并详细说明了系统的状态，用户的类别，用户状态，为消除团队成员对需求的理解不一致这一问题，文档中也详细说明了大多数功能的细节。并要求所有人仔细阅读这一文档，要求指出文档中存在的问题或是向我复述整个系统，以这样的方式，要求全员理解我们的系统，最终形成了一份大家都认可的文档，作为需求分析的蓝图。
在布置了需求评审的任务后，我为每个组员分配了各自的任务，这次任务量，相对于上一次的汇报，这次的任务量显的更大，任务更急，我为每个成员分配了适量的任务，自己的任务是，检查他们的成果，修改他们的成果，总结出文档，做PPT，演讲（嗯，最开始我觉得自己的工作量还是合适的），后期出现的问题如下。
- 问题1：小组成员之间对需求理解的轻微不一致，主要体现在数据导入导出，依靠之前的文档和队长我的“独裁”（这次有分歧，我说了算，毕竟我已经给了足够的时间给大家看我写的文档了），这一问题基本得到了解决，大大节省了时间。
- 问题2：能力相对薄弱的成员，能力依然没有有效提升（相比于第一次已经有了巨大的提升，但是这种提升还没到可以完成任务的程度，未来可期），所以最后作为队长，我还是承担了大量的作图任务，我之前的任务加上作图，汇报前三天我都是元气满满呢（狗头），幸好团队成员后期主动承担了一些任务，感谢大家。
- 问题3：任务分配不均的问题，虽然第一次线下会议就给了成员分工，但是，到最后的实施，并不是照着之前的计划。需要考虑每个人都有各自不同的其他学科任务，需要统筹兼顾，存在任务量不一致的问题，这个问题，确实难以解决。
- 问题4：自身任务量过大，因时间紧凑，外加难以平均分配任务，导致了我给自己分配任务过多，这进一步导致了我后期焦虑的问题，队长焦虑，也会导致真正想做好这门课的组员焦虑，也有多次有组员私信我以后要多分点任务给他们的情况，这一问题可以解决。
需求评审对全队成员都有比较大的考验，庆幸提前总结了第一次失败的经验，根据老师的反馈，重新对系统进行了设计，并在全队的努力下，按时完成了一份质量还算说得过去的需求文档，感谢全队成员的努力。
part4 总结
总结我们小组需求评审阶段，目前队伍配合良好，但是还是遇到了一些问题。
- 时间问题：小组内每个人的课程不尽相同，难以找到统一的时间线下会议，并且在布置完任务后，即使时间节点合理，也可能存在不能在规定时间完成任务的情况，目前主要通过群聊沟通。
- 个人能力问题：每个人的能力强弱不尽相同，存在队员完全不理解软件工程的情况，并且也可能存在成员参与度低导致显得能力不足的情况。幸运的是，已经看到成员能力的提升。
- 成员间理解不一致问题：对于复杂功能，即使经过了详细说明，在最后的用例图，RUCM图中，也显示出成员间理解不一致的问题。目前已经通过强制全员参与参与探讨，队长“独裁”等方式大致解决。
- 任务分配不均的问题：每个人的空闲时间不尽相同，为兼顾其他课程，分配任务前我会大致了解其他成员近期情况，存在为较忙的人少分配任务的情况，可能导致的隐患是其他成员的不满。目前难以解决，因为部分成员课程任务较重是客观事实，在实际的开发中，此类情况应该会有所好转。
- 自身任务过重的问题：原因可以归结为任务分配不合理，和对全局的控制欲过强，队长自身任务重会拖慢整体进度，导致队伍焦虑。此问题可以解决，经过长期的合作，已经大致了解了各位成员的能力和态度，部分任务的审核工作会交给责任心较强，对项目理解较深的成员承担。
