导航

• 我们为什么需要了解软件的生命周期/li>
• 软件生命周期主要节点
• • 需求分析
  • 软件设计
  • 程序编码
  • 软件测试
  • 运行维护
• 常见的软件开发模型
• • 瀑布模型
  • V模型
  • 原型模型
  • 螺旋模型（迭代模型）

我们为什么需要了解软件的生命周期/h1>

越是大公司，岗位的局限性越大，只需要拧好自己负责的那颗螺丝即可。所以我们往往忽略了对全局的整体理解，虽然对各个方面或多或少都有了解，但没有好好去思考过，没想过其存在的原因、合理性、必要性等。所谓“欲穷千里目，更上一层楼”，又所谓“不识庐山真面目，只缘身在此山中”，不妨暂跳出工作角色的限制，不在仅仅是一名BA、开发、测试或者运维，以CTO自居，去纵观一个软件的整个生命过程。有了充份的大局观，对如何做好具体的工作，以及个人的职业发展，均有益无害。

软件生命周期主要节点

生命周期这个词，我认为它稍微带点哲学的意味。大到宇宙的诞生与毁灭，小到细胞的孕育与死亡，万事万物都有一个从0到1，再由1归0的过程，软件，也是如此。

软件的生命周期主要可以分为这几个步骤：需求分析 -> 软件设计 -> 程序编码 -> 软件测试 -> 运行维护。软件第一次上线后，会不断循环这个过程，为软件增添新功能，或修复旧问题，直至软件再无继续开发维护的必要时，下线处理，宣告软件生命周期的终结。

需求分析

世上本是没有软件的，但为了解决某些人力难以解决的问题，为了提高工作效率，为了获取更多收益等等原因，于是结合现有的技术，决定去编写一个软件，这就是软件的孕育–为了解决问题，创造收益。

怎么才能通过软件解决问题，以及用何种技术实现，解决这类问题的过程就叫需求分析。BA（Business Analys)、产品经理等岗位，就是来处理这类事的。

需求分析大致细分为以下几个步骤：

• 1.需求沟通：往往由具体的软件使用方提出问题，但BA也会通过行业研究等途径发现问题。BA需要去理解用户的问题点、痛点，以全局的专业眼观给出预定的解决方法，并最终与用户达成一致。
• 2.需求分析：需求有了初步意向后，还需要进一步判断其真实性、价值及优先级、技术可行性等。
• 3.文档产出：编写PRD文档（产品需求文档），绘制原型图、流程图、时序图等，用于与开发、测试团队交接。
• 4.生产验收：需求上线后，与用户一起进行生产环境的验收工作，确认原始需求的预期目标已实现。

如果把BA当作一个function，那么他的入参就是”各类问题“，出参则是”需求文档“，是不懂IT的用户与IT团队间的沟通桥梁。

软件设计

在需求目标明确后，则需要着手考虑如何实现的问题。如果只以实现功能为目标，随意编码，则会导致场景考虑遗漏、系统代码后期难以维护、代码风格不统一难以阅读、重复或无用的代码越来越多，等等问题。

所以在正式开始编写代码前，需要进行设计，想清楚如何写，再动手。一般是由开发团队进行设计，由开发组长、经理、领域专家或开发人员自己，并绘制类图、E-R图、伪代码等。设计完成后，还需在开发团队内进行评审、修改。

软件设计，就是将文字版的需求文档，转换为开发团队专业性的语言，如果需求分析是用户与开发团队的桥梁，那么完成软件设计，算是彻底“过桥”了。

程序编码

分配开发任务至具体开发人员，将软件设计的结果编码实现。主要是对技术的应用，相对纯粹。也经常会遇见在设计过程中没考虑到的难题，或是代码运行结果与预期不符等疑难杂症，则需要花费大量精力去思考和解决。

为了提高编码效率与代码质量，也出现了很多分类。比如将前后端分离，分为前端开发、后端开发，分别专攻。为了保证代码质量，出现的TDD(测试驱动开发)、结对编程等理论。

比较关键的就是TDD这一点，这里的测试主要指单元测试，即一种白盒测试手段，通常由开发人员自行编写（自己测自己的代码是不靠谱的，结对编程可解决这问题，但又会出现成本可行性问题）。若想做到全路径的单元测试边际收益太低，通常覆盖60~80%即可。

软件测试

开发团队完成编码并自测通过后，交付给测试团队进行测试验证。测试人员扮演的角色，就好比传统制造业里的质检员，需要对软件进行全方位的测试验证，合格后才可以发布生产，交付给用户。

软件测试的种类有很多种划分办法：

• 从逻辑层级上划分：单元测试、集成测试、接口测试、界面测试、系统测试
• 根据测试的可见度：白盒测试、灰盒测试、黑盒测试
• 验证程序的健壮性：压力测试、性能测试、安全测试
• 帮助测试人员减少重复性工作：自动化测试

测试人员越早介入越好，在需求分析结束后，则可开始编写测试用例了，还可介入开发过程，提前编写单元测试、接口测试，以保证程序做了其该做的。而如何判断程序没有做其不该做的，也是另一半重要的工作。

运行维护

程序的生命周期里，开发、测试等只占整体时长的一小部分，绝大部分时间都是任其在生产服务器上运行的状态。（如若不然，那么投入产出比也太低了）

“常在河边走哪有不湿鞋”，就算是由最顶级的开发人员、测试人员产出的软件，也不能100%保证在运行过程中不出错。而为了应对生产环境出错的情况，则需要专门的运维人员来保证软件的可用性。

准确的来说，生产环境的运行维护可以分为两种类型：

• 1.基础设施的运维：保障服务器、 络、交换机等等基础设备的可用性，并为可能的灾难做预案，以便于真正发生时及时应对。
• 2.软件使用的运营：指导用户操作，为用户解答操作性问题。判断“系统故障”是人为问题还是系统问题，若为系统问题，则需要联系开发团队进一步排查并修复。

常见的软件开发模型

在实际工作中，如何让以上步骤更好的串联、配合，是一个需要在实践中求真知的过程。在不断的实践中，总结了一定的流程套路、框架，被称之为软件开发模型。

常见的软件开发模型有瀑布模型、原型模型、螺旋模型、喷泉模型、形式化方法模型等等。

瀑布模型

布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。

在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。

原型模型

在开发真实系统之前，通过构建一个可以运行的软件原型，使开发人员与用户达成共识，以便理解和澄清问题，最终在确定的客户需求基础上开发客户满意的软件产品。（通常由产品经理使用Axure等软件绘制原型图）

对有待开发的软件系统，先开发一个原型系统给用户使用，然后根据用户使用情况的意见反馈，对原型系统不断修改，使它逐步接近并最终到达开发目标。