zhmh
/
software-strategy-book
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

no message

This commit is contained in:
Xin Peng 2019-12-08 11:40:39 +08:00
parent 5a6b51ffa7
commit cef724f542
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
Ch1-4-SoftwareEngineering.tex
View File

@ -150,7 +150,7 @@
总之，敏捷软件开发通过自组织和跨职能团队及其客户/最终用户的协作努力，使需求和解决方案不断演化发展的方法，它倡导适应式规划、演化式发展、尽早交付和持续改进，同时鼓励快速应变和灵活反应。实际上，迭代增量开发可追溯到1957年~\cite{larman2003iterative}，而演化式项目管理~\cite{gilb1981evolutionary}和自适应软件开发~\cite{edmonds1974process}也早在70年代就已经出现。他们都早于敏捷宣言，并都被包含进敏捷软件开发方法。
\subsection{软件质量保障}
软件是一种人工制品，需要有相应的软件质量保障（Software Quality Assurance, SQA）机制，包括监控软件工程过程以确保质量。软件质量保障涵盖整个软件开发过程，包括需求定义、软件设计、编码、源代码控制、代码审查、软件配置管理、测试、发布管理和产品集成等。
软件是一种人工制品，需要有相应的质量保障（Software Quality Assurance, SQA）机制，包括监控软件工程过程以确保质量。软件质量保障涵盖整个软件开发过程，包括需求定义、软件设计、编码、源代码控制、代码审查、软件配置管理、测试、发布管理和产品集成等。
\subsubsection{软件质量体系}
软件质量是反映软件系统或产品满足明确或隐含需求能力的特性的总和。有四个方面的含义： 其一，能满足给定需要的特性的全体；其二，具有所期望的各种属性的组合的程度；其三，用户觉得能满足其综合期望的程度；其四，软件的组合特性，它确定软件在使用中将满足顾客预期要求的程度。软件质量常常用下列特性来评价：
@ -168,12 +168,12 @@
\item 易移植性：软件产品从一种环境迁移到另外一种环境的能力。
\end{itemize}
Boehm等人于1976年提出了定量评价软件质量的概念，提出了60个质量度量公式，首次提出了软件质量度量的层次模型。1978年Walters和McCall提出了从软件质量要素、准则到度量的三层次式的软件质量度量模型，将质量要素降到11个。国际标准化组织于1985年建议的质量度量模型是：高层——软件质量需求评价准则；中层——软件质量设计评价准则；低层——软件质量度量评价准则的三层次模型。高层
软件质量度量是用于确定软件系统或产品头屑特性的定量尺度，Boehm等人于1976年提出了定量评价软件质量的概念，提出了60个质量度量公式，首次提出了软件质量度量的层次模型。1978年Walters和McCall提出了从软件质量要素、准则到度量的三层式软件质量度量模型，将质量要素降到11个。
\subsubsection{软件质量标准}
国际标准化组织(ISO)和国际电工委员会(IEC)于1991年提出了标准，给出了6个特性和21个子特性；又于2001年再次修订了标准，建立了软件产品质量的两部分模型：（1）内部质量（软件产品在特定条件下使用时，软件产品的一组静态属性满足明确和隐含需要的能力）和外部质量（系统在特定条件下使用时，软件产品使得系统的行为能满足明确和隐含需要的能力），（2）使用质量（在特定的使用周境中，软件产品使得特定用户在达到有效性、生产率、安全性和满意度等方面的特定目标的能力）。
国际标准化组织于1985年建议的质量度量模型分为三层：高层——软件质量需求评价准则；中层——软件质量设计评价准则；低层——软件质量度量评价准则。在1991年，国际标准化组织(ISO)和国际电工委员会(IEC)又共同提出了标准，给出了6个特性和21个子特性，于2001年再次修订标准，建立了软件产品质量的两分模型：（1）内部质量（软件产品在特定条件下使用时，软件产品的一组静态属性满足明确和隐含需要的能力）和外部质量（系统在特定条件下使用时，软件产品使得系统的行为能满足明确和隐含需要的能力）；（2）使用质量（在特定的使用场景中，软件产品使得特定用户在达到有效性、生产率、安全性和满意度等方面的特定目标的能力）。
已经存在一系列标准用于监控和评估软件生产过程过程，以支持软件质量的提升，如，ISO/IEC 15504\footnote{https://www.iso.org/standard/38932.html}，其第一个版本专注于软件开发过程，后来扩展到涵盖软件业务中的所有相关流程，例如项目管理，配置管理，质量保障等，是成熟度模型的参考模型，评估者可以根据模型在评估期间收集证据，全面确定所开发产品（软件，系统和IT服务）的能力。其更新版本是ISO/IEC 33000\footnote{https://www.iso.org/standard/54175.html}。其它质量标准还包括ISO/IEC 25000\footnote{https://www.iso.org/standard/64764.html}、ISO/IEC/IEEE 29119\footnote{https://www.iso.org/standard/45142.html}等。
还有一系列标准用于监控和评估软件生产过程过程，以支持软件质量的提升，如，ISO/IEC 15504\footnote{https://www.iso.org/standard/38932.html}，其第一个版本专注于软件开发过程，后来扩展到涵盖软件业务中的所有相关流程，例如项目管理，配置管理，质量保障等，是成熟度模型的参考模型，评估者可以根据模型在评估期间收集证据，全面确定所开发产品（软件，系统和IT服务）的能力。其更新版本是ISO/IEC 33000\footnote{https://www.iso.org/standard/54175.html}。其它质量标准还包括ISO/IEC 25000\footnote{https://www.iso.org/standard/64764.html}、ISO/IEC/IEEE 29119\footnote{https://www.iso.org/standard/45142.html}等。
\subsubsection{形式化规约和验证}
除了采用工程方法来组织、管理软件的开发过程，并根据标准检验过程的正确性外。还有一类工作就是深入探讨程序和程序开发过程的规律，建立严密的理论，以其用来指导软件开发实践，这类工作推动了形式化方法的深入研究，其目标是以严格的数学推演为基础，通过对系统的形式规约、验证和逐步精化来构造并实现软件，从而提高软件设计的可靠性和鲁棒性。通过对系统的形式规约、验证和逐步精化来构造并实现软件。其中，形式规约是使用形式语言构建所开发的软件系统的规约，对应软件生命周期不同阶段的制品，刻画系统不同抽象层次的模型和性质。形式化开发就是构造并证明形式规约之间的等价转换和精化关系，以系统的形式模型为指导，通过逐步精化，最后开发出满足需要的系统，也称为构造的正确性(Correct by Construction)。
@ -184,7 +184,13 @@
软件测试通过人工或自动的方式运行被测试的软件，检验其运行结果或行为是否与预期相符，其目的是发现软件中潜在的错误和问题。测试应当经过设计，并在测试用例的驱动下进行。测试用例一般包括输入、环境配置、测试步骤和期望输出。软件测试可以在不同层次上进行，包括单元测试\index{单元测试}、集成测试\index{集成测试}、系统测试\index{系统测试}和验收测试\index{验收测试}。此外，在软件进行修改后为确认修改未引入新的错误还需要重新运行相关的测试用例，即进行回归测试\index{回归测试}。软件测试的基本过程包括测试计划、测试用例设计、测试执行、测试结果分析等步骤。其中，测试用例设计是关键，一方面要确保对软件运行过程中的各种可能性有较高的覆盖度，另一方面要限制测试用例数量以节省测试时间和成本。相应的测试用例设计方法主要包括白盒测试\index{白盒测试}和黑盒测试\index{黑盒测试}两类，同时与各种测试用例选取和排序等辅助技术相结合。为了缩短测试时间、节省测试成本，自动化测试技术受到了很大关注，包括自动化的测试用例生成、执行和结果分析。
\subsection{软件工程工具}
软件工程工具是辅助软件开发人员、运维人员、管理人员等不同参与者参与软件开发活动的各类软件产品的总称。软件工程工具从早期的编程工具、软件过程管理工具以及软件度量工具，逐步发展为服务于软件全生命周期的整套工具链，并且在不同的软件工程环节存在多种可供选择的工具产品。丰富的软件工程工具为软件开发人员提供了更加高效便捷的开发方法和能力。面向软件工程过程不同环节的软件工程工具，促进了软件工程的领域细分。不同的软件工程工具对工具使用者的不同技能要求，使软件工程技能培训和学习更加细化和专业化。根据软件工程工具所服务的人员角色不同，可将软件工程工具分为软件开发工具、软件运维工具、软件开发管理工具等。
软件工程工具，或软件工具，是用来辅助计算机软件的开发、运行、维护、管理、支持等过程中活动或任务的一类软件。早期的软件开发所用到的引导程序、装入程序、编辑程序等都可以看作是最早的软件工具。在汇编语言和高级程序设计语言出现以后，汇编程序、解释程序、编译程序、连接程序和排错程序构成了早期的软件工具集。在软件工程出现后，支持软件需求分析、设计、编码、测试、维护和管理等活动的软件工具逐渐发展起来，从各个阶段支持着软件开发过程，并且自然而然出现了工具集成的需要，使得各个工具能够协同操作。
软件开发环境由软件工具和环境集成机制构成，是支持软件产品开发的软件系统~\cite{张效祥2005计算机科学技术百科全书}。软件开发环境在工具集成的需求中开始萌芽，上世纪70年代中后期出现了软件工具箱（Toolkit）的思想，在软件开发过程中使用成套的多个软件工具。80年代起，出现了支持图形设计方式的第二代软件工具和集成这些工具为一体的软件开发环境，采用环境信息库，支持软件开发模型和开发方法，并且集成机制有了较大发展。90年代开始出现支持面向对象方法和技术的软件开发环境。我国“七五”“八五”科技攻关中研制的\index{青鸟软件开发环境}，是当时先进的软件开发环境，具有较为完善的集成化软件开发支撑能力。
21世纪以来，随着互联网和移动通信的普及，软件工具和软件开发环境的用途和种类进一步拓展，出现了支持软件国际化、软件开发协同工作、开源软件库和开源社区环境以及支持互联网、物联网和云计算的基础软件和应用测试支撑工具。软件开发环境不仅支持时间上的松耦合开发，还支持空间上的分布开发，并且开始以协同开发思想为基础，更强调多相关方、多工具、多活动的协同开发支撑，使得软件产品相关的所有利益相关方能在互动的软件开发协作过程中，实现包括需求管理、项目管理、软件部署和运行监控等活动在内的完整的软件生存周期过程支撑。
随着软件形态的演化和软件开发方法的发展，软件工具和软件开发环境正在功能智能化、网络化、服务化方向发展，并且对软件开发过程的可视化管理和定量分析优化提供支持。
\subsubsection{软件开发工具}
早期的软件开发工具仅限于汇编器和编译器。20世纪五六十年代，随着Fortran、Basic等高级语言的出现，计算机程序逐步脱离了面向特定硬件系统的束缚，更加接近于自然语言而易于开发人员书写。开发人员使用文本编辑工具编写代码后，使用代码解释或编译工具将源代码转换为操作系统可以识别的代码，进而实现预期的程序行为。广义上来说，文本编辑器、汇编器、编译器都可以看作最原始的软件开发工具。
@ -201,12 +207,6 @@
\end{itemize}
单一的软件开发工具很多时候由于缺少必要的上下文信息或与其他工具的联系而很难使用。因此，基于多种软件开发工具形成的集成开发环境（IDE）\index{集成开发环境（IDE）}逐渐发展起来。20世纪80年代，通用编程语言Ada带有自己的编程支持环境APSE，提供了编辑界面、编译器、测试器、连接加载器等功能模块，将集成开发环境提升到一个新的阶段。此后，微软（Microsoft）、宝蓝（Borland）等软件公司相继开发出各自的开发环境用于支持相应编程语言的开发与调试。
IDE的出现为软件开发人员在开发过程中集中完成软件开发任务提供了统一的环境，也为后续进一步扩展新的软件工程工具奠定了基础。例如，1987年宝蓝公司推出的Turbo C开发环境，在字符界面上提供了灵活的代码编写和调试环境，使得开发人员能够一站式完成程序编写、测试和调试。1991年为了适应微软公司的视窗（Windows）操作系统界面风格，宝蓝公司又推出Borland C++，并在90年代后期推出Borland C++ Builder提升了集成开发环境的易用性和代码编译链接的效率。在这个工具的升级过程中，不仅需要适应C/C++语言标准的变化、操作系统的变化，还考虑了开发人员的易用性需求，通过可视化的窗体设计器、对象观察器等可视化元素加入到开发环境中，推出了VCL构件库，引领了快速应用程序开发（RAD）开发方法，大大降低了开发Windows应用程序的难度。
开放式架构的开源集成开发环境以插件的形式提供各类辅助支持，包括在开发环境中提供各类代码静态扫描功能、代码重构功能、代码自动补全和框架自动生成功能等，大大扩展了集成开发环境的能力范围，使之能服务于不同的开发过程活动。例如最初由IBM公司主导开发的Eclipse在2001年开源转入非盈利组织Eclipse基金会管理后，开源社区的大量开发者为其开发了众多实用的功能，进而衍生出了MyEclipse、IBM Rational Software Architect等多种工具软件，服务于不同层次和复杂程度的开发需求。
\subsubsection{软件运维工具}
软件的运行和维护是软件交付后的必要环节。在以桌面应用为主的上世纪90年代以前，软件产品要么以商业成品（Commercial-off-the-shelf）形式提供给最终用户，要么以商用服务项目的形式在客户现场（On-site）提供支持。此时，软件的运维主要是软件日志的收集与分析。通常只能通过现场日志的分析获知软件的可能问题，进而在开发环境中进一步测试、验证、修改软件以修复相关问题。在这种模式下，软件运维工具往往并不受重视，并且通常是融合在软件开发工具中的，即需要通过软件开发过程中写入必要的日志信息，才能实现必要的运行维护工作。随着互联网应用和应用的服务化进程的开启，21世纪以来，服务化和云化的软件使得软件运维从客户端现场支持逐步转向后端、云端。此时的软件运行具有在线动态地特性，不仅需要运行时的日志记录与分析，还需要能快速响应特定的运行问题，并快速给出维护方案、上线修复的软件产品。软件运维从简单的运行日志分析和调错，逐步向实时监控、快速响应的反向发展，这也带来了开发运维一体化（DevOps）\index{开发运维一体化（DevOps）}的兴起。由此，软件运维工具范围迅速扩大，形成了涵盖开发、构建、测试、集成及交付、容器平台等个子领域的工具集。例如自动化构建是持续集成的重要支撑，支持持续集成的工具包括开源工具Jenkins、商用工具Bamboo以及商用开源版本并存的Travis等。这些工具的特性分别适应特定的应用群体或用户，运维人员可实现多种运维工具的按需选择。
@ -272,5 +272,6 @@
\section{结束语}
随着信息技术的飞速发展，软件系统无处不在，其应用形态呈现出泛在化、社会化、情境化、智能化等特征，软件正逐步成为人类社会不可或缺的基础设施。软件工程方法和技术的进步支撑了整个的软件应用的展开，体现在软件系统的规模越来越大，所解决的问题越来越复杂、交互对象越来越多样，人们寄予越来越高的可靠性要求。现在，人机物融合应用模式的不断深入，“泛在系统”和“软件定义”也成为呼之欲出的着力点。这既孕育了软件工程学科的新的增长点，也给软件工程方法和技术带来了新的挑战，需要有新的软件工程方法和技术支撑。
综观软件工程的起源和发展，可以发现，软件成为独立存在的人工制品，因此需要一种系统化的方法以及相应的技术，第一使得这种人工制品的功能能满足应用需求，第二使得其开发和生产能高效地完成，第三能提供手段以保证其质量。因此软件工程的发展总是围绕需求、软件方法学和软件开发技术、以及软件质量体系和保障等几个方面展开，这形成了软件工程学科的内涵。
但是，软件又和其它人工制品不同，它在需求和表现形式上具有极大变化性，它承载在看上去非常容易修改的代码上，随着软件和物理设备以及人的越来越深度的融合，通过软件作为核心支撑来解决的问题也越来越复杂。这也使得软件工程方法和技术不断面临新的挑战，面对的问题（需求）越来越复杂、软件操作的交互对象越来越多样，人们寄予越来越高的可靠性等等，这些是软件工程方法和技术发展的原动力。