软件生命周期详解

大家好，我是十一，今天我们就软件生命周期进行详细的解说。让大家整体的认识下软件的"成长历程"。

成都创新互联公司服务项目包括尚志网站建设、尚志网站制作、尚志网页制作以及尚志网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，尚志网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到尚志省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

什么是软件生命周期？

软件生命周期是软件从产生到废弃的整个过程，周期内有问题定义、可行性分析、需求分析、系统设计、编码、调试和测试、部署/发版、维护升级到废弃等阶段。

那软件生命周期各个阶段都是什么呢？

我们先看张购物图（为了这张图我眼睛也是要废了~）

上图呢就是一个完整的淘宝定制购物过程图了，那么购物过程跟咱们软件又有什么关系呢？整个过程对比《浅聊软件开发》里的软件生命周期图你能一一对应上吗？

大家先自己想想~（来，闭上眼睛，想一想～）

好啦，我来揭晓答案，大家看看你想的对不对！

首先，为故事找一主人公，暂且叫心心吧，心心定制了需求，然后跟客服沟通是否可做（需求可行性分析），沟通后选择喜欢的样式、尺码等下单，商家拿到订单后根据订单要求出设计图（原型设计），出图后跟心心沟通看是否是心心想要的（需求确认），得到肯定答复后投入生产（开发），生产完成后内部质检员检查（测试），检查无误后快递给心心（上线/发版），心心拿到衣服开始试穿以及查看是否有质量问题（测试），很满意此次购物，于是给了满意好评后，订单关闭，整个购物过程完成。

大家可能会说那支持维护没体现呀？

那如果心心穿了一周后发现衣服有掉色/图案一洗就花了等等质量问题呢？是不是就该去找客服了，跟客服沟通后商家会进行处理，换货/退货/修复等等，这个就是支持维护啦。

注意哦：购物图中的“商家根据要求出设计图样式” 这个跟软件流程图中的设计不是一个东西！

• 商家根据要求出设计图样式：是原型设计，即做一个静态的类似成品展示给客户，让客户确认是否是自己想要的，属于需求确认

• 软件流程图中的设计：是开发设计，设计要实现产品那么需要用的语言、框架、技术等等；对应购物图中的商家生产部分，商家生产前需要决定各种用什么布、线、缝制方式、配图材料/方法等等。

  上述整个过程其实跟实际的软件产品的整个流程比较贴切了。你了解了吗？我画了一张完整的软件流程图，供大家参考~

下面我们依据上图来分别介绍各个阶段。着重介绍每个阶段的概念以及参与者。 

需求定义（Ruquest for Proposal）：
描述：定义出本次任务都需要做什么，做成什么样子（比如，买家跟卖家说我要什么样子的衣服，然后双方开始协商，最终达成一致意见，这个过程就是需求定义）。
参与者：产品经理，需求，客户

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

需求分析/用户需求（Requirements Analysis）：
描述：需求分析其实是在做需求细化，按照任务说明书中的任务内容和指标具体细化各个点，细化到每个框每个按钮的样式，输入输出等各项值（比如：设计和工厂分别就这个衣服做材料分析，分析出这个衣服需要多少布料，扣子什么样式、颜色，不同布料具体用多少等等，这个过程叫做需求分析）；统一整理编写成《需求说明书/需求规格说明书》。
参与者：产品经理，项目经理，测试/质量管理员(很多公司把这个统称为QA)，开发，架构师

评审：（从图中可以看出，各个阶段几乎都需要做评审，在此处统一描述）
描述：评审就是做审查，对这个阶段的工作进行审查，看是否偏离或者有遗漏（比如：设计和工厂的各个环节都有相关的审查，审查材料是否合格、设计是否符合规定、按照工人/设计出的材料需求是否足够或者多余等等，这些审查都是评审）；评审一般由相应工作人员来参与
参与者：每个阶段的评审一般都是各职能部门内部审核，也可以申请其他相关人员审核，比如需求评审，一般是产品经理、项目经理、测试、开发一起评审；系统设计一般是项目经理、开发评审；测试策略评审一般是测试组内部评审等等

开发线

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

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

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

测试线

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

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

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

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

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

测试报告：
描述：最终测试完成（所有测试用例通过/已挂起）会出测试报告对以上测试进行总结性描述。
参与者：相关测试工程师

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

支持维护（Production Support）：
描述：支持维护类似于我们日常中的售后，主要是对已卖出的产品/已上线的项目进行日常维护。包括纠错性维护和改进性维护两个方面。
参与人：支持维护人员/售后工程师

以上就是整个软件的流程介绍了，内容有点多，但是我希望你能认真的看完，并且加以理解变成你自己的知识。

注意：以上的软件开发流程只是一个最基本的模板，但是公司内部有自己的组织架构，可根据项目酌情调整。只要适合自己的项目那么就是对的，就是好的。

 好了今天的内容到此结束，欢迎进群与我沟通！我们下次再见～