1 软件危机
- 为吸取历史经验教训 ,应该认真研究产生软件危机的原因 ,探讨消除软件危机的途径 。
1.1 软件危机介绍
- 软件危机:把在计算机软件的开发与维护过程中所遇到的一系列严重问题笼统为软件危机。又可称 软件萧条 或 软件困扰
软件危机包含两方面的问题 :
- 如何开发软件 ,以满足社会对软件日益增长的需求 ;
- 如何更有效地维护数量不断膨胀的已有软件 。
软件危机典型表现 :
- 对软件开发成本和进度的估计不准确 。
- 用户对“已完成的”软件产品不满意 。
- 软件产品的质量达不到要求 。
- 软件难维护的。
- 软件没有适当的文档资料 。
- 软件成本在计算机系统总成本中所占的比例逐年上升 。
- 软件开发生产率提高的速度不能满足社会对软件产品日益增长的需求 。
1.2 软件危机产生原因
- 客观原因:(1)软件缺乏可见性,维护难;(2)软件规模大,难以预见可能遇到的每一种情况。
- 主观原因:软件工程师在实际工作中采用了错误的方法。
1.3 消除软件危机的途径
为了消除软件危机 ,既要有技术措施(方法和工具) ,又要有必要的组织管理措施 。 软件工程正是从技术和管理两方面研究如何更好地开发和维护软件的一门新兴的工程学科 。
2 软件工程
2.1 软件工程简介
软件工程是指导计算机软件开发和维护的一门工程学科 ,其目的是生产出能按期交付的 、在预算范围内的 、满足用户需求的 、质量合格的软件产品 。
软件工程的本质特性 :
- 软件工程关注大型程序的构造 。
- 软件工程的中心课题是控制复杂性 。
- 软件经常变化 。
- 软件开发效率很重要 。
- 开发人员应和谐合作 。
- 软件必须有效地支持它的用户 。
- 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人开发产品 。
2.2 软件工程的基本原理
- 用分阶段的生命周期计划严格管理 。
- 坚持进行阶段评审 。
- 实行严格的产品控制 。
- 采用现代程序设计技术 。
- 能清楚地审查结果 。
- 开发小组人员应少而精 。
- 承认不断改进软件工程实践的必要性 。
2.3 软件工程方法学
- 方法学:把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学 ,也称为范型 。
软件工程方法学包含 3 个要素 :
- 方法:方法是完成软件开发各项任务的技术方法 ,回答“怎样做”的问题 ;
- 工具:法是完成软件开发各项任务的技术方法 ,回答“怎样做”的问题 ;
- 过程:过程是为了获得高质量的软件所需要完成的一系列任务的框架 ,规定完成各项任务的工作步骤 ,回答“何时做”的问题 。
使用最广泛的 2 种软件工程方法学:
1. 传统方法学(结构化范型):
(1) 采用结构化技术(结构化分析 、结构化设计和结构化实现)完成软件开发的各项任务 。
(2) 把软件生命周期划分成若干个阶段 ,然后顺序完成各个阶段的任务 。
(3) 每阶段的开始和结束都有严格的标准 ,前一阶段的结束标准就是后一阶段的开始标准 。
(4) 在每个阶段结束之前都必须正式地进行严格的技术审查和管理复审 。
2. 面向对象方法学(面向对象范型)
(1) 把对象作为融合了数据及在数据上的操作的软件构件,用对象分解取代传统方法的功能分解 。
(2) 把所有对象都划分成类 。
(3) 按照父类与子类的关系 ,把若干个相关类组织成一个层次结构的系统 。
(4) 对象彼此间仅能通过发送消息互相联系 。
结构化范型与面向对象范型区别
结构化范型开发大型软件产品不甚成功,因为使用结构化范型开发出的软件 ,本质上是一个单元 。而正确使用面向对象范型时 ,开发出的软件产品是由许多小的 、相对独立的单元(对象)组成的 。 因此 ,面向对象范型降低了软件产品的复杂度 ,简化了软件开发与维护工作 。
3 软件生命周期
软件生命周期由三部分组成:
- 软件定义
- 软件开发
- 软件维护
软件定义时期
软件定义时期的工作称为系统分析 ,由系统分析员负责完成 。
软件定义任务:
- 确定软件开发工程的总目标 ;
- 研究项目可行性 ;
- 分析确定客户对软件产品的需求 ;
- 估算完成该项目所需的资源和成本 ,并制定工程进度表 。
软件定义时期可划分成3 个阶段:
- 问题定义
- 可行性研究
- 需求分析 :包括需求获取( 揭示客户需求的过程)和需求分析 (进一步提炼和扩展需求 ,并用软件需求规格说明书把客户需求准确地记录下来)。
软件开发时期
具体设计和实现在前一个时期定义的软件 。
软件开发时期由 4 个阶段组成 :
- 总体设计(又称为结构设计) ;
- 详细设计 ;
- 编码和单元测试 ;
- 综合测试 。
- 其中前两个阶段又称为系统设计 ,后两个阶段又称为系统实现 。
运行维护时期
- 通过对已交付使用的软件做必要的修改 ,使软件持久地满足客户的需求 。
- 每一次维护活动本质上都是一次压缩和简化了的定义和开发过程 。
运行维护时期具体工作:
- 当软件在使用过程中发现错误时应该加以改正 ;
- 当环境改变时应该修改软件以适应新的环境 ;
- 当用户有新要求时应该及时改进或扩充软件以满足用户的新需要 。
软件生命周期各阶段
- 问题定义
- 可行性研究
- 需求分析
- 总体设计
- 详细设计
- 编码和单元测试
- 综合测试
- 维护
4 软件过程
软件过程定义了
- 运用技术方法的顺序
- 应该交付的文档资料
- 为保证软件质量和协调软件变化必须采取的管理措施
- 标志完成了相应开发活动的里程碑 。
通常使用生命周期模型概括地描述软件过程 。生命周期模型规定了软件过程包含的各个阶段 ,以及完成这些阶段的顺序 。
典型的生命周期模型:
1 .瀑布模型
传统软件工程方法学的软件过程 ,基本上可以用瀑布模型来描述 。
瀑布模型特点:
- 阶段间具有顺序性和依赖性。(1)须等前一阶段完成才能开始后一阶段工作。(2)前一阶段输出文档是后一阶段输入文档。
- 推迟实现观点。清楚区分逻辑设计与物理设计,尽可能推迟程序物理实现。
- 质量保证观点。(1)每个阶段必须完成规定文档。(2)每个阶段结束前必须正式进行严格的技术审查和管理复审 。
瀑布模型优点 :
- 强迫开发人员采用规范的技术方法 ;
- 严格规定了每个阶段必须提交的文档 ;
- 每个阶段结束前必须正式进行严格的技术审查和管理复审 。
瀑布模型缺点 :
在可运行的软件产品交付给用户之前 ,用户只能通过文档来了解未来的产品是什么样的 。 开发人员和用户之间缺乏有效的沟通 ,很可能导致最终开发出的软件产品不能真正满足用户的需求 。
2 .快速原型模型
“快速原型” ,是快速建立起来的 、可在计算机上运行的程序 ,它所能完成的功能往往是最终的软件产品所能完成的功能的子集 。 原型是软件开发人员与用户沟通的强有力工具 ,因此有助于所开发出的软件产品满足用户的真实需求 。
快速原型模型优点 :
- 使用这种软件过程开发出的软件产品通常能满足用户的真实需求 ;
- 软件产品的开发过程基本上是线性顺序过程 。
3 .增量模型
增量模型也称为渐增模型 ,使用增量模型开发软件时 ,把软件产品作为一系列增量构件来设计 、编码 、集成和测试 。每个构件由若干个相互协作的模块构成 ,并且能够完成相对独立的功能 。
构件分解时须遵循的约束条件:当把新构建集成到现有软件中时,所形成的产品是可测试的。
增量模型优点 :
- 能在较短时间内向用户提交可完成部分工作的产品 ;
- 逐步增加产品功能 ,从而使用户有较充裕的时间学习和适应新产品 ,减少一个全新的软件给客户组织带来的冲击 。
使用增量模型要求 :
- 软件工程师必须有较高的技术水平 ,能够设计出开放的软件体系结构 。
尽管采用增量模型比采用其他生命周期模型需要更精心的设计 ,但在设计阶段多付出的劳动将在维护阶段获得回报 ,因为用增量模型开发出的软件具有较好的可扩充性 。
4 .螺旋模型
在软件的开发过程中必须及时识别和分析风险 ,并且采取适当措施消除或减少风险的危害 。
构建原型是一种能使某些类型的风险(例如 ,产品不能满足用户的真实需求 ,采用了不恰当的技术方法等)降至最低的方法 。
螺旋模型的基本思想
使用原型及其他方法尽量降低风险 。 可以把它看作在每个阶段之前都增加了风险分析过程的快速原型模型 。 螺旋模型所描述的软件过程主要适用于内部开发的大型软件项目 。
螺旋模型优点 :
- 有利于已有软件的重用 ;
- 有助于把软件质量作为软件开发的一个重要目标 ;
- 减少了过多测试或测试不足所带来的风险 ;
- 软件维护与软件开发没有本质区别 。
使用螺旋模型要求:
- 软件开发人员具有丰富的风险评估知识和经验 。
5 .喷泉模型(面向对象软件项目)
迭代是软件开发过程中普遍存在的一种内在属性 。 在面向对象范型中 ,软件开发过程各阶段之间的迭代或同一阶段内各个工作步骤之间的迭代 ,比在结构化范型中更常见 。
7 敏捷过程与极限编程
7.1. 敏捷过程
敏捷开发宣言四个价值观
- 个体和交互胜过过程和工具
- 可以工作的软件胜过面面俱到的文档
- 客户合作胜过合同谈判
- 响应变化胜过遵循变化
7.2. 极限编程
极限编程有效实践
- 客户作为开发团队的成员
- 使用用户素材
- 短交付周期
- 验收测试
- 结对编程
- 测试驱动开发
- 集体所有
- 持续集成
- 可持续开发速度
- 开放的工作空间
- 及时调整计划
- 简单的设计
- 重构
- 使用隐喻
极限编程开发过程
- 根据用户故事提出隐喻
- 根据用户故事和隐喻指定交付计划
- 开始多个迭代过程
- 开发出的新版本软件通过验收测试后交付用户使用
敏捷开发优点
具有对变化和不确定性的更快速、更敏捷的反应特性,且在快速的同时能保持可持续开发速度。