目录
软件工程学概述
软件危机
软件危机的介绍
- 软件危机：指在计算机软件的开发和维护过程中所遭遇的一系列严重问题
- 软件危机包含以下两个方面的问题
- 如何开发软件，以满足社会对软件日益增长的需求
- 如何更有效地维护数量不断膨胀的已有软件
- 软件=程序+文档+数据
- 典型表现
- 产品不符合用户的实际需求
- 软件开发生产率不高，不能满足客观需要
- 软件产品质量差
- 对软件开发成本和进度的估计不准确
- 可维护性差
- 软件的文档资料不完整和不合格
- 软件成本逐年上升
产生软件危机的原因
- 宏观
- 缺乏总体考虑，没有软件工程学概念或系统工程思想。 ——软件
- 对业务了解支离破碎，需求分析不准。 ——软件
- 企业依赖激情指挥，企业管理标准化、规范化、科学化程度不高，导致不能成功地应用“死板”的软件，它依赖于业务的“科学化”、“条理化”、“程序化”。 ——企业
- 企业信息化程度和计算机应用水平低，导致无法准确描述需求。 ——企业
- 一把手对信息管理的重视程度不够。 ——企业
- 缺乏相互沟通，业务描述的详尽程度不能达到具备生活常识的人能够轻易理解。 ——企业、软件
- 微观
- 软件的规模比较庞大，其开发和维护相当困难
- 开发人员虽然有经验，但还存在着不少错误观点，没有实行工程化的方法
- 不能于用户及时沟通，不能了解用户的实际需要
- 没有统一的软件质量管理规范
- 不能根据环境的变化而随时对产品进行改正
软件工程
软件工程的介绍
- 定义：软件工程是指导计算机软件开发和维护的一门工程学科，该学科的目的是生产出能按期交付的、在预算范围内的、满足用户需求的、质量合格的软件产品
- 说明：把软件当作一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护
- 目的：实现按预期的进度和经费完成软件生产计划，提高软件的生产率和可靠性
- 软件工程具有以下本质特性
- 软件工程关注于大型程序的构造
- 软件工程的中心课题是控制复杂性
- 软件产品交付使用后仍然需要经常修改
- 开发软件的效率非常重要
- 开发人员和谐地合作是成功开发软件的关键
- 软件必须有效地支持它的用户
- 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人开发产品
软件工程的基本原理
- 用分阶段的生命周期计划严格管理
- 坚持进行阶段评审
- 实行严格的产品控制
- 采用现代程序设计技术
- 结果应能清楚地审查
- 开发小组的人员应该少而精
- 承认不断改进软件工程实践的必要性
软件工程方法学
- 三要素：工具、方法、过程
- 传统方法学（生命周期方法学/结构化范型）
- 采用结构化技术（结构化分析、结构化设计、结构化实现）完成软件开发的各项任务
- 把软件生命周期划分成若干个阶段，然后顺序完成各个阶段的任务
- 每个阶段的开始和结束都有严格的标准，对于任何两个相邻的阶段而言，前一阶段的结束标准就是后一个阶段的开始标准
- 在每个阶段结束之前都必须正式地进行严格的技术审查和管理复审
- 面向对象方法学（面向对象范型）
- 把对象作为融合了数据及在数据上操作的软件构件（用对象分解取代传统方法的功能分解）。
- 把所有对象都划分成类
- 按照父类与子类的关系，把若干个相关类组织成一个层次结构的系统
- 对象彼此间仅能通过发送消息互相联系
软件生命周期
- 软件生命周期由软件定义、软件开发和运行维护（软件维护）3个时期组成
- 软件定义时期
- 任务：确定软件开发工程必须完成的总目标；确定工程的可行性；导出实现工程目标应该采用的策略及系统必须完成的功能；估计完成该项工程需要的资源和成本，并且制定工程进度表
- 由系统分析员负责
- 3个阶段：问题定义、可行性研究、需求分析
- 软件开发时期
- 4个阶段：总体设计，详细设计，编码和单元测试，综合测试（前两个称为系统设计、后两个称为系统实现）
- 软件维护时期
- 任务：通过对已交付使用的软件做必要的修改，使软件持久地满足用户的需要
软件过程
- 软件过程定义了运用技术方法的顺序、应该交付的文档资料、为保证软件质量和协调软件变化必须采取的管理措施，以及标志完成了相应开发活动的里程碑
瀑布模型
- 主要优点
- 强迫开发人员采用规范的技术方法
- 严格地规定了每个阶段必须提交的文档
- 每个阶段结束前必须正式进行严格的技术审查和管理复审
- 主要缺点
- 在可运行的软件产品交付给用户之前，用户只能通过文档来了解未来的产品是什么样的
- 开发人员和用户之间缺乏有效的沟通，很可能导致最终开发出的软件产品不能真正满足用户的需求
- 可维护性差
- 选择模型的条件
- 在开发时间内需求没有或很少变化
- 分析设计人员对应用领域很熟悉
- 低风险项目（对目标、环境很熟悉）
- 用户使用环境很稳定
- 用户除提出需求以外，很少参与开发
增量模型
- 定义：增量模型将软件产品看作一组增量构件，每次设计、实现、集成、测试和交付一块构件，直到所有构件全部实现为止
- 本意：要开发一个大的软件系统，先开发其中的一个核心模块，后再开发其他模块，这样一个个模块地增加上去，直至整个系统开发完毕为止
- 主要优点
- 能在较短时间内向用户提交可完成部分工作的产品
- 逐步增加产品功能，从而使用户有较充裕的时间学习和适应新产品，减少一个全新的软件给用户所带来的冲击
快速原型模型
- 快速建立起来的、可在计算机上运行的程序，它所能完成的功能往往是最终的软件产品所能完成功能的子集。
- 主要优点
- 使用这种软件过程开发的软件产品通常能满足用户的真实需求
- 软件产品的开发过程基本上是线性顺序过程
- 选择条件：用户需求不明确、需求经常变化，系统规模不是很大
螺旋模型
- 基本思想：使用原型及其他方法尽量降低风险（在每个阶段之前都增加了风险分析过程的快速原型模型）
- 构建原型是一种能使某些类型的风险降至最低的方法
- 主要适用于庞大、复杂并且具有高风险的系统
- 主要优点
- 有利于已有软件的重用
- 有助于把软件质量作为软件开发的一个重要目标
- 减少了过多测试或测试不足所带来的风险
- 软件维护与软件开发没有本质区别
- 使用螺旋模型开发软件，要求软件开发人员具有丰富的风险评估知识和经验
喷泉模型
- 迭代是软件开发过程中普遍存在的一种内在属性
- 以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法，迭代无间隙
Rational统一过程（RUP）
- 最佳实践
- 采用迭代式开发
- 有效地管理需求
- 使用基于构件的体系结构
- 可视化建模
- 验证软件质量
- 控制软件变更
- RUP软件开发生命周期
敏捷过程与极限编程
- 敏捷过程4个价值观
- 开发人员的素质及相互之间的交互与协作比过程和工具更重要
- 可以工作的软件比面面俱到的文档更重要
- 与客户的合作比合同谈判更重要
- 及时响应变化比死板地遵循计划更重要
- 极限编程
- 4个价值观：沟通、简单性、勇气、反馈
- 5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作
- 最佳实践：计划游戏、隐喻、小型发布、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准
微软过程
8961
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
