系统维护，净室工程

系统维护

系统维护是整个系统开发过程中耗时最长的，系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下：

易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。

易改变性：软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。

稳定性：软件产品避免由于软件修改而造成意外结果的能力。

易测试性：软件产品使已修改软件能被确认的能力。

系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：

正确性维护：发现了bug而进行的修改。

适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。

完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。

预防性维护：对未来可能发生的问题进行预防性的修改。

遗留系统

是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统

高水平低价值：集成

高水平高价值：改造

低水平低价值：淘汰

低水平高价值：继承

系统转换

是指新系统开发完毕，投入运行，取代现有系统的过程，有下面三种转换计划：

直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本，只适合小系统

并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

数据转换与迁移

系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成

净室软件工程（CSE）

一种应用数学与统计学理论以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷，强调的是预防大于检查。净室方法不是先制作一个产品，再去消除缺陷，而是要求在规约和设计中消除错误，然后以“净”的方式制作，可以降低软件开发中的风险，以合理的成本开发出高质量的软件

在净室软件工程背后的哲学是：通过在第1次正确地书写代码增量，并在测试前验证它们的正确性，来避免对成本很高的错误消除过程的依赖。它的过程模型是在代码增量积聚到系统的过程的同时，进行代码增量的统计质量验证。它甚至提倡开发者不需要进行单元测试，而是进行正确性验证和统计质量控制。

净室软件工程(CSE)的理论基础主要是函数理论和抽样理论。

净室软件工程应用技术手段：

统计过程控制下的增量式开发。

基于函数的规范与设计。

正确性验证（CSE的核心）

统计测试和软件认证。

净室软件工程在使用过程的一些缺点：

CSE太理论化，需要更多的数学知识。其正确性验证的步骤比较困难且比较耗时。

CSE开发小组不进行传统的模块测试，这是不现实的。

CSE也会带有传统软件工程的一些弊端

基于构件的软件工程（CBES）

一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。CBSE体现了“购买而不是重新构造”的哲学，将软件开发的重点从程序编写转移到了基于己有构件的组装。用于CBSE的构件应该具备以下特征：

可组装型

可部署性

文档化

独立性

标准化

CBSE过程是支持基于构件组装的软件开发过程，过程中的6个主要活动：系统需求概览、识别候选构件、根据发现的构件修改需求、体系结构设计、构件定制与适配、组装构件创建系统。

CBSE过程与传统软件开发过程不同点：

CBSE早期需要完整的需求(即需求明确)，以便尽可能多地识别出可复用的构件。

在过程早期阶段根据可利用的构件来细化和修改需求。如果可利用的构件不能满足用户需求，就应该考虑由复用构件支持的相关需求。

在系统体系结构设计完成后，会有一个进一步的对构件搜索及设计精化的活动。可能需要为某些构件寻找备用构件，或者修改构件以适合功能和架构的要求。

开发就是将己经找到的构件集成在一起的组装过程。

构件组装是指构件相互直接集成或是用专门编写的“胶水代码”将它们整合在一起来创造一个系统或另一个构件的过程。常见的组装构件有以下3种组装方式：

顺序组装，层次组装，叠加组装