软件工程过程 - 期末复习

软件工程过程 - 期末复习

第1章 绪论

1. 主过程，支持过程和辅助过程

• 主过程：定义了与软件生产直接相关的过程，即软件从无到有到运营的过程，这些过程叫主过程。这些过程包括获取，供应，开发，运行和维护。

  • 获取过程
  • 供应过程
  • 开发过程
    • 需求分析
    • 系统设计
    • 编码
    • 测试
    • 安装及验收
  • 运行过程
  • 维护过程

• 支持过程：为了保证主过程的正常运行，目标的实现和质量的提高所从事的一系列活动。他们可被主过程的各个过程部分或全部采用，并由使用他们的组织或一个独立组织负责实施，也可由用户负责实施。这些过程包括文档、配置管理、质量保证、验证、确认、联合评审、审核、问题解决。

  • 文档过程
  • 配置管理过程
  • 质量保证过程
  • 验证过程
  • 确认过程
  • 联合评审过程
  • 审核过程
    • 审核一般采用独立的形式对产品以及所采用的过程加以判断、评估，并按项目计划中的规定，在预先确定的里程碑（代码完成日、代码冻结日和软件发布日等）之前进行，审核中出现的问题应加以记录，并按要求输入问题解决过程。
  • 问题解决过程
• 辅助过程：辅助过程是形成一个组织项目运作的环境，如管理、基础设施、改进和培训
  • 管理过程
    • 项目管理
    • 质量管理
      • 技术层次 - 数据，编程，文档
      • 方法体系层次 - 措施，项目，过程
      • 社会因素层次 - 质量环境，技术标准，业务标准，人员
    • 风险管理
  • 基础设施过程
  • 培训过程
  • 改进过程

2. 问题域、解系统和共享现象的含义以及三者的关系

https://wenku.baidu.com/view/0c956240571252d380eb6294dd88d0d233d43cf6.html

• 问题域
  • 问题的发生地，问题的发生范围及解决问题必须涉及的事件或事物
• 解系统
  • 软件系统通过影响问题域帮助人们解决问题被称为解系统
• 共享现象
  • 解系统可以对问题域进行模拟的现象称为共享现象
• 共享现象是解系统所模拟的问题域的部分，该部分在两个系统中同时存在。除了共享现象外，问题域还有一些没有被解系统模拟的知识，因为在现实世界非常复杂，不可能也没必要在解系统中完全重现。除了包含共享现象的知识模型之外，解系统也有一些并非来自于现实模拟的特性，例如数据库管理系统的选择，模型的规范化，索引的建立，这些因素并不对应于问题域知识，却是解系统必不可少的部分

第2章 软件开发的主要活动

2.1 需求分析与管理

• 需求分析与规范：需求分析的目标是形成对软件产品所需功能、接口和性能要求的完整并经过确认的需求规格说明书
  • 系统需求分析： 因为软件总是大系统的一个部分，因此必须从建立整个系统所有元素的需求工作开始，然后才能确定一些软件子系统的需求。当软件必须与系统的其他元素(如硬件、人和数据库等)接口时，这种系统的考察工作就显得非常重要。系统需求分析主要围绕系统级需求的聚集和少量顶层分析和设计展开
  • 软件需求分析：软件需求的聚集过程是逐条确定的。为了弄清所编写程序的性质，软件人员必须了解软件的信息与及所要求的的功能、性能和接口。
• 解释软件工程和系统工程之间的联系，这种联系对需求工程的工作有什么影响
  • 需求工程的需求分析包括系统需求分析和软件需求分析
  • 系统需求分析
    • 主要围绕系统级需求的聚集和少量顶层分析和设计展开。在实际软件开发中，必须从整个系统所有元素的需求工作开始，然后才能确定一些软件子系统的需求
    • 可以说，系统需求分析是软件需求分析的前提
    • 当软件必须与系统其它元素（如人，硬件和数据库）接口时，这种系统的考察工作就显得非常重要
  • 软件需求分析
    • 是具体软件子系统的需求分析
  • 因此，系统工程包括软件工程，软件工程是系统工程的细化体现，这种联系为需求工程的实行提供了完整的思路
• 需求变更管理
• 需求跟踪管理

2.2 设计

• 确定4种程序属性：软件体系结构，数据结构，过程细节，接口性质
• 高层设计
• 详细设计
• 软件设计也要文档化，并作为软件配置管理的一部分

2.3 编码

• 模块的编码和单元测试交替进行
• 软件一旦构造出来就应及时纳入配置管理，将构造出的新模块/对象和重用的模块/对象组成一个版本，以便有任何改变需重新进行测试时方便处理

2.4 软件测试

• 测试工作包括的活动
  • 制定测试计划
  • 编写测试用例
  • 准备测试环境
  • 执行测试用例
  • 测试结果分析
• 4种层次的测试：
  • 单元测试
  • 集成测试
  • 系统测试
  • 验收测试

2.5 运行与维护

2.6 软件项目管理

• 风险管理
  • 软件估算风险
  • 商业影响风险
  • 客户相关风险
  • 开发技术风险
  • 开发环境风险
  • 开发人员风险
  • 过程相关风险
• 风险管理包括哪些活动
  • 风险识别
  • 风险分析
  • 风险评估
  • 风险监控

2.7 软件配置管理

• 简述开发过程和配置管理过程的关系

  • 软件配置管理贯穿整个软件开发过程，其主要任务是每当有了更改，与其相关的软件配置项均得到正确处理，使新版本软件无内部冲突

  • 配置管理活动穿插在软件开发过程中，当软件开发过程中生成了新的软件制品，即配置项时，应首先进行评审，被批准的配置项连同其相关信息被保存，即检入到软件版本库，从此成为受控的配置项；
  • 同时“执行变更”，更新软件配置库中现存的原版本，生成更新后的版本，并保存到配置库中。此后在开发过程中使用的相关配置项，与配置库中的信息保持一致。
  • 若在软件开发过程中，需要对受控的配置项进行修改，则首先需要提出变更请求，被“授权变更”后，才能“执行变更”。
  • 配置审计活动则不定期或定期地监控配置库的管理状况。
• 软件配置项
  • 操作概念
  • 需求规格说明
  • 设计文档
  • 源代码
  • 目标代码
  • 测试计划
  • 测试用例、测试配置和测试结果
  • 维护和开发工具
  • 用户手册
  • 维护手册
  • 接口控制文档
• 基线：经过正式评审和认可的一组软件配置项，此后它们将作为下一步开发工作的基础，只有通过正式的变更控制流程才能被更改
  • 作用：把各阶段的工作划分得更加明确，使本来连续的工作在这些点上断开，以便于验证和确认开发成果。
  • 基线可为软件制品提供三种能力：
    • 再生能力：能够返回到过去的版本
    • 可追踪能力
    • 报告能力
  • 确定典型基线数目与类型的主要决定因素是软件开发项目使用的生存周期模型

2.8 验证与确认V&V【verification&validation】

• verification&validation
  • 开发者角度(Producer view) - verification验证
  • 客户角度(Consumer view) - validation确认

2.9 软件质量保证 SQA

• SQA与V&V的关系
  • 相同点：
    • 两者的目标都是监控项目和产品，确保客户得到符合质量标准的产品
  • 不同点：它们从不同的角度来实现这个相同的目标
    • SQA：是一种内部的方法，主要处理标准的符合问题和产品流的符合问题。SQA并不评估软件本身是否符合技术规范，包括安全、保密和质量属性等，也不评估功能和性能需求。
    • V&V：关注一个项目产品的技术属性及其开发过程。V&V为评估一个软件项是否是满足它的技术规范和所期望的使用，提供了详细的工程评价。
  • 如果组织得当，V&V和SQA是可以互补的，几乎没有多少重叠，二者配合可为软件开发工作提供综合的保证程序
• SQA能发挥作用的前提是什么
  • 合理计划SQA过程，其中包括：
    1. 根据项目特征建立一个适合本项目的SQA过程，来监控软件产品及其开发过程，以确保标准、过程相符，确保软件产品、使用标准的缺陷对管理者可见
    2. 确保SQA过程与V&V、联合评审过程和审计过程一致
    3. 开发SQA过程的活动和任务计划，并在整个合同期内实施并维护已文档化的SQA计划
    4. 按计划执行SQA活动和任务
    5. SQA活动和任务记录要符合获取方合同的要求
    6. 负责保证遵守合同的个人应具有组织自由度和资源的调配能力，并具有允许客观评估或发起、影响、处理和验证问题解决的权威性

2.10 软件文档管理

第3章 软件生存周期模型

• 软件生存周期模型：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，其中这些过程、活动和任务覆盖了从该软件的需求定义到系统的使用终止
  • 软件开发过程模型的基本特征
    • 描述了开发的主要阶段
    • 定义了每一个阶段要完成的主要过程和活动
    • 规范了每一个阶段的输入和输出提交物
    • 提供了一个框架，可以把必要的活动映射到该框架中
• 传统软件工程过程模型
  • 编码修正模型
  • 瀑布模型
  • 增量模型
  • 演化模型
  • 螺旋模型
• 现代软件工程过程模型
  • RUP模型
  • 敏捷过程agile process
  • 微软解决方案MSF

3.1 编码修正模型

3.2 瀑布模型

• 需求分析
• 设计
• 编码
• 集成与系统测试
• 运行与维护
• 瀑布模型的6个基本假设是什么
  1. 需求在实施之前就已清楚
  2. 需求没有任何不确定之处
  3. 需求不会发生大幅度的变更
  4. 需求和所有涉众的期待相一致
  5. 实现需求的正确架构能够被良好理解
  6. 有足够的时间按阶段实施开发过程

3.3 增量模型

3.4 演化模型

3.5 螺旋模型

3.9 统一软件过程模型RUP模型

• 主要特点：以用例驱动的、以架构为中心的、风险驱动的迭代和增量的开发过程
• RUP过程框架：
  • 初始
  • 细化
  • 构造
  • 移交
• 8个顶层工作流
  • 管理工作流
  • 环境工作流
  • 配置与变更
  • 业务与需求工作流
  • 设计工作流
  • 实现工作流
  • 测试与评估工作流
  • 部署工作流
• 简述RUP模型是如何体现实体过程模型思想的
  • 回答1
    • 实体过程模型处理的是真实对象，这些对象持续存在，并通过一个相对较小且已定义的状态序列进行进化
    • 在RUP的4个阶段中，管理制品集，需求制品集，设计制品集和实现与实施制品集这4类关键实体都一直存在，它们随过程而不断完善。这4个实体都是一个真实存在的对象，并具有延长的生命周期，它们存在于整个开发过程中，而不是在过程中暂时导入的短暂的对象
  • 回答2
    • 统一过程模型处理的是实体和在实体上进行的活动，每一个实体都是一个真实存在的对象，并具有延长的生命周期
    • 统一过程模型将需求，设计，实现和实施转化为制品集。核心工作流中的各活动不是简单按照线性方式进展，过程中的制品的构造进展也不是单调从一个制品转向另一个制品。相反，活动的焦点应该是反复构建制品。每个制品集都是生存周期某个阶段的主要开发焦点。由于制品集的进展是可跟踪的，这便是EPM/Entity Process Model的体现。
• RUP各阶段里程碑是什么
  • 初始阶段 - 生命周期目标里程碑
  • 细化阶段 - 生存周期构架里程碑
  • 构造阶段- 最初操作性能里程碑
  • 移交阶段 - 产品发布里程碑
• 说明在RUP的四个阶段中，分析与设计工作流的重点有什么不同
  • 初始阶段
    • 主要侧重于关键需求，其次侧重于初始的实施意图，很少侧重于实现（除了可能的语言和商业构件的选择外），而且可能侧重于高层次的架构设计而不是细节设计
  • 细化阶段
  • 需求更加深入，设计集也更加广泛，而且进一步解决了实现和实施问题，这个阶段的活动包括生成一个可执行的原型
  • 构造阶段
    • 主要侧重于设计和实现：在阶段的前期，主要侧重于设计制品的深度；在设计后期阶段，重点是以源代码和个别已测试的构建来实现设计
  • 移交阶段
    • 主要侧重于在其他集的语境中取得实施集的一致性和完整性
• 在RUP模型的4个阶段中，测试工作流任务的重点是什么
  • 初始阶段
    • 评估计划，构想和原型
    • 细化阶段
      • 评估架构
    • 构造阶段
      • 评估中间发布版
    • 移交阶段
      • 评估产品发布版

3.11 本章小结

• 简述软件开发过程模型的发展历程
• 软件开发早期遇到的主要问题是技术问题，因此编码修正模型、瀑布模型、增量模型主要规避的风险是技术风险。瀑布模型作为完整的过程模型首次描述了软件开发中的关键活动。为了规避需求风险出现了演化模型，对风险范围的不断扩充衍生了螺旋模型。螺旋模型的最大贡献是将风险源从需求扩大到软件开发过程中的方方面面，但因其模型的抽象层次过高，使其在实际中难以应用。统一过程模型很好的总结了传统生存周期模型的优势与不足，集结了软件工程实践中的最佳经验，提出了自己的过程模型框架。为了解决可操作性问题，从各阶段、活动、任务和评审等工作涉及的人员、输入、输出、执行流程，到工作制品的参考模型、可利用的工具、指南等事无巨细地一一给出，为各层次参与者提供在线指导。MSF模型对产品级开发活动的组织提供了一种值得借鉴的思路。这些过程为了保证最终提交物的高质量，在支持过程和辅助过程上花了大量资源，使整个过程变得笨重。其明显不适用与快速开发项目，为解决这个问题，敏捷开发模型如极限编程应运而生。
• 请以瀑布模型，增量模型，精益软件开发和敏捷模型为例，谈谈你对软件开发模型的认识

第4章 瀑布模型应用实例 - Infosys过程模型

• Infosys过程各阶段
  • 需求规范
    • 需求分析
    • 产品描述
  • 高层设计
  • 详细设计
  • 构建
  • 单元测试
  • 集成测试计划
  • 集成测试
  • 系统测试计划
  • 系统测试
  • 验收测试
  • 文档化
  • 安装
  • 维护支持
• 高层设计阶段主要包含哪几个方面活动
  • 应用系统的功能结构(以实现的逻辑结构表述)和数据库设计两个方面，确定标准等活动也在并行执行
  • 本阶段主要活动序列
    • 定义相关标准(编码、文档和用户接口等)
    • 确定/设计操作环境的详细资料
    • 进行模块设计
    • 开发物理数据库设计
• 若存在遗留数据，那么在需求分析，高层设计和详细设计阶段应开展哪些与数据迁移有关的工作
  • 需求分析
    • 获取数据迁移需求
  • 高层设计
    • 对遗留数据审计数据模型并更新现有数据模型，确定数据库结构，指定数据迁移计划
  • 详细设计
    • 提前开发和测试数据迁移程序，实现数据迁移细节，保证数据正常存储和使用，亦要确认数据正确性

第6章 软件过程的建立与管理

• 定义一个软件开发过程的基本步骤
  • 确定过程模型
  • 确定活动
  • 确定活动间的关系
  • 文档化每个活动的其他有用信息
  • 文档化如何裁剪过程
  • 文档化如何改善过程
  • 获得过程的买入/过程获得认可并培训员工
  • 不断地使用和改进过程

第7章 敏捷过程模型

• 请从软件价值链，管理软件质量和敏捷心态三方面解释软件开发中采用敏捷过程的必要性
  • 软件价值链
    • 价值链更加透明
    • 提高了生产率；减少“浪费”（不需要的文档，重复工作等）
  • 管理软件质量
    • 随时跟踪项目的状态和进展情况，及早发现问题和风险
    • 快速交付，每次迭代都能交付可运行的软件
    • 项目的每次迭代都有明确的目标
    • 最高风险和最高优先级的需求，最优先进行开发
    • 改善应对变更的能力
  • 敏捷心态
    • 改善项目沟通
    • 更好的客户参与，避免错误的假设
    • 提高客户满意度
    • 改善员工的满意度；拥有更好的团队精神，减少官僚，更够规划和管理自己的工作，减少“恐慌”，稳定的工作量（可持续的步伐）

1. 看板

• 精益制造中限制在制品数量的作用
  • 降低成本
    • 库存减少增加了运营现金的使用率，同时降低管理和仓储开销
  • 缩短交付周期，加速价值流动
    • 消除或缩短产品在工艺间的库存等待，缩短了从开始制造到交付的周期时间
  • 提高制造过程的灵活性
    • 在低库存水平下，调整生产的计划更加容易
  • 暴露系统中的问题
    • 湖水岩石效应使得过去被隐藏的问题，如团队协作不良、需求定义错误等得以显现
• 简述精益软件开发中限制在制品数量的作用
  • 限制在制品数量形成一个与精益制造类似的拉动机制，通过拉动系统可以：
    • 加速价值流动
      • 限制在制品数量，减少了价值项在阶段间的排队等待，缩短了价值从进入系统到交付的时间，加速了端到端的价值流动
    • 暴露问题
      • 限制在制品数量，让湖水岩石效应产生作用。它让过去被隐藏的问题，如团队协作不良，需求定义错误，开发环境低效，资源分配不均衡得以显现
• 五个核心实践
  • 可视化工作（价值）流
    • 产品开发的加工对象“信息”是抽象和不可见的，这提高了价值流的管理难度。通过看板的方式使得价值和价值流可见
  • 显示化流程规则
    • 明确定义和沟通/团队所遵循的流程规则，如价值项的流转规则
  • 限制在制品数量
    • 形成一个与精益制造类似的拉动机制。一个环节有空余的能力（在制品数目未达到上限）时，从上游拉入新的工作，拉动的源头是最下游的交付或客户需求
  • 度量和管理流动
    • 度量为改善价值流动提供方向参考，同时为改善的结果提供反馈，快速流动带来快速的价值产出和快速反馈
  • 协同改进
    • 团队协作，应用科学方法和模型
• 看板是引领变革的方法，看板实施从组织流程现状出发首先可视化实际工作流并显示化流程；在此基础上，限制在制品数量形成拉动系统以暴露系统问题和瓶颈，度量价值流动以发现改进机会；并通过团队的协作，不断改进和演化出合适的流程、方法，实现一个高效、顺畅的产品开发价值流

2. Scrum

• Scrum是一个用于开发和维持复杂产品的框架，是一个增量的、迭代的开发过程

• 在Scrum中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint

• Scrum流程
  • 产品backlog
  • sprint计划会议
  • sprint backlog
  • sprint迭代周期
  • 潜在可交付产品增量
• 3个角色
  • PO产品负责人 - product owner
    • 负责最大化产品以及开发团队工作的价值。管理产品待办事项列表的唯一负责人
  • SM - Scrum Master
    • 确保Scrum被理解并实施，以各种方式服务于产品负责人，服务于开发团队，服务于组织
  • Scrum团队
• 3个工件
  • 产品backlog
    • 使用产品backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事
  • Sprint Backlog
    • sprint计划会议中，scrum团队从产品backlog中挑选最高优先级的需求进行开发。挑选的需求经过讨论、分析和估算得到相应的任务列表，称之为sprint backlog
  • 产品增量Increment
• 5个活动
  • sprint计划会议 - sprint planning meeting
  • 每日站会 - daily scrum meeting
    • 检验sprint目标的进展，做出调整，从而优化下一个sprint的工作价值
  • sprint评审会议 - sprint review meeting
    • 检验发布目标的进展，做出调整，从而优化下一个sprint的工作价值
  • sprint回顾会议 - sprint retrospective meeting
    • 用来回顾已经完成的sprint，并且确定做出什么样的改善可以使接下来的sprint更加高效，更加令人满意，并且工作更快乐
  • 产品backlog梳理会议 - product backlog refinement
• 5个价值
  • 承诺，专注，开放，尊重，勇气
• Scrum三大支柱
  • 透明transparency
  • 检验inspection
  • 适应adaptation

• sprint燃尽图：显示了sprint中累积剩余的工作量

• scrum四大支柱
  • 迭代开发
  • 增量交付
  • 自组织团队
  • 高优先级的需求驱动
• 用户故事：从用户的角度来描述用户渴望得到的功能
  • 三要素
    • 角色：谁要使用这个功能
    • 活动：需要完成什么样的功能
    • 商业价值：为什么需要这个功能，这个功能带来什么样的价值
• 用户故事3C
  • 卡片Card
    • 用户故事一般写在小的卡片上，卡片上可能会写上故事的简短描述，工作量估算等
  • 交谈Conversation
    • 用户故事背后的细节来源于和客户或者产品负责人的交流沟通
  • 确认Confirmation
    • 通过验收测试确认用户故事被正确完成

  故事	答案
  用户可以在XP和linux上运行系统	好故事
  所有绘图和图表将用第三方类库完成	不是好故事，用户不会关心图表是怎么实现的
  用户最多可以撤销50步操作	好故事
  软件将在6月30日发布	不是好故事。这是一个需要在发布计划中考虑的限制条件
  软件将用Java编写	这可能不是一个好故事，但是它依赖于产品。如果产品是一个面向Java程序员的类库，那些用户会比较关心使用的语言
  用户可以从下拉列表框里选择她的国籍	好故事，但可能小了些
  系统将使用Log4J记录所有错误信息到一个文件	不是好故事。不应该指定使用Log4J实现日志功能
  如果用户15分钟内没有保存文档，系统将提示用户进行保存	好故事
  用户可以选择“导出到XML”特性	好故事
  用户可以导出数据到XML文件	好故事

• 六个特性INVEST

  • 独立性independent
    • 要尽可能的让一个用户故事独立于其他的用户故事
  • 可协商性negotiable
    • 一个用户故事的内容是可以协商的，用户故事不是合同
  • 有价值valuable
    • 每个故事必须对客户具有价值（无论是用户还是购买方）
  • 可以估算estimable
    • 开发团队需要去估计一个用户故事以确定优先级，工作量，安排计划
  • 短小small
    • 一个好的用户故事在工作量上要尽量短小
  • 可测试性testable
    • 一个用户故事要是可以测试的，以便于确认它是可以完成的
• 增加项目进展可视性措施
  • 产品待办事项列表梳理
    • 活动贯穿于整个scrum项目，实时显示产品的各个待办事项。产品待办事项列表列出了所有的特性、功能、需求、改进方法和缺陷修复等对未来发布产品进行的改变，梳理活动可以间接查看项目进度
  • sprint评审会议
    • 在任何时间，达成目标的剩余工作量是可以被累计的。产品负责人至少在每个sprint评审会议的时候追踪剩余工作总量，通过与之前数据对比监控向目标前进的进度。评审会议围绕完成的产品增量，了解目前进度，讨论下一步推进
  • 燃尽图
    • 显示了sprint中累计剩余的工作量，它是一个反映工作量完成状况的趋势图。通过每个sprint结束时更新的燃尽图来跟踪整个发布计划的进展，利用图标更加清晰地展现项目进展
  • 每日scrum会议
    • 说明做了什么，将要做什么，遇到的困难。内部沟通，确认团队目前进度，以及仍然可以实现sprint的目标

• 简述在Scrum模型中，分别采取了哪些措施来改善过程的透明性、检验性和适应性

  • 透明性
    • 产品待办事项列表梳理
    • sprint评审会议
    • 燃尽图
    • 每日scrum会议
  • 检验性和适应性
    • 每日scrum会议
      • 检验sprint目标的进展，做出调整，从而优化次日的工作价值
    • sprint评审会议
      • 检验发布目标的进展，做出调整，从而优化下一个sprint的工作价值
    • sprint回顾会议
      • 用来回顾已经完成的sprint，并且确定做出什么样的改善可以使接下来的sprint更加高效，更加令人满意，并且工作更快乐

3. XP极限编程模型

• 关于敏捷开发过程，为了把交流推向极致，XP极限编程模型采取了哪些措施

  • 双人编程
  • 单元测试
  • 残酷重整
  • 人员轮换
  • 使用CRC卡片模拟系统

原文：https://www.cnblogs.com/cbw052/p/11017019.html