1、2. 软件的可用性软件的可用性 对故障可修复系统，应同时使用可靠性和对故障可修复系统，应同时使用可靠性和可用性来衡量。可用性来衡量。 是：程序在给定的时间点，按是：程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。照规格说明书的规定，成功地运行的概率。 是：可靠性是在是：可靠性是在0到到t时间间隔内，系统没有失效的概率。而可用时间间隔内，系统没有失效的概率。而可用性是在性是在t时刻，系统是正常运行的概率。时刻，系统是正常运行的概率。 如果在如果在t时刻，系统是可用的，则有两种可能：时刻，系统是可用的，则有两种可能： 1）在）在0到到t时刻这段时间内，系统一直没有失时刻这段时间内，系统
2、一直没有失效（可靠）；效（可靠）； 2）在）在0到到t时刻这段时间内失效过，但是系统时刻这段时间内失效过，但是系统修复后运行到修复后运行到t时刻时情况良好。时刻时情况良好。 如果在一段时间内，软件系统故障停机时间如果在一段时间内，软件系统故障停机时间分别为：分别为：td1 , td2 , ,正常运行时间分别为：正常运行时间分别为：tu1 , tu2 , ,则系统的稳态可用性定义为：则系统的稳态可用性定义为： downupupssTTTA其中其中Tup= tui , Tdown= tdi 如果引入系统平均无故障时间如果引入系统平均无故障时间MTTF和平均维修时间和平均维修时间MTTR的概念，则上
3、面公式的系统稳态可用性变成：的概念，则上面公式的系统稳态可用性变成：MTTRMTTFMTTFAss MTTR是修复一个故障平均需要用的时间，取决于维护人是修复一个故障平均需要用的时间，取决于维护人员的技术水平和对系统熟悉程度。员的技术水平和对系统熟悉程度。 MTTF是系统按照规格说明书规定成功地运行的平均时是系统按照规格说明书规定成功地运行的平均时间，取决于系统中潜伏的错误数量。间，取决于系统中潜伏的错误数量。 1. 符号符号 估算估算MTTF时使用到下列符号时使用到下列符号 ET测试之前程序中故障总数；测试之前程序中故障总数； IT程序长度（机器指令总数）；程序长度（机器指令总数）； 测试（
4、包括调试）时间；测试（包括调试）时间； Ed() 在在0至至期间发现的错误数；期间发现的错误数； Ec() 在在0至至期间改正的错误数；期间改正的错误数； 7.9.2 估算平均无故障时间估算平均无故障时间MTTF的方法的方法2. 基本假定基本假定可作出下列假定：可作出下列假定：1）。一些统计。一些统计数字表明，通常有：数字表明，通常有：0.510-2ET/ IT210-2。2），。3），即，即Ec()= Ed()。由于系统剩余的故障数为：由于系统剩余的故障数为： Er() = ET- Ec()所以单位长度程序中剩余的故障数为：所以单位长度程序中剩余的故障数为： r () = ET / IT -
5、 Ec()/ IT 3. 估算平均无故障时间估算平均无故障时间MTTF 因为平均无故障时间与单位长度程序中剩因为平均无故障时间与单位长度程序中剩余的故障数余的故障数r ()成反比，所以：成反比，所以： / )(/1)(TcTTrIEIEKMTTF 其中：其中：K为常数，它的值根据经验选取，为常数，它的值根据经验选取，经典值是经典值是200。由上式变换后得到程序中改正的错误数：由上式变换后得到程序中改正的错误数： 根据对软件平均无故障时间的要求，可以估计根据对软件平均无故障时间的要求，可以估计需要改正多少个错误后，测试工作就可以结束。需要改正多少个错误后，测试工作就可以结束。 MTTFKIEET
6、Tc4. 估计故障总数估计故障总数ET的方法的方法1） 假设人为地植入的故障数为假设人为地植入的故障数为Ns，经过一段时间的测经过一段时间的测试之后发现试之后发现ns个植入的故障，同时还发现了个植入的故障，同时还发现了n个原有的个原有的故障，则可以估计出程序中原有的故障总数：故障，则可以估计出程序中原有的故障总数：ssNnnN 其中：其中： 是故障总数是故障总数ET的估计值；的估计值； N 植入错误法人为植入的错误与原有程序错误可植入错误法人为植入的错误与原有程序错误可能性质很不相同，发现它们的难度也不同，用此能性质很不相同，发现它们的难度也不同，用此法估计的错误数有时可能不太准确。法估计的错
7、误数有时可能不太准确。2） 分别测试法随机把程序中一部分原有错误加上分别测试法随机把程序中一部分原有错误加上标记，根据测试发现的有标记和无标记错误的比标记，根据测试发现的有标记和无标记错误的比例，估计程序错误总数。例，估计程序错误总数。 分别测试法使用两个测试员，独立地测试同一分别测试法使用两个测试员，独立地测试同一个程序的两个副本，由另一名分析员分析他们的个程序的两个副本，由另一名分析员分析他们的测试结果，把其中一个测试员发现的故障作为有测试结果，把其中一个测试员发现的故障作为有标记的故障。用标记的故障。用表示测试时间，假设表示测试时间，假设 = 0时故障总数为时故障总数为B0（即（即ET）
8、；）； =1时测试员甲发现的故障数为时测试员甲发现的故障数为B1； =1时测试员乙发现的故障数为时测试员乙发现的故障数为B2； =1时两个测试员发现的相同故障数为时两个测试员发现的相同故障数为bc。 如果认为测试员甲发现的故障是有标记的，即如果认为测试员甲发现的故障是有标记的，即程序中有标记的故障总数为程序中有标记的故障总数为B1，那么测试员乙发那么测试员乙发现的现的B2个故障中有个故障中有bc个是有标记的。所以可以估个是有标记的。所以可以估计出测试前程序中的故障总数为：计出测试前程序中的故障总数为：120BbBBc其中，其中， 是故障总数是故障总数ET的估计值。的估计值。 每隔一定时间，分析
9、员分析两名测试员的测试每隔一定时间，分析员分析两名测试员的测试结果，来估计错误总数。几次估计结果差不多时，结果，来估计错误总数。几次估计结果差不多时，用其平均值作为错误总数的估计值。用其平均值作为错误总数的估计值。0B 一种预测软件可靠性和衡量软件质量的方法。一种预测软件可靠性和衡量软件质量的方法。 用测试完成率作为度量软件质量的标准。用测试完成率作为度量软件质量的标准。7.10 日立预测法日立预测法7.10.1 测试完成率模型测试完成率模型 50%100%测试时间测试时间使用率使用率第一第一阶段阶段第二第二阶段阶段第三第三阶段阶段100%测试用例完成率测试用例完成率测试用例完成率随测试时间变
10、化的测试用例完成率随测试时间变化的情况情况 日立的经验表明，完成软件测日立的经验表明，完成软件测试通常需要经历三个阶段，第一阶试通常需要经历三个阶段，第一阶段故障多，测试完成慢，第二阶段段故障多，测试完成慢，第二阶段测试完成率提高快，第三阶段错误测试完成率提高快，第三阶段错误难改正，完成率提高不快。难改正，完成率提高不快。 测试时间使用率测试所用时测试时间使用率测试所用时间间/测试允许使用时间。测试允许使用时间。50%100%测试时间测试时间使用率使用率第一第一阶段阶段第二第二阶段阶段第三第三阶段阶段100%测试用例完成率测试用例完成率测试用例完成率随测试时间变化的测试用例完成率随测试时间变化
11、的情况情况日立的经验表明：日立的经验表明：1）第一个阶段平均占总时）第一个阶段平均占总时间的间的22%；2）如果第一个阶段占用的）如果第一个阶段占用的时间超过总时间的时间超过总时间的55%以上时以上时，该项工程必然失败；，该项工程必然失败；3）成功的工程第一个阶）成功的工程第一个阶段占用的时间平均为总时段占用的时间平均为总时间的间的15%，失败的工程第，失败的工程第一个阶段占用的时间高达一个阶段占用的时间高达总时间的总时间的97%左右；左右；4）成功的工程第二阶段）成功的工程第二阶段占总时间的占总时间的57%左右，失左右，失败的工程第二个阶段只占败的工程第二个阶段只占总时间的总时间的29%左右
12、。左右。50%100%测试时间测试时间使用率使用率第一第一阶段阶段第二第二阶段阶段第三第三阶段阶段100%测试用例完成率测试用例完成率测试用例完成率随测试时间变化的测试用例完成率随测试时间变化的情况情况错误发现率：单位时间内发现的错误数。错误发现率：单位时间内发现的错误数。 峰值时间峰值时间成功的成功的工程工程失败的工失败的工程程极坏的工程极坏的工程时间时间错误发现错误发现率率错误发现率曲线错误发现率曲线7.10.2 错误发现率模型错误发现率模型7.10.3 使用日立预测法的步骤使用日立预测法的步骤 1）制订测试计划，设计测试方案，确定要完）制订测试计划，设计测试方案，确定要完成的测试用例的总
13、数；成的测试用例的总数；2）从集成测试开始，记录测试用例完成数和）从集成测试开始，记录测试用例完成数和错误发现数，绘制用例完成率曲线和错误错误发现数，绘制用例完成率曲线和错误发现率曲线；发现率曲线；3）绘制曲线时，实际的数据是一串离散的点，）绘制曲线时，实际的数据是一串离散的点，如果工程不大周期不长的话，连接这些点如果工程不大周期不长的话，连接这些点得不到平滑的曲线时，作平滑处理；得不到平滑的曲线时，作平滑处理；4）每周至少检查一次绘制的曲线，以判断处于）每周至少检查一次绘制的曲线，以判断处于哪个阶段，如果第二阶段的到来比计划时间哪个阶段，如果第二阶段的到来比计划时间推迟推迟25，就需要及时采
14、取措施补救；，就需要及时采取措施补救；5）严密注视错误发现率变化情况以确定其峰值，）严密注视错误发现率变化情况以确定其峰值，在错误发现率下降时，计算其斜率，如果大在错误发现率下降时，计算其斜率，如果大于于0.3就产生了严重的问题；就产生了严重的问题；6）每周至少检验一次，以修正上一周作出的阶）每周至少检验一次，以修正上一周作出的阶段性预测。段性预测。第第7章小结章小结 为做好集成测试和验收测试，需为如何组织测试制订实为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的
15、偏差范围等。试用例的选取原则、测试结果允许的偏差范围等。 测试工作完成以后，应提交测试计划执行情况的说明，测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。对测试结果加以分析，并提出测试的结论意见。第第8章：维护章：维护 软件维护是软件生命周期的最后一个阶段。软件维护是软件生命周期的最后一个阶段。 它的任务是：维护软件的正常运行，不断改进它的任务是：维护软件的正常运行，不断改进软件的性能和质量，为软件的进一步推广应用和软件的性能和质量，为软件的进一步推广应用和更新替换做积极工作。更新替换做积极工作。 软件维护所需的工作量非常大，一般说来，软件维护所需的工
16、作量非常大，一般说来，大型软件的维护成本高达开发总成本的四倍大型软件的维护成本高达开发总成本的四倍左右。目前，软件开发组织把左右。目前，软件开发组织把60%以上的工以上的工作量用于维护自己的软件上。作量用于维护自己的软件上。问题：软件交付使用问题：软件交付使用 软件验收测试以后，就标志着软件设计软件验收测试以后，就标志着软件设计开发阶段的结束。开发阶段的结束。 而软件交付用户使用，才真正标志漫长而软件交付用户使用，才真正标志漫长的维护阶段的开始。的维护阶段的开始。 软件交付使用就是新系统和旧系统的转换。软件交付使用就是新系统和旧系统的转换。 旧系统可能是人工作业系统，也可能是某个旧旧系统可能是
17、人工作业系统，也可能是某个旧的计算机系统。的计算机系统。 软件交付应该是一个过程，而不是一个突然事软件交付应该是一个过程，而不是一个突然事件，软件的交付使用应尽可能平稳过渡，不影响件，软件的交付使用应尽可能平稳过渡，不影响生产或工作，新系统逐步安全地取代旧系统。生产或工作，新系统逐步安全地取代旧系统。一、软件交付使用的工作一、软件交付使用的工作1）将旧系统的数据转换到新系统（如数据库数）将旧系统的数据转换到新系统（如数据库数据）；据）；2）新系统调试完成并加载入机器，准备运行；）新系统调试完成并加载入机器，准备运行；3）将有关资料（如使用说明）转交给用户；）将有关资料（如使用说明）转交给用户；
18、4）对用户做适当的培训。）对用户做适当的培训。 二、软件交付使用的方式二、软件交付使用的方式 1）直接方式）直接方式 旧系统旧系统新系统新系统（a）直接方式直接方式 直接方式是用新系统直接替换旧系统，没有过渡。直接方式是用新系统直接替换旧系统，没有过渡。 优点：优点：。 缺点：缺点：。 由于新系统没有承担过实际工作，可能会出由于新系统没有承担过实际工作，可能会出现意想不到的问题，甚至出现程序设计错误。现意想不到的问题，甚至出现程序设计错误。 因此，实际应用时，采取一些措施，以便新因此，实际应用时，采取一些措施，以便新系统一旦出错，旧系统能够恢复运行。系统一旦出错，旧系统能够恢复运行。 直接方式
19、不适用于一些关系重大的系统。直接方式不适用于一些关系重大的系统。2）并行方式）并行方式 旧系统旧系统新系统新系统（b）并行方式并行方式 一些关系重大的软件产品在验收测试后，一些关系重大的软件产品在验收测试后，并不立即投入生产性运行，而是同时运行新系并不立即投入生产性运行，而是同时运行新系统和旧系统，以比较处理结果，这就是并行方统和旧系统，以比较处理结果，这就是并行方式。式。 ： A. 可以对系统进行全面测试，减少了新系统失灵可以对系统进行全面测试，减少了新系统失灵带来的风险，因为旧系统也仍然存在；带来的风险，因为旧系统也仍然存在； B用户也能够有一段熟悉新系统的时间。用户也能够有一段熟悉新系统
20、的时间。： 所需费用较高，双系统要投入更多的人力财力。所需费用较高，双系统要投入更多的人力财力。3）逐步方式）逐步方式 逐步方式是将软件分期，部分地交付使用。逐步方式是将软件分期，部分地交付使用。这种方式克服了上面两种方式的缺点，既能防这种方式克服了上面两种方式的缺点，既能防止直接转换产生的危险性，又能减少并行方式止直接转换产生的危险性，又能减少并行方式的费用。的费用。 但是这种方法使得整个系统中一部分是旧系但是这种方法使得整个系统中一部分是旧系统，一部分是新系统，所以必须考虑好它们的统，一部分是新系统，所以必须考虑好它们的相互配合问题和接口问题。相互配合问题和接口问题。 实际应用中，常常是混
21、合以上几种方法。对实际应用中，常常是混合以上几种方法。对系统不重要的部分采用直接方式，对系统重要系统不重要的部分采用直接方式，对系统重要部分采用并行方式，使系统平稳交付使用。部分采用并行方式，使系统平稳交付使用。 通常要求进行软件维护的原因有三种：通常要求进行软件维护的原因有三种：1）改正在特定使用条件下暴露出来的一些潜在）改正在特定使用条件下暴露出来的一些潜在程序错误或设计缺陷；程序错误或设计缺陷；2）因在软件使用过程中数据环境发生变化（如）因在软件使用过程中数据环境发生变化（如所要处理的数据发生变化）或处理环境发生所要处理的数据发生变化）或处理环境发生变化（如硬件或软件操作系统等发生变化）
22、，变化（如硬件或软件操作系统等发生变化），需要修改软件，以适应这种变化；需要修改软件，以适应这种变化；8.1 软件维护的定义软件维护的定义 8.1.1 软件维护的原因软件维护的原因3）用户和数据处理人员在使用时常提出改进）用户和数据处理人员在使用时常提出改进现有功能、增加新功能、以及改善总体性现有功能、增加新功能、以及改善总体性能的要求，为满足这些要求，需要修改软能的要求，为满足这些要求，需要修改软件。件。1） 交付给用户使用的软件，即使通过严格的测交付给用户使用的软件，即使通过严格的测试，仍可能有一些潜在的错误在用户使用的过试，仍可能有一些潜在的错误在用户使用的过程中发现和修改。诊断和改正错
23、误的过程称为程中发现和修改。诊断和改正错误的过程称为改正性维护。改正性维护。8.1.2 软件维护的类型软件维护的类型2）适应性维护适应性维护 随着计算机的飞速发展，新的硬件系统和外随着计算机的飞速发展，新的硬件系统和外部设备时常更新和升级，一些数据库环境、数部设备时常更新和升级，一些数据库环境、数据输入据输入/输出方式、数据存储介质等也可能发生输出方式、数据存储介质等也可能发生变换。为了使软件适应这些环境变化而修改软变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。件的过程叫做适应性维护。3） 在软件投入使用过程中，用户可能还会有在软件投入使用过程中，用户可能还会有新的功能和性能
24、要求，可能会提出增加新功新的功能和性能要求，可能会提出增加新功能、修改现有功能等要求。为了满足这类要能、修改现有功能等要求。为了满足这类要求而进行的维护称为完善性维护。求而进行的维护称为完善性维护。4） 为了改进软件未来的可维护性或可靠性，或为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而进行的者为了给未来的改进奠定更好的基础而进行的修改，称为预防性维护。修改，称为预防性维护。 这种维护活动在实践中比较少见。这种维护活动在实践中比较少见。 在各类维护中，完善性维护占软件维护工作的在各类维护中，完善性维护占软件维护工作的大部分。大部分。 根据国外的数据统计表明，完善性维护
25、占全部根据国外的数据统计表明，完善性维护占全部维护活动的维护活动的50%66%，改正性维护占，改正性维护占17%21%，适应性维护占，适应性维护占18%25%，其它维护活动，其它维护活动占占4%左右。左右。8.2.1 结构化维护与非结构化维护的差别结构化维护与非结构化维护的差别 1. 非结构化维护非结构化维护 软件配置的唯一成分是代码，维护从评价程序代码开始，软件配置的唯一成分是代码，维护从评价程序代码开始，对软件结构、数据结构、系统接口、设计约束等常产生误对软件结构、数据结构、系统接口、设计约束等常产生误解，不能进行回归测试，维护代价大。解，不能进行回归测试，维护代价大。 2. 结构化维护结
26、构化维护 有完整的软件配置，维护从评价设计文档开始，确定软有完整的软件配置，维护从评价设计文档开始，确定软件结构、性能和接口特点，现修改设计，接着修改代码，件结构、性能和接口特点，现修改设计，接着修改代码，再进行回归测试。再进行回归测试。8.2 软件维护的特点软件维护的特点 软件维护的代价表现为有形代价和无形代价。软件维护的代价表现为有形代价和无形代价。 有形代价指软件维护的费用开支。有形代价指软件维护的费用开支。 70年代，用于软件维护的费用只占软件总预算年代，用于软件维护的费用只占软件总预算的的30%40%，80年代上升到年代上升到60%左右，左右，90年代年代许多软件项目的维护经费预算达
27、到了许多软件项目的维护经费预算达到了80%。8.2.2 软件维护的代价软件维护的代价1. 有形代价与无形代价有形代价与无形代价无形代价：无形代价：1）当一些看起来合理的要求不能及时满足时，）当一些看起来合理的要求不能及时满足时，会引起用户的不满；会引起用户的不满；2）改动软件可能会引入新的错误，使软件质）改动软件可能会引入新的错误，使软件质量下降；量下降；3）把许多软件工程师调去从事维护工作，势）把许多软件工程师调去从事维护工作，势必影响开发工作。必影响开发工作。 软件维护所花费的工作量，一部分用于生产软件维护所花费的工作量，一部分用于生产性活动，如分析、评价、修改设计、编写程序性活动，如分析
28、、评价、修改设计、编写程序等；另一部分用于非生产性活动，如理解代码等；另一部分用于非生产性活动，如理解代码的含义、解释数据结构和接口特点等。的含义、解释数据结构和接口特点等。 2. 软件维护工作量模型软件维护工作量模型Belady和和Lehman提出了一种维护工作量模型：提出了一种维护工作量模型： 其中：其中： M：用于维护工作的总工作量用于维护工作的总工作量； P：生产性工作量；生产性工作量； K：经验常数；经验常数； c：因缺乏好的设计和文档而导致软件复杂性的度量；因缺乏好的设计和文档而导致软件复杂性的度量； d：维护人员对软件熟悉程度的度量。维护人员对软件熟悉程度的度量。 上述模型指出：
29、如果使用了不好的软件开发方上述模型指出：如果使用了不好的软件开发方法，原来参加开发的人员或小组不能参加维护，法，原来参加开发的人员或小组不能参加维护，则工作量和成本将按指数级增加。则工作量和成本将按指数级增加。8.2.3 软件维护的典型问题软件维护的典型问题 1）如果维护时只有程序代码而没有注释说明，）如果维护时只有程序代码而没有注释说明，维护起来就相当困难；维护起来就相当困难；2）由于软件维护阶段时间长，软件开发人员）由于软件维护阶段时间长，软件开发人员经常流动，所以在维护时，不可能所有的经常流动，所以在维护时，不可能所有的维护工作都依靠原来的开发人员。这会使维护工作都依靠原来的开发人员。这
30、会使得维护工作量增加；得维护工作量增加；3）软件没有足够的文档资料，或者程序修改后）软件没有足够的文档资料，或者程序修改后与文档资料不一致；与文档资料不一致；4）绝大多数软件在设计时没有考虑将来的修改）绝大多数软件在设计时没有考虑将来的修改，所以建议采用功能独立的模块化设计原，所以建议采用功能独立的模块化设计原则，增加软件的可维护性；则，增加软件的可维护性；5）软件维护被许多人视为一种毫无吸引力的工）软件维护被许多人视为一种毫无吸引力的工作，因为维护工作常常受到挫折。作，因为维护工作常常受到挫折。要缓解以上典型问题，建议采用软件工程的方法来开发程序。要缓解以上典型问题，建议采用软件工程的方法来
31、开发程序。 8.3 软件维护过程软件维护过程 1. 维护组织维护组织 维护要求维护要求（软件问题报告）（软件问题报告）维护管理员维护管理员系统管理员系统管理员软件系统软件系统变化授权人变化授权人图图8.1 维护组织维护组织 根据软件问题报告（维护要求），作出的软件修改根据软件问题报告（维护要求），作出的软件修改报告包含的信息主要有：报告包含的信息主要有： 1）满足维护要求表中提出的要求所需要的工作量；）满足维护要求表中提出的要求所需要的工作量； 2）维护要求的性质；）维护要求的性质； 3）这项要求的优先次序；）这项要求的优先次序； 4）与修改有关的事后数据（如测试数据等）。）与修改有关的事后数
32、据（如测试数据等）。2. 维护报告维护报告 3. 维护的事件流维护的事件流 类型类型开始分开始分析问题析问题评价优评价优先度先度计划改计划改正进度正进度开始分开始分析析维护任维护任务务复审复审估量错估量错误严重误严重程度程度维护要求维护要求错误错误严重严重适应适应完善完善不严重不严重错误改正目录错误改正目录开发目录开发目录高高低低分配的人员分配的人员分配的人员分配的人员修改后的修改后的软件配置软件配置复审后供使用复审后供使用的软件配置的软件配置图图8.2 维护阶段的工作流程维护阶段的工作流程 4. 保存维护记录保存维护记录 1）程序标识；）程序标识； 2）源语句数；）源语句数；3）机器指令数；
33、）机器指令数； 4）使用的程序设计语言；）使用的程序设计语言；5）程序安装的日期；）程序安装的日期； 6）自安装以来程序运行次数；）自安装以来程序运行次数；7）自安装以来程序失效次数）自安装以来程序失效次数 8）程序变动的层次和标识；）程序变动的层次和标识；9）因程序变动而增加的源语句数；因程序变动而增加的源语句数；10）因程序变动而删除的源语句数；因程序变动而删除的源语句数；11）每个改动耗费的人时数；）每个改动耗费的人时数； 12）程序改动的日期；）程序改动的日期；13）软件工程师的名字；）软件工程师的名字； 14）维护要求表的标识；）维护要求表的标识；15）维护类型；）维护类型； 16）
34、维护开始和完成的日期；）维护开始和完成的日期；17）累计用于维护的人时数；）累计用于维护的人时数； 18）与完成的维护相联系的纯效益。与完成的维护相联系的纯效益。5. 评价维护活动评价维护活动 可以从以下方面度量维护工作：可以从以下方面度量维护工作：1）每次程序运行平均失效的次数；）每次程序运行平均失效的次数；2）用于每一类维护活动的总人时数；）用于每一类维护活动的总人时数；3）平均每个程序、每种维护类型所做的程序变动数；）平均每个程序、每种维护类型所做的程序变动数；4）维护过程中增加或删除一个源语句平均花费的人时数；）维护过程中增加或删除一个源语句平均花费的人时数；5）维护每种语言平均花费的
35、人时数；）维护每种语言平均花费的人时数；6）一张维护要求表的平均周转时间；）一张维护要求表的平均周转时间；7）不同维护类型所占的百分比。）不同维护类型所占的百分比。8.4 软件的可维护性软件的可维护性 软件可维护性是：维护人员理解、改正和改进软件可维护性是：维护人员理解、改正和改进软件的难易程度。软件的难易程度。 一个软件的可维护性，主要由三个因素决定：一个软件的可维护性，主要由三个因素决定：1. 可理解性表现为外来读者理解软件的结构、接可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。口、功能和内部过程的难易程度。8.4.1 决定软件可维护性的因素决定软件可维护性的因素
36、影响软件可理解性的重要因素有：模块化、影响软件可理解性的重要因素有：模块化、结构化设计、详细的设计文档资料、源代码内结构化设计、详细的设计文档资料、源代码内部文档、良好的程序设计语言等。部文档、良好的程序设计语言等。2. 在设计开发阶段应该注意尽量把软件设计成在设计开发阶段应该注意尽量把软件设计成容易测试和容易诊断的，可用的测试工具和调容易测试和容易诊断的，可用的测试工具和调试工具对测试和诊断非常重要。试工具对测试和诊断非常重要。3. 软件的可修改程度与软件设计阶段采用的软件的可修改程度与软件设计阶段采用的原则和策略是直接相关的。如：模块的耦合、原则和策略是直接相关的。如：模块的耦合、内聚、控
37、制范围和作用范围、局部化程度都内聚、控制范围和作用范围、局部化程度都直接影响软件的可修改性。直接影响软件的可修改性。 4. 5. 决定软件可维护性的最终因素是软件设计阶决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的好坏。段所采用的方法，以及软件文档资料的好坏。 提高软件的可维护性是软件工程的一个重要提高软件的可维护性是软件工程的一个重要目标。目标。 8.4.2 文档文档 1. 用户文档用户文档 1）功能描述；）功能描述； 2）安装文档；）安装文档； 3）使用手册；）使用手册； 4）参考手册；）参考手册； 5）操作员指南；）操作员指南； 2. 系统文档系统文档SVN 软
38、件：软件： 配置修改记录、配置修改记录、代码版本管理。代码版本管理。8.4.3 可维护性复审可维护性复审 测试结束时进行正式的可维护性复审，称为测试结束时进行正式的可维护性复审，称为配置复审，目的是：保证软件配置的所有成分配置复审，目的是：保证软件配置的所有成分是完整的、一致的和可理解的。是完整的、一致的和可理解的。 在软件的维护过程中，花费的大量工作量会直在软件的维护过程中，花费的大量工作量会直接影响软件的成本。接影响软件的成本。 因此，应当考虑有哪些因素会影响软件维护的因此，应当考虑有哪些因素会影响软件维护的工作量，应该采取什么维护策略，才能有效地维工作量，应该采取什么维护策略，才能有效地
39、维护软件并控制维护的成本。护软件并控制维护的成本。 8.4.4 影响维护工作量的因素影响维护工作量的因素影响软件维护工作量的因素有：影响软件维护工作量的因素有：1）。系统越大，功能越复杂，理解掌。系统越大，功能越复杂，理解掌握起来就越困难，需要的维护工作量越大。握起来就越困难，需要的维护工作量越大。2）。使用功能强的程序设计语言。使用功能强的程序设计语言可以控制程序的规模。语言的功能越强，生可以控制程序的规模。语言的功能越强，生成程序所需的指令数就越少；语言的功能越成程序所需的指令数就越少；语言的功能越弱，实现同样功能所需的语句就越多，程序弱，实现同样功能所需的语句就越多，程序就越大，维护起来
40、就越困难。就越大，维护起来就越困难。3）。老系统比新系统需要更多的维护。老系统比新系统需要更多的维护工作量。许多老系统在当初并未按照软件工工作量。许多老系统在当初并未按照软件工程的要求进行开发，没有文档，或文档太少，程的要求进行开发，没有文档，或文档太少，或者在长期的维护中许多地方与程序不一致，或者在长期的维护中许多地方与程序不一致，维护起来困难较大。维护起来困难较大。4）。使用数据库工具，可有。使用数据库工具，可有效地管理和存储用户程序中的数据，可方便效地管理和存储用户程序中的数据，可方便地修改、扩充报表。数据库技术的使用可以地修改、扩充报表。数据库技术的使用可以减少维护工作量。减少维护工作
41、量。5）。在软件开发时，如。在软件开发时，如果使用能使软件结构比较稳定的分析与设果使用能使软件结构比较稳定的分析与设计技术（如面向对象分析、设计技术），计技术（如面向对象分析、设计技术），可以减少一定的工作量。可以减少一定的工作量。6）。如，应用的类型、数学模型、任务。如，应用的类型、数学模型、任务的难度、的难度、IF嵌套深度等等都会对维护工作嵌套深度等等都会对维护工作量产生一定的影响。量产生一定的影响。8.5 预防性维护预防性维护对旧程序维护的做法：对旧程序维护的做法： 1）反复多次做修改程序的尝试；）反复多次做修改程序的尝试； 2）先通过仔细分析程序，尽可能多地掌握程序内部工）先通过仔细分
42、析程序，尽可能多地掌握程序内部工作细节，再有效地修改；作细节，再有效地修改； 3）用软件工程方法重新设计、编码和测试需要变更的）用软件工程方法重新设计、编码和测试需要变更的软件部分；软件部分； 4）以软件工程方法为指导，对程序全部重新设计、编）以软件工程方法为指导，对程序全部重新设计、编码和测试。码和测试。 3）是局部再工程；）是局部再工程；4）是软件再工程）是软件再工程 / 预防性维护预防性维护8.6 软件再工程过程软件再工程过程正向工正向工程程库存目库存目录分析录分析文档重文档重构构逆向工逆向工程程代码重代码重构构数据重数据重构构 活动以线性顺活动以线性顺序发生，但并非序发生，但并非总是这
43、样。总是这样。 对于任意一个对于任意一个特定循环，可在特定循环，可在完成任意一个活完成任意一个活动后终止。动后终止。该模型定义的该模型定义的6类活动：类活动： 1. 库存目录分析；库存目录分析； 包含每个应用系统的信息，如：名称、构建日期、修改包含每个应用系统的信息，如：名称、构建日期、修改次数、过去次数、过去18个月报告的错误、用户数量、文档质量、预期个月报告的错误、用户数量、文档质量、预期寿命，等。从中选出再工程的候选者。寿命，等。从中选出再工程的候选者。 2. 文档重构；文档重构； （1）如果一个程序走向生命终点，不再经历变化，则保）如果一个程序走向生命终点，不再经历变化，则保持现状；（
44、持现状；（2）重构只针对当前正在修改的软件部分。）重构只针对当前正在修改的软件部分。 3. 逆向工程；逆向工程； 逆向工程是一个恢复设计结果的过程，从程序代码中抽逆向工程是一个恢复设计结果的过程，从程序代码中抽取数据结构、体系结构和处理过程的设计信息。取数据结构、体系结构和处理过程的设计信息。4. 代码重构；代码重构； 分析源代码，标注出与结构化程序设计概念不符的分析源代码，标注出与结构化程序设计概念不符的部分，重构它的代码，测试重构代码并更新代码。部分，重构它的代码，测试重构代码并更新代码。5. 数据重构；数据重构； 当数据结构较差时，进行再工程。如以文件方式保存当数据结构较差时，进行再工程
45、。如以文件方式保存数据变为以数据库方式存储。数据变为以数据库方式存储。6. 正向工程。正向工程。 也称革新或改造，即应用软件工程的原理、概念、技也称革新或改造，即应用软件工程的原理、概念、技术和方法来重新开发现有系统。术和方法来重新开发现有系统。第第8章小结章小结 主要包括软件系统说明、程序模块说明、操作环境、主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。支持软件的说明、维护过程的说明，便于软件的维护。 指出软件问题的登记情况，如日期、发现人、状态、指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。问题所属模块
46、等，为软件修改提供准备文档。 软件产品投入运行以后，发现了需对其进行修正、更软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。响作出详细的描述，提交审批。 软件工程开发中其它重要的文档软件工程开发中其它重要的文档 该月报系软件人员按月向管理部门提交的项目该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算
47、等。法以及下个月的打算等。 软件项目开发完成以后，应与项目实施计划对软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。作做出评价，总结出经验和教训。软件工程开发中其它重要的文档软件工程开发中其它重要的文档 本手册详细描述软件的功能、性能和用户界面，本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解使用户对如何使用该软件得到具体的了解,为操作为操作人员提供该软件各种运行情况的有关知识
48、，特别人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。是操作方法的具体细节。软件工程开发中其它重要的文档软件工程开发中其它重要的文档第第9章：面向对象方法学引论章：面向对象方法学引论9.1 面向对象方法学概述面向对象方法学概述9.1.1 面向对象方法学的要点面向对象方法学的要点 面向对象方法学的基本原则：尽可能模拟人类面向对象方法学的基本原则：尽可能模拟人类习惯的思维方式，使开发软件的方法与过程尽可能习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。接近人类认识世界解决问题的方法与过程。面向对象方法具有四个要点：面向对象方法具有四个要点： A认为
49、客观世界是由对象组成；认为客观世界是由对象组成； B把所有对象都划分成各种对象类（把所有对象都划分成各种对象类（Class）；）； C把若干对象类组成一个层次结构的系统（类等把若干对象类组成一个层次结构的系统（类等级）；级）； D对象彼此间仅通过传递消息互相联系。对象彼此间仅通过传递消息互相联系。 OO = Objects + Class + Inheritance + Communication with message 9.1.2 面向对象方法的优点面向对象方法的优点 1与人们习惯的思维方法一致；与人们习惯的思维方法一致； 2稳定性好；稳定性好； 3可重用性好；可重用性好； 4较易开发大型
50、软件产品；较易开发大型软件产品； 5. 可维护性好。可维护性好。9.1.3 喷泉模型喷泉模型9.2 面向对象的概念面向对象的概念9.2.1 对象对象 1、对象的形象表示、对象的形象表示 状态状态S操作操作1操作操作2操作操作3界面界面操作操作1、2、3的实现的实现图图9.2 对象的形象表示对象的形象表示1）定义）定义1：对象是具有相同状态的一组操作的集：对象是具有相同状态的一组操作的集合。合。2）定义）定义2：对象是对属性值和操作的封装。：对象是对属性值和操作的封装。3）定义）定义3:对象：对象：= 其中，其中，ID是对象的名字；是对象的名字；MS是对象中的操作集合；是对象中的操作集合；DS是
