软件开发周期相关名词解释

1、敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特诊。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用的状态。

拓展：敏捷开发（Agile Development）是一种以人为核心、迭代、循序渐进的开发方式。它不是一门技术，而是一种开发方式，也就是一种软件开发的流程。它会指导我们用规定的环节去一步一步完成项目的开发。因为它采用的是迭代式开发，所以这种开发方式的主要驱动核心是人。

为什么说人才是主要的驱动核心呢？之前的公司软件开发就是用的瀑布开发模型，它是以文档为驱动，开发人员都是根据产品经理或项目经理提供的需求文档或者原型图进行开发的，测试人员也是根据需求文档和原型图进行测试用例的编写，开发部和测试部计划乃至实施的核心是文档，所以说文档是这个模型中的一个核心。而敏捷开发的意义在于它只关注文档中的重要点，或者尽可能的去简化文档，敏捷开发其实更注重的是人与人之间的沟通、交流。所以它强调以人为核心。

 

扩展：

1）、敏捷开发的需求，是由产品经理提出和负责的。产品经理在敏捷项目开始之前应该和客户进行了足够交流，并在敏捷开发的计划会上和开发人员一起确认；

2）、适当的流程与文档的精简，以及沟通效率和工具使用便捷的提升是对的，也是正常的，其他的都是扯淡，不仅会降低效率，而且还对实际项目没有任何帮助；

3）、敏捷开发模式不仅仅针对于开发和管理人员，同时也是面向用户或客户的.，以Scrum为例，业务部门需要专门、全职的人员和开发人员一起工作，不断做需求更新和排位，不断收集业务部门的反馈来调整开发目标。业余人员的参与程度的高低直接影响甚至决定了Scrum开发方式的成败；

4）、对于一名测试人员来讲，正确、全面地理解用户需求是极其重要的。只有真正理解了用户需求，才能站在用户的角度来看问题，想问题，并把这些思想应运到软件测试当中去，及时发现并纠正软件开发过程中的缺陷。如果对用户需求一知半解，不能站在一个相当的角度看问题的话，测试人员就会为了测试而测试，迷失在繁多的测试案例之中。更糟糕的是，如果测试人员（其实对团队的每个成员都一样）对需求理解不当，并且没有及时得到纠正，那么整个团队将为此付出相当的代价。在每个开发周期的开发阶段，一个团队的所有成员都应坐在一起讨论这个开发周期的开发需求并拟定相应的开发与测试计划。

https://zhuanlan.zhihu.com/p/32782983

5）、敏捷开发，只得其形，而不得其神。

 

 图一

 

图2

 

 图3

 

2、瀑布模型（软件的生命周期）

就它的核心就是将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为

• 制定计划
• 需求分析
• 软件设计
• 程序编写
• 软件测试
• 软件运行维护

等六个基本活动，并且制定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

备注：每次迭代产生一个可运行的版本，同时增加更多的功能，每次迭代必须经过质量和集成测试。

拓展：项目经理的重要性

我觉得项目经理本质上和餐厅的服务员没有区别，都是一个服务行业从业者，食客（甲方爸爸）点了一桌子菜（提出需求），有项目经理记下来（收集需求），并且询问忌口，还要不要酒水（确认需求），之后协调后厨的王师傅做菜（开发），并且在保证菜品的情况下（质量），按时（进度）的端到食客的桌子上。在客人品尝之后，认可买单（验收）。

3、V模型（软件的生命周期）

即开发和测试可以同时进行。

 

4、SDK （software development kit）软件开发工具

SDK是一系列程序接口、文档、开发工具的集合，跟jdk一样包含了java运行时环境（JVM+Java系统类库）和一些JAVA工具。一个完整的SDk应该包含了以下内容：

• 接口文件和库文件：即API，将底层的代码进行封装保护，提供给用户一个调用底层代码的接口；
• 帮助文档：解释接口文件和库文件功能，以及介绍相关的开发工具，操作示例等等；
• 开发实例：做出来的一个DEMO展示，也要包含源代码；
• 实用工具：用于协助进行二次开发的工具，比如二次开发向导、API搜索工具、软件打包工具等；

5、.bat文件

所有的bat文件，都称为批处理脚本（batch），它的扩展名为Batch。顾名思义，批处理就是对某对象进行批量的处理，通常被认为是一种简化的脚本语言，它应用于Dos和Windows系统中。

6、synapseRT

synaoseRT作为一个JIRA插件，可以大大增强JIRA对于软件需求管理和软件测试管理的功能。它能够帮助开发团队在软件项目中高效、方便地协作；能够帮助测试团队方便地组织测试用例和计划，执行测试。同时，将需求、测试用例和测试结果完美地结合在一起，使整个项目团队在各阶段计划、构建和发布更好的软件产品。它主要包含以下4个模块：

• 测试用例管理：树形结构、测试用例集、测试用例
• 测试执行管理：测试计划、测试周期、测试报告
• 测试自动化：Rest API、Bamboo/Jenkins集成
• 需求管理：需求跟踪矩阵、需求版本、需求基线

备注：

• 需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。测试人员可以将自己的问题类型映射为“需求”
• 缺陷：软件的功能或性能等等缺陷
• 测试用例：为了某个功能测试而预先编制的一组测试输入、执行条件以及预期结果，以便系统地进行软件测试
• 测试用例集：用例集合
• 测试计划：描述了测试范围和测试活动
• 测试周期：是对测试计划执行的一个迭代。每个测试周期都包含一组从测试计划中继承而来的测试用例（用户可以调整测试用例。用户可以在一个测试计划中创建多个测试周期以覆盖不同的环境或者开发版本。在一个测试计划中需创建至少一个测试周期）
• 测试执行：对预编写的用例进行有效地多次地执行
• 测试者：执行测试用例的测试人员

用处：

• 记录和跟踪需求
• 创建、组织、计划、执行测试用例
• 开发人员查看跟踪测试用例和测试人员发现的bug
• 项目管理人员管理、组织软件测试，并生成需求和测试报告

使用流程：

• 在JIRA中创建需求
• 直接从需求中创建测试用例以保证需求被测试所覆盖，或者可以链接已有的测试用例到需求；
• 通过测试用例集来组织测试用例，为测试用例创建树形结构；
• 创建测试计划并且从测试用例集中挑选需要执行的测试用例；
• 为测试计划创建测试周期；
• 启动（开始）测试周期，为测试用例指派测试者（项目成员）；
• 测试者开始测试执行，发现缺陷时直接从测试执行中创建或者链接缺陷；
• 通过不同的测试报告查看测试结果。

 3、项目需求的重要性

系项目需求是软件开发、软件测试的一个依据，一个模板，也是实现成果完成交付的一个手段。

需求是来自于实际的业务使用场景及用户脑袋里存在的一些想法，这些想法有些能促进项目目标的，有些是对整个项目进度还有项目业务提升显现不明显的，这就需要你根据这些需求结合他们现在业务的实际流转情况，给他们清晰的一个解释，这些需求如何处理，需求的前置是业务，你要明白他们业务如何通过系统实现的，所以这就是项目经理去画原型图的原因了（原型图无论对于开发还是测试，都是对这个项目最终完成版本最直观的感受，最直观的认识）

拓展：需求和产品（项目）的先后顺序

到底是先有需求，还是先有项目/产品？按照大多数的逻辑，先有需求，才会有产品（大多数it公司都是根据需求文档进行开发的）。但实际上一个公司需要做一款产品的时候，往往是先有项目/产品，然后才去明确需求，收集需求，并整理成档，给developer开发的方向，给tester测试的依据。

拓展：项目需求不明确的情况下

当项目需求不清晰的情况下，先把清晰的模块做出来，一点点迭代，一点点推进。再不明确地需求，用户这块总能先做出来吧