위키원
소프트웨어공학
소프트웨어공학(software engineering)은 소프트웨어의 개발, 운용, 유지보수 등의 생명 주기 전반을 체계적이고 서술적이며 정량적으로 다루는 학문이다. 즉, 공학을 소프트웨어에 적용하는 것이다.
소프트웨어 공학의 영어 낱말 software engineering이라는 용어가 처음 나타난 곳은 1968년 나토 소프트웨어 공학 학회로, 당시에는 소프트웨어 위기에 관해 사람들이 주의를 기울여 생각할 것을 장려하기 위해서였다. 그 이후로, 하나의 직업으로서, 또한 학문의 한 분야로서 꾸준히 품질, 비용, 유지 보수성, 빌드 속도가 개선된 소프트웨어를 창조하는데 전념해 왔다. 이 분야는 그 자매 분야인 공학에 비해 아직도 상대적으로 젊은 분야로, 소프트웨어 공학'이란 실제로 무엇이며 전통적인 공학의 정의에 부합하는지에 대한 논의가 이루어지고 있다. 소프트웨어를 단순히 프로그래밍으로만 보는 한계를 벗어나는 것으로부터 유기적으로 성장한 분야이다. 최근의 흐름으로는 관점 지향(Aspect), 애자일(Agile), 모델 주도(Model-Driven) 등이 있다.
컴퓨터 시스템의 가격에서 소프트웨어가 차지하는 비율은, 컴퓨터가 생겨난 직후인 1955년경에는 20% 미만이었지만, 그 후에 급격히 높아져 80년대 후반에는 80~90%에 이르렀다. 이것은 요구되는 소프트웨어의 규모가 커짐에 따라 복잡해진 데 기인한다. 또, 요구되는 소프트웨어가 점차 복잡해진 반면, 그것에 대처할 수 있는 소프트웨어 기술(개발기술 및 관리기술)이 뒤따르지 못하기 때문이다. 그 결과, 소프트웨어는 항상 납기(納期)에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성(透明性)이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 '소프트웨어 위기(危機)'라고 불리는 징후가 나타나기 시작했다. 그 원인으로서, 모든 공학 분야에서 공통된 기본적인 설계절차를 밟지 않고 있다는 지적이 일기 시작하고, 소프트웨어의 개발에 스트럭처드 프로그래밍(structured programming:구조화 프로그래밍)과 같은 공학적 어프로치(approach)가 도입되기에 이르렀다.
소프트웨어에 소요되는 비용을, 계획에서 보수에 이르는 각 단계가 차지하는 비율로 보면, 요구하는 정의(定義) 및 방법의 기술(記述) 단계에 약 10%, 설계단계에 약 10%, 프로그래밍단계에 약 10%, 테스트 및 디버그 단계에 약 20%, 그리고 보수에 소요되는 비용이 약 50%를 차지한다. 검출되는 에러로는, 설계단계 및 그 이전의 것이 약 60%나 된다. 종래까지는 프로그래밍 단계가 강조되었으나, 소프트웨어의 '라이프사이클'을 인식하고 사태를 개선할 필요가 있다. 그러기 위해서는 과학적인 지식을 축적하고, 이를 실제적으로 응용해야 하는데, 이것들을 다루는 분야가 곧 소프트웨어 공학이다.
개념 및 정의[편집]
공학(工學, engineering)이란 일반적으로 과학(科學, science)과 수학을 기초로 하여 구조나 기계, 생산 공정, 시스템 등을 생산에 합리적이고 체계적인 방법을 적용시키는 학문을 말한다. 이러한 공학적 원리에 의하여 소프트웨어를 개발하는 학문이 바로 소프트웨어공학(-工學, software engineering)이다. 즉 소프트웨어공학은 소프트웨어를 분석, 설계, 개발, 운영, 유지보수 등 개발수명주기 전반에 걸친 계획·개발·검사·보수·관리, 방법론 등을 연구하는 분야이며, 개발이전단계(pre-development process), 개발단계(development process), 개발이후 단계(post-development process)로 구분할 수 있다.
지금까지 소프트웨어공학에 대한 정의를 내린 대표적인 인물과 그룹에서의 주장은 다음과 같다.
- ① 프리츠 바우어(Fritz Bauer, 1903~1968)
소프트웨어공학은 컴퓨터 하드웨어에서 신뢰성 있게 운용되는 소프트웨어를 경제성 있게 개발하기 위해 공학적 원리를 응용하고 확립시킨 이론이다.(1972, 제1회 NATO 소프트웨어공학 콘퍼런스)
- ② 베리 보엠(Barry Boehm, 1935~)
소프트웨어공학은 컴퓨터 프로그램을 설계하고 개발하며 운용, 유지보수에 관련된 문서를 작성하는 데 필요한 과학적인 지식을 실제로 적용하는 것이다.(1976, science)
- ③ 국제전기전자기술자협회(IEEE
- Institute of Electrical and Electronics Engineers)
소프트웨어공학은 소프트웨어를 개발하고, 운영하며, 유지보수하고, 폐기하기까지의 과정에 적용되는 시스템적 접근방안이다.(1983, systematic approach)
- ④ 리차드 페얼리(Richard E. Fairley)
소프트웨어공학은 예정 시간과 원가 예측의 범위 안에서, 소프트웨어를 체계적으로 생산하고, 유지보수하기 위한 기술적이며 관리적인 분야로, 전산학(電算學. computer science), 경제학(經濟學, economics), 경영과학(經營科學, management science) 및 의사소통 기술과 문제해결을 위한 공학적인 접근 방안을 토대로 소프트웨어 개발에 임하는 신기술 체계라고 정의하고 있다.(1985, technical & managerial)
공학의 목적은 사용자 요구사항에 맞추어 값싸고 품질 좋은 제품을 개발 기간 내에 개발하는 것이라고 볼 수 있는데, 소프트웨어공학 역시 고품질 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하는 것이 목표이다. ‘최소의 비용’이라 함은 소프트웨어를 최적의 비용으로 계획된 예산에 맞추어 개발하는 것을 의미한다. 또한 소프트웨어는 공정도에 나타난 계획된 기간 내에 개발되어 정해진 날에 정보이용자 및 고객에게 인도되어야한다.
개발과정에는 개발 생명주기 단계별로 관련자(사용자, 개발자, 프로젝트 관리자, 품질관리자 등)들이 참여한 가운데 중간 점검을 통하여 개발이 제대로 되고 있는지 확인하여야 하며 품질에 대한 점검도 필요하다. 특히 여러 부서와 외부 전문회사와 공동으로 여러 사람이 협력하여 소프트웨어를 개발하는 경우에는 전문 프로젝트 관리자에 의한 프로젝트 관리는 물론이고 개발 프로젝트에 대한 다양한 경험이 매우 중요하게 작용한다. 또한 비용과 일정의 문제는 소프트웨어를 생산하는 능률과 직접 관련된다. 따라서 생산성을 높이는 여러 가지 방법론과 도구, 관리 기법들을 통하여 생산성을 높이는 것이 또 하나의 목적이다.
정리하여 말하자면 소프트웨어공학은 소프트웨어의 개발방법을 연구하는 학문으로서 어떻게 하면 생산성이 높은 소프트웨어를 개발하고 품질을 보증함으로써 사용자에게 만족감을 부여할 수 있을 것인가를 연구하는 학문으로 이해할 수 있으며, 컴퓨터공학(-工學, computer engineering)에 필요한 과학적이고 경영학(經營學, business management)적이며 심리학(心理學, psychology)적인 학문을 토대로 체계적인 기술과 방법론을 모색하는 종합 학문이라고 할 수 있다.
오늘날에는 사용자들이 요구하는 소프트웨어가 다양해지고 복잡해짐에 따라 소프트웨어를 개발하거나 구입하는 비용이 급증하면서 이제는 실제 프로그램 개발에 필요한 비용보다는 프로젝트 관리 측면에서 소프트웨어를 개발하고 운영하기까지 소요되는 비용을 어떻게 정확하게 예측하고 효율적으로 관리할 것인가에 대해 관심이 모이고 있다. 또한 소프트웨어 개발과 유지보수에 드는 막대한 비용에 대해 효율적으로 관리하는 것에도 매우 관심을 갖게 되었다. 즉, 소프트웨어 개발과 유지보수에 대한 체계적이고 합리적인 접근방법이 필요하게 되었는데. 이러한 요구를 만족하게 해주는 학문이 소프트웨어공학이 출현하게 된 배경이라고 본다.
역사와 발전단계[편집]
1941년 현대 디지털 컴퓨터가 처음 나타났을 때, 연산 명령은 배선으로 주어졌다. 실무진이 금세 깨달은 것은 이러한 설계 방식이 유연하지 않다는 것이었고 "프로그램 내장 방식" 인 폰 노이만 구조를 개발하였다. 따라서 최초의 구분이 "하드웨어"와 "소프트웨어" 사이에 주어졌고, 전산의 복잡성을 다루기 위해 추상화가 동반되었다.
프로그래밍 언어는 1950년대 나타나기 시작하였으며 이는 또한 추상화를 향한 또 하나의 큰 한걸음이 되었다. 주요 언어 즉 포트란, 알골, 코볼 등이 1950년대 말 배포되어 과학, 알고리즘, 경영상의 문제를 각각 취급하였다. 에츠허르 데이크스트라는 그의 씨앗과 같은 논문 "Go to 문은 해로운 것으로 생각된다"를 1968년 발표하였고 데이빗 파르나스는 열쇠가 된 개념인 모듈성과 정보 은폐를 1972년 소개하여 프로그래머들이 영원히 증가하는 소프트웨어 시스템의 복잡성을 다루는 것에 도움을 주었다. 하드웨어를 관리하는 소프트웨어 시스템인 운영 체제 또한 소개되었고, 그 중 가장 눈에 띄는 것은 1969년에 등장한 유닉스였다. 1967년에는 시뮬라 언어가 객체 지향 프로그래밍 패러다임을 소개하였다.
이러한 소프트웨어의 진보에 발맞추어 컴퓨터 하드웨어도 발전하였다. 1970년대 중반 마이크로컴퓨터가 소개되어 취미로 컴퓨터를 구하고 그 소프트웨어를 작성하는 것이 경제적으로 가능해졌다. 이는 또한 이제는 잘 알려진 개인용 컴퓨터 또는 PC와 마이크로소프트 윈도우로 이어졌다. 소프트웨어 개발 프로세스 또는 SDLC 또한 나타나기 시작하여 1980년대 중반에는 중앙 집중화된 소프트웨어 개발을 위한 일치된 합의로서 자리매김하였다. 1970년대 말과 1980년대 초 시뮬라에서 영감을 받은 몇 개의 새로운 객체 지향 프로그래밍 언어가 나타났다: C++, 스몰토크, 오브젝티브-C.
오픈 소스 소프트웨어는 90년대 초 나타나기 시작하여 리눅스와 "바자 bazaar" 또는 분산형 소프트웨어 개발을 소개하였다. 그러고 나서 인터넷과 월드와이드웹이 90년대 중반을 강타하여 소프트웨어의 공학을 다시 한번 뒤흔들었다. 시스템 설계 방식의 시계추가 분산 시스템쪽으로 기울었고 자바 프로그래밍 언어가 가상 머신으로 추상화의 또 한발짝을 내디뎠다. 참여한 프로그래머들의 공동 작업으로 마련된 애자일(Agile) 성명서는 더 날렵한 개발 프로세스로 더 저렴하고 신속한 개발을 지향하였다.
현재의 소프트웨어 공학의 정의는 오늘날의 실무종사자들이 더 싸게 크게 빠르게 소프트웨어를 개발하고자 수많은 어려움을 뚫고 전진함에 따라 아직도 논쟁 중에 있다.
- 소프트웨어 위기(software crisis)
1960년대 이후 하드웨어의 급속한 발전과 컴퓨터의 대중화에 비교하여 소프트웨어의 개발 및 생산 활동은 매우 저조하여 소프트웨어의 공급과 수요의 격차가 매우 컸다. 1960년대 초기까지는 하드웨어 구매 및 하드웨어 유지보수를 위해 사용되는 비용이 시스템 비용의 전부였던 반면 소프트웨어 구입비용은 거의 무시되었다. 당시 소프트웨어 비용은 매우 작은 것으로 인식하고 있었기 때문에 소프트웨어 개발과정과 소프트웨어 개발비용과 프로젝트 관리 비용은 그다지 중요하게 생각하지 않았다. 그러나 1960대 중반부터 사용자 요구사항이 증대하고 하드웨어의 급속한 발달로 인해 소프트웨어 구축에 드는 비용이 40~50% 정도로 증가하기 시작하였다. 하드웨어 기술은 점점 발달하면서 비용이 하락한 반면에 소프트웨어 개발 인건비는 계속 상승하게 되었는데 이것이 가장 큰 원인이 되었던 것이다.
국내의 경우, 1980년대까지 프로그래머는 생산 업체의 기종 특성에 따라 소프트웨어(시스템 소프트웨어 및 응용 소프트웨어)를 각자 개발했어야 했다. 컴퓨터 하드웨어가 바뀔 때마다 소프트웨어도 대폭 수정하여야 했는데, 이는 컴퓨터 제조업체마다 개방형 구조가 아닌 자기 기종에서 고유의 특수한 문제를 처리하려면 직접 제조회사가 소프트웨어를 제작하여 하드웨어와 함께 고객에게 제공하여야 하는 폐쇄형 구조를 갖고 있었다. 이는 소프트웨어가 범용성을 갖고 대량으로 공급할만한 환경이 되지 못하였음을 의미한다.
1960년 중반부터는 하드웨어 성능이 점점 발전함에 따라 컴퓨터 보급이 증가하게 되었는데, 고가의 하드웨어를 도입하면서부터 소프트웨어에 대한 수요도 늘어나게 되었으며 지속적으로 컴퓨터를 효율적으로 사용해야 한다는 인식 또한 증가하게 되었다.
컴퓨터를 효율적으로 관리하기 위해서 필요로 하는 관련 소프트웨어를 개발하여 생산성을 증가시킬 수 있도록 요구하게 되었다. 이때부터 수요자 즉 사용자의 요구는 다양해지고 복잡해진 반면 소프트웨어 생산성을 높일 수 있는 기술과 전문 인력이 절대적으로 필요로 하여 공급이 수요를 충족하지 못해서 생산성에 대해 심각하게 우려하고 걱정하게 되었는데 이것을 '소프트웨어 위기(software crisis)'라는 단어로 표현하게 되었다. 당시 생산성 문제와 관련해서 소프트웨어 개발에 있어서는 다음과 같은 문제점을 안고 있었다.
① 개발 예산의 초과와 개발 기간의 지연
프로젝트 계획 수립단계에 소프트웨어 개발 일정과 비용에 대한 예측이 부정확하게 계획된 경우이다. 개발 조직 내에 과거의 유사 프로젝트에 대한 정보와 데이터가 없었거나 전문성과 기술 및 경험이 없는 프로젝트 관리자가 프로젝트를 계획, 추진하였기 때문이다.
② 프로그래머 개인의 판단과 역량에 의한 소프트웨어 개발 추진
소프트웨어 개발과 관련된 공학적 원리와 개발방법 및 표준에 의해 추진되는 것이 아니라 프로그래머 개인의 기술 및 경험과 역량에 좌우되어 추진된 경우이다. 이는 주관적 판단에 의한 예측과 개발 작업을 통해 발생된 판단 오류 등으로 인해 개발이 실패되곤 했었다. 즉 소프트웨어 개발 및 생산에 있어 엔지니어링 원리가 적용되기보다는 프로그래머 개인의 독창성에 의존하였고 효율적인 프로젝트 계획과 관리의 중요성을 외면한 상태로 소프트웨어를 개발한 것이 문제가 되었다.
③ 소프트웨어 품질에 있어서의 문제
소프트웨어 개발에 있어 단계별로 체계적이고 기술적인 검토 및 시험과정을 거치지 않고 완성된 소프트웨어에 대해 신뢰성에 문제점을 보인 경우이다. 자체적으로나 외부의 전문가 및 전문기관을 이용한 품질보증 활동이 미흡한 경우에 발생된다. 이러한 위기를 극복하기 위한 제반문제를 해결하려는 노력과 배경이 소프트웨어공학이라는 학문을 통해 연구되고 개발되어야 하는 필요성으로 대두하게 되었다. 즉 소프트웨어공학은 공학적인 접근 방법으로 원리를 적용하고 체계적인 개발을 통해 생산성 문제, 품질 문제, 관리 문제 등을 해결하려는 노력의 결정체이다.
- 소프트웨어공학의 발전추이
- 1970년대 초 [구조적 프로그래밍]
- • 구조적 코딩
- • 하향식 프로그래밍
- • 정보은닉(Parnas)
- • 추상화(Dijkstra)
- • 단계적 세분화(Wirrth)
- 1970년대 중 [설계방법론]
- • 구조적 설계(Yourdon과 Constantine)
- • Warnier-Orr 설계방법
- • JSP 설계방법(Jackson)
- 1970년대 말[분석방법론]
- • 자료흐름지향(구조적) 분석(Yourdon, Demarco, Gane, Sarson)
- • 자료구조지향(구조적) 분석(J. D. Warnier, M. A. Jackson)
- 1980년대 초[자동화 도구 및 객체지향 설계 및 프로그래밍]
- • PSL/PSA
- • 코드 자동 생성
- • 소프트웨어공학 도구
- • 객체 지향 설계
- • Smaltalk, Ada, Modula-2
- 1980년대 말 [컴퓨터응용 소프트웨어공학]
- • 분석을 위한 대화식 그래픽 도구
- • 통합 소프트웨어공학 환경
- • 프로그래밍 환경
- • 인터페이스 관리 시스템
- 1990년대 초 [객체지향 소프트웨어공학]
- • 객체지향 프로그래밍 언어
- • 객체지향 분석 및 설계
- • 프로그래밍 환경
- • 소프트웨어 재사용 시스템
- 2000년대 현재 [임베디드 및 컴포넌트 소프트웨어공학]
- • UML
- • JAVA
- • Embedded S/W
- • Component S/W
교육[편집]
프로그래밍에 관한 지식이 소프트웨어 공학자가 되기 위한 주요한 선수 요건이다. 그러나 그것만으로는 부족하다. 많은 소프트웨어 공학자들은 컴퓨터 과학 학위를 가지고 있으며 진정한 소프트웨어 공학자의 부족을 지적하는 의견도 있다. 왜냐하면 소프트웨어 공학 프로그램이 고등 교육에 빠져 있었기 때문이다. 그러나 새로이 소프트웨어 공학 학위가 특히 학부 이후 학위로 소개되었다. 표준 국제 학부 교육과정은 CCSE에서 정의한 바 있다.
2004년 IEEE 컴퓨터 학회는 SWEBOK을 내놓았고 소프트웨어 공학자가 알아야 할 지식의 범위에 대한 표준 ISO/IEC 24773으로 채택되었다.
유럽 위원회는 에라스무스 문두스 프로그램 안에 소프트웨어 공학 유럽 석사 학위를 유럽내외로부터의 학생들에게 제공하고 있다. 이는 복수 전공 프로그램으로 유럽 내의 4개 학교가 관련되어 있다.
접근방법 및 주요 연구영역[편집]
접근방법[편집]
스프트웨어공학에서는 구조적방법론, 정보공학적방법론, 객체지향방법론, CBD방법론 등을 이용하여 소프트웨어 수명주기에 따라 개발한다. 소프트웨어공학의 뉴 패러다임은 이제 '객체지향(object oriented)'이자 '컴포넌트(component)'이다. 소프트웨어는 '객체'라는 새로운 시각으로 파악된 대상들로 구조화되고 객체 구조만이 지니는 다양한 속성들을 이용하여 프로그래밍의 생산성과 효율을 높인다. 소프트웨어의 개발은 반복적이고, 점진적으로 진행되게 되어 빠르게 개발하고 실패의 위험도 크게 줄일 수 있게 되었다. 이것은 소프트웨어의 컴포넌트화 라는 개발기술에도 영향을 주어 재사용성과 유지보수에 큰 이점을 갖게 된다. 이것은 농업 사회에서 공업 사회로 발전한 것만큼이나 큰 발전이 아닐 수 없다.
소프트웨어공학의 연구영역[편집]
소프트웨어공학에서는 요구공학(要求工學, requirements engineering), 아키텍처(architecture), 개발방법론, 테스팅(testing), 프로세스, 형상관리, 품질관리(品質管理, quality control), 재사용 등에 대한 연구가 활발하게 이루어지고 있다.
- (1) 요구공학
요구공학 분야는 소프트웨어 개발에서 수행되는 첫 번째 작업인데, 개발될 시스템에 대한 고객의 요구를 이해하고 목표와 제약사항을 확립하여 시스템을 만족시킬 기능, 성능 그리고 다른 시스템과의 인터페이스 등을 정의하는 과정이며, 비용 증가, 납기 지연, 품질 저하를 방지하기 위한 필수 요건이 된다, 이 분야에서는 주로 요구사항의 추출, 저장, 변경 프로세스 및 요구사항 관리 지원 도구 등이 연구되고 있다.
- (2) 아키텍처
아키텍처 분야는 아키텍처 구성 요소와 이 구성 요소들 간의 관계, 그리고 시스템의 기능, 속성 및 제약사항 등을 적절히 반영하는 구조가 서로 조직화된 것으로 목표 시스템의 전체적인 형태를 표현한 것이다. '적절히 반영하는 구조'라는 것은 기존의 아키텍처 스타일을 문제 영역에 적절하게 변형 또는 조합하여 해당 스타일에서 언급하는 컴포넌트와 커넥터(connector)로 시스템을 분할하여 구조화하는 것을 말한다. 여기서는 주로 아키텍처의 유형분류, 아키텍처의 정의 언어, 아키텍처 분석방법론 등이 연구되고 있다.
- (3) 개발방법론
개발방법론 분야는 시스템을 개발하기 위해 어떠한 방법으로 진행할 것인가를 다루는 분야로서 구조적방법론, 정보공학적방법론, 객체지향방법론, 컴포넌트방법론 등이 있다. 개발 기술의 진화에 따라 계속적으로 연구, 발전되고 있으며, 개발조직의 특성 및 여건에 맞게 조정/재정의 될 수 있다.
- (4) 테스팅
테스팅 분야는 모듈(module) 단위의 단위 테스팅, 시스템 통합 시에 사용되는 통합 테스팅, 요구사항을 검증하는 시스템 테스팅 등이 있다. 소프트웨어 규모가 커지면서 전수 테스팅이 불가능하기 때문에 효과적인 테스트 케이스 산출 방법론은 반드시 연구되어야 하는 과제이다. 개발방법론에 따라 테스팅 방법도 달라져야 하므로 각 개발 방법론(구조적, 정보공학(情報工學, information engineering), 객체지향, 컴포넌트방법론) 및 분산 환경에서의 다양한 테스트 방법이 연구되고 있다.
- (5) 프로세스
프로세스는 소프트웨어의 개발 및 진화에 사용되는 활동, 방법 및 실무 활동(practice)들의 집합으로 일반적으로는 최종 소프트웨어 제품을 생산하기 위하여 요구되는 인력, 절차, 방법, 장치 및 도구 들을 통합하는 수단을 말한다. 이 분야에서는 프로세스의 정의방법, 프로세스 관리조직 및 관리기반 구조 등이 주로 연구되고 있다. 또한 소프트웨어 프로세스의 특성을 설명하는 모형 및 효과적인 소프트웨어 프로세스 실현을 위한 단계적 접근 방법을 명시하는 모델에 관해 연구되고 있다.
- (6) 형상관리
형상관리 분야에서는 소프트웨어 구성요소에 대한 변경관리 대상인 형상항목을 식별하고 변경을 통제, 기록하게 되는데 이때 형상식별, 형상통제, 형상상태 확인, 형상감사 등의 활동 등을 연구한다.
- (7) 품질관리
품질관리 분야는 소프트웨어 분야에서 품질은 제품 품질(product quality)과 프로세스 품질(process quality)로 분류된다. 제품 품질은 제품 자체가 가지는 품질을 의미하며, 프로세스 품질은 소프트웨어를 개발하는 프로세스가 정확하고 우수하면 좋은 품질의 소프트웨어를 생산할 가능성이 높다는 것을 의미하며, 제품 품질의 보증을 위한 SQA(Software Quality Assurance)활동, 제품 검사, 검토 등을 지원하는 평가모델, 국제표준 등이 연구되고 있다.
- (8) 재사용
소프트웨어에서 재사용하는 지식은 코드뿐만 아니라 응용 분야에 관한 지식, 개발 경험, 설계에 관한 결정, 시스템에 대한 지식, 요구분석 사항, 설계, 문서 등도 포함될 수 있다. 재사용 분야에서는 코드 재사용의 한계를 극복하기 위해 코딩 단계 이전의 분석 설계 단계에서 만들어진 산출물을 재사용하려는 노력을 계속하고 있다.
참고자료[편집]
같이 보기[편집]
