韩峰先生，上海交通大学生命科学技术学院生物医学工程专业硕士研究生；张继武先生，博士，柯达医疗全球研发中心总经理，大亚太区研发总监，上海交通大学兼职教授、博士生导师。2006年8月10日收到。
一 医用软件的质量要求
1. 医用软件的质量要求
(1)医用软件对于软件的稳定性有很高的要求，任何可能产生的不稳定因素导致机器死机等故障都可能会在诊断过程中出现灾难性的后果。
(2)医用软件对于软件的准确性有很高的要求，任何帮助医生诊断的图像和信息经过软件的处理和传输以后都必须是正确的，错误的图像和信息都会误导医生做出错误的诊断，对病人产生严重的伤害。
(3)医用软件对于图像质量有很高的要求。图像不仅要正确，更重要的是要帮助医生做出正确的诊断，所以图像的质量一定要高，以将病灶信息在图像上清晰地显示出来。
(4)医用软件都要通过DICOM标准确认和验证，以便所需图像和信息能够在医院的整个信息化系统中进行传输。
(5)医用软件的开发需要满足法律法规的要求。如ISO13485标准，是对提供医疗设备和相关服务的组织的质量管理体系提出的要求。通过建立完善的质量管理体系和符合法律法规要求的医疗软件开发流程。
2. 提高软件质量的方法
那么怎样比较好地保证质量呢？与软件质量相对应的是软件缺陷，软件的质量控制其实就是控制其缺陷。缺陷越多质量越低，缺陷越少质量越高，最理想情况就是实现“零缺陷”。所以提高软件质量的基本手段是消除软件的缺陷，而消除缺陷的方式有两种：
a. 预防
这是提高软件质量的方式中最好的，也是最经济的一种。预防，就是在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程中。能力成熟度模型集成(Capability Maturity Model Integration，CMMI)中的软件质量保证是基于规范的过程控制的。因为软件的开发不同于其它产品的开发、制造，软件开发中不确定因素较多，风险较大，因此软件的开发更需要一套严格的流程来保证软件质量，所以过程的质量与产品的质量存在某种程度的因果关系。过程控制的好坏从某一方面体现软件产品质量的好坏。但是也不能简单的走向另一个极端，认为好的过程就等于好的质量。符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷。
b. 及时发现并修改
在软件开发过程中，即使人们的技术水平很高，并严格遵守规范，但有些缺陷仍无法避免。此时对待缺陷就应当像病人看病一样，越早发现，越早治疗，所花费的代价也就越少。在适当的质量保证原则下，可以使错误和缺陷的累积影响降低。其中一个最重要的原则就是在生存周期开始时就进行测试，然后测试所有阶段的成果。如果不这样做，质量错误的后期修改可能变得很昂贵。
对于医用软件的质量控制，同样也是从过程控制和测试两方面入手，同时在开发过程中更关注于医用软件的稳定性、准确性以及图像质量等方面。
二 软件开发过程控制
对于医用软件的开发，不管是从提高医用软件质量的目的还是为了满足医用软件开发的法律法规的要求出发，都需要对医用软件的开发过程进行控制和改善。因此，医用软件开发组织需要建立完善的质量保证体系，控制和改善医用软件开发过程，提高医用软件开发组织的软件过程能力和软件过程成熟度，从而保证并能够不断提高所开发的医用软件的质量。
我们医用软件开发组织建立了质量保证部门，该部门包含过程保证组(PQA)，软件测试组(SQE)，配置管理组(SCM)。由该部门来完成质量管理体系的建立、医用软件开发过程的控制和医用软件开发文档模板的编写。所建立的医用软件的开发过程满足ISO13485标准和CMMI模型的要求。下面将结合CMMI2级的关键过程域的实施，说明进行医用软件的开发过程以及如何通过对过程的控制和改善来保证所开发的医用软件的质量。
1. CMMI 2级的实施
CMMI只是为软件过程改进提供了标准和框架，具体怎样实施并没有固定模式可循，因此软件企业在实施过程中遇到了这样或那样的问题和困难。为了探索CMMI的实施策略，积累经验和方法，笔者结合自己的亲身实践，详细阐述在CMMI的实施过程中遇到的问题和解决办法。
a. 实施CMMI的策略
通过吸取国内外软件企业在实施CMMI过程中的经验教训，对CMMI模型进行深入研究，并结合实际情况，提出了如下实施CMMI的策略。
(1)正确定位CMMI实施的目标。我们一致认为：CMMI认证不是目的，通过在工作中贯彻CMMI的管理思想和采用CMMI建议的工作方法，规范软件开发过程，控制软件开发的各个环节，从而提高软件质量，才是最终目的。
(2)在企业内部进行CMMI培训和动员。在整个企业内部，由质量控制人员(QA)对所有软件开发人员进行培训，使所有员工都认识到实施CMMI在提高软件过程能力，从而提升企业竞争力上的战略意义和重要作用，使企业管理人员和软件开发人员真正了解和认识CMMI，自觉地按CMMI的方法去进行工作。
(3)根据企业情况，成立相应的工作组。根据CMMI的实施需要，成立各种专门的领导小组，包括测试组、软件配置管理组、软件质量保证组。
(4)对照CMMI标准，诊断公司软件过程的问题。CMMI强调软件过程的改进，因此首先要参照CMMI标准，找出企业生产过程中的问题：包括缺乏较好的文档编制规范和模板定义；缺乏较好的设计和编程规范以及较好的模板定义；缺乏较好的基线控制；缺乏较好的工作产品转化规范；缺乏较好的版本管理。
(5)充分利用各种工具。CMMI的每个成熟级别由几个关键过程区域(KPA)组成，每个KPA确定一组相关活动。在整个软件开发过程中引进相关工具，能帮助我们有效地进行这些活动，减缓各种繁琐的事务性管理工作的压力，事半功倍的实施CMMI。
(6)总结经验，改进软件过程模型。总结成功项目的经验，从中规划出一个具有实际意义的软件过程，按照CMMI规范评估这个过程，找出其中的优缺点。对不满足CMMI要求的地方加以改进，使其成为一个完善的软件过程。然后应用到以后的项目上，在实际使用过程中进一步发现其中的不足和错误之处，加以改进。
b. CMMI 2级的关键过程域的实施
(1)需求管理。保证软件产品满足客户需求是进行软件项目开发的主要任务。在项目初期及开发过程中，经常会碰到不明确的需求及频繁的需求变更，正确对待并处理这种情况可保证软件产品在预计的进度和成本范围内提交。需求管理过程的目标是管理和控制需求，维护软件计划、产品和活动与需求的一致性，并保证需求在软件项目中得到实现。
针对需求管理中的两个主要问题即需求的不明确和需求的变更，我们采取了以下措施来进行需求管理，从而实现需求管理这一关键过程域。
首先，分三个步骤进行需求分析和确认。
第一，通过与医务人员的充分交流来获取需求。需求获取可能是软件开发中最关键、最易出错和最需要交流的阶段。为此，对于每一个软件的需求分析，项目系统分析员和医疗领域专家应多次与医务人员及管理机构接触，召开需求讨论会。经常进行座谈讨论是需求获取成功的一个关键途径，只有进行深入收集和分析才能减少需求冲突或不一致性。
第二，书写需求规格说明书并编制需求跟踪矩阵。经反复的座谈讨论，最终确认软件需求。确认客户需求包括确认非技术需求、技术需求文档及编制需求跟踪矩阵。非技术需求在协议、条件和合同条款中描述，包括提交产品、提交日期和里程碑等内容。技术需求描述了系统的功能需求、性能需求、设计约束、编程语言和界面需求等多方面内容。需求跟踪矩阵是在充分了解技术需求的基础上编制的，需求跟踪矩阵的建立使项目经理能够跟踪每一需求的实现状态。
第三，进行需求评审。在需求被纳入到软件项目之前，由项目经理和质量保证人员评审需求，同时，客户代表和专家人士也参与项目需求的评审。评审的对象是需求确认的结果，包括非技术需求文档、技术需求文档和需求跟踪矩阵。评审的主要目的在于：确定需求用软件来实现是可行的、适当的；需求被清晰、正确地描述；需求是一致的、相互不矛盾的；需求是可测试的。
评审的结束标志着与客户协商确认需求的结束。通过高级管理者批准的需求文档放置到了软件库中进行配置管理和控制。
然而，在软件开发过程中，需求变更是不可避免的。要求在项目开始之前，已经和用户达成了一致明确的需求协议，该协议要纳入基线，受到严格的控制管理。如果需求发生变化，需要进行评审，并通过配置管理进行版本控制。这样一方面保证了需求的稳定性，但是另一方面也使得需求的变动相当繁琐。在现实中，用户的需求在开始时往往是很难十分明确的，在项目的进行过程中，用户常常会提出或多或少的新要求。限制客户需求的变化是不切实际的，这样只会造成客户的不满，并且导致开发出一个不符合用户需求的软件，一个没有价值的低质量的软件。因此，如果需求的变更不能适应需求的变化，必将在一定程度上制约开发过程的顺利进行，甚至影响到最终软件产品的质量。
我们在研究和分析过程中认为解决这一问题的一个可行的方法是采纳敏捷方法的思想：适当的适应变化。正如敏捷方法所描述的那样，及时和用户进行沟通，准确捕获用户真正的需求，一旦用户的需求发生变化，立刻进行相应的调整，而不是等到评审完毕，纳入基线之后，才做出相应的调整。但是，不受限的变更，必将造成变更过于频繁，使开发人员无所适从，甚至会打击其积极性，降低其开发效率。因此变更必须是受控的。我们采用的方法是在一段给定的时间内，需求是固定不变的。根据项目的规模和需求变更的情况，这段时间的大小可以各不相同。
由上可以看到，我们既保留了原有的变更控制措施，又通过时间的约定，增强了其变更措施的灵活性。
(2)项目策划。制定软件项目计划的目标不是“精确”，而是要“合理”，也就是说，在项目规模、成本、时间进度等方面，都是可行的。但实际情况是，软件项目计划的主要内容，如软件规模、人力资源、进度安排等，都是项目一开始就涉及而且到最后才逐步完善的，在项目实施中，项目计划总是处于“需改动”的状态。针对这一现象，我们不期望在项目一开始就能做出一个完美的计划。而是从第一个项目开始，就准备收集数据包括采用的估计办法、假设条件，历史数据等，当项目完成后，对这些数据进行分析和整理。通过若干个项目进行同样的实践，就可以得到较可靠的数据用于以后的项目计划。
(3)项目跟踪和监督。进行软件项目的跟踪和监督，以增加软件开发的可视性，提高对软件开发工程的控制能力。对于软件项目的跟踪和监督，主要由项目经理完成。项目经理对软件的跟踪和监督的内容包括四个方面：软件开发的进度、成本、风险和资源。项目经理从几个方面可以获取软件项目开发的进度和状态，包括开发人员的汇报；质量人员的反馈；从配置管理系统中获得等。项目经理对软件的跟踪和监督最主要的目的就是控制软件项目与原计划的偏离程度，一方面使正在开发的项目尽可能按照计划顺利的开发；另一方面也可从项目中收集数据进行分析，为以后的项目制定更合理的计划，使软件开发进入良性循环。
(4)供应协议管理。这一关键过程域的活动主要是对软件承包商进行管理，而我们的软件基本上都是内部开发，所以我们的活动主要包含两个方面：一是内部团队合作开发项目，这时不同项目组之间的联系和开发进度都需要质量保证人员进行调节和控制；二是向供应商购买组件，这时所购买的组件需要质量人员进行确认和验证。
(5)过程与产品质量保证。在CMMI中，软件质量保证(SQA)，犹如一个司法机构，配备一些擅长软件开发方法和软件过程管理的人员，在项目组人员都注重项目开发时，用另一只眼来观察和识别一些问题的根本原因。充分发挥SQA的作用，可以使其成为不断过程改进、总结分析的资源。
软件质量保证是CMMI 2级中的一个重要关键过程域，它是贯穿于整个软件开发过程中的第三方独立审查活动，在CMMI的过程中充当重要角色。SQA组织并不负责生产软件产品和制定质量计划，而是负责审计软件项目经理和软件工程组的质量活动并鉴别活动中出现的偏差。SQA的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行，就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件产品。
在软件的开发过程中，SQA部门的人员参与项目开发的全过程，他们的主要工作包括以下三个方面：通过监控软件的开发过程来保证产品的质量；保证生产出的软件和软件开发过程符合相应的标准与规程；保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。
在实践中我们发现，SQA工作要顺利开展，有以下方面要注意：首先，SQA人员不能是项目组的开发人员、配置管理人员或测试人员。一个项目的SQA人员除了监控项目过程，完成SQA相关工作以外。不应该参与项目组的其它实质性工作，否则，他会与项目组捆绑在一起，很难保持客观性。其次，SQA人员要有很强的沟通能力。SQA人员不在项目组中，是独立于软件项目的第三方。他只有和软件开发经理以及项目组中的开发人员保持很好的沟通，才能深入项目，了解项目的开发过程和进度，捕捉到项目中不符合要求的问题。再者，SQA人员要能应对繁杂的工作。SQA人员在跟踪项目过程中要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个SQA人员还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求SQA人员在处理这些事物时要耐心细致。最后，SQA人员要客观，有责任心。作为第三方对项目过程进行监督，SQA人员要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。
在实践工作中，我们感到，SQA活动对于提高软件质量确实卓有成效。SQA对各阶段的输出产品进行检查和审计，对软件开发过程进行评审和监督，使得问题能够尽快发现并及时解决，尽可能减少开发过程中问题与错误的积累和扩散，实现了软件开发全过程的质量检测和控制。
(6)配置管理。软件配置管理(Soft-ware Configuration Management，SCM)应用于整个软件开发过程，是CMMI 2级中一个非常重要的关键过程域。在软件开发过程中，不仅有很多文档需要管理，而且其变更是不断出现的，而变更加剧了项目中软件开发者之间的混乱。软件配置管理活动的目标就是为了标识变更、控制变更、确保变更正确实现并向其他有关人员报告变更。有效的软件配置管理能在软件项目的生命周期内建立并维护软件项目产品的完整性。
我们在配置管理活动中使用了Rational公司开发的ClearCase工具，具体开展的工作如下：标识软件工作产品、进行配置控制、记录配置状态和配置审计。
其中，标识软件工作产品(配置标识)是配置管理的基础。对外交付的软件产品，指定的内部软件工作产品及指定的内部使用的支持工具都要进行配置标识。
配置控制是配置管理的核心工作。配置控制主要包括存取控制、版本控制、变更控制和产品发布4个方面。配置管理通过对配置状态的记录来协调对软件产品的控制。及时记录并通知配置管理状态信息可保证软件开发人员了解配置项的历史与当前状态，避免由于沟通不当而造成软件开发版本的混乱。
配置审计用来验证软件库中软件产品的一致性和完整性。功能审计和物理审计作为配置审计的两个方面分别审计检验软件库内容的一致性和完整性。产品发布之前，我们会对软件库执行一次完全的配置审计过程，以保证产品发布的正确执行。
在配置管理活动中，我们深刻体会到使用管理工具的重要性。运用软件配置管理，避免了很多严重问题的出现。
例如，如果在开发过程中开发人员的机器因感染病毒或其它原因造成系统崩溃，源代码都丢失了，重装系统后，可以从配置管理服务器的版本对象库中通过文件的检出(Check Out)操作，得到了最新的源程序版本，避免了代码资源的丢失。
如果开发人员在执行文件的检入(Check In)操作时，没经过测试的程序把正确的源程序覆盖了，系统集成编译运行时发生错误，就可以通过历史记录，将版本对象库恢复到最近一次正常运行的状态，并且通过日志查到是谁，在何时，做了错误的检入操作，督促当事人重新修改代码并充分测试。
总之，配置管理的执行，对实现文档、用例、代码等的统一管理，减轻变更给项目开发和管理带来的影响，减少由于沟通不及时带来的项目返工起到了重要作用。为提高组织开发效率，保证软件产品质量和帮助项目如期完成做出了重要贡献。
(7)度量与分析。度量与分析是在项目开发的过程中周期性的对项目的结果进行评估，评估的主要内容包括：项目开发的成本，完成的质量，完成的进度和功能的实现。使项目管理人员可以更好的控制项目开发过程的各个方面。
c. CMMI的实施效果
通过一段时间实施CMMI进行软件开发过程管理后，我们进行了内部评估，检验实施CMMI的效果。评估结果如图1所示：
可以看到，我们的开发过程有了很大的提高。通过实施CMMI后，我们的医用软件的开发过程满足ISO13485标准的要求，从过程上保证所开发的医用软件的质量，同时整个医用软件开发过程更加规范，避免和降低了许多在软件开发过程中出现问题的可能性，确实提高软件组织的过程能力，缩短开发时间，减少开发费用，降低项目风险和提高医用软件质量。
