每一个不曾起舞的日子都是对生命的辜负。
它一般指对是软件从计划到完成的整个过程。
常见的软件生命周期模型有 原型模型，螺旋模型，瀑布模型，迭代模型，现在正在使用敏捷软件开发和精益软件。
无论是瀑布软件开发还是敏捷软件开发都包含完整的软件生命周期。完整的软件生命周期包含以下结果方面：
客户调研：假设一个公司有意向去做一个软件，但是不知道这个软件是否有发展前途，是否可以盈利，所以要去做一个客户调研，去调查用户有多少人愿意使用这个软件，从而确定去软件的前景。
合同：如果客户调研的结果较好，这个公司就会去着手实现这个软件。在签订合同后，还需要去做inception确定需求。因为多数情况下公司可能并不知道自己到底想要做一些什么功能。除了inception，还需要确定软件的技术架构。
BA分析：当软件所有的大需求，技术架构都确定好了后，就会交给BA分析。BA会把大的需求拆分成一个一个小的故事卡，然后将故事卡分配给Dev。
Dev：现在就进入了developer的开发阶段，developer会去选择自己想做的故事卡，然后把故事卡差分为task卡，完成开发的任务。当然在开发的时候Dev会自己编写单元测试，也就是开发写的测试。
集成：
QA：QA负责质量保证，检测Dev编写的代码是否有逻辑或使用上的问题。如果有的话会反馈给Dev改正。
运维：为了保证软件的稳定性，需要运维人员去管理软件。
反馈：软件在使用过程中肯定会有测试没有测出来的Bug，这个时候会接收到用户的反馈，Dev和QA会针对用户提出的反馈再进行改进。
一个软件在上线一段时间后会发现功能不完善、功能不够好等，所以会再进行新的软件迭代。
严格把软件项目的开发分隔成各个开发阶段：需求分析，要件定义，基本设计，详细设计，编码，单体测试，结合测试，系统测试等。
使用里程碑的方式，严格定义了各开发阶段的输入和输出。如果达不到要求的输出，下一阶段的工作就不展开。
强调文档，在开发的后期才会看到软件的模样。在这种情况下，文档的重要性仿佛已经超过了代码的重要性。
瀑布模型把开发人员定义为流水线上的工人。由于各阶段的开发人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等。对于客户需求变更，编码人员会比设计人员更容易产生很强的抵触情绪。
瀑布模型产生的管理文档(计划书，进度表)等，能让不太了解该项目的人也能看懂项目的进度情况，很适合向领导汇报用。所以管理人员比较喜欢瀑布模型，但是开发人员不喜欢，因为它束缚了开发人员的创造性。
既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。软件生命周期前期造成的Bug的影响比后期的大的多。
核心是迭代。因为最终目标是让客户满意，所以能够主动接受需求变更，这就使设计出来的软件有灵活性，可扩展性。
宣言：
个体和交互 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过 合同谈判
响应变化 胜过 遵循计划
简单设计，重复迭代。减少不必要的文档。客户最关心的功能最先完成。要求客户有时间对每次迭代的成果进行确认，提出改进意见。沟通是非常重要的，所有的开发人员对项目活动的理解应该是一致的。
开发团队有两个队伍，业务团队和技术团队。如果任何一方控制了沟通，那么项目注定会失败。如果业务一方控制，项目会议上就会不断的要求功能和交付日，而不太担心开发人员是否能够全部完成或开发人员是否明白他们的真正要求；如果开发人员控制了沟通，那么项目会议上技术术语会代替面向客户的业务语言，开发人员也失去了通过倾听来了解客户真正需求的机会。
敏捷开发不能在一开始就给出项目的成本计划。
