软件工程第一次结对作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/SE2024
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/SE2024/homework/13261
这个作业的目标	阅读《构建之法》,用NABCD模型分析学生需求,创建原型模型解决需求问题
学号	102201506
结对成员学号	102201511
原型展示链接	https://modao.cc/proto/Be1eRrizskgaxpKE7iBUHi/sharing?view_mode=device&screen=rbpUPXyLdm8HpKiPb&canvasId=rcUPYG5kkIbKf0AD

《构建之法》第3章: 软件工程师的成长

3.1 个人能力的衡量与发展

3.1.1 初级软件工程师如何成长

• 技术技能：积累软件开发相关的知识，提升对具体技术的掌握和动手能力。
• 领域知识：积累问题领域的知识和经验，例如对游戏、医疗或金融行业的了解。
• 设计思想：对通用的软件设计思想和软件工程思想的理解。
• 职业技能：提升自我管理能力、表达和交流能力、与人合作的能力、按质按量完成任务的能力等。
• 实际成果：参与的项目、用户评价、市场占有率等实际成果。

3.1.2 软件开发的工作量和质量衡量

• 项目大小：用代码行数（LOC）或功能点来表示。
• 花费时间：以人月来表示，例如某项目花费了10个人×月。
• 代码质量：交付的代码中缺陷数量，可以用缺陷的数量除以项目大小来表示。
• 按时交付：稳定、一致的交付时间是衡量员工能力的重要方面。

3.1.3 团队对个人的期望

• 有效交流：能有效与其他团队成员交流。
• 说到做到：按时交付。
• 接受角色：接受团队赋予的角色并按角色要求工作。
• 全力投入：全力投入团队的活动。
• 流程要求：按照团队流程的要求工作。
• 做好准备：开始做事前做好准备工作。
• 理性工作：不要被个人的感情等因素驱动。

3.2 软件工程师的思维误区

3.2.1 分析麻痹（Analysis Paralysis）

• 想弄清楚所有细节、所有依赖关系之后再动手。

3.2.2 不分主次，想解决所有依赖问题

• 过于积极，想马上动手修复所有主要和次要的依赖问题。

3.2.3 过早优化

• 在某一个局部的问题上陷进去，未考虑全局。

3.2.4 过早扩大化/泛化（Premature Generalization）

• 软件的“软”还表现在它可以扩展，但过早泛化可能导致问题。

3.3 软件工程师的职业发展

3.3.1 职业发展路径

• 考级之路：通过职业资格考试证明能力。
• 公司内部成长：大公司有详细的职业等级和成长路径。
• 自我评估：通过自我评价清单检查自己的技能和知识。

3.3.2 微软公司的软件工程师职业等级

• SDE：初级软件开发工程师。
• SDE II：中级软件开发工程师。
• Senior SDE：高级软件开发工程师。
• Principal SDE：首席软件开发工程师。
• 更高职位：Partner SDE、Distinguished Engineer、Technical Fellow。

3.4 技能的反面

• 真正的能力：不仅是记忆和执行技能，更重要的是能够理解原理并灵活应对变化。
• 持续学习与实践：通过不断的练习和实际项目经验，提升问题解决能力。

3.5 软件工程的本质

3.5.1 工程 vs. 艺术

• 软件工程既需要工程的严谨和规范，也需要艺术的创造力和灵活性。

3.5.2 代码质量与数量

• 随着项目规模的增加，代码的结构化和可维护性变得更加重要。

3.6 实践中的启示

3.6.1 稳定与一致

• 在团队合作中，能够稳定、按时地交付高质量的工作结果。

3.6.2 持续改进与反馈

• 通过测试、反馈和迭代不断优化软件。

3.6.3 自我管理与成长

• 主动学习新技术、优化工作流程、提升职业技能。

《构建之法》第8章：需求分析

8.1 软件需求

• 获取和引导需求：软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。
• 分析和定义需求：对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化。
• 验证需求：软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。
• 管理需求：在软件的生命周期中，需求可能会变化，技术会发展，团队成员的能力也会提升，需持续审查和调整需求。

8.2 软件产品的利益相关者

• 用户：直接使用软件系统的人。
• 顾客：购买这个软件或者根据合同或规定接收软件的人。
• 市场分析者：市场部门要代表“典型用户”的需求。
• 监管机构：确保软件符合行业和政策规定。
• 软件工程师：工程师也是软件需求阶段的一个重要角色。

8.3 获取用户需求——用户调查

• 焦点小组：找到一群目标用户的代表，加上项目的利益相关者来讨论用户想要什么。
• 深入面谈：通过详细的面谈，广泛而深入地了解用户的背景、心理、需求等。
• 卡片分类：把各种需求做成便于规整的小卡片（或小贴纸）上，然后反复进行讨论、定义、归类、排序。
• 用户调查问卷：向用户提供事先设计好的问题，让用户回答。
• 用户日志研究：要求用户记录自己日常工作或生活中与所用软件相关的行为。
• 人类学调查：和目标用户“同吃同住同劳动”。

8.4 竞争性需求分析的框架——NABCD模型

• N（Need，需求）：明确解决用户的具体需求和痛点。
• A（Approach，做法）：提出独特的解决方案或方法。
• B（Benefit，好处）：展示产品或服务带给用户的具体好处。
• C（Competitors，竞争）：分析竞争对手，了解市场现状及竞争优势。
• D（Differentiation，差异化）：不同的产品的差异化.

8.5 功能的定位和优先级

• 杀手功能：产品的核心功能。
• 外围功能：对核心功能起辅助作用的功能。
• 必要需求：软件必须实现的功能。
• 辅助需求：非核心但有助于提升产品价值的需求。

8.6 计划和估计

• 目标：表达一个希望达到的状态。
• 估计：以当前了解的情况和掌握的资源，要花费多少人力物力时间才能实现某事。
• 决心：保证在某个时间之前完成预先规定的功能和质量。

8.7 分而治之（Work Breakdown Structure）

• WBS要点：
  • 保证所有子节点覆盖了全部父节点包含的内容。
  • 保证各个子节点不要相互覆盖。
  • 叶子节点要保证足够小，能在一个里程碑中完成。
  • 从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。

个人感悟

《构建之法》第3章和第8章分别针对软件工程师的成长和需求分析进行了全面阐述。第3章强调了技术技能、领域知识、设计思想、职业技能和实际成果的重要性，指出了工程师在职业发展中应避免的误区，并提出了职业发展路径。第8章则系统地介绍了需求分析的流程，包括获取、分析、验证和管理需求，以及如何通过NABCD模型进行竞争性需求分析。

个人感悟方面，这两章内容让我深刻认识到，软件工程师不仅要注重技术能力的提升，还要关注团队合作、沟通能力和持续学习。在需求分析方面，我学到了如何更有效地与利益相关者沟通，确保需求的准确性和完整性。这些知识对于我未来的职业发展和项目成功至关重要.

NABCD模型对该模型的分析

需求（Needs）

• 合作机会：学生需要一个平台来发现和联系不同专业的合作伙伴。
• 时间协调：需要工具来协调不同专业学生之间的课程安排和个人时间。
• 目标一致性：学生需要一个机制来确保所有团队成员对项目目标有共同的理解和承诺。
• 沟通方式：需要一个统一的沟通平台来促进不同背景学生之间的有效沟通。
• 资源支持：缺乏导师、技术资源和学习资源来支撑项目的持续发展。

方法（Approach）

• 智能匹配系统：开发一个算法，根据学生的专业背景、兴趣、项目需求和时间安排，智能推荐潜在的合作伙伴。
• 项目管理工具：提供在线项目管理工具，帮助团队成员协调时间表、设置项目目标和跟踪进度。
• 资源库：建立一个资源库，包括导师名单、技术工具、学习材料和案例研究，供学生使用。
• 沟通平台：提供一个内置的沟通平台，支持即时消息、视频会议和文件共享。

好处（Benefits）

• 扩大合作网络：学生可以通过平台接触到更广泛的潜在合作伙伴，不仅限于自己的社交圈。
• 提升项目管理能力：通过使用平台的项目管理工具，学生可以学习如何有效地管理项目。
• 增强沟通技巧：统一的沟通平台可以帮助学生学习如何在多元文化背景下进行有效沟通。
• 获取专业知识：通过跨专业合作，学生可以从其他专业的学生那里学习新的知识和技能。
• 增加项目成功率：有了合适的团队、资源和沟通，项目的成功率会大大提高。

竞争（Competitors）

• 传统校园论坛：通常仅限于校内沟通，缺乏智能匹配和项目管理功能。
• 社交媒体群组：如微信群、QQ群，虽然方便交流，但缺乏对跨专业合作的专门支持。
• 现有学术平台：一些学术平台可能提供有限的合作机会，但可能不够全面或者用户友好。

差异化（Differentiation）

• 专业化服务：专注于跨专业合作，提供从匹配到资源支持的一站式服务。
• 个性化匹配：通过算法个性化推荐合作伙伴，提高合作的成功率。
• 全面的资源库：提供广泛的资源，包括导师、工具和学习材料，以支持项目的各个方面。
• 用户友好的界面：设计一个直观、易于使用的平台，以提高用户满意度和参与度。
• 跨校区合作：支持不同校区甚至不同大学之间的学生合作，扩大合作的可能性。

项目流程图

总结

NABCD模型的优势在于其全面性和结构化，能够确保关键商业要素得到系统性考虑。它以用户需求为出发点，强调解决方案的客户价值，同时考虑市场竞争和产品差异化。这种模型简单易懂，便于团队沟通，促进跨部门协作。此外，它支持创新思维，鼓励团队探索独特的市场定位，从而在竞争中脱颖而出。NABCD模型适用于多种项目，有助于企业制定有效的商业策略和决策。

原型设计

登录界面

注册界面

个人主页

聊天界面

找项目和加入项目组界面

小组交流图片

PSP表格

PSP阶段	内容描述	预估耗时(小时)	实际耗时(小时)	备注
Planning	计划与任务分析	2	2	确定项目需求和目标
Development	需求分析	1.5	2.5	分析用户需求，设计系统架构
Development	原型设计	3	2	使用原型工具设计界面
Development	详细设计	2	3	完成详细设计文档
Testing	单元测试	4	3	对每个模块进行测试
Testing	集成测试	3	3	测试模块间的集成
Testing	系统测试	2	2	测试整个系统
Postmortem & Summary	总结和优化	1.5	1.5	项目总结，优化改进
总计		19	19

项目总结

本次项目的目标是设计一个促进大学校园内跨专业合作的平台。通过《构建之法》第3章和第8章的学习，我们了解到软件工程师的成长需要技术技能、领域知识、设计思想、职业技能和实际成果的全面发展。同时，需求分析是软件开发中至关重要的一环，它涉及到获取、分析、验证和管理需求。

项目流程和成果

在项目实施过程中，我们首先进行了计划与任务分析，明确了项目需求和目标。随后，我们进行了需求分析，设计了系统架构，并使用原型工具设计了界面。在详细设计阶段，我们完成了设计文档，并进行了单元测试、集成测试和系统测试，确保了软件的质量。

遇到的挑战

在项目开发过程中，我们遇到了一些挑战，如需求的不断变更和团队成员之间的沟通问题。为了解决这些问题，我们采用了敏捷开发的方法，定期进行需求评审和团队会议，确保项目按计划进行。

学到的经验

通过这次项目，我们学到了如何更有效地进行需求分析和项目管理。我们认识到了持续改进和团队协作的重要性，以及如何通过测试和反馈来优化软件。

未来展望

未来，我们计划继续优化平台的功能，增加用户反馈机制，以提高用户满意度。我们也将探索更多的可能性，如跨校区合作和国际化，以扩大平台的影响力。

结对工作的感受

结对工作让我们意识到了团队合作的力量。我们学会了如何更好地沟通和协作，共同解决问题。这种经历对我们未来的职业生涯大有裨益。

个人感悟

我对这次经历有以下个人感受：
团队协作的重要性：这次项目让我深刻体会到了团队合作的价值。每个成员都贡献了自己的专长，使得我们能够在有限的时间内完成一个相对复杂的任务。我学会了如何与他人有效沟通，协调工作，这是单独完成作业所无法获得的宝贵经验。
实践应用理论知识：将课堂上学到的软件工程理论应用到实际项目中，让我对这些概念有了更深入的理解。从需求分析到原型设计，再到模拟实现，每一步都是对所学知识的实践和巩固。
3. 用户体验的重要性：在模拟APP展示产品的过程中，我意识到了用户体验的关键作用。即使是一个初步的模型，也需要考虑到用户的需求和使用习惯，这让我对产品设计有了新的认识。
时间管理的挑战：在有限的时间内完成项目是一个挑战。我学会了如何更好地规划时间，设定优先级，这些技能对未来的学习和工作都很有帮助。
创新思维的培养：为了让我们的APP模型脱颖而出，团队中每个人都贡献了创新的想法。这个过程激发了我的创造力，让我认识到了创新在软件开发中的重要性。
6. 跨学科知识的重要性：在设计APP界面和功能时，我们不仅需要编程知识，还需要一些设计和市场营销的基本概念。这让我意识到了跨学科学习的重要性。
7. 处理分歧的能力：在项目过程中，难免会出现意见分歧。通过这次经历，我学会了如何以建设性的方式处理不同意见，找到平衡点。
对软件行业的认识：通过模拟实际的APP开发过程，我对软件行业有了更真实的认识。这次经历让我更加确定了自己未来的职业方向。
自我反思和成长：在项目结束后，回顾整个过程，我发现了自己的优点和不足。这种自我反思对个人成长非常有帮助。
10. 成就感：看到我们的努力最终转化为一个可以展示给客户的产品模型，我感到非常自豪和有成就感。这种正面的体验增强了我对学习和工作的热情。
总的来说，这次小组项目不仅让我学到了实用的技能，也让我对自己和团队合作有了新的认识。我相信这次经历将对我未来的学习和职业发展产生积极的影响。