嵌入式系统开发与维护知识
2024-5-19 21:30:56 Author: www.chenxublog.com(查看原文) 阅读量:7 收藏

开发模型

瀑布模型(SDLC,Software development lifecycle 软件开发生命周期)

需求明确的项目/二次开发项目适合使用

有利于项目管理,不适用于需求变化频繁的项目

阶段步骤
定义阶段软件计划
^需求分析
开发阶段软件设计
^程序编码
^软件测试
维护阶段运行维护

改进型的瀑布模型:每个阶段可以回溯,应对需求变化

改进的模型

基于原型,适用需求不明确时,用户参与过多会很难控制项目进度

  • 演化模型(变换模型):原型演化为产品
  • 螺旋模型:从不可用原型开始迭代,最后才发布可操作产品
  • 增量模型:每个版本均发布一个可操作的产品

V模型

需求分析 ↓      ↑ 验收测试
概要分析 ↓      ↑ 系统测试
详细设计 ↓      ↑ 集成测试
    编码 ↓      ↑ 单元测试
          [V模型]

喷泉模型

面向对象的模型

RAD(快速应用开发)

基于SDLC(软件开发生命周期)和CBSD(构件业务软件开发),基于构建来开发,一个控件一个控件开发

构建组装模型

构建可以在不同项目中使用

需求分析和定义→软件架构设计→
(构件库,构建获取,构建管理)构件库的建立(构建标准嵌入CORBA、COM/DCOM、EJB)→
应用软件构建→测试和发布

敏捷开发

每次发布版本都是一个可用的产品(不是完整功能)

符合敏捷宣言就是敏捷开发方法:

  • 个体和交互,胜过了过程和工具
  • 可工作的软件,胜过了大量的文档
  • 客户合作,胜过了合同谈判
  • 响应变化,胜过了遵循计划

基本原则:短平快会议、小型版本发布、较少的文档、合作为重、客户直接参与、自动化测试、适应性计划调整、结对编程、测试驱动开发、持续集成、重构

有几种:

  • 自适应开发
  • 水晶方法
  • 功用驱动开发
  • 极限编程 XP(用的最多)

XP 更关注技术和工程实践,而 Scrum 更关注团队协作和管理实践

水晶方法 Crystal

用最少的纪律约束,而仍能成功的方法

开放式源码

  • 开发人员在地理位置上分布很广
  • 查错排障高度并行性

并列争球法 Scrum

  • 开发中不能增改需求
  • 明确定义了可重复的方法过程
  • 用迭代方法,每段时间称为一个冲刺(2-4周)
  • 按优先级实现产品功能(不严格)
  • 小组并行开发

功用驱动开发 FDD

  • 开发人员分为:首席程序员“类”程序员

自适应软件开发 ASD

非线性、重叠的开发阶段:猜测、合作、学习

DSDM 动态系统开发方法

以业务为核心

项目管理

进度管理、时间管理

活动定义、活动排序、持续资源估算、活动历时估算、制定进度计划、进度控制

算那个图

软件配置管理

放到配置管理中的

  • 项目计划书、需求文档、设计文档、源码、可执行代码、测试用例、运行软件所需的各种数据
  • 属性:名称、标识符、文件状态、版本、作者、日期

三个库

  • 开发库(动态库。程序员库,工作库):开发人员在开发的
  • 受控库(动态库。主库,系统库):从开发库,经过测试区,通过测试的代码
  • 产品库(静态库。备份库,软件仓库)

三个名词

  • 检查点:规定时间间隔,对项目进行检查,对和需求的差异进行调整
  • 里程碑:完成阶段性工作的标志
  • 基线:一种重要的里程碑,通过正式评审,进入受控的状态

基线的类型

  • 功能基线(定义基线):系统分析、软件定义结束后,经过评审确定的
  • 分配基线(需求基线):需求分配阶段结束后,经过评审和批准
  • 产品基线:综合测试结束后,经过测试、评审、批准通过的软件产品的全部配置项的规格说明书

基线并更后,需要按变更控制流程,申请变更

软件过程改进(CMM)

评价软件企业的质量保证能力,软件研制和软件测试中的质量保证能力

  • 初始级:无纪律规则,英雄主义
  • 可重复级:纪律化,项目级别
  • 已定义级:标准化,组织级别
  • 已管理级:可量化
  • 优化级:缺陷预防

关键过程域(KPA)

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

需求工程

软件需求分析阶段

  • 需求开发↓需求基线
  • 需求分析↑支持

需求开发

  • 需求获取
  • 需求分析
  • 需求定义(规格说明书)
  • 需求验证

需求分析

  • 变更控制
  • 版本控制
  • 需求跟踪
  • 需求状态跟踪

需求分类

  • 业务需求(整体全局)
  • 用户需求(用户视角)
  • 系统需求(计算机化)
    • 功能需求
    • 非功能需求
    • 设计约束

结构化分析

数据字典

  • 功能模型(数据流图 DFD,一种静态行为)
    • 数据流
    • 加工
    • 数据存储
    • 外部实体
  • 行为模型(状态转换图 STD,一种动态行为)
    • 状态
    • 事件
    • 起点
    • 终点
  • 数据模型(E-R图,实体的静态结构),对数据进行描述
    • 实体
    • 联系
    • 连线
    • 属性

面向对象分析

统一建模语言(UML),静态图(结构体)、动态图(行为图)

  • 构造块
    • 事物
    • 关系

结构化设计

  • 抽象化
  • 自顶向下,逐步求精
  • 信息隐蔽
  • 模块独立(高内聚,低耦合)

模块设计原则

  • 保持模块大小适中
  • 尽可能减少调用深度
  • 多扇入,少扇出
  • 单入口,单出口
  • 模块的作用域应该在模块之内
  • 功能应该是可预测的
内聚类型描述
功能内聚完成单一功能,各个部分协同工作,缺一不可
顺序内聚各个部分必须按照顺序执行(有数据传递)
通信内聚所有处理元素,集中在一个数据结构的区域上(使用相同数据)
过程内聚各个部分必须按照顺序执行(无数据传递)
瞬时内聚/时间内聚包含的任务,必须在同一时间间隔内执行(初始化)
逻辑内聚逻辑上相关的一组任务(有传参)
偶然内聚没关系或松散关系
耦合类型描述
内容耦合一个模块直接访问另一个模块的内部数据
公共耦合多个模块引用同一个全局数据结构
外部耦合依赖同一个全局变量
控制耦合传递控制信息,控制另一个模块
标记耦合通过参数记录表(一个数据结构的子结构,不是简单变量)
数据耦合一个模块通过参数传递数据给另一个模块
非直接耦合两个模块之间没有直接的联系

结构化设计的基本任务:将系统划分为模块、确定软件的结构、设计模块间的接口

模块的概念:组成系统的基本单位,可以组合、分解、替换


文章来源: https://www.chenxublog.com/2024/05/19/embedded-system-development-and-maintenance.html
如有侵权请联系:admin#unsafe.sh