软件工程
软件危机:
- 软件不能很好的解决实际问题
- 软件不好维护
软件工程:
1. 软件生命周期:
软件在运行一段时间后彻底报废
2. 三个时期
3. 八个阶段：
| 阶段 | 关键问题 | 结束标准 |
|---|---|---|
| 问题分析 | 关于规模和目标的报告书 | |
| 可行性研究 | 系统的高层逻辑模型和数据流图以及成本/效益分析 | |
| 需求分析 | 系统的逻辑模型，数据流图，数据字典，算法描述 | |
| 总体设计: | 可能的解答：系统流程图，成本分析 | |
| 详细设计 | 编码规格 | |
| 编码/单元测试 | ||
| 综合测试 | ||
| 维护 | 改正性维护，适应性维护，完善性维护，预防性维护 |
软件开发模型:
1. 软件生存周期模型:
包括软件产品开发和运行和维护中有关过程活动和任务的框架，覆盖了从需求定义到系统使用的终止
- 基本特征：
- 描述了开发的主要阶段
- 每个阶段的主要过程
- 规范了每个阶段的输入
- 包含了每个阶段的框架
2. 常见模型:
==瀑布==
可行性研究与计划-->需求分析(纸质文档)--->设计(纸质文档)--->编码(纸质文档)--->测试-->运行--->评价----->计划(之后再进行需求分析)注意: 1. 不允许跨级返回 2. 每一阶段必须提供一个成品
特点:
- 阶段具有顺序性和依赖性
- 推迟实现的观点
- 质量保证的观点
缺点:
- 客户不能准确完整，全部的额宝打出自己的需求
- 缺乏灵活性
适应项目：
- 需求—-明确
- 方案—–成熟
- 项目—–短期项目
V(了解，类似于瀑布模型只不过要编写测试方案)
==增量==
把软件产品作为一系列的增量构件来设计，编码，集成，测试
特点:
假设需求是可分段的，称为一系列增量产品，每一增量可以单独开发
优点：
- 第一个交付的版本所需要的成本和时间少，占领市场
- 承担风险小
- 当配备人员不能在设定的期限内完成产品时，它提供一种推出核心产品的途径
- 逐步增加产品功能可以是用户有较充裕的时间学习和适应新产品
缺点:
- 软件体系结构必须是开放的
- 如果增量快过多的话，会增加管理成本
- 不同额度构建并行地创建又可能增加工程速度，但是不能集成的风险也会增大
计划-->需求--->概要--->针对每个构件完成详细设计，编码，测试，之后交付用户--->运行--->针对每个构件完成详细设计，编码，测试，之后交付用户-适应项目：
- 需求—–》改动
- 对于完成期限有严格要求，对市场和用户把握需要有逐步了解进行已有产品的升级开发
- 适用于商业软件的开发
实例:
- 微软“同步-稳定”增量模型
==快速原型==
快速建立一个能反应用户主要需求的原型系统，让客户使用，获取客户返回的需求完善产品
特点:
- 要快,造出原形系统
适应项目:
用户无法自主提出需求
希望减少需求的不确定性
项目小，较简单
==螺旋：==
每一个阶段都有一个风险分析
- 确定目标阶段
- 风险分析
- 实施工程
- 评估本阶段成果
适应项目:
适应于庞大，复杂，内部开发的项目
==喷泉==
支持面向对象的开发过程，体现了软件创建的固有的迭代和无缝隙的特征
需求分析无缝迭代
需求分析—设计—-需求分析—-设计—-需求分析—–设计
RUP统一(了解)
敏捷(了解)
软件开发方法学：
- 结构化开发方法
- 面向对象开发方法：
- 容易理解
- 稳定
- 复用
需求分析：
需求分析--->概要设计--->详细设计--->产品提交--->测试--->编码实施--->维护
1. 需求概述
1.1 需求分析的任务
- 获取需求，提交
用例图，类图，顺序图
软件需求获取过程
需求获取—>需求分析—>需求规格编写—>需求验证
UML概述
需求分析-OOA模型
用例图
用例文档
活动图
2.1 需求概述
2.1.1 需求分析任务
获取用户需求，从那个用户角度考虑，用户需要系统必须完成那些工作
提交主要文档
- 功能需求： 系统必须完成的功能
- 性能要求: 交换律速度，有效性，准确性，响应时间
- 可靠性需求: 故障的频率和严重性，结果的准确性，故障的平均时间，恢复能力
- 可用行需求: 恩威因素(审美，医学，医用)和界面，文档，培训资料的一致性
- 可支持性： 可扩展性，适应性，耐用性。。。
- 逆向需求：系统不能做什么
- 其他: 出错处理
需求的基本性质：
- 必要的
- 无歧义的
- 可测试的
- 可测量的
- 可跟踪的
==自悟==
==访谈==
==小组会==
UML统一建模为面向对象软件这几提供统一的标准的可视化建模语言
