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则在系统可靠度上进行规划。
<think>好的,我现在需要处理用户关于“SD规范”的查询,用户想了解SD规范在IT标准软件开发中的相关信息。首先,我需要明确SD在这里具体指的是什么。根据常见的IT术语,SD可能有多种含义,比如软件设计(Software Design)、系统设计(System Design),或者特定行业的标准,比如SAP的SD模块(Sales and Distribution)。但用户提到的是“规范”IT标准”,因此更可能指的是软件设计规范或相关标准。 接下来,我需要查阅用户提供的引用内容,看看是否有相关的信息。引用[4]提到了SASDSE在软件开发项目规划中的区别重要性,这里SD可能指系统设计(System Design)。引用[1]提到了BADI_SD_SALES_ITEM,这可能与SAP的SD模块相关,但用户的问题更偏向于规范标准,而不是具体的SAP模块。因此,可能需要综合多个引用内容来回答。 用户的问题涉及SD规范、IT标准软件开发,因此需要从软件设计的标准、流程以及相关规范入手。软件设计规范通常包括设计原则、文档标准、模块化设计、接口规范等。例如,引用[3]提到面向对象的设计原则,这可能与SD规范中的设计原则相关。此外,引用[4]中提到的SA(需求分析)、SD(系统设计)、SE(系统工程)的区别,说明SD在软件开发流程中的位置。 需要整理出SD规范的主要内容、在IT标准中的定位、以及在软件开发中的具体应用。同时,用户可能希望了解如何应用这些规范,以及相关的国际或行业标准,如ISO/IEC 12207、UML建模等。此外,结合引用[4],可以强调系统设计阶段的重要性,以及规范如何指导该阶段的工作。 最后,生成相关问题需要考虑用户可能的进一步需求,比如具体的设计方法、文档编写、实际案例等。需要确保问题覆盖规范的应用、实施挑战、与敏捷开发的结合等方面。</think>### SD规范在IT标准与软件开发中的解析 #### 1. **SD规范的定义与范畴** SD规范(System Design Specification)是软件开发过程中系统设计阶段的技术标准,用于明确系统架构、模块划分、接口定义及设计约束[^4]。其核心目标是确保软件系统满足功能需求的同时,具备可维护性、可扩展性安全性。例如,在面向对象设计中,SD规范会要求遵循**封装性****开放/封闭原则**(如引用[3]所述)。 #### 2. **SD规范的主要内容** - **架构设计**:定义系统分层(如MVC模式)技术选型(如微服务架构)。 - **模块化设计**:通过高内聚低耦合原则划分功能模块,如引用[1]中提到的`BADI_SD_SALES_ITEM`接口设计。 - **接口规范**:明确API格式(如RESTful)、数据交换标准(如JSON Schema)。 - **安全规范**:遵循如OWASP Top 10的安全设计原则,类似引用[2]中Android P对设备安全的强化要求。 - **文档标准**:要求输出UML图、ER图等设计文档。 #### 3. **SD规范与IT标准的关联** SD规范需符合国际或行业标准,例如: - **ISO/IEC 12207**:定义软件生命周期流程中的设计活动。 - **IEEE 1016**:软件设计描述标准。 - **企业级标准**:如Google的Android设计规范(引用[2])。 #### 4. **SD在软件开发中的实施** - **需求到设计的转化**:将SA(需求分析)阶段的用例转化为技术方案。 - **工具支持**:使用Enterprise Architect、Visio等工具实现UML建模。 - **代码落地**:通过设计模式(如工厂模式)编码规范(如PEP8)实现设计约束。 #### 5. **实际应用案例** 以SAP SD模块为例,其设计需遵循ABAP编程规范、接口增强标准(如引用[1]中的BADI扩展),并与物流模块(MM)集成,体现模块化设计思想。 ```plaintext 示例:SD设计文档结构 1. 系统架构图 2. 模块接口定义(输入/输出、协议) 3. 数据库ER图 4. 安全性设计(如权限控制模型) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值