软件开发项目规划时，SA、SD与SE的区别与重要性
做软件开发项目规划时, 常会碰到助理问我一个问题, 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执行以下的工作：
? 藉由系统需求书, 使用者的现有标准作业流程来建立出符合期望的新作业流程及搭配流程的系统功能及模块规划
? 依据功能及模块规划案, 定出初步的数据库内容及系统与使用者间的权限搭配规范
? 定出各个软件零件的规范, 如对象, 函数库, ...等等
? 设计新的标准作业流程, 并把系统功能或模块绑入这些流程中
? S.A依据客户的环境及需求, 寻找合适的SD来搭配
而SA也有以下的特色：
? 对于系统在怎样的环境及用什么开发工具, 并不十分在意, 良好的S.A产生出来的文件, 使用不同的开发工具都应该可以完成, 产生相同的结果, 但那一种最合适, 由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项目跟这个没有关系呢 ?
当然, 虽然SE是到处都吃得开, 但相对的也是项目里面最沉默及少有声音的一群。他们的工作基本上就是建构出一个可以执行系统的环境, 系统要如何展现, SE可以给SA和SD一些建议, 但建议时机通常都是在系统运行出了些非系统可以掌握的问题后。
系统工程师基本条件上, 和SD最为接近, 但有一点不同, 就是不需要有很好的软件开发经验, 也就是不太需要会写程序。但要对操作系统, 服务器系统, 网络运用环境有相当程度的了解。
SE通常是三者中最为博学一员, 好的SE虽然不一定要程序写的呱呱叫, 但却不能对编程一无所知, 对操作系统及开发工具也要有一定的熟悉度, 甚至部份网管有关的工作也要有所涉猎, 所以算得上是项目里的万金油。
在项目里, SE所要执行的工作如下：
? 规划及建置系统执行环境
? 安装及设定使用者端环境
? SERVER安装及设定
? 提供环境设置竟见给SA及PM
? 最佳化系统可靠度及效度
? 撰写可靠度及效能测试计划书
? 对计算机及相关外围设备有一定熟悉度
而一名SE则有下列基本要求：
1. 至少熟悉一种操作系统, 尤其是让系统的设定及微调等相关技术
2. 至少熟悉一种网络服务器操作系统, 对如何设定及最佳化熟悉
3. 曾任软件工程师职务一年以上或熟悉一种开发工具
4. 对网络环境有一定的认识, 尤其是一些通讯设置
5. 熟悉可靠度及效能的评估方法, 并了解与系统环境相关之设定
基本上, 如果拥有了像SD一样的技术背景及个性, 但在美学上实在令人不敢恭维, 那么SE算是极佳的选择了。一般而言, SE的下一个生涯规划, 会比较偏重于技术性兵种, 像是DBA或是网管, 对于IT产品比较有狂热或爱好的人, SE是极佳的出路。
[在项目中的运用时机]
基本上SE是万金油, 只要是IT的案子里就一定要塞一个SE进去, 因为没有IT项目不需要使用工程技术的, 差别只在使用何种工程技术而已。在软件包的导入项目里, SE负责处理软件使用环境, 解决非系统性问题, 安置及调整数据库和网络环境, 然后安装启动。所有系统运行所需要的条件, 都要由SE来解决和处理, 但这些工作全都不会出现在众人的面前, 但却又重要无比, 算得上是幕后的英雄。
会同时运用到SA,SD及SE的项目, 还是以客制化开发为主的。
在开发型项目里, SA团队要负责初期的需求调查及整体架构的规划, 将所有的系统开发工作内容转化成井井有条的文件, 并且适度的分割及派送, 并确保未来这些被分割的开发结果能够在未来可以正确运作。
SD则在SA的文件中去寻求系统呈现的一致性, 易用性及保证开发工具可以正确无误的展现SA的要求结果。所以SD要负责操作界面的外观设计, 订定一致的展现规范, 设计系统操作画面及操作手顺, 同时配合SA完成系统开发文件。基本上, 开发文件中, 是包含系统使用手册初稿的。
SD在设计时, 必需与SA充分配合, 以确保设计的系统符合需求及运作要求。
除了上述的工作内容外, 这三者都要撰写测试计划, 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执行以下的工作：
? 藉由系统需求书, 使用者的现有标准作业流程来建立出符合期望的新作业流程及搭配流程的系统功能及模块规划
? 依据功能及模块规划案, 定出初步的数据库内容及系统与使用者间的权限搭配规范
? 定出各个软件零件的规范, 如对象, 函数库, ...等等
? 设计新的标准作业流程, 并把系统功能或模块绑入这些流程中
? S.A依据客户的环境及需求, 寻找合适的SD来搭配
而SA也有以下的特色：
? 对于系统在怎样的环境及用什么开发工具, 并不十分在意, 良好的S.A产生出来的文件, 使用不同的开发工具都应该可以完成, 产生相同的结果, 但那一种最合适, 由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项目跟这个没有关系呢 ?
当然, 虽然SE是到处都吃得开, 但相对的也是项目里面最沉默及少有声音的一群。他们的工作基本上就是建构出一个可以执行系统的环境, 系统要如何展现, SE可以给SA和SD一些建议, 但建议时机通常都是在系统运行出了些非系统可以掌握的问题后。
系统工程师基本条件上, 和SD最为接近, 但有一点不同, 就是不需要有很好的软件开发经验, 也就是不太需要会写程序。但要对操作系统, 服务器系统, 网络运用环境有相当程度的了解。
SE通常是三者中最为博学一员, 好的SE虽然不一定要程序写的呱呱叫, 但却不能对编程一无所知, 对操作系统及开发工具也要有一定的熟悉度, 甚至部份网管有关的工作也要有所涉猎, 所以算得上是项目里的万金油。
在项目里, SE所要执行的工作如下：
? 规划及建置系统执行环境
? 安装及设定使用者端环境
? SERVER安装及设定
? 提供环境设置竟见给SA及PM
? 最佳化系统可靠度及效度
? 撰写可靠度及效能测试计划书
? 对计算机及相关外围设备有一定熟悉度
而一名SE则有下列基本要求：
1. 至少熟悉一种操作系统, 尤其是让系统的设定及微调等相关技术
2. 至少熟悉一种网络服务器操作系统, 对如何设定及最佳化熟悉
3. 曾任软件工程师职务一年以上或熟悉一种开发工具
4. 对网络环境有一定的认识, 尤其是一些通讯设置
5. 熟悉可靠度及效能的评估方法, 并了解与系统环境相关之设定
基本上, 如果拥有了像SD一样的技术背景及个性, 但在美学上实在令人不敢恭维, 那么SE算是极佳的选择了。一般而言, SE的下一个生涯规划, 会比较偏重于技术性兵种, 像是DBA或是网管, 对于IT产品比较有狂热或爱好的人, SE是极佳的出路。
[在项目中的运用时机]
基本上SE是万金油, 只要是IT的案子里就一定要塞一个SE进去, 因为没有IT项目不需要使用工程技术的, 差别只在使用何种工程技术而已。在软件包的导入项目里, SE负责处理软件使用环境, 解决非系统性问题, 安置及调整数据库和网络环境, 然后安装启动。所有系统运行所需要的条件, 都要由SE来解决和处理, 但这些工作全都不会出现在众人的面前, 但却又重要无比, 算得上是幕后的英雄。
会同时运用到SA,SD及SE的项目, 还是以客制化开发为主的。
在开发型项目里, SA团队要负责初期的需求调查及整体架构的规划, 将所有的系统开发工作内容转化成井井有条的文件, 并且适度的分割及派送, 并确保未来这些被分割的开发结果能够在未来可以正确运作。
SD则在SA的文件中去寻求系统呈现的一致性, 易用性及保证开发工具可以正确无误的展现SA的要求结果。所以SD要负责操作界面的外观设计, 订定一致的展现规范, 设计系统操作画面及操作手顺, 同时配合SA完成系统开发文件。基本上, 开发文件中, 是包含系统使用手册初稿的。
SD在设计时, 必需与SA充分配合, 以确保设计的系统符合需求及运作要求。
除了上述的工作内容外, 这三者都要撰写测试计划, SA着重在于数据的流动符合原先规划的顺序及结果测试, SD则着重在操作画面中的防呆测试及操作接口的正确性, 而SE则在系统可靠度上进行规划。
