开发模型
瀑布模型(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),静态图(结构体)、动态图(行为图)
- 构造块
- 事物
- 关系
- 图
结构化设计
- 抽象化
- 自顶向下,逐步求精
- 信息隐蔽
- 模块独立(高内聚,低耦合)
模块设计原则
- 保持模块大小适中
- 尽可能减少调用深度
- 多扇入,少扇出
- 单入口,单出口
- 模块的作用域应该在模块之内
- 功能应该是可预测的
内聚类型 | 描述 |
---|---|
功能内聚 | 完成单一功能,各个部分协同工作,缺一不可 |
顺序内聚 | 各个部分必须按照顺序执行(有数据传递) |
通信内聚 | 所有处理元素,集中在一个数据结构的区域上(使用相同数据) |
过程内聚 | 各个部分必须按照顺序执行(无数据传递) |
瞬时内聚/时间内聚 | 包含的任务,必须在同一时间间隔内执行(初始化) |
逻辑内聚 | 逻辑上相关的一组任务(有传参) |
偶然内聚 | 没关系或松散关系 |
耦合类型 | 描述 |
---|---|
内容耦合 | 一个模块直接访问另一个模块的内部数据 |
公共耦合 | 多个模块引用同一个全局数据结构 |
外部耦合 | 依赖同一个全局变量 |
控制耦合 | 传递控制信息,控制另一个模块 |
标记耦合 | 通过参数记录表(一个数据结构的子结构,不是简单变量) |
数据耦合 | 一个模块通过参数传递数据给另一个模块 |
非直接耦合 | 两个模块之间没有直接的联系 |
结构化设计的基本任务:将系统划分为模块、确定软件的结构、设计模块间的接口
模块的概念:组成系统的基本单位,可以组合、分解、替换