|
|
按照正常情况，软件开发项目的流程大致可分为“需求”、“分析”、“程序编写”、“集成”、“测试”等阶段，整个开发团队也是按照这个流程组合而成的，所有工作方能顺序进行。这种最常见的模式被称为“瀑布式（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 软件模块说明
清楚软件架构后，便是对每一模块的细节进行说明。诸如这种模块的名称、数据表、公共程序、所提供的功能等，均需在此以表格方式详细列出。若表格列出不够完整，可以在下方补述。
这部分牵涉到客户需求与后续估价，因此列举得越详细越好，以下列举数例。
【通讯录模块】
功能名称
| 数据库
| 程序
| 网页功能
| 通讯录
| 个人信息
| | 查看信息
|
|
| 人员权限管理AP
| 修改信息
|
|
| 版主管理AP
| 删除信息
|
|
|
| 查询通讯录
|
|
|
| 信息检索
|
|
|
| 管理功能
|
|
|
|
|
|
范例3-1 通讯录模块 【功能说明】
通讯录提供会员在线通讯录，依用户权限不同，提供查看、修改、删除通讯录项目等功能，以条件表达式进行在线查询与全文检索，同时提供完备的管理功能。
【讨论区】
功能名称
| 数据库
| 公共程序
| 网页功能
| 讨论区
| 讨论区
| 讨论区访问AP
| 添加讨论版
|
|
| 人员权限管理AP
| 删除讨论版
|
|
| 文件管理AP
| 修改讨论版
|
|
| 版主管理AP
| 添加主题
|
|
|
| 删除主题
|
|
|
| 修改主题
|
|
|
| 添加留言
|
|
|
| 删除留言
|
|
|
| 修改留言
|
|
|
| 表达式检索功能
|
|
|
| 文件上传功能
|
|
|
| 文件删除功能
|
|
|
| 实用工具功能
|
|
|
| 管理功能
|
范例3-2 讨论区模块 【功能说明】
讨论区为会员提供各种事务讨论的空间，依使用者权限不同，提供添加、删除与修改讨论区；添加、删除与修改主题；添加、删除与修改留言等功能。除文字留言外，还可上传图片或文件以供分享，并提供条件式检索，还可自定义讨论区文章链接至个人的链接中，方便日后查阅，同时也提供完备的版主管理功能。
l 项目开发计划
在对整个软件模块都有共识后，即可讨论软件开发计划。这部分通常以甘特图表示。需列出开始日期与结束日期，每一项目所需时间以及每一个检查点或里程碑（Mile Stone），以下是几个开发计划范例。
二手教科书管理系统项目时间起于2005年10月8日，止于2006年1月15日，共计三个月。
| | 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 9
| 10
| 11
| 12
| 13
| 14
| 系统分析/设计
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 系统分析文件书写
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 开发平台安装
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 数据存档
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 网页/应用程序开发
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 系统测试
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 系统发表
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
范例3-3 二手书网站开发日程 班级入口网站第一期项目起于2004年4月12日，止于2004年5月24日，共计7周。
| | 1
| 2
| 3
| 4
| 5
| 6
| 7
| 8
| 系统分析/设计
|
|
|
|
|
|
|
|
| 开发平台安装
|
|
|
|
|
|
|
|
| 应用程序开发
|
|
|
|
|
|
|
|
| 网页开发
|
|
|
|
|
|
|
|
| 系统测试
|
|
|
|
|
|
|
|
| 程序封装
|
|
|
|
|
|
|
|
| 文件制作
|
|
|
|
|
|
|
|
|
范例3-4 班级入口网站日程规划 要注意的是，如果项目要分期（第一期、第二期），甚至另有维护合约或保固合约等状况，则甘特图需延长或以数张甘特图表示。
l 交付项目
在此须详细列出项目完成时应交付给客户的产品清单，以表格列出以便于日后提交。也可指明项目应以何种形式提交（光盘、文件、原始文件或执行文件）。
在此须注意，交付项目应与估价相配合，例如：原始设计文件是否交付，若需要交付，其估价将大为不同。且此项目即为日后提交付款的依据，务必准确无误。
l 经费预估
经费的估计依项目难度、功能多少、自定义程度、美工设计、版型绘制、Logo制作等各有不同，不同地区、不同行业的软件开发费用也有不同，不可一概而论。在此仅指出几个要点：
依功能计价（可依软件模块功能一一计价，用于动态网站）。
依网页类型与数量计价（较常用于静态网站）。
美工通常另外计价（包括配色、版面、Logo、动画等）。
除执行文件外，客户如需软件源代码，则需另外计价。
如客户需要设计文件（SD），则需另外计价。
如有安装、维护、保固需求，则需另外计价。
如需协助数据输入（打字等），则需另外计价。
通常估价会在数次系统分析会议后，与客户协调出一个双方都能接受的价位，因此估价需有相当的经验与技巧才行。
因为SA文件是开发团队与客户的主要沟通文件，因此每次会议后变更的SA文件，均需明确加注版本号码（封面及每页的页首），并送交双方确认，以确保双方达成共识。
而最后定案的SA文件，需有三份备份文件，由客户、开发团队及公正第三者各执一份并盖章生效。通过这些交互验证程序，来确保双方共识无误与相互履行职责。
除了合约之外，SA文件便是双方最重要的公认文件，因此在编写、讨论、定稿等过程中切不可马虎和疏忽。
重点整理
系统分析通过编写系统分析文件（以下简称SA）与召开系统分析会议等步骤，将软件蓝图描绘得更清楚。
3.2.3 系统设计（System Design）
在系统分析完成后，项目团队与客户之间，应该已经达成一定的共识。接下来要进行的便是依据系统分析中客户所提出的要求，开始设计项目细节，也就是创建系统设计文件。
要注意的是，系统设计文件通常是由Project Leader（项目领导人）编写的，用途为创建所有项目成员在程序开发时的共识，也即所有开发细节均需记录在系统设计文件中，以方便项目成员彼此间的工作分配、共用组件、模块编写等协调工作。
项目细节主要分两部分，第一部分是“工作流程”；第二部分为“数据库规划”。
工作流程主要是将SA文件中所提及的功能模块，依实际运行状况，绘制其流程图。以一般流程图绘制方式绘制即可，也可使用UML（UnifiedModeling Language）绘制。因为流程图是项目成员之间沟通的重要媒介，所以最重要的是：所有项目成员均要看得懂。
流程图通常以功能模块作为绘制时的区分，如功能模块之间有相互关系，也可绘制另一流程图表示，以下是几个流程图的示例，如图3-5～图3-8所示。
图3-5 二手书拍卖网站书籍订购流程图 图3-6 班级入口网站公告模块流程图 
图3-7 漫画租借网站服务选择流程图 图3-8 二手书拍卖网站会员注册与登录流程图 系统设计的另一重要部分便是“数据库规划”。目前大部分的程序或网站，在运行时因存储数据之便，均需搭配数据库运行。而数据库的架构（称为Databaseschema），便是设计文件中最重要的部分。所有程序的编写、运行、日后维护也均需参考这部分，因此需细心编写规划。
规划数据库架构是一门专门的学问，在此仅提出几项原则以供参考。
l 在创建数据库架构前，必须针对系统内会运用到的所有数据库功能，进行完整的整理。并列出会使用到的字段和表格，确认字段关联性之后，再开始设计数据库架构。
l 所有数据表名称、字段名称等，需完全用英文和数字命名（最好统一均为大写或均为小写）。
l 每一数据表务必创建一个唯一（Unique）的序号（Serial）字段，用来正确无误地区分出每一条数据，通常这样的字段，我们会用自动增加功能（auto_increment）定义，使其可自动累计。
l 数据库规划需考虑到未来的扩增需求，例如电话号码目前以11位数字记载便已足够，但考虑到未来的需求（如增码、分机、速拨功能等），则通常应以15到20位才能满足未来扩增的需求。
因数据表名称、字段名称均以英文命名，因此每一表格、每一字段的定义与说明，便是SD文件中数据库规划所重点强调的部分，范例3-5列出了一标准的数据表。
数据表代号: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卡
狗仔卡
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡