1.系统开发过程及项目管理

1.1开发模型

• 开发模型（也称软件过程模型、软件生命周期模型）是对软件开发全过程的结构化划分与规范，定义了从需求分析、设计、编码、测试到维护的各个阶段及其关系、顺序和迭代方式。选择合适的开发模型能够提高效率、控制风险、保证质量

• 瀑布：一条路走到黑

• 螺旋：每次都要先看风险再前进

• V模型：写代码的同时就在想怎么测

• 原型：先做个玩具给你看，满意了再做真的

• 喷泉：面向对象专属，想怎么跳就怎么跳

• 增量：一块一块拼起来给你

• 迭代：先画个简笔画，一遍一遍改成名画

1.1.1瀑布模型（Waterfall Model）

• 特点：线性顺序，上一阶段完全结束后才能进入下一阶段。

• 阶段：软件计划 → 需求分析 → 软件设计 → 程序编码→ 软件测试 → 运行维护。

• 优点：简单清晰、文档驱动、里程碑明确。

• 缺点：无法应对需求变更，交付周期长，用户最后才能看到产品。

• 适用：需求明确、稳定且变化少的项目（如政府合同、嵌入式系统）。

需求分析 → 系统设计 → 实现编码 → 集成测试 → 部署维护
    ↓         ↓          ↓          ↓          ↓
   完成      完成       完成       完成       完成

1.1.2V模型（V-Model）

• 特点：瀑布模型的变种，强调测试与开发阶段的对应关系。左边是开发（需求、设计、编码），右边是测试（单元测试、集成测试、系统测试、验收测试），形成“V”字形。

• 优点：测试活动提前介入，缺陷早发现。

• 缺点：仍然缺乏处理变化的灵活性。

• 适用：安全关键系统（如汽车、医疗设备、航空航天）。

需求分析 ───────────────────→ 验收测试
    ↑                            ↓
系统设计 ───────────────────→ 系统测试
    ↑                            ↓
详细设计 ───────────────────→ 集成测试
    ↑                            ↓
编码实现 ───────────────────→ 单元测试

1.1.3螺旋模型（Spiral Model）

• 特点：结合瀑布与原型，并引入风险分析。每个螺旋周期包括：目标设定 → 风险分析 → 开发与验证 → 评审。

• 优点：风险驱动，适合高风险、大型、复杂的项目。

• 缺点：过程复杂，需要专业风险评估。

• 适用：大型企业系统、国防项目、创新性强的项目。

        ┌─────────────┐
        │  确定目标    │
        └──────┬──────┘
               ↓
        ┌─────────────┐
        │  风险分析    │  ←── 风险太大就终止
        └──────┬──────┘
               ↓
        ┌─────────────┐
        │  开发验证    │
        └──────┬──────┘
               ↓
        ┌─────────────┐
        │  客户评估    │
        └──────┬──────┘
               ↓
        下一圈循环（更复杂的版本）

1.1.4喷泉模型（Fountain Model）

• 特点：面向对象的生命周期模型，各阶段重叠、迭代、无明确边界，像喷泉一样向上循环。

• 优点：适应面向对象的开发特征，支持复用。

• 缺点：管理和文档困难。

• 适用：采用面向对象技术的中小型项目。

    ┌─────────────────────────────────┐
    │  分析 ←→ 设计 ←→ 编码 ←→ 测试 ←→ 维护  │
    └─────────────────────────────────┘
              （各阶段可同时进行）
              
    水从下往上喷，落下后又可以往上，各阶段没有明确边界

1.1.5敏捷方法

• 敏捷方法（Agile）是一种以人为核心、迭代演进、快速响应变化的软件开发与项目管理理念

• 敏捷宣言：

  • 个体和互动 高于 流程和工具

    • 强调团队成员间的有效沟通，比死板遵循工具或文档更重要。

  • 可工作的软件 高于 详尽的文档

    • 最终目标是交付能解决用户问题的软件，而不是写完美无缺的文档（但并非不要文档）。

  • 客户合作 高于 合同谈判

    • 把客户当作合作伙伴，持续沟通反馈，而不是只在签合同时谈定所有细节。

  • 响应变化 高于 遵循计划

    • 拥抱需求变化，即使在开发后期。这比一开始就定死所有计划并严格执行更明智。

• 十二项基本原则：

  • 最优先要做的是尽早、持续地交付有价值的软件，让客户满意。

  • 欣然面对需求变化，即使在开发后期。敏捷过程利用变化为客户维持竞争的优势。

  • 频繁地交付可工作的软件，从数周到数月，交付周期越短越好。

  • 在团队内外，面对面交谈是最有效，也是最高效的沟通方式。

  • 在整个项目过程中，业务人员必须和开发人员每天都在一起工作。

  • 以受激励的个体为核心构建项目。为他们提供所需的环境和支持，相信他们可以把工作做好。

  • 可工作的软件是衡量进度的首要标准。

  • 敏捷过程倡导可持续开发。

  • 坚持不懈的追求技术卓越和良好的设计，以此增强敏捷的能力。

  • 简单是尽最大可能减少不必要工作的艺术，是敏捷的根本。

  • 最好的架构、需求和设计来自自组织的团队。

  • 团队定期反思如何提升效率，并依此调整自己的行为。

• 4大价值观：沟通、简单、反馈、勇气

• 5大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作

• 敏捷模型：

  • 极限编程（XP）：

    • 专注于提升软件开发的技术卓越性和响应变化能力。它通过测试驱动开发 (TDD)、结对编程、持续集成 (CI)、简单设计、集体代码所有权等一系列工程实践，确保在需求频繁变动时，代码依然保持健康和高质量。XP是追求代码质量团队的最佳拍档

  • 水晶方法系列(Crystal)：（用最少纪律约束而仍能成功的方法）

    • 由方法论专家Alistair Cockburn提出的一个方法论家族。其核心思想是：没有一种方法能适用于所有项目，应根据项目的规模和潜在风险（如系统对生命财产的影响），选择最“轻量级”且够用的方法。Crystal强调人是核心，沟通比流程更重要，提倡“渗透式交流”（即轻松、非正式的面对面沟通）。

  • 并列争球法（Scrum）

  • 自适应开发

  • 功用驱动开发

1.1.6快速原型模型（Prototype Model）

• 特点：快速构建一个可演示的原型（可以是纸面、低保真或可运行界面），让用户试用并提出反馈，然后反复修改直至满意，再开发最终产品。

• 优点：减少需求误解，降低返工。

• 缺点：用户可能误以为原型就是产品，导致期望过高；原型可能带来额外成本。

• 适用：需求不明确、人机交互复杂的系统。

┌───────────────────────────────┐
│   快速构建原型 → 用户评估 → 精化需求   │
└───────────────┬───────────────┘
                ↓ 循环N次
        ┌─────────────┐
        │  正式开发    │
        └──────┬──────┘
               ↓
        最终产品

1.1.7增量模型（Incremental Model）

• 特点：先交付核心功能（增量），后续逐步增加功能模块，每个增量都是一个可交付的产品。

• 优点：用户可以快速获得基本功能，投资回报快。

• 缺点：如果架构设计不佳，增量集成可能困难。

• 适用：希望尽快上线基础版本的产品（如电商平台初期）

第1个增量：核心功能 → 交付用户使用
    ↓
第2个增量：增加功能 → 交付更新版本
    ↓
第3个增量：更多功能 → 继续交付
    ↓
...（直到完成所有功能）

1.1.8迭代模型/迭代开发方法（Iterative Model）

• 特点：将项目分成多个小“迭代”，每次迭代包含完整的开发活动（需求、设计、实现、测试），产生一个可运行的子集。

• 优点：早期即可得到部分可运行软件，降低风险，适应需求变化。

• 缺点：需要较强的架构规划和迭代管理。

• 适用：规模大、复杂度高、需求不完全确定的项目

• 迭代 vs 增量：迭代强调“反复优化”，增量强调“逐步添加功能”。两者常结合使用。

初始版本 → 评估反馈 → 改进版本 → 再次评估 → ... → 最终产品
   ↓          ↓          ↓          ↓
  能用      更好用     更完善     接近完美

1.1.9构件组装模型

• 特点：复用已有构件，组装现成的“积木”

• 优点：效率高，质量好，维护简单

• 缺点：集成风险，依赖外部构件

• 适用：需要快速交付、功能标准化的系统

  步骤	关键内容
  1. 需求分析	明确系统需要实现的功能，为后续构件识别提供依据。
  2. 构件识别与选择	在内部或第三方的构件库中寻找、评估并选择可用的构件。
  3. 架构设计	设计系统框架，明确各个构件如何组织和连接，定义其交互方式。
  4. 构件集成与开发	将选好的构件组装起来。只有当找不到合适构件时，才需要自己开发。
  5. 系统测试	对组装后的系统进行测试，重点验证构件间的接口和交互是否正确。

1.2项目管理

1.2.1时间管理

• 项目时间管理的6个核心过程：

  • 1.定义活动：将工作包分解为具体的活动清单。

  • 2.排列活动顺序：识别活动间的逻辑关系，并排序。

  • 3.估算活动资源：估算完成各项活动所需的具体资源（如人员、设备）。

  • 4.估算活动持续时间：根据资源估算结果，估算完成活动所需的时间。

    • 三点估算法：最乐观(tO)、最可能(tM)、最悲观(tP) → 期望时间 = (tO+4tM+tP)/6

    • 专家判断法：由有经验的人或小组估算

    • 功能点估算法：按照每个活动的功能点所需时间累加

  • 5.制定进度计划：综合分析活动顺序、资源和时间，制定出项目进度计划。

  • 6.控制进度：在项目执行过程中，监督和管理进度的变更

1.2.2软件配置管理（Software Configuration Management, SCM）

• 定义：是在软件的开发、测试、交付和维护过程中，用于管理软件资产变化的一套规范、方法和工具。它的目标是保证软件产品的完整性、可追溯性和一致性，防止因变更失控导致混乱或缺陷。SCM 回答的是“谁、在什么时候、基于什么原因、对哪个版本的文件、做了什么样的修改”。

• 为什么需要软件配置管理？

      在多人协作、多版本、多环境的开发中，如果不进行配置管理，会频繁出现以下问题：

      SCM 通过版本控制、变更控制、状态报告、配置审计来系统性地解决上述问题。

  • 修改冲突：两人同时改同一文件，后提交者覆盖前者的工作。

  • 版本混乱：分不清测试环境部署的是哪个版本，无法复现生产环境的缺陷。

  • 丢失历史：想回退到一周前的状态，但中间修改不可追溯。

  • 发布错误：漏提交或错提交了某个文件，导致构建失败或运行异常。

• 核心概念：

  • 配置项：纳入管理的基本单元，例如源代码文件、配置文件、数据库脚本、文档、构建脚本、测试用例等。

  • 检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整

  • 里程碑：完成阶段性工作的标志，不同类型的项目里程碑不同

  • 基线：指一组配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是一些重要的里程碑。作为后续变更和交付的基准。

    • 功能基线（定义基线）：系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格书

    • 分配基线（需求基线）：软件需求分析阶段，经过正式评审和批准的软件需求规格说明书

    • 产品基线：软件组装与系统测试阶段结束时，经过正式评审和批准的有关软件产品的全部配置项的规格说明

  • 变更控制：对配置项修改的申请、评估、批准、实施和验证流程。

  • 版本控制：配置项随时间演化的某个快照，通常用版本号标识（如 v1.2.3）。

  • 

1.2.3风险的分类：

• 项目风险

  • 潜在的预算、进度、人员和组织、资源、用户和需求问题

  • 项目复杂性、规模和结构的不确定性

• 技术风险

  • 潜在的设计、实现、接口、测试和维护方面的问题

  • 规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）

• 商业风险

  • 市场风险

  • 策略风险

  • 销售风险

  • 管理风险

  • 预算风险

1.3软件过程改进

• 软件能力成熟度模型CMM:是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度的等级认证标准。规定了软件研制和软件测试中的主要软件管理过程和工程过程的实践。主要用于评价软件企业的质量保证能力。

  等级	特征	组织表现	关键实践
  1. 初始级 (Initial)	混乱、无序、成功靠英雄。过程是临时和杂乱的，成功依赖于个人的能力和付出。	进度、成本和产品质量极不稳定，项目通常延期并超预算。	无明确关键实践
  2. 可重复级 (Repeatable)	建立了基本项目管理过程。项目计划、管理、跟踪和配置管理等基本过程已建立，能够重复过往的成功经验。	项目的成功不再完全依赖个人，项目经理能基于历史经验进行规划和跟踪。	需求管理、项目计划、项目跟踪与监控、软件子合同管理、软件配置管理、软件质量保证
  3. 已定义级 (Defined)	过程标准化、文档化。组织的软件过程已得到良好定义和文档化，形成了标准软件过程。	所有项目（除特殊情况外）都基于组织的标准过程裁剪、执行和维护，过程更加稳定并可重复。	组织过程焦点、组织过程定义、培训大纲、软件集成管理、软件产品工程、组织协调、同行评审
  4. 已管理级 (Managed)	过程可量化、可预测。对软件过程和产品质量建立了定量的理解和控制。	组织能够收集和分析详细的度量数据，对过程和产品质量进行量化管理，使得绩效变得可预测。	定量过程管理、软件质量管理
  5. 优化级 (Optimizing)	持续改进、追求卓越。过程改进是组织文化的一部分，能够基于量化反馈和新技术，持续地优化过程。	组织主动地识别过程的弱点，并引入创新实践和技术来预防缺陷，提高生产力。	缺陷预防、技术变更管理、过程变更管理

2.系统分析基础知识（有下午题）

2.1需求工程概述

• 软件的需求工程，他包括了创建和维护需求文档所必须的一切活动的过程

• 需求工程通常被划分为两大阶段：需求开发 和 需求管理。

• 需求开发

  • 需求获取

  • 需求分析

  • 需求定义（需求规格说明书）

  • 需求验证

• 需求管理：

  • 最基本的任务：建立需求基线

  • 需求变更控制

  • 版本控制

  • 需求跟踪

  • 需求状态跟踪

• 

2.2需求分类

• 软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望

• 业务需求（整体全局）

• 用户需求（用户视角）

• 系统需求（计算机化）

  • 功能需求

  • 非功能需求

  • 设计约束

• 

2.3需求分析

2.3.1结构化分析：

• 结构化分析（Structured Analysis, SA） 是需求分析阶段的一种经典方法，它采用自顶向下、逐层分解的思想，用图形化模型直观地表达系统的数据流、数据存储、处理过程和外部实体，特别适合数据密集型系统（如管理信息系统、报表系统）的需求建模。

• 结构化分析的核心思想：

  思想	说明	比喻
  自顶向下	从整体到局部，先看森林再看树木	先画中国地图，再画各省地图
  逐步分解	大功能拆成小功能，直到足够简单	把"做饭"拆成洗菜→切菜→炒菜→装盘
  抽象求精	先忽略细节看本质，再逐步细化	先知道"汽车能跑"，再研究发动机怎么转

• 结构化分析的核心模型

  • 数据字典 (DD)：对DFD中出现的所有数据流、数据存储、数据项进行精确定义。

    • 数据元素

    • 数据结构

    • 数据流

    • 数据存储

    • 加工逻辑

    • 外部实体

  • 功能模型——数据流图 (DFD)：展示系统中数据的流动、处理和存储，不控制逻辑。

    • 数据流

    • 加工

    • 数据存储

    • 外部实体

    • 

  • 数据模型——实体-关系图(E-R图)：描述系统中的静态数据结构（数据对象及其关系）。

    • 实体

    • 联系

    • 

  • 行为模型——状态-迁移图(STD)：描述系统在事件驱动下的行为变化（适用于实时或控制型系统）。

    • 状态

    • 事件

    • 

  • 对于纯数据处理型系统，DFD + DD + E-R图已足够；对于实时/控制型系统，需要增加STD。

• 结构化分析的核心步骤：

  • 建立环境图（上下文图）

    • 最高层DFD（图0），只用一个过程表示整个系统。

    • 标出所有与系统交互的外部实体（人员、外部系统、硬件）。

    • 标出在系统和外部实体之间流动的数据流（输入和输出）。

    • 作用：界定系统边界，明确“系统做什么”与“外部做什么”。

  • 绘制数据流图（逐层分解）

    • 将图0中的过程分解为更细粒度的子过程（图1、图2…）。

    • 遵循平衡原则：父图的输入/输出数据流必须与子图保持一致。

    • 一个过程一般分解为2～7个子过程为宜。

    • 使用数据存储表示数据在中间步骤的停留（文件、数据库表）。

  • 定义数据字典

    • 为DFD中每个数据流、数据存储、数据项建立条目。

    • 常用定义符号：= 表示“等于”，+ 表示“与”，[ ] 表示“或”，{ } 表示“重复”，( ) 表示“可选”。

    • 示例：

    • 购书订单 = 订单号 + 客户号 + { 书籍编号 + 数量 } + 总金额书籍编号 = 5位数字

  • 描述小说明（过程规格说明）

    • 对DFD中最底层的功能过程（基本过程）用伪代码、决策表或结构化英语描述其处理逻辑。

    • 避免描述控制流，只描述输入数据如何转换为输出数据。

  • 补充实体-关系图（可选但推荐）

    • 识别系统需要持久化的实体及其属性。

    • 建立实体间的联系，辅助数据库设计。

3.系统设计知识

3.1系统设计的主要层次

• 总体设计（概要设计）：确定系统的整体结构、模块划分、技术选型、软硬件部署方案。

• 详细设计：对每个模块进行内部设计，定义数据结构、算法、接口、状态转换。

3.2结构化设计

• 核心思想：

  • 抽象化

  • 自顶向下，逐步细化：从最顶层的控制模块开始，逐层分解为子模块。

  • 信息隐蔽

  • 模块独立：高内聚、低耦合，实现模块独立性

• 设计原则：

  • 保持模块的大小适中

  • 尽可能减少调用的深度

  • 多扇入，少扇出（多扇入意味着模块被多个调用者复用，少扇出意味着模块直接管理的子模块数量少（调用复杂度低））

  • 单入口，单出口（一个模块（或函数、过程、控制流图）有且仅有一个开始点和一个结束点。避免使用goto语句）

  • 模块的作用域应该在模块之内（尽量避免使用全局变量）

  • 功能应该是可预测的

• 内聚：指一个模块内部各元素（语句、方法、数据）之间结合的紧密程度。高内聚 意味着模块内的所有代码都共同完成一个单一的、明确的功能，职责单一

  类型	含义	评价
  功能内聚	模块只做一件事，且所有操作共同完成该功能	最好
  顺序内聚	模块内多个操作按顺序执行，上一个的输出是下一个的输入（如“读取数据→处理数据→输出结果”）	好
  通信内聚	多个操作访问同一数据，但彼此没有顺序关系	一般
  过程内聚	多个操作按特定顺序执行，但未必共享数据或协同完成单一功能	一般
  时间内聚	多个操作仅因为在同一时间执行而被放在一起（如初始化模块）	差
  逻辑内聚	多个功能通过一个控制标志选择执行（如一个函数根据参数做“添加/删除/修改”）	很差
  偶然内聚	多个完全无关的功能拼凑在一个模块里	最差

• 耦合：指多个模块之间相互依赖的程度。低耦合 意味着一个模块的变化对其他模块影响很小，模块之间通过简单的接口通信。

  类型	含义	评价
  无耦合	模块之间完全独立	理想但不现实
  数据耦合	只通过参数传递简单数据	最好
  印记耦合	传递整个数据结构，但只使用其中一部分（如传一个对象但只用它的一个字段）	较好
  控制耦合	一个模块通过传递控制标志，影响另一模块的内部逻辑	一般
  外部耦合	多个模块共享同一个全局变量或外部环境（如配置文件）	差
  公共耦合	多个模块共享同一个公共数据区（如全局变量）	很差
  内容耦合	一个模块直接修改另一个模块的内部数据或跳转到其内部标签	最差

• 模块结构设计

  • 基本任务：将系统划分为模块、确定软件的结构，模块的功能和模块间的接口，以及全局数据结构的设计

  • 模块的概念：模块是组成系统的基本单位，他的特点是可以组合、分解、更换

  • 模块的四要素

    • 输入和输出

    • 处理功能：指模块把输入转换成输出所做的工作

    • 内部数据：指仅供该模块本身引用的数据

    • 程序代码：指用来实现模块功能的程序

3.3面相对象设计

3.4软硬件协同设计