软件过程是为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动。不同的组织有不同的软件过程，这些活动可以重叠，执行时也可以有迭代。

　　在对待文档的态度上，一些组织认为通过阅读源程序就能理解该产品，而另一些组织对文档十分重视，在需求、设计、测试和维护等方面都要有详细的书面说明，并通过审查和变更控制等手段保证文档的质量。
　　在对待维护的态度上，有些公司十分关注维护的问题，但在像大学研究室这样的组织，往往只关心关键技术研究，而将产品开发与维护留给其他人去做。

　　软件生存周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，一般包括计划、分析、设计、实现、测试、集成、交付、维护等阶段。


　　在实践中，软件开发并不总是按照计划、分析、设计、实现、测试、集成、交付、维护等顺序来执行的，即各个阶段是可以重叠交叉的。整个开发周期经常不是明显地划分为这些阶段，而是分析、设计、实现、再分析、再设计、再实现等迭代执行。

（1） 计划阶段
　　确定待开发系统的总体目标和范围，研究系统的可行性和可能的解决方案，对资源、成本及进度进行合理的估算。软件计划的主要内容包括所采用的软件生命周期模型、开发人员的组织、系统解决方案、管理的目标与级别、所用的技术与工具，以及开发的进度、预算和资源分配。

　　没有一个客户会在不清楚软件预算的情况下批准软件的方案，如果开发组织低估了软件的费用，便会造成实际开发的亏本。反之，如果开发组织过高地估计了软件的费用，客户可能会拒绝所提出的方案。如果开发组织低估了开发所用的时间，则会推迟软件的交付，从而失去客户的信任。反之，如果开发组织过高地估计了开发所用的时间，客户可能会选择进度较快的其他开发组织去做。因此，对一个开发组织来说，首先必须确定所交付的产品、开发进度、成本预算和资源配置。

（2） 分析阶段
　　分析、整理和提炼所收集到的用户需求，建立完整的分析模型，将其编写成软件需求规格说明和初步的用户手册。通过评审需求规格说明，确保对用户需求达到共同的理解与认识。需求规格说明明确地描述了软件的功能，列出软件必须满足的所有约束条件，并定义软件的输入和输出接口。

　　在开发的初期，客户从概念上描述软件的概貌，但是这些描述可能是模糊的、不合理的或不可能实现的。由于软件的复杂性，软件开发人员很难将待开发的软件及其功能可视化，这对于一个不懂得计算机专业知识的客户来说是一件十分糟糕的事情。因此，需求阶段常常产生错误，也许当开发人员将软件交付给客户时，客户会说："这个软件是我们要求的，但并不是我们真正需要的。"为了避免或减少需求的错误，需要采用合适的需求获取和需求分析技术，如快速原型和用例建模的方法等。

（3） 设计阶段
　　设计阶段的目标是决定软件怎么做，设计人员依据软件需求规格说明文档，确定软件的体系结构，进而确定每个模块的实现算法、数据结构和接口等，编写设计说明书，并组织进行设计评审。

　　软件设计主要集中于软件体系结构、数据结构、用户界面和算法等方面，设计过程将现实世界的问题模型转换成计算机世界的实现模型，设计同样需要文档化，并应当在编写程序之前评审其质量。

（4） 实现阶段
　　实现阶段是将所设计的各个模块编写成计算机可接受的程序代码，与实现相关的文档就是源程序以及合适的注释。
（5） 测试阶段
　　在设计测试用例的基础上，测试软件的各个组成模块。然后，将各个模块集成起来，测试整个产品的功能和性能是否满足已有的规格说明。

　　一旦生成了代码，就可以开始模块测试，这种测试一般由程序员完成。但是，对于用户来说，软件是作为一个整体运行的，而模块的集成方法和顺序对最终的产品质量具有重大的影响。因此，除了单个模块的测试外，还需要进行集成测试、确认测试和系统测试等。

（6） 维护阶段
　　一旦产品已交付运行之后，对产品所做的任何修改就是维护。维护是软件过程的一个组成部分，应当在软件的设计和实现阶段充分考虑软件的可维护性。维护阶段需要测试是否正确地实现了所要求的修改，并保证在产品的修改过程中，没有做其他无关的改动。

　　维护时，最常见的问题是文档不齐全，或者甚至没有文档。由于追赶开发进度等原因，开发人员修改程序时往往忽略对相关的规格说明文档和设计文档进行更新，从而造成只有源代码是维护人员可用的唯一文档。由于软件开发人员的频繁变动，当初的开发人员在维护阶段开始前也许已经离开了该组织，这就使得维护工作变得更加糟糕。因此，维护常常是软件生命周期中最具挑战性的一个阶段，其费用是相当昂贵的。