软件开发项目规划时SASD与SE的区别与重要性精修订

软件开发项目规划时S A S D与S E的区别与

重要性

SANY标准化小组 #QS8QHH-HHGX8Q8-GNHHJ8-HHMHGN#

做软件开发项目规划时, 常会碰到助理问我一个问题, SA,SD和SE的差别在那里

这个问题我以前也有过, 还颇为困扰, 系统分析和系统设计及系统工程到底有什么差别 SA和SD的工作又有何不同这两者的养成教育又有何差异在过去, SA,SD及SE的确很难区分, 甚至这些角色常常会透过软件工程师来混合发展。随着IT领域的发展, SA,SD及SE渐渐的成为了大型项目必需要的专业分工, 这三者间是有相当的差异的, 不管是养成过程, 甚或是未来的发展, 都大相径庭, 而要成为一名称职的PM, 是要能区分出这三者的差异, 才能妥善的安排工作的。

[SA System Analysis,系统分析师]

SA是 System Analysis 的缩写, 一般称为系统分析, 主要的工作就是透过一系列的分析工作, 把客户想要的结果产生方式, 以各种文件表达出来, 让开发团队可以根据这些文件实作出这个结果。

这样的解释比较文绉绉一点, 用个通俗一点的方式比喻, 就像是要做出一道宫保鸡丁时, 就会有食谱一样, 里面会介绍需要的材料及做菜的顺序, 然后里面也会强调要以怎样手法才能产生出某种效果, 以促进色香味。

这样的过程里, SA是较为偏重于在工作流程和处理逻辑的, 透过SA, 开发团队才可以理出整个系统的架构, 一种做事的脉络, 以及系统和工作间的关连性, 最重要的, 是这些结果都会被SA呈现在文件中, 而非放在少数人的脑袋里。

SA不仅止是要针对计算机里的东西去运作及规划, 还包括了现实世界里的实体流程及组织。在很多的情

况下, 配合新系统的组织及流程, 是要由SA来执行的。总结起来, 在一个开发案里, SA执行以下的工作：

藉由系统需求书, 使用者的现有标准作业流程来建立出符合期望的新作业流程及搭配流程的系统功能及模块规划

依据功能及模块规划案, 定出初步的数据库内容及系统与使用者间的权限搭配规范

定出各个软件零件的规范, 如对象, 函数库, ...等等

设计新的标准作业流程, 并把系统功能或模块绑入这些流程中

依据客户的环境及需求, 寻找合适的SD来搭配

而SA也有以下的特色：

对于系统在怎样的环境及用什么开发工具, 并不十分在意, 良好的产生出来的文件, 使用不同的开发工具都应该可以完成, 产生相同的结果, 但那一种最合适, 由SD决定

SA偏重于流程及执行逻辑的表达

SA着重于软件逻辑, 对开发工具的学习并不是十分重要, 所以会一种语言即可, 主要是以该语言工具来实践逻辑观。

SA一定要有全局观, 也就是不能拘泥于一个角度或是一个局部去思考问题, 这一点是寻找优秀SA时最

困难的。因为在规划模块及功能时, 一定要同时考虑到所有直接相关及间接相关的程序及逻辑问题, 因此要有全局观。

相较于SD, SA更侧重在逻辑及工作顺序搭配的表达, SA并不需要去关切使用什么操作系统或是什么开发工具, 如前特色所述, 好的SA文件, 可以用任何一种开发工具来实现。当然, SA不受限于IT技术, 但

却会有专业领域的限制。

很少有SA同时专精于数个领域的, 熟悉汽车业运作规范的SA, 在金融业的开发案里, 就很难讨好, 反之亦然。但SD没有这种限制, 基本上SD可以和任何行业的项目开发团队配合运作。

会如此的原因是SA是偏重于流程及管理分析及重新再造工作的。而作业流程, 除了少数领域里共通性高, 在核心流程上, 是需要长期钻研的。前面提及的汽车及金融业就是一例。

所以, 一个SA必需具备以下的能力,资历及专业训练：

1. 至少熟悉一种程序开发语言

2. 熟悉软件工程, 对于开发工具的元素及特色熟悉

3. 对管理制度或作业流程设计熟悉

4. 熟悉UML或类似的系统描述工具

5. 逻辑能力良好

6. 良好的沟通能力, 主要作为了解需求之用

7. 相关的业界熟悉度

在三者之中, SA是最接近PM的, 所以SA在做生涯规划时, 不妨以PM做为下一个发展的专业目标。

[SD Systems Designer, 系统设计师]

一般来说, SD在生涯规划里, 并不是SA或是PM。当然, 一定要硬来一次也没有什么不可以, 但要走这条路, 就要趁早转职, 因为SD毕竟是较为幕后的工作, 在与客户的沟通协调上, 并不会有太高的要求, 也较不需要公司管理层面的全局观。

表面上看起来, SD没有SA那么多的工作要求, 但实际上SD是最需要天赋的工作, 不管是画面的构成,

操作的手顺及调整, 甚至于组件的定义及对象的规范, 全都需要一些天赋。很多软件, 功能很强, 但怎么看怎么不顺眼, 或者怎么用就怎么憋扭, 功能带来的效益, 全都被这些毛病给遮盖掉了, 这就是SD的问题。

另外, SD也扮演了系统最佳化的推手。SA所规划出来的要求及布置, 都只是逻辑上的构思, 在不同的工具上, 可能有更好的方法可以表现, 也可能会难以展示, 这都需要藉由SD对使用环境及开发工具的了解, 来进行调整和规划。

举例来说, 同样是一套财务软件, 在WINDOWS XP, MAC, X WINDOWS下, 就会有很不一样的展现模式和技巧。如果再搭配上不同的开发工具, 如C++, JAVA, .NET, PHP, ...那差异更多。对SA而言, 这些东西

他都不用去考虑, 但SD就不同了, 这些不同的地方, 并不仅仅只是如此而已, 有时还会包括了开发成本及时间问题, SD的重要度, 由此可知。

在一个客制化项目里, SD的工作内容如下：

设计画面元素规范

设计页面结构及规则

设计系统操作画面, 并编定字段规范及防呆处理

设计权限管理与系统操作机制

撰写使用手册

调整DB之各项定义, 使其符合画面字段规范及操作搭配

配合SA撰写系统开发文件, 供程序员CODING之用

撰写UI(使用者接口)测试计划书

而做为一名称职的SD, 以下的条件, 是必要的：

1. 至少对一个操作系统极为熟悉, 对于这个操作系统的各个组件特性及API, 有充分的了解

2. 熟悉2种以上的开发工具, 而项目所需的工具, 必需是其擅长的之一, 其熟悉度包含了标准安装里的各个函数库, 系统常数, 对象定义, 语法, 主要的辅助工具开发厂商, 及重要的工具使用方法

3. 具一定的美学感

4. 至少能使用一种绘图工具软件

5. 曾经担任职业软件工程师三年以上

可以这样说, SA给了系统灵魂和神经系统, SD则是给了系统躯体和外观, 两者的结合, 才能产生出正确, 美观又好用的系统。如果你觉得自己是个不太爱和太多人打交道的IT人, 又对使用者接口有那么点执着及天赋, 那么, SD绝对是适合你的好选择。

[SE Systems Engineer, 系统工程师]

就某种角度来看, SE对PM而言, 算是万金油, 只要做IT项目, 那就一定用得上, 差别只是要选那一个

专业的SE而已。系统建置安装要SE, 使用者环境要SE, 甚至到硬件选择及布建, 都要用到SE, 有什么

IT项目跟这个没有关系呢