当前课程知识点：软件工程与软件自动化 > 第九章 软件复用 > 9.3 软件复用实施 > 授课视频
嗨，大家好
今天我们来讨论如何在企业中实施软件复用
根据多年来的软件复用经验
我们已经得到这样的共识
为了获得软件复用的效果
需要在软件开发的过程方面作重大的变革
在传统的软件开发过程中，每个项目都是从头做 起
不同项目之间几乎没有共享的部分
项目内部的复用大多是开发者
在复用个人的知识和技能
而复用式的软件开发方法
是将诸多的应用开发项目与领域工程联系在一起
这样做，就需要站在新的立场上
重新思考软件开发的每一件事情
需要彻底检查企业的经营方式、开发过程和组织 结构
首先我们来看企业经营方式
软件企业的领导往往只考虑客户合同
并根据合同安排来开发团队
承担合同规定的应用系统的开发任务
很少考虑企业级的复用策略和复用所需要的投资 问题
在传统的软件开发过程中的各个阶段
一般都有质量检查点
但没有设置所谓的“复用”的思考点
没有机会让软件工程师们来思考复用的问题
传统的软件开发工程的技术和方法
缺乏界定“复用”的机制
不能明确哪些可以复用哪些不可以
缺乏制作可复用构件的方法
也缺乏实施复用的工具
传统的的软件开发实践
只关注一个应用系统
而复用实践要关注到覆盖整个应用领域的众多的 项目
还有文化问题
比如，有人对本单位其他人的工作未必信任
未必愿意复用别人的工作成果
又比如，有人不愿做复用者
担心丢失自己的创造性等等
此外，可复用构件开发过程的质量控制措施不力
生产出的可复用构件质量不理想
势必影响到复用计划的实施
这些管理模式、培训教育方面的新问题
需要有相应的新的组织结构的支持
系统的软件复用，由开发可复用资产
开发应用系统、支持和管理这四个并行的过程构 成
第一个过程是开发可复用资产
这个过程的目标是界定可复用资产
并为本单位提供可复用资产
以满足应用工程师的需要
我们知道，软件开发单位拥有的软件构件当中
有的是买的，有的是本单位开发的
这里重点讨论的是本单位开发可复用资产的过程
这个过程的活动包括
清理现有的应用软件和资产，列出它们的详细清 单
进行领域分析
设计软件的体系结构；评估应用工程师的需求
可复用资产的设计、实现、测试和打包等等
第二个过程是开发应用系统
这个过程是使用可复用资产来开发
客户合同所规定的应用系统的过程
对于可复用资产来说，这个过程就是复用的过程
这个过程的活动包括
检验领域模型，收集和分析最终用户的需求
从可复用资产中挑选合适的构件
并进行必要的客户化调节
设计和实现可复用资产没有覆盖到的部分
组装出完整的应用软件
最后对它进行测试并安装到客户指定的场所
第三个过程是支持过程
这个过程的任务是对可复用资产的获取
管理和维护提供技术支持
这个过程的活动包括
对所提供的可复用资产进行确认
对构件库进行分类编目
通告和分发可复用资产；提供必要的文档
从应用工程师那里收集反馈信息等等
第四个活动是管理活动
这个过程的任务是从事计划、资金
启动与跟踪、协调其它几个过程
管理过程的活动包括
对可复用资产的获取工作
包括购置、再工程、自行开发
进行优先性排队
筹集资金和人力；安排施工日程；组织培训
指挥并协调其它三个过程并及时解决出现的矛盾
我们知道，针对一个应用系统的软件工程
我们叫应用系统工程
针对一簇应用系统的软件工程，我们叫领域工程
领域工程为选定的领域建立模型
界定和设法提供可复用的资产
用于支持该领域众多的应用工程
而复用式的应用系统工程
与以往的应用系统工程也有所不同
在分析阶段，它要检验领域模型
收集和分析最终用户需求
在设计和实现阶段它要充分利用可复用资产
将它们汇集成应用系统
领域工程的目标是寻求可复用资产
以便支持该领域的一簇应用系统工程
具体说，领域工程要在选定的领域中
界定出事物的共性与可变性
要为该族的众多应用系统和构件系统
设计合适的软件体系结构
要开发一系列的可适度扩展的构件
以支持该族众多应用系统的开发
由于领域工程比多个应用系统工程的
简单相加更加复杂
人们往往没有充分的理解它的难度
不能够事先计划好，从而无法进行有效的管理
在开发可复用构件的时候
应当实施更为严格的工程规范
否则将生产出一堆不能搭配在一起工作的构件
不能有效地支持以后的应用系统工程
使可复用资产的投资得不到应有的回收
现在复用式的应用系统工程
应用工程师应当检验领域模型
收集和分析客户需求
设法将已有的可复用构件汇集在一起
生产出应用系统
理想情况下，应用系统由若干可复用构件组成
应用工程师利用可复用资产提供的可变性机制
对可复用构件进行客户化调节
就可组装成应用系统
如果现有的可复用构件还不足以完全满足客户所 有的需求
就需要另外编程
这类编程工作通常由软件工程师来完成
并集成到应用系统中
在需要另外编程的模块中
有可能被界定为新的可复用资产，则由构件开发 者
按照严格的软件开发规范生产出来
充实到已有的构件系统当中去
系统的复用是不可能自发实现的
为了在开发单位内部实施系统的复用
不仅需要采用相应的新技术
而且必须在复用的管理和组织方面投入很大的努 力
传统的软件开发单位的组织结构
通常是一个高级经理下面有若干个应用工程项目 经理
由高级经理来分配资源
而每个项目经理只负责他所掌管的项目
在这样的开发单位中没有可复用资产方面的资源
在实施软件复用的开发单位的组织结构就不一样 了
这样的开发单位至少有两个基本职能
而且由两种类型的部门分别承担
一个开发可复用资产
相应的部门是构件系统开发部
另外一个完成应用工程项目
相应的部门是应用工程部
往往还需要第三个职能，即支持职能
相应的部门是支持部
而且在构件开发、应用开发、支持3个平行的
部门上面还有一个高层经理
高层经理关注的是总目标
支持部门要对构件开发部所提供的
可复用资产进行确认
对构件库进行分类编目
向本单位的工程师们发布通告和分发可复用资产
提供必要的文档
从复用者收集反馈信息和缺陷报告
从复用者收集反馈信息和缺陷报告
从复用者收集反馈信息和缺陷报告
从复用者收集反馈信息和缺陷报告 在跨地域的大规模公司中
有时候会采用复用管理委员会
来替代高层经理，委员会包括体系设计师和经理
来替代高层经理，委员会包括体系设计师和经理
他们力图在跨地域的各个分单位之间进行复用
各分单位的矛盾提交到委员会上进行讨论和裁决
不过，这样的委员会的解决矛盾周期可能较长
因此，各个分单位要权衡一下是否要把矛盾
提交到委员会上去解决
所谓系统地实施复用技术，我们简称为系统复用
就是在软件开发单位内全面地实施软件复用
所谓渐进式地实施复用技术
就是逐步递增地实施系统复用
我们提到的四个并行的过程属于系统复用
但是系统复用是不可能自发实现的
需要软件开发单位全体职工的齐心协力
认真规划，仔细安排，才能逐步实现
软件开发单位要想实施系统复用
通常面临两种压力
第一，必须保持现有的传统机制继续运转
它包括获取经费以维持开发单位的各项活动
第二，要对现有的传统机制进行变革
使之逐步地过渡到系统复用状态
各级经理呢，他比较熟知如何运作现有的机制
各级经理呢，他比较熟知如何运作现有的机制
而不熟悉新的复用机制
更不知道如何在保持老机制运转的同时
来建立新的复用机制
所以说，从传统机制到复用机制的过渡
并不是一件简单的事情
往往需要几年的时间
而且最好以逐步过渡的方式
可以先典型的示范试行，摸索经验教训，再逐步 地扩展
最后逐步增加复用覆盖面
最后覆盖到整个软件开发单位
Hewlett-Packard公司经过多年的实践
总结出一套渐进的过渡方法
在前进了一步之后再跨进下一步
增添一些新的复用技术
各步增添的复用技术包括
一， 黑盒代码的复用
第二， 可复用构件库和工作成品的管理
三， 软件体系结构和构件系统
四，应用系统工程技巧和构件工程技巧
五，面向复用的过程和组织的管理
六，新工具和新技术
在充分认识到进入下一步的必要性时
就下定决心投资并进行准备
引入更高档次的复用技术
而高档次的复用呢又需要相应的组织结构来支持
并需要相应的软件体系结构，过程的实施也更为 严格
这是一个成熟的复用模型的实例
对于大规模的软件开发单位
尤其需要实施系统复用
要实施系统复用，就需要在经营业务、人员
过程、组织结构、体系结构、工具、技术等等
全方位的进行变革
而同时面对这么多方面的变革
如果缺少妥当的变革方法
很容易被许多枝节问题所困扰，风险很大
根据众多单位的经验，实施系统复用
需要同时注重下面三个方面的问题
第一个问题是复用式的业务工程
它包括一系列的功能交叉的过程
比如，针对整个单位的新的复用业务的设想
现有软件的逆向工程
新复用业务的正向工程以及实现等过程
相应的组织结构的优化
并制定和建立贯穿整个开发单位的政策和信息系 统
第二个问题是要注重人员的思想
组织结构的变革，涉及到人员的安排、人们的思 想顾虑
政策、组织方面的压力、知识的更新等等
进行变革的过程中需要进行细致的工作
包括建立信心、鼓励、支持、培训、权限分享等
包括建立信心、鼓励、支持、培训、权限分享等
第三个问题是建立相关的规章和具体措施
在实施的过程中
需要建立相关的注重实效的指南、模型、里程碑
还应当注重分步的计划安排以及督促检查措施
目前，大家已经得到这样的共识
成功的复用计划，应当是多步骤地逐渐成长和成 熟的
渐进复用的实践经验是
需要迭代好几轮才能达到较为满意的状态
这有两方面的原因
第一，体系结构需要稳定地变革
一般需要三轮左右的迭代
第二，组织结构的变革也不能搞一次性大跳跃
而应当逐步地边学习边改革
体系结构的稳步变革是个迭代过渡
可通过体系结构的接口界面得到控制
并且可让日益增多的人员逐步参与过渡
每一轮迭代大约需要 3到12个月
每一轮迭代都应当有明确的目标
通常，第一轮迭代是要得到分层式体系结构的大 图
开始认识到复用规划，同时还要关注软件工程过 程
我们建议先从一支核心的团队开始
然后逐步扩大队伍和范围
具体扩到多大，这要根据团队的经验
以及现有的咨询力量而定
随着经验的积累，应当对其它的过程开展
更为仔细的研究
而且应当有更多人员参与推广成功的经验
系统复用的内容与迭代式过渡框架组合在一起
我们就可以得到渐进式系统复用的高层视图
图中T1、T2……到T5组成的大图
便是某一轮当中新的复用业务工程的工作内容
T6是持续地改进过程，它包含从T1到T5
反复的迭代过程
随着每一轮的新业务模型开始运作
不断地收集并分析复用过程和产品评估
以评定过程、界定关键问题
为下一轮迭代作收集信息的准备工作
为下一轮迭代作收集信息的准备工作
为下一轮作些收集信息的准备工作
根据已经采用复用技术的众多开发单位的共同经 验
根据已经采用复用技术的众多开发单位的共同经 验
如果要系统地实施软件复用
就需要遵循下面这十条原则
第一，需要顶层管理领导
并需要有长期经费支持
并需要有长期经费支持
第二，为了渐进地推进系统的复用
需要规划和调节系统的体系结构、开发结构
组织结构，并以小规模的先行项目为典型示范
然后再铺展开来
第三，为了复用，先规划体系结构
及其逐步实施的过程
第四，过渡到明确的复用组织机构
将可复用构件的开发工作
与应用系统的开发工作分离开
并且提供明确的支持职能
第五，在实用的环境中
进行可复用构件的开发和改进工作
第六，要将应用系统和可重用构件
当作一个经济核算的产品进行管理
应当注重可复用构件在应用系统
领域中的高盈利作用
第七，要认识到单独的对象技术
或者单独的构件技术是不够的
第八，采用竞赛和更换负责人的方法
进行开发单位的文化建设和演变
第九，对基础设施、复用教育、技巧培训
要投资和持续地改进
第十，要采用度量方法测量复用过程
并要优化复用程序
好，这部分的内容就说到这儿，谢谢大家
-1.1 软件工程的前生今世
--开篇阅读
--授课视频
-第一章 软件工程基础--1.1 软件工程的前生今世
-1.2 万变不离其宗
--授课视频1/3
--授课视频2/3
--授课视频3/3
-第一章 软件工程基础--1.2 万变不离其宗
-1.3 唯一不变的是变化
--授课视频1/3
--授课视频2/3
--授课视频3/3
--外部链接
-第一章 软件工程基础--1.3 唯一不变的是变化
-1.4 亡羊补牢为时不晚
--授课视频1/2
--授课视频2/2
-第一章 软件工程基础--1.4 亡羊补牢为时不晚
-扩展阅读与话题讨论
--扩展阅读
--话题讨论
-2.1 方法论来源于恐惧
--授课视频
-第二章 敏捷开发--2.1 方法论来源于恐惧
-2.2 敏捷是什么
--授课视频
-第二章 敏捷开发--2.2 敏捷是什么
-2.3 典型敏捷开发方法
--XP敏捷开发方法
-第二章 敏捷开发--2.3 典型敏捷开发方法
-2.4 敏捷不是万能药
--授课视频
-第二章 敏捷开发--2.4 敏捷不是万能药
-专家谈敏捷
-扩展阅读与话题讨论
--外部链接
--话题讨论
-3.1 面向对象核心概念和基本特性
-第三章 OO与UML--3.1 面向对象核心概念和基本特性
-3.2 面向对象设计基本原则
-第三章 OO与UML--3.2 面向对象设计基本原则
-3.3 通用职责分配模式(GRASP)
--通用职责分配模式
-3.3 通用职责分配模式(GRASP)--作业
-3.4 从重构到模式
--模式和设计模式
-第三章 OO与UML--3.4 从重构到模式
-3.5 使用UML设计面向对象系统
--UML综述
-第三章 OO与UML--3.5 使用UML设计面向对象系统
-3.6 主要UML模型图绘制技巧
--UML用例图
--UML类图
-第三章 OO与UML--3.6 主要UML模型图绘制技巧
-扩展阅读与话题讨论
--设计模式有毒么？
--话题讨论
-4.1 案例简介
--书籍参考
--案例说明
-4.2 对象模型之一
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.2 对象模型之一
-4.3 对象模型之二
--授课视频1/2
--授课视频2/2
-第四章 对象模型分析--4.3 对象模型之二
-4.4 对象模型之交互
--授课视频
-第四章 对象模型分析--4.4 对象模型之交互
-扩展阅读与话题讨论
--图书推荐
--话题讨论
-5.1 软件自动化概述
--软件自动化概述
-第五章 软件自动化技术--5.1 软件自动化概述
-5.2 典型自动化方法和工具
-第五章 软件自动化技术--5.2 典型自动化方法和工具
-5.3 文档自动化
--文档自动化视频
-第五章 软件自动化技术--5.3 文档自动化
-5.4 测试自动化
--测试自动化视频
-第五章 软件自动化技术--5.4 测试自动化
-专家访谈
-扩展阅读与话题讨论
--话题讨论
-6.1 持续集成
-第六章 CI/CD与DevOps--6.1 持续集成
-6.2 持续交付和部署
-第六章 CI/CD与DevOps--6.2 持续交付和部署
-6.3 DevOps
-第六章 CI/CD与DevOps--6.3 DevOps
-专家访谈
-扩展阅读与话题讨论
--DevOps专题
--话题讨论
-7.1 质量和质量保证
--授课视频
-第七章 软件质量保证--7.1 质量和质量保证
-7.2 软件质量模型
--授课视频
-第七章 软件质量保证--7.2 软件质量模型
-7.3 SQA组织与职责
--授课视频
-第七章 软件质量保证--7.3 SQA组织与职责
-7.4 全面软件质量管理
--授课视频
-第七章 软件质量保证--7.4 全面软件质量管理
-专家访谈
--专家访谈
-扩展阅读与话题讨论
--外部链接
--话题讨论
-8.1 软件过程综述
--授课视频
-第八章 软件过程改进--8.1 软件过程综述
-8.2 软件过程改进
--授课视频
-第八章 软件过程改进--8.2 软件过程改进
-8.3 能力成熟度模型
--授课视频
-第八章 软件过程改进--8.3 能力成熟度模型
-8.4 过程改进标准框架
--授课视频
-第八章 软件过程改进--8.4 过程改进标准框架
-扩展阅读与话题讨论
--话题讨论
-9.1软件复用综述
--授课视频
-第九章 软件复用--9.1软件复用综述
-9.2 软件构件技术
--授课视频
-第九章 软件复用--9.2 软件构件技术
-9.3 软件复用实施
--授课视频
-第九章 软件复用--9.3 软件复用实施
-9.4 微服务架构
--授课视频
-第九章 软件复用--9.4 微服务架构
-扩展阅读与话题讨论
--微服务扩展
--话题讨论
-文档提交处--文档提交
