论文一 摘要
随着软件大型化，复杂化的发展，软件维护所耗费的资源越来越多，软件可维护性设计日益得到重视。我单位近几年开发综合业务 ATM交换机，用户对交换机的可维护性要求很高。我参加了该项目并负责软件的维护性设计工作。根据当前工作中在维护性设计中的不足。通过在各个软件开发阶段注重软件可维护性的应用，规范文档，使用CASE工具管理软件版本和成立软件可维护性设计小组等方面，为软件的可维护性设计提供了帮助，并最终开发出具有良好可维护性的交换机软件。但是由于初次实施这方面的工作，大家思想上认识不够，许多操作不习惯，并且单位里不具备专用的测试软件和其它CASE工具，在一定程度上制约了软件可维护性的实施。
正文
经过一系列的需求分析、设计、编码和测试之后，软件正式交付用户使用。至此，软件变进入维护期。软件维护的工作量特别大，随着时间的推移，软件维护对开发商带来的成本压力也越来越大。许多软件开发商要把70％的工作量用在维护已有的软件上，平均来说，大型软件的维护成本是开发成本的4倍左右。因此，在开发软件时，就应该考虑到可维护性问题，进行软件的可维护性设计。
2022年底，我单位开始为某集团开发综合业务 ATM交换机。该交换机支持多种业务应用，包括话音、IP数据、图像和视频等；用户可通过维护台或网管对交换机进行配置和管理；由于特殊的应用，用户对该交换机提出了很高的要求，并且提出要求产品交付使用之后，我单位要有很好的服务支持，鉴于将来要大批量生产交换机，软件的可维护性设计被提上日程。我有幸参加了该项目，并负责软件的维护性设计工作。
在以前的课题中，也曾提到过要进行软件的可维护性设计，但在真正实施过程中，还存在诸多问题，主要表现在：
在本交换机软件的设计过程中，我们通过注重软件可维护性的开发过程，规范文档，使用CASE工具管理软件版本和成立软件可维护性设计小组等方面进行软件的可维护性设计，最终开发出具有良好可维护性的交换机软件。
一、注重可维护性的开发过程
在整个交换机软件的开发过程中，从软件易于理解、易于测试、易于修改的角度出发，提高软件的可维护性。
在需求分析阶段，和用户进行充分的交流和协商，对将来要改进的和可能要修改的部分进行明确。由于该交换机所涉及的业务种类广泛，并且综合了话音、IP和网管等多种技术，任何一种技术实现的功能不完善或者扩展性不好，都不会让用户满意。但是，另一方面，又考虑到用户需求和功能需求并非容易获取，所以通过和用户定期交流，举办各种形式的讨论等方式尽可能了解当前的需求和以后需要扩展的需求信息，由专人整理记录这些信息，作为以后的跟踪内容。即使在其它设计阶段对需求的临时变动，也要在这个记录中体现。
在设计阶段，交换机软件被划分为不同模块进行设计，并遵循“高内聚、低耦合”的设计原则；这些工作便于将来软件维护工作的进行。同时也已考虑到，对可能要扩展的地方，预留出充足接口。在一些模块中，如网管模块中，根据功能，尽可能使用面向对象的设计方法，以便维护时的修改和升级。
在编码阶段，我和小组成员制定了统一的编码规范，经过半天的培训，强化编码人员对注释的使用，并强调要保证注释的质量，对有可能出现误解的地方，注释的要详细。并且，每个文件都要注明编写者，生产日期和版本号。
在测试阶段，测试组成员已经负责进行测试，我们小组这时的工作是根据测试报告，对照测试大纲和用例设计，对当前的测试进行总结，比如，何种测试用例发现何种错误，最常见的错误，如何从测试结果判断是哪种错误，该错误所在的模块是什么。在相关人员修改错误时，记录排错时的思路和过程。特别是，根据这些总结，我们编写了“ATM交换机软件故障解析”，这篇总结在后来的维护阶段被证明是最受欢迎的文档之一。
在维护阶段，制定严格的管理要求。每一次维护工作之后，都要按照配置关联，同步更新维护有关的系统文档和用户文档，包括维护需求、源代码、注释、设计文档、测试文档和用户使用手册等，保证系统的一致性。维护中所进行的修改要专人记录，生成“ATM交换机维护更新”文档，做为内部文件存档。同时把一些内容扩充到“ATM交换机软件故障解析”中。在用户使用时，做好用户的培训工作，初期由专人和用户一起操作交换机，直到能熟练操作，以免用户使用交换机时产生不满。
二、规范文档
交换机交付用户使用之后，除了在培训时所了解的内容之外，为了让用户对交换机软件能够更好的理解和使用，向用户提供了多种随机文档，包括功能说明，安装文档，用户使用手册，参考手册，管理员指南等。在文档的编写过程之前，我们编写了“ATM交换机软件文档编写规范”，对文档格式和一些必要内容进行了规范，保证各文档的风格一致，内容一致。对于一些用户使用中容易出错的地方，比如配置某种功能时，在用户使用手册示例说明。在具体编写文档时，根据设计人员的反馈信息，也及时调整了文档编写规范。
在设计开发过程中，对某个问题进行修改，或者功能增删，要充分考虑到问题所涉及的不同文档，保证前后文档在该问题的一致性。对于所修改的部分，要填写“更改单”，需要写明更改人，更改理由，更改所影响的程序和文档，更改日期，批准人。采用CASE工具在这一方面也起到了事半功倍的作用。
三、使用CASE工具管理软件版本
在软件的设计编码过程中，尤其是在调试阶段，会不断的生成新的程序版本。为了有效的管理版本问题，采用Ration公司的ClearCase工具，由专人负责进行管理，从而保证软件版本的一致性。
四、成立软件可维护性设计小组
为了有效的对软件可维护性设计进行管理，成立了软件可维护性设计小组。我担任小组组长，明确了维护性设计的工作内容和各人的责任，针对不同的模块，又确定四个责任人。在运作过程中，组长对软件开发阶段所需进行的工作进行协调，各负责人对维护性设计所涉及的变动控制进行维护。
因为交换机软件的各个模块开发时间有穿插，因此，对开发过程中出现的一些问题，包括技术方面和管理方面的问题，我们都及时进行了记录，对后面开发的软件模块进行指导，避免了同样问题的再次发生。现在这份文档已经成为单位新课题启动时的“必修”文档。
按照上面的思路，经过两年多的工作，我们已完成了交换机软件的开发，新的软件运行良好，交付用户后，用户很满意，受到了业务部门和技术部门高层的赞许。尤其是我们所总结的“ATM交换机软件故障解析”和“ATM交换机软件文档编写规范”等文档，对单位其它课题也起到了很好的指导和规范作用。并且，在提高软件可维护性的同时，也提高了软件产品的质量，我自己的开发管理水平也得到了很大的提升。单位的高层领导对我们制定的规范和做法也表示认可，正式在其它课题中推广。
总结
然而，由于初次在整个软件开发过程中进行可维护性设计，还有许多要改进的地方。许多情况下，现有的可维护性设计措施理论性太强，具体实施时可参考的依据少，比如我们测试小组如何更好的与各课题开发组间进行协调工作，感觉还是有不尽人意的地方。在测试阶段，单位条件所限，没有采用专业的测试软件进行测试，主要靠人工根据经验生成测试用例，测试力度不够，隐含的问题较多，这也不利于今后的维护工作。
软件可维护性设计是一个长期的工作过程，我希望今后能够不断的充实自己在这方面的知识，提供整体能力，为单位软件可维护性设计方面提供新的、好的思路。
论文二 摘要
2020年3月1日至12月20日，我参加了“数据安全访问平台”项目的开发，担任系统分析员的工作。该项目是某行业用户“数据中心二期”建设的主要内容，目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。
由于系统交付后，存在较长维护期，同时系统存在升级与扩展的情况，因此本项目对系统的可维护性设计要求较高。本文结合作者实践，讨论了从软件设计上提高可维护性的方法和措施：通过模块化设计方法和提高设计文档质量，改善软件的可理解性；通过提供测试接口和采用测试框架工具，改善软件的可测试性；通过动态库加载和针对接口编程的方法，提高软件的可扩展性。最后分析了采用方法的效果。
正文
2020年3月1日至2020年12月20日，我参加了“数据安全访问平台”项目的开发，担任系统分析员的工作。“数据安全访问平台”是某行业用户“数据中心二期”建设的主要内容。在一期建设中已建成数据的统一存储和统一分发框架。但主要存在以下问题：无法获得应用用户对数据库的操作日志；开发人员对数据库的使用不规范，查询的结果集过大，导致数据库的性能大幅下降；应用直接使用数据库的登录数据库，存在着一定的安全隐患。“数据安全访问平台”的目标是：建立数据统一访问接口及其使用标准，规范、约束和审计数据应用访问数据库的行为，对数据应用提供强制审计的技术手段。
该项目具有较高的业务需求风险和技术风险。由于没有成熟系统做为参照，该项目需求不是很明确，而且系统涉及甲方多个利益相关方，各方对系统的安全和审计功能、运行维护、可靠性、性能和易用性有者不同的观点，某些观点之间还存在冲突。同时系统作为“数据中心”的基础设施之一，所有的应用系统都要通过本系统完成数据库访问。系统的可靠性和性能直接影响到应用系统的正常运行。整个系统分为6个子系统，包括JDBC驱动封装子系统、ADO.Net驱动封装子系统、WebService 接口子系统、管理配置网站、存储子系统（SQL Server2005数据库，存储配置信息）和监控子系统（数据库网络协议分析与连接控制）。
一、系统的可维护性需求
本系统有较高的可维护性需求。首先，系统作为数据中心应用的基础平台，数据中心的新建应用系统必须依赖于本系统，系统具有较长生命周期；同时合同中规定系统正式上线后，公司需要提供1年的免费维护。其次，本项目中的接口子系统是基于 JDBC5.0和ADO．Net2.0实现的，随着JDBC与ADO．Net的升级，接口子系统也需要升级。然后，监控子系统对Oracle和SQL Server数据库的网络包进行解析，由于商用数据库网络包格式不公开，我们在解析时会有遗漏；用户要求，当发现未能解析的数据包时，需要及时添加到监控子系统中。最后，由于没有成熟系统做为参照，该项目开始时需求不是很明确，在开发过程中用户提出了一些新需求，由于工期的限制，经过与用户协商，这些新需求不在本项目中完成；用户准备视系统的运行情况，设立新的项目完成这些剩余需求。因此可维护性是本系统的一个重要质量指标。
为了增加系统的可维护性，减少维护人员理解和修改系统的难度，我们在本系统的设计上，不仅仅关注系统的功能需求实现，而且重视系统的可维护性需求。决定软件可维护性的因素主要包括：软件的可理解性、可测试性和可修改性。在整个系统设计过程中，我们都注重改善系统的可理解性、可测试性和可修改。
二、改善软件的可理解性
本系统涉及的问题域有一定的复杂性，如果将整个问题域的复杂性完全暴露给维护人员，维护人员很难理解整个系统。因此，首先，我们将整个系统划分为功能独立的六个子系统；其次，在各个子系统设计时，我们都采用了模块化的方法，即将内聚性高的业务逻辑合并封装成独立的模块；最后，重视设计文档质量，对设计文档做了内部审核，确保文档清晰准确了描述了设计。
监控子系统是本系统的关键部分之一。公司原有Oracle数据库监控子系统，本项目中需要在原有监控系统中增加SQLServer的监控功能。监控子系统的流程是网络协议包的截获、数据库协议解析、监控审计处理模块。由于原监控子系统只是处理 Oracle，其关注功能的实现，三个模块划分的不清晰。例如，使用了过多全局变量在模块间传递数据；功能分布不合理，导致模块之间相互依赖；一个源代码文件包含两个相关功能代码。本项目中，除了添加 SQLServer的监控功能外，我们还改善了子系统的设计，增强各个模块的内聚性，降低模块之间的耦合性。首先，各个功能的相关代码处于不同的代码目录；其次，三个模块都做成了单独的静态库，总控模块负责调度各个库，并且明确了各个模块对外提供的接口，模块之间的调用都通过接口完成。通过这种方式将系统进行清晰的划分，维护人员可通过对模块接口的学习快速了解子系统的运行流程，当需要时再对某模块做进一步分析。
三、改善软件的可测试性
维护人员对代码进行修改后，必须进行测试，才能保证软件的质量。并且，用户对系统的可靠性要求很高。因此，在软件设计的整个过程中，我们都考虑了测试的问题。首先，各个子系统的内部模块必须是单向依赖，对出现循环依赖的模块，我们采用调整功能分布，抽取公共模块等方面消除循环依赖。其次，对于接口子系统，我们需要对某些模块内部进行深入的测试，而由于模块接口的封装性，无法直接访问内部数据；对于这样的情况，我们在设计这样的模块时，专门提供了测试接口。最后，开发中采用了CppUnit、NUnit和JUnit测试框架，通过测试框架来组织测试驱动程序。
四、改善软件的可扩展性
监控子系统采用网络监听的方式获取数据库访问的信息，这种方案的优点是不给业务系统增加性能负担，缺点是由于商用数据库协议不公开的，虽然我们经过大量的测试，但是肯定是有遗漏的。
为了当发现未能解析的数据包时，及时添加到监控子系统，同时不重新编译系统，我们进行了可扩展性设计。我们采用了动态库加载和针对接口编程的方法。监控子系统启动后，会加载指定目录下的动态库（符合名字规范），这些动态库都实现了规定的接口。子系统当收到一个网络包后，会依次询问所有的动态库是否能解析该网络包。这样只需要将新开发的动态库拷贝到制定目录，并重启动监控子系统就可以完成系统的升级。
总结
在系统的维护阶段，发现了较严重缺陷2个与8个一般缺陷，同时，发现了监控子系统不能解析的5种协议包。维护阶段的开发人员与开发阶段有了较大变化。由于在系统设计上重视可维护性，软件进行模块化设计，提供了完备的设计文档，维护人员可以较快的定位与解决问题；由于考虑了系统的可测试性，提供了回归测试集，维护人员可以运行回归测试验证软件质量；由于考虑监控子系统的扩展性，维护人员可以及时增加了新的协议包解析功能。综上所述，由于在设计中考虑了软件的可理解性、可测试性与可扩展性，很大程度上提高了系统的可维护性。
论文三 摘要
2019年6月，我们公司为满足现代网络多媒体教学的需要，决定自主开发《网络教学录播系统》，我作为公司的技术骨干，有幸参与了该项目，主要负责系统的分析和设计工作。该系统主要是通过校园网络对教师授课现场进行直播，并将直播内容记录成ASF格式的文件，供学生点播。软件工程实践表明，维护工作量占软件开发的大部分工作。本系统今后也必然会面临一些维护工作，例如，增加生成点播、演示光盘制作等新功能；系统业务功能不变，为OEM用户定做新界面；更换不同型号或品牌的音视频采集卡；技术支持人员为用户解决售后问题等。因此，进行本系统设计时，为了提高系统的可维护性，我们采用了一些方法和措施，例如，设计合理的系统体系结构；业务逻辑与界面分离；用日志记录系统的运行情况；用配置文件降低软件对硬件设备依赖。目前，该系统已经成功面市，受到用户和售后支持人员的好评，但也存发现一些不足之处，例如，对老的音视频采集卡支持不太理想。
正文
随着现代教育技术改革的深化，流媒体技术也越来越多的应用于教学领域。正是在这样的背景下，我们决定开发《网络教学录播系统》，其主要功能是通过校园网络直播教师授课实况，并将实况媒体流记录成ASF格式媒体文件供学生课后点播用。它主要功能有音视频采集、音视频编解码、音视频回放、记录文件、索引文件、剪辑合并文件、点播、直播等。 采集功能：从采集卡获取音视频数据。 音视频编解码：采用WMV/WMA编解码算法进行音视频的编解码。 音视频回放：播放本地文件或网络媒体流。 记录文件：将网络媒体流记录成ASF格式的音视频文件。 索引文件：对记录生成的ASF文件进行索引。 剪辑合并文件：剪辑ASF格式的文件；将两个ASF格式的文件合并成一个文件。 直播点播：用户通过网络播放ASF文件或网络媒体流。
在上述系统的开发过程中，我负责系统的分析和设计工作。软件工程的实践表明，软件维护工作占整个系统开发工作的大部分。本系统也不例外，也将会面临一些维护工作，主要有增加生成点播、演示光盘制作等功能；为OEM用户定制新界面，但业务功能不变化；更换不同型号音视频采集卡；技术支持人员为用户解决售后问题等。为了使系统具有良好的可维护性，我们在设计本系统时，采取了一些方法和措施来提高系统的可维护性：
一、设计合理的体系结构，便于将来系统增加生成点播、演示光盘制作等新功能。
在设计本系统的体系结构时，我们将系统划分成五个子系统，分别为编码器子系统、媒体服务器子系统、终端播放子系统、媒体文件编辑子系统、Web应用子系统系统。 编码器子系统负责对现场进行采集、编码，并通过HTTP协议发送给媒体服务器子系统进行再发布；播放终端子系统播放本地媒体文件或者应用HTTP、RTP/RTCP、RTSP等网络协议，播放来自媒体服务器子系统的网络媒体流；Web应用子系统为用户提供基于Web的可视化操作界面，便于进行点播和直播操作；媒体文件编辑子系统只是对记录生成ASF文件做后期编辑，不与其它子系统进行直接交互。 在设计Web应用子系统时，我们采用B/S体系结构，使得用户无需安装专门的客户端软件即可使用点播、直播等功能，当本子系统升级时，只是需要在Web服务器上更新、升级，无需对每个客户端都进行更新、升级，减轻了系统升级的维护工作量。 这样进行系统的划分，子系统之间松散耦合、各个子系统内部高内聚，使系统将来添加新功能更容易。
二、系统界面与业务功能相分离，减少为用户（例如，OEM）变更软件界面的工作量。
将来我们经常会根据OEM用户的需求来定制新的用户界面，但业务功能不变。在设计本系统时，使系统界面与业务功能分离，它们之间通过消息或传递数据参数进行交互，系统界面只负责接收用户输入、显示业务功能层的运算结果，业务逻辑层负责具体的业务计算。这样，当用户（例如，OEM用户）对系统界面部分有修改需求时，只需要界面部分进行修改，无须对业务功能部分做改动。由于仅仅是对界面部分的修改，降低了软件修改、测试的难度；因为业务逻辑部分不作改动，所以无需对业务逻辑做专门的测试，而只要验证业务逻辑层与系统界面的配合，大大减少了测试的工作量和测试的难度。由此，可见软件界面与业务功能的分离，提高了系统的维护性。
三、用日志记录系统运行的情况，便于技术支持人员为用户解决问题。
日志是提高软件系统可维护性的很常用的方法，但是，很多时候系统日志是留于形式，并没有能够真正发挥其应有的作用。在本系统中，我们设计了两类日志，即系统运行日志和用户操作日志。系统运行日志主要记录用户系统运行的情况，包括系统启动过程、系统运行时执行的操作，以及退出系统过程。用户操作日志主要记录在系统运行期间，登陆用户对系统所做的操作，以及操作的结果等。我们设计以年、月、日等信息自动生成系统运行日志和用户操作日志的文件名称，例如：“Sys_2006-1-24.log”、“User_2006-1-24.log”，并以追加的方式分别记录每天系统运行的情况和用户所做的操作信息。系统日志具体记录的内容：操作时间（时：分：秒.毫秒）、操作的名称（具体到执行某个函数或方法）、操作执行结果、具体错误信息等。用户操作日志具体记录的内容：操作时间（时间：分：秒）、用户名称、用户的类型、用户执行操作的名称、操作结果等。 有了日志记录，技术支持人员可以通过分析系统运行日志找出用户问题的原因；系统管理员可以通过分析用户操作日志，每个用户执行操作的情况，便于系统管理人员对系统进行维护。
四、用硬件配置文件来降低系统软件对音视频采集卡硬件的依赖，减轻更换卡时的维护工作量。
目前，市面上有许多视频采集设备，如何是本系统软件能够支持多种硬件采集设备？在系统设计时，要重点考虑的问题。在设计编码器子系统时，我们设计了设备配置文件，来降低软件对硬件采集设备的依赖程度。该设备配置文件中，存放有采集设备的名称、设备的唯一标识（通常是设备GUID）、采集设备源的名称（至少有一个）。当用户要更换硬件采集设备时，只要修改采集配置文件中相应的配置项，无需对软件进行修改，系统就能够在新的硬件采集设备上运行，大大减轻了系统更换硬件设备的维护工作量，提高系统的可维护性。
总结
目前，该系统已经成功投入市场，用户和技术支持人员一致认为该系统容易维护。现在看来，在本系统的设计过程中，所采取的提高系统可维护性的方法和措施取得了良好的效果。例如，沈阳某用户来电，说编码器子系统无法正常直播，由于我们的技术支持人员不在现场，无法看到对方的实际运行情况，所以只能够通过查看对方发来的系统运行日志来分析问题的原因，发现是由于编码器子系统在连接媒体服务器子系统时，发生了超时失败。经询问用户媒体服务器的IP地址，发现编码器所使用的IP地址与媒体服务器实际IP地址不一致。 但是，本系统也存在一些不足之处，例如，我们采用设备配置文件，来降低系统软件对硬件采集设备的依赖，这种方法对WDM驱动模式的采集设备，能够做到仅修改配置文件就能够是系统在新的硬件设备环境中正常工作，但是对于VFW驱动模式（比较早的采集设备驱动模式）的采集设备，我们不但需要修改配置文件，还要适当的修改程序代码，才能够使系统正常工作。
更多内容请见： 备考系统架构设计师-核心总结索引