软件工程第一次结对作业

这个作业属于哪个课程	软件工程
这个作业要求在哪里	作业要求
这个作业的目标	分析同学们的需求，设计一个app原型解决客户的困扰
学号	052205144
合作伙伴	072208130曹星才

使用figma设计原型，原型链接：https://www.figma.com/design/0UL6vGH95oFVeFNIzFBKCM/软工第三次作业?node-id=0-1&t=VynEhJOI1qX6C14K-1

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

第3章 软件工程师的成长

”如果你有机会观察一个刚入职的软件工程师和一个工作多年、卓有成效的高级工程师，你会看到他们在公司里的行为没啥区别“，那除了比工作年头之外，软件工程师还有什么更好的方法来衡量自己的能力和价值？阅读《构建之法》第3章我们可以找到这个问题的答案。

（一）个人开发流程

软件开发流程不光指团队的流程，还包括个人开发流程，因为软件团队是由个人组成的。在团队的大流程中，是每一个具体的个人在做开发、测试、用户界面设计、管理、交流等工作。因此，个人在团队中也有独立的流程。

（二）Individual Contributor(IC)

软件团队和团队中的工程师也是这样。软件系统的绝大部分模块都是由个人开发或维护的。在软件工程的术语中，我们把这些单个的成员叫做Individual Contributor(IC)。

IC在团队中的流程

• 通过交流、实验、快速原型等方法，理解问题、需求或任务
• 提出多种解决办法并估计工作量
• 其中包括寻找以前的解决方案，因为很多工作是重复性的
• 与相关角色交流解决问题的提案，决定一个可行的方案
• 执行，把想法变成实际中能工作的代码，同时验证方案的可行性和其他特性(例如程序的效能等)
• 和团队的其他角色合作在测试环境中测试实现方案，修复缺陷(Bug)。如果此方案有严重问题，就考虑其他方案
• 在解决方案发布出去之后对结果负责

（三）初级工程师如何成长

1. 积累软件开发相关的知识，提升技术技能(如对具体技术的掌握，动手能力)。

例 如：对 Java、C/C++、C#的掌握，诊断/提高效能的技术，对设备驱动程序(Device Driver)、内核调试器(Kernel Debugger)的掌握；对于某一开发平台的掌握。

2. 积累问题领域的知识和经验(例如：对游戏、医疗或金融行业的了解)。

第一点和第二点在很多简历上都可以看到，也可以比较容易地检测出来。随着经验的 增长，一个工程师可以掌握更广泛、更深入的技术和问题领域的知识。

3. 对通用的软件设计思想和软件工程思想的理解。

这一方面就比较虚，什么是好的软件设计思想?什么是好的软件工程思想?一个工程 师开了博客，转发了很多别人的文章、这算有思想么?另一个工程师坚持做任何设计 都要画 UML图，这算有思想么?

4. 提升职业技能(区别于技术技能)。

职业技能包括：自我管理的能力，表达和交流的能力，与人合作的能力，按质按量完 成任务的执行力，这些能力在IT 行业和其他行业都很重要。

5. 实际成果。

绝大部分软件工程师的工作成果都是可以公开的，你参与的产品用户评价如何?市场 占有率如何?对用户有多大价值?你在其中起了什么作用?行胜于言，这些实际的工 作成果，是最重要的评价标准。

（四）软件开发的工作量和质量怎么衡量

1. 项目/任务有多大?

说明项目的大小，一般用代码行数(Line Of Code, LOC)来表示；也可以用功能点(Function Point)来表示。

2. 花了多少时间?

可以用小时、天、月、年来表示。一组人所花费的时间可以用(人数×时间)来表示，例如某项目花费了10个人×月。

3. 质量如何?

交付的代码中有多少缺陷?交付有两个定义：

• 在代码完成(Code Complete)时，交付给测试人员
• 在软件最终发布时，交付给顾客可以用缺陷的数量来除以项目的大小。例如5 Bugs / KLOC,意味着每千行程序有5个缺陷。用“re-work”来表示质量，例如：这1000行代码，从开始写到最后发布， 一共修改了200行·次。另一组代码，从开始写到最后发布，一共修改了50行·次。那 么改动少的代码最初质量高—因为 re-work(返工)的次数少。

4. 是否按时交付?

（五）团队对个人的期望

1. 交流：能有效地和其他队员交流，从大的技术方向，到看似微小的问题。
2. 说到做到：就像上面说的“按时交付”。
3. 接受团队赋予的角色并按角色要求工作：团队要完成任务，有很多事情要做，是否能接受不同的任务并高质量完成?
4. 全力投入团队的活动：就像一些评审会议，代码复审，都要全力以赴地参加，而不是游离于团队之外。
5. 按照团队流程的要求工作：团队有自己的流程(见“团队和流程”一章),个人的能力即使很强，也要按照团队制定的流程工作，而不要认为自己不受流程约束。
6. 准备：在开会讨论之前，开始一个新功能之前，一个新项目之前，都要做好准备工作。
7. 理性地工作：软件开发有很多个人的、感情驱动的因素，但是一个成熟的团队成员必须从事实和数据出发，按照流程，理性地工作。

（六）软件工程师的思维误区

a.分析麻痹

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

c.过早优化

d.过早扩大化/泛化(Premature Generalization)

（七）总结

对于”专“和”精“，工程师应该在实际中不断学习和不断成长，根据自己的情况选择在哪个方面追求“专”和“精”，在哪几个方面达到“知道就好”的水平。对于技能层面，我们要通过不断的练习，把低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间来解决高层次的问题，这也是我们成为一个好的软件工程师的前提。该章节主要探讨了现代软件开发中的迭代与增量开发。在软件开发过程中，强调了分阶段、分步骤的开发策略，而不是一次性完成整个项目。这种迭代与增量式开发模型能够让开发团队不断地根据反馈优化产品，提升软件的质量和适应性。具体来说，这一章介绍了如何通过小规模的迭代开发，逐步添加功能，并在过程中确保软件的稳定性。这种方法不仅提高了开发效率，也减少了项目的风险。

第8章 需求分析

（一）软件需求

A. 获取和引导需求(Elicitation)

B. 分析和定义需求(Analysis & Specification)

C. 验证需求 ：分析报告、技术原型、用户调查或演示等形式向他们验证软件团队对于这些需求认知。

D. 在软件产品的生命周期中管理需求(Management)

E. 软件需求的划分：

• 对产品功能性的需求
• 对产品开发过程的需求
• 非功能性需求
• 综合需求

（二）软件产品的利益相关者

A. 用户: 或称最终用户(User, End-user),是直接使用软件系统的人。

B. 顾客: 或称客户(Customer, Client),购买这个软件或者根据合同或规定接收软件的人。

C. 市场分析者：代表“典型用户”的需求，他们或者是市场部门的成员，或者是独立的市场分析人士。

D. 监管机构：在一些行业，软件必须符合许多行业和政策规定(如银行、公共交通、通信、矿产资源等)。

E. 系统/应用集成商：系统/应用集成商负责给客户提供 咨询、服务成等工作。

F. 软件团队：具体完成某一个特定软件或特定功能的团队。

G. 软件工程师：工程师也是软件需求阶段的一个重要角色

（三）获取用户需求—用户调研

A. 软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程。

B.几种常用的用户调研方法：

1. 焦点小组(Focus Group)
2. 深入面谈(In-depth Interview)
3. 卡片分类(Card Sorting) 讨论→明晰定义→归类→排序
4. 用户调查问卷(User Survey)
5. 常见错误：问题定义不准确；用含糊不清的形容词、副词描述时间、数量、频率、价格等；用户花额的努力来回答问题；问题带有引导性的倾向；问题涉及用户隐私、用户所在公司的商业机密或细节等。
6. 用户日志研究(User Diary Study)
7. 人类学调查(Ethnographic Study)
8. 眼动跟踪研究(Eye Tracking)
9. 快速原型调研(Quick Prototype) 用户参与式设计
10. A/B测试(A/B Test)

C. 各种方法的分类

D. 最好不要做过头了

（四）竞争性需求分析的框架

A.“创新”可以分为改良型的创新(在现有软件中增加几个功能，把某个程序变得更快一点，把程序移植到新的 平台)和颠覆型的创新(一个新的产品导致旧产品或产业发生巨大的变化或者消失)。

B.NABCD模型：

1. N(Need,需求) ，即了解用户的需求
2. A(Approach,做法) ，即找到了需求之后下一步应该怎么办，即你独特的做法
3. B(Benefit,好处) ，即有了独特的做法，那你这个产品/服务会给客户/用户带来什么好处
4. C(Competitors,竞争) ，即要看清楚我方优势在哪里，我方劣势在哪里。
5. D(Delivery,推广) ，即怎样把你的创新产品交到用户的手中

C. “电梯演说”模板（团队成员）

（五）功能的定位和优先级

得到了需求之后，软件团队就要考虑实现这些需求。

A. 功能分析：

1. 杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。
2. 外围功能：良好的界面设计，在各个平台上都能运行。
3. 必要需求：单词短语释义的准确性(如果达不到这一点，用户就不会来使用)。
4. 辅助需求：可以做各种皮肤(这也许能让一些用户更喜欢这个软件，但不是决定因素)

B. 资源有限，我们对不同功能有哪些办法呢?

1. 维持—以最低成本维持此功能。
2. 抵消—快速地达到“足够好”、“和竞争对手差不多”。
3. 优化—花大力气做到并保持行业最好。
4. 差异化—产生同类产品比不了的功能或优势(我有人无的优势，或者一个数量级以上的优势)。
5. 不做—砍掉一个功能也是一个办法，我们并不一定要做所有的功能。

C. 对四个象限的不同建议

D. 用户满意度

E. 在某一属性上增大投资力度，用户满意度未必提高

F. 让入惊喜的功能，会极大提高用户的满意度

G. 各种不同投资的不同效果

二、NABCD模型🍼

（一）、需求分析 (N - Need)

• 学生希望通过发起或参与跨专业的项目（创业、学术）来提升自己的综合能力，拓宽知识面和积累人脉

• 对于一些需要多学科支持的项目（需要设计、编程和市场营销能力的创业项目），在偌大的校园中，学生们需要找到志同道合的合作伙伴，能够交流。

• 不同专业之间的学生由于学校课程安排以及个人想法，可能在合作时间安排上、项目目标和沟通方式上可能存在差异，因此，学生需要能够合理安排各项成员和任务的时间表

• 大多数学生缺乏平台或资源来支持跨专业项目的持续发展，因此，学生需要有为他们提供资源的平台

（二）、关键功能与界面设计 (A - Approach)

风格：

1. 首页/登陆注册界面

• 功能：
  • 用户注册与登录界面，用户可以选择使用学生证/身份证/手机号进行注册或者登陆
• 界面要素：
  • 输入框（用户名、密码）
  • 注册和登录按钮
  • “忘记密码”链接
  • 用户协议等简要说明

2. 用户主页

• 功能：
  • 根据用户的专业和兴趣，个性化推荐可能感兴趣的项目或合作伙伴。
  • 主要展示正在进行的热门跨学科项目，按领域或合作需求进行分类（如：设计、编程、市场营销等）。
• 界面要素：
  • 导航栏：主页、项目、合作伙伴、个人资料
  • 卡片式项目展示，带有项目名称、领域、需求人才类型、剩余空位等信息
  • 顶部搜索框

3. 发起项目界面

• 功能：
  • 用户可以发起一个新的跨学科项目，描述项目的背景、需求、时间安排、合作目标等。
  • 项目发起人可以指定需要的合作伙伴类型（如设计师、程序员、市场营销人员等）。
• 界面要素：
  • 项目标题输入框
  • 项目描述区
  • 合作伙伴需求类型
  • 时间表与项目阶段设置
  • 提交按钮

4.项目详情界面

• 功能：
  • 详细展示某个项目的具体信息，包括项目目标、合作伙伴、导师、进度更新等。
  • 项目内沟通模块，团队成员可以在项目页面中进行交流和分享文件。
• 界面要素：
  • 项目简介、目标、需求技能等详细描述
  • 当前已加入的团队成员展示
  • 项目任务板，列出任务清单和完成情况
  • 项目内部聊天模块，方便团队沟通
  • 有邀请队员的按钮
  • 队长可在右上角进入时间管理与任务分配界面，队员也可进入，但权限为仅查看

5. 时间管理与任务分配界面

• 功能：
  • 项目发起人可以根据时间安排来为每个成员分配具体的任务。
  • 任务进展和截止日期提醒，帮助团队更好地管理时间和进度。
• 界面要素：
  • 任务列表（任务名称、截止日期、负责人、状态）
  • 日历视图显示每个任务的时间安排（可选）

6.合作伙伴页面

• 功能：
  • 展示所有聊天对话框
• 界面要素：
  • 列表显示聊天对话框
  • 右上角点击展示所有合作伙伴

7.合作伙伴详细页面

• 功能：
  • 展示所有所有聊天伙伴
• 界面要素：
  • 列表显示所有聊天伙伴，点击可以进入聊天伙伴的个人资料页

8.聊天页面

• 功能：
  • 可以与合作伙伴进行聊天
• 界面要素：
  • 底部输入框，主体页面展示聊天内容
  • 点击右上角可以看聊天对象的个人资料

9.个人资料页

• 功能：
  • 展示个人资料，包括头像、名字、专业、学号、联系方式、感兴趣的方向等个人信息
  • 展示已经参加了哪些项目
• 界面要素：
  • 右上角是设置按钮
  • 头像（旁边是名字），下面为其它个人信息展示

10. 隐私与安全设置

• 功能：
  • 用户可以设置隐私权限，决定哪些信息可公开，哪些仅限于合作伙伴查看。
  • 用户可以选择退出账号或者注销账号
• 界面要素：
  • 隐私设置选项：公开资料、仅团队可见资料、项目可见权限等

11.注册页面

• 功能：
  • 用户可以在该页面进行注册
• 界面要素：
  • 名字、学号、联系方式、身份证号、密码元素

（三）、解决方案的优势 (B - Benefit)

1. 跨学科知识共享与协作

该平台可以不仅仅是一个项目匹配工具，还可以作为学生们分享和学习不同学科知识的社区。例如，平台可以设置论坛或知识分享区，学生可以在项目之外交流各自学科的知识，这有助于他们在实际合作中更好地理解彼此的思维方式和工作方式。

2. 个人技能提升和展示

通过参与跨专业项目，学生可以积累更多实战经验，并通过平台记录和展示自己的技能和项目经历。平台可以为学生提供类似于“技能证书”或“成就徽章”的功能，帮助他们在未来求职中展示跨学科的综合能力。

3. 项目生命周期管理

平台可以提供完整的项目生命周期管理功能，从项目初始的需求发布、团队招募，到中期的任务分配、进度管理，直到项目结束后的总结和成果展示，确保每个项目都能有序高效地推进。这样的系统化管理不仅能提升项目成功率，也能为学生的项目管理能力加分。

4. 个性化推荐算法

平台可以通过数据分析和机器学习算法，为学生个性化推荐最合适的项目和合作伙伴。例如，基于学生的专业背景、兴趣爱好、过往项目经验和合作偏好，平台可以更智能地匹配出符合他们需求的项目。这种智能推荐能大大提升合作效率，减少学生寻找合作伙伴和项目的时间。

5.跨专业沟通工具与协作优化

为了降低跨专业沟通的难度，平台可以提供专门的协作工具，例如多语言支持、自动生成任务清单的项目管理工具，甚至通过AI分析提供团队的沟通建议。这些工具能够大大优化不同学科学生之间的沟通协作，减少误解和沟通障碍。

6. 反馈与评估系统

平台可以设置反馈和评估机制，学生在合作完成后可以为合作伙伴进行匿名评价，类似于职业社交平台LinkedIn的推荐功能。这不仅能帮助学生了解自身在跨专业合作中的表现，也为未来的合作伙伴提供了更多参考信息。

这些优势不仅能帮助学生提高跨学科合作的成功率，还能为他们未来的职业发展打下坚实的基础。通过有效整合资源和技术，这个平台有机会成为学生跨专业合作领域的领先解决方案。

（四）、竞争分析 (C - Competition)

1. 现有替代方案

目前，学生在大学中想要跨专业合作，通常依赖以下几种方式：

• 人际网络：学生通过已有的社交网络或朋友介绍来寻找跨专业的合作伙伴。
• 导师介绍：向导师或专业相关的老师寻求帮助，请他们推荐合适的学生或合作对象。
• 社交媒体：部分学生通过校内qq群、表白墙发布求助信息，希望找到合适的合作伙伴。
• 校园社团和活动：一些大学有跨学科项目的社团或定期举办的创新创业活动，学生可以通过这些途径参与跨专业的合作。

这些替代方案的局限性主要体现在：

• 机会有限：依赖人际网络和老师推荐，无法覆盖到所有潜在的合作伙伴。
• 信息不对称：合作机会的发布和获取并不透明，导致很多学生错失机会。
• 沟通成本高：在社交平台和活动中，找到合适合作伙伴的过程费时费力，且不同专业间的沟通协作并不顺畅。

2.竞争优势

与现有替代方案相比，该平台的主要竞争优势在于：

• 系统化匹配：通过数据和算法，平台可以高效、精准地匹配合作伙伴，远超依赖人脉和社交平台的效率。
• 平台资源支持：提供项目管理、时间表协调等功能，降低跨专业合作的沟通和协作成本。
• 导师支持：平台不仅限于学生间的合作，还可以整合导师的资源，提供更广泛的指导和人脉网络。

总的来说，这个平台可以有效弥补现有方式的不足，在帮助学生找到跨学科合作伙伴、管理项目资源和促进沟通协作方面具有显著的竞争优势。如果能有效推广并提高用户参与度，它将极具市场潜力。

（五）、推广策略 (D - Delivery)

1、在学校互助群表白墙宣传

2、成立工作室、招收工作室成员，负责对软件的维护运营

3、小有成色后可继续扩大市场，开放源代码，吸引广大学校创建属于它们的校园生态圈

三、UML用例图🍼

四、流程图

五、效果演示🍼

设计页面

注册页面

四大模块

项目分配

聊天页面

个人资料与隐私设置

六、工作过程

建立原型设计的工作过程是一个系统而细致的过程，它涉及到多个阶段和步骤。

1、需求分析阶段

步骤一：明确项目目标和需求

①学生希望通过发起或参与跨专业的项目（创业、学术）来提升自己的综合能力，拓宽知识面和积累人脉

②对于一些需要多学科支持的项目（需要设计、编程和市场营销能力的创业项目），在偌大的校园中，学生们需要找到志同道合的合作伙伴，能够交流。

③不同专业之间的学生由于学校课程安排以及个人想法，可能在合作时间安排上、项目目标和沟通方式上可能存在差异，因此，学生需要能够合理安排各项成员和任务的时间表

④大多数学生缺乏平台或资源来支持跨专业项目的持续发展，因此，学生需要有为他们提供资源的平台

步骤二：梳理业务流程

项目构思与规划—>项目注册与发布—>寻找合作伙伴—>项目管理与协作—>项目评估与反馈—>成果展示与分享

步骤三：遇到的问题及队员讨论

①如何进行结对作业：经讨论，决定使用飞书共享知识库‌‬‍‌‌‌‌⁠‬‌‌‌‬‬‍⁠‍‌‌⁠⁠README.md - 飞书云文档 (feishu.cn)进行

②如何分工：问题分析—>飞书知识库协作—>需求分析—>流程图—>选择原型设计工具figma—>学习如何使用—>原型设计—>演示与调试

问题分析：

飞书知识库协作：非常方便，还提供UML的小人‌‬‍‌‌‌‌⁠‬‌‌‌‬‬‍⁠‍‌‌⁠⁠README.md - 飞书云文档 (feishu.cn)

需求分析：NABCD模型，在⁠‬‌‌‬‌‍⁠⁠‍⁠‍‍‍‬‬⁠‬‍‬需求分析 - 飞书云文档 (feishu.cn)上协作完成，详情见上（二）

流程图：A同学画B同学检查思路会更清晰

选择原型设计工具：figma,免费申请团队协作步骤见‌‬⁠⁠⁠⁠‍‍‌⁠‍‍‍‍‌‬⁠‬‍⁠‌⁠‬⁠UI - 飞书云文档 (feishu.cn)

学习使用figma：figma入门_哔哩哔哩_bilibili

原型设计：使用设计工具Figma绘制出各个页面。包含页面的基本布局、元素和交互逻辑。

​ 分模块进行，但需确保风格统 一CMYK到RGB转换| 颜色转换 (rapidtables.org)

​ 初代小曹设计的图标，队员不满意回炉重造:

演示与调试：软工第三次作业 (figma.com)

3、评审与反馈阶段

步骤一：将原型设计进行内部评审，查缺补漏。

步骤二：给我们的好朋友和亲友看，让他们给出建议

4、迭代与优化阶段

步骤一：得到反馈结果后，根据反馈对原型设计进行修改和优化

步骤二：在原型设计接近完成时，模拟用户使用场景以进行进一步优化

5、交付阶段

交作业给老师和助教们以验收原型设计是否满足需求然后不断迭代与优化

七、PSP表格🍼

PSP	预估耗时（单位:小时）	实际耗时
阅读《构建之法》	1	6
需求分析	1	5
构建原型模型	10	7
项目准备工作	0.5	3
调试和修改	1	0.5
测试	1	0.5
复盘与总结	0.5	1
维护	2	暂无

八、总结🍼

052205144张诗悦：

​ 这次作业真奇妙！翻开《构建之法》这本宝藏书，我们就像小魔法师一样，吸收了满满的魔法知识，感觉整个人都闪闪发光起来啦！
​ 首先，我们像超级侦探一样，先给自己来了个“能力大搜查”，看看自己有哪些小技能已经装备好啦，又想着通过这个项目能解锁哪些新技能。接着，我们拿起了NABCD模型的放大镜，仔仔细细地观察问题，就像寻找宝藏地图上的线索一样，搞清楚用户心里的小九九，还有我们该怎么变身成问题解决小能手。从功能到界面，从大框架到小细节，我们都遵循着“先抓大放小，再慢慢填满”的原则，让项目的小船稳稳向前航行。
​ 说到功能页面，我们就像是小小建筑师，先画了一个大大的蓝图——“项目与伙伴的梦幻推荐屋”、“项目发起的大舞台”、“合作伙伴的悄悄话角落”，还有“个人风采的小展厅”，这四个模块就像四颗闪闪发光的宝石，镶嵌在我们的软件模型上。然后，我们一点点地为它们添砖加瓦，确保每一步都走得既坚定又有趣，远离了那些让软件工程师头疼的“分析迷宫”、“优化急先锋”和“扩张小恶魔”的陷阱，让项目之路顺畅无阻。
​ 在软件风格的设计上，我们可是下了不少功夫呢！我们变身成时尚小达人，紧紧跟随软件小伙伴们的审美潮流，打造了一个既简约又不失个性的小天地。软件界面就像是穿着得体又不失活泼的小伙伴，让人一眼就能感受到它的实用与魅力。而且哦，我们还特意把软件的难度调得恰到好处，就像是踮起脚尖就能摘到的苹果，既让我们在挑战中成长，又收获了满满的成就感。
​ 最后的最后，真是一场酣畅淋漓的学习之旅啊!

072208130曹星才：

这次作业总的来说进展还是很顺利的，看了《构建之法》后学到了很多。先衡量自己的水平，已经掌握了哪些技能且完成该项目可以学习哪些技能，从大的方向入手，逐步做规划。先是用NABCD模型对问题进行分析，分析用户需要什么，以及我们该怎么解决这个问题，从功能到界面，从一个大的框架到细节处理，都是基于先解决主要问题再对方案进行拓展。如本次功能页面，先设计一个大的框架——“项目与伙伴推荐”、“项目发起”、“合作伙伴聊天”、“个人资料展示”的四个模块设计软件模型，再逐步细化，避免陷入软件工程师的“分析麻痹”、“过早优化”、“过早优化”和“过早扩大化”的误区，使得项目顺利进行。在软件风格设计方面，我们结合了软件的受益人群的审美，将软件风格极简化，但又不失美观，使软件主体倾向于功能的使用。我们软件的主体也没有设计得很复杂，考虑到两个人的综合能力，将软件的程序实现难度超出我们能力的一点点，这让我们实现的时候也有所收获。

总的来说，我们两个人的任务分工分的很好，计划进行得也很顺利，使得项目得以顺利进展。