【中项第三版】系统集成项目管理工程师 | 第 5 章 软件工程② | 5.4 - 5.8
前言
第 5 章对应的内容选择题和案例分析都会进行考查，这一章节属于技术的内容，学习要以教材为准。
目录
5.4 软件实现
软件设计完成后，进入软件开发实现过程，在此过程中，需要重点关注软件配置管理、软件编码、软件测试、部署交付以及软件过程能力成熟度建设等。
5.4.1 软件配置管理
软件配置管理(Software Configuration Management，SCM)是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。在软件建立时变更是不可避免的，而变更加剧了项目中软件开发者之间的混乱。SCM活动的目标就是标识变更、控制变更、确保变更正确实现，并向其他有关人员报告变更。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小，并最有效地提高生产效率。软件配置管理的核心内容包括版本控制和变更控制。
1 版本控制(Version Control)
版本控制是指对软件开发过程中各种程序代码、配置文件及说明文档等文件变更的管理，是软件配置管理的核心思想之一。版本控制最主要的功能就是追踪文件的变更。并行开发中最常见的不同版本软件的错误（Bug）修正问题也可以通过版本控制中分支与合并的方法有效地解决。
2 变更控制(Change Control)
变更控制的目的并不是控制变更的发生，而是对变更进行管理，确保变更有序进行。对于软件开发项目来说，发生变更的环节比较多，因此变更控制显得格外重要。项目中引起变更的因素有两个：一是来自外部的变更要求，如客户要求修改工作范围和需求等；二是开发过程中内部的变更要求，如为解决测试中发现的一些错误而修改源码，甚至改变设计。比较而言，最难处理的是来自外部的需求变更，因为IT项目需求变更的概率大，引发的工作量也大（特别是到项目的后期）。
软件配置管理与软件质量保证活动密切相关，可以帮助达成软件质量保证目标。软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付等活动。
▲ 软件配置管理计划：软件配置管理计划的制订需要了解组织结构环境和组织单元之间的联系，明确软件配置控制任务；
▲ 软件配置标识：识别要控制的配置项，并为这些配置项及其版本建立基线；
▲ 软件配置控制：关注的是管理软件生命周期中的变更；
▲ 软件配置状态记录：标识、收集、维护并报告配置管理的配置状态信息；
▲ 软件配置审计：独立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动；
▲ 软件发布管理与交付：通常需要创建特定的交付版本，完成此任务的关键是软件库。
5.4.2 软件编码
所谓编码，就是把软件设计的结果翻译成计算机可“理解和识别”的形式，用某种程序设计语言书写的程序。程序的质量主要取决于软件设计的质量。但是，程序设计语言的特性和编码途径也会对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。
5.4.3 软件测试
软件测试是在将软件交付给客户之前所必须完成的重要步骤。软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。软件测试的目的就是确保软件的质量。
1 测试方法
软件测试方法可分为静态测试和动态测试。
①静态测试是指被测试程序不在机器上运行，只依靠分析或检查源程序的语句、结构、过程等来检查程序是否有错误，即通过对软件的需求规格说明书、设计说明书以及源程序做结构分析和流程图分析，从而找出错误。
静态测试包括对文档的静态测试和对代码的静态测试。
对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查（Desk Checking）、代码走查和代码审查的方式。经验表明，使用这种方法能够有效地发现30%—70%的逻辑设计和编码错误。
②动态测试是指在计算机上实际运行程序进行软件测试，对得到的运行结果与预期的结果进行比较分析，同时分析运行效率和健壮性能等。一般采用白盒测试和黑盒测试方法。
白盒测试也称为结构测试，主要用于软件单元测试中。按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按设计规格说明书的设定进行。白盒测试方法是从程序结构方面出发对测试用例进行设计，主要用于检查各个逻辑结构是否合理，对应的模块独立路径是否正常，以及内部结构是否有效，包括控制流测试、数据流测试和程序变异测试等。另外，使用静态测试的方法也可以实现白盒测试。使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考查对程序逻辑的覆盖程度，主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。
黑盒测试也称为功能测试，它是通过测试来检测每个功能能否正常使用。完全不考虑（或不了解）程序的内部结构和处理算法，根据需求规格说明书设计测试实例，并检查程序的功能是否能够按照规范说明准确无误地运行。对于黑盒测试行为必须加以量化才能够有效地保证软件的质量。黑盒测试根据SRS所规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。
2 测试类型
①单元测试主要是对该软件的模块进行测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类（统称为模块），其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错。单元测试的技术依据是软件详细设计说明书，着重从模块接口、局部数据结构、重要的执行通路、出错处理通路和边界条件等方面对模块进行测试。
②集成测试一般要对已经严格按照程序设计要求和标准组装起来的模块同时进行测试，明确该程序结构组装的正确性，发现和接口有关的问题。在这一阶段一般采用白盒测试和黑盒测试结合的方法进行测试，验证这一阶段设计的合理性以及需求功能的实现性。集成测试的技术依据是软件概要设计文档。除应满足一般的测试准入条件外，在进行集成测试前还应确认待测试的模块均已通过单元测试。
③确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致。
④系统测试的对象是完整的、集成的计算机系统，目的是在真实系统工作环境下，检测完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。主要测试内容包括功能测试、性能测试、健壮性测试、安装或反安装测试、用户界面测试、压力测试、可靠性及安全性测试等。其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法；性能测试主要验证软件系统在承担一定负载的情况下所表现出来的特性是否符合客户的需要。系统测试过程较为复杂，由于在系统测试阶段不断变更需求造成功能的删除或增加，从而使程序不断出现相应的更改，而程序在更改后可能会出现新的问题，或者原本没有问题的功能由于更改导致出现问题。所以，测试人员必须进行多轮回归测试。系统测试的结束标志是测试工作已满足测试目标所规定的需求覆盖率，并且测试所发现的缺陷已全部归零。
⑤配置项测试的对象是软件配置项，配置项测试的目的是检验软件配置项与SRS的一致性。配置项测试的技术依据是SRS（含接口需求规格说明）。除应满足一般测试的准入条件外，在进行配置项测试之前，还应确认被测软件配置项已通过单元测试和集成测试。
⑥回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。
3 面向对象的测试
OO系统的测试目标与传统信息系统的测试目标是一致的，但OO系统的测试策略与传统的结构化系统的测试策略有很大的不同，这种不同主要体现在两个方面，分别是测试的焦点从模块移向了类，以及测试的视角扩大到了分析和设计模型。与传统的结构化系统相比，OO系统具有3个明显特征，即封装性、继承性与多态性。正是由于这3个特征，给OO系统的测试带来了一系列的困难。封装性决定了OO系统的测试必须考虑到信息隐蔽原则对测试的影响，以及对象状态与类的测试序列；继承性决定了OO系统的测试必须考虑到继承对测试充分性的影响，以及误用引起的错误；多态性决定了OO系统的测试必须考虑到动态绑定对测试充分性的影响，抽象类的测试及误用对测试的影响。
4 软件调试
软件调试（排错）与成功的测试形影相随。测试成功的标志是发现了错误，根据错误迹象确定错误的原因和准确位置，并加以改正，主要依靠软件调试技术。常用的软件调试策略可以分为蛮力法、回溯法和原因排除法。
5.5 部署交付
5.5.1 软件部署
①软件部署存在着风险，这是由以下原因造成的：应用软件越来越复杂，包括许多构件、版本和变种；应用发展很快，相继两个版本的间隔很短（可能只有几个月）；环境的不确定性；构件来源的多样性等。
②软件部署过程的主要特征有：过程覆盖度、过程可变更性、过程间协调和模型抽象。已经提出一些抽象的软件部署模型，用于有效地指导部署过程，包括应用模型、组织模型、站点模型、产品模型、策略模型和部署模型。
③软件部署过程中需要关注的问题有：安装和系统运行的变更管理，构件之间的相依、协调，内容发放，管理异构平台，部署过程的可变更性，与互联网的集成和安全性。
④软件部署的目的是支持软件运行，满足用户需求，使得软件系统能够被直接使用并保障软件系统的正常运行和功能实现，简化部署的操作过程，提高执行效率，同时还必须满足软件用户在功能和非功能属性方面的个性化需求。
⑤软件部署模式分为面向单机软件的部署模式、集中式服务器应用部署和基于微服务的分布式部署。面向单机软件的部署模式主要适用于运行在操作系统之上的单机类型的软件，如软件的安装、配置和卸载；集中式服务器应用部署主要适用于用户访问量小（500人以下）、硬件环境要求不高的情况，诸如中小组织、高校在线学习、实训平台等；基于微服务的分布式部署主要适用于用户访问量大、并发性要求高的云原生应用，通常需要借助容器和DevOps技术进行持续部署与集成。
5.5.2 软件交付
传统的软件交付过程是指在编程序改代码之后，直到将软件发布给用户使用之前的一系列活动，如提交、集成、构建、部署、测试等。
传统软件交付流程可能存在的问题包括以下3个方面：
①业务人员产生的需求文档沟通效率较低，有时会产生需求文档描述不明确、需求文档变更频繁等问题。
②随着开发进度的推进，测试人员的工作量会逐步增加，测试工作的比重会越来越大，而且由于测试方法和测试工具有限，自动化测试程度低，无法很好地把控软件质量。
③真实项目中运维的排期经常会被挤占，又因为手工运维烦琐复杂，时间和技术上的双重压迫会导致运维质量难以保证。
因为存在以上问题，所以传统的软件交付经常会出现开发团队花费大量成本开发出的功能或产品并不能满足客户需求的局面。由此可以总结出传统的软件交付存在2个层面的困境：
①从表现层来看，传统软件交付存在进度不可控、流程不可控、环境不稳定、协作不顺畅等困境；
②表现层的问题其实都是由底层问题引起的，从根源上来说，存在分支冗余导致合并困难，缺陷过多导致阻塞测试，开发环境、测试环境、部署环境不统一导致的未知错误，代码提交版本混乱无法回溯，等待上线周期过长，项目部署操作复杂经常失败，上线之后出现问题需要紧急回滚，架构设计不合理导致发生错误之后无法准确定位等困境。
5.5.3 持续交付
在评价互联网公司的软件交付能力的时候，通常会使用两个指标：一是仅涉及一行代码的改动需要花费多少时间才能部署上线，这是核心指标；二是开发团队是否在以一种可重复、可靠的方式执行软件交付。目前，国内外的主流互联网组织部署周期都以分钟为单位，互联网巨头组织单日的部署频率都在8000次以上，部分组织达20000次以上。高频率的部署代表着能够更快更好地响应客户的需求。
5.5.4 持续部署
对于持续交付整体来说，持续部署非常重要。
1 持续部署方案
容器技术一经推出就被广泛地接受和应用，对比传统的虚拟机技术，其优点主要有：容器技术上手简单，轻量级架构，体积很小；容器技术的集合性更好，能更容易对环境和软件进行打包复制和发布。
容器技术的引入为软件的部署带来了前所未有的改进，不但解决了复制和部署麻烦的问题，还能更精准地将环境中的各种依赖进行完整的打包。
2 部署原则
在持续部署管理的时候，需要遵循一定的原则，主要包括：
部署包全部来自统一的存储库；
所有的环境使用相同的部署方式；
所有的环境使用相同的部署脚本；
部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作；
整体部署由运维人员执行；
仅通过流水线改变生产环境，防止配置漂移；
不可变服务器；
部署方式采用蓝绿部署或金丝雀部署。
3 部署层次
部署层次的设置对于部署管理来说也是非常重要的。首先要明确部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。完整的镜像部署包括3个环节：Build-Ship-Run。
Build：跟传统的编译类似，将软件编译形成RPM包或者Jar包；
Ship：将所需的第三方依赖和第三方插件安装到环境中；
Run：就是在不同的地方启动整套环境。
制作完成部署包之后，每次需要变更软件或者第三方依赖、插件升级的时候，不需要重新打包，直接更新部署包即可。
4 不可变服务器
在部署原则中提到的不可变服务器原则对于部署管理来说非常重要。不可变服务器是技术逐步演化的结果。在早期阶段，软件的部署是在物理机上进行的，每一台服务器的网络、存储、软件环境都是不同的，物理机的不稳定让环境重构变得异常困难。后来逐渐发展为虚拟机部署，在虚拟机上借助流程化的部署能较好地构建软件环境，但是第三方依赖库的重构不稳定为整体部署带来了困难。现阶段使用容器部署不但继承和优化了虚拟机部署的优点，而且很好地解决了第三方依赖库的重构问题，容器部署就像一个集装箱，直接把所有需要的内容全部打包进行复制和部署。
5 蓝绿部署和金丝雀部署
在部署原则中提到的两大部署方式分别为蓝绿部署和金丝雀部署。
蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署是指当有新版本发布的时候，先让少量的用户使用新版本，并且观察新版本是否存在问题，如果出现问题，就及时处理并重新发布，如果一切正常，就稳步地将新版本适配给所有的用户。
5.5.5 部署和交付的新趋势
无
5.6 软件质量管理
软件质量就是软件与明确地和隐含地定义的需求相一致的程度，更具体地说，软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准以及所有专业开发的软件都应具有的隐含特征的程度。从管理角度出发，可以将影响软件质量的因素划分为3组。这3组分别是产品运行、产品修改和产品转移，三者的关系如图所示。
软件质量保证（Software Quality Assurance，SQA）是建立一套有计划、有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。软件质量保证的目的是使软件过程对于管理人员来说是可见的，它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。软件质量保证组在项目开始时就一起参与建立计划、标准和过程。这些使软件项目满足机构方针的要求。
软件质量保证的关注点集中在一开始就避免缺陷的产生。质量保证的主要目标是：
事前预防工作，例如，着重于缺陷预防而不是缺陷检查；
尽量在刚刚引入缺陷时即将其捕获，而不是让缺陷扩散到下一个阶段；
作用于过程而不是最终产品，因此它有可能会带来广泛的影响与巨大的收益；
贯穿于所有的活动之中，而不是只集中于一点。
软件质量保证的目标是以独立审查的方式，从第三方的角度监控软件开发任务的执行，就软件项目是否正确遵循已制订的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程取得高质量的软件产品。
软件质量保证的主要作用是给管理者提供预定义的软件过程的保证，因此SQA组织要保证如下内容的实现：选定的开发方法被采用、选定的标准和规程得到采用和遵循、进行独立的审查、偏离标准和规程的问题得到及时的反映和处理、项目定义的每个软件任务得到实际的执行。
软件质量保证的主要任务包括：SQA审计与评审、SQA报告、处理不合格问题。
①SQA审计与评审。SQA审计包括对软件工作产品、软件工具和设备的审计，评价这几项内容是否符合组织规定的标准。SQA评审的主要任务是保证软件工作组的活动与预定的软件过程一致，确保软件过程在软件产品的生产中得到遵循。
②SQA报告。SQA人员应记录工作的结果，并写入报告之中，发布给相关的人员。SQA报告的发布应遵循3条原则：SQA和高级管理者之间应有直接沟通的渠道；SQA报告必须发布给软件工程组，但不必发布给项目管理人员；在可能的情况下向关心软件质量的人发布SQA报告。
③处理不合格问题。这是SQA的一个重要的任务，SQA人员要对工作过程中发现的问题进行处理，及时向有关人员及高级管理者反映。
5.7 软件过程能力成熟度
5.7.1 成熟度模型
CSMM定义的软件过程能力成熟度模型旨在通过提升组织的软件开发能力帮助顾客提升软件的业务价值。CSMM模型由4个能力域、20个能力子域、161个能力要求组成。其层次结构如图所示。
①治理：包括战略与治理、目标管理能力子域，确定组织的战略、产品的方向、组织的业务目标，并确保目标的实现。
②开发与交付：包括需求、设计、开发、测试、部署、服务、开源应用能力子域，这些能力子域确保通过软件工程过程交付满足需求的软件，为顾客与利益相关方增加价值。
③管理与支持：包括项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理能力子域，这些能力子域覆盖了软件开发项目的全过程，以确保软件项目能够按照既定的成本、进度和质量交付，能够满足顾客与利益相关方的要求。
④组织管理：包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域，对软件组织能力进行综合管理。
5.7.2 成熟度等级
CSMM定义了5个等级，高等级是在低等级充分实施的基础之上进行的。
能力域的成熟度等级要求见下图。
5.8 本章练习
◆ 练习题
◆ 练习题
◆ 练习题
◆ 练习题
◆ 练习题
至此，本文分享的内容就结束啦！🌺🌺🌺🌺🌺🌺🌺🌺🌺
原文地址：https://blog.csdn.net/wss794/article/details/140469512
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！