软件的接口设计图_产品基础 | 软件生命周期

一、什么是软件生命周期h2>

软件生命周期又称为软件生存周期或系统开发生命周期，是软件的产生直到 废的生命周期，周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段，这种按时间分程的思想方法是软件工程中的一种思想原则，即按部就班、逐步推进，每个阶段都要有定义、工作、审查、形成文档以供交流或备查，以提高软件的质量。但随着新的面向对象的设计方法和技

术的成熟，软件生命周期设计方法的指导意义正在逐步减少。

二、各阶段解读

1.可行性分析阶段

• 问题定义

概念：定义出本次任务都需要做什么，做成什么样子（比如，买家跟卖家说我要什么样子的衣服，然后双方开始协商，最终达成一致意见，这个过程就是需求定义）。

参与者：产品经理，需求分析师，客户

• 可行性分析

概念：由项目组相关成员去研究需求是否可行，能不能做出来（比如：商家拿订单需求去找设计和工厂，问设计图形或者样式能否做出来；问工厂在相应的布料上能不能做出设计图样式的衣服，这个过程就是可行性分析）

参与者：产品经理，架构师，项目经理，开发

2.需求分析阶段

• 需求分析

概念：需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个框每个按钮的样式，输入输出等各项值（比如：设计和工厂分别就这个衣服做材料分析，分析出这个衣服需要多少布料，扣子什么样式、颜色，不同布料具体用多少等等，这个过程叫做需求分析）；统一整理编写成《需求说明书/需求规格说明书》。

参与者：产品经理，架构师，项目经理，测试/质量管理员、开发

• 需求评审

概念：评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与

3.软件设计阶段

• 概要设计和详细设计

概念：架构师根据需求确定产品或者项目的场景、特点，选择合适的框架，技术使项目实现最优化。在此上将系统进行概要设计，包括系统总体数据结构、数据库结构、模块结构以及它们之间的关系等。开发人员根据概要设计对具体模块进行详细设计，包括接口参数、参数等。此处设计会形成概要设计文档和详细设计文档。

参与者：项目经理，架构师，开发，测试

• 软件编码

概念：开发人员根据详细设计文档对系统进行模块化开发，在确定参数和接口的情况下，根据需求对模块内部进行方法级别的设计和编码以及自测，对产品功能进行一一实现

参与者：开发

4.软件测试阶段

• 软件测试

概念：开发人员完成一个小迭代/小功能，且完成自测(开发编码完成后，一般都会自己检测下)，于是向测试部门发起提测，一般以邮件方式或者任务管理工具任务流方式向测试部门通知xxx模块/功能可以测试

参与者：任务责任人(开发)、测试

• 测试策略

概念：测试组长要根据《任务说明书》和《需求说明书》来决定此次测试的思路/类别（功能测试/性能测试/文档性测试或者几种组合）、测试方式方法、flag（任务指标，做到什么程度）等。也有很多公司把测试策略作为测试方案中的一部分。

参与者：测试组长/测试leader/自身的测试工程设计师

• 测试计划

概念：测试组长要根据《任务说明书》和《需求说明书》开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

参与者：测试组长/测试leader

• 测试方案

概念：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《需求说明书》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。

参与者：测试工程师

• 测试设计

概念：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，测试用例需要包括测试项，用例级别，预置条件，操作步骤和预期结果。同样，测试用例也需要评审。

参与者：相关测试工程师

• 测试执行

概念：根据测试用例对开发提测部分进行，通过的标记通过，不通过的提交有质量的Bug（问题缺陷）。这里要说下bug，测试对出问题的部分提交bug到相关开发工程师，开发根据问题描述，进行修订，修订完成后会将bug流转给相关测试人员（通过缺陷管理工具分配/邮件通知相关测试人员bug修订完成，可测)，测试需要对bug以及bug相关模块进行测试回归。

参与者：相关测试工程师、责任开发工程师

• 测试 告

概念：最终测试完成（所有测试用例通过/已挂起）会出测试 告对以上测试进行总结性描述。

参与者：相关测试工程师

5.软件运行和维护阶段

• 部署/发版

概念：经过前面的各个阶段，产品已经可以出售或者面见大众了；由测试进行冒烟测试，冒烟测试通过后配置管理人员进行封版、版本制作（针对产品来说）/部署上线（针对项目应用来说）。

参与人：配置管理人员，测试

• 支持维护

概念：支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。

参与人：支持维护人员/售后工程师

三、模型分类

从概念提出的那一刻开始，软件产品就进入了软件生命周期。在经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后由于缺少维护费用而逐渐消亡。这样的一个过程，称为”生命周期模型”（Life Cycle Model）。典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

1.瀑布模型

在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段，可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

然而轻易抛弃瀑布模型的观点也是非常错误的，瀑布模型还是所有软件开发模型的基础，体现了软件开发的本质过程。对于一些大型的软件项目，试图过于简化瀑布的前期的需求和设计阶段，用一个简单的原型或者迭代来模拟未来的系统，并试图帮助确认和挖掘客户的需求，是不可能的，不仅此时离客户的最终需求和隔山万千重，系统的架构也会随着过程而有很大被抛弃和大幅调整的过程，原型也就起不到原型的作用，成本和时间反而浪费，所以前期的功课还是少不了的，尤其对于复杂系统。

2.迭代式模型

迭代式模型是RUP（Rational Unified Process，统一软件开发过程）推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”

由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。”在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。”

3.快速原型模型

快速原型模型在功能上等价于产品功能上的一个子集。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。 上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。

4.螺旋模型

1988年，Barry Boehm正式发表了软件系统开发的”螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。

螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：

• • 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
  • 风险分析：分析评估所选方案，考虑如何识别和消除风险；
  • 实施工程：实施软件开发和验证；
  • 客户评估：评价开发工作，提出修正建议，制定下一步计划；

螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下：

• • 螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发；
  • 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目；
  • 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险；

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

四、需求分析

软件生命周期是指软件从产生到最终被废弃的生命周期，可以分为三大阶段，分别为定义问题、软件开发和软件维护，其中问题定义中的需求分析是软件开发和维护的前提，它直接决定软件项目的成败。在进行软件需求分析时，要明确需求分析的目标，采用合理的需求分析方法和工具，全面且正确的进行需求分析。获取需求时会受很多因素的影响，从而导致需求不能正确表达用户需求或者需求分析不够正确等，所以需求获取时要选择合理的获取方法，同时对需求要进行正确深入的分析，进而采用适合的工具来对需求进行说明和描述，这样对于后续的软件设计、编码、测试和维护打下坚实的基础。

软件需求简单的说就是研究“做什么”的问题，在现实工作过程中，应该考虑除功能需求之外的业务需求和用户需求。业务需求主要反映某机构或者客户对软件产品高层次的目标要求；用户需求是指用户使用产品必须完成的任务；功能需求指开发者不得不完成的软件功能，可以说功能需求满足了，业务需求也就达到了，需求分析并不考虑怎么做的问题。

声明：以上资料都由 络收集所得，且为个人学习整理分享出来，不做任何商业用途

相关资源：趋势科技PC-cillin云安全软件全功能破解版_奇妙趋势软件-系统安全…