某软件企业在项目开发过程中目标明确，实施过程遵守既定的计划与流程，资源准备充分，..

（1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

（2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

（3）已定义级：用于管理方面和工程方面的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

（4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。

（5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域（Key Process Area，KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。每个级别对应的关键过程域见下表。

关键过程域的分类

CMMI

与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。据美国国防部资料显示，运用CMMI模型管理的项目，不仅降低了项目的成本，而且提高了项目的质量与按期完成率。

可以这样看，CMMI把各种CMM集成到了一个系列的模型中，CMMI的基础源模型包括软件CMM、系统工程CMM，以及集成化产品和过程开发CMM等。CMMI也描述了5个不同的成熟度级别。

每一种CMMI模型都有两种表示法，即阶段式和连续式。这是因为在CMMI的3个源模型中，CMM是“阶段式”模型，系统工程能力模型是“连续式”模型，而集成产品开发（IPD）CMM是一个混合模型，组合了阶段式和连续式两者的特点。两种表示法在以前的使用中各有优势，都有很多支持者，因此，CMMI产品开发组在集成这3种模型时，为了避免由于淘汰其中任何一种表示法而失去用户对CMMI的支持，并没有选择单一的结构表示法，而是为每一个CMMI都推出了两种不同表示法的版本。

不同表示法的模型具有不同的结构。连续式表示法强调的是单个过程域的能力，从过程域的角度考查基线和度量结果的改善，其关键术语是“能力”；而阶段式表示法强调的是组织的成熟度，从过程域集合的角度考查整个组织的过程成熟度阶段，其关键术语是“成熟度”。

尽管两种表示法的模型在结构上有所不同，但CMMI产品开发组仍然尽最大努力确保了两者在逻辑上的一致性，两者的需要构件和期望部件基本上都是一样的。过程域、目标在两种表示法中都一样，特定实践和共性实践在两种表示法中也不存在根本区别。因此，模型的两种表示法并不存在本质上的不同。组织在进行集成化过程改进时，可以从实用角度出发选择某一种偏爱的表示法，而不必从哲学角度考虑两种表示法之间的差异。

阶段式模型也把组织分为以下5个不同的级别。

（1）初始级：代表了以不可预测结果为特征的过程成熟度，过程处于无序状态，成功主要取决于团队的技能。

（2）已管理级：代表了以可重复项目执行为特征的过程成熟度。组织使用基本纪律进行需求管理、项目计划、项目监督和控制、供应商协议管理、产品和过程质量保证、配置管理，以及度量和分析。对于级别2而言，主要的过程焦点在于项目级的活动和实践。

（3）严格定义级：代表了以组织内改进项目执行为特征的过程成熟度。强调级别3的关键过程域的前后一致的、项目级的纪律，以建立组织级的活动和实践。

（4）定量管理级：代表了以改进组织性能为特征的过程成熟度。4级项目的历史结果可用来交替使用，在业务表现的竞争尺度（成本、质量、时间）方面的结果是可预测的。

（5）优化级：代表了以可快速进行重新配置的组织性能和定量的、持续的过程改进为特征的过程成熟度。

CMMI的具体目标是：

（1）改进组织的过程，提高对产品开发和维护的管理能力。

（2）给出能支持将来集成其他科目CMM的公共框架。

（3）确保所开发的全部有关产品符合软件过程改进的国际标准ISO/IEC15504对软件过程评估的要求。

使用在CMMI框架内开发的模型具有下列优点：

（1）过程改进能扩展到整个企业级。

（2）先前各模型之间的不一致和矛盾将得到解决。

（3）既有分级的模型表示，也有连续的模型表示，可任意选用。

（4）原先单科目过程改进的工作可与其他科目的过程改进工作结合起来。

（5）基于CMMI的评估将与组织原先评估得分相协调，从而保护当前的投资，并与ISO/IEC15504评估结果相一致。

（6）节省费用，特别是当要运用多科目改进时，以及进行相关的培训和评估时。

（7）鼓励组织内各科目之间进行沟通和交流。

开发过程

嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。

项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。

：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。

程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。

最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。

管理体系

灾备管理体系主要是指组织机构的各个层面，在日常状态和灾难状态下的各种管理工作，至少包括以下5个方面。

（1）灾难恢复组织机构。商业银行应结合本行机构设置的具体情况，设立灾难恢复组织机构，包括灾难恢复规划建设、运行维护、应急响应和灾难恢复等各阶段工作所需的人员，有关人员可为专职，也可为兼职，关键岗位的人员应有备份。商业银行可以参考《JR/T0044 2008银行业信息系统灾难恢复管理规范》，设置灾难恢复组织机构，包括决策层、管理层和执行层，各层之间分工明确、职责清晰。

（2）岗位与培训管理。灾备中心的应急生产岗位应与生产中心对等，只不过可以按照人员复用的原则，由灾备管理人员、开发测试人员或系统运维人员专职或兼职担任。对不同层次、不同部门的岗位，在灾难恢复策略规划、系统建设与运维、预案制定、演练和更新维护等不同阶段，应按照不同的培训目标，安排不同的培训计划。

（3）灾难恢复预案管理与演练。灾难恢复预案要长期保持有效性，必须在灾难恢复策略发生变化、演练发现问题、生产系统发生变更、人员出现调整等情况下，及时修订维护预案，做好变更管理、版本管理，以及发布管理等，确保合适的人员及时获得最准确、最合适的信息。演练验证灾难恢复预案有效性的最佳手段。演练管理就是要对演练的计划、场景、人员、过程、总结评估和后续完善调整等进行全面管理，通过演练来培养灾难恢复团队面对复杂环境的信心和冷静心态，验证灾难恢复能力，改进灾难恢复流程，发现并纠正灾备体系中的缺陷。

（4）灾备中心日常运维、灾难响应与重续运行管理。灾备中心应随时做好接替生产中心的准备，因此，必须像生产中心一样，对灾备中心的系统、网络和环境等基础资源进行运行维护，按照备份策略按时完成数据备份，完成灾备系统与生产系统的同步。当灾难发生后，灾难恢复组织机构的各层人员立即响应，在指挥报告、协调、联络、保障等工作机制的保障下，按照灾难恢复流程步骤，一步步地恢复信息系统及其支撑的关键业务功能。在生产系统成功切换到灾备中心运行后，要按照生产中心的规章制度、操作流程、技术规范来管理，保障生产系统安全稳定运行，直至生产中心重建并恢复了生产运行能力。

（5）外部资源管理。外部资源主要指商业银行的合作伙伴、服务商、设备商和外协人员等。当发生灾难时，可能需要这些外部资源的支持才能完成灾难恢复，比如，从设备供应商紧急采购灾备生产设备，从电信运营服务商紧急租用通信线路，从银联借调交易流水等。因此，需要与这些外部资源建立日常联系或签订协议，并不定期地测试其支持能力，以保证在灾难恢复期间，外部资源可以提供有效的支持。

评估

评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。

很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。

在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。

评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。

评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。

评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。

用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。

工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。

所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。

在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。

进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。

网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。

需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。

制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。

最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5