典型用户和团队开发相关问题_用例图中的典型用户-CSDN博客

本文链接：https://blog.csdn.net/Areyoustudying/article/details/136980208

1 典型用户分析

用户模板

名字：李华
年龄和收入：20岁，大学生，无固定收入，主要依靠父母提供的生活费。
市场比例和重要性：约占潜在电影观众的30%。他们年轻，对电影充满热情，尽管付费用户比例可能不高，但因其为票房增长贡献显著，所以非常重要。
典型使用场景：李华在空闲时间或周末，经常和室友或同学一起，通过手机或电脑查询最新电影信息并在线预订票。
使用环境：一般在学校宿舍、图书馆或校园咖啡馆使用电影院售票系统。
生活/工作情况：他是一名学业繁重的大学生，但拥有相对充裕的课余时间。他喜欢社交与娱乐，观看电影是与朋友共度时光的常见活动。
知识层次和能力：李华有着基本的计算机与互联网操作能力，可以轻松使用各类手机应用和网站进行在线购票，但由于忙碌的学业，更喜欢简便易操作的系统。
动机、目的和困难：使用售票系统是为了能与朋友方便地预订电影票，享受集体看片的乐趣。目标是获得好座位与价格优惠。可能面临的困难包括系统操作界面不友好、选择座位受限或付款流程复杂。
用户偏好：更喜欢界面友好、操作简洁的售票系统。倾向于选择评分高、内容新颖的电影，并重视座位选择和价格。由于常与朋友共同观影，他希望系统支持团体购票，并且十分关心系统的稳定性和安全性以确保顺利购票。

2 电影院售票系统优化方案

典型场景下的客户分析

场景：选择座位并订票
客户概述：李同学，一名高校学生，热爱观看电影，频繁使用电影院售票系统预订电影票。
使用工具：通过手机应用选择座位并进行订票操作。
任务：在售票系统中选择座位并完成订票。
任务频率：每月至少2-3次。
任务细节：使用售票系统应用，查看座位图，选择座位并支付订单。

客户动机与问题

动机：为了和朋友一起获得舒适的观影体验。
问题：面对热门场次和黄金时段，常常面临心仪座位被抢占的状况，导致满意度下降。
现行解决方法：尽可能在放映时间较早的场次选择座位。
改变愿望：希望系统能够提供更多的座位选择，特别是在高需求时段。

提高满意度和效率的改进措施

优化座位选择机制：
- 引入多种座位类型如情侣座、豪华座等。
- 热门场次和高峰时段可提前开放座位预订，增加选择机会。
提供实时座位更新和提示：
- 座位图实时更新，以确保用户获取最新信息。
- 若选定座位被占，则系统立刻通知用户并推荐其他座位。
增加客户反馈渠道：
- 设置反馈系统，允许用户提出在预订及支付过程中的问题和建议。
- 根据用户反馈不断调整功能和改善用户体验。

通过实施这些措施，电影院售票系统可以为用户提供一个更加人性化、透明和便捷的订票环境，显著提高用户的使用满意度和提升产品的市场竞争力。

3 提高用户满意的优化措施

典型场景：《电影院售票管理系统》

座位选择与订票流程：

座位图查看：
- 空余座位以白色显示在座位图上。
座位选择：
- 用户点击心仪的空余座位，选择他们想坐的位置，系统随后将这些座位标记为选中状态。
座位确认：
- 用户完成座位选择后，确认所选座位无误。
支付与电影票生成：
- 用户确认座位后进入支付页面，完成支付流程。
- 支付成功后，系统生成电影票，用户可在系统中查看或下载票务信息。

典型用户的解决方法：

问题：如何有效选择和确认座位

解决方法：

查看座位图：
- 用户选定特定电影和放映时间后，座位分布图展示给用户，便于直观了解各个座位的位置和剩余情况。
多种选择座位方式：
- 用户可以根据个人喜好进行座位选择，系统支持单个选择、连续选择或区域选择等多种方式，以适配不同的用户需求。
订单详情确认：
- 在选择座位后，用户进一步确认所选座位，系统将显示详细的订单信息，包括座位位置、票价等，确保用户的选择无误。

4 新队员开发环境搭建指南

如果你的团队来了一个新队员，有一台全新的机器，你们是否有一个文档，只要设置了相应的权限，他就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？（在这过程中，不需要和老队员做任何交流）

有的，在开发初期，我的团队成员遇到了不少配置环境的问题，但好在我们硬件配置和系统版本相差不大，为了解决该问题，我们决定推出一份帮助文档，用于解决配置带来的问题。

5 源代码控制

你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？
场景：程序员甲正在对几个文件进行修改，实现一个大的功能，这时候，程序员乙也要改其中一个文件，快速修复一个问题。怎么办？
一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？
有几种设计，各有什么优缺点？
例如，签出文件后，此文件就加锁，别人无法签出；或者，所有人都可以自由签出文件。

我们团队的源代码控制在Gitee，采用的是Git系统。
对于文件的锁定问题，我们一般采用的是合并更改。这在初期开发的过程中一直出现，团队成员也曾遇到无法解决合并更改的问题。为此，我编写了一份解决方案文档，旨在帮助团队成员解决此类问题，方便大家记忆和操作。

6 查看版本差异

场景1：程序员甲看到某个文件被修改了，他怎么看到这个文件在最近的修改究竟改了哪些地方？（例子）
场景2：程序员甲看到某个文件在最新版本被改动了100 多行，那么和这100多行对应的其他修改在什么文件中呢？这个修改是为了解决哪些问题而作的呢？那些问题有工作项（work item，issue），或者bug 来跟踪么？

我用的是idea开发，以下场景均为idea使用的结果。
对于场景一：
我先在Git选项中选择Selected File下的Show Diff，然后就能查看当前文件和远程项目中文件的差异了
对于场景2：
可以通过gitee查看变更记录

7 合并更改

如果某个文件在你签出之后已经被别人修改，并且签入了，那么你在签入你的修改的时候，如何合并不同的修改（merge)? 你用了什么工具来帮助你？
我是用的是idea开发工具

更新（Update）本地代码仓库：在IDEA中，可以使用版本控制系统（VCS）界面的"更新项目"（Update Project）功能来拉取最新的代码。
如果有冲突（conflicts），IDEA会提示解决，点击弹出的对话框中的"合并"（Merge）。
使用内置的合并工具：IDEA内置了一个功能强大的合并工具，它可以帮助我可视化地比较不同的代码变更，并在一个用户友好的界面中解决冲突。界面中通常会分为三个部分，左边是他人的变更，中间是合并后的结果，右边是你的变更。
手动解决冲突
测试合并后的代码
提交合并后的改动

8 关于签入

你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？
场景：程序员甲要签入 20 个文件，他一个一个地签入，在签入完5 个 .h 文件之后，他发现一些 .cpp 文件和最新的版本有冲突，他正在花时间琢磨如何合并… 这时候，程序员乙从客户端同步了所有最新代码，开始编译，但是编译不成功 - 因为有不同步的 .h 文件和 .cpp 文件！这时候，别的程序员也来抱怨同样的问题，甲应该怎么办？

回滚（revert）或取消已经签入的文件：程序员甲应该使用版本控制系统回滚或取消已经提交的.h文件，以保证代码仓库中代码的一致性。
修复冲突：在本地解决所有的.cpp文件和最新版本的冲突。
本地测试：解决冲突并合并修改后，程序员甲需要在本地构建和测试所有修改，确保一切正常。
原子提交：冲突解决并通过本地测试后，程序员甲应该将所有20个文件作为一个整体，通过原子提交一次性签入版本控制系统。
通知团队成员：签入操作完成后，通知其他团队成员获取最新提交的代码，并进行编译和测试。

9 Changelist Management: 紧急Bug处理与本地修改的有效隔离

5.你的PC 上有关于三个功能的修改，但是都没有完成，有很多文件处于半完工的状态，这时你要紧急修改一个新的 bug，如何把本地修改放一边，保证在干净的环境中修改这个 bug, 并成功地签入你的修改 — changelist management。

为了在一个干净的环境中修改新的 bug 并成功地签入修改，采取以下步骤：首先，提交或保存当前关于三个功能的修改，确保工作进度得以保留。接着，在版本控制系统中创建一个新的分支用于修复新的 bug，并切换到该分支以确保专注于修改。然后，解决新的 bug 并进行必要的测试以验证修复。
最后，提交修改到版本控制系统，并在提交信息中描述清楚所做的修改和修复的 bug。完成后，可以考虑将新分支合并回主分支或其他适当的分支。通过这些步骤，你可以在不受其他未完成修改影响的情况下，专注于修复新的 bug，并确保修改的成功签入。

10 高效提交流程：自动化工具在代码签入与质量控制中的运用

规范操作和自动化
你的团队规定开发者签入的时候要做这些事情：
- 运行单元测试，相关的代码质量测试。
- 代码复审（要有别的员工的名字）
- 和这次签入相关的issue 编号，任务/task，缺陷/bug 编号，等等，以备查询。
请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？（高级功能，代码提交之后，相关bug 的状态会改动为 “fixed”，并且有链接指向这次签入。），举个例子。

是的，我们的团队使用了一些自动化工具来方便开发者一次性填入所有信息并提交代码。其中一个例子是使用集成开发环境（IDE）中的版本控制工具，比如 Git，并结合一些插件或扩展来实现自动化流程。这些工具通常提供了以下功能：

自动运行单元测试和代码质量测试：开发者提交代码时，可以配置 IDE 或版本控制系统来自动运行单元测试和代码质量测试，以确保提交的代码符合质量标准。
代码复审：通过版本控制系统的代码审查功能，开发者可以轻松地邀请同事进行代码审查，并在提交时将审查人员的名字附加到提交信息中。
关联相关的任务和缺陷编号：开发者可以在提交信息中引用相关的任务、缺陷或问题编号，以便于跟踪和查询。有些集成开发环境甚至可以通过插件直接在提交信息中添加链接到相关问题的功能。
自动更新关联的 bug 状态：一些版本控制系统和项目管理工具的集成可以实现在代码提交后自动更新相关 bug 的状态，例如将状态更改为 “fixed”，并提供链接指向这次签入的详细信息。例如，在提交信息中包含关键字和特定格式，当提交后触发自动状态更新。

11 如何给你的源代码建立分支？

场景1：你们需要做一个演示，所以在演示版本的分支中对各处的代码做了一个临时的修改，同时，主要的分支还保持原来的计划开发。你们怎么做到的？在演示之后，演示版本的有些修改应该合并到主分支中，有些则不用，你们是怎么做到的？
场景2：你们的软件发布了，有很多用户，一天，一个用户报告了一个问题，但是他们是用某个老版本，而且没有条件更新到最新版本。这时候，你如何在本地构建一个老版本的软件，并试图重现那个问题？

场景1：建立演示版本的分支并进行修改
为了进行演示，我们首先创建了一个演示版本的分支，并在该分支上进行了临时修改以满足演示的需求。在演示结束后，我们将需要的修改合并回主分支，同时回滚不需要的修改，以确保主分支保持原有的计划开发。
场景2：构建老版本的软件并重现问题
当用户报告一个问题时，我们首先检出报告问题的老版本的代码，并使用适当的构建工具构建老版本的软件。然后，在本地环境中运行老版本的软件，并尝试重现报告的问题，以便进一步进行调试和修复。

12 代码溯源分析：理解源文件历史签入的目的和时机

一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的（解决了哪个任务，或者哪个bug）？
场景：一个重要的软件历经几年，几个团队的开发和维护，忽然出现在某个条件下崩溃的事故，程序员甲经过各种debug手段，发现问题是在某一个文件中有一行代码似乎显然出了问题，但是这个模块被很多其他模块调用，这行代码是什么时候，为了什么目的，经过谁签入的呢？如果贸然修改，会不会导致其他问题呢？怎么办？

为了确定一个源文件中的每一行是什么时候签入的，以及为了什么目的签入的，程序员可以通过版本控制系统查看源文件的历史记录和提交信息。在确定了有问题的代码行后，程序员需要逐一检查每次提交的提交信息，以确定该行代码是在何时提交的，以及解决了哪个任务或者哪个 bug。
同时，需要分析其他模块对该文件的调用关系，评估修改可能带来的风险，并进行相应的修改和测试。这样可以有效地解决出现问题的源文件，并最大程度地减少修改可能带来的其他问题。

13 如何标记最后已知良好版本（Last Known Good）

为了标记软件的最后已知良好版本（Last Known Good），我们利用版本控制系统如Git执行以下步骤：

使用版本控制系统
确保项目已经采用了版本控制系统，比如Git。如果尚未使用，请迅速进行集成。
提交代码更改
代码变更时，都应该通过Git进行提交，并且配上详细的提交信息来说明修改内容与目的。
打标签标记Last Known Good版本
- 通过Git中的标签（Tags）功能，可以标记特定的提交。当代码处于稳定状态时，为其打上标签，比如lkg-v1.0。
- 保护标签，以防止被误删除或修改。在托管平台如GitLab或GitHub上，可以设置引用保护来确保标签不被更改。
同步Last Known Good版本
- 新员工同步： 新员工可以通过克隆仓库并检出Last Known Good标签来同步代码。
- 发布准备： 发布时，以Last Known Good标签为起点，基于此创建新分支，进行发布前的准备，再从该分支进行发布。
持续更新Last Known Good版本
时间推移，随着更多稳定版本的出现，应创建新的Last Known Good标签以标记这些版本。
自动化和CI/CD
- 自动化测试： 引入自动化测试以客观判断代码质量。测试通过率达到一定标准自动打上Last Known Good标签。
- CI/CD： 利用持续集成/持续部署工具自动化构建、测试和部署过程。这确保每次标记的Last Known Good版本都通过了构建和测试，真正具备发布的条件。

14 自动化测试与持续集成在代码质量保障中的应用

问题一：源代码、单元测试和其他测试脚本的存放位置

答案： 我们的源代码、单元测试和其他测试脚本一般放在项目结构中相邻的位置，这样方便开发与测试的紧密协作和维护。

问题二：修改源代码是否确保相应的测试也更新

答案： 在我们团队中，源代码的任何修改都必须伴随着相应测试的更新，以确保软件质量的持续性和可靠性。这涉及到开发者的责任感和团队的自我监管机制来保持代码与测试的同步。

问题三：自动构建任务的部署

答案： 我们团队利用持续集成（CI）系统，比如Jenkins或Travis CI，部署自动构建任务，它可以在代码变更时自动执行构建和测试流程。

问题四：程序员在签入前的本地自动测试

答案： 是的，在代码签入前，开发者能通过集成开发环境（IDE）或本地构建脚本自动运行测试，确保本地更改不会对软件整体质量造成影响。

问题五：代码签入后的服务器端自动测试

答案： 我们的CI服务器在代码提交后自动执行编译和测试，只有测试通过的代码才会被签入。这保证了合并到主分支的代码质量。

问题六：自动同步、构建和测试的服务器配置

答案： 团队已配置具备自动同步、构建和运行单元测试的服务器。如果构建或测试失败，它会自动向团队成员发出通知，便于及时解决问题。

15 各种软件构建环境的比较分析

下表展示了不同软件构建环境的优点、缺点和成本比较，以助于团队选择合适的工具。

软件构建环境	优点	缺点	成本
GitHub	- 全球最大的代码托管平台 - 强大的社区支持和协作功能 - 易于集成其他CI/CD工具	- 对于私有仓库需要付费 - 可能受到网络限制（在某些地区）	免费（公共仓库）；付费（私有仓库）
Gitee	- 国内访问速度快 - 支持中文界面和文档 - 提供私有仓库服务	- 相比GitHub，社区规模和活跃度较小	免费（公共仓库）；付费（私有仓库）
coding.net	- 提供完整的项目管理工具链 - 支持代码托管、任务管理、文档协作等 - 私有仓库服务	- 功能较为全面，但可能对于小型团队来说过于复杂	免费（基础功能）；付费（高级功能）
Visual Studio Team Foundation Server	- 与Visual Studio深度集成 - 提供全面的ALM（应用生命周期管理）功能 - 支持多种开发语言和平台	- 学习曲线可能较陡峭 - 部署和维护成本较高	付费
Gitblit	- 易于在Windows系统下搭建 - 提供网页端管理界面 - 轻便且易于扩展	- 社区支持和文档相对较少 - 功能相对简单	免费
Visual Source Safe (VSS)	- 早期的版本控制系统 - 对一些老项目可能仍有支持	- 功能较为陈旧 - 不再是主流的版本控制系统	付费（可能通过旧版许可或企业协议）
本团队自行搭建的系统	- 完全自定义，可以根据团队需求进行定制 - 可以更好地保护敏感数据	- 需要投入大量时间和资源进行开发和维护 - 可能存在稳定性、安全性等问题	取决于开发投入和维护成本

16 “英语单词学习与分享互动”: 一款社交化背单词手机应用的需求分析与设计

•手机英语背单词软件，用户可以选择单词本的类型（四级，六级，GRE，等），每天背单词的进度。
•可以和好友分享自己背单词的进度。还可以挑战好友，挑选20个单词，送给好友，让好友选择正确的解释，并把成绩自动分享回来。
•假设有微博/微信/email 可以确定用户的身份
•假设有服务器可以返回【中文 – 英语单词】的对应关系
用下面的工具进一步分析这些需求，做出草图
•思维导图
•ER图
•Use Case
•Data Flow Diagram
•UML

思维导图（Mind Map）
思维导图是将想法通过可视化的方式组织起来，以中心主题为核心向外扩散。对于这个背单词软件，核心节点可能是“手机英语背单词软件”，然后从这个节点伸展出不同的功能分支，比如“选择单词本的类型”，“每日背单词进度”，“分享背单词进度”，“挑战好友”以及“单词解释挑战”。每个分支下面可以进一步细化具体的操作或选项。
实体关系图（Entity-Relationship Diagram, ER图）
ER图用于描述系统中的实体以及实体之间的关系。在背单词软件中，“用户”、“单词本”、“进度”、“挑战”和“好友”可能是主要的实体。用户实体可能与单词本、进度、挑战及好友实体有关联。比如，一个用户（User）实体与单词本（Word Book）实体相关联，表明用户选择了某种类型的单词本。
用例图（Use Case）
用例图代表了不同角色（actors）与系统交互的场景。在背单词软件的情况下，唯一的角色是“用户”。用例包括“选择单词本类型”、“设置每日学习量”、“查看进度”、“分享进度至社交媒体”和“发送/接受挑战”。用例图帮助我们理解用户与系统如何交互。
数据流图（Data Flow Diagram, DFD）
数据流图描绘了数据在系统内部流动的路径。对于背单词软件，可以标示出从应用界面到数据库的数据流，包括用户输入的数据，如单词本选择情况、每日学习进度，以及如何将挑战结果发送给好友和服务器的数据流，如单词数据更新。
统一建模语言（Unified Modeling Language, UML）
UML是一个广泛用于软件工程的建模语言，它包含了多种图表来描述软件的不同方面。例如，活动图可以用来描述用户完成单个任务的步骤；类图可以用来定义软件中的数据结构；序列图可以描绘对象间交互的顺序等。