首先讲一下软件生存周期的定义，即以需求为触发点，提出软件开发计划的那一刻开始直到软件在实际应用中完全报废为止可以认为是一个完整的软件生存周期，软件生存周期的提出是为了更好的管理、维护和升级软件。其中更大的意义在于管理软件开发的步骤和方法。它把整个的软件生存时间看作是一个整体，以时间的推移和软件开发的工作重心之间作为划分点，把软件开发和维护的工作细分为若干个相对独立的部份，从而更好的控制软件的开发进度和难度，同时也十分有利于降低软件的出错频律，协调各个部门间的工作配合和责任分配。

软件生存周期的各个阶段的划分并没有一成不变的法则，不同的开发方式、软件种类、软件规模和开发环境都会在不同程度上影响软件生存周期各阶段的划分，但无论最终把生存周期如果根据自己的实际情况进行划分，都是旨在更好的利用手中的资源（主要指人力资源、软件资源、技术资源和源码资源），降低软件的开发风险、复杂度和开发成本（主要以开发的时间和投入资源为衡量标准），要做到最好的对软件生存周期各阶段进行划分，就必须遵循一条基本的原则，那就是在各阶段的任务应尽可能的相对独立，同一阶段各项任务的性质应尽可能的相同，从而达到降低每个阶段任务的复杂度，减少不同阶段任务之间的联系。这样做对软件项目开发的组织管理是十分有必要的，同时对最终的软件项目开发成功是不可或缺的。

尽管软件的生存周期各阶段的划分没有一个明确的法则，但就一般性而言，软件生存周期包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编写代码、软件测试和软件维护等活动（有的文档资料和开发项目把概要设计和详细设计合在一起，统称为软件设计或设计），这些活动的每一个可以说是软件开发过程中必须要经历的，所以我们应该将它们按照项目的划分合理的安排到各个阶段里面去。

既然软件开发周期这么重要，无论对软件项目最终开发是否能取得成功或是对软件管理和资源投入，我们就应当充份的了解周期里各个活动的定义和任务，才能合理，准确，客观的安排每一阶段的工作，以下就对各种活动的定义和任务做一下简单介绍，使之对它们有一个初步的了解。

一、 可行性分析和项目开发计划

这两个活动通常被整合在一起进行，在实际工作中通常把它们归类到同一个阶段中。在某种程度上甚至可以把它们看成是一个活动整体，要做的事情就是回答“需要做什么？要如何去做？可不可能完成？”

在这个阶段中经验起到了决定性的作用，软件工程之所以难就难在没有固定公式可供使用，很多时候都是靠系统分析员的经验来判断是否可行，在这个阶段中，可行性分析要依靠项目开发计划提供依据，而项目开发计划只有在初步得到可行性研究后才能再深入制定，两个活动可以说是互相制约，互相促进的关系。

同时在这个阶段中对要解决的问题定义十分重要，要注意和各方多沟通，得到尽可能准确的问题定义，再和各方再次沟通看看各方的理解是否相同，一般对问题的精确定义和理解在项目开发计划里解决比在需求分析阶段决解更合理，也可以更符合各方利益的要求，同时不会对软件开发方向造成隐患，亦不会给双方就软件开发报酬的商议造成不必要的麻烦。

在用户提出一个软件开发要求后，系统分析员要对此用户的机构进行了解，明确它是一个什么样的机构，它的作用是什么，这有利于分析所开发的项目的原由，同时对使用此软件的最终部门要进行一系列的观察研究，组织开会讨论，通过这一系列工作就可以确定软件项目的性质、目标和规模，其实这工作有点像需求分析的简化版，但对项目的后期工作是一个奠基的作用。到现在应该能够得出可行性研究报告了。

如果可行性研究的结果是可行的，接下来的任务就是制定详细的项目开发计划，项目开发计划主要根据所开发的项目的目标、性能、功能、规模来确定所需的资源，主要包括三个方面，即硬件资源（C）、软件资源和人力资源，除此之外还有对项目的开发费用，开发进度做出估计，可供决策者和用户参考。

至此，本阶段的工作任务已基本完成，这时候系统分析员应将《可行性报告》和《项目开发计划》一并提交管理部门审查。

二、 需求分析

软件开发最难的部份是什么？不用怀疑，就算是最初级的程序员也知道是需求分析，而另一个问题就是“需求分析为什么就那么难呢？”要回答这个问题，必须在实际工作中把“两帮人”搞清楚，一帮是软件开发的相关人员，而另一帮则是使用软件的需求者，通常软件开发人员开发软件都不是为了自己使用，而是为某个组织开发的，这“两帮人”一帮知道怎么用计算机解决实际问题而他要解决的问题不是自己的，一帮需要用计算机解决自己的问题但不懂如果用计算机去实现。

到现在应该知道需求分析的实质了吧，再说白点就是在开发者和使用者之间架起一座桥梁，让开发者最准确的知道“用户要的是什么”，要知道需求分析阶段不是要你动手去解决实际问题，而是要你弄清楚将要解决的问题。

需求分析并不是从一开始就要的，在软件行业初期并没有这个概念，而后来随着软件工程的提出和完善，需求分析才逐渐被人们所认识和重视，主要原因还是随着计算机硬件的不断升级换代，大的软件项目被越来越多的提上了日程，而软件开发技术并没有完全跟得上软件开发的步伐，越做越大的软件项目渐渐的超出了人们所能认识和接受的范畴，开发出来的软件很多都不能适应实际应用的需要，这个时候出现了“软件危机”，为了应对“软件危机”才提出了具有划时代意义的软件工程的概念，而随着软件工程理论的发展和客观上对准确理解用户需求的迫切需要，才出现在需求分析。

需求分析的难点主要体现在以下几个方面：
　（1）问题的复杂性。
　（2）交流障碍。
　（3）用户对问题的陈述不完备性和不一致性。
　（4）需求易变性。

针对需求分析人们提出了许多解决方法和自动化分析工具，如结构化分析方法和面向对象分析方法，CASE技术等等。解决问题的方法有许多，但都要遵循一些基本的原则：
　（1） 可以把一个复杂问题按照某种分解方式进行分解并可逐层细化。
　（2） 必须能够表达和理解问题的数据域和功能域。
　（3） 必须具有良好的模型建立能力，能够准确的把问题用“图表”的形式表达出来。

I：问题识别
　　（1） 功能需求
　　（2） 性能需求
　　（3） 环境需求
　　（4） 用户界面需求
　
　另外对软件各个部分和性能指标也要有一个明确的需求定义，如安全性、可靠性、可维护性、可移植性等等都要通过双方的共同讨论、研究，力求达到一个双方都可理解接受的指标。

II：分析与综合，导出软件的逻辑模型
　对于需求分析实际调研中所得到的信息，综合分析和理解，在此基础上通过规范的需求分析工具导出成为一个开发人员能够理解的软件逻辑模型。

III：编写文档
　　（1） 编写“需求规格说明书”，把双方共同理解和分析得到的结果以规范的方式描述出来，作为今后工作的基础。
　　（2） 编写初步用户使用手册，根据需求规格说明书编写初步的用户使用手册，一来可以更进一步的说明问题，二来可以强制系统分析员站在需求者的角度考虑软件。
　　（3） 编写确认测试计划，作为软件验收时的依据。
　　（4） 修改项目开发计划文档，此时对要开发的软件有了更进一步清晰的了解，应对原来的开发计划做一些适当的修改。
（注：需求规格说明书是项目开发里最重要的技术文档之一，但由于篇幅关系，这里无法给出实例文档，可在本站查找相关说明）

三、 概要设计

概要设计阶段通常在软件开发程序中排在需求分析后面，因为它的结构设计是直接对应需求分析里的功能说明的，在这个阶段，要的依然不是编写代码，而是实现需求功能的软件结构，软件结构是以模块来组成的，所以这个阶段要做的就是把需求分析里所说明的软件功能用模块的形式描述出来，每个模块都有明确的意义和功能，概要设计的主要工作就是设计模块和组织模块。
　　
　除了设计和组织模块以外，数据库的设计也是概要设计的工作之一，即软件系统要存储什么数据，这些数据的结构和关系等等，具体要学习数据库设计技术，已不是本文范畴，可自行找查资料。

概要设计的基本任务：

1、 设计软件系统的逻辑结构。
　没有“结构化”设计的软件系统，以后根本谈不上什么维护升级，就是简单的除虫也成了个问题，就算你的软件代码写得再好也只是“乱码”，根本一文不值，这个道理谁都懂，所以要写好软件，概要设计是非常关健的，具体工作如下：

(1) 采用某种设计方法，将一个复杂的软件系统按功能划分成许多有关系条理的模块。
　(2) 准确定义每个模块的功能。
　(3) 确定模块之间的调用关系。
　(4) 对每个模块确定其接口（要以文档对接口的数量，顺序，作用，属性等进行详细说明，这很重要）。
　(5) 对所设计的模块进行评估，尽量找出错误和不合理的地方，进行改正（这比软件做出来后的修改要容易得多）。

软件结构的设计是非常重要的工作，它直接影响以后的详细设计和编码，不合理的结构将有可能把未完成的系统埋葬，所以应选用能力强和经验比较丰富的程序员来做。

　2、 设计软件所需要的数据库系统
　一个好的软件一般都有一个专门为其设计的数据库系统，数据库的设计已自成理论体系，在这里不会详细说明如何做这个工作，但一般数据库的设计工作可分为数据结构设计和数据库设计，数据库设计还分为概念设计、逻辑设计和物理设计，每一项都有很多的知识和原则，有兴趣的朋友可自己去摸索。

3、 编写概要设计文档
　软件工程很强调文档的作用，概要设计也一样，要做好这阶段应有的文档才算是基本完成任务，对文档的编写主要是概要设计和数据库设计说明书，另外还有对需求分析阶段的用户手册和测试计划进行必要的修改，以更合理的对应所设计的软件系统。

4、 评审
　这主要是对这阶段工作的一次回顾，看看有什么遗漏或错误的地方没有。评审也有很多不同的技术性手段，可一般都将重点放在功能、性能、可行性、接口正确性等方面。

软件概主设计的几个基本原理：

1、 抽象
　即对将要用软件来完成的工作在本质上进行抽象，抛开无关紧要和多余的部份，构造出一个软件需要完成的功能的逻辑结构。

2、 信息隐蔽
　这是对抽象的进一步回应，信息隐蔽的实质就是“各管各的数据”。

3、 模块化
　这在上面已经讲过，模块化设计的根本原则就是做到所有模块尽可能的相对独立，对别的模块的依赖越小越好。模块化还具有几个相关的属性：接口、功能、逻辑、状态。

四、 详细设计

到了详细设计阶段，现在该把注意力从全局移到局部了，但先别着急，现在还不是编码阶段，要做的仍然是软件的逻辑设计部份，只不过现在不是设计结构了。

详细设计就是把我们在概要设计里所划分出来的模块要实现的功能用相应的设计工具详细的描述出实现步骤来，也即是写出代码的算法，在详细设计里所有的表述无论是语言或是图表，都应做到有精确的唯一解释，绝不允许出现有“二义性”或“多义性”的表述，所谓精确的表述就是要做到无论这份文档到了那个程序员手中，他都能看得懂文档的含意而且只有一个含意，不可能再解读出第二层意思来。
　　
　详细设计的任务就是为每个模块所要完成的功能进行具体而精确的描述，要根据功能描述再转化成精确的、结构化的软件过程描述，软件过程描述一般可直接对应到相应的代码，也就是以后程序员会根据这些过程描述来编写程序代码，具体如下：

(1)为每个模块进行详细的算法设计。这是需要用相应的工具来完成的，因为自然语言通常很容易具有“二义性”，而工具能做到含义唯一性。
　(2)为模块内的数据结构进行设计。
　(3)对数据库进行物理设计。注意这不是实现数据库，而是设计出数据库的具体物理结构。
　(4)其它设计（前期特殊代码设计、I/O格式设计、界面友好设计等）。
　(5)编写详细设计说明书。
　(6)评审。

　五、编写代码

编写代码就是真的在机器上用计算机语言实现前面所设计的软件功能了，编写代码时要做到高度对应在详细设计里所描述的算法，因为以后的“除虫”或升级等，很多时候都是以详细设计的文档资料为根据的，如代码和详细设计的描述的偏差，很容易误导以后进行维护工作的程序员，而且这种错误很能被发现，而那样会浪费掉很多不必要的人力物力。

程序员们还要注意的就是在编码时尽可能在重点和难点的地方留下注释，这样对后来的程序员读源代码也有很大的帮助。

六、软件测试
　　
　软件测试近年来好像提到了和需求分析同一个高度，有点实力的软件公司都有相应的软件测试队伍，他们的任务就是和开发人员作对，专门和他们过不去，软件开发得好好的，他们就来故意找茬，可在软件工程看来，这样找茬是保证软件质量必不可少的。

其实就软件这种产品的特殊性而言，没有一个软件可以做到没有BUG，从客观上讲测试是找出BUG最直接和有效的方法，当然这样的说法是相对于软件没有发行而言的，在软件工程里BUG粗劣的分法可以分为代码错误和逻辑设计错误。

至于测试软件的方式由于侧重点不同各有不同，主要方式还是在设计测试用例的基础上检验软件的各个组成部分，逐个测试看能不能达到所期望的结果，测试亦分为单元测试、集成测试、确认测试，除此之外还有错误测试，就是故意输入不合法的数据或故意进行非法操作来测试软件。

软件测试的方法：

软件测试的方法一般分成两种类型：静态测试法和动态测试法，而动态测试法又根据测试用例的不同可分为白盒测试和黑盒测试两类。

1、静态测试法
　不在计算机上进行测试而采用人工和计算机辅助分析的手段进行检测的方法称为静态测试法。

2、动态测试法
　利用计算机来运行相关软件产品进行的测试称为动态测试法，一般而言我们说的软件测试是指动态测试，它可分为白盒测试和黑盒测试。

(1)白盒测试:它把一个软件产品看作一个盒子，而白盒测试就是“打开这个盒子来测试”。测试人员要了解程序的内部结构和处理过程，而测试的主旨就是检查处理过程的细节有无出错。
　(2)黑盒测试：黑盒测试是最贴近用户使用角度的测试，它把软件产品看作是一个封闭的盒子，以功能为中心，测试软件的各项功能是否达到设计时的要求。

最后要讲一点就是原则上不要让软件开发人员再作为软件测试人员，因为人一般都有点“自我”心里，自己写的代码自己来测试，一来他会用“合法”的操作和数据来测试，不会出错，而一旦别人进行操作就会出问题，二来无论他是否愿意，都会有意无意的朝证明自己正确的方向进行，这样的测试很难发现重大的错误。

　七、软件维护

在软件工程各阶段的活动中，软件维护是时间最长的，一般意义上从软件交付使用的那一刻开始，就正式进入软件维护阶段，可能会由于软件本身写得好或其它的什么原因，持续几十年也说不定，这期间对软件的所有工作可以看作是对软件的维护（包括一般意义上的升级和除虫）。

软件维护的任务有四种类型：校正性维护、适应性维护、完善性维护和预防性维护。（题外话：在工业生产高度自动化的今天，软件出错可能导致整个的生产活动停滞，所以有的软件公司把软件的维护工作形象的称之为“救火”，很明显这种是属于校正性维护，无论一个软件公司多么有实力，技术储备多么雄厚，都无论回避“救火”的问题，但如果已经搞到三天“救火”四次的话，那该公司就要好好的反思一下自己了。）

软件维护的一般流程各个公司视情况会有所不同，一般通过行政手续后就可进行，记住维护工作一定要详细的记录下来，以供以后使用，因为对软件的维护一般都会对软件进行修改，而修改过的软件就和原来的软件文档不一致了，如果没有对所做的修改详细记录，以后可能会引起不必要的麻烦，而软件的维护一般的流程如下：

　1、确定维护的类型。
　　2、对校正性维护要从评价错误的严重性开始。
　　3、对适应性维护和完善性维护可以视业务繁忙情况而定，也有条件制定比较完善的维护计划。
　　4、实施维护工作，要确保维护是必要和安全的。
　　5、维护回顾，看看有没有什么地方做的不对或遗漏的。
　　6、编写详细的维护日志。

其实“救火”这活并不是一个好差事，除了要读懂以前那程序员的“天书”外，还有听取用户的述苦和牢骚，同时要面对一些不大好看的脸色，错不在你，这我们知道，可谁叫你是“消防队员”呢？