UML基础案例与应用第一章绪论
文章目录
- UML基础案例与应用第一章绪论
- 瀑布模型
- 快速原型模型
- 增量模型
- 螺旋模型
- 基于组件的开发模型
- 软件过程
- 软件规格
- 软件的设计与实现
- 软件确认
- 软件演化
- 软件过程模型
软件过程
软件过程是软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。
软件过程应该有明确的定义
- 团队人员的工作和职责
- 所执行的活动及其顺序关系
- 活动的内容和步骤
软件过程的目标：
- 标准化、预见性、生产率、高质量、计划进度和遇见的能力
软件过程的基本活动：
- 规格说明( s p e c i f i c a t i o n specification specification)定义软件功能及对使用的限制
- 软件开发( D e v e l o p m e n t Development Development)设计和实现满足规格说明的软件
- 软件确认( v a l i d a t i o n validation validation)验证软件以保证满足客户的要求
- 软件演化( E v o l u t i o n Evolution Evolution)改进软件以适应不断变化的需求
软件规格
软件规格说明是确定系统需要的服务以及运行和开发中约束的过程，也称为需求过程
软件的设计与实现
软件设计是根据需求规格说明，确定软件体系结构，进一步设计每个系统部件的实现算法、数据结构及其接口等。软件实现是将软件设计转换成程序代码。
软件确认
验证和确认需要指出软件是否符合规格说明以及是否满足客户的需求
- 验证和确认包括检查和评审过程以及系统测试
- 系统测试是使用由规格说明产生的测试用例执行软件的过程
软件演化
软件的内在本质是灵活的的可变的
- 随着业务需求的变化，软件必须进化和变更
- 尽管在开发过程和演化（维护）过程之间存在划分，但是现实中全新的系统越来越少
认识软件演化过程
- 好的软件需要维护
- 维护软件的成本很高的，应在开发阶段考虑维护的问题
- 文档是很重要的，但在实际开发过程中经常存在文档过时或缺少文档的情况
软件过程模型
软件过程模型是对实际过程的抽象描述，包括软件过程的活动，软件产品以及人员的不同角色
常见的软件过程模型
- 瀑布模型
- 快速原型模型
- 增量模型
- 螺旋模型
- 形式化方法模型
- 基于组件的开发模型
瀑布模型
适用于：在开发的早期阶段软件需求被完整确定
挑战：实际的项目开发很少是线性的过程，客户很难明确地描述软件的需求
缺点：
- 各个阶段的划分完全固定，阶段之间产生大量文档，极大的增加了工作量
- 开发过程中很难响应客户的变更需求
- 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
快速原型模型
快速原型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识。
目的：减少开发风险和需求的不确定性
缺点：
- 原型系统的内部可能结构不好
- 开发人员需要掌握建立快速原型的开发技术和工具
适用于：
- 小型或中等规模的交换式系统
- 大型系统的某些部分，例如用户界面
- 生命周期较短的系统
增量模型
优点：
- 整个产品分解成若干个构件逐步交付，用户可以不断地看到所开发的软件的可运行的中间版本
- 将早期增量作为原型有助于明确后期增量的需求
- 降低开发风险
- 重要功能首先交互，从而使其得到最大的测试
缺点
- 需要软件具备开放式的体系结构
- 需求难以在增量实现之前详细定义，因此增量于需求的准确映射以及所有增量的有效集成可能回比较困难
- 容易退化为边做边改方式，使软件过程的控制失去整体性
螺旋模型
螺旋回线：每一个回线表示开发过程的一个阶段
四个步骤
- 缺点阶段目标、完成这些目标的可选方案及其约束条件
- 从风险角度分析方案的开发策略，努力排除各种潜在风险，在需求不适当的情况下可能需要建造原型系统
- 软件开发和验证工作
- 评价该阶段的结果，并规划下一个开发阶段
优点：
- 关注软件的重用
- 关注早期错误的消除
- 将质量目标放在首位
- 将开发阶段与维护阶段结合在一起
缺点
- 契约开发通常需要事先指定过程模型和发布产品
- 需要风险评估的经验
基于组件的开发模型
基于组件的开发技术是使用可重用的组件或商业组件建立复杂的软件系统。
组件开发的两个重要因素
- 基于组件的软件体系结构
- 基于组件的开发过程
优点
- 充分体现了软件复用的思想
- 实现快速交付软件
缺点
- 商业组件的修改受到限制，影响系统的演化
