소프트웨어 엔지니어링의 역사

History of software engineering
컴퓨팅의 역사
Ordinateurs centraux 348-3-006.jpg
하드웨어
소프트웨어
컴퓨터 공학
현대 개념
국가별
컴퓨팅 스케줄
컴퓨터 과학 용어집
이 문서에서는 소프트웨어 개발에 대한 하나의 접근법이라는 의미에서 소프트웨어 엔지니어링 분야를 다루고 있습니다.이 용어는 동의어로 사용되는 경우가 있습니다.

소프트웨어 공학의 역사는 1960년대에 시작되었다.쓰기 소프트웨어는 소프트웨어의 품질을 극대화하는 최선의 방법 및 소프트웨어의 작성 방법에 관한 전문직으로 발전해 왔습니다.품질은 소프트웨어의 안정성, 속도, 조작성, 테스트성, 가독성, 크기, 비용, 보안, 결함의 수, 기타 많은 특성 중 우아함, 일관성, 고객 만족도 등의 측정 불가능한 품질을 나타냅니다.고품질 소프트웨어를 만드는 최선의 방법은 소프트웨어 설계 원칙, 이른바 코드 작성의 베스트 프랙티스, 최적의 팀 규모, 프로세스, 소프트웨어를 가능한 한 신속하게 제때 제공하는 방법, 워크플레이스에서의 문화, 고용 관행 등 광범위한 관리 문제를 망라하여 논란이 되고 있습니다.이 모든 것이 소프트웨어 [1]엔지니어링의 광범위한 영역에 속합니다.

개요

소프트웨어 엔지니어링의 진화는 다음과 같은 여러 영역에서 두드러집니다.

  • 직업으로서의 등장:1980년대 초에 소프트웨어 공학은 이미 컴퓨터 공학이나 전통적인 [citation needed]공학에 뒤지지 않는 진정한 직업으로 부상했다.[2]
  • 여성의 역할:1970년 이전에는 더 명망 있고 더 나은 보수를 받는 하드웨어 엔지니어링 역할을 하는 남자들이 종종 여성들에게 소프트웨어 작성을 위임했고 그레이스 호퍼나 마가렛 해밀턴과 같은 전설들이 많은 컴퓨터 프로그래밍 [3][4]직업을 채웠다.
    오늘날 소프트웨어 엔지니어링 분야에서 일하는 여성은 다른 직업에 비해 적으며, 그 원인은 명확하게 밝혀지지 않았다.많은 학계와 전문 기관들은[who?] 이 상황을 불균형하다고 생각하고 그것을 [5]해결하기 위해 열심히 노력하고 있다.
  • 프로세스:프로세스는 소프트웨어 엔지니어링의 큰 부분이 되었습니다.그들은 소프트웨어를 개선할 수 있는 잠재력 때문에 환영받지만 [citation needed]프로그래머를 제약할 수 있는 잠재력 때문에 혹평을 받고 있다.
  • 하드웨어 비용:소프트웨어와 하드웨어의 상대적 비용은 지난 50년간 크게 변화했습니다.메인프레임이 비싸고 대규모 지원 인력이 필요했던 시기에는 메인프레임을 구입하는 소수의 조직도 크고 비용이 많이 드는 커스텀 소프트웨어 엔지니어링 프로젝트에 자금을 지원할 수 있는 자원을 확보했습니다.컴퓨터는 이제 훨씬 더 많이, 훨씬 더 강력해졌고, 이것은 소프트웨어에 몇 가지 영향을 끼친다.큰 시장에서는 마이크로소프트와 같은 기업이 수행하는 것처럼 상용 소프트웨어를 생성하기 위한 대규모 프로젝트를 지원할 수 있습니다.값싼 기계 덕분에 각 프로그래머는 꽤 빠른 컴파일을 할 수 있는 단말기를 가질 수 있다.문제의 프로그램들은 가비지 수집과 같은 기술을 사용할 수 있어 프로그래머가 쉽고 빠르게 쓸 수 있다.한편, 대규모 커스텀 소프트웨어 프로젝트에 프로그래머를 고용하는 조직은 훨씬 적습니다.대신 상용 소프트웨어를 가능한 [citation needed]한 많이 사용하고 있습니다.

1945년부터 1965년까지:기원

소프트웨어 엔지니어링이라는 용어는 1965년 ACM 사장 Anthony Oettinger가 [6][7]보낸 서한과 Douglas T의 강연에서 유래했습니다. 1950년대 [8]MIT 로스입니다마가렛 H. 해밀턴은 "정당성을 [9][10]부여하기 위한 방법으로 그 분야를 소프트웨어 공학이라고 명명하는 아이디어를 생각해 낸 사람이다."

NATO 과학 위원회는 1968년 소프트웨어 엔지니어링에 관한 두 개의[11] 회의(Garmisch, Germany – Conference Report 참조)와 1969년 이 분야를 처음으로 활성화시켰습니다.많은 사람들은 이러한 컨퍼런스가 소프트웨어 엔지니어링 [6][12]분야의 공식적인 시작을 의미한다고 믿고 있습니다.

1965년부터 1985년까지:소프트웨어 위기

소프트웨어 엔지니어링은 1960년대, 1970년대 및 1980년대의 이른바 소프트웨어 위기에 의해 촉진되었습니다.이 위기는 소프트웨어 개발의 많은 문제를 식별했습니다.많은 프로젝트들이 예산과 일정을 초과하여 진행되었습니다.일부 프로젝트는 재산 피해를 야기했다.몇 개의 프로젝트가 인명 손실을 [13]초래했다.소프트웨어 위기는 원래 생산성 측면에서 정의되었지만 품질을 강조하기 위해 진화했습니다.일부에서는 소프트웨어 위기라는 용어를 자격 [citation needed]있는 프로그래머를 충분히 고용할 수 없다는 의미로 사용했습니다.

  • 비용 및 예산 초과:OS/360 운영체제는 전형적인 예입니다.1960년대부터 10년 동안 지속된 이 프로젝트는 결국 [12]당시 가장 복잡한 소프트웨어 시스템 중 하나를 생산했습니다.OS/360은 최초의 대규모(1000명의 프로그래머[citation needed]) 소프트웨어 프로젝트 중 하나였습니다.Fred Brooks는 The Infired Man-Month에서 [12]개발을 시작하기 전에 일관성 있는 아키텍처를 개발하지 않는 수백만 달러의 실수를 저질렀다고 주장한다.
  • 재산 피해:소프트웨어 결함으로 인해 재산 손해가 발생할 수 있습니다.허술한 소프트웨어 보안을 통해 해커들은 ID를 도용하여 시간, 비용 및 평판을 [citation needed]희생시킬 수 있습니다.
  • 생사: 소프트웨어 결함으로 사망할 수 있습니다.방사선 치료기에 사용되는 일부 임베디드 시스템은 치명적으로 고장나 환자에게 치사량의 방사선을 투여했다.이러한 실패들 중 가장 유명한 것은 Therac-25 [14]사건이다.

피터 G. Neumann은 소프트웨어 문제와 [15]재해에 대한 동시대의 목록을 보유하고 있습니다.소프트웨어 위기는 심리적으로 장기(20년 이상) 위기 모드를 유지하는 것이 매우 어렵기 때문에 시야에서 멀어지고 있다.그러나 소프트웨어(특히 실시간 임베디드 소프트웨어)는 여전히 위험성이 높고 널리 보급되어 있기 때문에 안주하지 않는 것이 중요합니다.지난 10-15년간 마이클 A. Jackson은 소프트웨어 엔지니어링의 본질에 대해 폭넓게 집필하고 있으며, 문제의 원인을 전문화의 결여로 파악하고 있으며, 그의 문제 프레임이 소프트웨어 엔지니어링의 "통상적인 관행"의 기초를 제공한다고 제안하고 있습니다.이것은 소프트웨어 엔지니어링이 [16]공학이 되기 위한 전제 조건입니다.

1985~1989년: "No Silver Bullet"

수십 년 동안 소프트웨어 도구를 생산하는 연구자와 기업은 소프트웨어 위기를 해결하는 것이 가장 중요했습니다.1980년대에 소프트웨어를 소유하고 유지하는 데 드는 비용은 소프트웨어 [citation needed]개발 비용보다 두 배 더 비쌌습니다.

  • 1990년대 동안 소유 비용과 유지 보수 비용은 1980년대에 비해 30% 증가했습니다.
  • 1995년 통계에 따르면 조사 대상 개발 프로젝트의 절반은 운영 중이었지만 성공적이지 못한 것으로 나타났다.
  • 평균적인 소프트웨어 프로젝트는 스케줄을 절반 초과합니다.
  • 고객에게 제공되는 모든 대규모 소프트웨어 제품의 4분의 3은 전혀 사용되지 않거나 고객의 요건을 충족하지 못하는 장애입니다.

소프트웨어 프로젝트

1970년대부터 1990년대까지 모든 신기술과 실천이 소프트웨어 위기를 해결할 수 있는 은빛 총알로 부각된 것 같다.도구, 규율, 공식 방법, 프로세스 및 전문성은 은빛 [citation needed]총알로 선전되었습니다.

  • 툴: 특히 강조된 툴은 구조화 프로그래밍, 객체 지향 프로그래밍, ICL의 CADS CASE 시스템,[17] Ada, 문서, 표준 등의 CASE 툴이었습니다.
  • 부문:일부 전문가들은 소프트웨어 위기가 프로그래머들의 규율 부족 때문이라고 주장했다.
  • 정식 방법: 일부에서는 정식 엔지니어링 방법론을 소프트웨어 개발에 적용하면 소프트웨어 생산도 엔지니어링의 다른 부문과 마찬가지로 예측 가능한 산업이 될 것이라고 생각했습니다.그들은 모든 프로그램이 정확하다는 것을 증명해야 한다고 주장했다.
  • 프로세스:많은 사람들이 역량 성숙도 모델과 같은 정의된 프로세스와 방법론의 사용을 지지했습니다.
  • 전문성:이것은 윤리, 면허, 전문성 강령에 대한 작업으로 이어졌다.

1986년 Fred Brooks는 No Silver Bullet 기사를 발표하면서 개인의 [citation needed]기술이나 실천이 10년 이내에 생산성을 10배 향상시키지 못할 것이라고 주장했습니다.

그 후 10년 동안 은탄에 대한 논쟁이 맹위를 떨쳤다.Ada, 컴포넌트 및 프로세스의 지지자들은 자신들이 가장 좋아하는 테크놀로지가 은빛 총알이 될 것이라고 오랫동안 주장했습니다.회의론자들은 동의하지 않았다.결국, 거의 모든 사람들이 은빛 총알이 발견되지 않을 것이라는 것을 받아들였다.하지만 은탄에 대한 주장은 지금도 [citation needed]종종 나온다.

소프트웨어[who?] 엔지니어링이 [clarification needed]실패했다는 의미로 해석하는 사람도[why?] 있다.하지만, 더 읽으면서, 브룩스는 계속 말한다: "우리는 분명 앞으로 40년 동안 상당한 진전을 이룰 것이다; 40년 이상의 규모가 마법 같은 것은 거의 아니다."[citation needed]

성공의 단 하나의 열쇠를 찾는 것은 결코 효과가 없었다.알려진 모든 기술과 관행은 생산성과 품질을 점진적으로 개선했을 뿐입니다.하지만, 다른 직업에도 은탄은 없다.소프트웨어 엔지니어링이 마침내 성숙했다는 증거로 해석하고, 열심히 [citation needed]일한 덕분에 프로젝트가 성공한다는 것을 인식한다는 증거로 해석하는 이들도 있습니다.

그러나 실제로 오늘날에는 경량 방법론('프로젝트 관리' 참조), 스프레드시트 계산기, 커스터마이즈 브라우저, 온사이트 검색 엔진, 데이터베이스 보고서 생성기, 메모리/차이/언도 포함 통합 설계 테스트 코딩 편집기, 전문 상점 등 다양한 장점이 있다고 할 수 있습니다.정보 웹 사이트와 같은 틈새 소프트웨어를 완전히 맞춤형 웹 사이트 개발 비용의 극히 일부에 불과합니다.그러나 소프트웨어 엔지니어링 분야는 하나의 "실버 글머리 기호"로 대부분의 문제를 개선하기에는 너무 복잡하고 다양하며, 각각의 문제가 모든 소프트웨어 문제의 [citation needed]극히 일부에 불과합니다.

1990~1999년: 인터넷의 중요성

인터넷의 발달로 인해 월드 와이드 웹의 국제 정보 표시/이메일 시스템에 대한 수요가 매우 빠르게 증가했습니다.프로그래머는 지금까지 볼 수 없었던 속도로 일러스트, 지도, 사진 및 기타 이미지와 간단한 애니메이션을 처리해야 했습니다.이미지 표시/스토리지 최적화 방법은 거의 없었습니다(예: 섬네일 [citation needed]이미지 사용).

HyperText Markup Language(HTML)에서 실행되는 브라우저의 사용 증가는 정보 표시 및 검색의 구성 방식을 변화시켰습니다.네트워크 접속의 확산은 MS Windows 컴퓨터에서의 국제적인 컴퓨터 바이러스의 성장과 예방으로 이어졌습니다.또한 스팸 메일의 급증은 전자 메일 시스템의 주요 설계상의 문제가 되어, 통신 채널이 범람해, 반자동의 사전 스크리닝이 필요하게 되었습니다.키워드 검색 시스템은 웹 기반 검색 엔진으로 발전했고, 많은 소프트웨어 시스템은 검색 엔진 최적화(SEO)에 따라 국제적인 검색을 위해 재설계되어야 했다. 인간의 자연 언어 번역 시스템은 여러 외국어로 정보 흐름을 번역하기 위해 필요했고, 많은 소프트웨어 시스템도 필요했습니다.사용자 번역자의 디자인 컨셉에 따라 다국어 사용을 위해 설계되었습니다.일반적인 컴퓨터 사용자 기반은 수백 또는 수천 명의 사용자에서 수백만 명의 해외 [citation needed]사용자로 확대되었습니다.

2000~2015: 경량화 방법론

많은 소규모 조직에서 소프트웨어에 대한 수요가 증가함에 따라 저렴한 소프트웨어 솔루션에 대한 수요는 요구 사항에서 도입에 이르기까지 소프트웨어를 보다 빠르고 빠르게 개발하는 단순하고 빠른 방법론의 증가로 이어졌습니다.고속 프로토타이핑의 사용은 Extreme Programming(XP)과 같은 경량 방법론 전체로 발전했습니다.XP는 소프트웨어 엔지니어링의 많은 분야를 단순화하려고 시도했습니다.이 분야에는 증가하는 소규모 소프트웨어 시스템에 대한 요구사항 수집 및 신뢰성 테스트도 포함됩니다.매우 큰 소프트웨어 시스템은 여전히 문서화된 방법론을 많이 사용하고 있으며, 문서 세트에는 많은 볼륨이 포함되어 있습니다.그러나 소규모 시스템에서는 소프트웨어 계산과 알고리즘, 정보 저장/검색 및 [citation needed]디스플레이의 개발과 유지보수를 보다 단순하고 빠르게 관리할 수 있었습니다.

소프트웨어 엔지니어링의 최신 동향

소프트웨어 엔지니어링은 아직 젊은 분야이며 아직 발전 중입니다.소프트웨어 엔지니어링의 개발 방향은 다음과 같습니다.[citation needed]

양상

이러한 측면은 소프트웨어 엔지니어가 소스 코드의 많은 영역에서 보일러 플레이트 코드를 추가하거나 제거하는 도구를 제공함으로써 품질 속성을 처리하는 데 도움이 됩니다.측면은 모든 개체 또는 기능이 특정 상황에서 어떻게 동작해야 하는지를 설명합니다.예를 들어 특정 유형의 모든 개체에 디버깅, 로깅 또는 잠금 제어를 추가할 수 있습니다.연구자들은 현재 범용 코드를 설계하기 위해 측면을 사용하는 방법을 이해하기 위해 노력하고 있습니다.관련 개념으로는 생성 프로그래밍과 템플릿이 있습니다.

실험적인

실험 소프트웨어 공학은 소프트웨어에 대한 실험을 고안하고, 실험으로부터 데이터를 수집하고, 이 데이터에서 법칙과 이론을 고안하는 데 관심이 있는 소프트웨어 공학 분야입니다.이 방법의 지지자들은 소프트웨어의 특성이 우리가 오직 [citation needed]실험을 통해서만 소프트웨어에 대한 지식을 발전시킬 수 있는 것이라고 주장한다.

소프트웨어 제품 라인

소프트웨어 제품 라인(일명 제품 패밀리 엔지니어링)은 일련의 개별 제품을 만드는 것이 아니라 소프트웨어 시스템 패밀리를 만드는 체계적인 방법입니다.이 방법은 소프트웨어 개발 프로세스를 산업화하기 위해 광범위하고 체계적인 정식 코드 재사용을 강조합니다.

ICSE 2000에서 개최된 Future of Software Engineering Conference(FOSE)는 2000년 SE의 최신 기술을 문서화하고 향후 10년간 해결해야 할 많은 문제를 나열했습니다.ICSE 2000 및 ICSE 2007[19] 회의에서의 FOSE 트랙도 소프트웨어 엔지니어링의 [citation needed]최신 기술을 식별하는 데 도움이 됩니다.

현재의 소프트웨어 엔지니어링

그 직업은 그것의 경계와 내용을 정의하려고 노력하고 있다.SWEBOK의 소프트웨어 엔지니어링 본부는 2006년에 ISO 표준으로 채택되었습니다(ISO/IEC TR [citation needed]19759).

2006년 Money Magazine과 Salary.com은 소프트웨어 엔지니어링을 성장, 임금, 스트레스 수준, 시간 및 작업 환경의 유연성, 창의성, 그리고 이 [20]분야의 진출 및 진출의 용이성 측면에서 미국 최고의 직업으로 평가했습니다.

하위 분야

인공지능

Cyc와 같은 전문가 시스템부터 딥러닝 프레임워크, 개방형 [21]인터페이스를 갖춘 Roomba와 같은 로봇 플랫폼까지 다양한 AI의 다양한 측면이 개발되었습니다.최근 심층 인공 신경 네트워크와 분산 컴퓨팅의 진보는 Deeplearning4j, TensorFlow, Therano 및 Torch를 포함한 소프트웨어 라이브러리의 증가로 이어지고 있습니다.

2011년 McKinsey Global Institute의 조사에 따르면 150만 명의 고도로 훈련된 데이터 및 AI 전문가와[22] 매니저가 부족하다는 것을 알 수 있으며, 다수의 사설 부트캠프가 이러한 수요를 충족시키기 위해 Data Incubator와 같은 무료 프로그램이나 General [23]Assembly와 같은 유료 프로그램을 포함하여 프로그램을 개발했습니다.

언어들

주요 기사:인공지능 프로그래밍 언어 목록

초기의 상징적 AI는 초기 AI 프로그래밍을 지배했던 리스프와 프롤로그에 영감을 주었다.현대의 AI 개발은 파이썬이나 C++[24]와 같은 주류 언어나 울프램 [25]언어 같은 틈새 언어를 사용하는 경우가 많습니다.

소프트웨어 엔지니어링 역사상 저명한 인물

  • 찰스 바크만(1924–2017)은 데이터베이스 분야에서의 그의 업적으로 특히 유명하다.
  • 1980년대 IEEE Transactions on Software Engineering 편집장 LaaSlady(1928년생).
  • Fred Brooks(1931년생)는 OS/360 개발을 관리하는 것으로 가장 잘 알려져 있습니다.
  • 개체 관계 모델링 개발로 알려진 Peter Chen(1947년생).
  • Edsger W. Dijkstra(1930–2002)는 구조화된 프로그래밍의 형태를 위한 프레임워크를 개발하였다.
  • David Parnas(1941년생)는 모듈러 프로그래밍에 숨어 있는 정보의 개념을 개발했다.
  • 마이클 A. Jackson(1936년생), JSP 프로그램 설계 방법, JSD 시스템 개발 방법(John Cameron과 함께), 소프트웨어 개발 문제를 분석하고 구조화하는 문제 프레임 접근방식을 책임지고 있습니다.
  • Richard Stallman은 GNU 시스템 유틸리티를 만들고 무료 소프트웨어를 옹호했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "CS302: Jared King's "The History of Software"". learn.saylor.org. Retrieved 2018-02-17.
  2. ^ "소프트웨어 엔지니어링은 최근 그 자체로 하나의 분야로 부상하고 있습니다."
  3. ^ Abbate, Janet (2012). Recoding Gender. Cambridge, MA: MIT Press. pp. 39. ISBN 978-0262534536.
  4. ^ Ensmenger, Nathan (2012). The Computer Boys Take Over. Cambridge, MA: MIT Press. ISBN 978-0262517966.
  5. ^ "Episode 576: When Women Stopped Coding". NPR Planet Money. Oct 17, 2014. Retrieved June 27, 2018.
  6. ^ a b Meyer, Bertrand (April 4, 2013). "The origin of "software engineering"". Retrieved 2016-11-25.
  7. ^ Tadre, Matti (2014-12-03). The Science of Computing. CRC Press. p. 121. ISBN 978-1-4822-1770-4.
  8. ^ Mahoney, Michael. "The Roots of Software Engineering" (PDF). CWI Quarterly. 3 (4): 325–334. Retrieved Jun 4, 2015.
  9. ^ 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 Jun 2018.
  10. ^ Rayl, A.J.S. (October 16, 2008). "NASA Engineers and Scientists-Transforming Dreams Into Reality". NASA 50th anniversary website. NASA. Retrieved 2016-11-25.
  11. ^ Brian Randell (2001). "NATO Software Engineering Conferences". ncl.ac.uk. Retrieved 2016-11-25.
  12. ^ a b c King, Jared (2016). "Jared King's "The History of Software"". CS302: Software Engineering. Saylor.org. Retrieved 2016-11-25.
  13. ^ 테라크-25
  14. ^ Leveson, N.G.; Turner, C.S. (1993-07-01). "An investigation of the Therac-25 accidents". Computer. 26 (7): 18–41. CiteSeerX 10.1.1.372.412. doi:10.1109/MC.1993.274940. ISSN 0018-9162. S2CID 9691171.
  15. ^ Neumann, Peter G. "RISKS-LIST: RISKS-FORUM Digest". The Risks Digest.
  16. ^ {마이클 잭슨, S Nanz ed, 소프트웨어 엔지니어링의 미래, Springer Verlag 2010, 마이클 잭슨, 문제 프레임:소프트웨어 개발 문제 분석 및 구조화; Adison-Wesley, 2001}
  17. ^ D.J. 피어슨 "소프트웨어 엔지니어링 시스템의 사용과 남용" 1979년 전미 컴퓨터 회의
  18. ^ "ICSE2000: Call for Participation". ul.ie.
  19. ^ "ICSE 2007: Home". ucl.ac.uk.
  20. ^ MONEY Magazine과 Salary.com은 성장, 임금, 스트레스 해소 및 기타 요인을 고려하여 수백 개의 일자리를 조사했습니다Kalwarski, Tara; Daphne Mosher; Janet Paskin; Donna Rosato (2006). "Best Jobs in America". MONEY Magazine. CNN. Retrieved 2006-04-20..이들 경력은 가장 높은 순위를 차지했습니다.1 . 소프트웨어 엔지니어..."
  21. ^ "Hacking Roomba". hackingroomba.com. Archived from the original on 18 October 2009.
  22. ^ Manyika, James; Chui, Michael; Bughin, Jaques; Brown, Brad; Dobbs, Richard; Roxburgh, Charles; Byers, Angela Hung (May 2011). "Big Data: The next frontier for innovation, competition, and productivity". McKinsey Global Institute. Archived from the original on 6 March 2013. Retrieved 16 January 2016. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  23. ^ "NY gets new boot camp for data scientists: It's free but harder to get into than Harvard". Venture Beat. Archived from the original on 15 February 2016. Retrieved 21 February 2016.
  24. ^ "C++ Java". infoworld.com. Retrieved 6 December 2017.
  25. ^ Ferris, Robert (7 April 2016). "How Steve Jobs' friend changed the world of math". CNBC. Retrieved 28 February 2018.

외부 링크