레이블이 스펙인 게시물을 표시합니다. 모든 게시물 표시
레이블이 스펙인 게시물을 표시합니다. 모든 게시물 표시

2009년 8월 9일 일요일

우리는 개발자가 테스트도 다 해요.

별도의 테스트팀이 없는 회사는 정말 많습니다.

별도의 테스트팀이 없이 개발자가 또는 팀장이 테스트에 참여하는 이유는 개발자가 아니면 제품의 기능을 속속들이 알 수 없어서 테스트를 하기가 어렵기 때문입니다. 이렇게 되는 이유는 제품의 스펙이 따로 문서화되어 있지 않기 때문에 개발자가 아니면 스펙을 알지 못하기 때문입니다.

하지만, 개발자는 인건비도 비쌀 뿐더러 테스트를 잘 하지도 못합니다. 그리고 아무리 테스트 능력이 있는 개발자라고 할지라도 자신이 작성한 기능을 테스트 하는 것은 좋은 방법이 아닙니다. 본인은 내부 동작방식을 잘 알기 때문에 기능이 정상적으로 동작하는 방식 위주로 테스트를 하기 마련입니다.

테스트는 반복적이고 전문적인 작업이기 때문에 개발자가 담당하고 있는 이상 정상적으로 이루어지고 있다고 보기 힘듭니다. 

테스트팀을 따로 두기 위해서는 기본적으로 제품의 스펙이 있어야 합니다. 그렇지 않다면 테스트 팀은 그냥 Random 테스트를 마구 해주는 아르바이트생 수준의 역할 밖에 할 수가 없게 됩니다. 실제 수많은 테스트 팀들이 그 정도 수준에서 밖에 테스트를 할 수 없는 열악한 상황에서 일을 하고 있습니다.

기본적으로 제품에 스펙이 존재를 해야 이를 토대로 테스트케이스를 만들어 낼 수 있고, Regression Test가 가능해 집니다. 그리고 테스트팀이 있다면 테스트 자동화에 대해서 좀더 연구를 하게 되고 테스트 효율성을 높이기 위한 작업들을 진행할 수 있습니다.

테스트팀을 두는 것이 비용을 줄이면서도 제품의 품질을 높일 수 있는 방법입니다. 개발 조직을 효율적으로 운영하고 싶으면 전문 테스트팀에 대해서 심각하게 고려해봐야 합니다.

2009년 8월 3일 월요일

이건 기능이 아닌데

의례 스펙, 기능요구사항 등을 정리한 문서를 보면 기능만 잔뜩 나열되어 있는 것은 매우 흔한 일입니다.

소프트웨어를 만든다고 하면 구현해야 할 기능만 알면 제대로 잘 만들 수 있을 것으로 생각하기 십상입니다. 상식적으로 생각해도 기능면 제대로 구현하면 되겠지요. 여기에 UI는 살짝 추가하고요.

하지만, 분석을 할 때 기능보다 더 중요한 것이 비기능 요구사항입니다. 즉, 기능은 아닌데, 요구사항 즉, 스펙인 겁니다. 기능이 중요하기는 하지만, 기능 하나가 잘못되면 이를 고치는 것은 그렇게 어렵지 않습니다. 그런데 비기능에서 잘못되면 소프트웨어를 완전히 뒤엎어야 하는 일이 발생할 수도 있습니다. 

이렇듯 비기능이 기능보다도 더 중요한 측면이 있는데, 눈에 바로 보이지 않는 다는 이유로 간과되기 쉽습니다. 그럼 이렇게 중요한 비기능 요구사항에는 어떤 것들이 있는지 몇 가지만 알아 보겠습니다.

첫째 성능입니다. 소프트웨어가 얼마나 빨리 반응을 보이며 단위 시간당 얼마나 많은 데이터를 처리해야 하는지 정의해야 합니다. 또한 이를 검증하기 위한 기준도 마련이 되어야 합니다.

둘째 안정성입니다. Database와 위젯 시계는 요구되는 그 안정성이 다릅니다. Database는 시스템이 정전이 되어도 데이트가 파손이 되어서는 안됩니다. 그러한 안정성을 보장하기 위한 요구사항도 자세히 기술이 되어야 합니다.

셋째 보안입니다. 데이터는 암호화 되어서 저장이 되어야 하는지? 암호키는 어떻게 보관을 하는지? 프로토콜은 암호화 되어야 하는지? 시스템은 인증을 거쳐서 접근해야 하는지? 등등의 보안 요구사항은 각 소프트웨어마다 다른 요구사항을 가지고 있습니다.

그 외에도 많은 비기능 요구사항은 있습니다. 가용성은 시스템이 24시간 동작하는 것인지 MS-Word처럼 필요할 때 사용하고 종료하는 것인지 기술합니다. 또, 이식성은 현재 지원해야 하는 것이 아니고 향후 미래에 Porting을 하기 용이하도록 만들기 위한 요구사항입니다. 미래에 Windows에서 Linux로 포팅을 할 수도 있고, 여러 언어를 지원하도록 확장할 수도 있습니다. 또 64bit를 지원할 수도 있고, Unicode를 지원하게 될 수도 있습니다. 따라서 미래에 어떻게 할지 계획이 아무것도 없다면 이식성을 정의할 수가 없습니다. 다국어, 개발표준, 메모리 사용제한, 소스코드 재사용성, 유지보수 편의성 등 많은 비기능 요구사항이 있습니다.

딱 보시면 아시겠지만, 하나하나가 잘못 적히면 완전히 소프트웨어 전체를 뒤집어야 하는 것들입니다. 이런 것들이 눈에 보이지 않는다고 기능만 보고 제품을 만들었다가는 앞은 안보고 땅만 보고 달리는 자동차와 같습니다. 조금만 고개를 들면 보이는 막다른 골목으로 가고 있을지도 모릅니다.

기능 신경쓰기도 바쁜데 이러한 수많은 비기능까지 어떻게 신경을 써서 만드냐고요?

그럼, 신경 안쓰고 그냥 만들면 그 요구사항이 사라지나요? 무시된겁니다. 요구사항을 고스란히 남아 있고 나중에 비용을 수십,수백,수천배를 치러야 합니다.

비기능 요구사항을 잘 적는 방법은 그러한 비기능 요구사항에 대하여 경험이 있을 수 있도록 소프트웨어를 개발한 상당한 경력이 필요하고, 적는 방법에 대하여 배우거나 학습이 필요합니다. 또, 이런 과정을 통해서 과거에 간과된 비기능 요구사항이 현재 얼마나 많은 손해를 끼치는 깨우치면서 배워나가게 됩니다. 하지만 이런 과정을 거쳐야 시행착오가 최소화 되지, 비기능 요구사항을 고려하지도 않는다면 항상 바쁘고 앞으로 잘 나아가지 못하는 굴레를 벗어나기 어려울 겁니다.

2009년 6월 29일 월요일

도대체 얼마나 자세히 적어 달라고?!

소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고

구현을 하기 전에 설계서를 작성하고

테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.

즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.

따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

2009년 4월 22일 수요일

개발자들이 바글바글한 외딴섬에 떨어진다면

개발자들이 바글바글한 외딴섬에 떨어졌는데 서로 뒤죽박죽으로 개발을 하고 있고,이들을 3개월 안에 훈련시켜서 정예 개발자로 만들어 한다는 미션이 떨어졌다면 무엇을 하시겠습니까?

Language 기초를 다시 가르칠까요?
UML을 가르칠까요?
문서 작성법을 훈련 시킬까요?
개발방법론을 가르칠까요?
팀워크를 키워줄까요?
OOP를 가르칠까요?

어떻게 하시겠습니까?

나는 스펙을 작성하는 방법을 가르치고 3개월간 훈련을 시킬 겁니다. 

즉 Requirement engineering을 익히게 하겠다는 뜻입니다. 그만큼 스펙은 현재 소프트웨어 개발현장에서 가장 많은 실패의 원인이 되고 있고, 배우기도 가장 어려운 분야입니다. 나는 수많은 개발자들이 작성한 스펙문서(다양한 이름의 문서)를 봐 왔지만, Requirement engineering을 제대로 알고 잘 작성한 스펙문서는 별로 접해보지 못했습니다. 또한 그로 인해서 프로젝트나 제품에서는 수많은 문제들이 야기되고 있었습니다.

물론 스펙을 제대로 쓰기만 한다고 소프트웨어를 잘 개발할 수 있는 모든 준비가 된 것은 아닙니다. 스펙을 쓰는 것은 이제 소프트웨어 제대로 된 소프트웨어 개발에 한 걸음 내디딘 것 뿐입니다. 거꾸로 스펙도 쓰지 않고 소프트웨어를 어떻게 개발하냐고 반문할 수 있습니다. 즉, 무엇을 개발할지도 모르고 여럿이서 소프트웨어를 어떻게 개발하냐는 것입니다. 또 영업이나 고객은 정확하게 무슨 제품이 나올지도 모르고 기다리냐는 것입니다.

하지만, 이에 대한 반론을 얘기하는 사람도 꽤 됩니다. 기존에 제대로 된 스펙 없이도 훌륭한 제품을 많이 탄생했고, 성공한 제품도 꽤 된다고 얘기합니다.  물론 예외는 항상 있습니다. 저도 몇몇 그런 사례를 알고 있습니다.

정확하게 따지면, 그렇게 성공한 제품은 별로 많지는 않습니다. 그리고 초창기에 제품의 크기가 작거나 고객 수가 작을 때는 멋진 제품이었으나 매출이 늘고, 소프트웨어 규모가 커지면서 망가진 제품도 꽤 많습니다. 즉, 스펙의 부실로 혼동에 빠져서 실패한 제품이 꽤 됩니다.

제대로 된 스펙도 없는 제품이 성공할 확률은 잘 작성된 스펙을 토대로 개발하고 유지보수 되는 제품의 성공확률의 1/10도 안될 겁니다. 

소프트웨어 개발자라면 스펙이 왜 중요하고, 스펙을 잘 적기 위해서 배우고 많은 노력을 기울여야 한다는 것을 알아야겠습니다.

PS) 가끔 우리나라가 소프트웨어 업계에서는 섬처럼 느껴지곤 합니다.

2009년 4월 6일 월요일

이 정도도 안되면서 Peer Review를 한다고요?

소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다.

개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요.

Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템과 버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 하고 있어야 합니다. 간단하게 2줄로 설명을 했지만, 이 정도의 역량을 가지고 있는 소프트웨어 회사는 흔하지 않습니다. 즉, 대부분의 회사들이 Peer Review를 시행할 준비가 되어 있지 않고, 억지로 시행한다고 해도 그 효과를 제대로 누리기는 어렵습니다.

스펙과 설계문서를 제대로 만든다는 의미는 이미 Peer Review를 모두 포함하고 있는 것입니다. 여기서 또 많은 개발자들이 스펙과 설계문서를 제대로 만들고 있다고 착각할 수도 있겠지만, 현실은 그렇지 않습니다. 필자의 경험에 의하면 많은 회사와 개발자들이 스펙과 설계문서를 만들고 있다고 착각을 하고 있습니다. 이에 관한 얘기들은 추후에 올릴 계획입니다.

이렇게 얘기를 하면 매우 비관적인 것처럼 보이는데 비관적인 것이 사실입니다. 굳이 거짓된 희망의 메시지를 전하고 싶은 생각은 없습니다. 현실이니까요. 이렇게 된 것은 개발자들만의 탓도 아니고 회사에서 제대로 된 개발 환경 및 교육의 기회를 제공했어야 하는데, 그렇지 못했고 많은 회사들이 그냥 개별 개발자들에 의존해서 주먹구구식으로 개발해왔고 뭔가를 시도하려고 한 회사들도 그렇게 좋은 성과를 낸 회사는 별로 없습니다. 

결론을 말씀드리면 그럼에도 불구하고 Peer Review를 시행하려고 노력하는 것은 의미가 있다고 할 수 있습니다. 하지만 그와 더불어서 개발의 기초를 닦기 위한 노력도 병행해야 합니다. 이미 개발을 잘하고 있는데 기초가 부족하다고 하면 기분이 나쁠 수도 있는데, 사실이기 때문에 말을 돌려서 하고 싶지는 않습니다. 코딩도 잘하고 꽤 근사한 제품도 만들어 내지만, 효과적인 개발의 체계를 갖추고 있지 못한 것을 사실입니다. 그래서 좀더 좋은 제품을 좀더 짧은 시간에 개발할 수 있는데 그렇지 못하고 개발자들은 제대로 성장할 수 있는 기회를 갖추고 있지 못한 것입니다. 

앞으로 개발자로서 10년, 20년 후의 모습이 그려지지 않는다면 소프트웨어 회사로서 제대로 체계를 갖추고 있지 못한 것이 확실합니다. 제대로 소프트웨어를 개발하기 위해서 우선적으로 해야 할 것이 무엇인지 생각해야 합니다.

2009년 3월 30일 월요일

외주를 주면 된다고요?

"우리가 못하면 외주를 주면 된다."

이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까?
대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다.

한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요.

인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠?

그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다.

결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만나면 개발은 제대로 되더라도 질질 끌려다니기 일쑤입니다. 또한 외주를 주기 위해서는 분석능력과 관리 능력이 필수 입니다. 특히 해외 업체에 외주를 줄 때는 대단히 정교한 스펙문서(SRS 등)가 필요합니다. 따라서 대다수의 업체는 외주를 줄 능력이 없다고 볼 수 있습니다. 그래서 외주가 아니고 사람만 빌려오는 거죠. 옆에 앉혀놓고 같이 의논해가면서 개발하는 방법이 유일한 방법입니다. 소프트웨어 개발 생산성이 아직도 매우 낮은 수준에 머물러 있는 원인이기도 합니다. 

"스스로 잘 할 수 없다면 외주는 더 어렵다."

2008년 11월 19일 수요일

SRS(Software Requirements Specification)의 중요성

본 블로그에서 소프트웨어 개발, 소프트웨어 공학에 대한 여러 주제에 대해서 다루겠지만, 
특히 나는 요구사항 특히 SRS에 대해서 많이 다루려고 합니다.
"소프트웨어개발의모든것"이라는 책에서도 요구사항에 대해서 가장 중요하게 다루고 있지만 지면의 한계와 다양한 독자층의 눈높이를 맞추기 위해서 욕심보다는 많이 설명하지 못하는 측면이 있습니다.
그래서 소프트웨어 개발단계에서 가장 중요한 "요구사항"에 대해서 천천히 여러분들과 의견을 주고 받으면서 심도있게 다뤄볼까 합니다. 제가 세상의 모든 경우의 요구사항 분석 기술 및 경험이 있는 것이 아니니 여러분들과 토론을 하면서 또 많이 배울 것을 기대하고 있습니다.

먼저 제가 책에서 요구사항에 대해서 설명한 내용을 앞부분을 약간 소개할까 합니다.

 요구사항 분석

소프트웨어 프로젝트에 있어서 가장 흔한 실수 중의 하나가 요구사항이 불명확한 상태에서 급하다는 이유로 일단 설계, 구현을 시작하는 일이다. 어떤 경우는 스펙문서가 아예 없는 상태에서 프로젝트를 진행하는 경우도 있다. 또는 간단한 요구사항 목록을 가지고 스펙이라고 착각하는 경우도 많다.
제대로 된 요구사항 개발 없이 프로젝트를 성공적으로 수행하는 것은 거의 불가능하다. 고객의 요구사항을 상세히 기술하였다고 해서 좋은 요구사항은 아니다. 고객도 자신이 원하는 것을 자세히 모르는 경우가 아주 흔하기 때문이다. 고객의 요구사항을 단순히 기술한 정도의 요구사항은 프로젝트 후반에 많이 바뀔 수 있는데, 요구사항 개발 시 간단히 해결할 수 있는 것을 프로젝트 후반이나 유지보수 시까지 와서야 처리함으로써 수십 배의 비용을 추가로 치르는 경우도 있다.
요구사항 개발은 단순히 요구사항을 옮겨 적는 일이 아니다. 요구사항을 수집하고, 분석하고, 정리하고, 리뷰하는 일을 반복하여 완성도를 높여가는 일이다.
책을 보고, 샘플을 보고, 템플릿을 이용해서 독학함으로써 SRS를 잘 쓰는 것은 거의 불가능하다. 책이 도움은 될 수 있으나, SRS를 제대로 쓰려면 제대로 된 회사에 가서 몇 년 동안 일하면서 배워야 한다. 때에 따라서는 전문가에게 컨설팅을 받는 것도 좋은 방법이다. SRS는 기능공처럼 기법에 따라 작성하면 되는 것이 아니라 인간의 판단이 핵심인 문서이기 때문에 작성이 생각처럼 간단하지 않다.

 요구사항의 중요성

요구사항 문서는 프로젝트에서 작성하는 산출물 중에서 가장 중요하다. 요구사항 문서인 SRS는 소프트웨어 프로젝트의 기둥이다.
소프트웨어 시스템 구축에서 가장 어려운 부분은 무엇을 구축할 것인지를 정확하게 판단하는 것이다. 그러나 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이 불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이 허락하는 한 최대 한도로 많은 정보를 파악하는 것이 좋다. 
잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발 비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며 많은 추가 비용을 발생시킨다. (출처, Software Requirements, Karl E. Wiegers, Microsoft Press)
완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다. 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수 있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.



요구사항 오류는 개발 단계가 지나가면 갈수록 그 수정 비용이 기하급수로 증가한다. 유지보수 단계에서 요구사항 오류를 바로 잡으려면 요구분석 단계에서 바로 잡는 것보다 200배의 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는 요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.

SRS란?

요구사항 분석 문서의 종류는 수없이 많다. 개발 방법론에 따라서 제시하는 요구사항 문서가 다르고, 그 개수도 다르다. 여기서 소개할 문서는 SRS이다. SRS는 이 책 전체에서 소개하는 많은 문서 중에서 가장 중요하다. 프로젝트를 성공으로 이끄는데 가장 중요한 핵심이기 때문이다. 만약 소프트웨어 프로젝트에서 문서를 딱 하나밖에 만들 시간이 없다고 하면 SRS를 만드는 것이 좋을 것이다.




SRS는 IEEE에서 만든 가이드와 표준 Template이 있다. 회사들마다 사용하는 Template이 약간씩 다르지만 문서이름, 목적, 취지는 전세계적으로 표준이라고 보면 된다. 소프트웨어 개발 회사라면 회사에 맞게 각자 커스트마이즈 된 SRS Template을 가지고 있어야 한다.