第七章 嵌入式系统开发与维护知识

系统开发过程及项目管理

开发模型

• 瀑布模型（SDLC）

• 演化模型

• 增量模型

• 螺旋模型

• 快速应用开发模型

• 喷泉模型

• V模型

• 构件组装模型/基于构件的开发方法

• 迭代模型/迭代开发方法

• 统一过程/统一开发方法

• 敏捷开发方法

  • 极限编程（XP)
  • 水晶方法系列（Crystal），其目的是发展一种提倡“机动性”方法，包含具有共性的核心元素，每个都含有独特的角色、过程模式、工作产品和实践
    • Crystal家族实际上是一组经过证明、对不同类型项目非常有效的敏捷过程，它的发明使得敏捷团队可以根据其项目和环境选择最合适的Crystal家族成员
    • 与XP的对比
      • 它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。Crystal考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Crystal探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡
      • 也就是说，虽然水晶系统不如XP那样的产出效率，但会有更多的人能接受并遵循它
  • 开放式源码，这里提到的开放式源码指的是开放源码界所用的一种运作方式
    • 开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作
    • 开放源码的一个突出特点就是查错排障的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库
  • 并列争球法（Scrum），该方法强调了这样一个事实，即明确定义了的可重复的方法过程，只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题
    • 运用了“迭代”的方法，把每段时间（例如30天）一次的迭代称为一个冲刺，并按需求的优先级别来实现产品，有多个自治组织和自治小组并行的递增来实现产品
    • 极限编程（XP）和并列争球法（Scrum）区别
      • 迭代长度的不同
      • 在迭代中，是否允许修改需求
      • 在迭代中，User Story是否严格按照优先级别来实现
      • 软件的实施过程中，是否采用严格的工程方法，保证进度或者质量
  • Coad的功用驱动开发方法（FDD-Feature Driven Development）FDD是由Jeff De Luca和大师Peter Coad提出来的。
    • 像其他方法一样，它致力于短时的迭代阶段和可见可用的功能
    • 在FDD中，一个迭代周期一般是两周
    • 在FDD中，编程开发人员分成两类：首席程序员和“类”程序员（class owner）。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序员则主要做源码编写
  • 自适应软件开发方法（ASD方法），ASD（Adaptive Software Development）方法由Jim Highsmith提出，其核心是三个非线性的、重叠的开发阶段：猜测、合作和学习
  • 动态系统开发方法（也称为业务中心框架开发方法，DSDM），它倡导以业务为核心，快速而有效的进行系统开发。我们可以把DSDM看成一种控制框架，重点在于快速交付，并补充如何应用这些控制的指导原则的框架。
    • DSDM是一整套的方法论，不仅仅包括软件开发内容和实践，也包括了组织结构，项目管理，估算，工具环境，测试，配置管理，风险管理，重用等各个方面的内容

项目管理

• 时间管理

• 时间管理-PERT图

• 时间管理-关键路径法

  • 关键路径法是在制定进度计划时使用的一种进度网络分析技术。关键路线法沿着项目进度网络路线进行正向与反向分析，从而计算出所有计划活动理论上的最早开始与完成日期、最迟开始与完成日期，不考虑任何资源限制
  • 总时差（松弛时间）：在不延误总工期的前提下，该活动的机动时间。活动的总时差等于该活动最迟完成时间与最早完成时间之差，或该活动最迟开始时间与最早开始时间之差

• 时间管理-甘特图

  • 优点：甘特图直观、简单、容易制作，便于理解，能很清晰地标识出直到每一项任务的起始与结束时间，一般适用比较简单的小型项目，可用于WBS的任何层次、进度控制、资源优化、编制资源和费用计划
  • 缺点：不能系统地表达一个项目所包含的各项工作之间的复杂关系了，难以进行定量的计算和分析，以及计划的优化等

• 软件配置管理

  • IEEE对配置项的定义为硬件、软件或二者兼有的集合，为配置管理制指定的，在配置管理过程中作为一个单独的实体对待，可作为配置项管理的有：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
    • 典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理（SCM)
    • 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者和日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。
    • 配置项及其历史记录反映了软件的演化过程。
  • 
  • 检查点：指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整
  • 里程碑：完成阶段性工作的标志，不同类型的项目里程碑不同
  • 基线：指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线是一些重要的里程碑，但相关交付成果要通过正式评审，并作为后续工作的基准和出发点。基线一旦建立后期变化需要受控制
    • 功能基线（定义基线）：是指在系统分析和软件定义阶段结束的时候经过正式评审和批准的系统设计规格说明书，这就是功能基线
    • 分配基线（需求基线）：也叫指派基线，它是指软件需求分析阶段结束时，经过正式评审和批准的软件需求规格说明书（SRS）
    • 产品基线：是指在软件组装和系统测试阶段结束时，经过正式评审和批准的有关开发的软件产品的全部配置项的规格说明

• 变更控制：按照变更控制系统来管理变更，所谓变更管理的控制系统它是一套实现所确定的修改项目文件或者改变项目活动的时候应该遵循的程序

• 版本控制：控制版本其实就是软件配置项的版本控制，因为所有配置项在标识的阶段已经描述了版本以及日期的相关信息，那么随着项目的开展，这些配置项可能要修改，要发生变更，变更以后那么版本要升级，整个这个过程叫版本控制

  • 总的来讲，配置项有三个状态，草稿状态、正式状态和修改状态
  • 那么整个版本控制的话，要明确一个版本的规则

• 风险的分类

  • 项目风险
    • 潜在的预算、进度、人员和组织、资源、用户和需求问题
    • 项目复杂性、规模和结构的不确定性
  • 技术风险
    • 潜在的设计、实现、接口、测试和维护方面的问题
    • 规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）
  • 商业风险
    • 市场风险：系统虽然很优秀但不是市场真正所想要的
    • 策略风险：系统不再符合企业的信息系统战略
    • 销售风险：开发了销售部门不清除如何推销的系统
    • 管理风险：由于重点转移或人员变动而失去上级支持
    • 预算风险：开发过程没有得到预算或人员的保证

软件过程改进

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

• 每个成熟度等级被分解成几个关键过程域，共18个关键过程域（KPA）

  成熟度等级\过程分类	管理方面	组织方面	工程方面
  优化级		技术变更管理、过程变更管理	缺陷预防
  已管理级	量化过程管理		软件质量管理
  已定义级	集成软件管理、组间合作	组织过程焦点、组织过程定义、培训计划	软件产品过程、同行评审
  可重复级	需求管理、软件项目计划、软件项目跟踪与监控、软件子合同管理、软件质量保证、软件配置管理

系统分析基础知识

需求工程概述

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

需求分类

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

需求分析

• 数据流图 DFD

• 状态行为图 STD

• ER图

• 面向对象-UML

  • 构造块
    • 事物
      • 结构事物：最静态的部分，包括：类、接口、构件、协作、用例、活动类和节点
      • 行为事物：代表时间和空间上的动作。交互和状态机，包括：消息、动作次序
      • 分组事物：看成是个盒子，如：包、构件
      • 注释事物：UML模型的解释部分。用来描述、说明和标注模型的任何元素。如注解
    • 关系
      • 依赖关系：一个事物发生变化会影响另一个事物
      • 关联关系：所描述的是一组对象之间连接的结构关系
        • 聚合关系：整体和部分生命周期不同
        • 组合关系：整体和部分生命周期相同
      • 泛化关系：一般/特殊关系
      • 实现关系：接口和类之间的关系
    • 图
  • 规则
  • 公共机制
    • 规格说明：事物语义的细节描述，它是模型真正的核心
    • 修饰：通过修饰来表达更多的信息
    • 公共分类：类与对象、接口与实现
    • 扩展机制：允许添加新的规则

• UML图

  • 静态图
    • 类图
    • 对象图
    • 构件图
    • 部署图：软硬件之间映射
    • 制品图
    • 包图
    • 组合结构图
  • 动态图
    • 用例图：系统和外部参与者的交互
    • 顺序图：强调按时间顺序
    • 通信图：强调收发消息的对象、或者参与者的一种结构或组织
    • 状态图：状态转换变迁
    • 活动图：类似程序流程图，并行行为
    • 定时图：强调消息跨越不同对象的实际时间
    • 交互概览图：是活动图和顺序图的混合物

系统设计知识

结构化设计

• 内聚（从高到低）

  • 功能内聚：完成一个单一功能，各个部分协同工作，缺一不可
  • 顺序内聚：处理元素相关，而且必须顺序执行（有数据传递）
  • 通信内聚：所有处理元素集中在一个数据结构的区域上（使用相同数据）
  • 过程内聚：处理元素相关，而且必须按特定次序执行（无数据传递）
  • 瞬时内聚：所包含的任务必须在同一时间间隔内执行（如初始化）（时间因素）
  • 逻辑内聚：完成逻辑上相关的一组任务（传递参数）
  • 偶然内聚：完成一组没有关系或松散关系的任务

• 耦合（从低到高）

  • 非直接耦合：没有直接联系，互相不依赖对方
  • 数据耦合：两个模块彼此间通过数据参数交换信息
  • 标记耦合：组模块通过参数表传递记录信息，这个记录是某一个数据结构的子结构，而不是简单变量
  • 控制耦合：模块间传递的信息中包含用于控制模块内部逻辑的信息
  • 外部耦合：模块间访问同一全局简单变量
  • 公共耦合：多个模块引用同一个全局数据结构
  • 内容耦合：一个模块访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口

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

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

• 模块的四要素

  • 输入和输出
  • 处理功能：指模块把输入转换成输出所做的工作
  • 内部数据：指仅供该模块本身引用的数据
  • 程序代码：指用来实现模块功能的程序

面向对象设计

软硬件协同设计