软件发展的生命周期
什么是软件发展的生命周期？就是将逻辑性的系统概念，发展成可以实作的系统设计文件后，以撰写程式码的方式实现，接着交付布建、测试运行，最后进入运行维护的发展步骤。
前言
笔者平常所接触的工作、研究等，常以专案或计画型态存在，本篇旨在藉由介绍专案的阶段、软体开发的生命周期与流程模型，帮助大家日后在面对软件专案开发时，能够依据特性，如程式语言类型、时程、成本、人力及组织型态等诸多因素，选择适合的模型，提高执行效率与品质。
软件业的特质
软件产业与实体产业有很大不同，软件产品『一次生产，多次销售』的特质，较专案导向的产品更是明显，不像制造业需投入大量资金来建造实体生产线，才能推出产品。
软件业的生产线就是软体开发流程。就投资而言，软件产品成形所需的元素为开发人员与专业知识，而此生产线只要制造一次就可以复制多次，相形之下，也突显出软件开发流程的重要性。软件业在开发的过程，有三个阶段很重要，取其最后一个字母，称为软体的3N：
Visio N：洞悉使用者的未来需求。
(做产品的公司，因为使用的客群过于广大，没有固定范围，确认使用者的需求也显得格外重要。软件公司常用焦点团体的方式，找人担任产品的使用者，以发掘、评估产品的功能。)Missio N：一个Vision会被分割成许多不同的Mission来达成。
(先要有一个足够大的Vision让公司看见未来的营利，才会愿意针对各种状况与问题着手，才有很多Mission被分割出来。)Actio N：软件3N中最实际的部份，此阶段就是进行软体开发。
专案的生命周期与阶段
专案的生命周期＝努力：时间。一开始工作量与时间皆为零，随着时间的推移，工作付出逐渐增加而达到高峰，再逐渐减少至专案结束。专案与服务不同在于，专案一定会有结束的一天，服务则必须一直维运下去。
专案通常分成几个阶段进行：
Concept(概念)：
搜集资料
确认需求
建立目标
分析风险
提出建议
获得核准
Development(发展)：比较接近规划阶段(Planning)；
建立团队
决定范畴
拟定计画
分解任务
排定时程
Implementation(执行)：真正开始进行程式码撰写；
带动团队
建立资讯
执行任务
采购物品
控制成本
掌握品质
Termination(结束)：这是最后阶段，会产出结案报告，经验是否能传承，全看结案报告是否能达成下列事项：
把当初的规划与最后结案的情况做比对，确认是否都达成预计的目标。
统计花了多少时间与成本。
将上述资料整理分析，累积增长经验，使日后评估更精确。
评估的方法有很多，经验累积后，才能找出最适合的法则。
此阶段主要活动为：
完成任务
审查结果
移转责任
结案报告
经验学习
解编归建
专案都会分阶段执行，完成第一阶段再进行第二阶段，以此类推直到完成。分阶段的意义在于，如果在每个阶段进行过程中，遇到最坏的状况或无法解决的问题，都可以有喊停的机会，不致于一直错下去，到无法挽回的地步。
软件生命周期模型
软件开发工程师必须组合出一个包含过程、方法及工具层次的开发策略。这样的策略经常被称为软体发展生命周期模型(Software Development Life Cycle Model，SDLC)。
软件开发程序(Software Development Procedure)或称为软体工程规范(Software Engineering Paradigm)，在IEEE/EIA 12207与J-STD-016有详尽的说明。
软件发展生命周期模型主要描述或定义软体开发的步骤阶段，提供开发者一个系统性的流程，以成功地开发使用者所需要的软件。这次为大家介绍七种模型：
1. 瀑布式
发展阶段一段一段往下推，一定要一个阶段作完才能往下做，无法平行，因此要准备的文件相当多，不适于小型专案开发。
1970年美国为了国防及航太计画所产生的模型。
安全的软件开发方式。
要求许多准备文件。
较易维护也易于管理。
所需开发的时间较长。
若产品需求稍做更动，会导致后面阶段也要进行更改。
适合大型专案开发。
2. 渐进式
特点：第一阶段产生的结果是第二阶段的需求。
每个阶段的产出都是产品，所以每个阶段产出都非常明显，但完成的产品会一直因为上一阶段的产出而有所变动。
将开发流程分为许多小型瀑布开发模式。
减少产品需求更动的影响。
开发成果较易显现。
可在不同的建构版本(Build)中决定产品开发是否继续。
3. V型
每个阶段都有对等的关系，从当初的设计、开发、架构…等，都会对应到一个方法来验证。
改良自传统瀑布式。
对品管是最有助益的方式。
确保所开发的产品符合设计规格。
承袭传统瀑布式缺点，需求更动即造成后续影响。
4. 原型快速开发
与瀑布式近似，但每个阶段都有强烈的回馈(feedback)，瀑布式与其不同在于它是很严谨的锁住每个阶段。
软件需求上的沟通确认较容易。
较适合专业开发模式。
5. 螺旋型
将瀑布模型的最终结果导回源头，成为一个往复式的圆圈，使整个流程具备回馈与检验机制，这就是螺旋模型(Boehm，1988)。
改善传统瀑布式的需求更动影响缺点，结合风险管理与原型快速发展的观念。
将开发目标、替代方案、限制的项目列出。
分析是否有其他方法，同时找出存在风险并加以解决。
进行开发、测试、审查的步骤。
进行下一个阶段的计画。
6. 极限型
适合Web应用方案，不适用大型专案(因大型专案在模型图中会有很多箭头进出)，这也是个强调回馈的模型，若采用此方式会造成需求不停变动，大型专案要一开始就清楚明确定义出需求，确定后就不宜更改。
Kent Beck 于1996年提出的理论，具有下列特点：
沟通(Communication)
简洁(Simplicity)
回馈(Feedback)
勇气(Courage)
注意事项：此模型并未要求准备详细的文件，对于专案开发而言是很难接受这样的开发模式。
7. RUP
软件工程在近代最有名且使用在物件导向是Rational统一流程(Rational Unified Process，简称RUP)。由Rational 公司发展，现已被IBM公司并购，有三大特点、四个阶段和九个核心流程。
三大特点为：
软件开发是一个叠代(Iteration)过程。
软件开发是由使用案例(Use Case)驱动。
软件开发是以构架设计(Architectural Design)为中心。
采瀑布式改良过的阶段开发流程：
起始阶段(Initial phase)：进行可行性研究，定义专案大小及涵盖范围，评估专案所需的能力、时程与经费，及资讯系统预期达到之效益，了解商业模型及需求。
精细规划阶段(Elaboration phase)：拟定专案计画、系统特性与架构•确认商业模型及需求，进行系统分析与设计。
建构阶段(Construction phase)：建构产品并进行单元、整合测试。
移转阶段(Transition phase)：将产品分批交付给客户验收测试，并进行使用者训练。
现实环境的软体开发模式
由上而下的方式(Top-Down Apporach)
此方式也称为架构式开发，使用开放的架构思考，将产品的需求列出，利用WBS(Work Breakdown Structure)的方法将各个需求分散成为不同的功能，每个功能再细分为规格。这种方式开发出的产品在延展性及稳定度较佳，但相对所需的开发时程和准备功夫也较长。由下而上的方式(Bottom-Up Approach)
通常使用这种方式是基于市场竞争考量，此法亦称为组合式开发，所采用的方式就是以目前所拥有的资源及技术进行快速组合成为产品。这种开发模式虽快速但他不是基于一个架构性的思考，因此所开发的产品在延展性及稳定度较差，而且产品需求是经由组合方式产生的，所以部份需求会与使用者的实际需求有所差异，当然伴随而来的是教育使用者的额外费用。
结语
上述对各种不同软体开发流程做简略的介绍说明，但大多数都是以传统瀑布式为主轴，并加以改良。但就软体产品的组成观点来看，其实只有两种方式：
1. 架构式开发
2. 组合式开发
无论选择哪种模式，在开发过程中，都必须设立不同的里程碑，或是检查点；例如像Pre Alpha、Alpha…等的名称都是流程中的里程碑。在每个里程碑时最好用REDC(Review、Evaluate、Discussion、Conclusion)方法来检查目前的进度，再进行下一阶段的开发流程。
软件开发在现实生活中困难重重，建议先建构基础的软件开发模型，再进行较大范围的系统开发。若是开发人数较少的团队，不建议开发Multi-Domain、Multi-Language、Multi-Skill、Multi-Model的软件，这样只会增加团队执行上的困难度。