按顺序回答文件中还有没被回答的问题

### 文件中尚未回答的问题：

#### 9. 分析判断
**有人认为：“直到程序开始运行，才能评估其质量。”这句话对吗？**
- **答：** 不完全正确。虽然程序运行后可以进行全面的质量评估，但在此之前也有很多方法可以在开发过程中提前评估软件质量。例如：
- **静态代码分析**：通过工具检查代码的语法、格式和潜在错误。
- **代码审查**：团队成员互相审查代码，发现潜在问题。
- **单元测试**：编写单元测试用例，确保每个模块的功能正确。
- **设计审查**：在设计阶段进行审查，确保设计的合理性。
- **需求验证**：确保需求的明确性和完整性。

**结合教科书中软件神话一部分提供的资料以及关于软件危机的思考，谈谈你对质量评估的看法。**
- **答：** 软件开发中的质量评估不应仅限于程序运行后，而应贯穿整个开发过程。早期的质量评估可以显著减少后期的返工和维护成本。软件神话中提到的很多问题，如需求不明确、开发进度难以控制等，都可以通过早期的质量评估和持续的验证来缓解。因此，全面的质量评估应该是多层次、多阶段的，包括但不限于需求分析、设计、编码、测试和维护等各个阶段。

#### 14. 原型开发
**经该过程得到的一个“可运行的原型”时，它可以发布吗？还是应该抛弃？为什么？**
- **答：** 可运行的原型通常不应该直接发布，而是作为进一步开发的参考和验证工具。原因是：
- **原型的目的**：原型主要用于验证需求和技术可行性，而不是作为一个成熟的产品。
- **质量和稳定性**：原型往往缺乏全面的测试和优化，可能存在性能问题和安全隐患。
- **用户反馈**：原型可以用来收集用户反馈，进一步完善需求和设计。
- **迭代开发**：原型的成功与否可以帮助团队决定下一步的方向，但正式发布前需要进行更多的开发和测试。

#### 15. 敏捷软件开发宣言
**请多读几遍“敏捷软件开发宣言”，并通过实践感受和思考。**
- **答：** 敏捷软件开发宣言的核心价值观和原则包括：
- **个体和互动高于流程和工具**：强调人的作用和团队合作的重要性。
- **可工作的软件高于详尽的文档**：重视实际成果，减少不必要的文档工作。
- **客户合作高于合同谈判**：与客户的紧密合作，确保需求的准确性和及时调整。
- **响应变化高于遵循计划**：灵活应对变化，快速调整开发方向。

通过实践，我感受到敏捷开发的优势在于提高了团队的灵活性和响应速度，减少了不必要的 bureaucracy，提升了客户满意度。然而，敏捷开发也需要团队成员的高度自律和良好的沟通能力。

#### 16. 极限编程过程
**XP有哪些关键性的活动？在活动执行过程中，它强调什么？遵循什么？鼓励什么？**
- **答：** 极限编程（XP）的关键活动及其强调和遵循的原则包括：
- **客户参与**：客户全程参与，确保需求的准确性和及时反馈。
- **小步快跑**：短周期的迭代开发，快速交付可工作的软件。
- **持续集成**：频繁地集成代码，确保代码的稳定性和质量。
- **结对编程**：两人一组共同编写代码，提高代码质量和团队协作。
- **测试驱动开发**：先编写测试用例，再编写代码，确保代码的正确性。
- **重构**：定期重构代码，提高代码的可维护性和可扩展性。
- **简单设计**：追求最简单的解决方案，避免过度设计。

**强调**：快速反馈、持续改进、高度透明。
**遵循**：敏捷开发原则、持续交付、客户价值最大化。
**鼓励**：团队合作、个人成长、创新思维。

#### 18. 需求工程的7项职责
**Seven distinct requirements engineering functions—（起始Inception），（导 出 Elicitation ） ， （精化 Elaboration ）,(协商 Negotiation),(规格说明Specification),(确认Validation), and(需求管理Requirements management)—are conducted by members of the software team.**
- **答：** 需求工程的7项职责包括：
- **起始（Inception）**：确定项目的基本目标和范围，初步评估项目的可行性。
- **导出（Elicitation）**：通过与利益相关者的沟通，收集和记录需求。
- **精化（Elaboration）**：详细分析和整理收集到的需求，确保需求的完整性和一致性。
- **协商（Negotiation）**：与利益相关者协商，解决需求冲突，达成共识。
- **规格说明（Specification）**：将需求转化为正式的文档，确保需求的明确性和可验证性。
- **确认（Validation）**：验证需求的正确性和可行性，确保需求符合实际需求。
- **需求管理（Requirements Management）**：管理和控制需求的变化，确保需求在整个开发过程中的稳定性。

#### 21. 识别利益相关者，并向其收集信息
**1. 找出A公司开发“公交站牌项目”的利益相关者**
- **答：**
- **公交集团**：项目发起方，提供资金和支持。
- **B公司**：提供实时公交到站信息的服务器供应商。
- **市民**：使用公交站牌的乘客，受益于实时报站信息。
- **政府交通部门**：监管公共交通，确保服务质量。
- **公交司机**：提供公交服务，间接影响站牌信息的准确性。
- **广告商**：可能在站牌上投放广告，提供额外收入。

**2. 调研访谈前，请为其准备一张问题清单**
- **答：**
- **公交集团**：
- 项目的预算和时间安排？
- 对站牌功能的具体要求？
- 如何确保信息的实时性和准确性？
- **B公司**：
- 提供的数据格式和频率？
- 数据传输的安全性和可靠性？
- 技术支持和服务？
- **市民**：
- 最关心的站牌功能有哪些？
- 是否有其他特殊需求？
- 对现有站牌的改进建议？
- **政府交通部门**：
- 对公共交通服务的要求和标准？
- 如何监督项目的进展？
- 对站牌外观和功能的意见？
- **公交司机**：
- 在日常运营中遇到的问题？
- 对站牌信息的期望？
- **广告商**：
- 广告投放的需求和限制？
- 广告内容的审核标准？

#### 23. 质量功能部署
**质量功能部署（QFD）是一种将客户要求转换为软件技术需求的质量管理技术。请思考这一技术对于软件开发的影响。**
- **答：** QFD对软件开发的影响包括：
- **提高客户满意度**：通过将客户需求转化为具体的技术需求，确保软件功能符合用户期望。
- **减少返工**：在开发早期明确需求，减少因需求变更导致的返工。
- **优化设计**：通过对客户需求的详细分析，优化软件设计，提高软件的可维护性和可扩展性。
- **增强团队协作**：跨部门协作，确保各部门对需求有统一的认识。
- **提高产品质量**：通过系统化的质量管理方法，确保软件质量达到预期标准。

#### 24. 上下文建模
**阅读教材中“Architectural Design”部分内容，总结建立上下文的方法。**
- **答：** 建立上下文的方法包括：
- **定义系统边界**：明确系统的输入和输出，确定系统与外部环境的交互点。
- **识别外部实体**：列出与系统交互的外部实体，如用户、其他系统、数据库等。
- **绘制上下文图**：使用图形表示系统的外部实体和系统之间的关系。
- **描述交互**：详细描述系统与外部实体之间的数据流动和交互过程。
- **定义接口**：明确系统与外部实体之间的接口，包括数据格式和通信协议。

#### 25. 阅读材料，分析系统行为，可视化为用例图
**材料：经沟通得到了一份需求说明，它是关于“一个企业的生产销售系统”的功能需求，文字表述如下：**
- **答：** 用例图如下：
- **系统管理员**：
- 管理系统基础功能
- **生产商**：
- 存储产品生产信息
- **业务员**：
- 管理销售情况
- **物流公司**：
- 提供产品使用反馈
- **银行**：
- 管理产品销售情况

  +----------------+
  | 生产销售系统   |
  +----------------+
            ^
            |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+    +----------------+
  | 系统管理员     |        | 生产商         |       | 业务员         |      | 物流公司       |     | 零售商         |    | 用户           |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+    +----------------+
  | - 管理系统基础功能 |    | - 存储产品生产信息 |   | - 提供产品使用反馈 |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+    +----------------+

  +----------------+
  | 银行           |
  +----------------+
  | - 管理产品销售情况 |
  +----------------+

#### 26. 阅读下面的用例图，运用给出的2种用例模板规格化其中之一的用例。
**用例名：Withdraw Funds [取款]**
- **答：** 用例规格化如下：
- **用例名称**：取款
- **主参与者**：客户
- **前置条件**：
- 客户已插入银行卡并输入正确的PIN码。
- **后置条件**：
- 客户成功取出所需金额。
- 账户余额相应减少。
- **主场景**：
1. 客户选择取款选项。
2. 系统提示客户输入取款金额。
3. 客户输入取款金额。
4. 系统验证账户余额是否充足。
5. 如果余额充足，系统吐出现金。
6. 系统更新账户余额。
7. 系统打印交易凭条。
- **异常场景**：
1. 如果余额不足，系统显示余额不足信息。
2. 如果客户输入的金额超过每日限额，系统显示超出限额信息。

#### 29. 向利益相关者收集需求的手段有哪些？怎样从收集的一手需求信息中导出功能性需求和非功能性需求？
**比如，给出这样一段材料，同学们能从中识别出非功能性需求吗？它是关于什么的非功能性需求，Modifiability？Usability?还是什么？请陈述识别的过程，并陈述该需求。**
- **答：** 收集需求的手段包括：
- **访谈**：与利益相关者进行一对一或多对一的访谈。
- **问卷调查**：通过问卷收集大量用户的意见和需求。
- **观察**：现场观察用户使用现有系统的操作。
- **头脑风暴**：团队成员一起讨论和提出需求。
- **用户故事**：通过用户故事的形式收集用户的需求。

**识别非功能性需求的过程**：
- **分析材料**：逐字逐句分析材料，寻找与性能、安全性、可用性等相关的描述。
- **分类**：将识别到的需求归类为功能性需求或非功能性需求。
- **验证**：与利益相关者确认识别的需求是否准确。

**示例**：
- **材料**：系统必须能够在1秒内响应用户的请求。
- **识别**：这是一个性能需求，属于非功能性需求。
- **分类**：Performance
- **验证**：与利益相关者确认1秒的响应时间是否合理。

#### 30. 请阅读下列一段材料，同学们能从中识别出功能性需求吗？陈述你是如何识别的？列出识别的功能性需求，并为其建立用例图。
- **答：** 材料如下：
- **系统必须能够**：
- 管理用户账号。
- 查询用户信息。
- 更新用户信息。
- 删除用户信息。
- 添加新产品。
- 修改产品信息。
- 删除产品信息。
- 查看订单状态。
- 创建订单。
- 取消订单。

**识别过程**：
- **关键词提取**：提取动词和名词组合，如“管理用户账号”、“查询用户信息”等。
- **分类**：将提取到的需求归类为功能性需求。
- **验证**：与利益相关者确认识别的需求是否准确。

**功能性需求**：
- 管理用户账号
- 查询用户信息
- 更新用户信息
- 删除用户信息
- 添加新产品
- 修改产品信息
- 删除产品信息
- 查看订单状态
- 创建订单
- 取消订单

**用例图**：

  +----------------+
  | 系统           |
  +----------------+
          ^
          |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+
  | 管理员         |        | 用户           |       | 业务员         |      | 客户           |     | 系统管理员     |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+
  | - 管理用户账号  |      | - 查询用户信息  |     | - 查看订单状态  |    | - 创建订单      |   | - 管理系统基础功能 |
  | - 添加新产品    |      | - 更新用户信息  |     | - 创建订单      |    | - 取消订单      |   |                 |
  | - 修改产品信息  |      | - 删除用户信息  |     | - 取消订单      |    |                 |   |                 |
  | - 删除产品信息  |      |                 |     |                 |    |                 |   |                 |
  +----------------+        +----------------+       +----------------+      +----------------+     +----------------+

#### 31. 如何建模生成用例图？下面给出一段“用户故事”材料，请同学们从中导出功能性需求，并为其生成用例图。之后，请自行总结“导出功能性需求并建模生成用例图的方法”。
**用户故事材料**：
- **一个顾客打电话给电影院，想要订两个座位看今晚的 The Shawshank Redemption（《肖申克的救赎》）。电影院员工开始使用订票系统来寻找和保留座位。期间涉及场次时间和座位的选择。**

- **答：**
- **功能性需求**：
- 顾客可以预订座位。
- 电影院员工可以查看场次信息。
- 电影院员工可以选择座位。
- 电影院员工可以输入顾客信息。
- 系统可以保留座位。

**用例图**：

  +----------------+
  | 电影订票系统   |
  +----------------+
          ^
          |
  +----------------+        +----------------+
  | 顾客           |        | 电影院员工     |
  +----------------+        +----------------+
  | - 预订座位     |      | - 查看场次信息  |
  |                |      | - 选择座位      |
  |                |      | - 输入顾客信息  |
  +--+

**总结方法**：
- **提取动词和名词**：从用户故事中提取动词和名词组合，如“预订座位”、“查看场次信息”等。
- **分类**：将提取到的需求归类为功能性需求。
- **绘制用例图**：使用UML用例图表示参与者和用例的关系。

#### 33. 如何生成活动图？下面给出一段材料，请同学们为其生成活动图。之后，请自行总结“生成活动图的方法”。
**材料**：
- **系统管理员能够进行系统基础功能管理**：系统管理员可以添加、删除和修改用户账号，管理权限，备份和恢复数据。

- **答：**
- **活动图**：

    +---------------------+
    | 系统基础功能管理     |
    +---------------------+
             |
             v
    +---------------------+
    | 添加用户账号         |
    +---------------------+
             |
             v
    +---------------------+
    | 删除用户账号         |
    +-------+
    | 修改用户账号         |
    +---------------------+
             |
             v
    +---------------------+
    | 管理权限            |
    +---------------------+
             |
             v
    +--+
             |
             v
    +---------------------+
    | 恢复数据            |
    +---------------------+

**总结方法**：
- **识别活动**：从材料中提取主要活动，如“添加用户账号”、“删除用户账号”等。
- **确定顺序**：确定活动的执行顺序，使用箭头表示。
- **绘制活动图**：使用UML活动图表示活动的流程。

#### 34. 下面给出一段材料，请同学们详述其中的非简单步骤4，即详述软件内部运作的细节——软件内部各个对象之间是如何协作来完成这一步的任务的。之后，请自行总结“如何运用GRASP详述非简单步骤的方法”。
**材料**：
- **系统管理员能够进行系统基础功能管理**：系统管理员可以添加、删除和修改用户账号，管理权限，备份和恢复数据。

- **答：**
- **非简单步骤4：管理权限**：
1. **系统管理员选择管理权限选项**。
2. **系统显示所有用户列表**。
3. **系统管理员选择一个用户**。
4. **系统显示该用户的权限列表**。
5. **系统管理员选择要修改的权限**。
6. **系统管理员选择新的权限级别**。
7. **系统更新用户权限**。
8. **系统显示更新成功的消息**。

**GRASP方法**：
- **应用GRASP**：
- **信息专家**：系统管理员是信息专家，负责管理权限。
- **控制者**：系统管理员是控制者，负责选择用户和权限。
- **创建者**：系统负责创建和更新权限记录。
- **低耦合**：系统管理员与用户权限管理模块解耦，通过接口进行交互。
- **高内聚**：用户权限管理模块内部高度内聚，专注于权限管理。

**总结方法**：
- **分解步骤**：将复杂的步骤分解为多个小步骤。
- **应用GRASP**：根据GRASP原则确定每个步骤的责任分配。
- **详细描述**：详细描述每个步骤的具体操作和对象之间的交互。

#### 35. 下面给出一段材料，请同学们为其生成顺序图。之后，请自行总结“生成顺序图的方法”。
**材料**：
- **系统管理员能够进行系统基础功能管理**：系统管理员可以添加、删除和修改用户账号，管理权限，备份和恢复数据。

- **答：**
- **顺序图**：

    +---------------------+
    | 系统管理员          |
    +--+
    | 系统               |
    +---------------------+
             |
             v
    +---------------------+
    | 用户管理模块        |
    +---------------------+
             |
             v
    +---------------------+
    | 权限管理模块        |
    +--+
    | 数据库              |
    +---------------------+
    
    1. 系统管理员选择管理权限选项
    2. 系统调用用户管理模块获取用户列表
    3. 用户管理模块从数据库获取用户列表
    4. 用户管理模块返回用户列表给系统
    5. 系统显示用户列表
    6. 系统管理员选择一个用户
    7. 系统调用权限管理模块获取权限列表
    8. 权限管理模块从数据库获取权限列表
    9. 权限管理模块返回权限列表给系统
    10. 系统显示权限列表
    11. 系统管理员选择要修改的权限
    12. 系统管理员选择新的权限级别
    13. 系统调用权限管理模块更新权限
    14. 权限管理模块更新数据库中的权限记录
    15. 权限管理模块返回更新结果给系统
    16. 系统显示更新成功的消息

**总结方法**：
- **识别参与者**：确定参与交互的对象，如系统管理员、系统、用户管理模块、权限管理模块、数据库。
- **确定消息传递**：确定每个对象之间的消息传递顺序。
- **绘制顺序图**：使用UML顺序图表示对象之间的交互过程。

#### 36. 评估下面的顺序图，找出问题，说明问题是什么，问题存在会导致什么后果，说明改进的目标（要求），然后解决，给出解决结果。
- **答：**
- **问题**：
- **重复调用**：`isAvailable()` 和 `setAvailable()` 方法多次调用，增加了代码冗余。
- **缺少异常处理**：没有处理书籍不可用的情况，可能导致系统崩溃或用户体验不佳。
- **耦合度过高**：`checkout` 方法与 `isAvailable()` 和 `setAvailable()` 方法耦合度过高。

- **后果**：
- **代码冗余**：增加代码维护难度。
- **系统健壮性差**：缺少异常处理，可能导致系统崩溃。
- **耦合度过高**：代码不易扩展和维护。

- **改进目标**：
- **减少代码冗余**：避免重复调用相同的方法。
- **增加异常处理**：处理书籍不可用的情况，提供友好的用户提示。
- **降低耦合度**：减少方法之间的直接调用，