软件开发中的用户参与与架构设计-优快云博客

15、让用户密切参与软件开发团队存在的一个问题是他们会“入乡随俗”。也就是说，他们会采用开发团队的观点，而忽视其用户同事的需求。请提出三种避免这个问题的方法，并讨论每种方法的优缺点。

以下是三种避免用户“入乡随俗”问题的方法及相应优缺点：

定期轮换用户代表
- 方法：安排不同的用户代表在不同时间段参与软件开发团队，避免同一用户长期与开发团队接触。
- 优点：
- 新的用户代表能带来新的视角和最新的用户需求信息，减少用户代表被开发团队同化的可能性。
- 不同用户代表的轮换可以让更多用户参与到项目中，增强用户群体对项目的整体参与感和认同感。
- 缺点：
- 频繁更换用户代表可能导致沟通成本增加，新的用户代表需要时间来了解项目的进展和背景，可能会影响项目的推进效率。
- 不同用户代表之间的需求理解和表达可能存在差异，这可能会让开发团队感到困惑，增加协调的难度。
建立用户反馈机制
- 方法：设立专门的渠道，如定期的用户调查、用户论坛、反馈邮箱等，让用户同事能够直接向参与开发团队的用户代表反馈需求和意见。同时，要求用户代表定期向用户群体汇报项目进展。
- 优点：
- 确保用户代表能够及时了解到用户同事的最新需求和意见，保持与用户群体的紧密联系。
- 通过透明的项目进展汇报，增强用户群体对项目的信任，也能让用户代表时刻牢记自己代表用户群体的职责。
- 缺点：
- 大量的用户反馈可能会让用户代表应接不暇，难以有效筛选和处理有价值的信息。
- 用户反馈可能存在主观性和分散性，难以形成统一明确的需求，增加了需求管理的难度。
开展用户培训和教育
- 方法：为参与开发团队的用户代表提供关于用户需求分析、用户体验设计等方面的培训，让他们具备专业的知识和技能，能够更好地理解和代表用户同事的需求。同时，向开发团队介绍用户群体的特点和需求。
- 优点：
- 提高用户代表的专业素养，使其能够更准确地把握用户需求，在与开发团队合作时更有自信和能力坚持用户的立场。
- 增强开发团队对用户需求的理解，促进开发团队和用户代表之间的有效沟通和协作。
- 缺点：
- 培训需要投入时间和资源，包括培训师资、培训场地和培训时间等，可能会增加项目的成本。
- 培训效果可能因个人差异而有所不同，部分用户代表可能无法完全掌握所学知识和技能，影响方法的实施效果。

16、为票务发行系统编写一组非功能性需求，明确其预期的可靠性和响应时间。

以下是为票务发行系统编写的一组非功能性需求，涵盖了预期的可靠性和响应时间：

可靠性

平均无故障时间（MTTF） ：票务发行系统的平均无故障时间应不少于 5000 小时。这意味着系统在正常运行条件下，平均连续工作 5000 小时才会出现一次故障。
故障恢复时间 ：当系统发生故障时，应能在 30 分钟内恢复正常运行。包括硬件故障、软件崩溃或网络中断等情况，确保系统能够快速恢复服务，减少对用户的影响。
数据完整性 ：在任何情况下，系统的数据完整性都应得到保证。数据丢失或损坏的概率应低于 0.01%。例如，在系统崩溃或异常关机后，重新启动时票务数据、用户信息等应保持完整，无丢失或错误。
可用性 ：系统的可用性应达到 99.9% 以上。这意味着在一年的时间里，系统的不可用时间应不超过 8.76 小时，确保用户在大多数时间都能正常使用票务发行服务。

响应时间

用户请求响应时间 ：当用户发起票务查询、预订或购买请求时，系统应在 3 秒内给出响应。对于简单的查询请求，如查询某一车次或航班的余票信息，应在 1 秒内返回结果。
批量处理响应时间 ：当进行批量票务处理时，如批量出票或批量退票，系统应在 10 分钟内完成处理并给出结果。确保在高峰时段或大规模业务操作时，系统仍能高效处理任务。
系统界面加载时间 ：系统的各个界面，如票务查询界面、预订界面、支付界面等，应在 2 秒内完成加载。提供流畅的用户体验，减少用户等待时间。

这些非功能性需求可以帮助确保票务发行系统的可靠性和响应时间满足用户的期望，提高系统的性能和用户满意度。在系统开发和测试过程中，可以根据这些需求进行针对性的设计和验证。

17、对于Mentcare系统，提出一组用例，说明看诊并开药和制定治疗方案的医生与Mentcare系统之间的交互。

以下是一组关于医生与Mentcare系统交互的用例：

查看患者记录
医生可以登录系统，从患者列表中选择特定患者，系统将显示该患者的基本信息、病史、之前的诊断结果、检查报告等。例如，医生在接待新患者时，先通过系统查看其过往病史，以便更好地进行诊断。
设置会诊
医生可以发起会诊，通过下拉菜单选择在线的其他医生，使不同办公室的医生能够同时查看同一患者的记录。在会诊过程中，只有发起医生可以编辑记录，同时系统提供文本聊天窗口方便医生之间协调