2014년 11월 2일 일요일

SWEBOK - SW 프로세스 #1 소개





SWEBOK SW Process #1 - 2014-11-02

8장 Software Engineering Process (소프트웨어 공학 프로세스)


(*** 필자주석) 1장의 "Requirements"를 끝내고 2장 설계를 설명하는 것이 순서이긴 하지만 국내 소프트웨어 산업에서 가장 많이 유행했던 용어가 "프로세스" 이었기 때문에 순서를 바꾸어 이 Chapter를 먼저 설명하기로 한다. 프로세스는 효용성 면에서 가장 논쟁적인 이슈이기도 하다. 프로세스라는 일반 용어는 수천 년간 사용되어 왔다. 어떤 일을 체계적인 단계를 정해서 각 단계에 시작 상태가 있고, 정해진 행위를 하고, 산출물이 나오는 것을 표준화하는 것이다. 요리를 해도 프로세스가 있고 골프를 치러가도 프로세스가 있다. 하지만 천재 물리학자인 스티븐 호킹이 말하기를 "인간에게 표준은 없다." 라고 했다. 과학에서도 똑같은 시험결과가 나오지 않는 것과 같이 인간 사회에서의 행동 패턴을 어떤 하나의 표준 프로세스로 정의할 수는 없다는 것이다. 인생에도 생로병사의 표준 프로세스가 있다고 생각하면 있는 것이지만 모든 사람의 인생이 다르기 때문에 표준이 없다 라고 말할 수도 있다. 프로세스라는 용어 자체가 극도로 추상적인 단어이기 때문에 증명도 어렵고 반증도 어려운 세계이다. 이런 추상화된 세계의 특성에 따라 자연히 사기꾼들이 성행하게 되니 매우 조심할 일이다.

프로세스에 관한 한 국내 소프트웨어 업계에서는 미국의 CMMI나 유럽의 SPICE와 같은 인증위주로 진행되어 왔다. 사실 이런 인증들은 돈만 들이고 문서만 적당히 만들어 내면 누구나 인증을 받을 수 있다는 것은 업계의 관계자들이라면 모두 알고 있다. 현실을 반영하기 보다는 조작에 가까운 문서를 작성해서 인증을 받는 경우도 비일비재하다. 그렇게 인증을 받았다고 자랑스럽게 언론기사에 광고할 수도 있지만 그런 인증들은 ISO와 같은 국제 표준도 아니고 사실은 인증도 아닌 등급일 뿐이다. 아래 문장을 읽어보면 그 실체를 조금 더 객관적으로 이해할 수 있다.
 

Organizations can be “Rated” at a Capability or Maturity Level based on over 300 discreet “Specific” and “Generic” Practices. Intended to be broadly interpreted, the CMMI is not a “Standard” (ala ISO), so achieving a “Level” of CMMI is not a certification, but a “rating.”

 


CMMI의 경우 SEI가 자기들이 정한 어떤 기준에 맞으면 그 수준을 인정하는 것이고 그런 인증을 요구하는 소수의 업체들과 비지니스를 하려면 필요하긴 한다. 하지만 인증이 실력으로 가치가 있는지 아닌지를 판단하기 위해서는 자기 이력서에 인증 경험을 적어서 취업에 도움이 된다면 가치가 있다고 보면 된다. 국내 이력서에서 프로세스 경험을 적은 것을 심심치 않게 보았다. 국방이나 자동차산업과 같은 특수한 분야에서는 도움이 될 수 있다. 하지만 실리콘밸리에서는 취업에 도움이 되기 보다는 그게 뭔지를 설명하느라 시간만 낭비할 것이다. 실리콘밸리의 회사에서 면접 시에 프로세스에 대한 질문은 하지 않는다.

프로세스의 진정한 가치는 체크리스트와 같은 형식이 아닌 산출물의 내용에 있고, 그 내용의 충실성을 지속할 수 있는 현실적인 프로세스에 있다. 국내에서는 이벤트용으로 인증 받았으니 언론에 자랑스럽게 내는 것은 이해하지만 그 속을 들여다 보면 대부분 실속은 없고 결론적으로 보면 언론에 기사 내는 것이 가장 큰 혜택 중의 하나이다. 이런 관행이 국내 SW 업계 경영자들의 맹목적인 경영방침을 반영하기도 한다. 이런 점이 기업평가 사이트인 glassdoor.com에서 보듯이 국내 기업의 경영진들이 외국인 엔지니어들에게 전문성이 없다는 평가를 받는 이유이다. 인증을 받고 외국 파트너와 얘기를 시작할 수는 있지만 결국은 품질을 확보할 수 있는 현실적인 프로세스여야 가치가 있다. 실리콘밸리에 가서 SW 엔지니어들에게 CMMI나 SPICE를 아는지 물어보면 대부분 용어도 들어본 적도 없다는 것에 놀랄 것이다. 더욱 놀라운 것은 실리콘밸리의 벤처회사도 국내에서 CMMI의 최고 등급을 받은 회사보다 훨씬 더 현실적으로 좋은 프로세스를 가지고 있고 개발도 더 잘한다는 것이다.

국내에서 생각하는 프로세스와 실리콘밸리에서 경험하는 프로세스는 겉모습과 용어는 같을 지 모르지만 속을 들여다 보면 완전히 다르다. 같은 용어라도 모든 회사에게 다 다르게 적용된다. 옳은 것도 아니고 틀린 것도 아니고 적용을 잘해야 하는 것이 프로세스의 어려운 점이다. 손자병법을 읽는 것은 쉬우나 현실에 적용하는 것은 완전히 다르다. 많은 사람들이 손자병법을 읽었지만 손무가 되기는 어렵다. 즉 손자병법을 읽었다는 인증은 받을 수 있지만 소프트웨어 개발이라는 전쟁은 수행하기 쉽지 않다. 아무튼 국내는 소프트웨어 프로세스가 극단적으로 형식적인 면에 치우쳐 적용되고 있는 갈라파고스 섬이다. 대부분의 회사는 프로세스 정립에 돈과 시간을 낭비할 확률이 높지만 시행착오를 하면서 배운다고 위안을 해보자. 단 국내 소프트웨어 산업이 돈과 시간 낭비하다가 외국 경쟁사에 뒤떨어지지 않을 정도만 시행착오를 해 보는 것이 좋겠다.


소개 - SW 공학 프로세스

공학 프로세스는 Resource를 투자해 어떤 Input을 Output으로 변환시키기 위한 일련의 행위를 의미한다. 전기, 기계, 토목, 화학과 같은 전통적인 공학에서는 에너지와 물리적인 형태를 다른 형태로 변환시키는 것이다. 소프트웨어 공학에서는 소프트웨어 엔지니어가 요구사항분석, 설계, 구현, 테스트, 형상관리와 같이 소프트웨어를 개발하고 유지보수하는 일련의 행위와 관련되어 있다. 여기서는 가독성을 위해 "소프트웨어 공학 프로세스"를 그냥 "소프트웨어 프로세스"라고 부르기로 한다.

소프트웨어 공학 프로세스는 다음과 같은 여러 목적을 위해 이용된다.
* 사람들간의 이해, 소통, 협업을 돕고,
* 소프트웨어 프로젝트의 관리를 돕고,
* 소프트웨어 품질을 측정하고 향상시키고
* 프로세스 자체의 개선을 돕고
* 프로세스 실행을 자동화하기 위한 기반으로 이용된다.

소프트웨어 공학 프로세스 지식영역은 다음과 같이 나누어 진다.

1. 소프트웨어 프로세스 정의 (Definition)
1.1 소프트웨어 프로세스 관리 (Management)
1.2 소프트웨어 프로세스 구조 (Infrastructure)

2. 소프트웨어 생명주기 (SW Life Cycles)
2.1 소프트웨어 프로세스의 분류 (Categories)
2.2 소프트웨어 생명주기 모델 (Life Cycle Models)
2.3 소프트웨어 프로세스 적용 (Adaptation)
2.4 현실적인 고려 (Practical Considerations)

3. 소프트웨어 프로세스 평가와 개선( SW Process Assessment and Improvement)
3.1 소프트웨어 프로세스 평가 모델 (Assessment Models)
3.2 소프트웨어 프로세스 평가 방법 (Assessment Method)
3.3 소프트웨어 프로세스 개선 모델 (Improvement Models)
3.4 연속적, 단계적 소프트웨어 프로세스 등급 (Continuous and Staged SW Process Ratings)

4. 소프트웨어 측정 (SW Measurement)
4.1 소프트웨어 프로세스와 제품 측정 (Process and Product Measurement)
4.2 평가결과의 품질 (Quality of Measurement Results)
4.3 소프트웨어 정보 모델 (SW Information Models)
4.4 소프트웨어 프로세스 측정 기술 (Measurement Techniques)

5 소프트웨어 공학 프로세스 도구들 (SW Engineering Process Tools)

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

댓글 1개:

warmpark :

이론을 위한 이론, 형식을 위한 형식이 아닌 알맹이를 위한 기본(이론/형식)이 되었으면 하는 같은 바람으로 글 읽기를 시작합니다.
소프트웨어에 대한 중요성에 대하여 이견을 제시하는 사람을 보지 못했지만, 소프트웨어 가치에 대해 정당한 비용을 지급하려고 하시는 분들 또한 찿기 힘들다는 것이 우리의 현실인 듯 합니다. 좋은 글 감사합니다.