소프트웨어공학
[ Software Engineering ]목차
1. 개념 및 정의
공학(工學, 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)적인 학문을 토대로 체계적인 기술과 방법론을 모색하는 종합 학문이라고 할 수 있다.
오늘날에는 사용자들이 요구하는 소프트웨어가 다양해지고 복잡해짐에 따라 소프트웨어를 개발하거나 구입하는 비용이 급증하면서 이제는 실제 프로그램 개발에 필요한 비용보다는 프로젝트 관리 측면에서 소프트웨어를 개발하고 운영하기까지 소요되는 비용을 어떻게 정확하게 예측하고 효율적으로 관리할 것인가에 대해 관심이 모이고 있다. 또한 소프트웨어 개발과 유지보수에 드는 막대한 비용에 대해 효율적으로 관리하는 것에도 매우 관심을 갖게 되었다. 즉, 소프트웨어 개발과 유지보수에 대한 체계적이고 합리적인 접근방법이 필요하게 되었는데. 이러한 요구를 만족하게 해주는 학문이 소프트웨어공학이 출현하게 된 배경이라고 본다.
2. 역사와 발전단계
1960년대 이후 하드웨어의 급속한 발전과 컴퓨터의 대중화에 비교하여 소프트웨어의 개발 및 생산 활동은 매우 저조하여 소프트웨어의 공급과 수요의 격차가 매우 컸다. 1960년대 초기까지는 하드웨어 구매 및 하드웨어 유지보수를 위해 사용되는 비용이 시스템 비용의 전부였던 반면 소프트웨어 구입비용은 거의 무시되었다. 당시 소프트웨어 비용은 매우 작은 것으로 인식하고 있었기 때문에 소프트웨어 개발과정과 소프트웨어 개발비용과 프로젝트 관리 비용은 그다지 중요하게 생각하지 않았다. 그러나 1960대 중반부터 사용자 요구사항이 증대하고 하드웨어의 급속한 발달로 인해 소프트웨어 구축에 드는 비용이 40~50% 정도로 증가하기 시작하였다. 하드웨어 기술은 점점 발달하면서 비용이 하락한 반면에 소프트웨어 개발 인건비는 계속 상승하게 되었는데 이것이 가장 큰 원인이 되었던 것이다.
국내의 경우, 1980년대까지 프로그래머는 생산 업체의 기종 특성에 따라 소프트웨어(시스템 소프트웨어 및 응용 소프트웨어)를 각자 개발했어야 했다. 컴퓨터 하드웨어가 바뀔 때마다 소프트웨어도 대폭 수정하여야 했는데, 이는 컴퓨터 제조업체마다 개방형 구조가 아닌 자기 기종에서 고유의 특수한 문제를 처리하려면 직접 제조회사가 소프트웨어를 제작하여 하드웨어와 함께 고객에게 제공하여야 하는 폐쇄형 구조를 갖고 있었다. 이는 소프트웨어가 범용성을 갖고 대량으로 공급할만한 환경이 되지 못하였음을 의미한다.
1960년 중반부터는 하드웨어 성능이 점점 발전함에 따라 컴퓨터 보급이 증가하게 되었는데, 고가의 하드웨어를 도입하면서부터 소프트웨어에 대한 수요도 늘어나게 되었으며 지속적으로 컴퓨터를 효율적으로 사용해야 한다는 인식 또한 증가하게 되었다.
컴퓨터를 효율적으로 관리하기 위해서 필요로 하는 관련 소프트웨어를 개발하여 생산성을 증가시킬 수 있도록 요구하게 되었다. 이때부터 수요자 즉 사용자의 요구는 다양해지고 복잡해진 반면 소프트웨어 생산성을 높일 수 있는 기술과 전문 인력이 절대적으로 필요로 하여 공급이 수요를 충족하지 못해서 생산성에 대해 심각하게 우려하고 걱정하게 되었는데 이것을 ‘소프트웨어 위기(software crisis)’라는 단어로 표현하게 되었다. 당시 생산성 문제와 관련해서 소프트웨어 개발에 있어서는 다음과 같은 문제점을 안고 있었다.
① 개발 예산의 초과와 개발 기간의 지연
프로젝트 계획 수립단계에 소프트웨어 개발 일정과 비용에 대한 예측이 부정확하게 계획된 경우이다. 개발 조직 내에 과거의 유사 프로젝트에 대한 정보와 데이터가 없었거나 전문성과 기술 및 경험이 없는 프로젝트 관리자가 프로젝트를 계획, 추진하였기 때문이다.
② 프로그래머 개인의 판단과 역량에 의한 소프트웨어 개발 추진
소프트웨어 개발과 관련된 공학적 원리와 개발방법 및 표준에 의해 추진되는 것이 아니라 프로그래머 개인의 기술 및 경험과 역량에 좌우되어 추진된 경우이다. 이는 주관적 판단에 의한 예측과 개발 작업을 통해 발생된 판단 오류 등으로 인해 개발이 실패되곤 했었다. 즉 소프트웨어 개발 및 생산에 있어 엔지니어링 원리가 적용되기보다는 프로그래머 개인의 독창성에 의존하였고 효율적인 프로젝트 계획과 관리의 중요성을 외면한 상태로 소프트웨어를 개발한 것이 문제가 되었다.
③ 소프트웨어 품질에 있어서의 문제
소프트웨어 개발에 있어 단계별로 체계적이고 기술적인 검토 및 시험과정을 거치지 않고 완성된 소프트웨어에 대해 신뢰성에 문제점을 보인 경우이다. 자체적으로나 외부의 전문가 및 전문기관을 이용한 품질보증 활동이 미흡한 경우에 발생된다. 이러한 위기를 극복하기 위한 제반문제를 해결하려는 노력과 배경이 소프트웨어공학이라는 학문을 통해 연구되고 개발되어야 하는 필요성으로 대두하게 되었다. 즉 소프트웨어공학은 공학적인 접근 방법으로 원리를 적용하고 체계적인 개발을 통해 생산성 문제, 품질 문제, 관리 문제 등을 해결하려는 노력의 결정체이다. 소프트웨어공학 발전 추이를 살펴보면 아래 표와 같다.
소프트웨어공학의 발전추이
| 기간 | 중요한 발전 |
|---|---|
1970년대 초 | [구조적 프로그래밍] |
1970년대 중 | [설계방법론] |
1970년대 말 | [분석방법론] |
1980년대 초 | [자동화 도구 및 객체지향 설계 및 프로그래밍] |
1980년대 말 | [컴퓨터응용 소프트웨어공학] |
1990년대 초 | [객체지향 소프트웨어공학] |
2000년대 현재 | [임베디드 및 컴포넌트 소프트웨어공학] |
3. 접근방법 및 주요 연구영역
1) 접근방법
스프트웨어공학에서는 구조적방법론, 정보공학적방법론, 객체지향방법론, CBD방법론 등을 이용하여 소프트웨어 수명주기에 따라 개발한다. 소프트웨어공학의 뉴 패러다임은 이제 ‘객체지향(object oriented)’이자 ‘컴포넌트(component)’이다. 소프트웨어는 ‘객체’라는 새로운 시각으로 파악된 대상들로 구조화되고 객체 구조만이 지니는 다양한 속성들을 이용하여 프로그래밍의 생산성과 효율을 높인다. 소프트웨어의 개발은 반복적이고, 점진적으로 진행되게 되어 빠르게 개발하고 실패의 위험도 크게 줄일 수 있게 되었다. 이것은 소프트웨어의 컴포넌트화 라는 개발기술에도 영향을 주어 재사용성과 유지보수에 큰 이점을 갖게 된다. 이것은 농업 사회에서 공업 사회로 발전한 것만큼이나 큰 발전이 아닐 수 없다.
2) 소프트웨어공학의 연구영역
소프트웨어공학에서는 요구공학(要求工學, 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) 재사용
소프트웨어에서 재사용하는 지식은 코드뿐만 아니라 응용 분야에 관한 지식, 개발 경험, 설계에 관한 결정, 시스템에 대한 지식, 요구분석 사항, 설계, 문서 등도 포함될 수 있다. 재사용 분야에서는 코드 재사용의 한계를 극복하기 위해 코딩 단계 이전의 분석 설계 단계에서 만들어진 산출물을 재사용하려는 노력을 계속하고 있다.
4. 주요 용어 및 관련 직업군
1) 주요용어
• 요구공학: 요구공학은 소프트웨어의 요구사항을 정의하고 관리하는 방법을 연구하는 학문이다. 소프트웨어의 규모가 커지면서 요구사항의 중요성이 날로 커지고 있다. 뿐만 아니라 요구사항을 어떻게 만드는가에 따라 소프트웨어 제품개발의 성공을 좌우하고 있다. 이에 따라 고객의 요구사항에 대한 연구가 늘고 있다.
• 구조적방법론: 업무 활동 중심의 방법론으로 정형화된 절차 및 도형 중심의 도구를 사용하여 사용자 요구사항 파악 및 문서화 하는 기법이다. 정형화된 분석 절차에 따라 사용자 요구사항을 파악, 문서화하는 체계적 분석이론이 며 프로그램 로직 중심 (프로세스 중심) 도형중심의 분석용 도구를 이용 자료 흐름도 (data flow),자료사전(data dictionary), 소단위명세서(mini-spec)를 작성한다.
• 정보공학적방법론: 정보공학방법론(IEM: Information Engineering Methodology)은 기업 정보시스템에 공학적 기법을 적용하여 시스템의 계획, 분석, 설계, 구축과정을 수행하는 데이터 중심의 방법론을 말한다. 기업 정보시스템이 중심이 되고, 정보전략계획(ISP)이 필수이며, 데이터 중심, CASE도구 등 공학적 접근과 사용자 참여가 요구된다. 데이터와 프로세스의 상관분석을 통해 기업에 필요한 정보와 업무를 총체적이고 분석, 설계하기 위해 공학적인 기법을 사용하고, 일련의 작업절차들을 체계화시키며 자동화를 지향하는 방법이다.
• 객체지향방법론: 분석과 설계 및 개발에 있어서 객체지향기법을 활용하여 시스템을 구축 하고자 하는 방법론이다. 업무영역을 상호작용하는 객체들의 집단으로 이해하고 시스템을 구축한다. 자료와 기능을 캡슐화, 객체 간 상호작용은 메시지를 통해서 이루어진다. 안정된 모델, 중요한 측면만 모델링하므로 분석의 초점이 명확하다.
• CBD방법론: 재사용이 가능한 컴포넌트의 개발 또는 상용 컴포넌트들을 조합하여 애플리케이션 개발 생산성과 품질을 높이고, 유지보수 비용을 최소화할 수 있는 개발방법론이다. 컴포넌트기반 개발, 반복적, 점진적 개발프로세스를 제공하며, 표준화된 산출물 작성이 가능하고, 컴포넌트 제작기법을 통해 재사용성을 향상시킬 수 있는 장점을 갖고 있다.
• 형상관리: 일반적으로 형상관리라 하면 소스 코드의 버전을 관리하는 것으로 국한하여 생각하는 경우가 많다. 하지만 (CMMI, SPICE, ITIL 등의) 소프트웨어공학 관점에서 얘기하는 형상관리의 기능의 범위는 변경관리, 릴리스관리까지 포함하여 그 범위가 매우 넓다. 즉, 변경관리 측면에서 CR(Change Request, 변경 요청)이 발생한 이후, 형상항목이 변경되고, 그 변경된 내용이 최종적으로 사용자에게 서비스되기까지의 생명주기를 다룬다고 할 수 있다.
2) 관련 직업군
• 기술 분야 공무원(국가공무원, 관변단체 공무원 등)
• 전문적인 기술인(산업기사, 기술사, 감리사 등)
• 학문분야(대학교수, 연구원 등)
• 산업체(대기업, 중견기업, 중소기업, 창업 등)
• 연구분야(정부기관 연구소 및 민간기업 연구소 컴퓨터 소프트웨어 전문가)
참고문헌
- R. S. Pressman(2005년), Software Engineering: A Pratitioner’s Approach(6th Edition), McGraw-Hill.
- P.fleeger(2001년), Software Engineering: Theory and Practice(2nd Edition).
- Sommerville(2007년), Software Engineering 8/E, Addison Wesley.
- 김태달(2013년), 『최신소프트웨어공학론』, 21세기사.
- 김태달(2006년), 『소프트웨어공학론』, 형설출판사.
- 김태달(2010년), 『시스템 분석 설계』, 홍릉과학출판사.
- 이주헌(1993년), 『실용 소프트웨어공학』, 법영사.
- 최은만(2004년), 『객체지향 소프트웨어공학』, 사이텍미디어.
[네이버 지식백과] 소프트웨어공학 [Software Engineering] (학문명백과 : 공학, 형설출판사)
'프로그래밍 개론 > 소프트웨어개론' 카테고리의 다른 글
| 소프트웨어 개발론 간단한 정리 (0) | 2015.11.20 |
|---|---|
| 소프트웨어 공학이 왜 필요하지? 복잡하기만 한데... (0) | 2015.11.20 |
532
처음 프로그래밍을 시작한 개발자들은 Hello World!를 기억 할 것이다. Hello world가 Hell World가 될 줄 몰랐던 한 개발자의 이야기. 게시글의 출처를 표기하며, 출처를 남기지 않고 펌을 하는것에 대해 법적 책임을 묻지 않습니다.