2014년 8월 30일 토요일

SWEBOK - 소프트웨어 요구사항 #9 (최종)




SWEBOK 해설 Software Requirements #9 (최종)


(***필자주석) 이번 포스트가 Software Requirements의 마지막 포스트인 도구에 관한 꼭지이다. 이제 Requirements를 끝내고 다음은 설계(Software Design)에 대한 포스트를 시작될 것이다. 이 꼭지는 양이 많지 않으니 먼저 번역을 하고 주석을 달도록 하겠다.



1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)
8. Software Requirements Tools (도구)

Software Requirements와 관련된 도구는 크게 두 가지로 나누어 진다. "모델링 도구"와 "요구사항 관리도구" 이다.

요구사항 관리도구는 문서화(Documentation), 추적(Tracing), 변경관리(Change Management) 등이 있는데 실제 개발에 큰 영향을 미친다. 사실 요구사항 추적이나 변경관리는 도구가 없이 수행하기는 비현실적이다. 요구사항 관리도구는 요구사항 관련 업무에 핵심적이기 때문에 많은 회사들이 요구사항 관리도구에 투자를 했다. 반면에 훨씬 더 많은 회사들은 만족스럽지는 않지만 스프레드시트와 같은 임시변통(Ad hoc)의 방법으로 관리한다.


(***필자주석) 국내에는 도구에 대한 맹신이 있다. 사실 SWEBOK에서도 도구에 대해서 마지막에 몇 줄로 간단히 언급했듯이 그렇게 많은 비중을 들이지 않았다. 필자는 국내 회사들이 필요 없는 도구에 대한 광적인 집착을 보이는 경우를 많이 보아왔기 때문에 주의를 주고 싶다. 괜히 필요 없는 건강식품을 믿고 먹다가 돈과 건강을 잃는 피해를 입지 않기 바란다. 거의 대부분의 국내 회사는 도구에 신경쓰기에 앞서서 도구를 이용할 내용을 잘 적는 것에 먼저 모든 노력을 하기 바란다. 지금까지 SWEBOK에서 얘기한 것이 바로 내용을 잘 적기 위한 원리를 설명한 것이다. 도구는 내용이 있을 때 마지막으로 걱정할 문제이고 또 그래야지만 자신에게 맞는 적절한 도구를 분별하고 현명하게 구입할 수 있는 능력이 생긴다.

SWEBOK에서 언급한 2가지 도구 중 모델링 도구에 관해서 많이 언급하지 않았지만 예를 들면 UML의 유스케이스 다이어그램을 만들어 주는 도구가 그 중의 하나이다. UML의 많은 다이어그램 중에 유스케이스 다이어그램은 Requirements를 명시하는 방법 중의 하나이다. 모든 프로젝트의 경우에 이용할 수 있는 방식은 아니지만 많은 경우에 사용되기는 한다.

요구사항 관리도구는 양날의 칼이다. 마치 타이거 우즈의 골프채 같은 것이다. 일반 아마추어 골퍼들이 타이거 우즈의 골프채가 좋다고 똑같은 골프채를 사서 친다면 재앙일 것이다. 비싸기만 하고 손해 본다. 그러지 않아도 요새 골프존마켓의 광고에서 고객과 골프상점 점원이 골프채를 서로 잡고 고객은 가져가려고 하고 점원은 안 뺏기려고 티격태격 한다. 고객 말은 "유소연이 이거 들고 일등 했거든요" 점원 말은 "당신은 유소연이 아니거든요. 손님한테 맞는 채를 사셔야 하거든요". 이 광고의 교훈은 비싼 도구와 나에게 맞는 좋은 도구는 다르다 이다. 물론 골프채의 경우는 비싼 채를 들고 다녀야 남들한테 졸부의 과시도 되고 하니까 전혀 가치가 없는 것은 아니다. 마찬가지로 회사의 경우에도 잘 알지는 못하니까 비싼 도구라도 사서 혹시라도 실패 시에 책임도 면하고 자기 과시도 하는 대기업 경영진들도 있다. 왜 비싸고 좋다는 도구를 샀는데 개발이 잘 안될까 하는 것을 필립 그린스펀은 유치원생이 비행기에 올라타서 이 버튼 저 버튼 눌러보면서 왜 비행기가 안 뜨지 하는 것과 같다고 말했다.

추적 관리도구 같은 경우가 어설프게 사용했다가 큰 피해를 입는 경우이다. 요구사항 내용을 적는 능력이 충분히 있고 그런 상태에서 요구 사항을 추적을 하겠다면 필수적인 도구이다. 스프레드시트를 사용하겠다는 경우는 매우 간단한 경우에 해당한다. 수십 명이 개발하는 규모 정도의 프로젝트만 해도 요구사항을 스프레드시트로 관리하기에는 어려울 수 있다. 특히 변경이 자주 일어난다면 변경관리는 거의 불가능하다. 하지만 아무리 도구가 좋다고 한들 내용이 제대로 적혀 있지 않으면 관리하는데 쓸데 없는 비용만 든다. 차라리 추적이나 변경 관리를 하지 않는 것이 좋을 수도 있다.

그럼 언제 도구가 효용성을 발휘할까? 이 답은 글을 쓰는 것과 비교해서 얘기할 수 있다. 내가 글을 쓰려고 하는 데 원고지에다 연필로 쓸까? 간단한 노트패드로 쓸까? 비싼 MS 워드로 쓸까? 하는 질문과 같다. 어떤 도구를 사용하든 먼저 글을 쓸 내용이 준비 되어 있어야 한다. 즉 생각하는 역량이 있은 다음에야 도구가 도와주는 것이다. 도구는 지원하는 도구일 뿐이지 글을 적는 데 핵심은 아니다. 뭘 적을 지도 모르는데 워드 띄워 놓고 쓰레기나 타이핑한다고 글은 나오지 않는다. 요구사항의 내용을 잘 적을 수 있을 때 편리성을 도와 주는 것이 도구인 것이다. 도구가 내용을 도출하는데는 도움이 되지 않는다. 내용을 도출하는 것은 전적으로 두뇌가 하는 행위이기 때문이다. 도구는 마지막에 기록하는데 도움이 되는 것이다.

결론을 말하자면 요구사항관리도구를 사용해서 혜택을 받을 수 있기 위해서는 어느 정도 수준에 올라야만 한다. 아직 국내의 SI 프로젝트나 회사내부 프로젝트의 경우나 다 SRS를 제대로 작성하고 개발하는 경우가 거의 없다. 앞 장에서 말한 대로 인수테스트를 적을 수 있는가 없는가 로도 그 판단을 할 수 있다. 그런 상태에서는 도구를 사용하는 것이 거추장스러운 존재가 될 가능성이 크다. 반대로 SRS를 잘 적을 수 있는 데 도구가 없다면 문제가 될까? 아마 약간의 효율성 저하가 있을 수는 있겠지만 실리콘밸리의 대부분의 벤처기업이나 중소기업들은 요구사항 관련 도구가 없이도 웬만한 규모의 프로젝트는 잘 수행하고 있다. 도구에 관한 문제는 미리 걱정할 필요도 없고 스스로 SRS 작성 역량이 늘어가면 필요한 도구를 선택할 수 있는 역량이 생긴다. 그 때까지는 도구 영업사원들의 과대광고에 현혹되어 피해를 입지 않기 바란다.

SRS를 잘 적는데 실패하는 프로젝트는 보기 어렵다. 반대로 SRS를 잘 적지 않고 성공하는 프로젝트도 보기 어렵다. 그래서 SW 프로젝트는 처음부터 이미 성공할지 실패할 지를 알 수 있다. 이렇게 SW 산업의 성공 조건은 간단하다. 하지만 "간단한 것이 더 어렵다"는 격언처럼 SW 전 생명주기에서 가장 중요하고 어려운 것이 바로 SRS이라고 SW 공학에서 강조한다.

그리고 다음부터 포스트할 설계에 관한 내용도 SRS를 잘 알고 있어야 이해가 쉽다. 필자도 읽고 이해하는 수준이 아니라 머리 속에서 이 원리를 습관적으로 이용하기 위해서 수 없이 반복해서 읽곤 한다. SWEBOK도 여러 번 숙지하면서 읽었어도 항상 새롭게 깨닫는 내용들이 있다. 독자들도 가능하다면 처음부터 다시 한 번 읽어보기를 권장한다.

2014년 8월 17일 일요일

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




SWEBOK 해설 Software Requirements #8


(***필자주석) 앞 포스트에서 인수테스트라는 얘기를 했다. 인수테스트를 작성해야 한다는 것은 소프트웨어 공학에서 많이 들었기 때문에 반론의 여지가 없겠지만 언제 작성하는지가 핵심이다. 지금까지 한국의 소프트웨어 회사에서 한번도 본 적이 없는 것이 인수테스트를 가지고 계약하는 것이다. 계약 시에 인수테스트를 충분히 적을 만큼 요구사항이 자세히 나와 있지도 않거니와 설령 나와 있다고 해도 계약을 위해 인수테스트를 작성한다는 생각을 하지 않을 것이다. 인수테스트를 어느 시점에 작성할 수 있는 역량과 현실에서 언제 작성하는가의 이슈는 다르다. SRS 와 함께 완성할 수 있는 역량이 있다면 언제든지 원하는 시점에 완성할 수 있다. 필자가 실리콘밸리에서 록히드와 계약을 하고 개발을 해주었을 때 SRS보다 더 중요한 것이 인수테스트였다. SRS의 내용은 다르게 해석할 여지가 조금 남아 있지만 인수테스트는 100% 통과해야지만 계약을 준수하는 것이다. 하나라도 통과하지 못하면 계약위반이다. 반대로 인수테스트만 통과하면 계약은 종료된다.

물론 실리콘밸리의 회사가 모든 계약에서 이렇게 하는 것은 물론 아니다. 하지만 그렇게 해야 될 때는 그렇게 한다. 할 수 있는 역량은 있지만 필요에 따라 하기도 하고 안하기도 한다. SRS를 잘 적을 수 있어야만 가능하다. 특히 국방부나 원자력발전소와 같이 대규모의 정교하고 안정된 소프트웨어를 개발할 때 중요해진다. 국내에서는 거의 모든 대규모의 프로젝트가 지연된다. 대규모 프로젝트일수록 인수테스트가 중요해지는데 SRS도 정확하지 않은 상태에서 계약시에 인수테스트를 작성한다는 것은 불가능하다.

역량과 이론과 현실의 삼각 관계에서 어떤 선택을 해야 하는가는 항상 어려운 이슈이다. 무모한 동키호테가 될 수도 있고 이론의 늪 속에 빠져 버릴 수도 있다. 하여튼 이론에서는 인수테스트가 SRS 같이 나와야 하지만 여러 가지 이유로 그렇지 않은 경우가 훨씬 많다. 이 쪽지의 주제가 바로 이론과 다를 수 있는 현실적인 고려사항이다. 현실에서는 고려해야 사항들도 이론과 마찬가지로 중요하다.


1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)
7. Practical Considerations (현실적인 고려사항)

이 전체 챕터의 제목인 "요구사항 지식영역"에서 지금까지 진행한 소제목들이 순서적으로 진행하는 것처럼 보이지만 그것은 편의상 단순하게 나열한 순서일 뿐이다. 요구사항은 전체 소프트웨어 생명주기에 관계된다. 미래에 개발될 제품을 위한 요구사항을 위한 변경 관리와 이미 개발된 제품에 대한 요구사항의 유지의 두 가지가 소프트웨어 공학 프로세스의 성공의 핵심이다.

모든 회사가 요구사항을 작성하고 유지하는 문화를 가지고 있는 것은 아니다. 특히 제품에 목숨을 걸고 한정된 자원 밖에 없는 역동적인 신생기업의 경우 이런 문서작업을 불필요한 오버헤드라고 생각하는 것이 통상적이다. 하지만 이런 회사들이 성장하고 고객이 늘고 제품이 진화함에 따라 과거의 요구사항에 대한 내용을 파악함으로써 미래를 위한 변경에 따른 영향과 파급효과를 이해할 수 있다. 그래서 요구사항문서와 변경관리는 성공적인 요구사항 관리 프로세스에서 핵심적인 역할을 한다.


(***필자주석) 요구사항의 문서가 없이 제품만 가지고 있는 경우는 사상누각과 같다. 더 이상 발전할 수가 없고 기존 제품만 유지보수 하는 것이 최선의 결과이다. 마치 빌딩을 지었는데 설계문서가 없는 것과 같다. 과거의 기억을 되살리면서 겨우 유지보수는 하겠지만 더 큰 빌딩을 지으라고 하면 머리의 기억만으로 지금까지 겪었던 경험과 시행착오를 기억할 수는 없다. 또 인력이 변경되면서 그런 과거의 배움은 사라지고 결과물만 남아있다. 새 제품을 개발하면서 적어도 과거에 개발할 때 결정한 사항이나 기술의 선택에 대한 배경이나 이론을 문서 없이 기억하기는 어렵다. 실제로 개발할 때 보면 복잡한 이슈의 경우 며칠 전에 정한 결정사항도 결과만 기억하지 결정에 이른 복잡한 과정은 기억하지 못하는 경우도 많다. 1,2년이 지나서 비슷한 상황이 생겼을 때 시행착오를 하지 않으려면 과거의 정보는 필수이다. 기억에 의존해서 소프트웨어를 장기간 개발하려고 한다면 소프트웨어를 너무 쉽게 생각한 것이거나 동호회 수준의 제품을 개발을 하고 있는 것이다.


7.1 Iterative Nature of the Requirements Process (요구사항 프로세스의 반복적인 특성)

경쟁적이고 시장 주도의 소프트웨어 영역에서는 점점 더 신속한 개발에 대한 압박이 크다. 더군다나 이미 개발되어 있는 아키텍처(구조) 위에서 업그레이드도 해야 하고 새 제품도 만들어야 하고 기존 제품도 유지해야 하는 동시에 벌어지는 다양한 일이 있다. 그래서 요구사항을 도출하고, 기준선(Baseline)을 긋고, 개발팀에게 넘기는 이론적인 순서로 차례로 수행한다는 것은 현실의 요구사항 프로세스에서는 거의 불가능하다. 그래서 대규모 소프트웨어 프로젝트에서 실제 요구사항이 처음에 완벽하게 이해되고 명시된다는 것은 신화적인 얘기이다.

대신에 요구사항은 설계가 가능할 만한 수준의 품질과 상세도로 반복적인 작업을 통해 정리되어 간다. 어떤 프로젝트에서는 모든 특성을 이해하기 전에라도 기준선을 긋고 개발을 하기도 한다. 물론 잘못된 요구사항이 나중에 발견되면 엄청난 피해를 입는 리스크가 있다. 하지만 소프트웨어 엔지니어들은 프로젝트 관리에 의한 일정을 따라야 하는 제약하에서 움직인다. 그런 환경하에서 주어진 자원으로 작성할 수 있는 최고 품질의 요구사항을 만들어야 한다. 예를 들어 요구사항에 대한 어떤 가정도 분명한 근거가 있어야 하고 알려진 문제에 대해서도 확실히 해결할 수 있다는 근거하에서 가정을 해야 한다.


(***필자주석) SRS를 작성하는 과정에서 가장 어려운 부분이 바로 Assumptions and Dependencies (가정과 의존) 부분이다. 통상적인 국내 개발에서 보면 엄청나게 많은 가정을 가지고 프로젝트를 시작한다. 만약에 가정을 모두 미리 해결할 수만 있다면 프로젝트는 주어진 일정에 정확하게 끝나야 한다. 일정이 지연되는 이유는 알건 모르건 어떤 가정이 생각대로 진행되지 않았기 때문이다. 가정에는 기술적인 이슈도 있지만 인사관리의 이슈도 있고 외주 회사나 플랫폼과 같은 타 회사의 일정에 관계되기도 한다. 그런 경우 가정과 함께 의존성도 생긴다. 이 수 많은 가정을 얼마나 잘 인식하고 도출해 내는 것이 첫번째 필요한 역량이고 그 다음에 어떤 가정을 언제 해결하는가 하는 것을 결정하는 것이 두번째 중요한 이슈이다. 대부분의 국내 회사에서는 거의 희망에 가까운 가정을 하고 해결 계획도 부족한 상태에서 프로젝트에 뛰어든다. 수 많은 가정이 깨어지면서 프로젝트는 아수라장이 된다. 사실은 많은 가정은 아예 초기에 인식조차도 못한다. 이런 상황에서 프로젝트가 제 일정에 끝날 확률은 거의 없다. 프로젝트의 리스크 관점에서는 기능요구사항보다도 훨씬 더 중요하다. 기능요구사항보다 중요한 것이 비기능요구사항이고 그보다 더 중요한 부분이 바로 "가정과 의존" 부분이다. 가정을 모두 해결하고 프로젝트에 들어가는 것은 현실적으로 불가능하다. 그래서 어떤 가정은 해결하고 어떤 가정은 리스크를 택하게 되는데 여기서 인간의 지혜와 경험으로 인한 현명한 결정이 핵심이다. 이 부분이 경험의 차이가 가장 큰 부분이다.


이런 반복적인 모델로 개발하기로 한 프로젝트에서는 요구사항 분석가는 현재 반복주기에 필요한 요구사항의 기준선을 긋고 그 기준선에 기반해서 개발팀은 설계와 구현을 함과 동시에 요구사항 분석가는 다음 반복주기를 위한 요구사항의 기준선을 긋기 위해 분석 작업을 한다. 이 개발모델은 고객에게 제품을 빨리 제공함과 동시에 재작업을 최소화하는 방법이다.


(***필자주석) 대충 보면 이런 방식이 바로 애자일 방식의 개념과 비슷하다. SWEBOK의 저자들이 폭포수 모델을 중심으로 적었을 것이라고 생각한다면 착각이다. 이미 20년 전에도 폭포수 모델의 장단점과 애자일 모델의 필요성에 대한 논쟁도 있었다. 필자도 실리콘밸리의 회사 중 GE와 GTE Government System을 제외하고는 모두 애자일 개념을 사용했다. 물론 그 당시에는 "애자일" 이라는 용어를 사용하지는 않았다. 나중에 만들어진 용어일 뿐이지 그런 행위는 이미 과거 수십 년 전에도 존재하고 있었다. 마치 애자일 방식이 소프트웨어 개발을 잘하는 최신 비법이라고 생각한다면 거대한 착각이다. 소프트웨어 개발의 핵심은 변하지 않았고 그냥 언저리 편법이 건강식품처럼 유행을 타기는 한다. 먼저 정통을 알고 그 다음에 상황에 따라 응용하는 것은 좋지만 정통은 해본 적도 없으면서 편법만 배워서 해결하려고 한다면 100% 실패할 수 밖에 없다.


거의 모든 경우에 요구사항의 이해는 기준선에서 끝나지 않고 설계와 구현단계까지 진화하며 계속된다. 이는 당연히 개발주기의 후반부에서 요구사항의 변경을 초래한다. 소프트웨어 요구사항에서 꼭 이해해야 할 가장 중요한 점은 요구사항의 많은 부분의 변경된다는 것이다. 이유로는 분석 과정에서의 오류도 있지만 많은 경우에 환경의 변화 때문이다. 환경에는 고객의 운영환경, 비지니스 환경, 정부의 규정 변경, 시장의 변화 등이 있다. 무슨 이유든지 간에 요구사항은 변경될 것이라는 것을 인정하고 그 영향을 최소화하도록 불가피하게 준비작업을 해야 한다는 것이다. 변경할 사항은 공식 검토와 승인 프로세스를 따라야 하며 요구사항 추적, 영향력평가, 형상관리와 같은 세심한 관리를 해야 한다. 그래서 요구사항 분석은 생명주기의 전반부에만 한정된 것이 아니라 전체 생명주기에 다 관련된 행위이다. 통상적인 프로젝트에서 소프트웨어 분석 행위는 최초의 도출 과정부터 변경관리의 마지막 단계까지 시간에 따라 계속 진화한다. Top-down 분석과 디자인 모델링의 상위기법과 Bottom-up 구현과 Refactoring 방식의 하위기법의 두 가지 방식이 중간 지점에서 만나도록 해서 두 방식의 좋은 점만을 이용할 수도 있다. 그러나 현실적으로 이런 두 가지 방식의 조합은 소프트웨어 엔지니어들의 경험과 성숙도가 최대한도로 요구되므로 어렵다.


(***필자주석) 앞 쪽에서 필자가 걱정한 것 중의 하나가 SWEBOK이 요구사항이 변할 수 있다고 하는 것이다. 여기서는 한 술 더 떠서 변경 가능성이 아니라 요구사항은 필연적으로 변경된다고 얘기한다. 그럼 변경은 기정사실화 하고 변경이 되기 때문에 요구사항 분석을 대충 하는 것이 좋은가 하는 착각을 하게 된다. 반대로 생각하면 변경이 될 것이기 때문에 그에 대비해서 먼저 분석을 잘해 놓고 나중에 변경 추적, 영향력 분석 등 중요한 이슈들을 분석하고 변경에 대한 대책을 세울 수 있어야 한다. 최초의 SRS가 없다면 변경 시에 더 어려운 일을 당하게 된다. 만약에 요구사항이 전혀 변하지 않고 차라리 문서를 작성하지 않아도 피해가 적다. 결론은 변경이 벌어질 것이기 때문에 SRS를 더 잘 작성해 놓아야 한다.


7.2 Change Management (변경관리)

변경관리는 요구사항 관리의 중심이 되는 토픽이다. 이 토픽은 변경관리의 역할, 프로세스, 변경 내용에 대한 분석 방법에 대한 이슈를 다룬다. Software Configuration Management KA 에서 관련 내용을 다룬다.

7.3 Requirements Attributes (요구사항 속성)

SRS는 요구되는 사양만을 포함하는 것이 아니라 그 외 부수적인 정보들도 포함한다. 부수적인 정보는 요구사항을 관리하고 이해하는 것을 돕는 역할을 한다. 그 중에는 여러 관점에서 본 분류체계(Section 4.1 Requirements Classification), 검증 방법, 관련된 인수테스트계획 등이 있다. 또 각 요구사항이 나온 배경, 요구사항의 근원, 변경 이력 등도 포함된다. 그 중에서도 가장 중요한 속성은 각 요구사항을 식별할 수 있는 고유한 아이디(ID)이다.


(***필자주석) 결국은 나올 수 있는 것은 다 나온다. 각 요구사항을 추적하려면 당연히 고유한 ID가 있어야 한다. 하지만 이런 행위도 요구사항이 적절한 단위로 세세히 나누어지고 잘 분류되어 있을 때 유용한 것이지 수시로 변하거나 대충 큰 단위로 분류를 해 놓았다면 얻는 것보다 시간 낭비할 가능성이 크다. 결국 기본이 되어 있지 않으면 소프트에어 공학에서 말하는 기법을 무조건 사용하는 것은 혜택보다는 피해가 크다.


7.4 Requirements Tracing (요구사항 추적)

요구사항 추적은 요구사항의 근원이 무엇이고 어느 곳에 영향을 미치는 가를 알게 한다. 특히 요구사항이 변경될 때의 영향도 평가에 필수적이다. 요구사항은 뒤로는 시스템 요구사항과 같이 생성의 근원과 요구한 이해관계자들을 인식할 수 있도록 한다. 반대로 앞으로는 그 요구사항을 만족시키는 설계, 소스코드, 테스트 케이스, 심지어는 사용자 매뉴얼의 어떤 부분과 관련이 있는지 까지 추적할 수 있어야 한다.

요구사항 추적은 통상적으로 복잡한 Directed Acyclic Graph(비순환 방향성 그래프, DAG) (Computing Foundation KA참조) 를 형성한다. 이런 DAG나 추적 매트릭스를 관리하는 행위는 전체 생명주기에서 필수적으로 고려해야 하는 행위이다. 만약에 추적표가 제대로 갱신되지 않는다면 영향도 평가를 신뢰할 수 없다.


(***필자주석) 요구사항 추적이 필요하다고 얘기하지만 현실적으로 국내에서 요구사항 추적을 할 정도로 SRS를 잘 적을 수 있는 회사가 있을 까 궁금하다. 기능요구사항은 비기능요구사항에 비해 상대적으로 쉬운 편이다. 실리콘밸리에서도 제대로 하기 어렵고 그래서 잘 이용하지 않는 것이 요구사항 추적이다. 추적을 하라고 하기도 난감하고 하지 말라고 말하기도 난감하다. 특히 대기업일 경우 소프트웨어 공학의 도입에 따라 비싼 도구를 이용해서 시도를 하기도 하지만 그 신뢰성과 효과는 미지수이다. 추적을 하느냐 안하느냐를 결정하기 전에 먼저 SRS를 제대로 적으면서 수 년의 경험을 한 다음에서야 추적을 시도할 것을 권장한다. 프로세스가 요구하니까 무조건 시도했다가는 시간만 낭비하기 딱 좋은 주제이다.


7.5 Measuring Requirements (요구사항 측정)

소프트웨어의 프로젝트에서 어떤 요구사항이 있으면 Volume("양") 에 관한 개념을 가져야 한다. 이 개념은 개발에 드는 비용, 유지보수에 드는 비용, 변경에 드는 비용의 규모를 측정하는데 필요하다. 또 다른 요구사항과 상대적으로 비교할 필요가 있을 때도 유용하다. Functional Size Measurement (FSM, 기능크기측정)이 Function의 규모를 측정하는 기법이다. 이와 관련된 정보는 Software Engineering Process KA에서 다룬다.



(***필자주석) 어떤 요구사항이 있을 때 개발비용과 일정이 얼마나 걸릴까 하는 것은 경영진과 관리자의 최고 관심사이다. 그러니 이 토픽이 소프트웨어 공학에서 없어질 수가 없다. 하지만 이론적이고 수학적인 방법이 과연 가능할까 하는 회의가 든다. 이론적인 소프트웨어 공학자들이 측정이론을 주장해도 일단 필자는 믿지 않는다. 이 부분은 인간의 고유 영역이라고 본다. 규모를 측정하고 일정을 산정할 때의 가장 큰 변수는 누가 개발하는 것이냐 이다. 모든 개발자들의 역량이 다른데 그 상황에 따라서 산정을 다르게 해야 한다. 개발이 끝난 후에 SLOC(소스코드 라인수)나 Function Point를 이용해서 비교하기도 하지만 난이도를 고려하지도 않고 코딩 스타일에 따라 천차만별이기 때문에 큰 의미를 부여할 수 없다. 그럼에도 불구하고 휴대폰에 들어간 소스코드가 몇백만 라인이다 라는 식으로 말할 때는 대충 규모를 판단하는 데 도움이 된다.



8. Software Requirements Tools (도구) - 다음 Post에서 다룬다

2014년 8월 10일 일요일

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




SWEBOK 해설 Software Requirements #7



(***필자주석) 지금까지 요구사항의 도출, 분석을 지나 명시(Specification) 했다. 이제는 내가 명시한 것이 맞는 것인지를 어떻게 증명하는 검증단계에 왔다. 여기서 대충 넘어가면 재앙이 벌어진다. 바로 소프트웨어공학의 1:10:100 법칙에 따른 피해가 벌어진다. 이 단계를 게을리 하면 잘못된 정보를 가지고 다음 단계인 설계를 열심히 하게 된다. 잘못 명시된 요구사항을 설계 단계에서 발견하면 그나마 다행히도 10배의 피해만 입게 된다. 즉 오류를 수정하는 데 들어가는 비용이 10배가 든다. 그 다음 단계인 코딩 단계에서 발견되면 100배의 비용이 들어 간다. 테스트 단계에서 발견되면 1000배의 비용이 들어간다.

쉽게 이해하려면 건축을 생각하면 된다. 건물을 설계단계의 종이에서 고칠 때와 다 만들어 놓고 고칠 때를 상상해 보면 된다. 이론으로 아는 사람은 많지만 실제 벌어지는 국내 프로젝트에서는 똑같은 시행착오를 지금까지 일이십년을 반복해 오고 있다. 그 이유에는 수십가지가 있지만 모두 다 잘못된 핑계에 불과하다. 필자의 책에서도 누누이 얘기하지만 고쳐지지는 않는다. 유일하게 키움증권의 차세대 프로젝트가 제대로 된 SRS를 작성하고 필자가 아는 한 국내에서 처음으로 제 일정에 완성한 프로젝트였다. 필자의 주장을 증명한 케이스이기도 하다. 이에 관해 지디넷(zdnet)에 실린 기사이다.

http://www.zdnet.co.kr/news/news_view.asp?artice_id=20140728162641&type=xml



지금까지의 국내 관행대로 똑같은 방법으로 진행한 프로젝트는 모두 일정연기라는 똑같은 결과를 가져왔고 필자의 주장대로 수행한 유일한 프로젝트는 성공했다. 사실은 필자의 주장이 아니라 IEEE의 전문가들 혹은 실리콘밸리의 회사들의 평범한 관행일 뿐이다. 기본을 무시하고는 어떤 것도 잘 될 수는 없다는 것을 보여준다. 건축, 자동차, 전자, 소프트웨어나 모두 다 같다.

앞 단계의 명시단계에서 오류를 범했더라도 아직도 늦지 않았다. 아직은 종이 서류에 불과하고 공사는 시작하지 않았으니 피해 없이 고칠 수 있는 마지막 기회다.


1장 Software Requirements (소프트웨어 요구사항)
1. Software Requirements Fundamentals (소프트웨어 요구사항의 본질)
2. Requirement Process (요구사항 프로세스)
3. Requirement Elicitation (요구사항 도출)
4. Requirements Analysis (분석)
5. Requirements Specification (명시)
6. Requirements Validation (검증)

작성된 요구사항 문서(SRS)는 검증(Validation)과 테스트(Verification)을 해야 한다. 즉 작성한 소프트웨어 엔지니어가 요구사항을 제대로 이해했다는 것을 검증해야 한다. 더 나아가 문서가 회사의 표준에 맞게 작성되어 있고, 이해할 수 있고, 일관성 있고, 완성도 있게 작성되었다는 것을 검증하는 것도 중요하다. 회사의 표준 용어가 외부의 표준 용어와 다르게 사용된다면 그 두 용어 사이의 매핑 테이블을 만들어야 한다. 이런 점에서 누구나 다 이해하는 표준인 공식적인 표기법(Formal Notation)의 방식을 이용해서 작성했다면 매핑 테이블 같은 것을 만들지 않아도 되는 장점이 있다. 고객과 개발자 등을 포함한 모든 이해관계자들이 문서를 검토해야 한다. 이 문서는 소프트웨어 생명주기에 나오는 모든 산출물(설계문서, 소스코드등) 과 동일한 수준으로 그리고 동일한 방법으로 형상관리를 해야 한다. 요구사항관리도구를 이용해서 요구사항 문서를 만드는 경우에도 마찬가지의 형상관리를 해야 한다.


(***필자주석) 형상관리를 소스코드 관리로 한정해서 생각하는 개발자들이 많지만 사실은 요구사항문서(SRS)가 소스코드만큼 중요하기 때문에 철저한 형상관리(여기서는 버전관리를 의미) 해야 한다. 하지만 대부분의 국내 프로젝트는 SRS는 버전관리를 할 만큼 정확하게 적히지도 않고 소스코드와 내용이 일치되지도 않기 때문에 버전관리를 하나 안하나 의미가 없다. SWEBOK에서 말하는 SRS를 형상관리하라는 말은 글로벌 수준의 회사를 기준으로 말하는 것이고 그렇지 않은 회사는 형상관리 하느라 노력한 대가도 없고 그냥 관리비용만 늘어가니 국내에서는 적당히 형식적으로만 하면 될 것이다. 항상 그렇지만 내용이 충실하면 관리가 중요해 지지만 내용이 부실하면 관리를 해도 의미가 없다. 그냥 형식적인 회사 프로세스에서 형상관리를 요구한다면 역시 형식적으로 흉내만 내면 된다. 그래서 기초가 부족한 상태에서 프로세스를 도입한다고 해야 시간과 비용만 들고 피해만 입는다.


적어도 한 번 이상의 검증을 해야 하고 그 검증을 위한 회의 일정을 공식적으로 미리 정해 놓고 하는 것이 정상이다. 근본적인 목적은 개발자원이 투입되기 전에 문제가 있는 지를 찾아내는 것이다. 다시 말하지만 검증(Validation)은 요구사항문서가 우리가 원하는 소프트웨어를 정확하게 제대로 정의했는지를 조사하는 것이다.


(***필자주석) SRS는 필자의 경험으로 Full Review를 적어도 2번 이상은 해야 한다. 한 번에 통과한다는 것은 기적이다. 아직까지 한 번도 본 적이 없다. 가장 잘 적은 경우의 시나리오는 한 번 검토하고, 검토한 결과에 따라 수정하고, 두 번 째 회의에 모여 모든 이해관계자가 승인해 주는 경우이다. 두 번에 통과하기도 매우 어렵다. 여기서 통과하느냐 마느냐 하는 것도 SRS 내용을 자세히 적었을 때 어려운 것이다. 차라리 내용이 대충 추상적으로 제목 정도만 적혀 있으면 통과하기는 쉽다. 대충 적힌 문서는 시비를 걸기 어렵기 때문이다. 나중에 문제가 생겨서 그렇지 일단 SRS는 통과한다. 나중에 수백 배의 피해를 입는 조삼모사이다. 국내 기준으로 보면 RFP 혹은 기획서 정도의 내용이 적힌 문서가 계약에서 통과된다. 그런 것을 SRS 검증이라고 얘기 할 수는 없다. 결국 진정한 SRS는 한 번도 검증되지 않은 상태에서 설계나 코딩이 벌어지게 되는 것이 국내 현실이다. SWEBOK이 가정한 개발 환경과 실제 국내 환경과는 갭이 크니 그걸 감안해서 잘 해석해야 한다.


6.1 Requirement Review (요구사항 검토)

검증에서 가장 많이 사용되는 방법은 조사(Inspection) 혹은 검토(Review)이다. 여러 명의 검토자 들에게 오류, 잘못된 가정, 불명확한 설명, 비표준적인 내용 등을 찾도록 부탁한다. 검토자 그룹의 멤버가 중요한데 예를 들어 적어도 한 명의 고객대표가 참석해야 한다. 검토하기 쉽도록 체크리스트 같은 가이드가 도움이 되기도 한다. 통상적으로 검토는 시스템 정의서 (System Definition), 시스템 사양서(System Specification), SRS(Software Requirements Specification) 이 완성된 다음에 진행된다.


(***필자주석) SWEBOK에서 체크리스트가 있으면 도움이 될지도 모른다고 했는데 이 부분을 잘못 해석하면 체크리스트에 있는 Yes/No 형식의 답을 한다고 생각하면 오산이다. 체크리스트가 제공해 주는 것은 검토를 해야 할 주제를 혹시라도 빼먹지 않도록 하는 것이지 검토 자체를 도와주는 것이 아니다. 예를 들어 "문서의 가독성"을 검토해야 하는데 Yes/No 로 대답한다면 잘못된 것이다. 체크리스트는 올바른 검토를 하기 위해 필요한 가이드이지 체크리스트가 없어서 검토를 못하는 것도 아니고 체크리스트가 있다고 해도 검토를 제대로 하는 것은 더군다나 아니다. 여행 준비물 체크리스트 정도의 의미라고 생각하면 된다. 필자에게 템플릿과 체크리스트를 보여달라고 하는 개발자들이 많은데 검증의 품질과는 거의 관계가 없다는 것을 알기 바란다.


6.2 Prototyping (프로토타이핑)

프로토타이핑은 개발자가 어떻게 사양을 이해했는가를 검증하는 방법이다. 겸사겸사 눈에 잘 보이니 새로운 요구를 추가하기 쉽기도 하다. 요구사항 도출(Elicitation) 때와 마찬가지로 프로토타입이 효율적으로 사용될 수 있는 부분이 있다. 프로토타입의 장점은 개발자가 어떻게 이해했는가를 볼 수 있는 가장 좋은 방법이고 동시에 무엇이 잘못되었는지를 발견하고 의견을 주기에도 적합하다. 동적인 유저인터페이스를 글로 설명하기는 어렵운 반면에 동적인 애니메이션이 훨씬 더 잘 설명할 수 있다. 프로토타입으로 검증된 요구사항이 수정될 가능성은 매우 낮은 것이 장점이다. 안전요구사항이나 중요한 핵심적인 기능들은 프로토타이핑을 해보는 것이 중요하다. 하지만 프로토타이핑의 단점도 있다. 사용자들이 미적인 이슈에 사로 잡혀 진정한 기능을 게을리 볼 수 있는 위험성도 있고 프로토타이핑의 품질이 나쁘다는 데 있다. 그래서 프로토타이핑 보다는 시나리오북 (Flip-chart based mockup) 같은 방식을 선호하기도 한다. 프로토타입은 개발비용이 많이 든다. 그렇더라도 나중에 잘못된 소프트웨어를 개발하는 것보다는 프로토타이핑을 하는 것이 좋을 수도 있다. 만약 프로토타입이 최종 제품과 비슷한 모습을 가지고 있다면 꼭 버릴 필요는 없다.


(***필자주석) SWEBOK에서 프로토타이핑한 결과를 100% 버려야 한다고 주장할 수는 없는 상황이기 때문에 프로토타입을 실제 제품에 사용할 수도 있다고 하지만 필자의 경험으로는 프로토타입은 버리는 것이 옳다. 프로토타입은 가장 신속히 개발해서 SRS를 검증하는 것이 목표이기 때문에 한가하게 아키텍처 생각하고, 주석 달고, 공통코드 추출하고, 에러처리하고, 등등 할 시간이 없다. 그런 코드를 나중에 그대로 써 먹는다는 것은 얻는 것보다 잃는 것이 많다. 물론 프로토타입에 사용한 코드의 일부분을 사용하는 것은 문제가 없지만 프로토타입은 말 그대로 모형이다. 아파트 모델하우스를 고쳐서 실제 살 집을 만들지 않는 것과 같이 프로토타입은 100% 버린다고 생각해라.


6.3 Model Validation (모델 검증)

분석과정 중에 모델 기법을 사용했다면 모델의 품질을 검증하는 것이 필요하다. 예를 들어 객체모델(Object Model)인 경우 정적 분석(Static Analysis)을 통해 객체간에 어떤 데이터가 움직이는 지와 같은 것을 검증할 수 있다. 만약 공식표기법(Formal Notation)이 사용되었다면 공식적인 로직에 기반한 검증방법을 사용하는 것이 가능하다. 이 부분은 Software Engineering Models and Methods KA 와 밀접하게 관련되어 있다.


(***필자주석) 이 꼭지는 대부분의 독자는 건너 뛰어도 된다고 생각한다. 그 이유는 통상적인 SRS에서는 설계의 상위부분을 다루게 되는데 그럴 경우에 Modeling 기법도 사용하고 Formal Notation도 도입할 수 있는데 국내에서는 SRS 단계에서 그 정도까지 생각하는 경우가 거의 없기 때문에 이 꼭지는 거의 의미가 없다. 모델링은 설계단계에서 수행하는 것이라는 흑백논리의 오류인 것이다. 이 점은 앞 단계에서도 이미 언급되었지만 분석이나 설계단계에서 할 일이 흑백논리로 정해지는 것이 아니고 경우에 따라 원칙을 잘 적용하는 것이 실용주의인 소프트웨어공학을 잘하는 것이다.


6.4 Acceptance Tests (인수 테스트)

소프트웨어 요구사항의 필수적인 단계는 개발이 요구사항에 적힌 그대로 개발이 완료되었냐는 것을 확인하는 것이다. 확인될 수 없는 요구사항은 희망사항(Wishes)에 불과하다. 그러므로 확인하기 위해서 꼭 필요한 일은 어떻게 확인할(Verify) 지를 계획하는 것이다. 대부분의 경우에 인수테스트(Acceptance Test)를 사용한다.


(***필자주석) 확인(Verify)하기 위해서는 확인할 대상이 정확이 명시되어 있어야 한다. 확인할 대상이 대충 적혀 있다면 확인을 아무리 잘한다고 한들 의미가 없다. 그래서 필자가 책에서도 말했지만 세계적인 테스트팀이 와도 SRS가 잘 적혀있지 않다면 소프트웨어 품질이 좋아지지 않는다고 하는 이유이다. 하여튼 일단 테스트를 잘 하는 것은 일부라도 품질을 높이기 위해서는 중요하다. 근래 많이 사용하는 테스트 방법론인 V-Model 혹은 V-testing model을 보면 인수테스트 외에도 많은 종류의 테스트가 있다. 확실한 것은 SRS에 대응되는 테스트는 인수테스트이고 인수테스트가 바로 계약에 사용되는 문서이다. 다른 테스트는 계약에 필요한 것이 아니고 개발을 진행하면서 중간에 필요한 테스트들이다. 고객에게 약속한 최종사양은 인수테스트에서 모두 명시되어야 하고 인수테스트만 통과하면 계약은 종료된다.


인수테스트를 도출하고 설계하는 것이 비기능요구사항 (Nonfunctional Requirements) 의 경우에 매우 어렵다. 검증이 가능하려면 먼저 충분히 분석되고 작은 컴포넌트로 나누어지고 숫자적으로 표현될 수 있어야 한다. Software Testing KA 에서 인수테스트에 관한 추가정보를 얻을 수 있다.


(***필자주석) SRS를 적성할 때 요구사항 종류에는 기능요구사항과 비기능요구사항이 있는데 비기능요구사항은 생각해 내기도 쉽지 않다. 생각해 내기도 어려운 데 테스트 하기도 어렵다. 특히 초보자들은 잘 모르니까 "빨리" "사용하기 용이한" 등 추상적인 용어를 사용하게 된다. 그런 용어는 SRS를 적을 때 절대 사용하면 안 되는 감점요인이다. 그리고 프로젝트 실패 중에서도 큰 실패의 원인은 대부분 비기능요구사항의 부족에서 발생한다. 조금이라도 비기능요구사항의 완성도를 높이기 위해서는 많은 실무 경험이 있어야 한다. 비기능요구사항은 템플릿이나 체크리스트조차 만들기 어렵다. 비싼 상용도구를 사용하더라도 도움이 될 수준까지 자세히 가르쳐 줄 수가 없다. 그러다 보니 국내 대부분의 프로젝트는 아예 비기능요구사항을 적지도 않고 진행하기도 한다. 하여튼 비기능요구사항을 충분히 자세히 적을 수 있다면 이미 글로벌 개발 역량을 가지고 있는 것이다. 즉 SWEBOK을 읽을 것이 아니라 SWEBOK을 작성할 수 있는 수준일 것이다. 그만큼 어려운 것이 비기능요구사항의 작성이다.



7. Practical Considerations (현실적인 고려사항) - 다음 Post에서 다룬다

8. Software Requirements Tools (도구)