软件工程结对第一次作业

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/SE2024
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/SE2024/homework/13261
这个作业的目标	根据客户需求，为用户设计一个APP或小程序
学号	102202154
合作伙伴	102202154、102202155

使用墨刀设计原型：https://modao.cc/proto/mVb2KS0Zskcqy9dqRG6Qg/sharing?view_mode=read_only

一、《构建之法》阅读成果

第三章 软件工程师的成长

《构建之法》第三章深入探讨了软件工程师如何在职业生涯中成长，包括个人能力的发展、避免思维误区、职业路径规划以及对技能全面性的理解。

1.1 个人能力的衡量与发展

这一部分强调了软件工程师个人能力和职业发展的核心要素。书中提到，尽管许多软件系统是由个人开发或维护的，但是团队合作对于项目的成功同样至关重要。因此，除了技术专长之外，软件工程师还需要发展诸如沟通、协作、领导力等软技能。此外，个人的职业发展是一个持续的过程，需要不断地学习新知识、掌握新技术，并通过实践来提升自己的能力。

• 自我评估：定期进行自我评估是个人成长的关键。这有助于识别强项和弱点，从而设定明确的学习和发展目标。
• 主动学习：鼓励工程师们积极地寻找机会学习新的编程语言、工具和技术框架，以保持竞争力。
• 反馈循环：建立一个有效的反馈机制，无论是来自同事还是上级，都可以帮助个体更好地了解自己的表现，并据此调整行为。

1.2 软件工程师的思维误区

本节揭示了一些常见的思维误区，这些误区可能会阻碍软件工程师的职业进步和个人成长。例如，过于关注短期效率而忽视长期可维护性，或者过分依赖特定的技术栈而不愿意尝试新的方法。

• 追求完美主义：虽然高质量代码很重要，但过度追求完美可能导致项目延误。重要的是找到质量与速度之间的平衡点。
• 孤立工作：软件工程是一项团队活动，单打独斗往往不能达到最佳效果。学会与他人合作解决问题是非常重要的。
• 缺乏用户视角：开发时要始终考虑最终用户的体验。如果忽略了这一点，即便技术实现得再好也可能不会被市场接受。

1.3 软件工程师的职业发展

这部分讨论了软件工程师可能经历的不同职业阶段及其相应的发展方向。从初级工程师到高级专家，每个人的成长路径都是独特的。随着经验的增长，人们可以探索更多角色如技术领导者、项目经理等。

• 专业深化：选择一两个领域进行深度研究，成为该领域的专家。
• 横向扩展：拓宽视野，接触不同类型的项目和技术栈，增加自己的适应性和灵活性。
• 领导力培养：随着职位晋升，领导力变得越来越重要。学习如何激励团队成员并有效地管理项目。

1.4 技能的反面

最后，本节提醒读者警惕某些看似正面但实际上可能带来负面影响的行为模式。比如，专注于单一技能集可能导致职业瓶颈；另一方面，过度多元化也有可能分散精力，影响专注度。

• 技术债务：快速迭代过程中积累的技术债务如果不及时清理，将会给未来的开发带来麻烦。
• 过度设计：复杂的解决方案并不总是最好的。有时候简单的办法更有效且易于理解和维护。
• 忽视基础知识：即使是在不断追求最新趋势的同时，也不要忘记巩固基础，因为它们构成了所有高级概念的基础。

总结，《构建之法》第三章“软件工程师的成长”为我提供了丰富的启示和思考。它让我更加清晰地认识到软件工程师的成长路径和所需具备的能力素质，也为我未来的职业发展指明了方向。我相信只要我保持持续学习的态度、注重实践积累、提升团队合作与沟通能力、制定明确的职业规划并保持积极的心态和态度，就一定能够在软件工程师的道路上不断前行并取得更大的成就。

第八章 需求分析

阅读《构建之法》的第八章“需求分析”，我深刻体会到了在软件开发过程中，需求分析的重要性和复杂性。

1.1 软件需求

寻找需求：

1. 获取和引导需求（Elicitation）

软件团队需要找到软件的利益相关者，了解和挖掘他们对软件的需求，引导他们表达出对软件的需求。

2. 分析和定义需求（Analysis&Specification）

这是指对从各个方面获取的需求进行规整，定义需求的内涵，从各个角度将需求量化（需求实现的最后期限，实现需求大致所需的时间和资源成本，各个不同需求的优先级，需求带来的收益，等等）。

3. 验证需求（Validation）

软件团队要跟利益相关者沟通，通过分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求的认知。

4. 在软件产品的生命周期中管理需求（Management）

在软件的生命周期中，需求在发送变化，技术在发展，团队成员的能力在提高。

对软件需求的划分：

1. 对产品功能性的需求：要求产品必须实现某些功能。

2. 对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件，例如，开发过程必须产生某种类型的文档，必须在某个时间点达到某个状态，必须对源代码施以某种约束（安全性检查、代码版权核查、代码规范和支持文档的核查）。

3. 非功能性需求：例如：执行时间限制等。

4. 综合需求：可能牵涉到其他系统的情况。

1.2 软件产品的利益相关者

用户：

顾客：购买这个软件或者根据合同或规定接收软件的人。这些人不一定是软件的直接用户。

市场分析师：市场部门要代表“典型用户”的需求。

监管机构：

软件工程师：工程师也是软件需求阶段的一个重要角色，软件的各种约束、特性会影响到他们的工作效率、开发难度和软件维护的难度。他们应积极参与到软件需求阶段中来。

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

     用户最需要的>

               用户表达出来的>

                        软件团队能理解的+团队的商业目的>

                                 软件团队成员具体表达出来的（PM写Spec）>

                                           在各种约束条件下，具体执行表达出来的（Dev写代码）>

                                                    验证通过的（Test）>

                                                             通过各种渠道告诉用户目标（发布/推广）>

                                                                       用户终于能用上了，但是他们不满意

1. 焦点小组（Focus Group）

2. 深入面谈（In-depthInterview）

一般是一对一。

3. 卡片分类（Card Sorting）

讨论->明晰定义->归类->排序

4. 用户调查问卷（User Survey）

5. 用户日志研究（User Diary Study）

6. 人类学调查（Ethnographic Study）

这种方法听起来学术味很浓，其实可以解释为——和目标用户“同吃同住同劳动”。

7. 眼动跟踪研究（Eye Tracking）

一些研究发现了F模式。

8. 快速原型调研（Quick Prototype）

9. A/B测试（A/B Testing）

1.4 竞争性需求分析的框架

大部分普通用户的需求都有好几个互相竞争的机构在提供服务，对于互联网类型的软件来说，更是如此。很多需求并不是用户提出来的，而是技术的突破让产品团队看到了可以让用户做到以前不敢想、不敢做的事情——但这个时候大多数用户并没有意识到自己有这个具体需求。

1. N（Need，需求）

确定目标用户的具体需求是什么，为什么他们需要这个功能。

2. A（Approach，做法）

描述你计划如何解决这些需求，采用什么样的技术和方法。

3. B（Benefit，好处）

明确你的解决方案能够给用户带来哪些好处，如何提高他们的工作效率或生活质量。

4. C（Competition，竞争）

分析竞争对手的产品特点，找出你的产品与之相比的优势和劣势。

5. D（Delivery，推广）

规划如何将产品推向市场，包括营销策略、推广渠道等。

1.5 功能的定位和优先级

在这一部分，作者使用了四个象限的方法来帮助软件团队理解和处理不同类型的用户需求。这四个象限基于两个维度：功能的重要性和实现的难度。

杀手功能 vs 外围功能

杀手功能：这些是产品的核心功能，对用户来说至关重要。没有这些功能，产品可能无法在市场上立足。

外围功能：这些功能虽然重要，但不是产品成功的关键。它们可以增强用户体验或提供额外的价值。

必要需求 vs 辅助需求

必要需求：这些需求是产品必须满足的基本要求，否则产品将无法正常工作或失去市场竞争力。

辅助需求：这些需求虽然能提升产品价值，但不是必需的。它们可以在后续版本中逐步添加。

四个象限及应对措施

高重要性、低实现难度（杀手功能 + 必要需求）

措施：优先开发这些功能，因为它们既关键又容易实现，能够快速带来显著的价值。

高重要性、高实现难度（杀手功能 + 辅助需求）

措施：尽管实现难度大，但这些功能对于产品的成功非常重要。应该投入足够的资源和时间来确保这些功能的质量和性能。

低重要性、低实现难度（外围功能 + 必要需求）

措施：这些功能虽然不那么关键，但由于实现起来相对简单，可以作为次要任务来完成，以提高产品的完整性和用户体验。

低重要性、高实现难度（外围功能 + 辅助需求）

措施：这类功能通常可以放在项目的后期考虑，或者在时间和资源允许的情况下再进行开发。如果资源有限，可以考虑暂时放弃这些功能。

1.6 计划和估计

目标、估计和决心

• 明确目标：设定清晰、具体的目标，确保所有团队成员都理解并同意这些目标。
• 合理估计：基于历史数据、专家判断和经验法则来进行项目的时间和成本估计。
• 坚定的决心：一旦制定了计划，就需要有坚定的决心去执行，并根据实际情况灵活调整。

找出估计后面的假设

• 识别假设：列出所有的假设条件，例如技术成熟度、团队技能水平、外部依赖等。
• 验证假设：通过调研、原型测试等方式验证这些假设是否成立。
• 风险管理：针对可能的风险制定应对策略，减少不确定性带来的影响。

提高估计能力的招数

• 历史数据：利用过去的项目数据来改进估计的准确性。
• 分解任务：将大型任务分解成更小的任务，逐个进行估计。
• 专家评审：邀请有经验的专家参与估计过程，提供专业的意见。
• 持续学习：从每次项目的经验中学习，不断改进估计方法。

1.7 分而治之（Work Breakdown Structure）

做好WBS的几个要点：

     1.保证所有子节点覆盖了全部父节点包含的内容。

     2.保证各个子节点不要相互覆盖。

     3.叶子节点要保证足够小，能在一个里程碑中完成。

     4.从结果（Outcome）出发构建WBS，而不是从团队的活动（Action）出发。

总之，《构建之法》的第八章“需求分析”让我深刻认识到了需求分析在软件开发中的重要作用和复杂性。它不仅是软件开发的第一步，更是贯穿整个软件生命周期的重要工作。在未来的软件开发实践中，我将更加注重需求分析工作，努力提升自身的专业素养和团队协作能力。

二、NABCD模型

NABCD 模型是一种用于分析和描述产品或项目的方法，以下为你详细介绍：

一、N（Need，需求）

• 合作机会有限

1. 跨专业合作高度依赖个人积累的人脉资源，人脉不足则难以找到合适的合作伙伴。
2. 依靠不同专业的老师帮忙介绍的方式具有局限性，使得合作机会十分有限。

• 寻找伙伴困难
  对于多学科支持的项目，在大学校园里难以找到志同道合、具备相应专业能力的合作伙伴。
• 合作难度较大

1. 不同专业学生的学校课程安排不同，导致合作时间难以协调。
2. 各专业学生在项目目标上可能存在分歧，难以达成一致。
3. 沟通方式的差异也增加了合作的难度。

• 缺乏支持平台
  没有专门的平台或充足的资源来支持跨专业项目的持续发展。

二、A（Approach，做法）

• 项目发布与搜索：

  • 学生可以发布自己的跨专业项目需求，详细说明项目的背景、目标、所需专业技能等信息。例如，一个需要设计、编程和市场营销能力的创业项目，可以明确列出对不同专业学生的具体要求。
  • 其他学生可以通过关键词搜索，快速找到符合自己兴趣和专业能力的项目。同时，搜索结果可以根据项目的热度、发布时间等进行排序，方便用户筛选。

• 个人信息注册和专业技能标签：

  • 学生在注册时，选择自己的专业并添加相关的专业技能标签。例如，计算机专业的学生可以添加“编程”“软件开发”等标签；设计专业的学生可以添加“平面设计”“UI 设计”等标签。
  • 这样在项目搜索和匹配时，可以更加精准地找到具备相应技能的合作伙伴。

• 智能匹配推荐：

  • 基于学生的专业技能标签、项目偏好和历史合作记录，系统自动为用户推荐可能感兴趣的项目和合作伙伴。

• 沟通与协作工具：

  • 提供实时聊天、语音通话、视频会议等沟通工具，方便项目成员之间进行交流。

三、B（Benefit，好处）

• 对学生个人的好处

1. 综合能力提升：
   参与跨专业项目可让学生接触不同领域的知识和技能，锻炼解决复杂问题的能力，全面提升自身的综合素养。
2. 拓宽知识面：
   打破专业界限，了解其他专业的前沿动态和研究方法，丰富知识储备。

• 对学校的好处

1. 创新人才培养：
   促进跨专业合作有助于培养创新型、复合型人才，满足社会对多元化人才的需求。学校可以通过这种方式提升教育质量和声誉。

2. 校园文化建设：
   营造积极向上、开放包容的校园文化氛围，鼓励学生勇于尝试、创新，培养学生的团队合作精神和创业意识。

• 对社会的好处

1. 推动创新发展：
   大学生跨专业项目可能孕育出具有创新性的产品、服务或解决方案，为社会经济发展注入新的活力。

四、C（Competition，竞争）

• 学术交流平台：主要用于学术研究与合作。

• 项目管理工具：提供团队协作和项目管理功能，适用于多专业团队合作。

• 在线学习平台：虽然主要是提供课程，但也促进了跨学科的学习与合作。

• 社交网络平台：学生可以创建和参与项目小组。

• 校园内的学生组织或俱乐部：学校内部的组织会促进跨专业的合作和交流。

五、D（Delivery，推广）

• 校园活动

介绍平台的功能和优势。
组织跨专业的创新比赛，鼓励学生注册和使用。

• 社交媒体营销

在CSDN、博客园、知乎等平台上创建内容，展示成功案例和用户反馈。
利用短视频平台（如抖音）制作有趣的介绍视频，吸引年轻用户。

总之，NABCD 模型可以帮助你全面地分析和描述产品或项目，从而更好地满足用户需求，提高产品的竞争力和市场占有率。

三、分析客户需求

客户面临的困扰可以总结为以下几点：

人脉限制

学生希望参与跨专业项目，但往往缺乏足够的人脉，导致合作机会有限。

跨专业支持不足

对于需要多学科支持的项目，学生难以找到志同道合的合作伙伴，特别是在设计、编程和市场营销等领域。

沟通与协调难题

不同专业学生在课程安排、项目目标和沟通方式上的差异，使得跨专业合作的协调变得复杂。

缺乏持续发展平台

缺少支持跨专业项目的资源和平台，导致项目难以持续发展，无法实现长期的合作与成长。

解决方案

为了解决该困扰，我们为此设计了一款"闽宁跨域合作宝”，定位为一款专注于大学校园跨专业项目合作的平台，旨在帮助学生打破专业壁垒，轻松找到志同道合的合作伙伴，促进跨专业项目的顺利开展和持续发展。

1. 项目发布与搜索：

   • 学生可以发布自己的跨专业项目需求，详细说明项目的背景、目标、所需专业技能等信息。
   • 其他学生可以通过关键词搜索，快速找到符合自己兴趣和专业能力的项目。同时，搜索结果可以根据项目的热度、发布时间等进行排序，方便用户筛选。

2. 个人信息注册和专业技能标签：

   • 学生在注册时，选择自己的专业并添加相关的专业技能标签。例如，计算机专业的学生可以添加“编程”“软件开发”等标签
   • 这样在项目搜索和匹配时，可以更加精准地找到具备相应技能的合作伙伴。

3. 智能匹配推荐：

   • 基于学生的专业技能标签、项目偏好和历史合作记录，为用户推荐可能感兴趣的项目和合作伙伴。

4. 沟通与协作工具：

   • 提供实时聊天、语音通话、视频会议等沟通工具，方便项目成员之间进行交流。

四、流程图

五、原型设计

首页设计

注册

登录

完善个人信息

发布项目

发布帖子

消息中心

论坛

六、PSP表格

阶段	活动	输出	时间估算	实际时间
1. 需求分析	收集学生需求和项目特征	需求文档	1天	1天
2. 交流讨论	分析客户需求	解决方案	1天	1天
3. 原型设计	使用墨刀设计原型	模型的初步实现	2天	2天
4. 总结	线下讨论商议	总结报告	1天	1天

七、结对感受与收获

交流过程

总结与收获

• 王梓联
  作为来自宁夏的一名访学生，我也面临组队的困扰，毕竟来这边人生地不熟。为此，设计一个跨域交流平台既可以解决我的需求，也可以解决其他同学的困扰。在建模初期，我和我的搭档深入探讨了跨域交流的核心需求，包括创建项目、个人信息的管理、实时沟通交流等多方面的挑战。这使我更加认识到，设计一个成功的跨域交流平台，不仅需要技术上的支持，更需要对用户需求的深刻理解和把握。显然，我作为访学生，从我的角度来看，就算在我们同一个专业组队，都面临组队的困扰，更不用说，跨专业组队了，这是我亲身经历的感受。同时，我和我的搭档也积极学习并应用了最新的设计技术和工具，如原型设计软件、用户研究方法等，确保设计既具创新性又具可行性。与搭档的紧密合作是此次项目成功的关键。我们共同制定了项目计划，明确了各自的任务和责任，并在遇到问题时及时沟通、共同解决。这种团队协作模式不仅提高了工作效率，也增强了我们的凝聚力和信任感。通过用户研究和反馈收集，我更加深刻地认识到了用户导向思维在产品设计中的重要性。我学会了如何站在用户的角度思考问题，如何根据用户需求来设计和优化产品，以确保其能够满足用户的期望和需求。总之，这次跨域交流平台原型设计模型项目是一次宝贵的经历。它不仅让我在专业技能和团队协作能力上得到了提升，也让我在创新思维和用户导向思维方面有了更深刻的认识和体会。

• 王贺雯
  通过这次结对作业，我深刻体会到了团队合作的重要性。在合作中，我们可以互相学习、互相启发，共同攻克难题。同时，合作也让工作变得更加有趣和富有挑战性，激发了我们的创造力和积极性。我相信，这种合作的经验将对我今后的学习和工作产生积极的影响。本次作业对我的帮助非常大，为了促进闽宁协作，我们因此有机会到贵校体验访学，作为访学生的我们，第一次感受到了学校教学模式的不同，我们来这边感觉压力倍增，第一是学习压力，基础弱比较吃力，第二就是组队困难。正是我们正在面临这困扰，所有我们能清楚知道该客户的需求。通过NABCD，我们更加清楚设计一个跨域合作软件的重要性，所以将这个软件命名为“闽宁跨域合作宝”，由于第一次接触这种作业，完全没有头绪，所以参考了很多大佬的设计。