소프트웨어 엔지니어링

Software engineering
시리즈의 일부
소프트웨어 개발
핵심 활동
패러다임 및 모델
방법론 및 프레임워크
지원 분야
프랙티스
도구들
지식의 표준과 본문
용어집
개요

소프트웨어 엔지니어링은 소프트웨어 [1][2][3]개발에 대한 체계적인 엔지니어링 접근법입니다.

소프트웨어 엔지니어는 소프트웨어 엔지니어링의 원리를 컴퓨터 소프트웨어의 설계, 개발, 유지보수, 테스트 및 평가에 적용하는 사람입니다.프로그래머라는 용어는 동의어로 사용되기도 하지만 공학 교육이나 기술의 함축이 부족할 수도 있습니다.

엔지니어링 기술은 소프트웨어 라이프 사이클 프로세스 자체의 정의, 구현, 평가, 측정, 관리, 변경 및 개선을 수반하는 소프트웨어 개발[1][4] 프로세스에 정보를 제공하기 위해 사용됩니다[clarification needed].소프트웨어 구성 관리를[1][4] 많이 사용합니다.이 관리에서는 구성 변경을 체계적으로 제어하고 시스템 라이프 사이클 전체에서 구성 및 코드의 무결성과 트레이서빌리티를 유지합니다.최신 프로세스에서는 소프트웨어 버전 관리를 사용합니다.

역사

주요 기사:소프트웨어 엔지니어링의 역사

1960년대부터 소프트웨어 공학은 독자적인 공학으로 인식되었다.게다가 소프트웨어 엔지니어링의 개발은 고군분투로 여겨졌다.소프트웨어 엔지니어들에게 많은 문제를 야기하는 하드웨어를 따라가기가 어려웠다.예산 초과, 기한 초과, 광범위한 디버깅 및 유지보수가 필요하며 소비자의 요구를 충족시키지 못하거나 완성되지 못한 소프트웨어 등이 문제였습니다.1968년 NATO는 소프트웨어 개발에 관한 가이드라인과 베스트 프랙티스가 확립된 최초의 소프트웨어 엔지니어링 컨퍼런스를 개최했습니다.[5]

"소프트웨어 엔지니어링"이라는 용어의 기원은 다양한 출처에서 기인한다.「소프트웨어 엔지니어링」이라는 용어는, 1965년 6월호 「COMPUTERS and AUTOMATION」에 게재되어 ACM 사장 Anthony A에 의한 「ACM 멤버쉽에의 서신」(1966년 8월호)에 게재되어 보다 정식으로 사용되고 있습니다.Oettinger는 [6][7]1968년 Friedrich L. Bauer 교수가 소프트웨어 [8]공학에 관한 첫 회의인 NATO 회의의 제목과도 관련이 있습니다.Margaret Hamilton은 아폴로 임무 동안 그들이 하고 있는 일을 [9]합법적으로 하기 위한 "소프트웨어 엔지니어링"을 묘사했다.그 당시에는 "소프트웨어 위기"[10][11][12]로 인식되었습니다.제40회 소프트웨어 엔지니어링 국제회의(ICSE 2018)에서는 Frederick[13] Brooks와 Margaret [14]Hamilton의 주요 내용으로 50년간의 "소프트웨어 엔지니어링"을 기념하고 있습니다.

1984년 미국 펜실베니아주 피츠버그에 있는 카네기 멜론 대학의 캠퍼스에 본부를 둔 연방정부의 자금 지원 연구 개발 센터로서 소프트웨어 엔지니어링 연구소(SEI)가 설립되었습니다.Watts Humphrey는 소프트웨어 엔지니어링 프로세스를 이해하고 관리하기 위한 SEI 소프트웨어 프로세스 프로그램을 설립했습니다.도입된 프로세스 성숙도 레벨은 개발 능력 성숙도 모델 통합(CMMI-DEV)이 됩니다.CMMI-DEV는 미국 정부가 소프트웨어 개발팀의 능력을 평가하는 방법을 정의합니다.

일반적으로 인정되고 있는 소프트웨어 엔지니어링의 최신 베스트 프랙티스는 ISO/IEC JTC 1/SC 7 소위원회에 의해 수집되어 소프트웨어 엔지니어링 지식기구(SWEBOK)[15]로 발행되었습니다.소프트웨어 엔지니어링은 주요 컴퓨팅 분야 [16]중 하나로 간주됩니다.

정의와 용어의 문제

소프트웨어 엔지니어링의 주요 정의는 다음과 같습니다.

  • "소프트웨어의 설계, 구현, 테스트 및 문서화에 대한 과학기술 지식, 방법 및 경험을 체계적으로 적용하는 것"-노동통계국 -IEEE 시스템 및 소프트웨어 엔지니어링 – 용어[17]
  • "소프트웨어의 개발, 운용 및 유지보수에 대한 체계적이고 규율적이며 수량화 가능한 접근법의 적용" -IEEE 소프트웨어 엔지니어링[18] 용어집
  • "소프트웨어 생산의 모든 측면에 관련된 엔지니어링 분야": Ian Sommerville[19]
  • "신뢰성이 높고 실제 기계에서 효율적으로 작동하는 소프트웨어를 경제적으로 얻기 위해 건전한 엔지니어링 원칙을 확립하고 사용한다.": 프리츠 바우어[20]
  • "복잡한 컴퓨터 프로그램의 설계, 구현 및 유지보수를 다루는 컴퓨터 과학의 한 분야": Merriam[21] Webster
  • '소프트웨어 엔지니어링'은 단순히 코드를 작성하는 행위뿐만 아니라 조직에서 코드를 구축 및 유지하기 위해 사용하는 모든 도구와 프로세스를 포괄합니다.[...] 소프트웨어 엔지니어링은 '시간이 지남에 따라 통합된 프로그래밍'이라고 할 수 있습니다.'-Google의 소프트웨어[22] 엔지니어링

이 용어는 또한 덜 공식적으로 사용되었습니다.

  • 이전에는 컴퓨터 프로그래밍 및 시스템 [23]분석이라고 불리던 광범위한 활동을 나타내는 비공식적인 현대 용어.
  • 컴퓨터 과학의 [24]하위 분야로 공식적으로 연구되는 컴퓨터 프로그래밍 이론과 대조적으로 컴퓨터 프로그래밍 실습의 모든 측면에 대한 넓은 용어이다.
  • 컴퓨터 프로그래밍에 대한 특정 접근방식을 옹호하는 용어로서, 컴퓨터 프로그래밍을 예술이나 공예가 아닌 공학 분야로 취급할 것을 촉구하고 권장 [25]프랙티스의 코드화를 옹호하는 용어이다.

소프트웨어 엔지니어의 어원

Margaret Hamilton은 아폴로 계획에 대한 그녀의 연구 중에 "소프트웨어 엔지니어링"이라는 용어를 홍보했습니다."공학"이라는 용어는 이 작업이 기술 발전에 대한 다른 기여와 마찬가지로 진지하게 받아들여져야 한다는 것을 인정하기 위해 사용되었습니다.Hamilton은 다음과 같은 용어의 사용을 자세히 설명합니다.

내가 처음 이 용어를 생각해냈을 때, 적어도 우리 세계에서는 아무도 전에 이 용어를 들어본 적이 없었다.그것은 오랫동안 계속된 농담이었다.그들은 나의 급진적인 생각을 가지고 놀리기를 좋아했다.가장 존경받는 하드웨어 전문가 중 한 명이 미팅에서 소프트웨어 구축 프로세스도 하드웨어와 마찬가지로 엔지니어링 분야로 간주해야 한다는 데 동의했다고 설명한 것은 기억에 남는 하루였습니다.그가 새로운 용어 자체를 받아들였기 때문이 아니라, 우리가 그와 그 방에 있는 다른 사람들을 공학 분야로 받아들였기 때문입니다.[26]

용어의 적합성

소프트웨어 엔지니어링 또는 엔지니어링 분야로서의 정당성을 정의하는 방법에 대해 개별 논평가들은 크게 이견을 보이고 있습니다.David Parnas는 소프트웨어 엔지니어링은 사실 엔지니어링의 [27][28]한 형태라고 말했습니다.Steve McConnell은 그렇지 않지만 [29]그래야 한다고 말했다.도널드 커누스는 프로그래밍은 예술이자 [30]과학이라고 말했다.Edsger W. Dijkstra는 소프트웨어 엔지니어링과 소프트웨어 엔지니어라는 용어가 오용되었으며[improper synthesis?] 특히 미국에서 [31]유해하다고 간주되어야 한다고 주장했다.

대규모 프로젝트 태스크

주요 기사:소프트웨어 엔지니어링의 개요

소프트웨어 요건

주요 기사:소프트웨어 요건

요구사항 엔지니어링은 소프트웨어에 대한 요구사항의 도출, 분석, 사양 및 검증에 관한 것입니다.소프트웨어 요건은 세 가지 유형으로 나눌 수 있습니다.기능요건, 비기능요건 및 도메인요건이 있습니다.소프트웨어의 조작을 실시해, 유저가 사용할 수 있는 적절한 출력을 기대할 필요가 있습니다.비기능적 요건은 휴대성, 보안, 유지보수성, 신뢰성, 확장성, 퍼포먼스, 재사용성, 유연성 등의 문제를 다룹니다.인터페이스 제약, 퍼포먼스 제약(응답시간, 보안, 스토리지 공간 등), 운용 제약, 라이프 사이클 제약(유지보수성, 휴대성 등) 및 경제적 제약으로 분류됩니다.기능하지 않는 요건을 특정할 때는 시스템 또는 소프트웨어의 동작에 대한 지식이 필요합니다.도메인 요건은 프로젝트의 [32]특정 범주 또는 도메인의 특성과 관련이 있습니다.

소프트웨어 설계

주요 기사:소프트웨어 설계

소프트웨어 설계는 시스템 또는 컴포넌트의 아키텍처, 컴포넌트, 인터페이스 및 기타 특성을 정의하는 프로세스에 관한 것입니다.이를 소프트웨어 아키텍처라고도 합니다.소프트웨어 설계는 세 가지 수준의 설계로 나뉩니다.인터페이스 설계, 아키텍처 설계 및 상세 설계의 3가지 레벨이 있습니다.인터페이스 설계는 시스템과 그 환경 간의 상호작용입니다.이는 시스템의 내부 작동과 함께 높은 수준의 추상화에서 발생합니다.아키텍처 설계는 시스템의 주요 구성요소와 그 책임, 속성, 인터페이스, 그리고 이들 사이에 발생하는 관계와 상호작용과 관련이 있습니다.상세설계는 모든 주요 시스템 컴포넌트, 그 속성, 관계, 처리, 그리고 보통 알고리즘과 데이터 구조의 내부 요소입니다.[33]

소프트웨어 구축

주요 기사:소프트웨어 구축

소프트웨어 [1][4]개발의 주요 활동인 소프트웨어 구축은 프로그래밍, 유닛 테스트, 통합 테스트 및 디버깅의 조합입니다.이 단계에서의 테스트는 일반적으로 소프트웨어 구축 중에 프로그래머에 의해 수행되며, 작성된 내용을 확인하고 코드를 다음 단계로 전송할 준비가 언제 되었는지 판단합니다.

소프트웨어 테스트

주요 기사:소프트웨어 테스트

소프트웨어[1][4] 테스트는 테스트 대상 제품 또는 서비스의 품질에 대한 정보를 이해관계자에게 제공하기 위해 실시되는 경험적 기술적 조사로, 유닛 테스트 및 통합 테스트 등의 다양한 접근 방식을 제공합니다.이것은 소프트웨어 품질의 한 측면입니다.소프트웨어 개발의 다른 단계로서 일반적으로 품질보증 담당자 또는 코드를 작성한 개발자가 아닌 개발자가 수행합니다.

소프트웨어 유지보수

주요 기사:소프트웨어 유지보수

소프트웨어 유지보수란[1][4] 소프트웨어 제품 출하 후 비용 효율이 높은 지원을 제공하기 위해 필요한 작업을 말합니다.소프트웨어 유지보수는 장애를 수정하고 성능을 개선하기 위해 배포 후 소프트웨어 애플리케이션을 수정 및 업데이트하는 것입니다.소프트웨어는 실제 세계와 많은 관련이 있으며, 실제 세계가 바뀌면 소프트웨어 유지보수가 필요합니다.소프트웨어 유지보수에는 오류 수정, 최적화, 사용되지 않는 기능 및 폐기된 기능의 삭제, 기존 기능의 확장 등이 포함됩니다.일반적으로 유지보수는 프로젝트 비용의 약 40~80%를 차지하기 때문에 유지보수에 중점을 두고 비용을 [34]절감합니다.

교육

컴퓨터 프로그래밍에 대한 지식은 소프트웨어 엔지니어가 되기 위한 필수 조건이다.2004년 IEEE Computer Society는 SWEBOK를 제작하여 ISO/IEC Technical Report 1979:2005로 발행하였습니다.이 보고서에는 4년 [35]경력의 대학원 소프트웨어 엔지니어가 습득할 것을 권장하는 지식들이 기재되어 있습니다.많은 소프트웨어 엔지니어들이 대학 학위를 취득하거나 전문학교에서 훈련을 받아 이 직업에 입문한다.IEEE Computer Society 및 Association for Computing Machineery에 의한 컴퓨팅 커리큘럼에 관한 공동 태스크 포스에 의해 학부 소프트웨어 공학 학위를 위한 하나의 표준 국제 커리큘럼이 정의되어 [36]2014년에 갱신되었습니다.많은 대학이 소프트웨어 엔지니어링 학위 프로그램을 보유하고 있습니다.2010년 현재 미국에는 244개의 캠퍼스 소프트웨어 엔지니어링 학사 프로그램, 70개의 온라인 프로그램, 230개의 석사 레벨 프로그램, 41개의 박사 레벨 프로그램, 69개의 자격증 레벨 프로그램이 있습니다.

대학 교육 외에도 많은 기업들이 정보기술 분야의 직업을 원하는 학생들을 위해 인턴십을 후원하고 있습니다.이러한 인턴십을 통해 학생들에게 일반적인 소프트웨어 엔지니어가 매일 접하는 흥미로운 실제 작업을 소개할 수 있습니다.소프트웨어 공학의 군복무에서도 비슷한 경험을 얻을 수 있다.

소프트웨어 공학 학위 프로그램

오늘날 모든 실무자의 절반은 컴퓨터 공학, 정보 시스템 또는 정보기술 [citation needed]학위를 가지고 있습니다.소프트웨어 공학 학위를 가진 소수의 실무자가 증가하고 있습니다.1987년 임페리얼 칼리지 런던의 컴퓨팅 학과는 영국과 세계에 최초의 3년제 소프트웨어 공학 학사 학위를 도입했습니다.다음해 셰필드 대학도 비슷한 프로그램을 [37]설립했습니다.1996년, 로체스터 공과대학은 미국 최초의 소프트웨어 공학 학사 프로그램을 설립했지만, 라이스 대학, 클락슨 대학, 밀워키 공대, 미시시피 주립 대학이 [38]취득한 것과 같은 시기인 2003년까지 ABET 인증을 취득하지 못했습니다.1997년 인도 코임바토레에 있는 PSG College of Technology는 소프트웨어 엔지니어링 [citation needed]분야에서 5년간 통합된 과학 석사 학위를 최초로 취득했습니다.

그 후, 많은 대학에서 소프트웨어 공학 학사 학위가 설립되었습니다.학부 소프트웨어 공학 학위를 위한 표준 국제 커리큘럼인 SE2004는 2001년부터 2004년 사이에 컴퓨터 기계 협회와 IEEE 컴퓨터 협회의 자금으로 운영 위원회에 의해 정의되었습니다.2004년 현재 미국에서는 약 50개의 대학이 컴퓨터 공학과 공학 원리 및 실무 모두를 가르치는 소프트웨어 공학 학위를 제공하고 있다.최초의 소프트웨어 공학 석사 학위는 1979년 시애틀 대학에서 설립되었습니다.그 후, 소프트웨어 공학 석사 학위를 더 많은 대학에서 취득할 수 있게 되었습니다.마찬가지로 캐나다에서는 캐나다 프로페셔널 엔지니어 평의회의 캐나다 엔지니어링 인증위원회(CEAB)가 몇 가지 소프트웨어 엔지니어링 프로그램을 인정했습니다.

1998년 미국 해군대학원(NPS)은 세계 [citation needed]최초로 소프트웨어 공학 박사과정을 개설했다.또한 풀러턴 캘리포니아 주립대학교 컴퓨터 공학부에서 제공하는 소프트웨어 공학 석사(MSE) 학위 등 소프트웨어 공학 분야의 많은 온라인 고급 학위도 등장했습니다.스티브 맥코넬은 대부분의 대학에서 소프트웨어 공학보다는 컴퓨터 과학을 가르치기 때문에 진정한 소프트웨어 [39]엔지니어가 부족하다고 주장한다.ETS(Ecole de technologie supérieure) University 및 UQAM(Université du Québec mon Montréal)은 IEEE로부터 소프트웨어 [40]엔지니어가 다루는 지식을 기술하는 ISO 표준이 되었습니다.

직업

주요 기사:소프트웨어 엔지니어링 전문성 및 엔지니어링 규제 및 라이선스

전문 소프트웨어 엔지니어의 라이센스 또는 인증에 관한 법적 요건은 전 세계에 걸쳐 다릅니다.영국에서는 Software Engineer라는 직함을 인수하거나 사용하기 위한 라이센스나 법적 요건이 없습니다.Alberta, British Columbia, [41]Ontario 및 Quebec과 같은 캐나다의 일부 지역에서는 소프트웨어 엔지니어가 Professional Engineer(P)를 보유할 수 있습니다.Eng) 지정 및/또는 정보시스템 프로페셔널(I.S.P.) 지정.유럽에서는 소프트웨어 엔지니어가 유럽 엔지니어(EUR ING) 프로페셔널 타이틀을 취득할 수 있습니다.

미국은 2013년부터 소프트웨어 엔지니어링에 NCEES Professional Engineer 시험을 제공하고 있으며, 이에 따라 소프트웨어 엔지니어의 면허 및 인정을 [42]받을 수 있게 되었습니다.NCEES는 [43]참여 부족으로 2019년 4월 이후 시험을 종료할 예정이다.강제 라이선스는 현재도 크게 논의되고 있으며 [citation needed]논란의 여지가 있는 것으로 인식되고 있습니다.텍사스 등 미국의 일부 지역에서는 엔지니어의 사용이 법률로 규제되어 있으며 프로페셔널 엔지니어 자격증을 [citation needed]가진 개인만이 사용할 수 있습니다.

IEEE Computer Society와 ACM은 소프트웨어 엔지니어링 분야의 주요 2개 전문 조직입니다.「IEEE's Guide to the Software Engineering Body of Knowledge – 2004 Version (SWBOK)」에서는, 이 필드를 정의하고, IEEE가 실무 소프트웨어 엔지니어가 갖추어야 할 지식을 설명하고 있습니다.최신 SWEBOK v3는 업데이트된 버전으로 [44]2014년에 출시되었습니다.IEEE는 또, 「소프트웨어 엔지니어링 윤리 강령」[45]도 공표하고 있습니다.

고용.

다음 항목도 참조하십시오.소프트웨어 엔지니어링 인구 통계

미국 노동통계국(BLS)은 [46]2018년 미국에서 일자리를 갖고 있는 소프트웨어 개발자를 136만5500명으로 집계했다.상대적으로 새로운 학문 분야이기 때문에, 소프트웨어 공학에서의 정규 교육은 컴퓨터 과학 커리큘럼의 일부로 종종 가르쳐지며, 많은 소프트웨어 엔지니어들이 컴퓨터 과학 [47]학위를 보유하고 있습니다.BLS는 2014년부터 2024년까지 컴퓨터 소프트웨어 엔지니어링이 17%[48] 증가할 것으로 예상하고 있습니다.이는 소프트웨어 [49][48]엔지니어링 분야의 2012~2022년 BLS 예측치인 22%에서 감소한 것입니다.또한 2010년 [50]BLS 추정치의 30%에서 2020년 BLS 추정치로 더 낮아졌습니다.이러한 추세로 인해 지난 10년 동안 일자리 증가 속도가 빠르지 않을 수 있습니다.미국에서는 컴퓨터 소프트웨어 엔지니어에게 돌아갈 수 있었던 일자리가 인도나 다른 [51][52]나라의 컴퓨터 소프트웨어 엔지니어에게 아웃소싱될 것이기 때문입니다.또한 BLS Job Outlook for Computer Programmers, 2014–24는 -8%(하락),[51] Job Outlook은 -9%[53] 감소, 2020-2030은 10% 감소할 것으로 [54][55]예측하고 있습니다.게다가 많은 소프트웨어 분야의 여성도 다른 공학 [56]분야와 비교해 수년에 걸쳐 감소하고 있다.그러나 미국 시장에서 현재 소프트웨어 엔지니어들이 향후 수십 년 안에 이 직업이나 연령을 시장에서 벗어나기 때문에 이러한 추세는 미래에 바뀌거나 느려질 수 있다.

많은 소프트웨어 엔지니어가 직원 또는 청부업자로 일하고 있습니다.소프트웨어 엔지니어는 기업, 정부기관(민간기관 또는 군사기관) 및 비영리단체와 협력합니다.소프트웨어 엔지니어 중에는 프리랜서로 일하는 사람도 있습니다.일부 조직에는 소프트웨어 개발 프로세스의 각 태스크를 수행할 전문가가 있습니다.다른 조직에서는 소프트웨어 엔지니어가 이러한 작업을 대부분 또는 모두 수행해야 합니다.대형 프로젝트에서는 한 가지 역할만 전문화할 수 있습니다.소규모 프로젝트에서는 여러 역할 또는 모든 역할을 동시에 수행할 수 있습니다.많은 기업들이 여름 방학 동안 종종 대학생이나 대학생인 인턴을 고용하거나 외부 인턴을 고용합니다.전문 분야에는 분석가, 건축가, 개발자, 테스터, 기술 지원, 미들웨어 분석가, 프로젝트 관리자, 교육자 및 연구자가 포함됩니다.

대부분의 소프트웨어 엔지니어와 프로그래머는 일주일에 40시간을 일하지만 [52]2008년에는 소프트웨어 엔지니어의 약 15%, 프로그래머의 11%가 일주일에 50시간 이상을 일했습니다.컴퓨터 단말기 앞에 앉아 키보드로 타이핑을 하는 다른 근로자들과 마찬가지로 엔지니어와 프로그래머들은 눈의 피로, 허리의 불편함, 손목 터널 [57]증후군과 같은 손과 손목에 문제가 생기기 쉽기 때문에 이러한 직업에서 부상을 입을 수 있다.

인정.

Software Engineering Institute는 보안, 프로세스 개선 및 소프트웨어 [58]아키텍처와 같은 특정 주제에 대한 인증을 제공합니다.IBM, Microsoft 및 기타 기업도 자체 인증 시험을 후원합니다.많은 IT인정 프로그램은 특정 테크놀로지를 지향하며 이들 [59]테크놀로지의 벤더에 의해 관리되고 있습니다.이러한 인증 프로그램은, 이러한 테크놀로지를 사용하는 종업원을 채용하는 기관에 맞추어 조정되고 있습니다.

일반적인 소프트웨어 엔지니어링 기술에 대한 광범위한 인증은 다양한 전문 협회를 통해 이용할 수 있습니다.2006년 현재 IEEE는 575명이 넘는 소프트웨어 전문가를 인정 소프트웨어 개발 전문가(CSDP)[60]로 인정했습니다.2008년에는 Certified Software Development Associate(CSDA)[61]라는 엔트리 레벨 인증을 추가했습니다.ACM은 1980년대 [citation needed]초에 전문 자격증 프로그램을 가지고 있었지만, 관심 부족으로 인해 중단되었다.ACM은 1990년대 후반 소프트웨어 엔지니어의 전문 인증 가능성을 검토했지만 결국 소프트웨어 [62]엔지니어링의 전문 산업 실무에 적합하지 않다고 판단했다.

영국에서는, 영국 컴퓨터 협회가 법적으로 인정되고 있는 「차타드 IT프로페셔널」(CITP)이라고 불리는 전문 자격증을 개발했습니다.이 자격은 완전 자격 회원(MBCS)이 이용할 수 있습니다.소프트웨어 엔지니어는 엔지니어링 및 테크놀로지 협회의 회원 자격을 취득할 수 있으므로 공인 엔지니어 자격을 취득할 수 있습니다.캐나다에서는, 캐나다 정보 처리 협회(Canadian Information Processing Society)가, ISP([63]Information Systems Professional)라고 하는 법률적으로 인정되고 있는 프로페셔널 인증을 개발했습니다.캐나다 온타리오에서는 캐나다 엔지니어링 인증위원회(CEAB) 인정 프로그램을 졸업하여 PEO(Professional Engineer Ontario) Professional Practice Examination(PPE; 프로페셔널 프랙티스 시험)을 성공적으로 이수하고 Eng Professional Engineering을 통해 최소 48개월 이상 인정받은 소프트웨어 엔지니어가 면허를 취득할 수 있습니다.온타리오에 있으며 프로페셔널 엔지니어 P가 될 수 있습니다.그러나 [64]PEO는 온라인이나 원격교육은 인정하지 않으며 컴퓨터 사이언스 프로그램이 소프트웨어 엔지니어링 프로그램과 동등하다고 생각하지 않습니다.이는 논란과 인증전쟁을 불러일으켰다.또한 P의 번호도 보유하고 있습니다.전문직의 영어 보유자는 유난히 낮다.이 분야에서 일하는 프로페셔널의 대부분은 SE가 아닌 CS 학위를 보유하고 있습니다.SE가 아닌 학위 소지자에게는 어려운 인증 경로를 고려할 때, 대부분은 굳이 라이센스를 취득하지 않습니다.

세계화의 영향

아웃소싱의 초기 영향과 제3세계 개발도상국의 국제 인력 비용이 상대적으로 낮았기 때문에 소프트웨어 개발 활동이 북미 및 유럽의 기업에서 인도 및 그 이후에 대규모로 이행하게 되었습니다.중국, 러시아 및 기타 개발도상국.이 접근법에는 주로 거리와 시간대의 차이로 인해 고객과 개발자 간의 인적 상호 작용이 방해되고 대규모 작업 이전이 방해되는 결함이 있었습니다.이는 소프트웨어 엔지니어링 직업의 많은 측면에 부정적인 영향을 미쳤다.예를 들어 선진국의 일부 학생들은 해외 아웃소싱(다른 나라에서 소프트웨어 제품이나 서비스를 수입)이나 외국인 비자 [65]근로자에 의해 대체될 것을 우려하여 소프트웨어 공학 관련 교육을 기피하고 있다.통계는 현재 소프트웨어 엔지니어링 자체에 위협이 되는 것은 아니지만, 관련된 경력에 컴퓨터 프로그래밍이 영향을 [66][67]받은 것으로 보입니다.그럼에도 불구하고 Follow-the-sun 워크플로우를 통해 오프쇼어 및 근해 자원을 현명하게 활용할 수 있는 능력은 많은 [68]조직의 전반적인 운영 능력을 향상시켰습니다.북미인들이 퇴근할 때 아시아인들은 막 출근하고 있다.아시아인들이 직장을 떠날 때 유럽인들이 직장에 도착한다.이를 통해 시간외 수당을 지급하거나 주요 인력인 수면 패턴을 중단하지 않고 24시간 비즈니스 크리티컬 프로세스를 지속적으로 감시할 수 있습니다.

글로벌 아웃소싱에는 몇 가지 이점이 있지만, 글로벌하게 분산되어 있는 개발은 개발자 간의 거리가 멀기 때문에 심각한 문제에 직면할 수 있습니다.이는 지리적, 시간적, 문화적, 커뮤니케이션으로 식별된 이 거리 유형의 핵심 요소(다른 위치에서 [69]다른 언어와 영어 사투리를 사용하는 것을 포함) 때문이다.지난 15년 동안 글로벌 소프트웨어 개발 분야에서 연구가 수행되었으며, 복잡한 활동과 관련된 이점과 문제점을 강조하는 관련 연구들이 광범위하게 발표되었습니다.소프트웨어 엔지니어링의 다른 측면과 마찬가지로 이 분야 및 관련 분야에서도 연구가 진행 중입니다.

상품

소프트웨어 엔지니어링 [70]분야에는 다음과 같은 상이 있습니다.

  • Codie Awards는 소프트웨어 산업 내 소프트웨어 개발 우수성에 대해 소프트웨어 및 정보 산업 협회가 매년 수여하는 상입니다.
  • Jolt Awards는 소프트웨어 업계의 상입니다.
  • Stevens Award는 Wayne Stevens를 기리는 소프트웨어 공학상입니다.

비판

소프트웨어 엔지니어링은 실무자를 명확한 엔지니어링 접근방식을 따라 문제를 해결하는 개인으로 간주합니다.이러한 접근방식은 다양한 소프트웨어 엔지니어링 서적 및 연구 논문에 명시되어 있으며, 항상 예측 가능성, 정밀도, 리스크 완화 및 전문성을 함축하고 있습니다.이러한 관점에서 볼 때 엔지니어링 지식을 보급하고 분야를 성숙시키기 위한 메커니즘으로 라이선스, 인증 및 지식 체계화가 요구되고[by whom?] 있습니다.

소프트웨어 엔지니어링은 엔지니어링을 확장하고 엔지니어링 모델(엔지니어링 프로세스, 엔지니어링 프로젝트 관리, 엔지니어링 요건, 엔지니어링 설계, 엔지니어링 건설 및 엔지니어링 검증)을 활용합니다.이 개념은 매우 새로운 것이어서 거의 이해되지 않으며 소프트웨어 공학 교과서, 논문, 프로그래머와 크레이퍼 커뮤니티 등 널리 잘못 해석되고 있습니다.

소프트웨어 엔지니어링의 핵심 문제 중 하나는 접근방식의 실제 검증이 일반적으로 부재하거나 매우 제한적이기 때문에 접근방식이 충분히 경험적이지 않다는 것이다.따라서 소프트웨어 엔지니어링은 종종 "이론적인 환경"에서만 실현 가능한 것으로 잘못 해석된다.

오늘날 소프트웨어 개발에서 사용되는 많은 개념의 창시자인 Edsger Dijkstra는 2002년 사망할 때까지 "소프트웨어 엔지니어링"이라는 개념을 거부했습니다.이 용어들은 컴퓨터 과학의 "급진적 신규성"에 대한 빈약한 비유라고 주장했습니다.

이러한 현상의 대부분은 "소프트웨어 엔지니어링"이라는 이름으로 번들되어 있습니다.경제학이 '비참한 과학'으로 알려지면서 소프트웨어 공학은 '불운한 학문'으로 알려져야 하는데, 그 목적은 자기 모순이기 때문에 목표에 접근조차 할 수 없기 때문이다.물론 소프트웨어 엔지니어링은 또 다른 가치 있는 명분으로 제시되지만, 그것은 안목입니다.그 문헌을 주의 깊게 읽고, 그 신봉자가 실제로 무엇을 하고 있는지를 분석하면, 소프트웨어 엔지니어링이 「할 [71]수 없는 경우의 프로그래밍 방법」의 헌장으로 받아들여지고 있는 것을 알 수 있습니다.

「 」를 참조해 주세요.

Wikimedia Commons에는 소프트웨어 엔지니어 관련 미디어가 있습니다.

공부와 연습

역할

프로페셔널한 측면

레퍼런스

인용문

  1. ^ a b c d e f 아브란 등 2004년, 1-1페이지
  2. ^ ACM (2007). "Computing Degrees & Careers". ACM. Retrieved 2010-11-23.
  3. ^ Laplante, Phillip (2007). What Every Engineer Should Know about Software Engineering. Boca Raton: CRC. ISBN 978-0-8493-7228-5. Retrieved 2011-01-21.
  4. ^ a b c d e "Software Engineering Body of Knowledge (SWEBOK Version 3), 2014" (pdf). www.swebok.org. IEEE Computer Society. Retrieved 24 May 2016.
  5. ^ "The history of coding and software engineering". www.hackreactor.com. Retrieved 2021-05-06.
  6. ^ Oettinger, A. G. (1966). "President's Letter to the ACM Membership". Commun. ACM. Association for Computing Machinery. 9 (8): 545–546. doi:10.1145/365758.3291288. ISSN 0001-0782. S2CID 53432801.
  7. ^ "The origin of "software engineering"". 4 April 2013. Retrieved 17 November 2017.
  8. ^ Randall, Brian. "The 1968/69 NATO Software Engineering Reports". Retrieved 17 November 2017.
  9. ^ Software Magazine. "What to Know About the Scientist who Invented the Term "Software Engineering"". Archived from the original on November 24, 2018. Retrieved February 12, 2019.
  10. ^ Sommerville 2008, 페이지 26 : 2008
  11. ^ Peter, Naur; Randell, Brian (7–11 October 1968). Software Engineering: Report of a conference sponsored by the NATO Science Committee (PDF). Garmisch, Germany: Scientific Affairs Division, NATO. Retrieved 2008-12-26.
  12. ^ Randell, Brian (10 August 2001). "The 1968/69 NATO Software Engineering Reports". Brian Randell's University Homepage. The School of the Computer Sciences, Newcastle University. Retrieved 2008-10-11. The idea for the first NATO Software Engineering Conference, and in particular that of adopting the then practically unknown term "software engineering" as its (deliberately provocative) title, I believe came originally from Professor Fritz Bauer.
  13. ^ 2018 International Conference on Software Engineering celebrating its 40th anniversary, and 50 years of Software engineering. "ICSE 2018 – Plenary Sessions – Fred Brooks". YouTube. Retrieved 9 August 2018.
  14. ^ 2018 International Conference on Software Engineering celebrating its 40th anniversary, and 50 years of Software engineering. "ICSE 2018 – Plenary Sessions – Margaret Hamilton". YouTube. Retrieved 9 August 2018.
  15. ^ "ISO/IEC TR 19759:2005". Retrieved 2012-04-01.
  16. ^ "The Joint Task Force for Computing Curricula 2005" (PDF). 2014-10-21. Archived (PDF) from the original on 2014-10-21. Retrieved 2020-04-16.
  17. ^ 시스템 및 소프트웨어 엔지니어링 – 용어집, ISO/IEC/IEEE 규격 24765:2010(E), 2010.
  18. ^ IEEE 표준 소프트웨어 엔지니어링 용어집, IEEE 규격 610.12-1990, 1990.
  19. ^ Sommerville, Ian (2007) [1982]. "1.1.2 What is software engineering?". Software Engineering (8th ed.). Harlow, England: Pearson Education. p. 7. ISBN 978-0-321-31379-9. Software engineering is an engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining the system after it has gone into use. In this definition, there are two key phrases:
    1. Engineering discipline Engineers make things work. They apply theories, methods and tools where these are appropriate [. . .] Engineers also recognize that they must work to organizational and financial constraints. [. . .]
    2. All aspects of software production Software engineering is not just concerned with the technical processes of software development but also with activities such as software project management and with the development of tools, methods and theories to support software production.
  20. ^ "Software Engineering". Information Processing. 71: 530–538.
  21. ^ "Definition of SOFTWARE ENGINEERING". www.merriam-webster.com. Retrieved 2019-11-25.
  22. ^ Winters, Titus; Manshrec, Tom; Wright, Hyrum (2020). "Preface, Programming Over Time". Software Engineering at Google. O'Reilly Media, Inc. pp. xix–xx, 6–7. ISBN 978-1-492-08279-8. We propose that “software engineering” encompasses not just the act of writing code, but all of the tools and processes an organization uses to build and maintain that code over time. What practices can a software organization introduce that will best keep its code valuable over the long term? How can engineers make a codebase more sustainable and the software engineering discipline itself more rigorous?
  23. ^ Akram I. Salah (2002-04-05). "Engineering an Academic Program in Software Engineering" (PDF). 35th Annual Midwest Instruction and Computing Symposium. Retrieved 2006-09-13.: "소프트웨어 엔지니어링은 프로그래밍의 미명일 뿐입니다.프로그래머라면 '소프트웨어 엔지니어'를 명함에 넣을 수 있지만, '프로그래머'는 아닙니다."
  24. ^ Deimel, 리오넬 E(1990년)에서 밀스, 할란 D, J.R. 뉴먼, 그리고 CB엥글, Jr.,"한 학부 교육 과정 소프트웨어 공학과에,".소프트웨어 공학 교육:특수 경력 부호 회의 1990년, 펜실베니아 주 피츠버그, 미국, 4월 2–3,...스프링거.아이 에스비엔 978-0-387-97274-9.,p. 26.`너는 현실적으로는, 우리는 연습, 소프트웨어 개발과 유지 보수 전문가들에게 필요한 준비로 소프트웨어 공학으로 보고 있다.컴퓨터 사이언티스트는 더 많은 이론적 연구를 준비하고 있다.."
  25. ^ 데이비드 Budgen, 펄 브레러턴. 미국, 바바라 Kitchenham, 스티븐 Linkman(2004-12-14)."Evidence-based 소프트웨어 공학을 깨닭자".그 2006-12-17에 원래에서 Archived..:"우리는 그 소프트웨어 공학은 단지 한 엔지니어링으로 옹호, 그리고 분석에 현재 의존에서 옮겨 가고 밭을 갈 수 있다고 믿는다...2006-10-18 Retrieved."
  26. ^ Lawrence, Snyder (2017). Fluency with information technology : skills, concepts, & capabilities ([Seventh edition] ed.). NY, NY. ISBN 978-0134448725. OCLC 960641978.
  27. ^ 파르나스, 데이비드 L.(1998년)."소프트웨어 공학 Programmes이 아닌 컴퓨터 과학 Programmes".소프트웨어 공학 실록.6:19–37. doi:10.1023/A:1018949113292.S2CID 35786237., 19:"오히려 이상 컴퓨터 과학의로서 소프트웨어 공학을 처리하면, 나는 집합의 요소,{토목, 기계 공학, 화학 공학과, 전기 공학, 같아....}그것을 치료한다."p..
  28. ^ 파르나스, 데이비드 L.(1998년)."소프트웨어 공학 Programmes이 아닌 컴퓨터 과학 Programmes".소프트웨어 공학 실록.6:19–37. doi:10.1023/A:1018949113292.S2CID 35786237 20항 p.:"이 종이는 인가를 받은 전문 프로그램의 소프트웨어 공학에 도입되는 프로그램에 전통적인 공학 분야에서 본떠 만든다 프로그램들은 그들의 교육이 필요한 졸업생들 잘 대비하는 양쪽의 질과 양이 증가할를 개발하는 일을 도울 것이라고 주장한다 신뢰할 수 있는 소프트웨어 p.roducts."
  29. ^ McConnell, Steve (August 2003). Professional Software Development: Shorter Schedules, Better Projects, Superior Products, Enhanced Careers. Boston, MA: Addison-Wesley. ISBN 0-321-19367-9., p.39: "내 생각에 이 질문에 대한 답은 명확합니다.전문 소프트웨어 개발은 엔지니어링이 되어야 합니다.그래요? 아뇨, 하지만 그래야 하나요?의심할 여지 없이, 그래."
  30. ^ Knuth, Donald (1974). "Computer Programming as an Art" (PDF). Communications of the ACM. 17 (12): 667–673. doi:10.1145/361604.361612. S2CID 207685720.1974년 튜링상 강의록.
  31. ^ Dijkstra, Edsger W; transcribed by Mario Béland (November 23, 2004) [First published December 3, 1993]. "There is still a war going on (manuscript Austin, 3 December 1993)". E. W. Dijkstra Archive. The University of Texas at Austin, Department of Computer Sciences. Retrieved February 17, 2007. When the term was coined in 1968 by F.L. Bauer of the Technological University of Munich, I welcomed it. [. . .] I interpreted the introduction of the term "software engineering" as an apt reflection of the fact that the design of software systems was an activity par excellence for the mathematical engineer. [. . .]. As soon the term arrived in the USA, it was relieved of all its technical content. It had to be so for in its original meaning it was totally unacceptable [. . .] In the meantime, software engineering has become an almost empty term, as was nicely demonstrated by Data General who overnight promoted all its programmers to the exalted rank of "software engineer"!
  32. ^ "Software Engineering Classification of Software Requirements". GeeksforGeeks. 2018-06-19. Retrieved 2021-05-06.
  33. ^ "Software Engineering Software Design Process". GeeksforGeeks. 2019-05-24. Retrieved 2021-05-06.
  34. ^ "What is Software Maintenance? Definition of Software Maintenance, Software Maintenance Meaning". The Economic Times. Retrieved 2021-05-06.
  35. ^ Abran, Alain, ed. (2005) [2004]. "Chapter 1: Introduction to the Guide". Guide to the Software Engineering Body of Knowledge. Los Alamitos: IEEE Computer Society. ISBN 978-0-7695-2330-9. Retrieved 2010-09-13. The total volume of cited literature is intended to be suitable for mastery through the completion of an undergraduate education plus four years of experience.
  36. ^ "SE2014 Software Engineering Curriculum" (PDF).
  37. ^ 카울링, A. J. 1999년소프트웨어 공학 학사 학위 프로그램의 첫 10년.앤, 소프트우Eng. 6, 1~4(1999년 4월), 61~90년
  38. ^ "ABET Accredited Engineering Programs". April 3, 2007. Retrieved April 3, 2007.
  39. ^ McConnell, Steve(2003년 7월 10일).프로페셔널 소프트웨어 개발: 짧은 스케줄, 고품질 제품, 보다 성공적인 프로젝트, 향상된 경력ISBN 978-0-321-19367-4.
  40. ^ Software Engineering — Guide to the software engineering body of knowledge (SWEBOK), International Organization for Standardization, 2015, retrieved January 11, 2020
  41. ^ Williams, N.S.W. (19–21 February 2001). "Professional Engineers Ontario's approach to licensing software engineering practitioners". Software Engineering Education and Training, 2001 Proceedings. 14th Conference on. Charlotte, NC: IEEE. pp. 77–78.
  42. ^ "NCEES Software Engineering Exam Specifications" (PDF). Archived from the original (PDF) on 2013-08-27. Retrieved 2012-04-01.
  43. ^ "NCEES discontinuing PE Software Engineering exam". National Council of Examiners for Engineering and Surveying. 13 March 2018. Retrieved 6 August 2018.
  44. ^ "SWEBOK Guide Version 3". Retrieved 2015-03-09.
  45. ^ "Software Engineering Code of Ethics" (PDF). Retrieved 2012-03-25.
  46. ^ "Software Developers". Occupational Outlook Handbook. U. S. Bureau of labor Statistics. 4 September 2019. Retrieved 11 December 2019.
  47. ^ "Computing Disciplines and Majors" (PDF). ACM. Retrieved 6 September 2019.
  48. ^ a b "Software Developers: Occupational Outlook Handbook". U.S. Bureau of Labor Statistics.
  49. ^ "Computer Software Engineer". Bureau of Labor Statistics. March 19, 2010. Archived from the original on July 26, 2013. Retrieved July 20, 2012.
  50. ^ "Software Developers". Bureau of Labor Statistics. January 8, 2014. Retrieved July 21, 2012.
  51. ^ a b "Computer Programmers: Occupational Outlook Handbook". U.S. Bureau of Labor Statistics.
  52. ^ a b Rosenthal, Rachel (August 4, 2020). "Tech Companies Want You to Believe America Has a Skills Gap". Bloomberg. Retrieved October 8, 2021.{{cite web}}: CS1 maint :url-status (링크)
  53. ^ "Computer Programmers : Occupational Outlook Handbook: : U.S. Bureau of Labor Statistics". www.bls.gov.
  54. ^ "Archive By Publication : Beyond the Numbers: U.S. Bureau of Labor Statistics". www.bls.gov.
  55. ^ "The Soon-to-Be-Extinct Embedded Software Engineer". designnews.com. May 10, 2018.
  56. ^ "hp's Developer Portal HP International Women's Week: Women in Computer Science dropping since 1980s". developers.hp.com.
  57. ^ "Computer Software Engineers and Computer Programmers". Retrieved 2009-12-17.
  58. ^ "SEI certification page". Sei.cmu.edu. Retrieved 2012-03-25.
  59. ^ Wyrostek, Warren (March 14, 2008). "The Top 10 Problems with IT Certification in 2008". InformIT. Retrieved 2009-03-03.
  60. ^ IEEE Computer Society. "2006 IEEE computer society report to the IFIP General Assembly" (PDF). Retrieved 2007-04-10.
  61. ^ IEEE. "CSDA". Retrieved 2010-04-20.
  62. ^ ACM (July 17, 2000). "A Summary of the ACM Position on Software Engineering as a Licensed Engineering Profession" (PDF). Association for Computing Machinery (ACM). Archived from the original (PDF) on May 17, 2008. Retrieved 2009-03-03. At its meeting in May 2000, the Council further concluded that the framework of a licensed professional engineer, originally developed for civil engineers, does not match the professional industrial practice of software engineering. Such licensing practices would give false assurances of competence even if the body of knowledge were mature; and would preclude many of the most qualified software engineers from becoming licensed.
  63. ^ Canadian Information Processing Society. "I.S.P. Designation". Retrieved 2007-03-15.
  64. ^ "Professional Engineers Ontario: Welcome to PEO's website". Peo.on.ca. Retrieved 2012-03-25.
  65. ^ Thibodaux, Patrick (2006-05-05). "As outsourcing gathers steam, computer science interest wanes". Computerworld.com. Retrieved 2016-12-06.
  66. ^ "Computer Programmers". Bls.gov. Retrieved 2012-03-25.
  67. ^ Mullins, Robert (2007-03-13). "Software developer growth slows in North America". InfoWorld. Archived from the original on 2009-04-04. Retrieved 2012-03-25.
  68. ^ "Gartner Magic Quadrant" (PDF). Cognizant.com. Retrieved 2012-03-25.
  69. ^ Casey, Valentine (2010-08-20). "Virtual software team project management". Journal of the Brazilian Computer Society. 16 (2): 83–96. doi:10.1007/s13173-010-0013-3. S2CID 14383734.
  70. ^ 일부 외부 링크:
  71. ^ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Retrieved 2014-01-10.

원천

추가 정보

외부 링크

Wikimedia Commons에는 소프트웨어 엔지니어링과 관련된 미디어가 있습니다.
Wikdiversity에는 소프트웨어 엔지니어링에 관한 학습 리소스가 있습니다.