按照正常情况，软件开发项目的流程大致可分为“需求”、“分析”、“程序编写”、“集成”、“测试”等阶段，整个开发团队也是按照这个流程组合而成的，所有工作方能顺序进行。这种最常见的模式被称为“瀑布式（Waterfall）”流程法，也就是前一个步骤完成后，再把结果导入下一个步骤，依此类推，直到得到最后结果。这种传统方法的特色是职责分明、各行其是，但同时也有缺点。因为这种单向流程模式缺少各部门间的沟通与反馈设计，也缺少弹性应变机制，一旦发生失误、需求临时改变或流程出现问题时，就会使整个流程大乱，轻则成员彼此指责，重则重起炉灶。这就是软件开发成功率只有24%的原因所在，结果导致人力资源浪费、成本膨胀及客户关系恶化。
既然传统的软件开发体制漏洞百出，那该如何改进呢？目前的软件开发方式，倾向于颠覆惯用的单向式流程，把瀑布的最终结果导回源头，成为一个循环的圆圈（Cycle），使整个流程具备反馈与检验机制。
一般软件开发过程通常分为以下几个阶段：
l 需求分析（RequirementAnalysis）
l 系统分析（SystemAnalysis）
l 系统设计（SystemDesign）
l 程序开发（Implementation）
l 集成及测试（Integrationand Testing）
这种具备往复Cycle能力的软件开发流程图如图3-1所示，并分段详细介绍如下。
图3-1 项目开发流程
重点整理
软件开发项目流程早期常见的模式被称为“瀑布式（Waterfall）”，如今，循环的圆圈（Cycle），使整个流程具备反馈与检验机制，称为RUP（Rational Unified Process），翻译为“统一软件流程”。
3.2.1 需求分析（Requirement Analysis）
开发软件最怕的就是“做出来的东西，不是客户想要的”，轻者劳而无功，重者违约、毁坏信誉、吃上官司等。为了避免这种状况，软件开发第一阶段的重点是“需求分析”。
在进行需求分析之前，开发团队务必要对该项目的专业领域知识有所了解，也就是俗称的Domain knowledge。常见的状况是：开发团队不了解委托客户的专业领域知识，不了解其专有名词、作业流程，无法顺利沟通，而导致项目失败，这样的例子相当多。
例如：如果要涉足金融领域，则势必要了解金融领域中所惯用的专业名词，如“冲销”、“冲正”、“传票”等所代表的意义。要涉足家具领域，则其“仓管”、“点货”、“报单”等术语也需彻底了解。就算一开始不了解，也要在之后彻底弄清楚。若含糊带过、敷衍了事，很容易造成沟通不良等状况。因此，若要涉足专业领域，开发团队内最好有熟悉该领域的成员。
经过数次需求讨论会议后，开发团队应针对客户需求，举行提案会议并提出一份提案简报。这种提案简报应包含以下几点：
l 开发团队组织成员。
l 新系统与过去（旧系统或无软件）的比较。
l 采用本系统可改进的效益。
l 系统功能大纲，是否可满足客户需求。
l 大致的开发日程与估价。
这份幻灯片（讲解提案简报内容的幻灯片）与这种简报会议相当重要，说明白一点，客户的项目可能有很多竞标者，而这种提案简报将是客户对开发团队的第一印象。因此，不论是幻灯片的精彩程度，还是主讲人的表现，都是决定能否争取到这个项目的关键。
因此，这种幻灯片内容要丰富多彩，要能达到吸引人注意的效果，所以一开始不要直接放上系统架构、模块说明等硬邦邦的内容。可以举出实例，比较有无这种新系统的不同，以此突出新系统的价值与必要性。待客户接受新系统的必要性之后，再大致解说系统架构（不必太详细，在SA、SD文件中才需详细）与日程和估价即可。
如果你已通过这种提案会议与简报为你的团队争取到这个项目，恭喜你！我们可以开始进行下一步骤：系统分析。 重点整理
软件开发第一阶段，“需求分析”最为重要。
在需求分析之前，开发团队务必要对该项目的专业领域知识有所了解，也就是俗称的Domain knowledge。
3.2.2 系统分析（System Analysis）
系统分析是为了更清楚地描述客户所要的软件蓝图，通过编写系统分析文件（以下简称SA）和召开系统分析会议等步骤，将软件蓝图描绘得更清楚。
SA文件是作为开发团队与客户讨论之用的，因此必须包含以下几点：
l 前言
应包含背景介绍、开发动机、开发目标等纲要。
l 系统平台架构
应包含这种系统所使用的平台与其架构配置图（硬件、软件、操作系统、服务器、数据库等）。
l 系统软件架构
系统软件架构中，最主要的便是整体系统架构图，此图可用功能框图或网页架构图绘制，其目的在于让客户对系统有一个整体的认识，同时通过此架构图，也方便与客户讨论功能配置、模块增删等细节。绘制上，只要开发团队与客户均能接受，可以据此互相讨论即可。下面列举出常见的几种软件架构图，如图3-2-3-4所示。
图3-2 网上书店软件架构图
图3-3 校园门户网站架构图
图3-4 漫画租售网站架构图
l 软件模块说明
清楚软件架构后，便是对每一模块的细节进行说明。诸如这种模块的名称、数据表、公共程序、所提供的功能等，均需在此以表格方式详细列出。若表格列出不够完整，可以在下方补述。
这部分牵涉到客户需求与后续估价，因此列举得越详细越好，以下列举数例。
【通讯录模块】
系统设计的另一重要部分便是“数据库规划”。目前大部分的程序或网站，在运行时因存储数据之便，均需搭配数据库运行。而数据库的架构（称为Databaseschema），便是设计文件中最重要的部分。所有程序的编写、运行、日后维护也均需参考这部分，因此需细心编写规划。
规划数据库架构是一门专门的学问，在此仅提出几项原则以供参考。
l 在创建数据库架构前，必须针对系统内会运用到的所有数据库功能，进行完整的整理。并列出会使用到的字段和表格，确认字段关联性之后，再开始设计数据库架构。
l 所有数据表名称、字段名称等，需完全用英文和数字命名（最好统一均为大写或均为小写）。
l 每一数据表务必创建一个唯一（Unique）的序号（Serial）字段，用来正确无误地区分出每一条数据，通常这样的字段，我们会用自动增加功能（auto_increment）定义，使其可自动累计。
l 数据库规划需考虑到未来的扩增需求，例如电话号码目前以11位数字记载便已足够，但考虑到未来的需求（如增码、分机、速拨功能等），则通常应以15到20位才能满足未来扩增的需求。
因数据表名称、字段名称均以英文命名，因此每一表格、每一字段的定义与说明，便是SD文件中数据库规划所重点强调的部分，范例3-5列出了一标准的数据表。
X章Y节：公司部门表
数据表代号:com_dept
数据表定义:公司部门表
操作方式:添加/删除/修改/查询
权限：root
使用的索引
索引字段
类型
Primary Key
serial
int unsigned
Unique Key
id
int unsigned
字段代码
字段名称
NULL
内部类型
长度
备注
serial
数据序号
N
int unsigned
10
自动产生序号
id
部门代码
N
int unsigned
10
0～1
name
部门名称
N
Varchar（30）
30
中文字符
manager
部门负责人
N
Varchar（20）
20
中文字符
tel
部门电话
N
Varchar（30）
30
0～1
mobile
部门手机
Y
Varchar（30）
30
0～1
fax
部门传真
Y
Varchar（30）
30
0～1
addr
部门地址
Y
varchar（300）
300
中文字符
status
公司状态
Y
varchar（30）
30
memo
备注
Y
varchar（100）
100
范例3-5 公司部门表
数据表设计的第一部分，便是说明这种表格的名称及其代表的意义。同时也需标示出可操作的权限（添加/删除/修改/查询等）与可执行这些操作的账号。
第二部分便是此数据库所使用到的索引及关联，需标出其索引的类型和字段的类型。如有必要，也可将关联到的目的表格字段标出。
第三部分便是每一个数据字段的说明，叙述如下：
l 字段代码：字段的实际名称（需完全用英文与数字命名，最好统一均为大写或均为小写）。
l 字段名称：用中文编写，字段的实际意义。
l NULL：可否为NULL。Y表示可为NULL，N表示不可为NULL。
l 内部类型：这种字段的数据类型。
l 长度：数据字段长度。
l 备注：说明这种字段的特性，例如自动创建序号、允许输入的字符或代码所表示的意义等，均可在此列出。
以下是另一个数据表，如范例3-6所示。
X章Y节：员工账号及数据表
数据表代号：com_usr
数据表定义：公司员工系统账号
操作方式：添加/删除/修改/查询
权限：root
使用的索引
索引字段
类型
Primary Key
serial
int unsigned
Unique Key
id
varchar(20)
字段代码
字段名称
NULL
内部类型
长度
备注
serial
数据序号
N
int unsigned
10
自动产生序号
id
用户账号
N
Varchar（20）
20
0～1,a～z,A～Z,_
pwd
用户密码
N
Varchar（20）
20
默认
name
用户姓名
N
Varchar（20）
20
中文字符
comid
所属公司代码
N
int unsigned
10
对应com.id
com
所属公司名称
N
Varchar（50）
50
中文字符
orgid
所属部门代码
N
int unsigned
10
对应com_dept.id
org
所属部门名称
N
Varchar（30）
30
中文字符
title
职称
N
Varchar（50）
30
中文字符
sex
性别
N
Varchar（50）
2
男、女
bir
生日
Y
Date
0000-00-00
tel
市内电话
Y
Varchar（30）
30
0～1
mobile1
手机（第一组）
N
Varchar（30）
30
0～1
mobile2
手机（第二组）
Y
Varchar（30）
30
0～1
addr
居住地址
Y
Varchar（300）
300
中文地址
email
电子邮件
Y
Varchar（150）
150
status
任职状况
N
Varchar（30）
30
在职、离职、休假
memo
备注
Y
Varchar（100）
100
范例3-6 员工账号及数据表
如果要使用数据表中某个字段的使用代码，则势必要有另一张代码表提供对照。例如员工账号数据表中的orgid（部门代码），便需对应到com_dept（部门信息表）的id字段，这种信息也可在备注中说明。
SD文件中，除了“工作流程”与“数据表架构”外，也可补充其他有助于团队成员进一步了解项目架构的章节，例如：整体系统架构、模块说明、组件说明、公共函数库说明、使用手册等。
再一次强调，系统设计（SD）文件主要用作开发团队内部沟通与协调。因此，编写这种文件时，让开发团队内的成员都能了解是最重要的。 重点整理
系统设计主要分两部分文件，第一部分是“工作流程”，也就是流程图；第二部分为“数据库规划”，要设计出数据表。
3.2.4 程序开发（Implementation）
在完成系统设计（System Design）文件后，项目成员便可依照SD文件中所述的各项目分别进行程序编写工作。一个合格的程序员，应具备在阅读SD文件中所述的流程与数据结构后便能够编写程序的能力。
在程序开发阶段，各项目成员依然需要有定期的项目会议，通过会议来协调程序或文件需要修改的部分，也可掌控成员间的进度。
在程序编写期间，有几点注意事项：
l 如在程序开发会议中，对文件（SA、SD及其他）有所修订，则在会议结束后，务必更新文件版本并清楚标明，并且确保项目成员均得知这种信息。
l 程序代码在每一模块完成后，均须进行单元测试与集成测试，不可等到所有程序都完成后，才在集成测试阶段进行测试。
l 程序代码必须由专人管理，并妥善整理各个版本。建议可采用CVS（ConcurrentVersions System）管理程序代码，务必确定各项目成员所使用或维护的程序为最新版本。
l 共用组件必须由专人管理，并妥善整理各个版本。建议共用组件应在程序编写初期便制作完成，并提供组件使用说明。除非必要，尽量不要在程序开发期间，变更共用组件的函数或定义，以免造成程序代码需大幅变更的后果。
l 需定期（每日一次为最低要求）异地备份程序代码，并注明该版程序的进度，以备不时之需。其他编写程序时应注意的相关事项，请参考该程序的相关参考书籍。 重点整理
在完成系统设计（SystemDesign）文件后，项目成员便可依照SD文件中所述的各细节分别进行程序编写工作。
3.2.5 集成及测试（Integration and Testing）
其实，集成测试阶段与程序开发阶段是密不可分的。每一程序组件和每一功能模块在编写完成后，均需进行单元测试，以有利于问题提早发现并解决。万万不可待所有程序完成后再开始测试。
当所有程序编写完成后，通常需根据“测试计划”与“营运计划”进行一次完整的软件测试，一个完整的测试至少应包括以下几点：
l 正常流程运行测试
l 异常状况测试
l 压力测试
l 最大处理能力测试
l 调试能力测试
l 入侵测试
l 自动恢复机制测试
l 备份机制测试等
另外，如与其他系统相互连接，如金融系统、银行后端、信用卡后端等，也需进行完整的集成测试。
所有的测试开始之前，均需编写“测试计划”，并依测试计划准备相关测试数据与测试用软件，并详细记录测试过程与测试结果。
集成测试是相当重要的一个步骤，完善的集成测试可以确认系统的漏洞、缺失与其极限所在，可让系统正式启用后的缺陷减到最少。 重点整理
每一程序组件和每一功能模块在编写完成后，均需进行单元测试。
当所有程序编写完成后，通常需根据“测试计划”与“营运计划”进行一次完整的软件测试。
IP卡
狗仔卡
重点整理
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡