软件工程

初始笔记

软件过程模型

软件生命周期描述了软件从生到死的全过程。包括需求分析、软件设计、软件开发、运行维护和淘汰。
软件生命周期模型，也叫做软件过程模型，是为了对各项任务给予规程约束，从而能够有序地按照规程进行。

• 瀑布模型 (Waterfall Model)
  
  • 特点是因果关系紧密相连，前一个阶段工作的输出结果，是后一个阶段工作的输入。每一个阶段都是建筑在前一个阶段正确实施的结果之上。每一个阶段工作完成后都伴随着一个里程碑(一组检查条件)，对该阶段的工作进行审查和确认。
  • 主要缺点有：
    • 软件需求的完整性、正确性等很难确定，甚至是不可能和不现实的。因为用户不理解计算机和软件系统，无法回答目标系统“做什么”,对系统将来的改变也难以确定，往往用“我不能准确地告诉你”回答开发人员。
    • 瀑布模型是一个严格串行化的过程模型，使得用户和软件项目负责人要相当长的时间才能得到一个可以看得见的软件系统。如果出现与用户的期望不一致，或者出现需求变更，将会带来巨大的损失(例如人力、财力、时间等)。
    • 瀑布模型的基本原则是在每个阶段一次性地完全解决该阶段的工作，不会出现遗漏、错误等情况，而实际上这是不现实或不可能的。
• 原型模型 (Prototype Model)
  
  • 包括原型开发阶段和目标软件开发阶段
    • 原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。
    • 目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。
  • 按照原型的作用不同，出现了抛弃型原型和演化性原型
    • 抛弃型原型是将原型作为需求确认的手段，在需求确认结束后，原型就被抛弃不用，重新采用一个完整的瀑布模型进行开发。
    • 演化性原型是在需求确认结束后，不断补充和完善原型，直至形成一个完整的产品。
• 螺旋模型 (Spiral Model)
  
  • 把整个软件开发流程分成多个阶段，每一个阶段都由目标设定、风险分析、开发和有效性验证、评审4部分组成。软件开发过程实际是上述4个部分的迭代过程，每迭代一次，螺旋线就增加一圈，软件系统就生成一个新版本，这个新版本实际上是对目标系统的一个逼近。经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内，否则也有可能中途夭折
• 敏捷模型
  • 敏捷型方法主要有两个特点
    • 敏捷型方法是“适应性” (adaptive) 而非“预设性” (predictive) 的
      • 软件开发无法将设计和实施分离开来，一些设计错误只能在编码和测试时才能发现，根本无法做出一个交给程序员就能直接编码的软件设计。
    • 敏捷型方法是“面向人的” (People-oriented) 而非“面向过程的” (Process-oriented)
      • 在开发过程中，项目的需求是在不断变化的，管理人员之间、开发人员之间以及管理人员和开发人员之间，都必须不断地了解这些变化，对这些变化做出反应，并实施在随后的开发过程中。
• 统一过程模型(Rational Unified Process,RUP)
  • 描述了如何有效地利用商业的、可靠的方法开发和部署软件，是一种重量级过程。
  • RUP中有9个核心工作流
    • 业务建模 (Business Modeling): 理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。
    • 需求 (Requirements): 定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。
    • 分析与设计 (Analysis & Dcsign): 把需求分析的结果转化为分析与设计模型。
    • 实现 (Implementation): 把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。
    • 测试 ( Test ) : 检查各子系统之间的交互、集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。
    • 部署 (Deployment): 打包、分发、安装软件，升级旧系统；培训用户及销售人员，并提供技术支持。配置与变更管理 (Configuration & Change Management): 跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
    • 项目管理 (Project Management): 为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。
    • 环境 (Environment): 为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。
  • RUP 把软件开发生命周期划分为多个循环 (Cycle), 每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段 (Phase) 组成，每个阶段完成确定的任务。
    • 初始 (inception) 阶段：定义最终产品视图和业务模型，并确定系统范围。
    • 细化 (elaboration) 阶段：设计及确定系统的体系结构，制订工作计划及资源要求。
    • 构造 (construction) 阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。
    • 移交 (transition) 阶段：把产品提交给用户使用。
  • RUP中定义了如下一些核心概念
    • 角色 ( Role ) : Who的问题。角色描述某个人或一个小组的行为与职责。 RUP预先定义了很多角色，如体系结构师 (Architect)、 设计人员 (Designer)、 实现人员 (Implementer)、 测试员 (tester) 和配置管理人员 (Configuration Manager) 等，并对每一个角色的工作和职责都做了详尽的说明。
    • 活动 (Activity):How 的问题。活动是一个有明确目的的独立工作单元。
    • 制品(Artifact):What的问题。制品是活动生成、创建或修改的一段信息。也有些书把Artifact翻译为产品、工件等，和制品的意思差不多。
    • 工作流 (Workflow):When 的问题。工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。
  • RUP采用“4+1”视图模型来描述软件系统的体系结构。
    
    • 分析人员和测试人员关心的是系统的行为，会侧重于用例视图；
    • 最终用户关心的是系统的功能，会侧重于逻辑视图；
    • 程序员关心的是系统的配置、装配等问题，会侧重于实现视图；
    • 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，会侧重于进程视图；
    • 系统工程师关心的是系统的发布、安装、拓扑结构等问题，会侧重于部署视图。
• 软件能力成熟度模型(Capability Maturity Model for Software,CMM)
  • CMMI(Capability Maturity Model Integration for Software, 软件能力成熟度模型集成) 是在全世界推广实施的一种软件能力成熟度评估标准，主要用于指导软件开发过程的改进和进行软件开发能力的评估，它将软件过程改进的步骤组织成5个成熟度等级，为软件过程不断改进奠定了一个循序渐进的基础。
    • Level 1 初始级。过程通常是随意且混乱的。这些组织的成功依赖于组织内人员的能力与英雄主义。成熟度1级的组织也常常能产出能用的产品与服务，但它们经常超出在计划中记录的预算与成本
    • Level 2已管理级。组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。
    • Level 3 已定义级。企业能够根据自身的特殊情况定义适合自己企业和项目的标准流程，将这套管理体系与流程予以制度化，同时企业开始进行项目积累，企业资产的收集。
    • Level 4 量化管理级。组织建立了产品质量、服务质量以及过程性能的定量目标。成熟度级别3级与4级的关键区别在于对过程性能的可预测。
    • Level 5 优化级。企业的项目管理达到了最高的境界。成熟度级别5级关注于通过增量式的与创新式的过程与技术改进，不断地改进过程性能。处于成熟度5级时，组织使用从多个项目收集来的数据对整体的组织级绩效进行关注

需求工程

软件需求包括3个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求)

1. 业务需求 (business requirement) 反映了组织机构或客户对系统、产品高层次的目标要求
2. 用户需求 (user requirement) 描述了用户使用产品必须要完成的任务，是用户对该软件产品的期望。这两种构成了用户原始需求文档的内容。
3. 功能需求 (functional requirement) 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足业务需求。非功能需求描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。

需求工程是指应用已证实有效的原理、方法，通过合适的工具和记号，系统地描述待开发系统及其行为特征和相关约束。

需求工程的活动主要被划分为以下几个阶段。

1. 需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求
2. 需求分析：为系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义。
3. 形成需求规格(或称之为需求文档化):按照相关标准，生成需求模型的文档描述，用户原始需求书作为用户和开发者之间的一个协约，往往被作为合同的附件；软件需求描述规约作为后续软件系统开发的指南。
4. 需求确认与验证：以需求规格说明为输入，通过用户确认、复审会议、符号执行、模拟仿真或快速原型等途径与方法，确认和验证需求规格的完整性、正确性、一致性、可测试性和可行性，包含有效性检查、一致性检查、可行性检查和确认可验证性。
5. 需求管理：包括需求文档的追踪管理、变更控制、版本控制等管理性活动。

需求获取

需求获取过程的参考步骤：
1)开发高层的业务模型
2)定义项目范围和高层需求
3)识别用户角色和用户代表
4)获取具体的需求
5)确定目标系统的业务工作流
6)需求整理与总结

需求获取方法：
针对不同类型的软件项目，需要采用不同的需求获取方法。常见的需求获取方法如下。
1)用户面谈
这是一种最为常见的需求获取方法，是理解用户需求的最有效方法。面谈过程需要认真的计划和准备；面谈之后，需要复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题。
2)需求专题讨论会
需求专题讨论会也是需求获取的一种有力技术。在短暂而紧凑的时间段内将相关涉众集中在一起集体讨论，与会者可以在应用需求上达成共识，对操作过程尽快取得统一的意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。
专题讨论会具有以下优点。

• 协助建立一支高效的团队，围绕项目成功的目标。
• 所有的风险承担人都畅所欲言。
• 促进风险承担人和开发团队之间达成共识。
• 揭露和解决那些妨碍项目成功的行政问题。
• 能够很快地产生初步的系统定义。
• 可以有效地解决不同涉众之间的需求冲突。

3)问卷调查
问卷调查可用于确认假设和收集统计倾向数据。存在的问题是：相关问题不能事先决定，问题背后的假设对答案造成偏颇，难以探索一些新领域，难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术收到良好效果。
4)现场观察
该方法主要是通过观察用户实际执行业务的过程，来直观地了解业务的执行过程，全面了解需求细节。执行业务可能是手工操作，也可能是在原有的业务系统上执行。
5)原型化方法
在需求的早期，用户往往在具体的需求定义上存在很多不确定性，尤其是信息系统的人机交互界面和查询报表类的需求上。此时往往可以通过在需求阶段采用原型化方法，通过开发系统原型以及与用户的多次迭代反馈，解决在早期阶段需求不确定的问题，尤其是在人机界面等高度不确定的需求。
6)头脑风暴法
在一些新业务拓展的软件项目中，由于业务是新出现的，而且业务流程存在高度的不确定性，例如互联网上的新业务系统、 App等，一群人围绕该业务，发散思维，不断产生新的观点，参会者敞开思想使各种设想在相互碰撞中激起大脑的创造性风暴，从而确定具体的需求。

需求变更

1. 问题分析和变更描述。当提出一份变更提议后，需要对该提议做进一步的问题分析，检查它的有效性，从而产生一个更明确的需求变更提议。
2. 变更分析和成本计算。当接受该变更提议后，需要对需求变更提议进行影响分析和评估。变更成本计算应该包括对该变更所引起的所有改动的成本，例如修改需求文档、相应的设计、实现等工作成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
3. 变更实现。当确定执行该变更后，需要根据该变更的影响范围，按照开发的过程模型执行相应的变更。在计划驱动过程模型中，往往需要回溯到需求分析阶段开始，重新作对应的需求分析、设计和实现等步骤；在敏捷开发模型中，往往会将需求变更纳入到下一次迭代的执行过程中

需求跟踪

需求跟踪有两种方式：

1. 正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。
2. 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

总结思考

瀑布模型是最早的结构化过程模型，其核心特征是严格的线性顺序：需求分析→设计→编码→测试→维护。适用场景：需求明确且稳定、技术风险低、有严格合同约束的项目，如军工、航天、嵌入式系统，或者对文档和审计要求高的领域。
原型模型的特征是通过“快速构建—用户反馈—修改”的循环来解决需求不清晰的问题。它分为原型开发和目标软件开发两个阶段，并衍生出两种形态：抛弃型原型（原型仅用于确认需求，用完即弃，之后回到瀑布流程开发正式系统）和演化型原型（原型本身不断迭代完善，最终演变为交付产品）。适用场景：需求模糊、用户缺乏明确概念的系统，尤其是界面交互密集的信息系统；抛弃型适合需求探索阶段，演化型适合小型、需求持续演进的中小型项目。
螺旋模型可以理解为“瀑布模型 + 原型迭代 + 风险分析”。每一圈迭代都由目标设定、风险分析、开发与验证、评审四部分组成，每转一圈产生一个更接近目标的新版本，系统逐步收敛；若始终无法收敛，项目可能中途夭折——这也是风险分析的直接后果（及时止损）。适用场景：大型、高风险、需求复杂且难以一开始确定的项目，如新领域的大型系统开发、技术不确定性高的项目。
敏捷不是单一模型，而是一族方法（Scrum、XP 等）。一是“适应性”而非“预设性”——承认设计与实施无法分离，很多问题只有编码测试时才会暴露，因此不预先做完备设计，而是通过短周期迭代（Sprint）持续调整；二是“面向人”而非“面向过程”——认为响应变化比遵循计划更重要，依赖高水平的团队和紧密的沟通协作。适用场景：需求高度不确定、变化频繁的小中型项目，典型如互联网产品、App、初创公司的快速试错型业务。
RUP 是一种用例驱动、以架构为中心、迭代增量的重量级过程框架。它有两个维度：时间维度上，生命周期划分为多个循环，每个循环经历初始（确定范围和业务模型）→细化（确定架构和计划）→构造（开发产品）→移交（交付用户）四个阶段；内容维度上有九个核心工作流（业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境），阶段与工作流交织进行。它通过角色（Who）、活动（How）、制品（What）、工作流（When）四个核心概念将过程规范化，并用"4+1"视图模型（用例、逻辑、实现、进程、部署视图）从不同干系人的视角描述架构。适用场景：大型企业级软件项目，尤其是对架构要求高、团队规模大、开发周期长、需要严格过程管控的场景。
CMM/CMMI 不是过程模型而是过程改进与能力评估框架——它回答的是“组织的过程管理水平处于什么等级”，而不是“项目应该按什么流程开发”。它定义了五个成熟度等级：初始级（依赖个人英雄主义）、已管理级（项目级过程受控）、已定义级（组织级标准过程制度化）、量化管理级（过程性能可度量、可预测）、优化级（基于数据的持续改进）。等级递进的关键节点是：2 级管住单个项目，3 级上升到组织级标准，4 级实现定量预测，5 级做到自我优化。适用场景：组织级的过程改进和能力认证，如软件外包企业、承接政府或大型企业项目的供应商。

从演化脉络看，这些模型其实是对同一个矛盾的回应：需求确定性 vs 开发过程的管控强度。

• 需求越稳定，越适合计划驱动（瀑布、RUP）；需求越模糊，越适合迭代反馈（原型、螺旋、敏捷）；
• 而风险和团队规模决定了需要多大程度的规范约束。

实际工程中很少有项目纯粹采用单一模型，常见的做法是组合使用，例如用抛弃型原型做需求确认后转入瀑布开发，或在 RUP 框架内局部引入敏捷实践。