学生请假管理系统—典型用户及场景

第三周

一、  典型用户（作业一）

1.1学生请假管理系统教师用户

身份：教师

名字：李老师

年龄和收入：40岁，中等收入，作为教育工作者，拥有稳定的薪资和福利待遇。

代表的用户在市场上的比例和重要性：李老师代表了广大教师群体，这一用户群体在市场上的比例相当大，并且他们对于学校日常管理和学生管理有着至关重要的影响。教师们的体验和反馈对于请假管理系统的改进和推广至关重要。

使用这个软件的典型场景 ：李老师需要在学生提交请假申请后，登录请假管理系统进行审批。他可以查看学生的请假理由、请假时间等信息，并根据实际情况进行批准或驳回。

使用本产品的环境：李老师主要在学校的办公室使用本产品，这里提供了稳定的网络环境和适合办公的设施。

生活/工作情况：李老师是一名负责任的教师，平时工作繁忙，需要处理各种教学和管理事务。他关注学生的学业和成长，对于请假管理也十分重视。

知识层次和能力：李老师拥有高等教育学历，对电脑和互联网的基本操作比较熟悉。他能够熟练使用各种办公软件和在线平台，进行日常的教学和管理工作。

用户的动机、目的和困难：李老师使用请假管理系统的动机是提高请假审批的效率和准确性，确保学生请假流程的规范化和透明化。他的目的是方便管理学生的请假情况，减少纸质文件的使用，提高工作效率。困难在于，过去请假审批流程繁琐，需要耗费大量时间和精力进行手动操作。

用户的偏好：李老师偏好界面清晰、操作简便的产品，他希望请假管理系统能够提供直观的数据展示和简洁的审批流程。同时，他也注重产品的稳定性和安全性，不希望出现系统崩溃或数据泄露的情况。他期望系统能够智能地整理和分析请假数据，为他提供决策支持。

1.2学生请假管理系统学生用户

身份：学生

名字：张萧红

年龄和收入：20岁，学生，无固定收入，主要依靠父母提供的生活费。

代表的用户在市场上的比例和重要性：张萧红代表了广大的在校学生群体，这一用户群体数量庞大，虽然他们可能没有直接的购买力，但他们的使用体验和反馈对于产品的改进和推广至关重要。因此，虽然付费比例不高，但他们在市场上的重要性不容忽视。

使用这个软件的典型场景：张萧红在需要请假时，会使用本小组开发的请假管理系统进行请假申请，避免了过去需要亲自到办公室或找老师签字的繁琐过程。

使用本产品的环境：张萧红主要在学校宿舍或图书馆使用本产品，这些地方提供了稳定的网络环境和适合学习的氛围。

生活/工作情况：张萧红是一名大学生，平时生活规律，学习认真。她需要经常参加各种课程和活动，有时会因为特殊原因需要请假。

知识层次和能力：张萧红是一名大学生，她对电脑和互联网的基本操作比较熟悉，能够熟练使用各种在线工具和平台。

用户的动机、目的和困难：张萧红使用请假管理系统的动机是方便快捷地提交请假申请，避免因为请假而耽误学习进度。她的目的是确保请假流程的高效和透明，减少不必要的沟通成本。困难在于，过去请假流程繁琐，需要耗费大量时间和精力。

用户的偏好：张萧红偏好界面简洁、操作便捷的产品，她希望请假管理系统能够提供清晰的申请流程和实时的申请状态更新。同时，她也注重产品的稳定性和安全性，不希望出现信息泄露或系统崩溃的情况。

1.3学生请假管理系统辅导员用户

身份：辅导员

名字：王辅导员

年龄和收入：35岁，中等偏上收入，作为高校辅导员，拥有稳定的薪资和一定的福利待遇。

代表的用户在市场上的比例和重要性：王辅导员代表了高校中的辅导员群体，他负责学生的日常管理和思想工作，是连接学校和学生之间的桥梁。这一用户群体虽然比例不如学生和教师多，但他在学生请假管理、思想引导等方面起着至关重要的作用，其反馈对于请假管理系统的改进和推广具有重要意义。

使用这个软件的典型场景：王辅导员在学生提交请假申请后，登录请假管理系统进行查看和审批。他会仔细核对学生的请假理由、请假时长，并与学生进行必要的沟通，确保请假的合理性和合规性。

使用本产品的环境：王辅导员主要在学校的办公室使用本产品，偶尔也会在家里加班时使用。这些地方都提供了稳定的网络环境和适合办公的设施。

生活/工作情况：王辅导员工作繁忙，需要处理大量学生的日常管理事务，包括学生请假、心理咨询、学业指导等。他关注学生的全面发展，注重与学生的沟通和交流。

知识层次和能力：王辅导员通常拥有较高的教育学历，对电脑和互联网的基本操作比较熟悉。他能够熟练使用各种办公软件和在线平台，进行日常的学生管理工作。

用户的动机、目的和困难：王辅导员使用请假管理系统的动机是提高请假审批的效率和准确性，确保学生请假流程的规范化和透明化。他的目的是更好地掌握学生的请假情况，为学生提供及时的帮助和指导。困难在于，过去请假审批流程繁琐，需要耗费大量时间进行手动操作，且难以对请假数据进行有效的统计和分析。

用户的偏好：王辅导员偏好界面简洁明了、操作便捷的产品。他希望请假管理系统能够提供清晰的请假申请列表和审批流程，方便他快速查看和处理学生的请假申请。同时，他也注重产品的稳定性和安全性，不希望出现系统崩溃或数据泄露的情况。此外，他还期望系统能够支持数据导出和统计分析功能，方便他对请假数据进行深入的分析和研究。

二、典型场景（作业二）

2.1.典型场景下的客户

        客户为某高中的学生及教师，他们负责日常的上课和请假管理。

2.2 学生请假管理系统在公司/家庭/学校/社区/…里面处于什么位置，负责什么?

        在学校环境中，学生请假管理系统是日常行政管理的重要组成部分。它负责记录学生的请假申请、审批流程、请假统计及后续跟进，确保学校对学生出勤情况的全面掌握，同时也为学生和教师提供一个便捷的请假申请和审批平台。

2.3 学生请假管理系统 目前用什么样的办法/工具

        目前，学校使用的是基于Excel表格的传统请假管理方式。学生需要填写纸质请假条，教师手动记录并审批，最后由行政人员汇总统计。这种方式效率低下，容易出错，且不利于数据的长期保存和查询。

2.4 客户待完成的任务

        学生和教师需要频繁使用请假管理系统进行请假申请和审批。教师需要审核学生的请假理由，确认请假时长，并做出是否批准的决定。此外，学校管理层还需要定期查看请假统计，以了解学校整体的出勤情况。

2.5 学生请假管理系统的细节

        请假系统需要详细记录学生的请假信息，包括请假人、请假时间、请假时长、请假理由、审批状态等。同时，系统还需要支持多种请假类型（如病假、事假、公假等）和灵活的审批流程（如班主任审批、年级主任审批等）。

2.6 客户动机

        完成学生请假管理系统的动机是提高请假管理的效率和准确性，减轻教师和行政人员的工作负担，同时为学生提供更加便捷的请假服务。完成后，学校能够实时掌握学生的出勤情况，优化管理流程，提升学校整体管理水平。

2.7 客户问题

        最大的烦恼是请假流程繁琐、审批时间长，以及数据统计不准确。目前，客户通过纸质记录和人工汇总来绕过这些问题，但这增加了出错的可能性，且效率低下。

2.8 对于待完成的学生请假管理系统，如果能改变一件事情，客户想改变什么？

        客户希望能够实现请假流程的自动化和智能化，减少人工干预，提高审批效率。同时，他们也希望系统能够提供更加准确和详细的数据统计功能，以便学校管理层能够做出更加科学的决策。

2.9 为了提高10倍的“用户满意度和产品效率”，本小组应做出哪些改进措施？

（1）开发在线请假平台：设计一个易于使用的在线请假系统，支持学生在线提交请假申请，教师在线审批，减少纸质文档的使用，提高处理速度。

（2）优化审批流程：简化审批步骤，设置合理的审批权限，实现请假申请的快速流转。可以考虑引入自动化审批机制，对于符合条件的请假申请进行自动处理。

（3）增强数据统计功能：完善系统的数据统计和分析功能，提供多种维度的请假数据报表，帮助学校管理层全面了解学生出勤情况，为决策提供数据支持。

（4）提供个性化服务：针对不同用户群体（如学生、教师、管理层）提供个性化的服务界面和功能，满足不同用户的需求。

（5）加强系统安全性：确保学生请假管理系统的数据安全，防止数据泄露和非法访问。采用加密技术保护用户隐私，定期备份数据以防丢失。

（6）开展用户培训与支持：为用户提供系统的使用培训，确保他们能够熟练使用请假管理系统。同时，提供及时的技术支持，解决用户在使用过程中遇到的问题。

三、用户故事（作业三）

第四周

学生请假管理系统的用例图

question0：

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

answer: 

        我们确实拥有一份详细的搭建环境文档，其中包含了设置机器、安装必要的软件、配置环境变量、获取源代码、编译软件以及运行单元测试等所有步骤。这份文档针对新版本的软件进行了更新，确保提供的是最新、最稳定版本的编译指南。同时，我们也设置了相应的权限，确保新成员能够访问这份文档以及所需的资源。

question1：

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

        场景： 程序员甲正在对几个文件进行修改，实现一个大的功能， 这时候，程序员乙也要改其中一个文件，快速修复一个问题。怎么办？

answer: 

         我们团队使用Git源代码控制系统，在Git这样的分布式版本控制系统中，通常不会直接对文件进行锁定，而是通过分支和合并机制来处理冲突。程序员甲和程序员乙都可以同时修改同一个文件，并将各自的修改提交到不同的分支。当需要合并这些修改时，Git会自动检测并解决冲突。

question2：

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

        场景1：程序员甲可以在版本控制系统中查找最近的提交记录，找到涉及该文件的提交。
使用diff命令或图形界面工具查看该提交中该文件的差异。

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

answer:

        场景1：打开命令行，切换到项目目录。
使用git diff命令查看工作区与暂存区的差异，或使用git diff --cached查看暂存区与最近一次提交的差异。如果要查看特定提交中文件的差异，可以使用git show <commit-hash>:<file-path>。

        场景2：程序员甲首先查看该提交的说明或消息，以获取关于修改目的的线索。如果提交消息中包含对工作项的引用，程序员甲可以跳转到项目管理工具中查看该工作项的详细信息，包括其他相关文件的修改和解决的问题。如果没有直接引用，程序员甲可以检查其他最近的提交，看是否有其他文件也进行了相关修改，并尝试通过代码逻辑或注释理解这些修改之间的关系。

question3：

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

answer:

        需要进行合并操作以解决版本之间的冲突。在Git这样的分布式版本控制系统中，你可以使用git merge或git rebase命令来完成合并操作。

question4：

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

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

answer: 

        回滚已签入的.h文件：如果可能的话，程序员甲可以回滚已经签入的.h文件，将它们恢复到之前的状态。
解决冲突：然后，程序员甲需要解决.cpp文件中的冲突。这可能需要与修改这些.cpp文件的其他程序员进行协调。
重新签入所有文件：解决冲突后，程序员甲可以重新签入所有20个文件，确保它们作为一个整体被提交。

question5：

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

answer: 

        可以利用版本控制系统Git的分支和暂存功能来确保在一个干净的环境中修改bug，并成功签入我的修改。

question6：

     规范操作和自动化

     你的团队规定开发者签入的时候要做这些事情：

    - 运行单元测试，相关的代码质量测试。

    - 代码复审 （要有别的员工的名字）

    - 和这次签入相关的issue 编号， 任务/task， 缺陷/bug 编号，等等， 以备查询。

    请问你的团队有这样的自动化工具让开发者方便地一次性填入所有信息然后提交么？  （高级功能， 代码提交之后， 相关bug 的状态会改动为  “fixed”， 并且有链接指向这次签入。），举个例子。

answer: 

     以下是一个简化的例子来说明如何实现这些高级功能：

    1.自动化代码质量检查与单元测试：
        使用CI/CD（持续集成/持续部署）工具，如Jenkins、GitLab CI等，在每次代码提交时自动运行单元测试和相关的代码质量检查（如代码风格检查、静态代码分析等）。
        如果测试或检查失败，CI/CD工具会报告错误，并阻止代码合并到主分支。
    2.代码复审：
        可以使用Git的Pull Request功能或类似机制来发起代码复审。
        在Pull Request中，开发者可以指定其他员工进行代码复审，并填写相关的描述和变更信息。
        复审者可以在Pull Request中评论、提出修改意见，直到代码满足要求后批准合并。
    3.关联Issue/任务/缺陷：
        在代码提交信息中，开发者可以包含与本次提交相关的Issue/任务/缺陷的编号或链接。
        CI/CD工具或版本控制系统可以配置为解析这些提交信息，并自动更新相关Issue/任务/缺陷的状态或添加提交链接。
    4.自动化状态更新：
        当代码合并到主分支并通过所有检查后，可以配置CI/CD工具或与其他系统集成，以自动更新相关Issue/任务/缺陷的状态为“fixed”。

question7：

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

    场景1：你们需要做一个演示，所以在演示版本的分支中对各处的代码做了一个临时的修改， 同时，主要的分支还保持原来的计划开发。 你们怎么做到的？ 在演示之后，演示版本的有些修改应该合并到主分支中，有些则不用，你们是怎么做到的？

    场景2： 你们的软件发布了，有很多用户，一天，一个用户报告了一个问题，但是他们是用某个老版本，而且没有条件更新到最新版本。 这时候，你如何在本地构建一个老版本的软件，并试图重现那个问题？

answer: 

场景一：

        1.创建演示分支：
从主分支（假设是master）创建一个新的分支用于演示版本的开发。

        2.在演示分支上修改代码：
在demo-branch分支上进行演示所需的临时修改。

        3.保存修改并提交：
完成修改后，使用git add和git commit命令保存并提交这些更改。

        4.演示后的合并：
演示结束后，需要决定哪些修改应该合并回主分支。可以通过创建一个合并请求（merge request）或使用git merge或git cherry-pick命令来实现。

        5.删除或保留演示分支：
合并完成后，可以选择保留或删除demo-branch分支，取决于是否还需要这个分支作为历史记录或将来可能还需要的参考。

场景二：

        1.找到老版本的提交：
首先，需要确定用户报告问题时的软件版本对应的Git提交。这可以通过查看版本历史或使用标签（tag）来实现。

        2.检出老版本的代码：
使用git checkout命令检出对应提交的代码。

        3.构建和测试老版本软件：
在检出的老版本代码基础上，按照正常的构建流程构建软件，并尝试重现用户报告的问题。

        4.修复问题并合并到主分支：
如果在老版本中找到了问题并修复了它，可能需要将这个修复合并回主分支。这通常涉及到创建一个新的分支来修复问题，然后将这个修复合并回主分支。

question8：

        一个源文件，如何知道它的每一行都是什么时候签入的，为了什么目的签入的 （解决了哪个任务，或者哪个bug）？

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

answer: 

        要确定一个源文件每一行的签入时间、签入目的以及解决了哪个任务或bug，通常需要使用版本控制系统（如Git、SVN等）。这些系统记录了文件的每一次变更，包括变更的时间、变更者以及变更的内容，有时还包括变更的描述（commit message），描述中可能会注明此次变更的目的或解决的bug。
（1）使用版本控制系统查询历史：
（2）打开命令行或版本控制软件的图形界面。
（3）导航到包含源文件的仓库目录。
（4）使用git log（对于Git）或相应的命令来查看文件的提交历史。
（5）使用git blame（Git）命令来查看每行代码的最后修改者和时间。
（6）分析commit message：这些消息通常由开发者在提交代码时编写，用于说明变更的原因和目的。如果message中提到了特定的任务编号或bug编号，可以在项目管理工具（如Jira、Bugzilla等）中查找更多详细信息。
（7）审查代码变更：查看问题代码行前后的变更记录，理解其上下文和修改逻辑。如果变更与某个功能或修复相关，可以查阅相关的设计文档、测试用例或bug报告，以更深入地了解代码修改的初衷。
（8）考虑测试的影响：在修改代码之前，评估修改可能对其他模块或功能产生的影响。可以编写或运行测试用例来验证修改的正确性，并确保没有引入新的问题。
（9）与团队沟通：如果对代码的修改历史或目的仍有疑问，可以与之前的开发者或团队成员沟通，了解他们的意图和经验。
（10）谨慎修改：在修改代码时，务必谨慎行事，确保理解代码的功能和逻辑。先在开发环境中进行测试，确保修改没有引入新的问题。
（11）提交新的commit：在修改代码并经过充分测试后，提交一个新的commit，并编写清晰的commit message，说明修改的原因、目的以及可能的影响。
（12）持续监控：修改代码并提交后，持续监控软件的运行情况，确保修改没有引入新的问题或导致其他模块崩溃。

question9：

        如何给一个系统的所有源文件都打上标签，这样别人可以同步所有有这个标签的文件版本？

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

answer: 

        1.确保代码已经提交到版本控制系统：
        在Git中，确保已经将当前的代码状态通过git commit命令提交到本地仓库。

        2.打标签：
        使用git tag命令为当前的提交打上标签

question10：

        你的项目的源代码和测试这些代码的单元测试，以及其他测试脚本都是放在一起的么？ 修改源代码会确保相应的测试也更新么？你的团队是否能部署自动构建的任务？

    在签入之前，程序员能否自动在自己的机器上运行自动测试，以保证本地修改不会影响整个软件的质量？

    在程序员提交签入之后，服务器上是否有自动测试程序， 完成编译，测试，如果成功，就签入，否则，就取消签入？

    团队是否配置了服务器，它自动同步所有文件，自动构建，自动运行相关的单元测试，碰到错误能自动发邮件给团队

answer: 

        通常，最佳实践是将源代码与测试脚本（包括单元测试和其他类型的测试）分开存放，但又在逻辑上保持紧密的联系。例如，可以将测试脚本放在与相应源代码相同的目录下，或者有一个专门的测试目录来存放所有测试脚本。
这样的组织方式有助于维护代码的清晰性和可维护性，同时使得测试与代码之间的对应关系一目了然。

question11：

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

answer: 

GitHub

    优点：
        全球最大的代码托管平台，拥有庞大的社区和丰富的代码库。
        提供了强大的版本控制功能，支持分支、合并请求等。
        易于协作，支持多人同时编辑和审查代码。
        提供了许多有用的插件和扩展，增强了功能性和灵活性。

    缺点：
        私有项目需要付费，对小型团队或个人用户可能成本较高。
        在某些地区，访问速度可能较慢。
        团队管理权限设置可能不够灵活。

    成本：私有项目需要支付一定费用，但开源项目可以免费托管。

Gitee

    优点：
        针对中国用户，访问速度快，稳定性好。
        提供了与GitHub相似的功能，易于上手。
        支持私有项目，且价格相对较为亲民。
        与国内开发者社区联系紧密，适合国内团队协作。

    缺点：
        国际影响力相对较小，社区规模可能不如GitHub。
        功能和插件可能不如GitHub丰富。

    成本：私有项目需要付费，但价格相对较低。

Coding.net

    优点：
        支持多种编程语言和框架，适合不同技术栈的团队。
        提供了在线代码编辑和运行功能，方便开发者快速验证代码。
        团队管理功能较为完善，可以满足团队不同角色的需求。

    缺点：
        与GitHub和Gitee相比，社区规模和影响力较小。
        某些高级功能可能需要付费。

    成本：部分高级功能需要付费，但基本功能对免费用户也开放。

question12：

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

answer: 

        安全性有待增强： 数据加密：学生请假管理系统可能涉及个人隐私信息，如学生姓名、联系方式等。为了提高数据安全性，建议对敏感数据进行加密存储和传输，防止数据泄露或被非法访问。 权限控制：不同用户类型在系统中的权限应有明确的划分和限制。建议加强权限控制机制，确保每个用户只能访问其权限范围内的数据和功能，防止非法操作和数据篡改。

question13：

     考虑下面的软件需求：

•手机英语背单词软件，用户可以选择单词本的类型（四级，六级，GRE，等），每天背单词的进度。

•可以和好友分享自己背单词的进度。还可以挑战好友，挑选20个单词，送给好友，让好友选择正确的解释，并把成绩自动分享回来。

•假设有微博/微信/email 可以确定用户的身份

•假设有服务器可以返回 【中文 – 英语单词】的对应关系

使用思维导图做出草图

answer: 

小组成员作业

姓名	文章链接
陈瑜红	学生请假管理系统用例图-CSDN博客
卢思涛	http://t.csdnimg.cn/5WdjY
刘文齐	http://t.csdnimg.cn/1YuSw
郭丽珠	【个人作业】学生请假管理系统-用例设计-CSDN博客
郑昀昀	系统分析与设计【随堂练习】：学生请假系统的用例及用例图-CSDN博客
陈幼君	作业：学生请假管理系统-用例及用例图-CSDN博客