【原文链接】系统架构设计师(第二版)学习笔记----软件工程
文章目录
- 一、软件工程
- 1.1 软件危机的表现
- 1.2 软件工程的内容
- 二、软件过程模型
- 2.1 软件的声明周期
- 2.2 瀑布模型
- 2.3 瀑布模型的缺点
- 2.4 原型模型
- 2.5 原型模型开发阶段
- 2.6 开发原型的途径
- 2.7 螺旋模型
- 2.8 螺旋模型每个阶段的组成
- 三、敏捷模型
- 3.1 敏捷型方法的特点
- 3.2 敏捷方法的核心思想
- 3.3 常见的敏捷方法实践
- 3.4 极限编程的基础和价值
- 3.5 FDD认为软件开发需要的3要素
- 3.6 FDD定义了6中项目角色
- 3.7 FDD的5个核心过程
- 四、统一过程模型(RUP:Rational Unified Process)
- 4.1 RUP的生命周期
- 4.2 RUP中每个循环中的过程
- 4.3 RUP中的核心概念
- 4.4 RUP的特点
- 4.5 RUP的视图模型
- 4.6 软件开发采用迭代和增量的好处
- 五、软件能力成熟度模型
- 5.1 CMMI的5个成熟度等级
一、软件工程
1.1 软件危机的表现
- 软件开发进度难以预测
- 软件开发成本难以控制
- 软件功能难以满足用户期望
- 软件质量无法保证
- 软件难以维护
- 软件缺少适当的文档资料
1.2 软件工程的内容
- P(Plan):软件规格说明,规定软件功能及其运行时的限制
- D(Do):软件开发,开发出满足规格说明的软件
- C(Check):软件确认,确认开发的软件能够满足用户的需求
- A(Action):软件演进,软件在运行过程中不断改进以满足客户新的需求
二、软件过程模型
2.1 软件的声明周期
- 需求分析
- 软件设计
- 软件开发
- 运行维护
- 淘汰
2.2 瀑布模型
- 需求分析
- 系统设计
- 程序设计
- 编码实现
- 单元测试
- 集成测试
- 系统测试
- 运行维护
2.3 瀑布模型的缺点
- 软件需求的完整性、正确性等很难确定,甚至是不可能和不现实的
- 瀑布模型是一个严格串行化的过程模型,使得用户和软件项目负责人要相当长时间才能得到一个可以看得见的软件系统。如果出现于用户的期望不一致、或者出现需求变更,将会带来巨大的损失
- 瀑布模型的基本原则是在每个阶段一次性地完全解决该阶段的工作,不会出现遗漏、错误等情况,二实际上这是不现实或者不可能的。
2.4 原型模型
2.5 原型模型开发阶段
- 原型开发阶段
- 目标软件开发阶段
2.6 开发原型的途径
- 利用模拟软件系统的人机界面和人际交互方式
- 真正开发一个原型
- 找来一个或几个正在运行的类似软件进行比较
2.7 螺旋模型
2.8 螺旋模型每个阶段的组成
- 目标设定
- 风险分析
- 开发和有效验证
- 评审
三、敏捷模型
3.1 敏捷型方法的特点
- 敏捷方法是“适应性”而非“预设性”
- 敏捷方法是“面向人”而非“面向过程”
3.2 敏捷方法的核心思想
- 敏捷方法是适应型,而非可预测型
- 敏捷方法是以人文本,而非以过程为本
- 迭代增量式的开发过程
3.3 常见的敏捷方法实践
- 极限编程(XP)
- 水晶系列方法
- Scrum
- 特征驱动开发方法(FDD)
3.4 极限编程的基础和价值
- 加强交流
- 从简单做起
- 寻求反馈
- 勇于实事求是
3.5 FDD认为软件开发需要的3要素
- 人
- 过程
- 技术
3.6 FDD定义了6中项目角色
- 项目经理
- 首席架构师
- 开发经理
- 主程序员
- 程序员
- 领域专家
3.7 FDD的5个核心过程
- 开发整体对象模型
- 构造特征列表
- 计划特征开发
- 特征设计
- 特征构建
四、统一过程模型(RUP:Rational Unified Process)
4.1 RUP的生命周期
- 业务建模
- 需求
- 分析与设计
- 实现
- 测试
- 部署
- 配置与变更管理
- 环境
4.2 RUP中每个循环中的过程
- 初始阶段:定义最终产品视图和业务模型,并确定系统范围
- 细化阶段:设计及确定系统的体系结构,指定工作计划及资源要求
- 构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交
- 移交阶段:把产品提交给用户使用
4.3 RUP中的核心概念
- 角色(Role):Who的问题
- 活动(Activity):How的问题
- 制品(Artifacts):What的问题
- 工作流(Workflow):When的问题
4.4 RUP的特点
- 用例驱动
- 以体系结构为中心
- 迭代和增量
4.5 RUP的视图模型
- 用例视图
- 逻辑视图
- 实现视图
- 进程视图
- 部署视图
4.6 软件开发采用迭代和增量的好处
- 在软件开发的早起就可以对关键的、影响大的风险进行处理
- 可以提出一个软件体系结构来指导开发
- 可以更好的处理不可避免的需求变更
- 可以较早得到一个可运行的系统,鼓舞开发团队的士气,增强项目成功信心
- 为开发人员提供一个能更有效工作的开发过程
五、软件能力成熟度模型
5.1 CMMI的5个成熟度等级
- Level 1 初始级
- Level 2 已管理级
- Level 3 已定义级
- Level 4 量化管理级
- Level 5 优化级