软考知识汇总-软件工程

1 能力成熟度模型（CMM）

将软件工程成熟度分为5个级别

• 初始级：杂乱无章，很混乱，完全依赖个人努力和英雄核心主义
• 可重复级：建立了基本的项目管理过程等
• 已定义级：管理和工程已经文档化、标准化
• 已管理级：制定了软件过程和产品质量的详细度量标准，过程质量被理解和控制
• 优化级：加强了定量分析，通过过程质量反馈和新概念、技术的反馈不断优化

2 能力成熟度模型集成（CMMI）

CMMI是CMM模型的集成，分为阶段式模型和连续式模型

2.1阶段式模型

类似于CMM，关注于组织的成熟度

• 初始的：过程不可预测且缺乏控制
• 已管理的：过程为项目服务
• 已定义的：过程为组织服务
• 定量管理的：过程已度量和控制
• 优化的：集中于过程改进

2.2 连续式模型

关注每个过程域的能力

• $C{L}_0$(未完成的)：未执行或未得到$C{L}_1$定义的所有目标
• $C{L}_1$(已执行的)：将可标识的输入产品转换为可标识的输出产品
• $C{L}_2$(已管理的)：管理过程的制度化
• $C{L}_3$(已定义级的)：已定义过程的制度化
• $C{L}_4$(定量管理的)：可定量管理过程的制度化
• $C{L}_5$(优化的)：量化手段改变和优化，持续改进

3 软件过程模型

• 瀑布模型：以文档为驱动，适合于需求明确的软件项目模型，管理成本低
• 增量模型：瀑布模型的变体，假设需求可以分段为一系列增量产品，**第1个增量往往是核心产品，**第一个可交付版本所需的成本和时间较少
• 演化模型：不断演变、迭代
• • 原型模型：建立一个原型，适合于需求不清、经常变化、系统规模不是很大也不太复杂
• • 螺旋模型：加入了风险分析，适合于庞大、复杂并且具有高风险的系统
• 喷泉模型：以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法，各个阶段没有明显的界限，克服了瀑布模型不支持软件重用和多项开发活动集成的局限性，使开发过程具有迭代性和无间隙性
• 统一过程(UP)模型：
• • 初始阶段：生命周期目标
• • 精化阶段：生命周期架构
• • 构建阶段：初始运作功能
• • 移交阶段：产品发布
• 敏捷方法：
• • 极限编程：xP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贳穿于整个生存周期。
    •4大价值观：沟通、简单性、反馈和勇气。
    •5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作、
    •12个最佳实践：计划游戏(快速制定计划、 随着细节的不断变化市完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（我到合适的比喻传达信息）、简单设计(只处理当前的需求，使设计保持简单）、测试先行(先写测试代码，然后再编写程序)、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本)
    每周工作 40 个小时、现场客户和编码标准
• • 水晶法：每一个不同的项日都需要一套不同的策略、约定和方法论
• • 并列争求法：使用达代的方法，基过，把每 30 天一次的迭代称为一个“冲刺”，
• • 自适应软件开发：⑥个基本的原则：有一个使命作为指导；特征被视为容户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键：变化不被视为改正，而是被视为对软件开发实际情况的调整：确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。
• • 敏捷统一过程：敏捷统一过程 (Agile Unified Process, AUP)采用“在大型上连续，以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动（初始、精化、构建和转换），提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个 AUP 迭代执行以下活动：
    •建模。建立对商业和问题域的模型表述，这些模型 “足够好”即可，以便团队继续前进。
    •实现。将模型翻译成源代码。
    •测试。像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
    •部署。对软件增量的交付以及获取最终用户的反馈。
    •配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
    •环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施

4 软件需求

• 功能需求。考虑系统要做什么，在何时做，在何时以及如何修改或升级。
• 性能需求。考虑软件开发的技术性指标。例如，存储容量限制、执行速度、响应时间
  及吞吐量。
• 用户或人的因素。考虑用户的类型。例如，各种用户对使用计算机的熟练程度，需要接受的训练，用户理解、使用系统的难度，用户错误操作系统的可能性等。
• 环境需求。考虑末来软件应用的环境，包括硬件和软件。对硬件设备的需求包括机型、外设、接口、地点、分布、湿度、磁场干扰等；对软件的需求包括操作系统、网络、数据库等。
• 界面需求。考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。
• 文档需求。考虑需要哪些文档，文档针对哪些读者。
• 数据需求。考虑输入、输出数据的格式，接收、发送数据的频率，数据的淮确性和精度，数据流量，数据需保持的时间。
• 资源使用需求。考虑软件运行时所需要的数据、其他软件、内存空问等资源；软件开发、维护所需的人力、支撑软件、开发设备等。
• 安全保密要求。考虑是否需要对访问系统或系统信息加以控制，隔离用户数据的方法，用户程序如何与其他程序和操作系统隔离以及系统备份要求等
• 可靠性要求。考虑系统的可 靠性要求，系统是否必须检测和隔离错误：出错后，重启系统允许的时间等。
• 软件成木消耗与开发进度需求。考虑开发是否有规定的时间表，软/硬件投资有无限制等。
• 其他非功能性要求。如采用某种开发模式，确定质量控制标准、里程碑和评审、验收
  标准、各种质量要求的优先级等，以及可维护性方面的要求

5 系统设计

5.1 概要设计

• 设计软件系统总体结构
• 数据结构及数据座设计
• 编与概要设计文档
• 评审