소프트웨어 개발을 엔지니어링으로 간주 할 수 있습니까? 그렇지 않다면 공학 분야의 자격을 갖추기 위해 부족한 것은 무엇입니까? 이것과 관련하여 프로그래머와 소프트웨어 엔지니어의 차이점에 대한 Stack Overflow에 관한이 질문이 있습니다.
Carnigie Mellon University에는 CMMI 표준을 규정하고 유지하는 소프트웨어 엔지니어링 연구소가 있습니다. 이것이 개발을 엔지니어링으로 바꾸는 것입니까?
답변:
소프트웨어 개발 엔지니어링입니까? 그렇지 않다면, 자격을 갖추기 위해 부족한 것은 무엇입니까?
예, 소프트웨어 엔지니어링은 엔지니어링 분야입니다.
위키 백과는 엔지니어링을 "수학, 과학, 경제, 사회 및 실용 지식뿐만 아니라 구조, 기계, 도구, 시스템, 구성 요소, 재료를 발명, 혁신, 디자인, 구축, 유지, 연구 및 개선하기위한 응용 프로그램으로 정의합니다. , 프로세스, 솔루션 및 조직 "소프트웨어 엔지니어링의 결과는 사람들의 삶을 향상시킬 수있는 소프트웨어 시스템이며 과학, 수학, 경제, 사회 또는 실제 지식의 조합을 포함 할 수 있습니다.
학문적으로나 전문적으로 어떻게 보는가에 따라 다릅니다. 소프트웨어 엔지니어링 프로그램은 ABET에 의해 엔지니어링 프로그램으로 인증 될 수 있습니다 . 소프트웨어 엔지니어는 IEEE의 구성원이 될 수 있습니다. 어떤 회사는 소프트웨어 공학을 공학 분야라고 생각하지만, 그렇지 않은 회사도 있습니다.
이 주제에 관한 최고의 책은 Steve McConnell의 전문 소프트웨어 개발 : 짧은 일정, 고품질 제품,보다 성공적인 프로젝트, 향상된 경력 입니다. 소프트웨어 엔지니어링을 전문직, 기술에서 전문직으로의 진화, 소프트웨어 개발 과학, 소프트웨어 엔지니어링과 소프트웨어 엔지니어링 의 차이점 (엔지니어링 사례를 통해 소프트웨어를 개발하는 엔지니어와 소프트웨어에 엔지니어링 사례 적용) 포함 모교 ), 인증 및 라이센스 및 윤리.
글렌 밴더 버그 (Glenn Vanderburg) 2010 년과 2015 년 사이에 여러 회의에서 "실제 소프트웨어 엔지니어링"이라는 과 함께 "Craft, Engineering, and Essence of Programming"(2011 년부터 RailsConf의 기조 연설) 및 "Craft and Software Engineering"(2011 년 QCon London에서 제공). 이러한 논의는 소프트웨어 엔지니어링이 엔지니어링 분야 인 이유에 대한 매우 포괄적 인 주장이라고 생각합니다.
Vanderburg 자신의 회담에서 간단히를 제공 한 인수에 의해 만들어진 하나 의 소프트웨어 디자인과 소프트웨어 공학 설계 활동의 출력 코드가 얼마나 무엇에 (2005 년에 다시 재 방문) 1992 년 잭 W. 리브스 ( 이 또한 C2 위키에서 논의). 사양 및 모델링이 소프트웨어 설계이고 코드가 소프트웨어 설계 인 구식 사고 방식에서 벗어나면 소프트웨어 엔지니어링과 기타 엔지니어링 분야 간의 관계가보다 분명해집니다. 소프트웨어 개발의 경제성이 다른 많은 분야와는 크게 다르다는 것을 알면 약간의 차이와 그 차이에 대한 이유가 더욱 분명해집니다. 설계는 값이 싸고 (대부분의 경우 무료이며) 디자인은 비용이 많이 듭니다.
[CMMI]가 개발을 엔지니어링으로 바꿀 것입니까?
CMMI는 소프트웨어를 구축 할 때 어떤 종류의 활동이 유용한 지 조직에 지침을 제공하는 프로세스 개선 프레임 워크입니다. 엔지니어링 분야에는 일반적으로 엔지니어링 프로세스가 있습니다. 이러한 프로세스를 갖는 것은 고품질 프로젝트를 성공적으로 완료하는 데 중요합니다. 즉, CMMI (또는 다른 프로세스 프레임 워크 또는 방법론)는 단일 도구 일뿐입니다.이를 사용하면 개발자에서 엔지니어로 마술처럼 발전 할 수 없습니다. 그러나 어떤 종류의 프로세스를 따르지 않는 것은 엔지니어링 프로젝트가 아닌 프로젝트의 표시입니다.
또한 소프트웨어 엔지니어링 과정 / 인증서에 대한 귀하의 의견은 무엇입니까?
다른 사람들이 생각하는 것만 큼 가치가 있습니다. 유용한 코스가 있으며 쓸모없는 코스가 있습니다. 가치있는 인증서와 인쇄 된 용지 가치가없는 인증서가 있습니다. 교육 과정을 승인 또는 승인하는 사람, 현재 직업 산업에 대한 인증서를 현재 직업에 발급하는 사람 및 가고 싶은 곳 등 많은 요인이 있습니다.
일반적인 엔지니어링 배경에서 온 것이지만 소프트웨어 개발 분야에서 경력을 쌓으면서 두 세계간에 큰 유사점이 있습니다. 엔지니어링의 정확한 정의와는 별도로 소프트웨어 개발은 실제 제품 개발과 크게 다르지 않습니다. 적어도 나는 그렇게 다르지 않아야한다고 생각합니다.
항공기 또는 소프트웨어 응용 프로그램을 설계 할 때 다음을 수행해야합니다.
프로그래밍을 시작하기 전에 모든 것을 디자인하지 않기 때문에 소프트웨어 디자인이 다르다는 다른 대답의 어딘가를 읽었습니다. 실제로 실제 제품을 디자인 할 때도 마찬가지입니다. 설계 및 프로토 타이핑 및 테스트는 반복적 인 프로세스입니다.
또한 소프트웨어 프로젝트의 규모가 커지면 항공기와 같은 복잡한 제품을 설계하는 것과 유사한 명확한 하위 시스템, 구성 요소 및 인터페이스를 정의하는 것이 더욱 중요합니다.
이것이 제가 소프트웨어 개발을 엔지니어링으로 생각하는 이유입니다.
나는 실제로 소프트웨어 공학과 같은 것이 있다고 주장 할 것이다.
공학에는 과학적 지식을 체계적으로 적용하여 문제를 해결하는 것이 포함됩니다. 오늘날 다루어지는 문제의 복잡성은 전기 엔지니어가 제조 프로세스를 고안 할 때 회로 나 화학 엔지니어를 만들거나 장치를 만들 때 기계 엔지니어가 다루는 문제와 다르지 않습니다.
기존 계획 (이 경우 개발)을 적용하는 실질적인 접근 방식이 있다는 사실은 다른 분야에서 다른 사람이 해당 계획 (예 : 건설 노동자)을 실행한다는 사실과 유사합니다.
대부분의 개발자들도 소프트웨어 엔지니어링 작업을 수행하고 있으며 우리의 교육은 종종 프로그래밍이 아니라 소프트웨어 엔지니어링에 관한 것입니다. 그래서 우리는 손을 더럽 히지 만 토목 기술자는 그렇지 않습니다.
그러나 프로그래밍 언어와 프로그램을 적용 할 수있는 능력은 엔지니어로 변하지 않습니다. 현재 코드 외부의 복잡성과 문제에 대한 진정한 이해가 부족한 개발자들과 만났습니다.
CMU에 관한 귀하의 질문 : 표준 또는 관행의 적용 (예 : CMMI)은 개인의 작업을 엔지니어링으로 자동 전환하지 않습니다. 그러나 새로운 관행을 제공하기 위해 과학적 연구를 수행하는 조직이 있다는 사실은 다시 엔지니어링과 같은 것이 있다는 신호입니다.
아니요, 공학이 아닙니다. 우리는 과학적이지 않으며 이러한 상태 엔지니어링 테스트를 통과 할 필요가 없습니다. 사실, 테스트가 부족하여 어떤 곳에서 자신을 소프트웨어 "엔지니어"라고 부르는 것은 불법입니다.
IMHO라는 용어는 단지 '프로그래머'(생각이나 창의력이 거의없는 일부 기계적 프로세스의 색조가 있음)가 아니라 개발자가하는 일의 범위를 더 잘 설명하기 위해 만들어졌습니다.
개인적으로 저는 실용적인 프로그래머들에 의해지지받는 '직공'으로서 개발자의 새로운 비유를 선호합니다.
역사적으로 사람들은 소프트웨어 제작을 제조와 유사하게 만들려고 노력했습니다. Jack Reeves는 그의 기사 What Is Software Design 에서이 아이디어를 불신하게한다고 꽤 좋은 주장을했다고 생각 합니다.
위키에서 :
공학 :
소프트웨어 엔지니어링은 소프트웨어의 개발, 운영 및 유지 보수 에 체계적이고 체계적이고 정량화 가능한 접근 방식을 적용하고 이러한 접근 방식을 연구하는 것입니다. 즉, 엔지니어링을 소프트웨어에 적용하는 것입니다.
소프트웨어 개발
소프트웨어 개발은 소프트웨어 제품을 만드는 일련의 활동입니다. 소프트웨어 개발에는 연구, 새로운 개발, 수정, 재사용, 리엔지니어링, 유지 보수 또는 소프트웨어 제품을 초래하는 기타 활동이 포함될 수 있습니다. [1]
특히 소프트웨어 개발 프로세스의 첫 번째 단계에는 마케팅, 엔지니어링, 연구 개발 및 일반 관리를 포함한 많은 부서가 포함될 수 있습니다.
그것들은 꽤 비슷하며 같은 것을 의미 할 수도 있습니다.
Dictionary.com에서 : en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /
– 명사 1. 엔진, 교량, 건물, 광산, 선박 및 화학 공장의 건설과 같이 물리 또는 화학과 같은 순수 과학 지식을 실용적으로 적용하는 기술 또는 과학.
소프트웨어를 만드는 것은 수학과 컴퓨터 과학, 그리고 응용에 따라 다른 많은 순수 과학의 실질적인 응용이라고 할 수 있습니다.
[편집] FWIW, 나는 나 자신을 소프트웨어 엔지니어라고 부르지 않고 소프트웨어 개발자라고 부르기 때문에 개인적으로 관심이 없다.
제 생각에 소프트웨어 엔지니어와 소프트웨어 개발자는 서로 다른 두 가지입니다.
소프트웨어 엔지니어를 본다 등의 계획을 수행 하나를, 어떤 라이프 사이클 것입니다 개발 테이크 등 요구 사항 / 사양을하고 ... 기본적으로, 문서의 많은 소프트웨어 엔지니어를 다룬다. 이것은 소프트웨어 개발자 및 / 또는 프로젝트 관리자가 수행 할 수 있습니다.
소프트웨어 개발자 더 밀접 프로그래머로하지만, 데이터베이스 관리 등과 같은 다른 분야에서 더 능력과 관련이있을 것이다 ..
제기해야 할 흥미로운 것은 건축 입니다. 프로젝트 수명주기에 어떤 하드웨어 / 소프트웨어가 필요한지 알아내는 데 관여하는 사람.
나는 "아니오"로 갈 것입니다. 동생은 기계 엔지니어이며 공학을 "저렴한 기술"이라고 묘사합니다.
"엔지니어들은 가능한 한 적은 비용으로 가능한 가장 적은 비용으로 가능한 한 빨리 작업을 수행하는 데 더 많은 관심을 가지고 있습니다. "
이에 대한 반응으로 소프트웨어 개발 (소프트웨어 엔지니어링이 아니라 기본적으로 두 가지 다른 분야 임)을 "효율적인 기술"이라고 설명했습니다.
"개발자들은 가능한 한 가장 적은 비용으로 가장 적은 반복 횟수 로 가능한 한 빨리 작업을 수행하는 데 더 많은 관심을 가지고 있습니다. "
차이점은 그 문장의 마지막 부분에 있습니다.
소프트웨어 개발 엔지니어링입니까?
엔지니어가된다는 것은 프로젝트가 원인과 결과 타임 라인을 따르는 것을 의미합니다. 건물 코드를 따르므로 건물이 무너지지 않습니다. 소프트웨어 작성, 당신은가는 모든 지침을 따를 수 있습니다 (그리고 선택할 수있는 많은 다른 것들이 있습니다!). -효과적인 기능 언어).
엔지니어 (기계적, 구조적, 소프트웨어)는 이해 된 요구와 해당 요구를 수용하기 위해 재료를 적용하는 방법과 방법에 대한 이해를 바탕으로 제품을 설계하는 사람으로 간주합니다.
예를 들어, 구조 엔지니어가 강철의 다양한 강도를 찾고 물리 규칙을 적용하여 필요한 재료와 구현 방법을 계산하는 경우가 종종 있습니다. 구조 엔지니어링은 가장 좋은 예입니다. 빌드하기 전에 항상 빌드 할 계획의 청사진 (사양)으로 끝나기 때문입니다. 소프트웨어에서 항상 그런 것은 아닙니다.
저에게 소프트웨어 엔지니어와 프로그래머의 차이점은 엔지니어가 코드를 작성하기 전에 생성 할 내용에 대한 사양을 작성할 수 있다는 것입니다. 프로그래머는 다른 사람의 사양에 따라 코드를 작성하거나 그 중 하나입니다. 사양없이 코드를 작성하는 와일드 웨스트 프로그래머 또한 엔지니어는 학위를 가지고 있습니다.
나는 건설 노동자와 구조 엔지니어의 차이점을 프로그래머와 소프트웨어 엔지니어의 차이점에 비유합니다.
명확히하기 위해 나는 대학 졸업장 만 가지고 있으므로 엔지니어라고 부를 수는 없습니다.
나는 "엔지니어링"이라는 용어를 소프트웨어 개발을 설명하는 데 가장 적합한 것으로 간주하지 않을 것입니다.
산업, 토목, 해군 또는 기계 공학과 같은 전통적인 공학 분야에서 비롯된 많은 오래된 아이디어, 개념 및 소위 "황금 규칙"을 전달합니다. 나는이 가장 자주 만 ... 노동 부문의 규칙, 생산 공정, 품질 기준에 대해서 이야기하고 소폭 소프트웨어에 적용됩니다.
프로그래밍이 다른 분야보다 더 많은 것이 무엇인지 (그리고 나는 훨씬 더 많이 다르다고 생각합니다), 개발자가 전통적인 방식에 비해 매일 직면 해야하는 새로운 과제를 만족스럽게 설명하지 못합니다. 소각 영역. 소프트웨어의 가상적이고 중요하지 않은 특성은 그 점에서 큰 역할을합니다.
소프트웨어 개발은 오랫동안 "또 다른 엔지니어링 분야"로 여겨져왔다. 우리가 측정 한 이후로 알려진 소프트웨어 프로젝트의 실패율을 고려할 때, 개발을 완전히 새로운 동물로 인식하고, 완전히 다른 종류의 생산 주기로 실제 재료 및 응용 프로그램 수명 주기로 코드를 인식하고, 필사적으로 시도를 중단해야 할 때입니다. 그들에게 오래된 요리법을 적용합니다.
그렇습니다. 괜찮은 제품에 도달하기 위해 표준과 원칙을 적용 할 수 있어야합니다. 어려운 점은 고객의 사고 방식 (코드 일 뿐이며 비용이 많이 들지 않아야 함), 제품이 기계 코드 (음성 / 쓰기 언어에서 코드로)로 수행해야하는 작업을 체계화하는 데 어려움이 있으며 " 품질". 품질에 대한 당신의 정의는 내 것이 아닙니다.
반복성이기도합니다. 일련의 요구 사항을 가져와 두 팀에 제공하십시오. 팀이 서로 이야기하지 않고 같은 것을 얻을 수 있다면 엔지니어링에 매우 가깝습니다.
다른 공학 분야에도 처벌이 있으며 엄격한 검토와 사인 오프가 있습니다. 책임.
아닙니다. 소프트웨어 엔지니어링은 엔지니어링이 아닙니다. 제 생각에는 차이는 창의력의 양에 있습니다. 예를 들어, 토목 공학에서는 창의성이 거의 없거나 전혀 없을 수 있습니다. 이것은 좋은 일입니다.
다리를 건설하려면 일련의 사양이 있습니다 (강의이 쪽에서 다른 쪽으로이 차량 수를 가져와야합니다).
이것으로부터 나는 추론 할 수있다 :
그런 다음 계산을 올바르게 수행했는지 확인하기 위해 제 3 자 (다른 회사)가 설계를 승인하고 확인해야합니다.
그런 다음 다리가 실제로 건설되면 자격을 갖춘 사람들이 표준 방식으로 작업을 수행합니다. 그들은 수백 번, 아마도 수천 번 전에 한 일을하고있을 것입니다.
틀리지 말고 모든 토목 공학 프로젝트는 다르지만 새로운 응용 프로그램 / 웹 사이트를 개발할 때마다 상황이 다르게 수행되는 것 같습니다.
예, 개발은 엔지니어링의 일부라고 생각합니다.
Code Complete 는 "구축"을 코딩 및 디버깅 (및 주석 달기)과 동의어로, 사전 세부 설계 및 이후 단위 및 통합 테스트와 함께 정의합니다. 1 장, 소프트웨어 구성 시작 (PDF) 은 전체 소프트웨어 개발 라이프 사이클 (문제 정의, 소프트웨어 아키텍처, 수정 유지 관리 등)에 많은 주제를 나열한 다음 시작합니다.
그림에서 알 수 있듯이 시공은 대부분 코딩 및 디버깅이지만 자세한 설계, 시공 계획, 단위 테스트, 통합, 통합 테스트 및 기타 활동도 포함됩니다. 이 책이 소프트웨어 개발의 모든 측면에 관한 책이라면, 개발 과정의 모든 활동에 대한 균형 잡힌 토론이 특징입니다. 그러나 이것은 건축 기법의 핸드북이기 때문에 건축에 중점을두고 관련 주제에 대해서만 다루고 있습니다. 이 책이 개라면, 디자인과 테스트에서 꼬리를 흔든 다음 다른 개발 활동에 착수 할 것입니다.
소프트웨어 개발은 엔지니어링입니다.
소프트웨어 엔지니어링이 엔지니어 표준을 충족하지 않는 이유에 대해 다른 사람들이 한 몇 가지 주장 :
어떤 사람들은 엔지니어들이 공공재를 위해 "사물"을 설계하는 사업에 있다고 말합니다. ICBM, 탱크 등은 공공재에 있습니까? 어떤 사람들은 그렇다고 대답 할 것입니다 (좋은 공격은 좋은 방어입니다). 그러나 차세대 탱크 타겟팅 시스템을 설계하는 사람이 엔지니어라는 의견에 동의하지 않을 것입니다. 공공재는 주관적 일 수 있습니다. 여하튼, 많은 소프트웨어가 공공의 이익에 속하므로 요점은 어느 쪽이든 약점입니다.
다른 사람들은 엔지니어가 자신이 만들지 않은 것을 설계한다고 말합니다. 몇 가지 "기계 엔지니어들이 용접하지 않습니다"유형의 의견을 보았습니다. 자세한 디자인이 - 나는 기계 엔지니어 청사진 생산 있다고 주장 뭔가를 다른 구현을. 기계 엔지니어가 청사진을 만들어 CNC 기계에 공급하는 경우 기계 엔지니어가 더 이상 기계 엔지니어가되지 않습니다. 기계가 사람 대신 구현했기 때문입니까? 소스 코드는 구현을 수행하는 머신에 공급되는 자세한 청사진이라고 주장하며 이것이 MechE가 CNC 머신에 공급하는 코드와 다른 점을 알 수 없습니다. 그리고 우리는 이제 기계 엔지니어의 끝을 나타내는 3D 프린터를 가지고 있습니까? 그들은 이제 기계 개발자입니까?
라이센스는 내가 보게 될 다른 주제입니다. 현재 일부 관할권의 라이센스 소프트웨어 엔지니어 만 있습니다. (현재까지) 소프트웨어 엔지니어에 대한 미국 전체의 라이센스는 없습니다 (Texas만이 그렇게 생각합니다). 일부는 이것을 소프트웨어 엔지니어링을 엔지니어링이라고 부를 수없는 이유로 사용했습니다. 소프트웨어 엔지니어를위한 PE가오고 있습니다. 그러나 일부 주 입법자들이 소프트웨어 개발 엔지니어링이라고 부르거나 선택하지 않기 때문에보다 철학적 인 수준에서는 현실에 영향을 미치지 않습니다.