| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 需求分析和原型设计 |
| 学号 | 102202112 |
| 结对成员学号 | 102202145 |
| 原型链接 | 墨刀链接 |
一、《构建之法》阅读成果 📚
第3章 软件工程师的成长 🚀
软件工程包括了开发、运营、维护软件的过程中的很多技术、做法、习惯和思想。把这些相关的技术和过程统一到一个体系中就叫“软件开发流程”，其目的是为了提高软件开发、运营、维护的效率，以及提升用户满意度、软件的可靠性和可维护性。
3.1 个人能力的衡量与发展 🛠️
（一）个人开发流程
- 软件开发流程包含团队和个人的流程。
- 个人在团队中有独立的开发、测试、设计、管理等任务。
（二）Individual Contributor (IC)
- IC（Individual Contributor）指团队中的单个开发或维护软件模块的成员。
IC在团队中的流程
- 理解问题、需求或任务（通过交流、实验等）。
- 提出解决方案并估计工作量。
- 寻找重复性解决方案。
- 与相关角色交流并选择方案。
- 执行方案并验证其可行性。
- 合作测试与修复缺陷。
- 负责解决方案发布后的结果。
（三）初级工程师如何成长 🌱
- 技术技能：掌握编程语言（如Java、C/C++）、设备驱动、调试器等技术。
- 问题领域知识：积累行业经验（游戏、医疗、金融等领域）。
- 设计思想与软件工程思想：理解什么是好的设计和工程思想。
- 职业技能：包括自我管理、沟通、合作能力等。
- 实际成果：通过产品用户评价、市场占有率等来衡量贡献。
（四）软件开发的工作量和质量衡量 ⚖️
- 项目大小：通常用代码行数（LOC）或功能点表示。
- 时间投入：用人力×时间表示（如10人×月）。
- 质量衡量：通过缺陷数量/KLOC或返工次数（re-work）来衡量。
- 按时交付：按项目计划如期完成交付。
（五）团队对个人的期望 🤝
- 交流：能有效沟通，从技术方向到细节问题。
- 说到做到：按时交付任务。
- 接受团队角色：接受并高质量完成团队赋予的任务。
- 全力参与：全身心投入团队活动，如代码评审会议。
- 按团队流程工作：即使能力强，也应遵守团队流程。
- 准备工作：做好会议、项目或功能开发的准备。
- 理性工作：以事实和数据为依据，避免感情驱动。
3.2 软件工程师的思维误区 🤔
- 分析麻痹：过度分析导致行动滞后。
- 不分主次：试图解决所有依赖问题。
- 过早优化：在问题尚未明朗时优化代码。
- 过早泛化：未明确需求时过度泛化解决方案。
3.3 软件工程师的职业发展 📈
（一）对职业的态度
- 临时的寄托或工作
- 工作
- 职业
- 投身的事业
- 理想的呼唤
（二）职业发展
- 考级之路：通过职业资格考试，如微软认证专家（MCP）、Oracle认证项目（OCP）等。
- Steve McConnell版本：将工程师的能力量化为12个等级，评判标准则是一个工程师对软件知识的掌握程度——入门、熟练、带头人、大师。
- 大公司版本
- 自我评估：不断学习和成长，选择在哪个方面追求“专和精”，在哪几个方面达到“知道就好”的水平。
3.4 技能的反面（问题的三个层次） 🕵️♂️
3.5 总结 🔍
- 工程师应在专精领域持续学习与成长，选择性深入或略懂某些技能。
- 通过不断练习将低层次问题自动化处理，腾出时间解决更复杂问题。
- 迭代与增量式开发能够提高开发效率并减少项目风险。
第8章 需求分析 📝
8.1 软件需求
（一）全面找到需求的步骤
- 获取和引导需求
- 分析和定义需求
- 验证需求
- 在软件产品的生命周期中管理需求
（二）软件需求的类型的划分
- 对产品功能性的需求：要求产品必须实现某些功能。
- 对产品开发过程的需求：要求软件的开发流程必须满足某些约束条件。
- 非功能性需求：这类需求关注软件的质量属性，如性能、可用性、可靠性、安全性等。
- 综合需求：可能牵涉到其他系统的需求。
8.2 软件产品的利益相关者 🧑🤝🧑
- 用户: 或称最终用户(User, End-user)，是直接使用软件系统的人。
- 顾客: 或称客户(Customer, Client)，购买这个软件或者根据合同或规定接收软件的人。
- 市场分析者：代表“典型用户”的需求，他们或者是市场部门的成员，或者是独立的市场分析人士。
- 监管机构：在一些行业，软件必须符合许多行业和政策规定（如银行、公共交通、通信、矿产资源等）。
- 系统/应用集成商：系统/应用集成商负责给客户提供咨询、服务等工作。
- 软件团队：具体完成某一个特定软件或特定功能的团队。
- 软件工程师：工程师也是软件需求阶段的一个重要角色。
8.3 获取用户需求—用户调研 🔍
- 软件开发的过程，就是“用户最需要的东西”在下面这一链条中传送、转换、实现、扭曲或丢失的过程。
2. 常用的用户调研方法
- 焦点小组：组织一群用户的代表和利益相关者进行讨论，收集他们的意见和建议。
- 深入面谈：与用户进行一对一的交流，通过用户完成任务的过程观察其潜在需求。
- 卡片分类：将需求写成小卡片，通过讨论、明确定义、归类和排序来整理需求。
- 用户调查问卷：设计问卷向用户收集意见和反馈，但需注意问题的明确性、避免引导性倾向等问题。
- 用户日志研究：要求用户记录自己使用软件的行为，以供分析。
- 人类学调查：与目标用户“同吃同住同劳动”，深入了解其使用场景和需求。
- 眼动跟踪研究：利用眼动追踪设备研究用户浏览网页时的视觉行为，以优化用户体验。
- 快速原型调研：构建软件的原型版本，让用户使用并收集反馈。
- A/B测试：同时测试两种不同的UI或功能，通过用户反馈和数据分析来决定最优方案。
3. 各种方法的分类
8.4 竞争性需求分析的框架 ⚔️
NABCD模型是一个系统化的框架，旨在帮助团队更好地构建和评估项目。
- 需求（Need）：识别并探究用户尚未得到充分满足或需要进一步优化的需求点。
- 方法（Approach）：设计并实施一种创新的解决方案或采用先进的技术手段来应对这些需求。
- 好处（Benefit）：评估新提出的解决方案或技术对用户的具体益处。
- 竞争（Competitors）：分析当前市场上的竞争格局，包括对手的数量、市场份额以及他们的产品特性。
- 推广（Delivery）：策划并执行一套有效的市场推广计划，确保新产品或服务能够成功地传递给目标用户群体。
8.5 功能的定位和优先级 🔝
1. 功能分析的4个象限
- 杀手功能：OCR文字识别技术，可以在屏幕上取词解释，拥有独家权威词典，等等。
- 外围功能：良好的界面设计，在各个平台上都能运行。
- 必要需求：单词短语释义的准确性（如果达不到这一点，用户就不会来使用）。
- 辅助需求：可以做各种皮肤（这也许能让一些用户更喜欢这个软件，但不是决定因素）。
2. 对四个象限的不同建议
- 维持—以最低成本维持此功能。
- 抵消—用更有吸引力的功能去替代。
- 切换—选择最有潜力的功能继续开发，其他的放弃。
- 激励—将此功能提升到更高的优先级。
3.各种不同投资的不同效果
8.6 总结 📋
- 需求分析是软件工程中的一个重要步骤，它帮助开发人员确定软件的功能需求和用户期望。
- 需求调研方法多样，应该选择适合项目类型和用户特征的方法进行分析。
- 需求评估与优先级确定有助于开发人员聚焦核心功能，避免资源浪费。
二、原型设计
（一）原型开发工具选择：墨刀
（二）CoLab平台的NABCD模型 🚀
Need（需求）🔍
- 学生们需要一个跨专业合作的平台，以便找到志同道合的伙伴。
- 需要项目管理和资源分享的工具，简化合作流程。
- 学校希望促进不同学科间的交流，提升学生的综合能力。
Approach（方法）🛠️
- CoLab提供在线协作环境，通过“发起项目”功能促进跨专业合作。
- “导师大赏”和“技能桥梁”帮助学生发现并联系不同专业的导师和技能人才。
- “社区”功能鼓励经验分享和讨论，推动跨学科交流。
- “个人资料”和“我的项目”帮助学生管理项目和个人信息。
Benefit（好处）✨
- 学生们可以轻松找到合作机会，不再受限于个人人脉和专业限制。
- 项目管理工具和协作邀请功能提高团队协作效率。
- 平台帮助学生拓宽知识面，积累人脉，提升综合能力。
- 导师的参与为项目提供指导和监督，增加成功率。
Competitors（竞争）🏆
- 分析现有的在线协作工具如GitHub、Slack等，它们可能在某些功能上有所欠缺。
- 校园内部的非正式合作网络或小组，可能在特定领域内有影响力。
- 通过对比这些竞争者在功能、用户界面、社区支持和专业匹配方面的优劣，确定CoLab的独特卖点。
Delivery（推广）📣
- 与大学合作，通过校园活动和学术会议推广CoLab平台。
- 利用社交媒体和在线广告针对学生群体进行宣传，强调平台特色和好处。
- 提供免费试用期和入门指导，降低尝试门槛。
- 通过成功案例和用户推荐来增强平台的可信度和吸引力。
（三）CoLab平台用户操作流程与流程图展示
1. 登录和角色选择
- 首先，你需要登录CoLab平台。登录后，根据你的角色（导师或学生），你将进入不同的界面。 🔑✨
2. 首页功能
- 切换页面: 你可以在不同的页面间切换，比如社区、协作邀请、个人资料等。 📄
- 社区: 在这里，你可以浏览导师大赏，了解不同导师的详情，或者通过技能桥梁发起私聊。 💬
- 协作邀请: 可以发起新的项目，邀请他人加入你的学习或教学项目。 🤝
- 个人: 管理你的个人资料、查看消息中心、管理你的项目以及进行反馈或设置。 🛠
3. 项目探索
- 推荐项目: 平台可能会根据你的兴趣和历史行为推荐相关项目。 🔍
- 搜索框: 你可以使用搜索功能来寻找特定的项目或关键词。 🔑
- 项目详情: 查看项目的具体信息，了解项目分类、导师信息和相关文件。 📚
4. 流程图展示
（四）各个主要界面的原型图
1.首页->账号登录->项目介绍
2.技能桥梁（学生技能分享）->开启聊天
3.导师大赏->导师详情（导师研究方向分享）
4.搜索界面->搜索结果
5.团队搭建->发起项目/协作邀请->项目分享
6.个人->个人资料->个人技能树->我的项目
7.个人->设置->系统消息及私信->反馈与建议
（五）交互逻辑和功能展示
<一个小的用户介绍>🌟
欢迎来到Colab小程序，一个专为知识分享、团队协作和个人成长打造的平台。我们通过四个核心页面的动态展示，为您呈现一个充满活力和互动性的体验。让我们一起探索这些页面的精彩动图吧！
1.首页动图：
动图展示：首页动图以简洁明快的动画呈现Colab的核心价值和欢迎信息，营造出一种温馨且专业的第一印象。✨
2.社区动图：
动图展示：社区页面的动图通过展示浏览导师大赏、查看导师详情以及通过技能桥梁发起私聊的场景，传达出一个充满活力和创意的交流空间。💬
3.团队搭建动图：
动图展示：团队搭建页面的动图通过模拟发起新项目、邀请他人加入学习或教学项目的场景，展示了如何在Colab中轻松组建和管理团队。🤝
4.个人动图：
动图展示：个人页面的动图通过展示管理个人资料、查看消息中心、管理项目以及进行反馈或设置的动画，突出了用户在Colab中的个性化体验。🛠️
Colab小程序旨在通过直观的设计和动态的视觉效果，为您提供一个既高效又愉悦的协作环境。立即体验这些页面的动图，感受Colab带来的无限可能！🎉
三、😊 遇到的困难以及解决方法
1. 工具操作不熟悉
困难：初次使用墨刀时，可能不熟悉其操作界面和设计工具的具体功能，导致效率低下，设计过程受阻。
解决办法：
- 查看墨刀的官方教程或使用在线资源进行学习，快速掌握基础操作。
- 从简单的界面设计开始，逐步熟悉各项功能，避免一开始就设计复杂的界面。
- 多利用墨刀的模板和组件库，减少从头开始设计的负担。
2. 设计思路不清晰
困难：在设计小程序Colab界面时，可能会对整个设计流程缺乏清晰的思路，尤其是在用户体验（UX）和界面布局（UI）上难以掌控。
解决办法：
- 借助《构建之法》中提到的NABCD模型，明确需求分析，围绕用户需求展开设计。
- 分析类似的小程序界面，参考其布局和功能设计，找到适合自己项目的设计灵感。
- 和团队成员多沟通，明确目标用户的需求，并根据用户的反馈调整设计。
3. 团队协作问题
困难：由于墨刀的团队协作功能不如Google Docs等平台方便，可能在多人协作时出现同步问题，或者无法清楚地分工。
解决办法：
- 将墨刀的设计项目共享给团队成员，分工明确，指定每个人负责不同模块的设计，避免多人修改同一部分。
- 利用墨刀的注释功能，在设计图中直接添加备注和讨论点，方便团队成员理解每个部分的设计思路。
- 定期同步项目进度，结合其他实时协作工具，如微信或Slack，确保团队沟通顺畅。
4. 原型细节和逻辑不完整
困难：在设计过程中可能忽略了一些交互逻辑和功能细节，导致最终的原型图不够完整，难以展示清晰的使用流程。
解决办法：
- 在墨刀中充分利用交互功能，将按钮点击、页面跳转等逻辑展示出来，确保设计流程完整。
- 在设计之前先画出整个系统的流程图，明确每个功能的交互路径，再在墨刀中进行详细的界面设计。
- 定期回顾原型设计，从用户角度进行测试和体验，及时发现设计中的不足并进行调整。
四、PSP表格及效能总结
| 任务名称 | 预估耗时 (小时) | 实际耗时 (小时) | 备注 |
|---|---|---|---|
| 阅读《构建之法》第3章 | 1 | 1.5 | 理解需求分析和原型设计 |
| 阅读《构建之法》第8章 | 1 | 1.5 | 理解NABCD模型 |
| 讨论客户需求 | 1.5 | 2 | 讨论了用户角色和功能 |
| 设计原型功能 | 2 | 3 | 确定主要功能和流程 |
| 制作原型图 | 5 | 8 | 使用墨刀完成原型图 |
| 撰写博文草稿 | 1 | 3 | 草稿完成 |
| 修改与完善博文 | 1 | 1.5 | 根据反馈进行修改 |
| 整理结对工作记录 | 1 | 1.5 | 收集讨论和构建过程照片 |
| 最终检查与提交 | 0.5 | 1 | 确保格式与内容完整 |
效能分析报告 📝
1. 阅读《构建之法》第3章 📖
- 预估耗时: 1小时
- 实际耗时: 1.5小时
- 原因分析:
- 在阅读过程中，遇到了一些新的概念和技术，导致理解的时间延长。
- 章节内容涉及多个复杂的主题，尤其是需求分析和原型设计的部分。
- 思考:
- 下次在预估耗时时，考虑将新概念的学习时间纳入评估，以提高准确性。
- 可以制定更详细的阅读计划，将复杂内容拆分，以便逐步深入理解。
2. 阅读《构建之法》第8章 📚
- 预估耗时: 1小时
- 实际耗时: 1.5小时
- 原因分析:
- 对NABCD模型的理解需要多次思考与反复阅读，以确保对各个要素的清晰理解。
- 思考:
- 可以在阅读时做笔记，帮助巩固记忆和理解，提高后续应用的效率。
- 未来可以利用相关的视频资料或案例来辅助学习，加深理解。
3. 讨论客户需求 💬
- 预估耗时: 1.5小时
- 实际耗时: 2小时
- 原因分析:
- 讨论中涉及多方利益相关者的意见，导致需要更多时间来协调和分析不同观点。
- 用户角色和功能的定义较为复杂，需要多次确认和修正。
- 思考:
- 可以提前准备讨论提纲，确保讨论更加高效，集中在关键问题上。
- 考虑设置讨论时间的限制，以促进更快的决策。
4. 设计原型功能 🎨
- 预估耗时: 2小时
- 实际耗时: 3小时
- 原因分析:
- 主要功能的确定过程中，涉及到较多的迭代和反馈，导致时间延长。
- 对于功能的设计和流程的厘清需要更多的讨论与调整。
- 思考:
- 在设计之前，可以进行更充分的需求调研，以减少设计阶段的反复修改。
- 尝试使用可视化工具帮助理清思路，提高设计效率。
5. 制作原型图 🖼️
- 预估耗时: 5小时
- 实际耗时: 8小时
- 原因分析:
- 制作原型图时，发现原先的设计无法完全满足用户需求，进行了多次修改。
- 使用工具的学习曲线也导致了耗时增加。
- 思考:
- 在制作前，可以进行小规模的用户测试，收集反馈，减少后期的修改。
- 提前进行工具的熟悉和培训，以提高制作效率。
6. 撰写博文草稿 ✍️
- 预估耗时: 1小时
- 实际耗时: 3小时
- 原因分析:
- 在撰写过程中，内容需要多次调整和补充，导致时间超出。
- 对于文字表达的准确性和逻辑性较为关注，反复推敲耗时。
- 思考:
- 可以制定一个更清晰的草稿大纲，以提高写作效率。
- 未来可以设定初稿与最终稿的不同时间预估，合理分配时间。
7. 修改与完善博文 📝
- 预估耗时: 1小时
- 实际耗时: 1.5小时
- 原因分析:
- 修改反馈过程中，遇到了一些新的建议和意见，需要更多的时间进行调整。
- 思考:
- 收集反馈时，可以提前明确期望的反馈内容，减少修改的次数。
- 尝试设定时间限制，以提高修改效率。
8. 整理结对工作记录 📂
- 预估耗时: 1小时
- 实际耗时: 1.5小时
- 原因分析:
- 收集讨论和构建过程的照片时，发现缺少部分必要记录，导致时间增加。
- 思考:
- 建议在每次会议后及时记录关键要点和结果，以便于后期整理。
- 未来可考虑使用共享文档实时更新记录。
9. 最终检查与提交 ✔️
- 预估耗时: 0.5小时
- 实际耗时: 1小时
- 原因分析:
- 最终检查时，注意到了一些小细节，导致检查时间延长。
- 思考:
- 可以在提交之前，进行小组内部的预审，以提高最终提交的质量和效率。
- 设定更明确的检查清单，以便于高效完成检查工作。
总结 🏁
整体来看，任务的实际耗时普遍高于预估，这反映出在需求理解、讨论协调、设计迭代等方面存在提升空间。通过加强前期准备、明确讨论重点、优化任务分解与时间管理，可以有效提升整体工作效率。未来的项目中，应更加注重时间预估的准确性，并不断调整工作方法以适应实际情况。
五、结对工作记录🍵
（一）讨论过程记录😯
在项目开始之前，我们首先确定了目标和大致的分工，并讨论了项目的预期结果和可能遇到的挑战。随着讨论的深入，我们开始细化任务和分配责任，并使用了思维导图和流程图来梳理项目的结构和关键点。在明确了各自的任务后，我们开始动手构建原型，使用墨刀逐步完善了原型界面的设计。项目完成后，我们回顾了整个过程，讨论了哪些地方做得好，哪些地方可以改进，对整个项目进行了总结和分析，为下次结对作业做准备。
（二）使用工具构建原型时的照片🍷
六、项目总结 📝✨
我的总结 😊
在这次原型设计小程序Colab的项目中，我深刻体会到了团队合作的重要性。我们从最初的需求分析开始，逐步明确了项目的目标和用户需求。在使用墨刀进行原型设计时，我面临了一些挑战，尤其是在工具的操作和界面设计思路的把握上。但通过查阅教程和与谢含的沟通，我逐渐熟悉了工具并清晰了设计思路。
在设计过程中，我负责了用户注册和登录模块的设计。我利用墨刀的注释功能，与团队保持了良好的沟通，确保了每个功能的设计方向都符合用户需求。同时，我们也定期回顾项目进度，确保设计的细节和交互逻辑完整。最终，我们的原型图得以顺利完成，并在反馈中得到了积极的评价。
通过这个项目，我不仅提高了自己的设计技能，还增强了团队协作能力。期待在下一个项目中能继续与谢含合作，创造出更好的成果。 🌟
她的总结 😄
在这次与刘莹共同完成的Colab小程序原型设计项目中，我感受到了协作的力量和设计的乐趣。从需求分析阶段开始，我们便紧密合作，利用NABCD模型明确用户需求，并制定设计方案。
在墨刀的使用上，我起初也遇到了一些困难，但通过团队的共同努力，我们相互支持和分享资源，使我们都能快速上手。我的主要任务是设计小程序的主界面及功能模块。在这个过程中，我学习到了如何有效运用墨刀的功能，特别是在交互逻辑的设计上，我通过不断的迭代和反馈，提升了原型的完整性和可用性。
我们在项目中经常进行沟通，确保设计方向一致，同时也会在墨刀上留下备注和讨论点，帮助彼此理解设计意图。经过多次调整和优化，最终的原型图清晰展示了小程序的使用流程，得到了老师的认可。
总结这次项目，我不仅提升了自己的设计能力，还加强了与他人的协作和沟通技巧。我期待将这些经验应用到未来的项目中，继续与刘莹一起探索新的创意。 🚀
