[I.3] 个人作业：结课总结

[I.3] 个人作业：结课总结

项目	内容
这个作业属于哪个课程	2026年春季软件工程
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	了解软件工程开发流程，熟悉团队开发过程，能够与团队完成一个软件项目，积累沟通协作的能力
这个作业在哪个具体方面帮助我实现目标	通过回顾学期初的提问，反思自己在项目实践中的所得与所失

第一次作业链接：个人作业：阅读和提问

一、问题解答

问题一：在实际团队协作中，时间花费是如何计算的？Cocomo模型还准确吗？

我的解答：Cocomo模型作为宏观估算工具在特定场景仍有参考价值，但它无法描述“人月”的复杂性。实践中我们体会到了Brooks法则——增加人手反而拖慢了进度。通过对比各模块工作量，发现沟通成本随模块依赖关系呈指数增长。课后查阅COCOMO II资料，发现它已引入乘数因子修正早期不足。对于我们的课程项目，实际更依赖任务拆解和燃尽图进行管理。

问题二：在实践中，有哪些有效的方法或模板可以将模糊的非功能需求转化为可测试、可验证的具体指标？

我的解答：核心方法是用可测量的用户场景来描述非功能需求。我们将“响应要快”改为“100个并发用户下95%的登录请求在2秒内完成”；将“界面友好”改为“新用户5分钟后了解用法”。做法是在需求阶段引入量化验收标准，并与指导老师协商调整指标。这让测试和验收有了客观依据。

问题三：Program Manager VS. Project Manager,哪一个更适合小组软件开发？

我的解答：实践中我们发现纯粹的PM角色都不太适用课程项目。我们的做法是功能PM——由对某模块最了解的成员临时担任，负责任务拆解和进度跟进，同时也要写代码。决策采用集体讨论方式。这种“自组织”模式避免了“PM不干活”的矛盾，也让每个人都有机会锻炼管理能力。

问题四：在小组进行软件工程开发时，如何准确定义“用户”画像？

我的解答：
准确定义用户画像需要遵循"数据驱动、全员共识"的原则，具体分三步走：

第一步，收集真实数据。问卷调查（覆盖目标群体）和现场观察获取一手信息，而非凭空想象。例如校园类产品需覆盖新生、在校生、校友三类群体。

第二步，提炼画像卡片。为每种用户类型创建包含姓名、年龄、身份、使用目标、行为习惯和痛点的画像卡片，控制在3-5个，明确主要和次要画像。

第三步，持续验证更新用户画像应随产品迭代动态调整，不是一次性工作。核心是让团队对"为谁做"有一致认知，使功能优先级和交互设计有据可依。

问题五：小组开发的末期，如何进行有效的测试？

我的解答：
第一，回归测试。代码修复后重新执行核心流程用例，确保原有功能未被破坏。每次提交后运行冒烟测试覆盖主路径。

第二，非功能性测试。包括性能（响应时间、内存）、兼容性（不同设备/系统）、网络（弱网降级）和安全测试，确保产品在真实环境中稳定可用。小程序需特别关注微信版本、分包加载和权限授权。

二、各阶段学到的知识点

• 需求阶段：用户画像需基于真实调研数据提炼，而非凭想象编造，要让团队对目标用户有统一认知。
• 设计阶段：原型设计应以用户任务流为导向，先梳理操作路径再设计界面，避免功能堆砌。
• 实现阶段：小程序主包体积有 2MB 限制，大体积功能（如 XR、AR 模型）必须拆分到分包实现按需加载。
• 测试阶段：末期测试需覆盖功能、性能、兼容性三层，优先确保 P0/P1 级 Bug 清零后再考虑发布。
• 发布阶段：微信小程序提交审核前必须完成隐私协议合规改造，用户需主动勾选同意才能发起登录。
• 维护阶段：线上问题应通过日志和用户反馈双渠道监控，按严重程度分级响应，优先修复影响核心流程的缺陷。

三、心得与感悟

个人项目

在Lab1中，实验要求我们关注需求文档、功能文档的内容，而不是直接写代码。这让我明白到需求分析的重要性，以及在项目中如何与团队合作。
在Lab2中，掌握从现有代码逆向推导UML类图的方法，学会借助IDEA工具识别核心业务类与技术实现细节，能够绘制符合UML规范的类图，同时理解MVC架构模式在项目代码中的具体体现，包括模型、视图、控制器各层的职责划分和代表类。
在Lab3中，理解开发范式中“规范优先、可验证、可测试”的核心思想，掌握为方法撰写包含前置条件、主要流程、后置条件和异常分支的结构化规约的能力，并能够将规约组织成提示词引导LLM生成代码，最终通过自动化评测脚本进行验证与迭代，形成完整的质量闭环。
在Lab4中，理解测试的内容，了解如何编写测试，同时使用AI工具辅助测试。这让我明白到测试的重要性。

结对编程

结对编程花费时间较多，我和我的搭档一共花费四五次才真正完工，虽然过程很艰辛，但是也让我明白到团队合作的重要性。

在编程阶段，我们先定下整体框架，在讨论具体的实现细节。最终得出一个符合需求的实现方案。在策略设计方面，我们也通过讨论，最后确定了方案。两个人通过讨论，发现了互相的纰漏，及时调整了方案。

结对编程让我意识到团队合作的重要性，以及在项目中如何与团队合作。双人同时编程让我们在实践中进步迅速。

团队项目

回顾整个学期，最大感悟是：软件工程是应对复杂性的思维和沟通框架，而非方法论的堆砌。

从“个人英雄主义”到“团队合力”——结对编程让我明白“可读”比“聪明”重要；团队项目更让我认识到组织良好的团队产出远超个人相加。从“畏惧沟通”到“拥抱沟通”——80%的问题可以通过短平快的面对面沟通解决。同时我也产生了新的疑问：AI辅助编程工具日益强大的今天，软件工程的团队协作模式和测试方式会发生怎样的根本性变革？