宏观上讲，软件开发机构基本可分为二种角色，管理角色和技术角色。不同角色各有其不同的发展方向，如图7所示。

不论是走技术路线还是管理路线，不存在那种角色地位更高的问题。高级架构设计师与部门经理具有同等的地位与待遇。

4. 软件开发的阶段划分及目标
软件开发进行阶段划分主要有以下三方面优点：
1) 有利于软件质量控制；
2) 便于项目进度控制与管理；
3) 有利于项目成本费用控制；
4.1 软件开发的阶段划分
虽然软件开发与工程设计有其相似之处，但由于其所处的领域不同，发展历史与人文环境也有一定的差别，完全照搬工程设计的管理模式也存在一些弊端。下面就国外流行的软件开发模式与工程设计理论及原始的软件开发做以简单比较，见图8。

原始的软件开发模式很是简单，有些项目连需求分析都不完整，软件测试只是相当于模块集成一级的测试，没有规范的软件测试。软件质量取决于编程者个人的技术水平，质量无法保证，也很难控制。在满足用户需求方面取决于编程者个人的理解，软件交付后经常发生大面积的修改。项目似乎完成得很快，交付后大面积的修改经常导致延误工期，修改后的软件缺乏必要的测试手段，往往导致极大的售后服务支持成本。造成项目表面赢利、实际亏损的局面。
软件工程理论指导下的软件开发管理模式也存在一定的问题，那就是有些环节的可操作性较差，主要表现在需求分析到总体设计这个环节。需求分析是文档性的描述，一般是软件开发人员对用户需求的一种理解，这种文字描述一般很难精确可视地展现未来软件的情况，而用户也很难说清楚自己的需求，这就使得用户很难鉴别需求分析的精确性。往往导致软件交付后的大量修改。有一篇“Client / Server软件开发常犯错误”的文章说得好，“用户不知自己需要什么样的系统，但知道不要什么样的系统”。
为避免软件开发中需求分析到总体设计这个环节的歧异性问题，目前，国际流行的软件开发模式中增加了FS+UI（功能规范和用户界面）这个环节，这个环节不但解决了用户在需求分析理解上的困难，同时也解决了软件开发过程各种角色人员的并行工作问题，便于软件开发工期的缩短，有利软件开发质量与成本的控制 [ FS+UI（功能规范和用户界面）见后面章节 ]。
4.2  软件开发各阶段目标
以下就软件开发阶段划分的各阶段的任务与目标做以简单描述，这是软件公司进行质量控制的基础。
1) 可行性分析
可行性分析是软件项目立项的必要阶段，对于项目型软件开发，可行性分析一般由用户自行完成，软件公司基本在技术上给予必要的支持。对于产品型软件开发，可行性分析是非常重要的一环，产品采用的技术、市场定位与销售策略等直接关系着产品的生存与发展。
可行性分析基本包括如下几个方面的内容，

A. 项目定义：项目定义主要是对产品定位有一个大致的描述，钩画出该软件产品的运行环境、产品功能、用户特征以及制约因数进行全面的描述，以便下一步工作的展开。
B. 技术分析： 此处的技术主要包括软件的开发环境与运行环境所涉及的各方面技术，在此应对这些技术的发展状况，成熟情况及未来的技术走势应有细致的阐述。
C. 市场分析： 包括国内外行业发展现状、市场格局、发展趋势，在市场容量统计数据的基础上，推测我们产品可能的市场占有率及销售情况。
D. 产品策略： 产品策略包括产品的技术策略与产品的市场策略。
E. 投资与回报分析：项目投资总额、项目成本核算、项目收益、投资回报等。
F. 已有资源分析：包括资金资源、人力资源、技术资源等的分析。
G. 其它应考虑的因素
2) 需求分析
需求分析是软件项目正式实施开始的第一个阶段，需求分析应该遵循可行性分析确定的基调，包括技术路线、产品基本功能、产品运行环境及市场定位。需求分析主要应完成对用户应用流程的描述，即完成商业逻辑分析。并根据商业逻辑的需要确定软件的功能列表及描述。
3) FS+UI
A. 总体描述，包括应用平台及应用限制，...
B. 功能列表
C. 用户界面
FS+UI的合格与否取决于能否完成以下二方面的工作。
① 完成用户手册的编写！
② 准备测试计划、测试用例及确定验收标准！
FS+UI是产品管理部门与软件开发部门的接口，对于项目型开发是软件开发商与用户责任划分的重要依据，FS+UI不同于需求分析，它提供给用户的是一个清晰可见的用户界面与完整的功能说明，方便用户的理解与确认。软件开发据此进行下一步工作就有了坚实的基础，避免软件交付后的大量修改工作，有利于软件质量与进度的控制。同时，便于软件开发并行工作的展开。
FS+UI是软件总体设计及软件α测试的基础。
4) 总体设计
总体设计的依据是FS+UI文档，其目的是根据FS+UI要求，依据具体采用的开发工具与技术平台确定软件实现的对象关系与数据库结构。并非项目组每个成员均参加总体设计，一般来讲，一般中小项目总体设计为一到二个人，中大型项目一般为一个总体设计小组，由项目总设计师负责将项目进行分解为可操作的大小，交由不同设计小组完成相关功能的总体设计，总设计师负责协调各子项之间的协调关系，从而完成大型的总体设计。
总体设计设计深度情况直接影响下一步的详细设计。过细的总体设计也是不必要的，少量的人员进行过细的设计必然影响整个项目的设计周期，而过粗的总体设计当然也不利于详细设计设计任务的分配与设计展开。
总体设计是软件详细设计及软件集成测试的基础。
5) 详细设计
详细设计是总体设计的继续，主要目的是完成总体设计完成的对象内部的商业逻辑的实现设计，在总体设计完成后可以将不同的设计对象交由不同的设计人员来完成。原则上讲，在开始软件编码之前应完成所有的设计细节，避免在编码中进行设计工作。
详细设计是编码及软件模块测试的基础。
6) 编码
编码是软件详细设计的一种再现，编码中最重要的是要遵从相关开发工具的设计规范及数据库设计规范，另外，养成一个良好的编程习惯是一个软件公司和软件编程人员最基本的职业素质。
对于软件应用可靠性要求严格的案例，所有软件模块必须通过模块测试，对一般应用软件中的重要模块也应进行模块测试。
7) 集成
集成是软件开发中重要的一环，集成测试的依据是软件的总体设计。如果缺乏前期的模块测试，必然会导致集成时间的加长，同时也会加重后期的α测试及问题处理的工作量。
8) α测试
α测试是在软件集成结束后软件开发进入的下一个环节，它标志着软件开发从设计级段进入软件测试阶段。一般情况下，软件开发从设计进入测试是通过CMO来完成这一过程。
为完成α测试，测试部门一般包括如下几个方面的工作。
① 编制测试计划
② 编制测试用例
③ 测试执行
③ 测试结论（包括问题报告）
一般而言，测试工作基本上可以分为如下几个轮回：

α测试是软件公司对自身产品的一次自我测试，α测试结束后，测试部门会提供一个软件测试评价报告，这个评价报告在某种程度上决定了该软件是否适应商业销售。
一般来讲，软件通过测试并不意味着软件没有任何问题，只是意味软件通过了可接受测试条件。软件测试的问题报告是软件公司售后服务与产品升级的重要参考因素之一。
9) 问题处理与设计文档改进
问题处理是软件开发组交付测试后的重要任务之一，及时解决软件测试过程中发现的问题，以便进行下一轮测试。
软件开发人员在交付测试后的另一重要任务就是将编码过程中对设计的修改及时反映到总体设计文档和详细设计文档中去，确保定版的软件与其设计文档的一致性。
10) IRL内部定版
测试合格的软件在软件开发部内部定版，进入产品的组装或β测试，及产品销售。对项目型软件开发，则进入系统的实施级段。

5  过程管理与质量控制标准化
5.1 软件开发过程管理
传统的软件开发一般遵循的是瀑布过程模型,一个阶段的结束是下一个阶段的开始。这种模型不适合基于对象、分布式的企业应用开发。部件的开发具有并行性，而非顺序性。另外,瀑布进程模型缺乏灵活性，不适应快速原型开发工具的要求。
基于里程碑的过程模型引进迭代过程模型，允许开发任务的重叠和反复，可以很好适应基于部件的软件开发。基于里程碑的过程模型便于团队模型中责权的划分。便于风险评定，鼓励快速交货。
1) 里程碑过程模型的特征：
A. 里程碑过程：软件开发过程是由指导开发进程的外内部里程碑所驱动的。
B. 明确责权关系：过程模型将每个里程碑与开发组的责任角色相关联。
C. 风险驱动的计划安排：高风险部件应尽早完成。
D. 评估说明：评估说明直接影响着项目的计划与管理，在整个软件开发过程中致关重要。
2) 里程碑的制定
里程碑也可以称作项目实施计划。对于软件开发项目而言，一但项目立项确定，需要做的第一件事情就是确定项目实施的里程碑。根据前面我们确定的软件开发阶段划分，在里程碑中应清楚地定义每一个阶段的开始时间、结束时间、负责人，阶段的提交成果由各阶段的软件开发规范确定。里程碑是公司对进行项目控制的主要依据。里程碑一旦确定，各相应负责人应确保按时交付任务。
对于各不同里程碑阶段可以根据需要制定阶段里程碑，阶段里程碑一般由开发组织内部确定以便于更好管理与控制项目的进程。达到某个里程碑表明对此负有主要责任的角色完策任务。便于明确各个角色责权范围、有利于按时完成任。
软件开发里程碑主要包括如下阶段：

3) CMO 软件配置管理
为确保软件及其文档的一致性，进行软件配置的管理是必要的。

5.2  质量控制体系
软件开发阶段划分的目的是为了便于形成基于里程碑的软件开发质量控制体系，每个里程碑都是一个质量控制结点，这些质量控制结点贯穿于整个软件开发全过程，从而构成软件开发的质量控制体系。
基于里程碑的软件开发质量控制体系可以用图11表示。

图12表示软件开发阶段目标与质量控制的关系

每个具体的里程碑与软件开发组某一具体的角色相关联，不同的角色则隶属于不同的业务部门，而人员业绩的评估与管理归属各自的业务部门，因此，基于里程碑的软件质量控制必然会演变成对角色的质量控制，这样才能真正达到对软件质量的控制。基于角色的质量控制体系详见图13

在软件开发的六种角色中，一般规模的软件公司都会将其做以归类，图13是基于常见的软件开发任务划分方式形成的基于角色的质量控制模型。
5.3 
根据软件开发的阶段划分及基于里程碑的项目管理模式，贯穿于整个软件生命周期中的软件开发规范基本包括如下规范：
1) 可行性分析规范 （FS）
2) 需求分析规范 （RS）
3) 功能说明规范 （FSS）
4) 用户界面规范 （UIS）
5) 总体设计规范 （GDS）
6) 详细设计规范 （DDS）
7) 程序编码规范 （CS）
8) 软件测试规范 （TS）
以上规范在软件开发阶段划分章节已有简单描述，此处不再介绍。
5.4  阶段审核制
软件开发阶段审核制是采用基于里程碑管理模式的必然产物。在每个里程碑结束时公司质量控制机构（QA）根据相应的软件开发管理规范及应用要求对阶段成果进行评议控制，确保应用开发的顺利进行，及交付的应用系统能够满足用户的使用需要，确保交付的系统能够代表公司的整体技术水平。同时也有利于规避软件开发风险。

6. 软件维护与版本控制
无论是项目型软件开发还是产品型软件开发，软件的维护与版本控制都是必须值得重视的。因为任何一个软件产品或一个应用软件开发项目或多或少存在一些值得改进的问题，这些问题可能是程序的Bug，也可能是因不能满足用户需要迫切需要改进的地方，对于交付运行的软件进行后期维护成为软件公司必不可少的工作。而由于后期维护所造成对已定版软件的修改的管理是致关重要的。
6.1  软件维护与版本控制的意义
软件维护与版本控制的目的有三点：
1). 解决由于问题处理带来对已定版软件的版本升级等管理问题，确保可以提供某一特定时间的版本，为用户提供满意的售后服务。
2). 解决软件开发过程中的版本控制问题，有利于团队开发的协同工作问题，也有利于公司对开发项目的版本控制及知识产权的保护。
3). 良好的版本控制与管理，有利于新版软件的开发工作的进行。确保软件产品循环渐进，逐步提高。
6.2 开发过程的版本控制
软件开发过程中的版本控制一般都是基于特定的开发工具和特定的版本控制管理工具，现在绝大部分的软件开发工具均提供这方面的功能。如Microsoft Visual Source Safe （简称VSS），IBM Visual 系列开发工具等，版本控制的原理大同小异，以下以VSS为例介绍软件开发过程的版本控制模型。

软件配置管理包括软件开发过程中的文档管理与程序管理，软件开发中的文档主要包括如下文档：
* 可行性分析报告
* 需求分析文档
* 功能规范及界面文档
* 总体设计文档
* 详细设计文档
* 编码设计文档（包括模块测试计划及结果文档）
* 测试计划文档
* 测试用例
* 测试评估文档（包括问题报告）
* 用户手册
* 在线帮助文档
与CMO软件配置管理相关的文档一般包括：
* 工作报告（编码期间协同工作文档）
* 问题报告文档 （编码期间协同工作文档）
* 问题处理报告 （编码期间协同工作文档）
* CMO每日报告（为程序经理提供每日项目变化报告）
不同配置管理软件的功能大同小异，总体来说，配置管理软件的安全性较差，为确保软件开发过程中代码与文档的安全，制定一个合理的系统备份策略是必要的。