软件过程

作者:苏康胜 前言 本人从事软件行业以来，经历了多次的成功与失败的体验，总觉得中国的软件应该可以做得更好些，但结果并不是我想象中的那样，许多的项目实际都还只是以假的、虚的面孔而存在，其中原由大家都可以说得出很多很多，但怎么改呢？一些问题的存在只是因为其他问题存在而存在的，所以我想寻找中国软件行业为什么不能崛起的根源。 中国人智商不够？那绝对是错的。 中国人不够勤奋？那也绝对是错的。 科技不如其它国家发达？通讯如此发达的现代，那不是理由。 中国人做软件的少？那更加不是理由。 ...... 为什么呢？中国缺少高效的软件开发团队吗？这也许是问题的根源。 正文： 喜欢足球的朋友应该非常清楚一件事情，那就是在一场足球赛中假如球员之间缺少默契的配合或教练的指导思想执行不到位等情况下，那场比赛多半是以失败告终的，因为这支球队并不是优秀的球队。开发软件项目就象一场进行中的足球赛，是靠项目管理、系统分析设计、程序编制、测试、市场营销等不同角色人员共同协作完成的，不同角色的人执行的工作相互促进和制约着其它角色的人的工作，因此一个高效的软件开发团队是高质量软件项目或产品的保证，可如何才能营造高效软件开发团队呢？从以下几个方面来说明： 一、 高效软件开发团队的特征 高效的软件开发团队是建立在合理的开发流程及团队成员密切的合作的基础之上的，成员共同的迎接挑战、有效的计划

Build tool（构建工具） what: 构建工具能够帮助你创建一个可重复的、可靠的、携带的且不需要手动干预的构建。构建工具是一个可编程的工具，它能够让你以可执行和有序的任务来表达自动化需求。假设你想要编译源代码，将生成的class文件拷贝到某个目录，然后将该目录组装成可交付的软件。 理解构建工具中组建的交互、构建逻辑和实际定义，以及输入输出的数据是非常重要的。 构建文件 构建文件包含了构建所需的配置信息、定义外部依赖，例如第三方类库，还包含了以任务形式实现某个特殊目的的指令和它们的相互依赖关系。在通常情况下，会使用脚本语言来表达构建逻辑。这就是为什么一个构建文件也叫做构建脚本的原因。 构建的输入和输出 一个任务会接受一个输入，然后执行一系列步骤，最后产生一个输出。某些任务也需不需要输入，也不需要产生一个必要的输出。在复杂的任务依赖关系中，也许会使用一个依赖任务的输出作为输入。例如，我们将源代码文件作为输入，将它们编译为class文件，并组装成可交付软件作为输出。编译和组装过程各表示一个任务。只有先编译了源代码，组装可交付软件才有意义。因此两任务需要保证它们的顺序。 构建引擎 构建文件的一步步指令或者规则集必须被翻译成构建工具可以理解的内部模型。构建引擎会在运行时处理构建文件，解析任务之间的依赖，设置好执行做需要的全部配置。一旦内部模型建立好了

Build Tool（构建工具） what： 构建工具能够帮助你创建一个可重复的、可靠的、携带的且不需要手动干预的构建。构建工具是一个可编程的工具，它能够让你以可执行和有序的任务来表达自动化需求。假设你想要编译源代码，将生成的class文件拷贝到某个目录，然后将该目录组装成可交付的软件。如下图所示，展示了所描述场景中任务和它们执行的顺序。 每个任务都代表着一个工作单元——例如，编译源代码。顺序是非常重要的。如果所需要的class文件没有被编译出来，那么你是不能够组建构件的。因此编译任务必须先被执行。 本质上，任务和它们的相互依赖被模块化成一个有向非循环图（DAG）。DAG是计算机科学的一种数据结构，包含下面两个元素： 节点：一个工作单元；就构建工具而言，它指的是一个任务（例如，编译源代码）。 有向边：有向边也叫作箭头，表示点节之间的关系。在这里，箭头表示依赖关系。如果一个任务的定义依赖于另一个任务，那么所依赖的任务就必须先被执行。发生这种情况常常是因为一个任务依赖于另一个任务的输出。这里有个例子——要执行任务“组装可交付软件”，你需要先执行任务“拷贝class文件到目录”和“编译源代码”。 每个节点都知道自己的执行状态。一个节点——表示一个任务——只能被执行一次。 作为开发人员，你没有必要和DAG图打交道。这个工作是由构建工具来完成的。 构建工具的剖析 理解构建工具中组建的交互

前言 本篇文章将对敏捷软件开发的方法论及其应用做基本介绍，将描述团队是如何通过协作来完成共同目标的。本篇文章不仅仅适合软件开发人员阅读，同时也适合于团队负责人、项目经理、产品经理、开发经理、测试人员、QA经理、QA工程师、技术文档专员、用户体验设计师等任何涉及软件交付的人员。文章重点介绍技术团队是如何通力协作来计划、构建和交付软件的。但文中没有具体代码的编写，也没有对特定技术的介绍，并且也不会介绍任何微软技术。希望这篇文章可以帮助你改善专业性和团队的效率。 背景 Winston Royce 瀑布模型 引自 1970 年的 IEEE 论文 "Managing the Development of Large Software Systems" 该论文中阐述了，在计算机程序设计开发过程中，无论软件的规模和复杂度如何，都会经过两个必不可少的阶段：软件分析和编码。而许多其他额外的开发步骤，虽然也是需要的，但却都没有像软件分析与编码一样对最终产品作出最直接的贡献，反而增加的开发过程的支出。 然后，Royce 介绍了需要额外的将 5 个重要的步骤添加到整个开发流程中，用于最大化地消除软件开发中的风险： 步骤1：程序设计优先 一个软件程序的初步设计阶段，将被插入到软件需求和软件分析阶段之间。程序设计人员将在此阶段开始进行软件整体的初步设计，包括设计、定义和指定数据处理模型，定义系统间的接口

1 ． 软件测试 的目的是尽可能多的找出软件的缺陷。（ Y） 2 ．Beta 测试是验收测试的一种。（ Y） Acceptance testing 验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。 3 ．验收测试是由最终用户来实施的。（ N ） 是由测试人员来实施的 4 ．项目立项前测试人员不需要提交任何工件。（ Y ） 工件：加工过程中生产对象 5 ．单元测试能发现约80% 的软件缺陷。（ Y ） 6 ．代码评审是检查源代码是否达到模块设计的要求。（ N ） 代码评审也称代码复查，是指通过阅读代码来检查源代码与编码标准的符合性以及代码质量的活动。 7 ．自底向上集成需要测试员编写驱动程序。（ Y ） 自顶向下综合测试的具体步骤为： 　　1 以主控模块作为测试驱动模块，把对主控模块进行单元测试时引入的所有桩模块用实际模块替代； 　　2 依据所选的集成策略（深度优先或广度优先），每次只替代一个桩模块； 　　3 每集成一个模块立即测试一遍； 　　4 只有每组测试完成后，才着手替换下一个桩模块； 　　5 为避免引入新错误，须不断地进行回归测试（即全部或部分地重复已做过的测试）。 自底向上综合测试的步骤分为： 　　1 把低层模块组织成实现某个子功能的模块群（cluster）; 　　2 开发一个测试驱动模块

DevOps面试问题 01 您能告诉我们DevOps和Agile(敏捷)之间的根本区别吗？ 答：尽管DevOps与敏捷方法（这是最流行的SDLC[Software Development Life Cycle]方法之一）有一些相似之处，但两者在软件开发方面都是根本不同的方法。以下是两者之间的各种基本差异： 敏捷方法 敏捷方法适用于敏捷中的开发同时敏捷方法适用于DevOps中的开发和操作。 实践和流程 敏捷涉及敏捷Scrum和敏捷看板等实践，而DevOps涉及CD（持续交付），CI（持续集成）和CT（持续测试）等流程。 优先级 敏捷优先考虑及时性，而DevOps优先考虑及时性和质量。 发布周期 DevOps提供较小的发布周期并提供即时反馈，而敏捷仅提供较小的发布周期而没有立即反馈。 反馈源 敏捷依赖于客户的反馈，而DevOps涉及到自身（监控工具）的反馈。 工作范围 对于敏捷，工作范围仅是敏捷，而对于DevOps，这是敏捷和对自动化的需求。 02 为什么我们需要DevOps？ 答：如今，很多组织或企业正试图通过一系列的发布小的特性传递给客户，而不是发布大的特性集。这样做有几个好处，包括更好的软件质量和快速的客户反馈，所有这些好处导致更高的客户满意度，这是任何产品开发项目的最重要目标。为此，公司需要： 增加部署频率 缩短修复时间 降低新版本的失败率 万一新版本崩溃

1、客户不满意，不能一直让客户牵着鼻子走，我们需要去深入理解客户的需求，将自己的理解给客户，达到客户的认同。 2、不能客户说怎么做就怎么做，客户没有这方面的知识，需要提前分析客户的功能，用计算机能用的方法就觉。 3、需求调研之前需要进行角色分析，需要对每个角色都进行调研。 划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。 4、在开发过程中需要时刻将程序的进行与客户交流，在开发过程中发现问题，及时解决，避免到最后的赶时间，出现更多的问题。 【拜访】 5、与客户相处好关系， 经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。 【研讨会】 6、 业务商讨，可以划分为几个部分或找到相关的部分将他们集中到一起，集中进行调研，每个部门都划分开，以保证不会杂乱无章。 【需求研讨】 7、 自己做的软件与客户期待的软件不是一种东西，客户前期调研是提不出需求，最后做出软件客户使用时，感觉不是这个软件。这就需要在调研过程中不要先于客户讨论软件的功能，先了解客户的知识领域，将自己带入到特定的软甲使用环境中， 客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么

笔记要求：发表一篇阅读笔记，说明本学期《软件需求分析》需要掌握哪些必要的内容？针对每个内容点说出自己的理解，并绘图示意相互之间的关联关系。 　　　　　　　　　 　读《需求工程——软件建模与分析》有感 　　 今天大致的看了一下这本书，对软件需求分析有了初步的了解，我认为学习软件需求分析需要掌握的内容主要包括五个方面：需求基础与过程、需求获取、需求分析、需求的文档化和验证、需求管理与工程管理。 　　 一、需求的基础与过程 　　这一部分主要是对软件需求有一个大致的了解，例如需求的概念，不同群体的人们对需求有不同的理解，IEEE对需求的定义：用户为了解决问题或达到某些目标所需要的条件和能力；系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的需求而需要具备的条件或能力。 　　软件系统通过影响问题域，能够帮助人们解决问题，成为解系统。解系统是问题的解决手段，但是并不是问题的产生地。所以，解系统并不是问题域的一个部分，它们之间存在可以相互影响的接口，以实现交互活动。 　　功能需求被分为：业务需求、用户需求、系统需求。三者之间有所区别，将用户需求转化为系统需求是一个复杂的过程。 　　需求工程的过程就是：需求获取、需求分析、需求规格说明、需求验证、需求管理的过程。 　　 二、需求获取 　　 顾名思义，需求获取就是进行需求收集的一个活动，他从人员、资料和环境中得到的系统开发所需要的相关信息。

什么是软件？ 软件是计算机系统中与硬件相互依存的另一部分， 软件包括程序+文档 什么是软件测试？ （1）软件测试是在现有软件（程序+文档）中寻找缺陷的过程； （2）软件测试是指使用人工或者自动化手段来运行或测试某个系统的过程，目的是检验系统是否满足需求规格说明书中的要求 软件测试的目的？ 测试的目的是找出软件产品中的错误，使软件尽可能的符合用户的要求。 黑盒测试： 又叫功能测试，把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程，根据规格说明书，通过操作软件验证程序的功能是否与规格说明书规定的一致。 白盒测试： 也称结构性测试，是基于代码的测试，按照程序内部的逻辑结构，检测程序是否能按预定要求进行正确的工作。 回归测试： 回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。 冒烟测试： 是指在对一个新版本进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性，冒烟测试又称版本验证测试。冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件的基本功能正常，可以进行后续的正式测试工作。 简单地说，冒烟测试就是用较少的人，在较短的时间内测试程序的主要功能，如果通过再进行正式的测试。 aplha测试和bate测试的区别？ Alpha测试(α测试)： 通常也叫“验证测试”，主要是指在软件开发完成以后

1.什么是软件测试? 答:软件测试是 为了发现错误而执行程序的过程 。或者说，软件测试是 根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例 (即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。（1.验证程序正常运行 2.验证满足用户需求 3.发现缺陷） 2. 软件测试的目的? 答;测试的目的是想 以最少的人力、物力和时间找出软件中潜在的各种错误和缺陷 ，通过修正错误和缺陷提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。 3.什么是需求文档测试？ （主要测试需求中是否存在逻辑矛盾以及需求在设计上是否可以实现） 1、需求文档是否符合用户需求； 2、需求文档是否符合逻辑； 3、技术上是否能实现； 软件开发过程中，通常会有专门的测试人员，他们首先 会根据需求文档编写测试用例 ，用于指导如何测试，以及那些输入条件预期得到什么结果 4. 什么是设计文档测试? 答:测试设计是否符合全部需求以及设计是否合理 5.什么是 α测试 ? 答:Alpha测试(α测试)是 由一个用户在开发环境下进行的测试 ，也可以是 公司内部的用户在模拟实际操作环境下进行的受控测试 ， Alpha测试不能由程序员或测试员完成 。Alpha测试发现的错误，可以在测试现场立刻反馈给开发人员，由开发人员及时分析和处理。 目的是评价软件产品的功能