SWEBOK - 소프트웨어 요구사항 #2

SWEBOK 해설 -  Software Requirements #2

1장 Software Requirements (소프트웨어 요구사항)

1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)

1.1 Definition of a Software Requirements (소프트웨어 요구사항의 정의)


기본적으로 Software Requirements는 현실에서 어떤 문제를 해결하기 위해 묘사되는 특성(Property)이다. 해결하려고 하는 문제는 기업의 비지니스 프로세스일 수도 있고, 기존 제품의 개선일 수도 있고, 기구의 컨트롤 시스템일 수도 있고 수 많은 문제들이 있다. 인간 사용자나 비지니스 프로세스나 기구나 대체적으로 동작하는 방식은 복잡하다. 요구사항이라는 것은 소프트웨어가 동작하는 방식에 연관되어 있는 다양한 수준의 사람들이 요구하는 모든 기능들이 고려되는 복잡한 집합체이다.

(***필자주석) 모든 이해관계자들이 요구하는 기능을 다 집어넣는 다는 것은 가장 나쁜 요구사항 작성법이다. 바로 Kitchen Sink라고 말하는 쓰레기 통이다. 요구사항 작성이 어려운 것은 이 모든 이해 관계자들을 조율해서 가장 현실적인 제품을 만들어 내는 것이다.

Software Requirements의 필연적인 특성은 기능으로서나 혹은 시스템에 부과되는 비기능요구사항으로서나 각각 하나씩 독립적으로 검증될 수 있어야 한다는 것이다. 이런 검증은 매우 어렵거나 많은 비용이 들 가능성이 있다. 예를 들어 Call Center의 요구사항을 테스트하기 위해서는 시뮬레이션 프로그램을 개발해야 할지도 모른다. 소프트웨어 요구사항 작성자나 테스트계획이나 품질검증부서는 현실적으로 가능한 자원의 한도 내에서 모든 요구사항이 검증될 수 있다는 것을 보장해야 한다.



또 요구사항은 제한적인 자원과 프로젝트의 트레이드오프를 선택할 수 있도록 우선순위를 명시해야 하는 특성을 가지고 있다.

(***필자주석) 요구사항 작성시 우선순위의 명시는 필수이다. 보통 저지르는 실수는 전부 다 중요하다고 적은 것이다. 그렇게 하려면 적을 필요도 없다. 항상 일정과 자원과 기능의 상충되는 목표를 조율하기 위해서는 모든 기능의 우선순위를 적절히 배분해서 명시해야 한다. 그래서 여러 이해관계자들 사이에서 조율이 필요하다. Kitchen Sink는 최악의 요구사항이라는 것을 인식해 놓기 바란다. 버릴 고객은 과감히 버려야 한다.

1.2 Product and Process Requirements (제품요구사항과 프로세스 요구사항)



제품요구사항은 개발하려고 하는 소프트웨어 제품의 기능이나 제약에 관한 것이다. 반면에 프로세스 요구사항은 소프트웨어를 개발하는 과정에서 부과되는 제약사항들이다. 예를 들어 "이 소프트웨어는 RUP 프로세스 방식을 이용해서 개발할 것이다" 와 같은 것들이다. 혹은 Java를 이용한다와 같은 것들이다.



어떤 소프트웨어는 암묵적인 프로세스 요구사항을 가지고 있다. 예를 들어 테스팅의 경우 특수한 테스팅 기계가 필요할 수도 있고 국방부 프로젝트와 같이 공식적인 문서작성 방식을 따라야 하는 경우도 있다. 프로세스 요구사항은 개발조직에서 자체적으로 설정할 수도 있고, 고객이 설정할 수도 있고  안전검증기관과 같이 국가기관에서 설정할 수도 있듯이 다양한 요구자가 있다.



1.3 Functional and Nonfunctional Requirements (기능요구사항과 비기능요구사항)



기능요구사항은 소프트웨어가 실행하는 기능(Function)을 묘사한다. 보통 기능(Capability) 혹은 특성(Feature) 이라고 알려져 있다. 테스팅 관점에서는 제품 동작을 검증하기 위해서 유한한 테스팅 단계에 의해 검증이 가능한 단위를 의미한다.

(***필자주석) 테스트 케이스의 설명으로 요구사항을 정의할 수 있다는 것이 바로 Agile 방법론 중의 하나이다. 어차피 요구사항과 테스트 케이스가 일대일 매핑이 가능하다면 같은 기능을 두 번 명시하는 것은 중복이라고 할 수 있다. 즉 테스트의 자세한 설명으로 내가 무엇을 개발할지 확실히 알 수 있는 제품이라면 당연히 요구사항을 추가로 적을 필요는 없다. 하지만 그런 제품은 많지 않다는 것이다. 예를 들어 사용자의 관점에서 테스트를 할 수 있는 홈페이지 같은 것들은 숨어있는 로직이 별로 없기 때문에 테스트 케이스를 작성하나 요구사항을 작성하나 큰 차이가 없다. 이럴 경우는 선택의 문제라고 할 수 있다. 정상적인 경우는 요구사항은 요구사항 방식으로 적는 것이 99%의 경우에 해당한다고 보면 된다. 또 요구사항 대신에 테스트 케이스를 적는다고 하더라도 요구사항 작성역량이 있는 상태에서 결정하는 것이 옳다. 기본도 되어 있지 않은 상태에서 테스트 케이스로 요구사항을 대신한다는 것은 매우 위험한 일이다.

비기능요구사항은 제품에 기능 외에 제약사항이 있다는 것을 의미한다. 용어로는 제약요구사항 (Constraint Requirements) 혹은 특성요구사항 (Quality Requirements)이라고 한다. 더 자세하게 나누면 성능요구사항 (Performance Requirements), 유지보수요구사항 (Maintainability Requirements), 안전요구사항(Safety Requirements), 상호운영성성요구사항 (Interoperability Requirements) 등 많은 비기능적인 요구사항들을 의미한다.

(***필자주석)  현실적으로 이 비기능요구사항이 기능요구사항에 비해 작성하기 훨씬 어려운 부분이다. 난이도로 볼 때 10배 이상 어렵다고 볼 수 있다. 그만큼 기능요구사항을 적을 때 보다 훨씬 더 많은 경험이 필요한 분야이다. 템플릿에도 자세한 설명이 나와 있지도 않고 가르쳐 줄 수도 없다. 원칙을 이해하고 상상력을 동원해 적어야 하는 부분이다. 제품의 심각한 문제는 주로 이 비기능요구사항의 부족함에서 생긴다. 소프트웨어 개발에서의 큰 소송은 발주자와 개발자의 커뮤니케이션의 오해에서 생기는데 기능요구사항보다는 비기능요구사항에서 문제가 될 확률이 훨씬 높다. 이 문제는 교육이나 강의로 가르쳐 줄 수 있는 문제가 아니고 같이 일하면서 경험을 쌓으면서 커가는 역량이다.

1.4 Emergent Properties (출현특성)
이 특성은 어느 하나의 컴포넌트에서 나오는 요구사항이 아닌 여러 개의 컴포넌트의 상호작용에 의해 출현되는 요구사항이다. 예를 들어 Call Center에서 얼마나 많은 전화를 응대할 수 있는가 하는 것은 전화 중계기, 전산 시스템, 그리고 전화응대 직원이 현실 상황에서 어떻게 상호작용하는 것에 의해서 결정된다. 이 출현특성은 시스템 아키텍처에서 매우 중요하게 고려되는 요소이다.

(***필자주석) 순수 소프트웨어만을 개발하는 경우라면 소프트웨어 아키텍처만 걱정하면 되겠지만 많은 소프트웨어는 하드웨어 시스템과 같이 연관되어 있다. 그게 소프트웨어 역사에서의 최초 사용도이기도 했다. 바로 임베디드 시스템이다. 그러므로 소프트웨어 요구사항을 작성한다고 하면 많은 경우에 시스템 요구사항과 시스템 아키텍처가 상위수준에서 우선적으로 명시되게 되어 있다. 앞으로도 이 차이점에 대해 뒷부분 여기저기서 나오겠지만 일단은 생각하는 방식과 작성하는 방식은 하드웨어나 소프트웨어나 동일하다는 것을 인식해 놓기 바란다.

1.5 Quantifiable Requirements (정량적인 요구사항)



소프트웨어 요구사항은 명확하게 (Clearly) 그리고 애매모호하지 않게(Unambiguously) 명시되어야 한다. 그리고 가능한 한 정량적으로 명시되어야 한다. "대충" 그리고 "검증할 수 없게" 적는 것은 피해야 한다. 사람마다 다르게 해석되는 대표적인 용어의 예가 "신뢰할 만한" 그리고 "사용자에게 친숙한" 과 같은 용어이다. 정량적인 요구사항은 특히 비기능요구사항의 경우에 중요하다. Call Center의 경우에 정량적으로 비기능요구사항을  명시한 예를 보면 "시간당 처리량(Throughput)이 현재보다 20% 증가해야 하고 치명적인 오류는 시간당 1 * 10**(-8) 보다 작게 발생해야 한다"이다. 이 상위수준의 정량적 요구사항에 따라서 하위 컴포넌트에게 많은 자세한 요구사항이 생겨날테고 또 시스템 어키텍처에 많은 제약을 가하게 될 것이다.

(***필자주석) 정량적으로 적는다는 것이 생각보다는 훨씬 어렵다. 잘 적을 수 있다면 이미 글로벌 분석가 수준이다. 대부분의 초보자들의 핑계는 해보지 않고 어떻게 숫자를 얘기할 수 있느냐고 한다. 해보지 않고도 알 수 있는 방법은 과거의 경험으로 유추하거나 현재의 환경에서 미래를 시뮬레이션 해서 상상해야 하는 매우 어려운 지식산업의 영역이다. 그리고 통찰력도 필요하다. 이 부분을 잘 명시할 수 없다면 외국에서는 계약이 성립되지도 않거니와 운이 좋아 계약을 했다고 해도 100% 소송의 대상이다. 계약의 기쁨이 악몽으로 변하는 지름길이기도 하다. 국내 소프트웨어 SI 업체와의  계약을 보면 이 부분이 매우 취약하다.

1.6 System Requirements and Software Requirements (시스템요구사항과 소프트웨어요구사항)



"시스템"은 International Council on Software and Systems Engineering(INCOSE)에서 다음과 같이 정의된다.



시스템은 원하는 목적을 위해 상호작용해야 하는 모든 요소들의 집합이다. 즉 하드웨어, 소프트웨어, 펌웨어, 사람, 데이터 정보, 조작기술, 시설, 서비스 등 모든 지원시설이다.



시스템요구사항은 시스템 전체에게 부과되는 요구사항이다. 소프트웨어를 포함하는 시스템에서는 당연히 시스템요구사항으로부터 소프트웨어요구사항이 파생되어 나오게 된다. 한편으로는 사용자요구사항(User Requirements)은 고객이나 최종 사용자의 입장에서 정의된다. 반면에 시스템요구사항은 사용자요구사항과 같이 사용자의 관점에서만 본 시스템이 아닌 정부의 규제 조항이나 안전요구사항과 같은 모든 요구사항을 의미한다.

(***필자주석) 시스템요구사항과 소프트웨어 요구사항은 앞으로도 계속 혼란을 가져오는 이슈이므로 조금이라도 빨리 확실한 이해를 해 두는 것이 중요하다. 근본적으로 생각하는 방식은 같지만 생각할 대상이 시스템에서는 광범위하므로 소프트웨어 만의 경험으로는 작성하기 어려운 것은 사실이다. 산업 도메인 지식도 있어야 하고 하드웨어나 경우에 따라 펌웨어에 대한 기본 이해는 하고 있어야 한다.

2. Requirement Process (요구사항 프로세스) - 다음 Post에서 다룬다

SWEBOK - 소프트웨어 요구사항 #1

SWEBOK 해설 - Software Requirements #1



1장 Software Requirements (소프트웨어 요구사항)

(*** 필자주석) "Requirements"를 "요구사항"이라고 편의상 번역해 놓았으나 국내에서는 고객 요구사항, 기능명세서, 요구사항 명세서등 다양한 이름으로 잘못 번역되어 있기 때문에 필자는 기존의 잘못된 이해에 대한 혼란을 피하기 위한 유일한 방법으로 앞으로 계속해서 "Requirement"로 표현한다. 국내에서 시용하는 대부분의 문서와는 100% 일치하지 않으니 기존에 알고 있던 문서와 매칭시키려는 노력은 이 연재가 끝나기 전까지는 당분간 보류하기 바란다. 나중에 전체를 이해하고 나면 국내의 모든 문서가 어느 위치에 있고 다른 방법론의 어떤 문서와 매치되는지를 알 수 있으나 지금으로서는 혼란만 일으키니 지금까지 알고 있던 문서는 당분간 머리 속에서 지워버리자.

소개



소프트웨어 요구사항 지식영역은 소프트웨어 전체 생명주기에서 다음 주제를 다룬다.



* Elicitation(도출)

* Analysis (분석)

* Specification (명시)

* Validation (검증)

* Management (관리)



Requirements와 관련된 활동이 제대로 수행되지 않는다면 소프트웨어 프로젝트는 매우 위태롭다고 이론가들이나 실무자들 모두에게 인식되고 있다.

(***필자주석) 이 문장은 이론가들이라면 수도 없이 들어 보고 주장하는 문장이지만 실제로 위태로운 정도를 상상하기가 어렵다. 하지만 필자의 30년 경험상 학교숙제나 간단한 스마트폰 앱을 개발할때도 Requirements 활동을 하지 않으면 구현을 시작하지 않을 정도로 위태로움을 느낀다. 하지만 초보자들에게 아무리 위태롭다고 해야 그 심각성을 이해시키기는 불가능하다. 바로 "칩 히스"가 "스틱" 이라는 베스트셀러에서 얘기한 "지식의 저주"이다. 초등학생들에게 공부를 잘하라고 아무리 얘기한들 그 중요성을 깨달을 수는 없다. 하지만 세계 최고의 소프트웨어 실무 전문가인 수백 명의 저자들이나 30년을 실리콘밸리의 글로벌회사부터 벤처기업까지에서 일했던 필자가 그 심각성을 주장한다면 다시 한 번 고려하는 것이 좋을 것이다.

Software Requirements는 현실의 문제를 해결하기 위한 소프트웨어 제품의 필요기능과 제한사항을 표현한다. 한편으로 "Requirements Engineering" 이라는 용어는 Requirements의 체계적인 관리라고 정의되어 있다. 하지만 이 "Requirements 지식영역"에서는 용어의 혼란을 피하고 일관성을 위해서 "Software Engineering"을 의미하는 경우가 아니고는 "Engineering" 이라는 용어를 여기서는 사용하지 않는다. 같은 이유로 시중의 다른 문서들에서 사용되는 "Requirements Engineer" 라는 용어도 여기서는 사용하지 않는다.

그 대신 Requirements를 수행하는 사람들을 "Software Engineer" 혹은 "Requirements Specialist" 라는 용어를 사용하기로 한다. Requirements Specialist는 일반적으로  Software Engineer가 아닌 사람들이 분석작업을 할 경우 붙이는 용어이지만 그렇다고 Software Engineer가 분석 작업을 할 수 없다는 것은 아니다. 즉 Software Engineer이든 개발자가 아닌 Requirements Specialist이건  둘 다 분석 작업을 할 수 있다.

(*** 필자주석) 여기서 저자들이 "소프트웨어 공학"이라는 용어로 잘못 유도되는 잘못을 피하기 위해 아예 공학이라는 말을 사용하지 않겠다는 것이다. 필자도 "소프트웨어 공학" 이라는 용어를 사용하는 것을 극단적으로 피한다. 실무 경험이 없으면서 이론적으로 "소프트웨어 공학" 을 안다고 하는 것이 어불성설인데 그런 이론가들과 필자와의 차이를 두기 위해서이다. 필자는 실리콘밸리에서 자란 실무전문가이지 소프트웨어 공학 이론가는 아닌 것이다.

하여튼 "공학" 이라는 말이 많은 혼란을 일으키고 공학이라는 이름 아래 선 무당들이 국내 소프트웨어를 잘못 이끌어 가는 것을 피하기 위해서는 공학의 진정한 의미를 깨닫기 전에는 일단 공학이라는 단어를 사용하지 않겠다는 저자들의 말에 필자도 전적으로 동의한다. 필자가 평생 동안 소프트웨어 공학을 실행했으면서도 소프트웨어 공학을 한다는 말은 하지 않는 이유이다. 이 부분이 필자의 고민이었듯이 저자들의 심오한 철학적인 면까지도 엿볼 수 있다.

Software Requirements를 수행하는 방법을 프로세스의 관점(Process-based Breakdown)에서 순서대로 나열하면 마치 폭포수모델(Waterfall Model)의 Top-down 방식으로 생각할 수 있다. 하지만 그것은 착각이고 Requirements 과정을 순서적으로 설명하는 것은 각 Requirements의 상세과정을 수행하는 각 과정에서 필요한 자원과 제약사항 등에 대한 설명을 하기 위한 하나의 분류방법인 것이다. 이런 프로세스 관점의 순서대로 설명할 수도 있지만 프로세스가 아닌 제품 관점(Product-based Breakdown)으로 단계를 나눌 수도 있다. 예를 들어 System requirements, Software Requirements, Prototype, Use cases 등과 같은 방법도 하나의 방법이다.



여기에서는 프로세스의 관점에서 나누는데  그것 때문에 마치 프로젝트의 시작시점에서 Requirements의 활동을 모두 완벽하게 수행해야 하는 독립적인 프로세스로 착각할 수 있다. 하지만 Requirements Process는 매우 복잡하고 개발 후반부의 설계, 구현, 테스트, 유지보수, 형상관리 등 모든 지식영역과 매우 밀접하게 관련되어 있다. 즉 하나의 독립된 프로세스는 아니다. 순서적으로 진행할 수도 있고 다른 지식영역 활동과 병행해서 진행할 수도 있다.

(*** 필자주석) 국내에서 거의 모든 사람들이 착각하는 것이 저자들이 얘기하듯이 분석단계를 개발시작시에 첫 단계에서 작성해서 완성하는 것이라고 이론적으로 생각하는 것이다. 반대로 더 큰 착각은 그게 어려우니까 그냥 대충하고 넘어가고 나중에 상세한 부분을 정해나가겠다는 것이다. 둘 다 잘못된 것이다. 하나는 지극히 느린 국방부의 접근 방법이고 두 번째는 개집 만드는 경우에는 괜찮지만 전세계 소프트웨어의 99.9%에 해당되는 상용제품을 만드는 경우에는 나쁜 방법이다.

이미 저자들이 앞부분에서 불충분한 Requirements의 위험성에 대해서 경고했지만 지금 실감하기는 어려울 것이다. 아무튼 이것도 잘못이고 저것도 잘못이라고 하는데 일단 머리에 인식해 두고 계속 경험하면서 과연 저자들이 무엇을 전달하려고 했는지 깨달아 보자.

또 독립된 프로세스라고 생각하고 SRS를 작성하기 위한 문서 Template을 달라고 하는 사람들이 많은데 Template은 인터넷에 널려 있는 것에 불과하고 지금 이 문서에서 말하는 복잡성이나 어려움에 대한 이해를 못하고 있는 것이다. 템플릿은 음식을 담는 그릇일 뿐 중요한 것은 그릇에 담을 내용물인 음식을 만드는 것이다. 필자의 책에서도 언급했지만 더 이상 Template을 찾아 헤매는 노력은 하지 않기 바란다.

"Software Requirements 지식영역"은 다음과 같은 Topic으로 구분된다



1. Software Requirements Fundamentals (본질)

2. Requirements Process (프로세스)

3. Requirement Elicitation (도출)

4. Requirements Analysis (분석)

5. Requirements Specification (명시)

6. Requirements Validation (검증)

7. Practical Considerations (현실적인 고려사항)

8. Software Requirements Tools (도구)

(*** 필자주석) 국내에서 용어의 혼란 때문에 정확한 의미를 이해하는 것이 어려울지 모른다. 특히 Requirements와 Specification의 차이는 문서의 양으로 비교했을 때 10페이지와 1000페이지의 차이일 정도로 크다. 그런데 Requirements를 작성하고서는 Specification을 작성했다고 착각한다. 용어도 요구사항, 고객요구사항, 명세서, 기능명세서, 요구사항명세서 등을 혼용해서 사용하기도 한다. 다 똑같은 문서를 의미하는 것으로 착각하기도 한다. 그래서 필자가 영어를 그대로 사용하지 절대 번역을 하지 않는다. 지금 이 단계에서는 Software Requirements Specifications(SRS)이 위의 8가지 Topic의 결과로 나오는 문서이고 그 중간 과정에서 나오는 문서가 Requirements 라는 것 정도만 이해하고 넘어가자.

위  8개의 Topic은 다음 Post 부터 하나씩 설명하기로 한다.

SWEBOK 해설 시리즈 - 소개

SWEBOK 시리즈  #1 - 2014-06-04



SWEBOK에 대한 소개



Software Engineering Body of Knowledge (SWEBOK, 소프트웨어 공학 지식체계)은 소프트웨어 공학의 지식체계에 대한 ISO/IEC 국제 표준이다. 필자가 그 내용의 심오함에 감탄한 문서이기도 한다. 그 감탄은 필자가 수십 년간 소프트웨어 개발을 해 왔기 때문에 가능한 것이지 충분한 경험 없이는 감동을 느끼기는 어려울 것이라고 생각한다. 이 문서는 법적인 표준이 아니라 소프트웨어 업계에서 일반적으로 공감하는 내용으로서 전 세계 수백 명의 소프트웨어 전문가들이 자발적으로 참여해서 만든 문서이다. 2004년에 V2가 발간되었고 2014년에 V3가 발간되었다. SWEBOK은 거의 모든 소프트웨어 공학활동의 기반이 되는 바이블 같은 문서인 만큼 모든 경우를 설명하는 세세한 내용을 담을 수는 없고 어느 정도 추상적인 수준으로 작성되었다는 것은 자연스러운 일이다.



대부분의 실리콘밸리 소프트웨어 회사에서의 실무적인 경험은 체계적이기는 하지만 공학이론에서 시작한 것이 아니라 현실에서 정립된 방법론이었다. 그런 상황에서 우연히 SWEBOK을 처음 접했을 때 이렇게 훌륭한 문서가 있나 하는 느낌을 받았다. 필자의 수십 년 개발경험의 핵심을 그대로 적어 놓은 것 같았다. 그런 면에서 소프트웨어 공학의 바이블이라고 불리는 것도 전혀 놀랍지 않다. 하지만 그렇게 훌륭한 문서임에도 불구하고 현실적인 이용가치는 거의 없다는 것이 필자의 생각이다. 마치 멋진 예술 작품을 보는 느낌이다. 멋진 그림을 실제로 그릴 수 있게 차근차근 공부해 나가는 것이 이 시리즈의 목적이다.



SWEBOK을 읽고서 이해하고 훌륭한 소프트웨어를 개발한다는 것은 망상이다. 현실과 연결하는 고리가 없기 때문이다. 추상적인 이론은 하나지만 현실은 백이면 백 모두 다르다. 다양하게 응용해서 적용하는 것은 각자 알아서 해야 하는 일이다. 그럼에도 불구하고 소프트웨어 공학의 바이블답게 모든 핵심과 함께 심지어는 가끔가다 요령이나 힌트까지 적혀 있다. 그런 점에서 순수 이론만을 강조하는 문서는 아니지만 각자 처한 환경에 맞게 해석해서 현실에 어떻게 적용하는 지는 최고 경험자가 아니면 불가능한 수준이다. 손자병법과 같이 훌륭한 내용이지만 응용하는 것이 어렵다.



먼저 SWEBOK에 들어가기 전에 근본적으로 소프트웨어 공학에 대한 실체를 이해해 볼 필요가 있다. 소프트웨어의 역사가 60년이 넘어가면서 그 동안에 쌓인 Know-how가 미국의 소프트웨어 산업계에 녹아 들었다. 실리콘밸리에서는 'Software Engineering' 이라는 용어조차도 생소하다는 것은 현실적인 소프트웨어 개발 역량과 소프트웨어 공학 이론을 안다는 것과는 인과관계가 별로 없다는 것을 의미한다. 소프트웨어 공학이 선구자의 입장에서 학계의 연구의 필요성은 있겠지만 현실에서 무조건 받아들이는 것은 조심해야 할 일이다.



소프트웨어 공학은 현실에서 소프트웨어를 잘 개발하는 방법을 연구하는 학문이다. 이론이 현실을 논한다는 데서 모순이기도 하다. 먼저 소프트웨어 공학 자체가 너무 추상적인 단어이기 때문에 종교적인 신념과 같이 사람에 따라 받아들이는 정도가 다르다. 소프트웨어 공학 이론의 세계적인 대가라고 할 수 있는 이바 야콥슨(Ivar Jacobson)조차 그의 저서에서 소프트웨어 공학의 문제점에 대해 다음과 같이 언급했다.



* 단기적인 유행(FAD)과 패션(Fashion)에 의한 흥행

* 검증되지 않은 미숙한 이론에 근거

* 비교할 수도 없는 너무 많은 방법론

* 평가할 수 있는 실험 결과의 부재

* 학계의 연구와 산업계의 실용성의 차이



이 말은 소프트웨어 공학을 맹목적으로 믿고 따라하기 보다는 생각할 만한 요소가 많다는 것을 말해준다. 야콥슨의 말을 한마디로 요약하면 실전을 다루는 소프트웨어 공학을 이론적으로 접근했다는 것이 문제이다. 이론과 현실의 괴리이다. 많은 소프트웨어 개발자들이 소프트웨어 공학에 현혹되어 불필요한 활동을 하게 된 데에는 이론에 너무 집착했기 때문이다.



결론적으로 필자가 SWEBOK의 심오함에 감동했음에도 불구하고 최고 전문가가 아닌 사람들이 실제 현실에 적용하기에는 너무 어렵다. 그래서 그 간극을 메워주기 위한 노력으로 마치 바이블을 해석하듯이 국내 현실에 맞게 시리즈로 설명해보려고 한다.



지금부터 본격적으로 SWEBOK에 대한 해석을 시작해 보자. 필자의 주석은 (***필자주석)으로 표시하였고 나머지 부분은 SWEBOK을 번역한 부분이다.



SWEBOK는 다음의 5가지 목적으로 작성되었다.

1. 세계적으로 소프트웨어 공학에 대해 일관성 있는 정보를 전달한다

2. 소프트웨어 공학의 범위를 명확히 정하고 전산학, 수학, 프로젝트 관리와 같은 다른 활동과의 차이를 명백히 한다

3. 소프트웨어 공학의 내용을 설명한다

4. 소프트웨어 공학의 지식체계에 대한 쉬운 Top-Down 접근방법을 제공한다.

5. 인증이나 자격증의 교과 과정을 위한 기반을 제공한다

(***필자주석) 공식적인 문서답게 딱딱한 용어로 표현되었지만 소프트웨어 공학(즉 개발을 잘하는 방법)에 대해 혼란을 없애고 본질을 이해시키는 것이 목적이다.

이 목적을 위해 15개의 지식영역(KA, Knowledge Area)으로 분류한다.

(***필자주석)  소프트웨어 전문가가 되기 위해 알아야 할 영역이 15개라는 것을 의미한다. 동시에 많은 시간이 걸린다는 것을 의미한다. 심지어는 Software Requirements와 같이 한 분야에 5년 10년이 걸려도 잘 하기 어려운 분야가 있다. 진정한 소프트웨어 전문가가 된다는 것은 프로그래밍을 잘 한다는 것 외에도 많은 것이 필요하다.

1  Software Requirements (소프트웨어 요구사항)
2  Software Design (소프트웨어 설계)
3  Software Construction (소프트웨어 구현)
4  Software Testing (소프트웨어 테스팅)
5  Software Maintenance (소프트웨어 유지보수)
6  Software Configuration Management (소프트웨어 형상관리)
7  Software Engineering Management (소프트웨어 공학 관리)
8  Software Engineering Process (소프트웨어 공학 프로세스)
9  Software Engineering Models and Methods (소프트웨어 공학 모델과 방법론)
10  Software Quality (소프트웨어 품질관리)
11  Software Engineering Professional Practice (소프트웨어 공학 전문가 기량)
12  Software Engineering Economics (소프트웨어 공학 경제학)
13  Computing Foundations (컴퓨팅의 기반)
14  Mathematical Foundations (수학적 기반)
15  Engineering Foundations (공학적 기반)



각 지식영역(KA)은 다시 2 혹은 3 수준의 토픽(Topic)으로 나누어져서 원하는 토픽를 쉽게 찾을 수 있도록 했다.

(***필자주석) SWEBOK이 소프트웨어 생명주기의 모든 영역을 다루므로 책 한두 권으로 전문가가 될 수 있는 것은 아니다. 하나의 KA만 해도 평생을 향상시키면서 가는 것이기 때문에 배우면 배운 만큼 향상된 것으로 생각해야지 언제 완성시킨다는 개념은 없다.

이제 긴 여행을 시작해 보자.