软件工程第1章绪论(15-17).ppt

主要内容 软件生存期过程和模型 软件工程并行工程 1.5 软件生存期过程 软件生存期过程规定了获取、供应、开发、操作和维护软件时，要实施的过程、活动和任务。其目的是为各种人员提供一个公共的框架，以便可以使用“相同的语言”在自己的环境中创作和管理软件。 软件生存期过程没有规定一个特定的生存周期模型，各软件开发机构可视其项目的需要选择一种软件生存周期模型，并将软件生存期过程所含过程、活动和任务映射到选定的软件生存周期模型中。 GB/T8566-1995 1.6 常用软件生存期模型 软件生存期模型描述了软件项目从需求定义开始，到开发成功后投入使用，在使用的过程中不断增补修订，直到最后停止使用这一期间所进行的各种活动如何执行的模型。 软件开发机构应该综合项目和应用的性质、将要使用的方法和工具等，选择其中合适的模型，并将软件生存期过程映射到选定的模型中进行软件开发和维护。 1.6.1 瀑布模型 瀑布模型的特点 各阶段顺序相互依赖； 每阶段进行评审； 强调需求分析和设计。 瀑布模型的不足 实际软件开发中，各阶段之间并非完全的自上而下线性顺序展开 ； 在开发过程中，用户看不见系统，而只有在交付使用时系统才能和用户见面； 不够灵活（针对需求模糊或变化的情况） 。 1.6.2 快速原型化模型 快速原型化模型的特点 “快速”开发 ； 用户反馈； 逐步完善（原型）。 快速原型化模型的不足 不宜利用原型系统作为最终产品（原型成本问题）； 原型模型的“快速”特点对最终系统不适用（原型作用问题-----定义需求）。 1.6.3 RAD模型 RAD模型的特点 顺序开发（如同瀑布模型）； 业务建模：弄清业务活动中的信息流； 数据建模：精化业务建模结果； 处理建模：依据数据建模结果，创建处理描述； 应用生成：组件复用与开发； 测 试：新的组件及所有接口。 强调极短的开发周期（2-3月）。 RAD模型的不足 技术风险很高的情况不适合采用； （如新软件要求与已存在的程序有高可互操性时，或系统难以被适当地划分为若干功能等情况） 需要足够的人力以创建足够的RAD小组； 开发者和用户需要在很短的时间内完成系统开发。 1.6.4 渐增模型 前述生存期模型，均是一次性地将整个系统交给用户： 瀑布模型是假设当线性阶段完成之后就能交付一个完善的系统。原型模型主要用来帮助开发者获取用户需求，待需求稳定后再开发最终系统提供给用户。RAD模型则先将系统主要功能分给若干RAD小组开发，然后集成起来形成最终系统提交给用户。 渐增模型示意图 渐增模型的特点 可以根据需要补充人员 ； 能够有计划地管理技术风险； 能够减少全新软件产品对用户带来的影响； 不需要大的资金支出； 用户能及早使用及早发现问题； 投资回报随功能渐增而渐增。 渐增模型的不足 如果产品整体结构设计不当，则难以为其增加新的增量； （对设计水平要求较高） 由于采用增量开发，故难于进行彻底的测试。 1.6.5 螺旋模型 螺旋模型的特点 既保持了传统生命周期模型中系统的阶段性方法，又将迭代演化的思想吸收到模型中； 螺旋模型是风险驱动的。 （风险分析使得用户和开发者能够更好地理解和对待每一个阶段的风险） 螺旋模型的不足 要求软件开发人员善长风险分析； 风险分析会导致项目终止而终止合同，出现违约诉讼； 对于小项目，风险分析的成本可能与整个项目的成本相当。 其它模型 构件组装模型；(基于构件组装) 簇模型；（强调并行开发） 喷泉模型；（适合面向对象软件开发） 智能模型；（将瀑布模型与专家系统结合） ... ... 1.7 软件工程的并行工程 传统的产品开发过程是一个顺序的、静态的和相互分离的流程，即串行工程。 1986年，美国防御分析研究所在R-338报告中提出了并行工程概念，认为并行工程是集成地、并行地设计产品及其相关的各种过程的系统化方法。 Humphrey和Kellner在1989年指出软件开发中任何一个阶段的活动都存在并行性。 1.7.1 簇的基本概念 簇是相关的类的组合，或者是相关的簇的组合。 簇有两种情况：纯粹由若干个相关的类组合而成，这样的簇称为基本簇；由若干个其它的相关的簇组合而成，称为超簇。 每一个簇应该只由一个人来管理，并且一个人应该能够理解簇中包括的所有的类。 1.7.2 并行工程的提出 传统的生命周期模型的一个缺点是：如果在哪一环节上碰到了暂时无法克服的困难，只能等待，从而会影响整体进度。且这种直线式的方法几乎不能反映现在的软件开发的实际。 面向对象开发方法可以支持并行工程的实施方案。通过将系统（或子系统）分成若干个簇，可以在串行化的