飞机预订系统——典型用户+最困难场景+快速原型制作+问题回答+手机英语背单词软件分析

典型用户

典型用户的模板

1. 名字（越自然越好）
2. 年龄和收入（不同年龄和收入的用户有不同的需求）
3. 代表的用户在市场上的比例和重要性比例大不等同于重要性高，如付费的用户比例 较少，但是影响大，所以更重要
4. 使用这个软件的典型场景
5. 使用本产品的环境（在办公室/ 家里/ 沙发/ 床上/ 公共汽车/ 地铁……）
6. 生活/ 工作情况
7. 知识层次和能力（教育程度，对电脑、互联网的熟悉程度）
8. 用户的动机、目的和困难（困难 = 需要解决的问题）
9. 用户的偏好

典型用户举例

1. 名字：王晓峰
2. 年龄和收入：42岁，年收入在20万到30万之间。属于中等收入群体。
3. 代表的用户在市场上的比例和重要性：在航空订票市场中占有一定比例，重要性较高。虽然付费能力不是最强的群体，但在航空出行市场中仍然扮演着重要角色。
4. 使用这个软件的典型场景：经常需要出差或旅行，需要频繁预订飞机票的商务人士。
5. 使用本产品的环境：通常在办公室或家里使用电脑或手机进行飞机订票，也可能在公共交通工具上利用碎片时间安排行程。
6. 生活/工作情况：在一家跨国公司任职中层管理岗位，需要经常出差国内外进行业务会议和谈判。
7. 知识层次和能力：具有本科学历，对电脑和互联网较为熟悉，在日常工作和生活中经常使用各类在线服务。
8. 用户的动机、目的和困难：主要动机是快速、方便地预订符合出行需求的机票，节省时间和精力。经常面临的困难包括行程变动导致的机票调整问题，以及如何在预算范围内获取舒适的舱位和服务。
9. 用户的偏好：倾向于选择航班时间灵活、服务品质好的航空公司，注重舒适度和出行效率。希望通过订票软件快速比较各种选项，找到最适合自己需求的机票。

最困难、最典型的场景

1. 处于典型环境下的用户
2. TA 在公司/家庭/学校/社区/…里面处于什么位置，负责什么?
3. TA 目前用什么样的办法/工具
4. [客户待完成的任务]
5. 任务的频繁程度
6. 任务的细节
7. [ 客户动机 ]
8. 完成任务的动机是？完成之后是达到了什么状态
9. [ 客户问题 ]
10. 最大的烦恼是什么？ 现在客户是怎么绕过这些问题的？
11. 对于 [ 待完成的任务 ]， 如果你能改变一件事情，你想改变什么？

在飞机订票系统中，最困难、最典型的场景如下：

•== 处于典型场景下的客户==：王小亮，一位频繁出差的商务人士。
• TA 在公司里面处于中层管理岗位，负责跨国公司业务会议和谈判。
• TA 目前用什么样的办法/工具：通常使用各大航空公司的官方网站或第三方预订>平台来搜索和预订机票。
• 客户待完成的任务：频繁预订符合出差需求的机票。
• 任务的频繁程度：每个月至少需要安排一次国内或国际出差，需要多次预订机票。
• 任务的细节：需要考虑航班时间、舱位舒适度、价格以及行程变动时的改签问题。
• 客户动机：完成任务的动机是快速、方便地找到符合需求的机票，提高出行效率和舒适度。完成任务后能够安心地进行商务出差。
• 客户问题：最大的烦恼是在频繁出差需要灵活调整行程时，处理机票变动和改签问题较为繁琐。目前客户通过联系客服或自行登录网站进行修改。
• 对于待完成的任务，如果改进一件事情，客户希望改变的是预订流程的复杂性和改签手续的繁琐性。客户希望能够更快速、便捷地完成预订和改签操作，避免耽误时间和增加精力成本。

为了提高10倍的用户满意度和产品效率，我们小组考虑以下改进措施：

1. 引入智能推荐算法：根据用户的偏好和历史订单数据，系统可以智能推荐符合需求的机票选项，减少用户搜索时间。
2. 简化预订流程：优化界面设计，简化预订流程，让用户能够快速、轻松地完成预订操作。
3. 提供在线改签功能：引入在线改签功能，让用户可以直接在系统内完成机票改签，避免繁琐的人工操作。
4. 实时更新航班信息：保持航班信息的实时更新，及时通知用户航班动态和可能的变动，提高用户出行安排的效率和准确性。
5. 提供多样化支付方式：增加多种支付方式，提升支付灵活性，满足不同用户的支付习惯。
   通过这些改进措施，可以使飞机订票系统更加智能、便捷，提高用户满意度并提升产品效率。

快速原型制作典型场景

用快速原型工具或笔和纸画出一个本小组开发软件产品的典型场景，描述典型用户如何解决问题

问题回答

问题0

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

对于新队员和全新机器的情况，理想情况下，团队应该有一个详尽的文档，描述了从环境搭建到软件编译和单元测试运行的全过程。这样的文档通常包含系统要求、软件依赖、安装步骤、配置指南、编译指令以及运行测试的说明。通过适当的权限设置，新队员可以访问这个文档，并独立地按照文档指引完成所有步骤。这样，新队员可以快速地融入团队，并减少对老队员的直接依赖。

问题1

1、你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？

---

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

源代码控制：
源代码通常存储在版本控制系统（如Git、SVN等）中。
对于Git，文件锁定通常不是内置的，而是通过分支、合并和冲突解决机制来处理并发修改。

---

场景处理：
程序员甲正在修改多个文件实现大功能时，程序员乙需要快速修复其中一个文件的问题。乙可以基于当前主分支创建一个新的分支，修复问题，然后提交更改。之后，乙可以将这个修复合并回主分支，或者等待甲完成他的大功能后再合并。
锁定文件：这种设计可以确保在文件被编辑时其他人不能修改，但可能导致工作流程阻塞，降低团队协作效率。
自由签出：这种设计允许多人同时编辑文件，但可能导致合并冲突，需要团队具备良好的冲突解决能力。
优缺点：
锁定文件：优点是避免冲突，缺点是可能阻塞工作流程；
自由签出：优点是工作流程灵活，缺点是可能产生合并冲突。

问题2

2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。

---

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

查看文件差异和与工作项的关系：
大多数版本控制系统都提供了查看文件差异的功能。例如，在Git中，可以使用git diff命令来查看文件的更改。
为了跟踪代码修改与工作项和缺陷修复的关系，团队通常会使用项目管理工具（如JIRA、GitLab Issues等）来创建工作项和缺陷跟踪。这些工具通常允许将代码提交与工作项或缺陷修复关联起来。

---

场景处理：
程序员甲可以使用版本控制系统的差异查看功能来查看文件的最近修改。
如果某个文件在最新版本中改动了100多行，甲可以通过查看提交记录和相关的工作项或缺陷跟踪来了解这些修改的目的和背景。
工作项和缺陷跟踪：
为了确保代码修改与问题或工作项相对应，团队应该养成在提交代码时引用相关工作项或缺陷的习惯。这样，通过查看提交记录，可以轻松地追踪到代码修改与哪些问题或工作项相关联。
所有的工作项和缺陷修复都应该被跟踪，以便团队能够了解项目的状态和进度，并确保所有问题都得到了妥善解决。

问题3

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

解决步骤：版本控制系统：首先，确保你使用的是版本控制系统（如Git、SVN等），它们提供了合并不同修改的功能。
拉取最新代码：在你准备签入修改之前，先拉取（pull）或更新（update）最新的代码，确保你的本地副本包含他人的修改。
合并操作：使用版本控制系统的合并功能，将你的修改与最新的代码进行合并。这通常涉及到运行特定的命令（如Git的git merge）或使用图形界面的合并工具。
解决冲突：如果合并过程中出现冲突（即你和他人修改了同一部分的代码），你需要手动编辑文件以解决这些冲突。这通常涉及到打开文件，查找以特殊标记（如<<<<<<<、=======和>>>>>>>）表示的冲突区域，然后决定保留哪些修改。
测试：解决完冲突后，确保你的代码仍然按预期工作。运行测试套件或手动测试关键功能是一个好习惯。
签入合并后的代码：一旦你对合并后的代码感到满意，就可以将其签入版本控制系统了。

---

工具帮助：
Git：Git是一个强大的分布式版本控制系统，广泛用于软件开发。它提供了丰富的合并和冲突解决功能，以及大量的第三方工具和插件来增强这些功能。
SVN：Subversion（SVN）是另一个流行的版本控制系统，虽然不如Git灵活，但对于许多项目来说仍然足够使用。它也有自己的合并和冲突解决机制。
IDE集成：许多集成开发环境（IDE）如IntelliJ IDEA、Visual Studio Code、Eclipse等集成了版本控制功能，包括合并和冲突解决。这些IDE通常提供直观的图形界面来简化合并过程。
第三方合并工具：除了版本控制系统自带的工具外，还有一些第三方合并工具（如KDiff3、Meld等）可以帮助你更轻松地解决合并冲突。这些工具通常提供更强大的比较和编辑功能。

总的来说，合并不同修改是版本控制中常见且重要的任务。选择合适的工具和遵循正确的步骤可以帮助你高效地完成这项任务。

问题4

4. 你有20个文件都是关于同一个功能的修改，你要如何保证这些文件都同时签入成功（修改的原子性），或者同时签入不成功？

---

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

为了保证多个文件修改的原子性，即确保所有相关文件要么全部成功签入，要么全部不签入，可以采取以下策略：
使用分支：在开始对多个文件进行修改之前，程序员甲可以创建一个新的分支。在这个分支上进行所有相关的修改，并在修改完成后进行充分的测试以确保功能正常。一旦测试通过，甲可以将这个分支合并回主分支。这种方法确保了所有的修改要么全部应用到主分支，要么全部不应用。
暂存更改：如果版本控制系统支持（如Git），甲可以将所有20个文件的修改暂存起来，而不是逐个签入。这样，所有的修改都保持在本地，不会影响到其他人。在解决所有可能的冲突并完成所有测试之后，甲可以一次性提交所有暂存的更改。
使用补丁或变更集：某些版本控制系统（如Perforce）支持将多个文件的修改组合成一个逻辑单元，称为补丁或变更集。程序员甲可以创建一个包含所有20个文件修改的变更集，并尝试将其签入。如果中间遇到冲突，他可以暂停签入，解决冲突，然后继续签入整个变更集。
沟通协调：在签入之前，程序员甲应该通知团队中的其他成员他正在进行的修改，并请求他们暂时不要同步或编译代码。这可以通过团队内部的沟通渠道（如邮件、聊天工具或项目管理工具）来完成。
回滚不完整的更改：如果程序员甲在签入过程中意识到某些文件有冲突，并且决定暂停签入，他应该确保回滚那些已经签入的文件到之前的状态。这样，其他人同步代码时不会遇到不同步的文件。
使用持续集成/持续部署（CI/CD）：引入CI/CD系统可以帮助自动化测试并验证代码更改。当甲尝试签入他的更改时，CI/CD系统可以自动运行测试并报告任何失败或冲突。这有助于更早地发现问题，并避免将问题推给其他开发人员。
在当前的场景中，如果程序员甲已经签入了5个.h文件并发现.cpp文件有冲突，他应该立即停止进一步的签入操作，并通知团队其他成员不要同步代码。然后，甲应该解决.cpp文件中的冲突，并测试所有相关的修改以确保它们协同工作。一旦所有问题都解决并且测试通过，甲可以一次性签入所有剩余的修改。同时，考虑使用分支、暂存更改或使用CI/CD系统来防止类似问题的再次发生。

问题5

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

当你在本地有多个功能的修改处于未完成状态，但又需要紧急修复一个新bug时，管理这些修改（通常称为“更改列表”或“changelist”管理）以确保在干净的环境中修复bug并成功签入修改，是非常重要的。
使用版本控制系统（如Git）

• 创建临时分支：
  如果你使用的是Git，可以创建一个新的临时分支来存放当前所有未完成的修改。这样，你的主分支（或你用来修复bug的分支）将保持干净。
  git stash # 保存当前工作区的修改
git checkout -b feature-work-in-progress # 创建并切换到新的临时分支
git stash pop # 恢复之前保存的修改到工作区
• 切换到干净分支：
  切换到主分支或专门为bug修复创建的分支。确保这个分支是干净的，没有未提交的修改。
  git checkout main # 假设main是你的主分支
• 修复bug：
  在干净的分支中，进行bug修复。完成后，提交这些修改。
  git add . # 添加所有修改的文件
git commit -m "Fix bug XYZ"
• 签入bug修复：
  将bug修复推送到远程仓库，并可能需要通过代码审查或CI/CD流程。
  git push origin main # 假设origin是你的远程仓库名，main是主分支名
• 合并回临时分支：
  一旦bug修复完成并签入，你可以将主分支（或bug修复分支）的更改合并回你的临时分支，继续之前的工作。
  git checkout feature-work-in-progress
git merge main # 将主分支的更改合并到临时分支

问题6

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

我们使用自动化工具来简化开发者操作。开发者在提交代码时，通过集成的工具自动运行单元测试、代码质量分析，并进行代码复审。同时，开发者在提交信息中填入相关的issue编号、任务和缺陷信息。
我们团队使用定制的自动化工具，比如名为"智能CI/CD"的系统，它与我们的版本控制系统紧密集成。一旦代码提交成功，智能CI/CD会自动触发流程，更新相关issue状态，并将修复的bug状态自动标记为“fixed”，同时在相应的issue中添加签入链接，以便快速查看变更详情。
这样，智能开发团队的开发者可以更加方便地提交代码，并确保相关信息完整性和流程规范性。

问题7

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

---

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

为了给源代码建立分支并在演示版本的分支中做临时修改，然后将部分修改合并到主分支中，可以按照以下步骤操作：
创建演示版本的新分支：
git checkout -b demo_branch main
在演示版本的分支中进行临时修改和调整。
演示结束后，根据需要选择性地将修改合并到主分支：
git checkout main
git merge demo_branch
如果只需要合并部分修改，可以使用交互式合并（interactive merge）：
git checkout main
git merge --no-ff --no-commit demo_branch
git reset HEAD <file(s) to exclude>
git commit -m "Merge selected changes from demo_branch"

对于第二个场景，如果需要在本地构建一个老版本的软件以重现问题，可以按照以下步骤进行：
确定需要构建的老版本的标签或提交哈希值。切换到该特定的标签或提交：
git checkout <tag/commit>
• 根据项目的构建指南或脚本，重新构建软件：
make clean
make

运行构建后的软件，并尝试重现报告的问题。
通过这些步骤，您可以在本地构建老版本的软件，并进行问题重现和调试。

问题8

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

当遇到一个源文件中特定行代码出现问题时，想要了解该行代码的签入历史以及修改目的，并担心贸然修改可能引发其他问题时，可以采取以下步骤：

• 查看每一行的签入历史和目的：使用版本控制系统（如Git）提供的功能，通过 git blame 命令查看文件中每一行是谁在什么时间提交的，并显示对应的提交哈希值。
  git blame <file_path>
  根据显示的提交哈希值，使用 git show 命令查看具体的提交信息，包括提交者、提交时间、提交目的等信息。
  git show <commit_hash>
• 了解修改的目的和背景：
  * 在提交信息中，通常会包含提交的目的、解决的任务或bug等相关信息，从中可以了解这行代码的修改原因。
  * 如果需要更多背景信息，可以与曾经负责该行代码修改的开发者或团队进行沟通。
• 风险评估和测试：
  * 在确定修改之前，建议在本地环境中测试修改，确保不会引入其他问题。
  * 如果不确定修改是否会影响其他模块，可以进行全面的测试和代码审查，以确保修改的安全性和稳定性。
• 谨慎修改和部署：
  * 在了解签入历史和修改目的的基础上，进行谨慎的修改，并跟踪修改的影响范围。
  * 在部署修改之前，可以先进行灰度发布或者逐步回滚的策略，以降低风险。

问题9

9. 如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？ 代码每天都在变， 有时质量变好，有时变差，我们需要一个 Last Known Good （最后稳定的好版本） 版本， 这样新员工就可以同步这个版本， 我们如果需要发布，也是从这个版本开始。 那么如何标记这个 Last Known Good 版本呢？

为了给系统的所有源文件打上标签，并且创建一个 Last Known Good （最后稳定的好版本）标签，可以采取以下步骤：
给系统的所有源文件打上标签：
1.提交当前代码状态：
确保当前的代码修改已经提交并且工作目录是干净的。
git add .
git commit -m "Committing all changes before tagging"
2.创建一个新的标签：
为当前代码创建一个标签，例如 “v1.0”。
git tag v1.0
3.推送标签到远程仓库：
如果需要其他人能够同步这些标签，需要将标签推送到远程仓库。
git push origin v1.0

---

创建 Last Known Good 标签：

1. 找到最后稳定的好版本：
   进行代码审查、测试等工作，确认某个版本是“最后稳定的好版本”。
2. 创建 Last Known Good 标签：
   为该版本创建一个 Last Known Good 标签，例如 "LastKnownGood_v1.0"。
git tag LastKnownGood_v1.0 <commit_hash>
   其中 <commit_hash> 是最后稳定的好版本对应的提交哈希值。
3. 推送 Last Known Good 标签到远程仓库：
   如果需要其他人和发布都能从这个版本开始，需要将 Last Known Good 标签推送到远程仓库。
   git push origin LastKnownGood_v1.0

通过以上步骤，您可以为系统的所有源文件打上标签，并创建一个 Last Known Good 标签以便新员工同步这个版本，以及在发布时能从这个版本开始。同时，确保将标签推送到远程仓库，以便其他人能够访问和使用这些标签。

问题10

10. 你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？ 在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？ 在程序员提交签入之后，服务器上是否有自动测试程序， 完成编译，测试，如果成功，就签入，否则，就取消签入？ 团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

一个良好的软件开发流程通常包括源代码管理、自动化构建和测试、持续集成等环节。

1. 项目的源代码和测试是否放在一起？
   通常，项目的源代码和相关的测试代码可以放在一起的，例如在同一个代码库中。这样有利于代码和测试的管理，并且修改源代码时也能够更新相应的测试。
2. 修改源代码是否会确保相应的测试也更新？
   在良好的开发实践中，修改源代码时通常会考虑更新相应的测试。同时，团队也会有代码审查和持续集成等环节来确保修改的质量。
3. 团队是否能部署自动构建的任务？
   是的，现代的软件开发团队通常会配置自动化构建系统，例如使用持续集成工具（如Jenkins、Travis CI等）来自动构建和测试代码。
4. 程序员能否自动在自己的机器上运行自动测试？
   是的，程序员通常可以在本地运行自动化测试以确保本地修改不会影响整个软件的质量。
5. 提交签入之后，服务器上是否有自动测试程序？
   是的，持续集成环境通常会配置自动化测试程序，包括编译、单元测试、集成测试等。成功则自动进行代码提交，失败则通知相关人员。
6. 团队是否配置了服务器来自动同步所有文件、自动构建、自动运行相关的单元测试，并在错误时发邮件通知团队？
   是的，团队通常会配置持续集成服务器来自动同步文件、自动构建、自动运行测试，并在遇到错误时发邮件通知团队成员。
   通过以上自动化流程，团队能够更高效地进行代码开发、构建和测试，并及时发现和解决问题，有助于确保软件质量和稳定性。

问题11

11. 分析比较各种软件构建环境： 就像一个厨师要分析各种厨房用具，挑选适合自己的工具组合， 一个软件团队也要挑选适合自己的源代码管理和其他配套工具，请选择至少三种，比较各自的优点缺点，成本：

github
https://gitee.com/education
coding.net
code.csdn.net
gitcafe.com
www.visualstudio.com
code.taobao.org
Visual Studio Team Foundation Server
gitblit， 在Windows系统下构建 git 服务，带网页端管理…
Visual Source Safe (VSS)
本团队自行搭建的系统

---

1. GitHub:

• 优点：流行度高，社区活跃，支持分布式版本控制，易于协作和代码审查，具备强大的Issue跟踪功能。
• 缺点：对私有仓库收费，部分高级功能需要付费订阅，可能不适合一些小团队或个人开发者。
• 成本：免费版提供公共仓库功能，私有仓库需付费订阅。

2. Visual Studio Team Foundation Server (TFS):

• 优点：与Visual Studio集成良好，提供全面的应用生命周期管理(ALM)工具，包括版本控制、工作项跟踪、构建管理等。
• 缺点：安装和配置相对复杂，适用于大型企业团队，对小团队来说有些臃肿。
• 成本：需要购买许可证，并且对用户数量有限制。

3. Visual Source Safe (VSS):

• 优点：简单易用，适合小型团队，直接集成到Visual Studio中。
• 缺点：已经停止更新和维护，性能、安全性和扩展性不如其他现代化的版本控制系统。
• 成本：在一些情况下可能会包含在Visual Studio订阅中，但不再推荐作为主要的版本控制工具使用。

问题12

12.每个小组说明自己团队的开发环境和流程有什么需要改进的地方？

1. 开发工具链：评估团队使用的开发工具，确保其能够有效支持团队的需求，并考虑引入新的工具来提升效率。
2. 文档和知识管理：加强文档编写和知识管理，确保团队成员之间的信息共享和沟通顺畅。 团队协作和沟通：加强团队协作工具的使用，促进团队成员之间的有效沟通和合作。

问题13:手机英语背单词软件

13. 考虑下面的软件需求：

• 手机英语背单词软件，用户可以选择单词本的类型（四级，六级，GRE，等），每天背单词的进度。
  可以和好友分享自己背单词的进度。还可以挑战好友，挑选20个单词，送给好友，让好友选择正确的解释，并把成绩自动分享回来。
  假设有微博/微信/email 可以确定用户的身份
  假设有服务器可以返回 【中文 – 英语单词】的对应关系

用下面的工具进一步分析这些需求，做出草图

1. 思维导图

2. ER图

• ER图描述：
  用户 (User):
  属性：用户ID（主键）、用户名、密码、微博/微信/email（用于身份验证）
  单词本 (WordBook):
  属性：单词本ID（主键）、单词本名称（如四级、六级、GRE等）
  单词 (Word):
  属性：单词ID（主键）、英语单词、中文解释
  进度 (Progress):
  属性：进度ID（主键）、用户ID（外键，引用User）、单词本ID（外键，引用WordBook）、学习日期、学习时长、学习单词数
  挑战 (Challenge):
  属性：挑战ID（主键）、挑战者ID（外键，引用User）、被挑战者ID（外键，引用User）、挑战日期、挑战状态（如进行中、已完成等）
  成绩 (Score):
  属性：成绩ID（主键）、挑战ID（外键，引用Challenge）、用户ID（外键，引用User）、正确单词数、总单词数、得分
  

3. Use Case

4. Data Flow Diagram

5. UML

上述的用例图 (Use Case)实际上也为uml图中的一种，以下将绘用户背词的状态图进一步阐述系统中核心状态的细节。

小组成员个人作业链接

• 杨嘉宜:第3,4周个人作业
• 刘真桃:第3,4周个人作业
• 袁露容:第3,4周个人作业
• 杨海娟: 第3,4周个人作业
• 姚文辉:第3,4周个人作业
• 陈建明:第3,4周个人作业