SA, SD 및 SE

 

소프트웨어 개발 프로젝트를 계획 할 때 종종 어시스턴트가 질문을하는데 SA, SD, SE의 차이점은 무엇입니까?

이전에이 질문을 해본 적이 있는데 상당히 당혹 스럽습니다. 시스템 분석과 시스템 설계와 시스템 엔지니어링의 차이점은 무엇입니까? SA와 SD의 작업의 차이점은 무엇입니까? 두 교육 교육의 차이점은 무엇입니까? 과거에는 SA , SD 및 SE는 실제로 구별하기 어렵고 이러한 역할조차도 소프트웨어 엔지니어를 통해 혼합되는 경우가 많습니다.

IT 분야의 발전에 따라 SA, SD, SE는 점차 대규모 프로젝트에 필요한 전문 분업이되었으며, 개발 프로세스 든 미래 개발이든 크게 차이가 있습니다. 유능한 PM이되기 위해서는이 세 가지의 차이점을 구별 할 수 있어야 작업을 적절하게 준비 할 수 있습니다.

1. SA, 시스템 분석가

SA는 System Analysis의 약자로 일반적으로 시스템 분석이라고하며, 주요 업무는 일련의 분석 작업을 통해 고객이 원하는 결과를 표현하고이를 다양한 문서로 표현하여 개발팀이 실제로 이러한 문서를 기반으로 결과를 만들 수 있도록하는 것입니다. .

공 바오 치킨을 만들고 싶을 때 필요한 재료와 요리 순서를 소개하는 조리법이있는 것처럼 더 대중적인 은유법을 사용하여 좀 더 장황하게 설명합니다. 색과 향기를 촉진하기 위해 특정 효과를 만드는 방법.

이 과정에서 SA는 워크 플로우와 처리 로직에 더 초점을 맞추고 있으며, 개발팀은 SA를 통해 전체 시스템의 아키텍처, 작업을위한 컨텍스트, 시스템과 작업 간의 연결을 파악할 수 있습니다. 이러한 결과는 소수의 사람들의 머리가 아닌 파일로 SA에 의해 제공됩니다.

SA는 컴퓨터의 사물을 운영하고 계획하는 것뿐만 아니라 실제 세계의 물리적 프로세스와 조직도 포함합니다. 많은 경우 새 시스템과 협력하는 조직과 프로세스는 SA에 의해 실행됩니다. 요약하면 개발 사례에서 SA는 다음 작업을 수행합니다.

· 시스템 요구 사항 문서를 기반으로 사용자의 기존 표준 운영 절차를 통해 기대치를 충족하는 새로운 운영 프로세스를 만들고 시스템 기능과 일치 프로세스의 모듈 계획을 만듭니다. 기능 및 모듈 계획을
기반으로 예비 데이터베이스 콘텐츠를 결정하고 시스템과 사용자 간의 권한 일치에 대한 사양
· 개체, 기능 라이브러리 등과 같은 각 소프트웨어 구성 요소의 사양 을 결정합니다.
· 새로운 표준 운영 절차를 설계하고 시스템 기능 또는 모듈을 이러한 프로세스에 바인딩합니다.
· SA 기반 고객의 환경과 요구 사항에 적합한 SD 찾기

SA에는 다음과 같은 특성도 있습니다.
· 시스템에서 사용하는 환경 및 개발 도구에 크게 신경 쓰지 않습니다. 좋은 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을 개발의 다음 전문 목표로 간주하는 것이 좋습니다.

2. SD, 시스템 디자이너

일반적으로 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와 협력하여 프로그래머 코딩을위한 시스템 개발 문서 작성
· UI (사용자 인터페이스) 테스트 계획 작성

유능한 SD로서 다음 조건이 필요합니다.

1. 하나 이상의 운영 체제에 매우 익숙하고이 운영 체제의 각 구성 요소의 기능과 API를 잘 이해하고 있어야합니다.
2. 2 가지 이상의 개발 도구에 익숙하고 프로젝트에 필요한 도구가 좋은 점 중 하나 여야합니다. 친숙 함은 표준 설치의 다양한 함수 라이브러리, 시스템 상수, 개체 정의, 구문 및 주요 보조 도구 개발 공급 업체를 포함합니다. , 그리고 중요한 도구를 사용하는 방법
3. 특정 미학 감각을 가지고
4. 하나 이상의 그리기 도구 소프트웨어를 사용할 수 있습니다.
5. 전문 소프트웨어 엔지니어로 3 년 이상 근무

SA는 시스템의 영혼과 신경계를, SD는 시스템의 몸과 외모를 제공한다고 할 수 있으며,이 둘의 조합은 정확하고 아름답고 사용하기 쉬운 시스템을 만들어 낼 수 있습니다. 당신이 너무 많은 사람들을 대하는 것을 좋아하지 않고 사용자 인터페이스에 약간의 끈기와 재능이있는 IT 전문가라고 생각한다면 SD는 확실히 당신에게 좋은 선택입니다.

3. SE, 시스템 엔지니어

어떤 관점에서 보면 SE는 PM의 만병 통치약입니다. IT 프로젝트를 수행하는 한 확실히 유용 할 것입니다. 유일한 차이점은 어떤 전문가 SE를 선택 하느냐입니다. 시스템 구축 및 설치에는 SE가 필요하고, 사용자 환경에는 SE가 필요하며, 하드웨어 선택 및 배포에도 SE가 필요합니다. 이와 관련이없는 IT 프로젝트가 있습니까?

물론 SE는 어디에서나 먹을 수 있지만 프로젝트에서 가장 조용하고 거의 목소리를 내지 않는 그룹이기도합니다. 그들의 작업은 기본적으로 시스템이 실행될 수있는 환경을 구축하는 것입니다 .SE는 시스템을 표시하는 방법에 대한 몇 가지 제안을 SA 및 SD에 제공 할 수 있지만 제안 타이밍은 일반적으로 시스템이 처리 할 수있는 문제가 소진 된 후입니다.

기본 조건에서 시스템 엔지니어는 SD에 가장 가깝지만 좋은 소프트웨어 개발 경험이 필요하지 않다는 점, 즉 프로그램을 작성할 필요가 없다는 점에서 차이가 있습니다. 그러나 운영 체제, 서버 시스템 및 네트워크 운영 환경에 대한 상당한 이해가 필요합니다.

SE는 일반적으로 세 가지 중 가장 지식이 풍부한 구성원입니다. 좋은 SE는 프로그래밍 할 필요는 없지만 프로그래밍을 무시할 수 없습니다. 또한 운영 체제와 개발 도구, 심지어 일부 네트워크 관리자에 대해서도 어느 정도 익숙해야합니다. 관련 작업도 다루어야하므로 프로젝트에서 만병 통치약으로 간주 될 수 있습니다.

프로젝트에서 SE가 수행 할 작업은 다음과 같습니다.

· 시스템 실행 환경 계획 및 구축
· 클라이언트 환경
설치 및 설정
· SERVER 설치 및 설정 · SA 및 PM 환경 설정 제공
· 시스템 신뢰성 및 유효성 최적화
· 신뢰성 및 성능 테스트 계획 작성
· 컴퓨터 및 관련 주변 장치에 익숙 함

SE에는 다음과 같은 기본 요구 사항이 있습니다.

1. 하나 이상의 운영 체제, 특히 시스템 설정 및 미세 조정과 같은 관련 기술에 익숙합니다.
2. 하나 이상의 웹 서버 운영 체제에 익숙하고 구성 및 최적화 방법에 익숙합니다.
3. 소프트웨어 엔지니어로 1 년 이상 근무했거나 개발 도구에 익숙 함
4. 네트워크 환경, 특히 일부 통신 설정을 확실히 이해하고 있어야합니다.
5. 신뢰성 및 성능 평가 방법을 숙지하고 시스템 환경과 관련된 설정을 이해합니다.

기본적으로 SD와 동일한 기술적 배경과 성격을 가지고 있지만 미학이 실제로 아첨하지 않다면 SE는 탁월한 선택입니다. 일반적으로 SE의 다음 경력 계획은 DBA 또는 네트워크 관리와 같은 기술 분야에 더 중점을 둘 것이며, IT 제품에 더 열광적이거나 취미가있는 사람들에게 SE는 훌륭한 탈출구입니다.

4. 프로젝트에서 사용하는 경우

기본적으로 SE는 만병 통치약이며, 엔지니어링 기술을 필요로하지 않는 IT 프로젝트가 없기 때문에 IT 사례라면 SE가 포함되어야하며, 유일한 차이점은 사용되는 엔지니어링 기술의 유형입니다. 패키지 소프트웨어 가져 오기 프로젝트에서 SE는 소프트웨어 사용 환경 처리, 비 체계적인 문제 해결, 데이터베이스 및 네트워크 환경 설치 및 조정, 설치 및 시작을 담당합니다. 시스템 작동에 필요한 모든 조건은 SE가 해결하고 처리해야하지만, 이러한 작업 중 어느 것도 모든 사람 앞에 나타나지 않을 것이지만 매우 중요하며 배후의 영웅으로 간주 될 수 있습니다.

SA, SD, SE에 동시에 적용될 프로젝트는 여전히 맞춤형 개발을 기반으로합니다.

개발 프로젝트에서 SA 팀은 초기 수요 조사 및 전체 아키텍처 계획을 담당하고, 모든 시스템 개발 작업 내용을 잘 구성된 문서로 변환하고 적절하게 분할 및 발송하고 이러한 분할 된 개발 결과를 향후에 사용할 수 있도록합니다. 앞으로 제대로 작동합니다.

SD는 SA 문서에서 시스템 프레젠테이션의 일관성과 사용 용이성을 추구하고 개발 도구가 SA 요구 사항을 올바르게 표시 할 수 있도록합니다. 따라서 SD는 운영 인터페이스의 외관 디자인, 일관된 디스플레이 사양 공식화, 시스템 운영 화면 및 운영 절차 설계, SA와 협력하여 시스템 개발 파일을 완성합니다. 기본적으로 개발 파일에는 시스템 매뉴얼의 초안이 포함되어 있습니다.

SD는 설계시 SA와 완전히 협력하여 설계된 시스템이 요구 사항 및 운영 요구 사항을 충족하는지 확인해야합니다.

위의 작업 내용 외에도 테스트 계획을 작성해야합니다 .SA는 원래 계획된 순서 및 결과 테스트에 따른 데이터 흐름에 중점을두고, SD는 작업 화면의 오류 방지 테스트와 작업 인터페이스의 정확성에 중점을 둡니다. SE는 시스템 안정성을 계획합니다.

5. 소프트웨어 엔지니어는 언제 작업을 변경합니까?

프로그램을 작성하는 사람은 누구나이 작업을 평생 할 수 없다는 것을 마음 속으로 알고 있습니다. 육체적, 정신적 문제 만이 아니라 가장 중요한 것은 프로그램 작성이고 경제적 가치는 매우 제한적입니다.

프로그래머가 많다는 사실을 부정하지는 않겠지 만, 요점은 당신이 얼마나 좋은가가 아니라 얼마나 많은 사장님이 당신을 돌 보려는 노력에 비례하여 월급을 기꺼이 지불 하느냐입니다. 그런 일이없는 것이 아니라 드물고, 스트레스가 너무 많고 청춘을 너무 많이 소비하기 때문에 보통 이런 일을 빨리하게됩니다.

한발 물러 서면 그렇게 많은 비용을 지불 할 가치가 없습니다. 엔지니어는 좋은 SA 및 SD 계획을 통해 우연이 아니거나 사용자가 매우 만족하지 않는 한 일반 표준을 충족하는 한 소프트웨어 개발 요구의 90 % 이상을 해결할 수 있습니다. 관심이 있다면 다른 10 % 직업을 만날 기회를 갖기가 어렵거나, 그렇게하더라도 평생 동안 당신을 지원할 수 없을 것입니다.

소프트웨어 엔지니어는 언젠가 직업을 바꿀 것이며 이것이 그들의 운명입니다.

직업을 바꾸고 싶을 때 SA, SD, SE, 보스가되고 새 직업을 바꾸는 몇 가지 선택권이 있습니다. 많은 것 같지만, 밤 장면은 실제로는 암울합니다. 프로그래밍이 닫힌 방에서 작성되기 때문에 장기적인 자폐증의 결과로 직장을 바꾸고 싶을 때 밝은 미래의 경력에서 그들을 지원할 충분한 접촉을 갖기가 어렵습니다. 대부분의 사람들은 IT 직원의 높은 연봉에 감탄하지만 적절한 계획없이 돈을 지불하고 있으며 미래가 약하다는 사실을 모릅니다.

처음 5 개 옵션, 기본적으로 마지막 2 개는 상황을위한 것입니다. 소수의 사람 만이이 두 가지를 선택할 수 있습니다. 대부분의 소프트웨어 엔지니어는 여전히 처음 세 가지 중 하나를 선택하여 개발해야합니다.

SA는 가장 아름답게 보이고 미래에 최고의 잠재력을 가지고 있지만 불행히도 소수의 소프트웨어 엔지니어 만이이 직책에 적합합니다. 이 직업은 다른 사람들과의 관계를 필요로하기 때문에 좋은 소프트웨어 엔지니어는 보통 이것에 매우 나쁩니다.

그러므로 당신이 의사 소통에 능숙하다고 생각한다면, 3 명의 숙모와 6 개의 시가 당신의 동료이고, 좋은 논리적 기술을 가지고 있고, 경영에 관심이 있다면, SA는 당신에게 좋은 선택이며, 프로그래밍 기술은 당신의 고려의 초점이 아닙니다.

대조적으로, 당신은 사용자 인터페이스에 대해 매우 잘 알고 있고 미적 측면에서 동료들로부터 만장일치로 칭찬을 받았으며 프로그래밍 기술에 약간의 자신감을 가지고 있습니다. 당신은 IT가 아닌 사람들과 채팅하는 것을 싫어합니다. 그렇다면 SD는 당신의 최고입니다. 좋은 집.

마지막으로, 운영 체제, 개발 도구, 소프트웨어 및 IT 장비 등 IT의 세계가 매력으로 가득 차 있다는 느낌이 들기 때문에 사람들 사이의 접촉은 인생에서 가장 중요한 것이 아닙니다. 끝없는 IT 기술은 당신을 취하게 만들므로 SE는 확실히 당신의 첫 번째 선택입니다.

직업을 바꾸려면 모든 소프트웨어 엔지니어가 자신의 미래에 따라 어떤 직위를 선택하고 싶은지 정직하게 대면해야합니다. 이렇게 선택하면 직장에서의 개인적인 경험을 바탕으로 그러한 사람은 매우 빛을 발산하기도 어렵고 그가 기대했던 성과를 얻기도 어렵습니다. 따라서 현재 프로그램을 작성 중이고 전직을 원하는 엔지니어는 신중하고 정직하게 대면하여 적절한 선택을하시기 바랍니다.

6. 결론

위의 내용은 SA, SD 및 SE에 대해 혼란스러워하는 친구에게 개인적으로 제공되며 작업 할당의 기준 및 기준으로 사용됩니다. 이 세 가지의 출현은 실제로 현재 IT 기술의 급속한 성장에 기인하므로 점점 복잡 해지는 IT 환경에 대처하기 위해 소프트웨어 엔지니어링을위한 적절한 분업을 수행 할 필요가 있습니다.