软件工程第一次结对作业之需求分析和原型设计
| 这个作业属于哪个课程 | https://edu.cnblogs.com/campus/fzu/SE2024/ |
|---|---|
| 这个作业要求在哪里 | https://edu.cnblogs.com/campus/fzu/SE2024/homework/13261 |
| 这个作业的目标 | 结对共同完成跨专业信息化方案、学习使用原型软件设计，学会团队协作，加强对流程图、用例图的记忆与学习 |
| 学号 | 102202157 |
| 结对成员学号 | 102202156 |
| 原型设计链接 | https://app.uizard.io/prototypes/XO3yaqzPoXFnjWz8xnbd |
一、阅读《构建之法》第3章和第8章内容的学习成果
1.第3章：软件工程师的成长
1.软件工程师能力衡量与发展
- 个人流程：了解软件工程师在团队中的个人流程，包括从理解问题、需求到提出解决方案，与团队成员交流确定可行方案，执行方案并在测试环境中验证和修复缺陷，最终对结果负责等一系列环节。
能力衡量方法 - 成长维度：软件工程师的成长体现在积累软件开发知识、问题领域知识和经验，理解软件设计和软件工程思想，提升职业技能以及取得实际成果等多个方面。
- 工作量和质量衡量：软件开发工作量和质量可从项目大小（如代码行数或功能点）、花费时间、质量（如缺陷数量或 “re - work” 次数，但 “re - work” 与最终质量不成正比）以及是否按时交付等维度衡量。稳定、一致的交付时间是衡量员工能力的重要方面，工程师不能按时交付可能源于想解决通用问题而非满足当前需求。
- 团队期望：在团队环境中，工程师应具备交流、按时交付、接受并胜任团队角色、投入团队活动、遵循团队流程、做好准备以及理性工作等能力。
2.思维误区认知
认识到软件工程师常见的思维误区，如分析麻痹（过度关注细节和依赖关系导致无法开始工作）、不分主次（试图解决所有依赖问题而忽视 “足够好” 的方案）、过早优化（过度关注局部优化而忽略全局重要性）以及过早扩大化 / 泛化（过度追求软件的通用性而不考虑实际情况）。
3.职业发展规划 - 职业态度分级：了解软件工程师可能持有的不同职业态度，包括临时的寄托或工作（低动力、低技能）、工作（作为挣钱营生）、职业（有规划和道德）、投身的事业（长期承诺）以及理想的呼唤（追求改变世界）。
发展路径探索 - 考级：中国的软件工程师考级途径包括计算机等级考试和全国计算机技术与软件专业技术资格考试等，同时了解到这些考级的利弊，以及一些公司和行业协会提供的职业认证项目。
- 企业模式：不同企业或专家提出的职业发展模式，如 Steve McConnell 版本的知识领域和能力阶段划分，微软公司的软件工程师职业等级设定，以及工程师自我评估时需结合行业特点考虑在不同方面追求的专业程度。
4.技能本质反思
理解技能的反面是 “Problem Solving”，通过面试和魔方技能的例子，明白不断练习解决低层次问题，才能进阶到解决更高层次问题，以及技能的不同层次划分与教育理论中的舒适区、学习区、恐慌区的关联。
第8章：需求分析
- 软件需求的全面剖析
- 需求获取与管理的流程
从获取和引导需求入手，强调软件团队要从多方面挖掘需求，包括利益相关者（用户、顾客、市场分析者等多类角色）的需求，以及来自商业模式、技术团队自身等不同源头的需求。
接着是分析和定义需求，对获取的需求进行规整和量化，考虑实现期限、成本、优先级和收益等要素。
验证需求环节通过与利益相关者的多种形式沟通来确保对需求的准确理解。
强调在软件生命周期中持续管理需求，因为需求会随技术发展、团队能力提升等因素而改变。 - 需求类型的多维划分
明确了对产品功能性的需求、对产品开发过程的需求、非功能性需求（服务质量需求）以及综合需求等不同类型，强调软件团队和客户代表需在需求阶段清晰定义这些需求。
- 用户调研方法的深入探讨
- 多种调研方法介绍
焦点小组：组织相关人员讨论，但存在受多种因素影响导致结果可能不准确的问题。
深入面谈：一对一深入了解用户，但效果取决于采访者能力，可用于软件可用性研究。
卡片分类：有助于统一需求认识和定义软件架构等。
用户调查问卷：设计有讲究，要避免常见错误，问题形式多样。
用户日志研究：要求用户记录行为，需注意隐私保护和用户自律。
人类学调查：通过和用户 “同吃同住同劳动” 了解需求。
眼动跟踪研究：研究用户浏览规律以优化信息展示。
快速原型调研：快速获取用户反馈。
A/B 测试：对产品不同设计进行测试，但有运行成本等弱点。 - 方法的综合比较与反思
介绍了这些方法在态度和定量上的分野，提醒过度依赖数据可能带来问题，如 Google 视觉设计主管的案例。
- 竞争性需求分析的关键框架
- 创新导向的需求分析思路
区分改良型和颠覆型创新，批判 “二拍” 式的错误需求分析做法，强调实用且创新的项目需求分析。
详细阐述 NABCD 模型，包括需求（N）、做法（A）、好处（B）、竞争（C）和推广（D）各个环节的要点和作用。 - 竞争产品的比较分析
通过与竞争对手比较，明确我方产品在满足用户需求方面的优势和劣势，为产品定位提供依据。
- 功能定位与优先级的策略
- 功能分类与核心价值判断
根据功能特点划分为杀手功能 / 外围功能、必要需求 / 辅助需求四个象限，以英汉词典软件为例说明不同象限功能的特点和地位。
强调资源应倾斜到能产生差异化和独特用户价值的地方，针对不同象限功能提出维持、抵消、优化、差异化和不做等处理策略。 - 功能与用户满意度的动态关系
探讨不同类型功能（核心需求相关、卫生属性、让用户惊喜）与用户满意度的关系，以及这些功能类型随时间推移的变化，如手机多点触摸功能的演变。
- 计划和估计的重要方法与技巧
- 目标、估计和决心的概念区分
通过软件项目计划中对时间估计的重要性，清晰区分目标、估计和决心，以历史上 “大跃进” 为例说明混淆三者的危害，阐述软件项目估计困难的原因。 - 提高估计能力的实用方法
介绍通过 Wideband Delphi 方法找出估计背后假设的步骤，以及参考前人经验和采用快速原型法提高估计能力的思路。
提及软件工程师的经验公式，介绍影响软件成本的多种因素（产品、平台、人员、项目等方面）。 - 不同估计方法的灵活运用
包括自底向上、回溯等常规方法，以及敏捷开发中的估计扑克牌、划拳估计法、T 恤尺寸法等快速粗粒度估计方法，强调敏捷开发中应根据实际情况调整进度，“猜得准” 不是首要目标。
- 分而治之（WBS）的项目分解方法
介绍 WBS 方法的核心要点，即从最终产品开始逐步分解项目为可操作的工作，明确做好 WBS 的关键要点，如子节点覆盖、不相互覆盖、叶子节点合适以及从结果出发构建等。
解答关于 WBS 的常见问题，如文档和工作计划的处理、开发活动的计入以及细枝末节的处理方式等。
NABCD模型
NABCD 模型是一个用于分析需求和说服别人创新想法可行性的有效方法
- N（Need，需求）
创意要解决用户的需求，这个需求可能是明确的，也可能是潜在的。了解用户需求可通过假设用户需求已被满足，查看用户反馈和不满，以及找到 “不消费的用户”，了解他们不使用相关 App 的原因等方式。同时要充分了解用户的痛苦和对现有软件、服务的不满意之处，注意用户可能不了解颠覆型创新，开发者也不应局限于某种产品形式。 - A（Approach，做法）
找到需求后，要有独特的招数来解决用户的痛苦。这些招数不仅包括技术方面，还可以是商业模式、地域、人脉、行业或成本等方面的优势。 - B（Benefit，好处）
独特的做法要能给客户 / 用户带来好处。当用户已有解决方案时，要考虑新产品的优势能否让用户愿意迁移，包括考虑用户迁移成本，如对硬件、网络等方面的要求。 - C（Competitors，竞争）
要了解市场竞争情况，包括竞争对手的先发优势或后发优势。通过分析与竞争对手在满足用户需求方面的差异，明确我方优势和劣势。 - D（Delivery，推广）
要考虑如何把创新产品交到用户手中，即产品的推广方式。可以通过做广告、公关活动、鼓励有影响力的用户介绍、设计高质量的功能让用户口口相传等手段，还可以在产品本身设计相关功能，如把用户生活中的好友拉进产品或在交流中自然宣传产品。 - NABCD 模型优点
全面系统：涵盖从需求到推广各环节，逻辑清晰，引导团队全面、系统思考产品，确保各环节不遗漏，提高产品成功率。
用户导向：以用户需求为核心，强调产品对用户的价值，提升用户满意度和市场接受度。
竞争意识：促使团队分析竞争环境，制定针对性策略，适应市场变化。 - NABCD 模型缺点
应用复杂：信息收集难，分析繁琐，对团队知识经验要求高。
主观影响：需求和竞争分析易受主观判断左右，导致偏差。
动态不足：是静态框架，难以及时反映市场动态变化。
方案设计
二、界面原型设计
1.原型设计演示图
| 原型设计工具 | uizard |
|---|---|
| 原型链接 | https://app.uizard.io/prototypes/XO3yaqzPoXFnjWz8xnbd |
2.流程图
3.用例图
三、主要界面及功能显示
1.注册页面
2.登陆页面
3.功能页面显示
四、信息化设计方案
需求分析
- 获取和引导需求
利益相关者：有跨专业合作需求的学生、不同专业的老师（可能作为介绍人或资源提供者）。
需求挖掘：学生需要一个平台来寻找跨专业合作伙伴，解决合作机会有限的问题；需要一种方式来协调不同专业学生在时间安排、项目目标和沟通方式上的差异；需要资源支持跨专业项目的持续发展。 - 分析和定义需求
需求内涵：开发一个跨专业项目合作平台，具有项目发布与搜索功能，方便学生找到合适的合作伙伴；提供项目管理工具，用于协调时间、目标和沟通；整合校园资源，为项目提供支持。
量化需求
实现期限：可根据开发难度和资源情况设定合理期限
成本：考虑开发成本、服务器维护成本等，可进行成本估算。
优先级：项目发布与搜索功能优先级较高，其次是项目管理工具，最后是资源整合。
收益：提高学生跨专业合作的机会和效率，促进学生综合能力提升，对学校的学术和创业氛围有积极影响。 - 验证需求
通过与学生代表、老师进行访谈或问卷调查，了解他们对平台功能的期望和建议，验证需求的合理性和可行性。
设计与实现
功能设计
- 核心功能
用户注册与登录：支持学生和老师注册登录，区分不同角色权限。
项目发布与搜索：学生可以发布项目需求，包括项目名称、简介、所需专业技能、时间安排等信息；其他学生可以根据关键词搜索项目。
合作伙伴匹配：根据项目需求和学生个人资料，自动匹配可能的合作伙伴，并提供推荐列表。
项目管理：提供项目时间管理、目标设定、任务分配、沟通工具（如论坛、即时通讯）等功能。
资源整合：整合学校的实验室资源、学术资料、创业基金等信息，供项目团队申请和使用。
界面设计：设计简洁、易用的界面，符合学生和老师的使用习惯。 - 测试与发布
测试计划
制定详细的测试计划，包括单元测试、集成测试、系统测试和用户体验测试。
对各个功能模块进行测试，确保功能的正确性和稳定性。
发布与推广
选择合适的时间发布平台，如在新学期开始或学校举办创业活动期间。
通过学校官方网站、学生会宣传、老师推荐等方式进行推广。 - 运营与维护
用户支持
设立用户反馈渠道，及时处理用户在使用过程中遇到的问题。
平台更新
根据用户反馈和需求变化，定期对平台进行更新和优化。
数据管理
对用户数据、项目数据和资源数据进行安全管理和备份。
五、PSP表格
| PSP 阶段 | 具体任务 | 时间估计（小时） | 实际时间（小时） |
|---|---|---|---|
| 计划 | 确定学习《构建之法》相关章节的目标和计划 | 1 | 1 |
| 需求分析 | 分析软件工程师成长和需求分析相关内容 | 3 | 3.5 |
| 设计 | 构思界面原型设计方案 | 2 | 2.5 |
| 开发 | 创建界面原型、流程图和用例图 | 4 | 4.5 |
| 测试 | 检查界面原型和功能设计的合理性 | 2 | 2 |
| 报告 | 撰写学习成果总结 | 2 | 2 |
六、交流过程
七、总结
- 一、作业的意义
本次作业的意义在于针对大学校园内跨专业合作的实际难题，设计并构想了一套信息化解决方案。通过构建一个集项目发布、团队组建、协作沟通、资源共享于一体的平台（可以是软件、APP或小程序），我们旨在打破传统合作模式的局限，为有志于跨专业合作的学生提供一个高效、便捷、安全且隐私保护的合作环境。这不仅有助于提升学生的综合能力，拓宽知识面，还能有效促进不同专业之间的交流与融合，推动校园内创新项目的孵化与发展。 - 二、在本次结对完成作业中我的收获
知识掌握与深化：在作业过程中，我深入学习了软件设计、用户体验、数据安全等方面的知识，特别是关于如何设计一款既实用又符合用户需求的产品。同时，我也对跨专业合作的重要性和挑战有了更深刻的理解。
团队协作能力提升：与搭档紧密合作，共同完成了从需求分析、方案设计到原型制作的全过程。这个过程中，我们学会了如何有效沟通、分工协作以及相互支持，这对于我未来的学习和工作都将产生积极影响。
创新思维激发：在解决具体问题的过程中，我们不断尝试新的思路和方法，努力使设计方案更加完善。这种创新思维的培养对于我个人的成长具有重要意义。 - 三、掌握的知识
软件设计原则：掌握了用户中心设计、简洁性、一致性等基本原则，确保设计出的产品既美观又实用。
用户体验优化：学习了如何通过用户调研、原型测试等方法来优化产品体验，提高用户满意度。
数据安全与隐私保护：了解了数据加密、访问控制等安全措施的重要性，并学会了如何在设计中融入这些元素以保护用户隐私。 - 四、自己的不足
在作业完成过程中，我也发现了自己的一些不足之处。例如，在需求分析和方案设计阶段，我有时过于关注细节而忽略了整体架构的合理性；在团队协作中，我有时过于坚持己见而未能充分听取搭档的意见。为了克服这些不足，我计划在未来的学习和工作中更加注重全局思维的培养和团队沟通能力的提升。 - 五、团队的配合重要性
本次结对完成作业的经历让我深刻认识到团队合作的重要性。一个优秀的团队能够集思广益、优势互补，共同面对挑战并找到最佳解决方案。在作业过程中，我们互相学习、互相帮助，共同克服了一个又一个难题。这种紧密的合作不仅提高了我们的工作效率，也增强了我们的团队凝聚力。因此，在未来的学习和工作中，我将更加注重与团队成员的沟通和协作，努力成为一个更加优秀的团队成员。
